[10:14] <munckfish> Hi, I have a proposed update for the linux-ports kernel sat in my Git tree. The changes are for the PS3. I can't test on any of the other architectures unfortunately.
[10:15] <munckfish> could someone explain what the process should be to get these changes reviewed and included?
[10:16] <munckfish> Should I just send a [request pull] message to the kernerl-team list? Or should I try to find folks to test it on other architectures first?
[10:16] <munckfish> also, I appreciate it's late on in the Intrepid cycle, so any advice on how or if at all this is likely to get included would be great.
[10:22] <amitk> munckfish: please send a pull request to kernel-team. How are the changes impacting other arches?
[10:37] <munckfish> amitk: ok I'll do that. The other architectures will be affected in that I re-synced to 2.6.25.16. Most of the few patches I had to apply should only affect powerpc.
[10:37] <munckfish> One patch fixed a boot hang introduced in 2.6.25.10 by code in 
[10:38] <munckfish> drivers/usb/core/hcd.c
[10:39] <munckfish> A diffstat of my changes/patches not including the re-sync is here: http://paste.ubuntu.com/46120/
[10:40] <munckfish> My tree is here: http://kernel.ubuntu.com/git?p=dmunckton/ubuntu-intrepid-ports.git;a=summary
[10:44] <amitk> munckfish: a quick glance doesn't reveal anything catastrophically wrong :) Hopefully stable tree updates shouldn't kill other arches.
[10:45] <munckfish> amitk: great thx for looking over it
[10:46] <munckfish> amitk: so is your main focus on lpia support? I notice that's in the name of your tree on zinc
[10:52] <amitk> munckfish: for the moment, yes
[10:56] <munckfish> ok thx for you help
[10:56] <amitk> munckfish: np
[14:45] <rtg> smb_tp: have you tried sending your depmod changes to the maintainer?
[14:46] <smb_tp> rtg, No not yet. Since the bug I created them seems to be not solved by that (at least there still might be something missing)
[14:46] <smb_tp> s/bug I/bug for which I/
[14:46] <rtg> smb_tp: you were definitely on the right track.
[14:47] <smb_tp> rtg, Probably the machanism that loads the modules for usb devices should stop at the first driver that is successfully loaded
[14:47] <rtg> smb_tp: that seems like a modprobe issue
[14:49] <smb_tp> rtg, Either modprobe or the framework around (suspect hal but just by gut feeling, no proof). You also had some issues with ordering. Did you get around them with this patch
[14:50] <rtg> smb_tp: yep - it solves the case where a new module with a different name supersedes an existing module with regard to device IDs
[14:50] <rtg> and still preserves the search order
[14:50] <smb_tp> rtg, yours was a pci driver IIRC
[14:50] <rtg> smb_tp: yep - but I'm sure USB would suffer the same issue
[14:51] <smb_tp> rtg, The ordering problem in any case. I could see it on two of my machines. Depending on creation order of the dirs the order in which the ids/drivers where listed just changed
[14:52] <rtg> smb_tp: as long as the 2 modules have the same name, then ordering is done correctly, right?
[14:54] <smb_tp> rtg, Yes, and only in that case. Actually that is with or without the patch handled differently. If there is a module with the same name, only the one with the highest priority (search order) will be kept.
[14:54] <smb_tp> For drivers that supply the same pci id, both are listed in the modules.* files
[14:55] <rtg> smb_tp: that as is it should be, so that blacklisting the first module allows you to load the second module.
[14:55] <rtg> but that only works if they have a different name
[14:56] <smb_tp> rtg, yep (to one) if they have the same name (second statement)
[14:56] <smb_tp> rtg, Or I am confused... Let me rethink
[14:56] <rtg> smb_tp: you're right.
[14:57] <rtg> smb_tp: I think you should engage the maintainer on these issues.
[14:58] <smb_tp> rtg, Right, if there are already two corner cases this makes sense. And your case is even solved by a change
[15:00] <smb_tp> rtg, Marco d'Itri?
[15:01] <rtg> smb_tp: dunno, who's in the changelog?
[15:01] <smb_tp> rtg, Him (beside of me and you for the last minor changes. :))
[15:56] <Q-FUNK> howdy!  recent 2.6.27 uploads seem to have broken fbdev.  I cannot get any login prompt on vcons, even when booting in recovery mode. is there any change in how the fbdev modules are compiled that would explain this and how do I fix it?
=== CarlFK1 is now known as CarlF1
[17:33]  * elkan76 hi everybody!
[17:47] <Wellark> nice.. I have a laptop with unsupported rtl8187 wireless and (broken) r8169 wired
[17:47] <Wellark> no network for me :)
[17:48] <Wellark> will provide more info later.. :/
[18:31] <elkan76> Sorry but where can i find the diffrences for the last propossed kernel 2.6.24-21 generic
[18:31] <elkan76> I'm using the previous version of 2.6.24-21, and after the last update, my wireless drop down. I have a Broadcom 4318 AirForceOne rev.02 and Hardy Heron.
[18:31] <elkan76> Thanks for any indication
[18:32] <elkan76> Ohh and my module is b43... :)
[19:17] <Wellark> ok. I used python (no network, no access to compilers or kernel source) to patch the usb id of my rtl8187 usb device to rtl8187.ko and got the wireless working so it's just a matter of adding the ID to rtl8187_dev.c
[19:19] <Wellark> but now dns is not working (might have something to do with NetworkManager doing something smart with resolv.conf) and I can't download any packages atm..
[19:20] <Wellark> does anyone have the interface specification from realtek for r8169 chipsets?
=== philwyett_ is now known as philwyett
[20:39] <elkan76> Hi, i find three bugs that are similar, but in different dates, there are a common factor??
[20:39] <elkan76> https://bugs.launchpad.net/ubuntu/+bug/269533
[23:19] <Kano> hi, does somebody else have got lots of
[23:19] <Kano> [46591.657036] ata2: EH pending after 5 tries, giving up
[23:19] <Kano> [46591.657045] ata2: EH complete
[23:19] <Kano> ?
[23:19] <Kano> with latest 2.6.27-3.4
[23:20] <Kano> seems to be the pata-amd