=== \sh is now known as \sh_away [00:39] same for prism54 as p54pci has same ids [00:39] remove those from prism54 [00:40] very unlikely that a card will work when 2 drivers are loaded [00:42] Why? [00:42] Two drivers can't claim the same card [00:42] they do [00:42] in both cases [00:42] No. They don't. [00:42] of course [00:42] Really. They don't. [00:43] then buy glasses [00:43] No. It is impossible for two drivers to claim the same PCI device. [00:43] The kernel doesn't allow it [00:43] pci_enable_device() will fail [00:43] so which driver do you think will udev load [00:43] i would say the wrong one [00:43] It's arbitrary [00:44] It depends on the order of the inodes in /lib/modules [00:44] funny [00:44] why not make it deterministic by removing pciids like you did for ipw3945 [00:45] That's a perfectly reasonable request [00:45] my card only works with p54pci so remove it from prism54 [00:46] There are some cards with that PCI ID that work better with prism54 [00:46] also i would say that b43 - loaded via ssb should be used now and pciids removed from bcm43xx [00:46] I'd agree [00:46] softmac are more common today [00:47] and p54pci supports those [00:47] as far as i know did prism54 not even support wpa [00:47] Thanks, Kano [00:48] prism54 is really outdated [00:49] also i build the new 5 kernel without those ipw39/49 drivers. but it dont see em in lum yet [00:50] Have you considered sending in a patch to remove the pciids? To kernel-team@lists.ubuntu.com and LKML... [00:50] thats something i can not do [00:51] Because? [00:51] 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] 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] 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] all? [00:53] as they are the same [00:53] i think it is easy enough to verify this with modinfo [00:54] Put it in email so it does not get lost [00:54] http://www.nabble.com/please-add-dm-raid45-2.6.22.1-20070724.patch.bz2-p13426286.html [00:54] that was my mail last time [00:54] there is no final 2.6.24 out therefore no offical patch for it yet [00:55] but thats a needed one [00:55] otherwise only kanotix will be able to use raid5 [00:55] as i patch that always [00:55] Thanks, Kano [00:56] amitk: hey, are you working on lrm? [00:56] tjaalton: sure [00:57] amitk: additional to that patch you need updated dmraid [00:57] but i can provide you that too, thats not the problem [00:58] amitk: I sent an email to the list earlier this week (forgot the subject though) with a couple of fixes [00:59] tjaalton: for the nvidia? [01:00] amitk: that and the convenience package for fglrx-amdcccle [01:00] btw. as you like your lrm package so much: ati updated fglrx [01:00] we know [01:00] or, at least I do :) [01:00] the list of known issues is longer than the list of fixed ones.. [01:00] which is no news [01:01] i think only the widescreen bug was fixed not much more [01:01] partly [01:01] the most funny part was the modline fix mentioned in the release notes [01:01] tjaalton: This week has been overloaded. We'll get to processing all the patches next week [01:01] http://www.phoronix.com/forums/showthread.php?t=7427&page=2 [01:02] one more modelines -> fatal server error for me... [01:02] amitk: there are also some reports about not being able to uninstall nvidia*. I'd like to fix that too [01:02] seems to affect amd64 only [01:03] ok [01:03] * amitk calls it a day. Have a good weekend guys [01:03] hehe [01:03] "look at the time fly" [01:03] sheesh [01:05] I'll work on lrm this weekend and then send a patch on the kernel list.. [02:02] tjaalton: do you need a fix for the avm drivers or did you find it on your own? [02:04] i mean the objcopy -L hack [02:05] from Karsten Keil [02:06] Is it legal to distribute the modified binaries? [02:08] i see no problem, i even got the test hardware for free [02:09] nobody will hurt you [02:09] Yes, but what does the license say? [02:09] read it if you like to [02:10] You're the one offering the patch [02:11] you find it in my avm package [02:11] http://kanotix.com/files/thorhammer/kanotix/non-free/avm/avm_3.11-18.dsc [02:11] this also adds a the cz mod of one driver [02:13] if you want to add that to your repository be sure you have got drdsl for i386+amd64 in it [02:14] capiinfo [02:14] Number of Controllers : 2 [02:14] Controller 1: [02:14] Manufacturer: AVM-GmbH [02:14] 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] the drivers work [02:15] as long as you know how to use em ;) [02:16] look for fxusb_cz special handlinng === reynaldo_ is now known as reynaldo === mekius_ is now known as mekius [06:37] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/156050/comments/13 [06:38] Launchpad bug 156050 in linux-source-2.6.22 "r8180 and ieee80211_rtl cause total system lockup." [Undecided,Won't fix] [06:38] could someone PLEASE re-enable this driver? at least so it can be tested? === \sh_away is now known as \sh [07:57] 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] for bug 104837, I was unable to add link to upstream bug tracker, as the upstream link is not defined [07:58] 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] [08:51] 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. === Lure_ is now known as Lure === asac_ is now known as asac [14:05] 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] Launchpad bug 182603 in linux "Please add simple lhash patch for aufs" [Wishlist,Triaged] https://launchpad.net/bugs/182603 [14:26] laga: is this patch not going to make it into 2.6.24? [14:38] 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] Can you confirm that my investigation on bug 177713 is correct? [19:10] Launchpad bug 177713 in boinc "2.6.24-2: Regression with idle cpu cycle handling" [Medium,Triaged] https://launchpad.net/bugs/177713 [19:17] yes [19:17] I was just about to comment that CFS is "causing" that [19:51] 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] it's a feasible approach, but it would need more testing [19:59] 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] 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] I've linked a patch in the lkml post, it may be worth testing, if it applies and makes sense (just skimmed it) === \sh is now known as \sh_away === \sh_away is now known as \sh