[00:39] <Kano> same for prism54 as p54pci has same ids
[00:39] <Kano> remove those from prism54
[00:40] <Kano> very unlikely that a card will work when 2 drivers are loaded
[00:42] <mjg59> Why?
[00:42] <mjg59> Two drivers can't claim the same card
[00:42] <Kano> they do
[00:42] <Kano> in both cases
[00:42] <mjg59> No. They don't.
[00:42] <Kano> of course
[00:42] <mjg59> Really. They don't.
[00:43] <Kano> then buy glasses
[00:43] <mjg59> No. It is impossible for two drivers to claim the same PCI device.
[00:43] <mjg59> The kernel doesn't allow it
[00:43] <mjg59> pci_enable_device() will fail
[00:43] <Kano> so which driver do you think will udev load
[00:43] <Kano> i would say the wrong one
[00:43] <mjg59> It's arbitrary
[00:44] <mjg59> It depends on the order of the inodes in /lib/modules
[00:44] <Kano> funny
[00:44] <Kano> why not make it deterministic by removing pciids like you did for ipw3945
[00:45] <mjg59> That's a perfectly reasonable request
[00:45] <Kano> my card only works with p54pci so remove it from prism54
[00:46] <mjg59> There are some cards with that PCI ID that work better with prism54
[00:46] <Kano> also i would say that b43 - loaded via ssb should be used now and pciids removed from bcm43xx
[00:46] <mjg59> I'd agree
[00:46] <Kano> softmac are more common today
[00:47] <Kano> and p54pci supports those
[00:47] <Kano> as far as i know did prism54 not even support wpa
[00:47] <mjg59> Thanks, Kano
[00:48] <Kano> prism54 is really outdated
[00:49] <Kano> also i build the new 5 kernel without those ipw39/49 drivers. but it dont see em in lum yet
[00:50] <amitk> Have you considered sending in a patch to remove the pciids? To kernel-team@lists.ubuntu.com and LKML...
[00:50] <Kano> thats something i can not do
[00:51] <amitk> Because?
[00:51] <Kano> i do not write kernel patches, the max is that i seek for code to make a driver work with a new kernel
[00:52] <Kano> therefore i did not announce my own variant of the dmraid45 patch for 2.6.24, but i would suggest to use it as soon as one official one appears like i did not the 2.6.22 kernel - you find still my message in your list
[00:53] <amitk> Then you might be better served writing email to the above email address with the pciids you want removed and your reasons. Putting it on IRC on a Friday night is a hard way get this fixed.
[00:53] <Kano> all?
[00:53] <Kano> as they are the same
[00:53] <Kano> i think it is easy enough to verify this with modinfo
[00:54] <amitk> Put it in email so it does not get lost
[00:54] <Kano> http://www.nabble.com/please-add-dm-raid45-2.6.22.1-20070724.patch.bz2-p13426286.html
[00:54] <Kano> that was my mail last time
[00:54] <Kano> there is no final 2.6.24 out therefore no offical patch for it yet
[00:55] <Kano> but thats a needed one
[00:55] <Kano> otherwise only kanotix will be able to use raid5
[00:55] <Kano> as i patch that always
[00:55] <amitk> Thanks, Kano
[00:56] <tjaalton> amitk: hey, are you working on lrm?
[00:56] <amitk> tjaalton: sure
[00:57] <Kano> amitk: additional to that patch you need updated dmraid
[00:57] <Kano> but i can provide you that too, thats not the problem
[00:58] <tjaalton> amitk: I sent an email to the list earlier this week (forgot the subject though) with a couple of fixes
[00:59] <amitk> tjaalton: for the nvidia?
[01:00] <tjaalton> amitk: that and the convenience package for fglrx-amdcccle
[01:00] <Kano> btw. as you like your lrm package so much: ati updated fglrx
[01:00] <tjaalton> we know
[01:00] <tjaalton> or, at least I do :)
[01:00] <tjaalton> the list of known issues is longer than the list of fixed ones..
[01:00] <tjaalton> which is no news
[01:01] <Kano> i think only the widescreen bug was fixed not much more
[01:01] <tjaalton> partly
[01:01] <Kano> the most funny part was the modline fix mentioned in the release notes
[01:01] <amitk> tjaalton: This week has been overloaded. We'll get to processing all the patches next week
[01:01] <Kano> http://www.phoronix.com/forums/showthread.php?t=7427&page=2
[01:02] <Kano> one more modelines -> fatal server error for me...
[01:02] <tjaalton> amitk: there are also some reports about not being able to uninstall nvidia*. I'd like to fix that too
[01:02] <tjaalton> seems to affect amd64 only
[01:03] <amitk> ok
[01:03]  * amitk calls it a day. Have a good weekend guys
[01:03] <tjaalton> hehe
[01:03] <tjaalton> "look at the time fly"
[01:03] <tjaalton> sheesh
[01:05] <tjaalton> I'll work on lrm this weekend and then send a patch on the kernel list..
[02:02] <Kano> tjaalton: do you need a fix for the avm drivers or did you find it on your own?
[02:04] <Kano> i mean the objcopy -L hack
[02:05] <Kano> from Karsten Keil <kkeil@suse.de>
[02:06] <mjg59> Is it legal to distribute the modified binaries?
[02:08] <Kano> i see no problem, i even got the test hardware for free
[02:09] <Kano> nobody will hurt you
[02:09] <mjg59> Yes, but what does the license say?
[02:09] <Kano> read it if you like to
[02:10] <mjg59> You're the one offering the patch
[02:11] <Kano> you find it in my avm package
[02:11] <Kano> http://kanotix.com/files/thorhammer/kanotix/non-free/avm/avm_3.11-18.dsc
[02:11] <Kano> this also adds a the cz mod of one driver
[02:13] <Kano> if you want to add that to your repository be sure you have got drdsl for i386+amd64 in it
[02:14] <Kano> capiinfo
[02:14] <Kano> Number of Controllers : 2
[02:14] <Kano> Controller 1:
[02:14] <Kano> Manufacturer: AVM-GmbH
[02:14] <Kano> CPU[AMD Athlon 64 X2 Dual Core 3800+ clocked at 1000.000 Mhz]  Kernel[Linux 2.6.24-5-generic i686]  Up[-5:32-]  Mem[-284.8/2027.1MB-]  HDD[-800GB(90%used)-]  Procs[-144-]  Client[Konversation 1.0.1]
[02:14] <Kano> the drivers work
[02:15] <Kano> as long as you know how to use em ;)
[02:16] <Kano> look for fxusb_cz special handlinng
[06:37] <Toma-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/156050/comments/13
[06:38] <ubotu> Launchpad bug 156050 in linux-source-2.6.22 "r8180 and ieee80211_rtl cause total system lockup." [Undecided,Won't fix] 
[06:38] <Toma-> could someone PLEASE re-enable this driver? at least so it can be tested?
[07:57] <Lure> can somebody define upstream packaging for linux-source 2.6.2[04] packages, so that we could link to upstream bugs at bugzilla.kernel.org (and use LP's bug tracking)?
[07:58] <Lure> for bug 104837, I was unable to add link to upstream bug tracker, as the upstream link is not defined
[07:58] <ubotu> Launchpad bug 104837 in linux-source-2.6.20 "kernel warns BUG: at fs/inotify.c:172 set_dentry_child_flags()" [Medium,Confirmed] https://launchpad.net/bugs/104837
[07:58] <Lure> [08:51] <persia> Lure: You'll first need to use https://launchpad.net/ubuntu/feisty/+source/linux-source-2.6.20/+edit-packaging to link the feisty kernel to an upstream project.  You may need to define the project.
[14:05] <laga> btw, i posted an updated patch to bug #182603 . are patches like that one actually suitable for inclusion? (no, not pushing, just wondering if there's any hope for me :))
[14:05] <ubotu> Launchpad bug 182603 in linux "Please add simple lhash patch for aufs" [Wishlist,Triaged] https://launchpad.net/bugs/182603
[14:26] <amitk> laga: is this patch not going to make it into 2.6.24?
[14:38] <laga> amitk: i don't think the aufs maintainer has submitted it for inclusion yet. maybe he will do that when he submits aufs. 
[19:10] <blueyed> Can you confirm that my investigation on bug 177713 is correct?
[19:10] <ubotu> Launchpad bug 177713 in boinc "2.6.24-2: Regression with idle cpu cycle handling" [Medium,Triaged] https://launchpad.net/bugs/177713
[19:17] <crimsun> yes
[19:17] <crimsun> I was just about to comment that CFS is "causing" that
[19:51] <blueyed> Ok. So all those "use idle cpu in the background" programs need to get patched to change the cpu_share value for their user to something like 2?
[19:56] <crimsun> it's a feasible approach, but it would need more testing
[19:59] <blueyed> I think it's cumbersome to change all those packages. To be more futureproof we might want to use cgroups instead and put those scripts in this group - to make it easier to just apply cpu_share=2 to all of them.
[19:59] <blueyed> btw: I don't think cfs is good in this regard: a totally niced process from another user should not hug the whole cpu slices assigned to this user.
[20:01] <blueyed> I've linked a patch in the lkml post, it may be worth testing, if it applies and makes sense (just skimmed it)