[12:25] <BenC> -       if (!pci_test_config_bits(pdev, &piix_enable_bits[ap->port_no] )) {
[12:25] <BenC> -               ata_port_printk(ap, KERN_INFO, "port disabled. ignoring.\n");
[12:25] <BenC> -               ap->eh_context.i.action &= ~ATA_EH_RESET_MASK;
[12:25] <BenC> -               return 0;
[12:25] <BenC> -       }
[12:25] <BenC> -
[12:25] <BenC> +       if (!pci_test_config_bits(pdev, &piix_enable_bits[ap->port_no] ))
[12:25] <BenC> +               return -ENOENT;
[12:25] <BenC> I wonder if that's part of our problem
[12:25] <BenC> the clearing of ATA_EH_RESET_MASK is interesting
[12:27] <defendguin> mjg59: what are you expecting to happen when i do sudo acpi_fakekey 142 ?
[12:29] <mjg59> I don't kniw
[12:29] <mjg59> What does happen?
[12:30] <defendguin> it suspends
[12:31] <mjg59> Ok
[12:31] <mjg59> In that case, something in /etc/acpi is broken
[12:31] <defendguin> the touchpad isn't working now though
[12:31] <defendguin> :-P
[12:32] <mjg59> Have you just been upgrading this machine from dapper?
[12:32] <mjg59> If so, at some point you've altered a conffile in /etc/acpi
[12:32] <defendguin> no this was a fresh install of feisty herd 3 and i just upgraded from there
[12:33] <defendguin> i have 3 5gb partitions and i just keep installing fresh when the time comes to upgrade
[12:33] <mjg59> Well, check that sudo /etc/acpi/sleepbtn.sh also works
[12:34] <defendguin> mjg59: i thought it had to do with the system not realizing that that particular button press even was supposed to do
[12:36] <mjg59> When you press the sleep button, what appears in /var/log/acpid?
[12:38] <BenC> the eh clearing got moved to libata-core is all :/
[12:39] <kylem> eh?
[12:39] <kylem> ;)
[12:39] <mjg59> BenC: Has it ever worked with ata_piix?
[12:40] <BenC> mjg59: I've no idea...I've done some checking and the same problem happens under vmware
[12:40] <BenC> it continues to work, but the exception is printed several times
[12:40] <BenC> it only messed up the CDROM
[12:40] <BenC> the disk is fine
[12:41] <defendguin> mjg59: suspending causes all sorts of problems with wireless returning properly
[12:44] <defendguin> i never had the touchpad problems before with suspending but that crept in somewhere 
[12:44] <mjg59> defendguin: I'll worry about that at some later point
[12:44] <mjg59> Can we fix this bug first?
[12:44] <defendguin> yeah
[12:44] <defendguin> absolutely 
[12:47] <mjg59> So the acpid log stuff is what's relevant
[12:47] <BenC> I wonder if I should switch PIIX3/4 back to piix.ko
[12:48] <defendguin> acpid.log?
[12:49] <mjg59> /var/log/acpid
[12:49] <BenC> or maybe just move all piix pata back to piix.ko
[12:50] <defendguin> pastebin?
[12:50] <mjg59> Yes
[12:53] <defendguin> hmm its screwing up the formatting
[12:54] <defendguin> mjg59: http://pastebin.ca/435401
[12:55] <mjg59> defendguin: Which of those entries corresponds to you pressing the sleep button?
[12:56] <defendguin> i am guessing there is no entry for when i press Fn + F4
[12:57] <mjg59> What do you have in /proc/acpi/button ?
[12:58] <defendguin> lid and power
[12:59] <mjg59> Ok.
[12:59] <mjg59> So you don't have an ACPI sleep button.
[12:59] <defendguin> lid and power Fn + F4 button and no even was made in /var/log/acpid
[01:00] <mjg59> Can't go any further
[01:00] <defendguin> ok
[01:01] <defendguin> mjg59: whats my next step?
[01:01] <mjg59> Work out why you have no sleep button
[01:02] <defendguin> should there be a hibernate button there too?
[01:02] <mjg59> In /proc/acpi? No.
[01:09] <defendguin> mjg59: is there anything i can do to help?
[01:13] <defendguin> :-(
[01:15] <mjg59> defendguin: Right now, it's probably limited to me getting one of those laptops
[01:15] <defendguin> hmmm
[01:15] <defendguin> i could let you remote the laptop
[01:16] <defendguin> that might be a problem when you try to suspend it though
[01:17] <BenC> defendguin: the basic issue is that your laptop is crappy and doesn't produce proper acpi events for the lid and button
[01:17] <mjg59> Well, it doesn't seem to provide an acpi object for the button
[01:17] <defendguin> well closing the lid works fine
[01:17] <mjg59> So the lack of events is unsurprising
[01:17] <BenC> well, for the button I mean
[01:17] <BenC> defendguin: check the linux acpi website for a possible DSDT to fix it, or perhaps a BIOS update, or something
[01:18] <mjg59> If you can pastebin the full dmesg, that would probably help
[01:18] <defendguin> i updated the bios a few weeks back
[01:19] <defendguin> mjg59: i have several dmesg posts on the bug which show the output after me doing several things,  lid close, telling to suspend from dialog box, and button press
[01:20] <mjg59> What was the bug number, again?
[01:21] <defendguin> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/44615
[01:23] <defendguin> hmm i guess i was wrong about that i have lots of lspci output
[01:23] <mjg59> There's no dmesg there
[01:24] <defendguin> would you like me to do some action before giving you the dmesg output?
[01:25] <mjg59> No
[01:25] <mjg59> Full dmesg after a clean boot
[01:25] <defendguin> can i past 4 lines here?
[01:25] <defendguin> paste
[01:26] <mjg59> Sure
[01:26] <defendguin> http://pastebin.ca/435507
[01:26] <defendguin> i'm going to reboot and give you a clean dmesg output
[01:28] <defendguin> that looked particularly interesting
[01:35] <defendguin> mjg59: http://pastebin.ca/435520  here is a fresh dmesg right after boot
[01:36] <mjg59> Do you get that setkeycodes message whenever you press the sleep key?
[01:37] <defendguin> 2 for 2 so far
[01:41] <mjg59> Can you try sudo setkeycodes e017 142
[01:41] <mjg59> And then see if it works?
[01:43] <defendguin> suspend like magic
[01:43] <defendguin> whoot and i still have a wireless network connection
[01:44] <defendguin> no touchpad though
[01:45] <defendguin> [  514.704000]  atkbd.c: Use 'setkeycodes e018 <keycode>' to make it known.
[01:45] <defendguin> [  514.712000]  atkbd.c: Unknown key released (translated set 2, code 0x98 on isa0060/serio0).   I get this error message when i try to hibernate my laptop if you want to knock out 2 birds with one stone
[01:46] <defendguin> not when i try to hibernate but when i press Fn +F12 which should hibernate the laptop
[01:47] <kylem> BenC, i pushed that stuff.
[01:47] <kylem> reviewing stable atm.
[01:48] <BenC> kylem: Ok, I'll merge and prepare a summary
[02:02] <mjg59> defendguin: Can you install http://www.codon.org.uk/~mjg59/tmp/hotkey-setup_0.1-17ubuntu8_i386.deb and see if that helps?
[02:06] <defendguin> ok lets see
[02:06] <defendguin> ok that worked
[02:06] <defendguin> ok that worked
[02:06] <mjg59> Hibernate and suspend?
[02:09] <defendguin> both worked
[02:09] <mjg59> Excellent
[02:09] <defendguin> you da man
[02:09] <mjg59> Not sure it'll hit feisty
[02:10] <mjg59> Though it's fixed for you now
[02:10] <defendguin> mjg59: as long as i know that at some point that patch will find its way into ubuntu
[02:10] <mjg59> Well, it's written
[02:10] <mjg59> The issue is just whether it can be accepted
[02:12] <defendguin> [ 2598.024000]  atkbd.c: Unknown key pressed (translated set 2, code 0x96 on isa0060/serio0).
[02:12] <defendguin> [ 2598.024000]  atkbd.c: Use 'setkeycodes e016 <keycode>' to make it known.   this one is supposed to turn wireless off
[02:13] <defendguin> sorry i forgot about that one
[02:13] <mjg59> Which key is that?
[02:13] <mjg59> fn+f5?
[02:13] <defendguin> yup
[02:14] <mjg59> Any others?
[02:14] <defendguin> nope
[02:14] <mjg59> Ok
[02:20] <defendguin> 44616  44615 and 44614 you may want to make comments on these 3 bugs  
[02:51] <BenC> mjg59: There's actually a chance we'll need a hotkeys-setup update for feisty, so if you plan to upload, let me know so we can coordinate
[02:52] <defendguin> awesome!
[02:55] <mjg59> BenC: Ok. What needs adding?
[03:12] <defendguin> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86820/   i'm also suffering from this bug if anyone is interested
[03:22] <mjg59> defendguin: If you're able to build your own kernel, could you see if http://www.codon.org.uk/~mjg59/tmp/i8042.diff works?
[03:23] <defendguin> mjg59: for what bug?
[03:24] <mjg59> The missing touchpad
[03:25] <defendguin> i've only done it once before a while back
[03:25] <defendguin> did you have that diff already?
[03:26] <mjg59> I've been looking for changes that could have affected this codepath
[03:26] <mjg59> That's the only one that looks relevant
[03:26] <defendguin> would this also effect the num lock being turned on?
[03:33] <mjg59> Dunno
[03:35] <defendguin> let me find some directions on compiling a kernel
[03:35] <defendguin> its been way too long\
[03:36] <mjg59> Ok, I may be able to do this for you
[03:36] <mjg59> You're on 2.6.20-14-generic?
[03:36] <BenC> I can pump out kernels in about 20 minutes if you need to
[03:37] <defendguin> yeah thats the kernel
[03:38] <defendguin> this is the problem with a linux distro appealing to the masses
[03:39] <defendguin> i've been using since RH 7.0 and i've built a kernel once
[03:48] <mjg59> defendguin: Ok, nearly done
[03:48] <mjg59> defendguin: Do you still have -13-generic installed as well?
[03:48] <defendguin> yup
[03:48] <mjg59> Good
[03:48] <mjg59> This may break things :)
[03:49] <defendguin> i've got 12 too
[03:49] <defendguin> since that was the last one that worked with my card reader
[03:50] <mjg59> Ok. Grab http://www.codon.org.uk/~mjg59/tmp/vmlinuz-2.6.20-14-generic
[03:50] <mjg59> And put it in /boot, then reboot
[03:51] <orangey> hey all!
[03:51] <orangey> I'm having an interesting problem here..
[03:51] <orangey> I have an NC6400, which has a non-working keyboard on resume (bug filed)
[03:52] <defendguin> link again please
[03:52] <orangey> Now, when I try to do the fix suggested, removing i8042 and making it a module (CONFIG_SERIO_I8042=m), when I make kpkg, it reverts it!
[03:52] <orangey> defendguin: link to what?
[03:52] <mjg59> orangey: Unlikely to help, but could you grab http://www.codon.org.uk/~mjg59/tmp/vmlinuz-2.6.20-14-generic
[03:52] <mjg59> Put it in /boot and try with that?
[03:52] <mjg59> defendguin: ^
[03:53] <orangey> mjg59: Is this -14.12?
[03:54] <defendguin> mjg59: the file is only 1.5mb?
[03:54] <mjg59> defendguin: Yes, it's only the kernel
[03:54] <mjg59> Not the modules
[03:54] <defendguin> ahhh
[03:55] <mjg59> orangey: Yes
[03:55] <mjg59> With a patch
[03:55] <defendguin> should i be able to rename the old kernel to *.old so i can revert?
[03:55] <orangey> mjg59: Ah. Which patch? I've already patched my i8042 to latest in the git tree.
[03:56] <orangey> Hmm. incidentally, where are the default config files kept?
[03:57] <defendguin> ok rebooting
[03:58] <mjg59> orangey: A reversion of something introduced in 2.6.19
[04:00] <orangey> mjg59: I'm sorry. I don't follow. What is our goal here?
[04:01] <mjg59> To see whether it works
[04:01] <defendguin> well my mouse doesn't work when i booted back up
[04:01] <mjg59> defendguin: dmesg, please?
[04:02] <orangey> mjg59: OK. I'll try it out just as soon as I get this computer's suspend working : )
[04:03] <orangey> found the defconfig!
[04:03] <mjg59> Well, the aim is to see if it fixes your suspend
[04:03] <mjg59> So, y'know
[04:03] <defendguin> http://pastebin.ca/435680
[04:04] <orangey> mjg59: Ah. Gotcha.
[04:04] <BenC> mjg59: Do you know where to find the linux-to-X keycode conversions?
[04:04] <mjg59> BenC: Seriously, do not go there
[04:04] <BenC> or X macros
[04:04] <kylem> heehee.
[04:04] <mjg59> Run xev and see what it says when you hit the keys
[04:05] <BenC> ah, ok
[04:05] <mjg59> defendguin: Hm, looks absolutely fine. That's with the new kernel?
[04:05] <defendguin> uh huh
[04:05] <mjg59> And your keyboard doesn't work?
[04:05] <defendguin> looks fine?
[04:05] <defendguin> keyboard is fine
[04:05] <defendguin> mouse doesn't even light up
[04:06] <mjg59> Oh, sorry, mouse
[04:06] <mjg59> Light up?
[04:06] <defendguin> optical
[04:06] <mjg59> Uhm.
[04:06] <mjg59> How about the touchpad?
[04:06] <defendguin> touchpad works
[04:06] <mjg59> Over suspend/resume?
[04:06] <defendguin> i have not gotten to suspend 
[04:06] <mjg59> I suspect I've broken some of the symbol versioning
[04:07] <mjg59> So your usb modules probably aren't loading properly, or something
[04:07] <mjg59> Please try suspend 
[04:07] <defendguin> ok i'll do that now
[04:08] <BenC> mjg59: I don't see anything remotely useful when I hit the key
[04:08] <defendguin> ok mouse no worky 
[04:08] <BenC> KeymapNotify event, serial 29, synthetic NO, window 0x0,
[04:08] <BenC>     keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
[04:08] <BenC>            0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
[04:08] <defendguin> touchpad no worky
[04:09] <mjg59> defendguin: dmesg after suspend, please
[04:09] <defendguin> lol no mouse to move windows around
[04:09] <mjg59> dmesg > ~/dmesg.stillnotworking
[04:09] <mjg59> reboot
[04:09] <BenC> ctrl+alt+f1 got to terminal and do it
[04:09] <defendguin> ahh yes
[04:09] <orangey> mjg: Incidentally, what are you testing on?
[04:11] <mjg59> A range of systems
[04:11] <orangey> mjg59: Mine appears to be hanging at ipv6:
[04:11] <mjg59> None of them with these problems
[04:11] <mjg59> Yeah, ignore that
[04:12] <mjg59> It ought to get past there eventually
[04:12] <orangey> righto.. finally past that now.
[04:12] <orangey> on inital boot, everything looks to work.
[04:13] <orangey> neither keyboard nor mouse are working on resume.
[04:13] <orangey> mouse=toucpad
[04:13] <mjg59> Ok
[04:13] <mjg59> So unhelpful
[04:13] <mjg59> dmesg from post-resume would be good
[04:14] <orangey> : )
[04:14] <orangey> well, usually my USB mouse works where I might actually get that.. alright, moment.
[04:16] <orangey> actually, a few more keys work now than before.. For example, the power button used to produce nothing, but now acts responsibly. Same with my other hotkeys. But not the keyboard.
[04:16] <defendguin> http://pastebin.ca/435689
[04:16] <mjg59> defendguin: Ok, I've got nothing immediately helpful there
[04:17] <mjg59> You may want to reinstall the standard kernel package to get your mouse back
[04:17] <orangey> mjg59: Can I recover my dmesg after a reboot?
[04:17] <mjg59> orangey: Ah. Not easily.
[04:17] <defendguin> mjg59: i booted up to -13
[04:17] <mjg59> Try this:
[04:17] <mjg59> from a shell in X, do
[04:17] <mjg59> sudo /etc/acpi/sleep.sh force; dmesg >~/dmesg.nokeyboard; sync
[04:18] <mjg59> That should suspend, resume, write the file and then make sure it's on disk
[04:18] <mjg59> Then when you reboot, it'll be there
[04:18] <orangey> what about turning on pm_trace?
[04:19] <orangey> I didn't find it helpful while initially debugging, but do you want me to do that?
[04:19] <rtg_> orangey: It only helps to debug resume hangs.
[04:19] <defendguin> ok one moment
[04:19] <orangey> rtg_: Isn't that what this is?
[04:20] <mjg59> orangey: No, it's resuming but your keyboard isn't working
[04:20] <rtg_> orangey: I thought it was just the mouse not working. You must have other symptoms I'm not aware of.
[04:20] <defendguin> mjg59: is this still gonna work since i booted into a different kernel from the one you patched?
[04:20] <mjg59> defendguin: Sorry, that was directed at orangey, not you
[04:20] <mjg59> I've got all I need from you for now, thanks!
[04:20] <defendguin> ohh ok
[04:21] <defendguin> great
[04:21] <orangey> I must say, I pity you guys for relying on people like me to test your work : )
[04:21] <defendguin> hehehe
[04:22] <BenC> mjg59: was xev really supposed to give me something useful? :)
[04:23] <mjg59> BenC: There ought to be a keycode there
[04:23] <mjg59> Assuming you've already mapped it with setkeycodes
[04:24] <BenC> KeymapNotify event, serial 29, synthetic NO, window 0x0,
[04:24] <BenC>     keys:  4294967174 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
[04:24] <BenC>            0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
[04:24] <BenC> I did, and that's all I get from it
[04:24] <BenC> I mapped it to $KEY_PLAYPAUSE
[04:25] <mjg59> There should be a KeyPress event
[04:25] <BenC> do I need to restart X if I change hotkeys and run /etc/init.d/hotkey-setup start?
[04:25] <mjg59> No
[04:25] <BenC> I don't get a KeyPress or KeyRelease event
[04:25] <mjg59> Oh if this is another of those cases where Dell think "Oh, hey, let's make keys that send DOWN keycodes but never send UP keycodes" I'm going to be really upset
[04:25] <mjg59> Y'know, sort of implausibly upset
[04:26] <defendguin> lol
[04:26] <mjg59> From a console, if you run showkey do you get both a make and a break event?
[04:26] <mjg59> Or just the down?
[04:26] <BenC> I get up/down events from showkey
[04:26] <mjg59> Right, so not that
[04:26] <mjg59> Hm
[04:27] <BenC> I get events from xev on up/down, just not KeyPress/KeyRelease ones
[04:27] <mjg59> Can you grab evtest from somewhere, run that and see what it's sending?
[04:27] <BenC> wait, no, just even on down
[04:27] <BenC> ok, I think I have it lying around somewhere
[04:27] <mjg59> And you're focused in the xev window, right?
[04:28] <mjg59> I can't reproduce this behaviour at all
[04:29] <BenC> yep, it's focused on the xev window
[04:30] <BenC> regular keys produce press/release events, just not these media keys
[04:30] <mjg59> Whack.
[04:30] <mjg59> See what evtest says, I guess
[04:32] <BenC> wow, I have a broadcom keyboard
[04:32] <defendguin> mjg59: did you also get that Fn+F5 wireless bug fixed?
[04:33] <mjg59> Yes
[04:33] <mjg59> Well
[04:33] <mjg59> It sends a keycode
[04:33] <mjg59> But it'll do nothing
[04:33] <BenC> Event: time 1176345196.584872, -------------- Report Sync ------------
[04:33] <BenC> Event: time 1176345198.487478, type 4 (Misc), code 4 (ScanCode), value a2
[04:33] <BenC> Event: time 1176345198.487488, type 1 (Key), code 164 (PlayPause), value 1
[04:33] <BenC> Event: time 1176345198.487491, -------------- Report Sync ------------
[04:33] <BenC> Event: time 1176345198.625543, type 4 (Misc), code 4 (ScanCode), value a2
[04:33] <BenC> Event: time 1176345198.625553, type 1 (Key), code 164 (PlayPause), value 0
[04:34] <BenC> evtest shows goodness
[04:34] <mjg59> Yeah
[04:34] <mjg59> Hm
[04:34] <kylem> GOD DAMN
[04:34] <kylem> -ECHAN
[04:34] <mjg59> Ok. Can you poke things into the gnome keyboard shortcuts panel?
[04:34] <kylem> cough.
[04:35] <BenC> lol
[04:35] <defendguin> huh?
[04:35] <kylem> five keyboards in front of me, bound to happen sooner or later.
[04:35] <BenC> mjg59: already done...will the values in there stay constant based on the code (e.g. 164 in this case)?
[04:36] <BenC> the value in keybindings is 0xa4...will 0xa2 linux code always produce 0xa4 for X keybindings?
[04:37] <mjg59> Yes
[04:38] <mjg59> The mapping is in drivers/char/keyboard.c
[04:38] <mjg59> And then X munges it further
[04:38] <mjg59> You so desperately don't want to try to understand this stuff
[04:38] <mjg59> I tried, and I went odd
[04:39] <kylem> mjg59, was this pre or post acpi?
[04:40] <mjg59> Pretty contempory
[04:44] <BenC> if x key mappings lead to wanting to mess with acpi, I'll pass
[05:19] <defendguin> if any of you guys are ever in Houston let me know so i can buy yall a beer
[05:36] <orangey> mjg59: sorry about that.. long phone call.
[05:36] <orangey> mjg59: is there a new version of that file?
[05:37] <orangey> mjg59: Also, I'm not sure where to post the dmesg file.. pastebin won't take it.
[06:41] <eman_> hey all!
[06:41] <eman_> I'm trying to edit my .config, and make-kpkg after that..
[06:42] <eman_> but it keeps overwriting the .config with oldconfig
[06:42] <eman_> what gives?
[06:48] <fabbione> BenC: ping?
[06:49] <BenC> fabbione: yo
[06:49] <fabbione> BenC: hey dude,, did you happen to pull those 4 OCFS2 changes in our tree?
[06:49] <fabbione> i know you are going to upload another kernel for final
[06:49] <BenC> I did, so they will probably go in Friday
[06:49] <fabbione> perfect.. from the 2.6.20_fixes branch
[06:49] <fabbione> great
[06:52] <eman_> hmmm.
[06:52] <eman_> any hints as to how to make it so that this i8042 module isn't compiled directly into the kernel?
[06:56] <BenC> eman_: This isn't a support channel, it's for ubuntu kernel development
[06:56] <BenC> eman_: I think there might be a #kernelnewbies channel
[06:57] <fabbione> argh.. now i know why git pull was taking this long
[06:57] <fabbione> BenC: did you fork ubuntu-feisty-2.6 and pulled in from linus?
[06:57] <BenC> you didn't do the ubuntu-feisty.git ? :)
[06:57] <BenC> ubuntu-2.6 is basically stock linus kernel right now
[06:57] <fabbione> ok :)
[06:57] <BenC> 2.6.20 moved to ubuntu-feisty.git
[06:58] <eman_> BenC: I'm trying to remove a module from the kernel. When I change it in .config, make-kpkg restores it. I do see why it may not be for here, but it's not an egregious offence to pursue it here.
[06:58] <fabbione> eman_: blacklist the module. if something pulls it in it's because it's required
[06:58] <eman_> fabbione: the module doesn't play nicely with suspend / resume, but is necessary to power my kb and touchpad.
[06:59] <BenC> eman_: I didn't say it was a horrible offense, just that you'd have better luck getting help somewhere else...I don't have an immediate answer to your question, so my next best help was to point you to some place else
[06:59] <eman_> others have reported that when i8042 was a module, suspend/resume worked fine.
[07:00] <eman_> BenC: sorry. My misinterpretation, probably due to the lack of body language or whatnot.
[07:02] <BenC> eman_: On x86 hw, it's forced to be compiled into the kernel
[07:03] <BenC> you can override that by editing drivers/input/serio/Kconfig
[07:03] <eman_> BenC: hmm. That's unfortunate.. 
[07:03] <eman_> ok.
[07:03] <BenC>         tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
[07:03] <BenC> change that line to
[07:04] <BenC>         tristate "i8042 PC Keyboard controller"
[07:04] <BenC> if you need it, you'll have to add it to /etc/modules.conf
[07:05] <eman_> BenC: Thank you. I'll test to see if it works, then update my bug report on it.
[07:11] <eman_> BenC: I put it to: tristate "i8042 PC Keyboard controller"\        default m
[07:11] <eman_> but it still seems like make-kpkg is taking oldconfig, even though I'm doing --config=menuconfig
[12:19] <cjwatson> pkl_: do you know if the HPA stuff is in git?
[12:20] <pkl_> cjwatson: I'll check, Kyle did he'd checked them in...
[12:20] <cjwatson> don't see anything relevant from Kyle
[12:22] <pkl_> hmm, git-pull hangs for some reason at the moment...
[12:23] <Mithrandir> cjwatson: http://people.ubuntu.com/~kyle/feisty/
[12:23] <Mithrandir> ben pulled in a couple of patches yesterday
[12:24] <cjwatson> crestline went in
[12:25] <cjwatson> as did 0002-2.6.21-fix-lba48-bug-in-libata-fill_result_tf.txt (but I dunno, doesn't seem feisty-ish now)
[12:25] <cjwatson> the rest didn't hit git AFAIK
[12:26] <cjwatson> though I suppose it's possible that 0002 is a prereq for the others
[12:28] <pkl_> doesn't look like it...
[12:32] <pkl_> cjwatson:  I got the impression something was going to be checked in by Kyle, but obviously nothing did.
[03:54] <elementz> hi guys
[03:55] <elementz> i was trying to patch my kernel with the 16k patch from linuxant - since i need it for my pcmcia wlan - seems to not work - i got a foo.patch file but can't apply it
[03:55] <elementz> should i just recompile?
[03:56] <mjg59> elementz: This channel is for development of the Ubuntu kernel, not support for third-party patches
[03:56] <mjg59> elementz: #ubuntu may be a better bet, or alternatively talk to Linuxant (since you've presumably bought their product)
[03:56] <elementz> jg59 kk - no the patch is free
[03:57] <elementz> jg69 do you give support on how to recompile my kernel with 16k stack though? or should i go to #ubuntu for this as well?
[03:57] <mjg59> Yes
[03:57] <mjg59> That is, you should ask in #ubuntu
[03:57] <elementz> kk thx
[03:58] <zul_> or check the wiki
[04:05] <\sh> BenC: I just exchanged the old dapper server cd installer kernel with the -proposed 2.6.15-50.61 dapper kernel to our install cd...rebuild debian installer with all necessary udebs from -proposed archive and now d-i complains about problems with usb-storage udeb...
[04:06] <\sh> BenC: now I don't know if it's me and a broken debian-installer kernel or if it's something with the 50.61 -proposed dapper kernel
[04:07] <\sh> BenC: oh damn...i found my mistake
[04:10] <elementz> i am really sorry to ask in here - but maybe you guys can give me a quick reply - is there an easy way to obtain a patch (maybe even in the repos) that patches the kernel to use a 16k stack? i use 2.6.20-14-generic
[04:14] <mjg59> No
[04:14] <elementz> thx
[04:31] <aurelianito> hi all
[04:31] <aurelianito> I'm using kubuntu since dapper
[04:32] <aurelianito> and I  having a problem with the edgy-eft kernel
[04:32] <aurelianito> I'm using the Huawei SmartAX MT882 ADSL USB modem
[04:32] <mjg59> aurelianito: Bug number?
[04:33] <aurelianito> and this device is recogniced by kernel 2.6.15 (dapper) but no 2.6.17 (edgy-eft)
[04:33] <aurelianito> I don't have a bug number
[04:33] <mjg59> Please file a bug
[04:33] <aurelianito> where?
[04:33] <mjg59> bugs.ubuntu.com
[04:34] <aurelianito> do I need a login?
[04:34] <mjg59> Yes
[04:34] <aurelianito> I don't have one
[04:34] <elementz> sorry guys - i really don't mean to be annoying! asked in other channels - to no avail though! maybe you guys can tell me how to apply this to my kernel? http://www.linuxant.com/driverloader/wlan/full/archive/linux-2.6.20-16kstacks.patch
[04:34] <zul> then you can make one
[04:35] <mjg59> elementz: No
[04:35] <elementz> kk
[04:36] <mjg59> elementz: Sorry, we really don't have time to support people attempting to add third-party patches to break their kernel
[04:36] <mjg59> Feisty is due to release next week
[04:38] <elementz> yes i understand - it's just that i am desperately i need of my wireless - even if it involves a dirty solution at the moment
[04:38] <elementz> but i understand where you're coming from
[04:39] <zul> elmentz: as we said before check the wiki
[04:45] <zul> BenC: can we kill bug #96430?
[04:52] <aurelianito> I'm trying to file a bug, but the site is soooo slow......
[04:52] <aurelianito> Do you know if it's having any problems?
[05:00] <fabbione> aurelianito: known issue (lp being slow)
[05:25] <Keybuk> why does the kernel continually spit ata errors under vmware ?
[05:25] <kylem> because vmware's emulation sucks?
[05:26] <Nafallo> Keybuk: if user = keybuk etc... ;-)
[05:30] <arkora> is there any file server that still holds the 2.6.20-*13* debs? In the apt repositories, these build do not exist any more.
[05:30] <Nafallo> arkora: launchpad :-)
[05:30] <Nafallo> arkora: but it slow as *beep* today
[05:31] <aurelianito> amazingly, I've been able to file my bug report
[05:31] <arkora> Nafallo: thanks, I should have known :o)
[05:32] <aurelianito> the number is 105883
[05:37] <nictuku_i386> hello.
[05:37] <_MMA_> BenC: I have someone that wants to help us (Ubuntu Studio) with a RT.
[05:37] <_MMA_> *RT kernel.
[05:38] <_MMA_> If you not too swamped is there a place to see what patches Ubuntu applies?
[05:38] <fabbione> _MMA_: we are busy trying to get feisty out next week.. 
[05:39] <Mithrandir> _MMA_: far too late to feisty; Look at git for the patches.
[05:39] <mjg59> _MMA_: All the patches are in the ubuntu tree on git.kernel.org
[05:39] <_MMA_> fabbione: I figured. Hence the "If you not too swamped"
[05:39] <_MMA_> mjg59: Thanx
[05:40] <_MMA_> Mithrandir: I know. We might use it in our repo and get it in if its necessary for +1.
[05:40] <rtg_> arkora: See the comment at the end of bug #96480.
[05:44] <arkora> rtg: great, thanks!
[05:58] <fabbione> kylem, BenC, rtg_, pkl_: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/105888
[05:59] <fabbione> ^^ cjwatson, Mithrandir FYI..
[05:59] <fabbione> coming from hwcert
[05:59] <kylem> can you summarize it?
[05:59] <kylem> privately
[05:59] <andre_pl> with the latest feisty kernel my tifm card reader doesn't work at all.  the modules load, but otherwise theres nothing in dmesg.. i had read on launchpad that the latest kernel had included a newer tifm driver that was supposed to solve most of these problems but in my case it is worse.
[05:59] <kylem> launchpad is uselessly slow.
[05:59] <fabbione> summarize?
[06:00] <kylem> fabbione, i can't load the page.
[06:00] <fabbione> i was able to open it..
[06:00] <fabbione> oh
[06:00] <fabbione> sure
[06:00] <andre_pl> kylem: same here, launchpad is totally useless right now
[06:00] <mjg59> Apr 11 20:51:40 ubuntu kernel: [    1.253614]  ACPI: Wrong _BBN value, reboot and use option 'pci=noacpi' is arguably more disturbing
[06:03] <mjg59> fabbione: Get them to boot with pci=noacpi and see if it works. If so, buggy BIOS.
[06:04] <fabbione> mjg59: older kernels didn't show the problem on that machine.. regression perhaps?
[06:04] <mjg59> Which older kernels/
[06:05] <fabbione> down to Herd 2
[06:05] <fabbione> all milestones.. etc.
[06:05] <mjg59> ?
[06:05] <fabbione> mjg59: that machine is tested on each milestone release
[06:05] <mjg59> So everything pre-RC worked?
[06:05] <fabbione> yes
[06:06] <mjg59> Herd 6 was fine?
[06:06] <Nafallo> Herd 6 was cancelled? :-)
[06:06] <mjg59> Uh, yeah.
[06:06] <mjg59> I meant 5
[06:07] <mjg59> Which kernel did we ship in Herd 5?
[06:08] <mjg59> I'm pretty sure that there have been no even vaguely relevant changes since then
[06:08] <Nafallo> beta is the latest milestone I think
[06:08] <mjg59> Ah, true
[06:08] <mjg59> Very easy to lose track
[06:09] <Nafallo> maybe -12 there? from the top of my head :-)
[06:09] <Nafallo> indeed it is :-)
[06:09] <mjg59> fabbione: Anyway, I don't believe that it's possible for this to have appeared between beta and now
[06:09] <fabbione> mjg59: well ok.. i will ask to check
[06:12] <pkl_> andre_pl: are you expecting the card to automount?
[06:13] <andre_pl> pkl_: I'm expecting to see something in dmesg telling me that it at least realizes tha ti've inserted or removed a card.
[06:14] <mjg59> andre_pl: Is tifm_sd loaded?
[06:14] <andre_pl> mjg59: yep
[06:14] <andre_pl> and tifm_core
[06:14] <pkl_> andre_pl: yeah it should do that...  A change in -13 with mmc-core broke automounting, but you should be able to manually mount it.
[06:14] <mjg59> And tifm_7xx1?
[06:14] <andre_pl> and tifm7xx1
[06:15] <andre_pl> is there another module i might be missing? 
[06:15] <pkl_> mmc_core mmc_block
[06:16] <mjg59> SD card or MMC?
[06:16] <pkl_> andre_pl: what kernel version did this work?
[06:17] <andre_pl> pkl in -13 i got alot of garbage whenever i inserted or removed a card.  but it hasn't worked Properly" since edgy
[06:18] <mjg59> andre_pl: Are you doing anything funny with setpci?
[06:18] <andre_pl> mjg59: nothing at all.
[06:18] <mjg59> Right. Well, it works fine here.
[06:18] <pkl_> The .8 tifm drivers should have fixed things for most people.  Unfortunately, there's still people for which it doesn't work.
[06:19] <andre_pl> pkl_ I dont think I get ANYTHING at all in dmesg, even if i remove all the modules and reload them.
[06:19] <mjg59> Not even PCI interrupt disabled/enabled messages?
[06:20] <andre_pl> let me try removing all the modules and see what comes up.
[06:20] <andre_pl> is there an order they should be inserted in?
[06:21] <mjg59> Load tifm_7xx1 and mmc-core
[06:21] <mjg59> Everything else will be loaded on demand
[06:22] <pkl_> andre_pl: have a look at bug 53923, that's got a number of tifm issues.
[06:24] <andre_pl> I get 2 lines 
[06:24] <andre_pl> [ 3835.864000]  ACPI: PCI interrupt for device 0000:08:06.2 disabled
[06:24] <andre_pl> [ 3943.088000]  ACPI: PCI Interrupt 0000:08:06.2[C]  -> GSI 22 (level, low) -> IRQ 22
[06:26] <mjg59> Ok.
[06:27] <mjg59> And if you insert an sd card, what happens?
[06:27] <andre_pl> zilch
[06:27] <mjg59> Nothing at all?
[06:27] <mjg59> Is tifm_sd now loaded?
[06:27] <andre_pl> no, just core and 7xx1
[06:27] <mjg59> Right
[06:28] <andre_pl> load it?
[06:28] <mjg59> No
[06:28] <mjg59> And this is an SD card?
[06:28] <mjg59> Not an MMC?
[06:28] <andre_pl> Says SD on it :)
[06:28] <mjg59> Ok
[06:28] <mjg59> I'm sorry, I've no idea what the problem is
[06:29] <pkl_> nor do I, which is why I've done nothing about it :)
[06:29] <andre_pl> this is a huge problem. lol
[06:29] <mjg59> andre_pl: For you, yes
[06:32] <mjg59> As I said, it's working on the tifm machines I have here
[06:32] <mjg59> So figuring out the problem is awkward...
[06:32] <pkl_> I can't reproduce it (not having the hardware), and AFAIK 0.8 is the latest version.
[06:34] <andre_pl> neither mmc_block nor tifm_sd loaded automatically. are they supposed to?
[06:34] <mjg59> They'd only be loaded automatically if the card insertion was detected
[06:35] <andre_pl> should I see anything in dmesg just by loading the modules with no card inserted?
[06:37] <mjg59> No
[06:38] <andre_pl> so what are these 2 PCI Interrupt lines telling me?
[06:38] <andre_pl> besides bad news?
[06:39] <mjg59> That the device was detected and activated
[06:39] <andre_pl> really?
[06:39] <andre_pl> thats messed up
[06:40] <andre_pl> maybe the card is messed up?
[06:40] <mjg59> Maybe
[06:48] <capiira> hi,hi, I compiled my kernel with debian/rules and everything worked fine but how can i define the name/version of the kernel? Now its called "linux-image-2.6.20-14-1a1-generic_2.6.20-14.22_i386.deb" i would like to have it named like the original one "linux-image-2.6.20-14-generic" with that "2.6.29-14.22" under latest version.
[06:49] <capiira> that was my compilation command AUTOBUILD=1 fakeroot debian/rules binary-debs flavours=generic
[07:10] <rtg_> mjg59: I'm getting some serious heat for bug #96480. What are the side effects of reverting db2f0f088a056c4ccf9054747169802db2f9ae9a 'Declare more i2c_adapter parent devices'? I'm sure this is what broke ACER and Mac Pro. They all say 2.6.12-20 works, 2.6.20-13 doesn't.
[07:11] <mjg59> I've no clue - wasn't my patch
[07:12] <rtg_> mjg59: I thought you might know 'cause it is related to ACPI. 
[07:12] <BenC> rtg_: IIRC, that was pulled in to fix something else
[07:12] <BenC> one of the i2c drivers was crashing before that was pulled in
[07:12] <rtg_> BenC: That is why I'm asking about side effects.
[07:12] <BenC> and that fixed it
[07:12] <mjg59> Looks like an i2c issue, not an acpi one
[07:13] <rtg_> mjg59: No, I believe its the way ACPI starts up its bus driver for I2C.
[07:14] <rtg_> So it looks like catch-22.
[07:18] <mjg59> It's an i2c driver
[07:18] <mjg59> The only ACPI-related aspect is that it gets a couple of bits of information from an ACPI table
[07:18] <BenC> cjwatson: edgy's ata_piix driver was only handling 3 pata chipsets, for reference
[07:19] <mjg59> BenC: I've made no effort to determine whether any of the acpi/pata code for drivers/ide still works this cycle
[07:20] <mjg59> Since all my test hardware transitioned over to ata_piix
[07:20] <BenC> mjg59: Willing to run through some tests when I get this kernel compiled?
[07:22] <mjg59> The HPA stuff has nothing to do with the chipset
[07:22] <mjg59> If any pata chipsets are driven by libata, we need the HPA patch
[07:22] <cjwatson> sure, but which manufacturers actually used HPA?
[07:22] <mjg59> Impossible to determine
[07:22] <mjg59> We've seen it on some desktop machines
[07:22] <cjwatson> the HPA patch has, as far as I can tell, had no testing on any other distribution
[07:23] <mjg59> Correct
[07:23] <cjwatson> it is SEVEN DAYS BEFORE RELEASE
[07:23] <mjg59> As I've said repeatedly, we either ship it or we revert all of pata back to drivers/ide
[07:23] <BenC> we had pata in edgy, without this HPA patch
[07:23] <cjwatson> or release-note that some people are going to have to use edgy
[07:23] <cjwatson> the alternative is to delay the release by upwards of a week
[07:23] <BenC> s/pata/libata-pata/
[07:24] <mjg59> BenC: On a tiny, tiny number of chipsets
[07:24] <BenC> it was a good chunk of chipsets, just not the popular ones, like ata_piix
[07:24] <cjwatson> this has a really nasty knock-on effect on all sorts of things
[07:24] <mjg59> cjwatson: It's very, very non-trivial for a user to determine whether they'd be bitten by this before upgrade
[07:25] <BenC> wouldn't their dmesg show "Host Protected Area ..." ?
[07:25] <mjg59> Yes, but asking most of our users to check dmesg before performing an upgrade is a non-starter
[07:25] <cjwatson> update-manager could be made to do it ...
[07:25] <BenC>         printk(KERN_INFO "%s: Host Protected Area detected.\n"
[07:25] <Mithrandir> cjwatson: ew.
[07:25] <cjwatson> (ew, yes, but)
[07:25] <Mithrandir> cjwatson: yes, it can, but, ew.
[07:26] <cjwatson> reverting all of pata is a non-starter
[07:26] <Mithrandir> how much testing do we need to establish that the HPA patch doesn't break stuff?
[07:26] <mjg59> It doesn't break anything here.
[07:26] <mjg59> Beyond that, I obviously can't say
[07:26] <BenC> Mithrandir: actually, I've had 4 people report that it fixes things
[07:26] <fabbione> we can't guarantee that dmesg has enough buffer to have that printk in queue either
[07:26] <BenC> and it hasn't broken anything on my system
[07:27] <BenC> systems
[07:27] <cjwatson> BenC: (we need to get the kernel with those drivers reverted up first regardless of this discussion; time is slipping away)
[07:27] <BenC> cjwatson: it's in progress
[07:27] <cjwatson> yup, just being clear
[07:27] <mjg59> cjwatson: Reverting anything back to drivers/ide also needs further testing
[07:27] <BenC> mjg59: we have to revert some piix ones anyway
[07:27] <cjwatson> mjg59: indeed so
[07:27] <mjg59> It means more people hitting codepaths that haven't seen significant use since edgy
[07:27] <BenC> because they are broken with ata_piix
[07:28] <cjwatson> right now, we need concrete evidence of HPAs existing on hardware other than the ones we're talking about reverting to drivers/ide
[07:29] <mjg59> cjwatson: The issue is the drive, not the chipset
[07:29] <cjwatson> HPAs are only set up by system manufacturers, right?
[07:29] <mjg59> Yes, but people may then swap motherboards
[07:30] <mjg59> And we have no clue which vendors may have used HPAs at different stages
[07:30] <mjg59> Yes, this is all a bit handwavy, but it's not possible for us to say "Nobody will be affected by this decision"
[07:30] <mdz> I've heard conflicting reports about the failure mode here
[07:30] <mdz> what goes wrong?
[07:31] <mjg59> mdz: Part of the hard drive becomes inaccessible. This may contain filesystem.
[07:31] <mdz> that seems backwards to me; I thought the failure was that extra bits of disk were accessible which shouldn't be
[07:31] <mjg59> No
[07:32] <mjg59> HPAs are enforced by the drive
[07:32] <BenC> Linux chooses to ignore HPA by default in the ide-disk driver
[07:32] <mjg59> Old situation: Drive has HPA. Linux ignores this. User deletes rescue partition, installs into HPA. Everything works.
[07:32] <mjg59> New situation: Drive has HPA. Linux doesn't ignore this. User can no longer access data that is in HPA.
[07:32] <mjg59> User sad.
[07:33] <mdz> so this is a problem for users who installed a Feisty snapshot over an HPA
[07:33] <BenC> or, User upgrades, system that is installed in HPA, and now can't read the partition
[07:33] <cjwatson> or <= Edgy
[07:33] <Mithrandir> or any previous version
[07:33] <cjwatson> since drivers/ide ignores the HPA (which means that the entire disk, including the HPA, is accessible)
[07:33] <cjwatson> the terminology is very confusing
[07:33] <mdz> which versions of Ubuntu does "Linux chooses to ignore HPA By default in the ide-disk driver" refer to?
[07:34] <mjg59> mdz: All of them
[07:34] <mjg59> Except feisty
[07:34] <BenC> no, ide-disk driver still ignores it
[07:34] <BenC> it always has
[07:34] <mjg59> Well, but we now drive much less with ide-disk
[07:34] <mdz> if HPA is enforced by the drive, how can we install into them?
[07:34] <Mithrandir> the problem is for drivers which used to be ide-disk and are now libata.
[07:34] <mjg59> mdz: You can't
[07:34] <BenC> it's sd_mod that doesn't, and libata never took it into account
[07:34] <mjg59> It's an upgrade issue
[07:35] <mdz> how can we *ever* have installed into an HPA?
[07:35] <mjg59> Because all versions before feisty allowed you to do so
[07:35] <mdz> you said the disk disallowed it
[07:35] <mjg59> The disk disallowed it. The kernel then asked the disk to allow it.
[07:35] <cjwatson> mdz: no, the disk says what the max size is, but it's the OS' choice whether to honour that
[07:35] <mdz> which is inconsistent with the rest of the description I've heard
[07:35] <cjwatson> http://en.wikipedia.org/wiki/Host_Protected_Area
[07:35] <maswan> mjg59: did you mean "driver" in "HPAs are enforced by the drive"?
[07:35] <mjg59> maswan: No
[07:35] <maswan> Ok, so I don't understand it either then.
[07:36] <mjg59> There is a region of the drive.
[07:36] <mdz> I do now
[07:36] <mjg59> If you attempt to access it, the drive says "no"
[07:36] <BenC> HPA is suggested by the drive, the driver can override it to get the native size
[07:36] <mjg59> ide-disk pokes the drive to remove that restriction
[07:36] <mjg59> libata doesn't
[07:36] <maswan> Ah, ok.
[07:36] <mdz> but if I do understand correctly, the safest thing is to stick with the same behaviour we have always had
[07:36] <cjwatson> yes
[07:36] <mjg59> mdz: Correct. Which requires either reverting to drivers/ide or adding the patch.
[07:36] <kylem> so the same behaviour is to revert *ALL* ide drivers back to drivers/ide code.
[07:36] <mdz> which means my understanding of the patch was reversed
[07:37] <cjwatson> reverting *all* drivers seems insanely risky at this point
[07:37] <mdz> I thought it was "adding HPA support", not "explicitly ignore HPA"
[07:37] <cjwatson> a few PCI IDs I can handle, but ...
[07:37] <cjwatson> (particularly if they have other problems)
[07:37] <BenC> mdz: It's adding the ability to recognize and ignore the HPA :)
[07:37] <mjg59> mdz: Adding HPA support means teaching the driver what an HPA is
[07:37] <kylem> it's an ATA command, not poking a IDE controller.
[07:37] <kylem> so it doesn't matter which chipset you have, it's drive dependent...
[07:38] <mjg59> Right. I can take an HPAed drive and put it in another system with a different IDE chipset
[07:38] <BenC> I didn't understand that either...I thought it was something done by the controller at the BIOS's request
[07:38] <mjg59> BenC: No, the drive firmware will have been modified to set it up
[07:38] <BenC> I guess the code being in libata-core confused that for me
[07:39] <BenC> in IDE, it is in ide-disk specifically
[07:39] <cjwatson> does anyone sell bare HPAed drives?
[07:39] <mjg59> cjwatson: No, but you can set one up
[07:39] <cjwatson> I mean not as part of some other system
[07:39] <BenC> cjwatson: it's all provisioning for hw vendors
[07:39] <cjwatson> I'm not interested in theoretical cases at this point
[07:39] <mjg59> Oh,a ctually, yes
[07:39] <mdz> mjg59: do I understand correctly that unless the OS takes specific action related to HPA, it's transparent and the drive simply appears to be smaller?
[07:39] <mjg59> Various drives are limited to 32GB with a large HPA
[07:39] <BenC> mdz: right
[07:39] <mjg59> This is to avoid BIOS bugs
[07:39] <mdz> and so the intent of the patch is to recognize the existence of an HPA and instruct the drive to ignore it?
[07:40] <mjg59> mdz: Correct
[07:40] <mjg59> cjwatson: Many drives have a "Limit to 32GB" jumper that actually sets an HPA
[07:40] <BenC> yeah, one person in the bug report seems to have that case
[07:40] <mjg59> Award shipped BIOSes that crashed if they saw a >32GB drive
[07:40] <cjwatson> ok, first I've heard of that
[07:40] <Mithrandir> ah, I always wondered how that worked.. and why Linux saw the full size of the disk.
[07:40] <BenC> 32G -> 160G was the HPA message
[07:40] <mjg59> Hits machines up to ~2000
[07:41] <mjg59> Ok. And we've got a real case of that in the wild.
[07:41] <cjwatson> sigh, my prior understanding was that it was basically laptops
[07:41] <cjwatson> since everybody who talked about this bug seemed to do so in the same sentence as "Thinkpad"
[07:41] <mjg59> Thinkpads are the most common case where developers are going to hit it
[07:42] <Mithrandir> is that because it's more common on thinkpads or because 90% of our developers have their machines?
[07:42] <mdz> and we've switched the driver that most thinkpads use to one which doesn't know about HPA?
[07:42] <mjg59> mdz: Yes
[07:42] <mdz> why?
[07:42] <mjg59> Because we moved pata over to libata
[07:42] <mdz> why?
[07:42] <BenC> we followed upstream
[07:42] <mdz> so this is a horrendous regression in 2.6.20?
[07:42] <BenC> mdz: Moving to libata has been a spec since back in dapper
[07:43] <cjwatson> at that time, nobody knew about this HPA thing
[07:43] <mjg59> mdz: If using libata rather than drivers/ide, yes
[07:43] <mdz> or does 'upstream' mean a git repository that hasn't been pushed to linus yet?
[07:43] <cjwatson> at least nobody who actually said anything
[07:43] <BenC> it was generally considered a rolling spec, moving to drivers as they become stable
[07:43] <mjg59> cjwatson: I've been mentioning it repeatedly throughout the entire release cycle
[07:43] <cjwatson> the first I heard of it was beta, and I was most certainly not aware of its extent
[07:44] <BenC> mdz: It means every kernel release, the libata pata drivers mature and change to "stable", and so I've moved support for those chipsets from ide to libata
[07:44] <cjwatson> but that's not particularly relevant, what I mean is that nobody said anything when the plans were being discussed
[07:44] <BenC> in the kernel, you can choose either drive
[07:44] <mdz> BenC: which drivers are we talking about in this case, which are relevant to the cases of HPA badness we've seen?
[07:45] <BenC> mdz: It's not driver specific, it just means we are exposing more and more users to libata over time, and eventually hitting ones that have HPA drives
[07:45] <BenC> it was just a matter of time before this turned into what we have now
[07:45] <mdz> BenC: I understand, but we've been doing that for a while, and only recently has it become a big problem
[07:46] <BenC> mdz: With the early march move of about 3 major drivers, I think that was the tipping point
[07:46] <mdz> BenC: which drivers were those?
[07:46] <BenC> pata_sis, quite a few more for ata_piix, one other legacy type driver that I'd have to check changelog for
[07:47] <mjg59> mdz: It's likely that it's merely hit small numbers of users with previous drivers
[07:47] <BenC> but I know that there were three drivers changed to "stable" by jgarzik
[07:47] <mdz> PATA_SIS is marked experimental
[07:47] <mjg59> In pure 2.6.20, I believe it's stable in the libata tree
[07:47] <BenC> yeah, and I just looked, and it's because SATA_SIS depends on it
[07:48] <BenC> pata_sis exports two tables, for sata/pata combined controllers
[07:48] <BenC> s/two tables/pci tables/
[07:48] <nictuku_i386> may i ask for help finding the list of patches applyed to the ubuntu kernel in the git site?
[07:48] <BenC> we can't support sata_sis without pata_sis driver
[07:48] <mdz> 2.6.20 was released in early Feb, and we made this change in March, so it doesn't sound like it came from Linus' tree
[07:48] <zul> nictuku_i386: not now
[07:49] <BenC> mdz: I talked to jeff Garzik about his stable tree, and he agreed that it was safe to pull into our tree
[07:49] <nictuku_i386> ok thnx
[07:49] <BenC> his stable tree is for the 2.6.22 window, not experimental stuff, well tested patches
[07:49] <cjwatson> what other distributions are using his stable tree?
[07:49] <BenC> it was needed to get DMA support for ata_piix driver, and get a few new chipsets supported that we didn't have drivers for at all
[07:50] <mjg59> cjwatson: Fedora
[07:50] <mjg59> But Jeff works for RH
[07:50] <cjwatson> FC6?
[07:50] <mjg59> No
[07:50] <mjg59> FC7 will ship with it
[07:50] <mdz> we need to talk about when and why we pull from various trees, but now is not the time
[07:51] <mdz> so to come back to the immediate problem
[07:51] <BenC> well, it was either that, or we release feisty that is not installable on some major hw that we sort of have to support
[07:51] <mdz> I hear from mjg59 that this is a showstopper and needs to be fixed
[07:51] <mjg59> mdz: I've been saying that for the past three months
[07:51] <mdz> BenC: do you argee or disagree?
[07:51] <mdz> or, perhaps, agree
[07:51] <BenC> mdz: yeah, it would seem so
[07:52] <mdz> then we have consensus
[07:52] <mdz> let's get the fix in
[07:52] <mdz> mjg59: I'm not arguing that point.  this is all news to me.
[07:53] <mdz> I am in the moment
[07:53] <BenC> ok, so I'll revert the 4 oldest PIIX chipsets back to piix.ko (from ata_piix.ko) to fix 82314, and add the HPA patch in
[07:54] <cjwatson> and skip the SIS change?
[07:54] <BenC> kernel will be uploaded soon, and I'll have images available for people to test prior to buildd
[07:54] <BenC> cjwatson: right, I can't revert pata_sis anyway because of sata_sis needing it
[07:55] <mjg59> Ok.
[07:55] <mjg59> One of the other effects of this is that we need to be very careful about what update-manager does with the cd-rom entry in fstab
[07:56] <BenC> you mean the /dev/hdc-/dev/scd0 reference?
[07:56] <BenC> I think we already know about that one
[08:02] <mjg59> BenC: Right, but lots of machines will be sticking with /dev/hdc
[08:03] <BenC> I think the idea was to switch to /dev/cdrom, since udev updates that link
[08:04] <mjg59> There's potential for that still to lose, but yeah, that's probably sane
[08:08] <mdz> it's the best we can do; it's at least more future-proof
[08:09] <cjwatson> BenC: that's what u-m does now
[08:09] <cjwatson>         " convert /dev/{hd?,scd0} to /dev/cdrom for the feisty upgrade "
[08:09] <mjg59> Ok, that shouldn't be a problem
[08:09] <mjg59> I can't think of any other issues
[08:09] <cjwatson> and it does so only if /dev/cdrom currently points to whatever the device in fstab is
[08:09] <cjwatson> (seeing as it's doing the rewrite on the old kernel)
[08:14] <BenC> I guess now is a good time to do a .orig.tar.gz
[08:20] <BenC> cjwatson, mdz: package is uploading
[08:21] <mdz> BenC: thank you
[08:39] <Mithrandir> mdz: do you want to review and approve the kernel upload or should I?
[08:40] <BenC> I can provide a diff from the current kernel if need be
[08:41] <mdz> Mithrandir: I'm happy to help with review; Colin is likely interested as well
[08:41] <mdz> Mithrandir: and perhaps mjg59
[08:41] <Mithrandir> I'll put it on rookery.
[08:42] <Mithrandir> BenC: I'm generating it on drescher, but thanks.
[08:42] <mdz> better to generate the exact diff from the upload
[08:42] <Mithrandir> yes, I'm doing that.
[08:43] <cjwatson> Mithrandir: could you make your queue publish stuff do mdebdiff? might need to cache it
[08:43] <Mithrandir> cjwatson: it runs every hour, so I don't really see the point in caching, but yes, I could do that.
[08:43] <cjwatson> just say openoffice.org
[08:44] <cjwatson> new upstream
[08:44] <cjwatson> (for example :-))
[08:44] <Mithrandir> I wonder how you guys survived without mdebdiff.
[08:44] <Mithrandir> well, point.
[08:45] <Mithrandir> still not a magnitude bigger than the kernel which takes a minute or two.
[08:45] <mjg59> BenC: Did you get a chance to check those scancodes?
[08:45] <cjwatson> lots of .gitignore stuff
[08:45] <BenC> mjg59: Yeah, but have not uploaded it yet
[08:46] <cjwatson> is the removal of debian/abi/2.6.20-13.21/ significant?
[08:46] <BenC> no, the ABI for 2.6.20-14.22 was added
[08:46] <cjwatson> oh, -14.22 got added, ok
[08:46] <BenC> -13.21 isn't needed
[08:46] <Mithrandir> http://people.ubuntu.com/~ubuntu-archive/queue/linux-source.debdiff is the diff
[08:47] <mjg59> BenC: Ah - if that was going in, there's a couple of others that could do with it as well
[08:48] <BenC> 10.4Meg...hugeness
[08:49] <BenC> I foobar'd the .orig.tar.gz...left all the .gitignore files in
[08:49] <BenC> not a big deal, just oversized .diff.gz's
[08:50] <mjg59> Looks good to me
[08:50] <mjg59> I'll test it once binaries exist
[08:50] <BenC> build now
[08:51] <mjg59> BenC: This is meant to purely be the ATA stuff, rather than the other one-liners, right?
[08:52] <BenC> mjg59: pay close attention to the logic in ata_same_device, since that's what I changed from the patch that kyle had
[08:52] <fabbione> BenC: you also left some other random stuff like scripts/kconfig/zconf.tab.c in the orig but cleaned for diff.gz
[08:52] <BenC> mjg59: this is HPA, and moving a few older PIIX chipsets back to piix.ko
[08:52] <BenC> fabbione: Yeah, my tree must be pretty crufty
[08:52] <BenC> shame git-status doesn't show that stuff
[08:52] <BenC> harmless though
[08:53] <mjg59> BenC: So this isn't the final kernel upload?
[08:53] <fabbione> BenC: i just spoke with Sunil from Oracle. he says that's ok to skip these 4 patches, but to pull again for the first update. there are more fixes in their queue for .20_fixes that are passing QA now
[08:53] <BenC> git-ls-files --others
[08:53] <BenC> that's what I needed
[08:53] <fabbione> BenC: the most important ones are the ones i applied manually anyway
[08:53] <BenC> mjg59: This is just to get us past release
[08:54] <mdz> mjg59: this is meant to be the showstopper fixes
[08:54] <BenC> mjg59: the HPA patch in here was tested and confirmed by 4 different people on that bug report (82314)
[08:54] <mjg59> I thought we were targetting the MMC fix for release
[08:54] <mdz> minor stuff can go in a stable update with less hurry
[08:54] <mjg59> (At least, I thought that was what got agreed on yesterday)
[08:54] <BenC> I'm more worried about the install stoppers
[08:55] <BenC> we'll have an updates kernel withing days of release
[08:55] <mjg59> Ok. Which one's going to end up on the shipit CDs?
[08:55] <mdz> I'm not opposed to the MMC fixes as such, but given the weight of the other stuff, I'd prefer to keep this as simple as possible and roll an early SRU
[08:55] <mdz> mjg59: the CDs will get this kernel Ben has just prepared, barring further showstoppers
[08:55] <mdz> anything else will be a network update
[08:55] <mjg59> I think losing MMC on the Live CDs would be an error
[08:56] <mjg59> Given the trivialness of the fix
[08:56] <mdz> BenC: this diff is unreadable
[08:56] <Mithrandir> mdz: filterdiff -x '*/.gitignore' 
[08:56] <BenC> mdz: egrep -v '(gitignore|debian/abi)'
[08:57] <mdz> lots of big removals too
[08:57] <BenC> my .orig.tar.gz had some build cruft too, but it's harmless stuff that will get deleted on build
[08:57] <BenC> mdz: debian/abi/ changes can be ignored
[08:58] <BenC> standard update from last build
[08:58] <Mithrandir> /tmp/Y9bNBOLdlm/linux-source-2.6.20-2.6.20/drivers/cpufreq/.tmp_versions/cpufreq_conservative.mod and friends, you mean?
[08:58] <BenC> yeah, those things are cruft that git-status didn't show
[08:58] <mdz> I can't do more than eyeball the HPA stuff; it's too big and requires context
[08:58] <cjwatson> I also thought we had agreed the MMC fix earlier
[08:58] <mdz> BenC: looks like that stray .swp is still there in the new version
[08:59] <BenC> yeah, I just removed all the cruft in my tree
[08:59] <mjg59> BenC: I'd be happier if we went with the MMC fix as well
[08:59] <BenC> do you guys want to hold that last upload and include the mmc fix?
[09:00] <mdz> I found no fault with the diff other than the clutter, though there's a lot of new code there I can't possibly assess
[09:00] <BenC> take me 15-30 minutes
[09:00] <Mithrandir> if the mmc fix is as trivial as you say and has been tested, I'm fine with it.
[09:00] <mjg59> It's trivial and it's been tested
[09:00] <BenC> I can ditch the cruft at the same time
[09:01] <mdz> mjg59: you do realize that you're asking other people to work even later for the sake of that change
[09:01] <Mithrandir> why are there five added items to the piix_pci_tbl_aliases, but only three ifdef-ed out of ata_piix.c in the pci table there?
[09:01] <mjg59> mdz: I realise that yesterday we decided to include it and have been telling users that since then
[09:01] <zdzichuBG> anyone remeber edgy kernel patches to enable more thinkpads in hdaps driver? I couldn't find any
[09:02] <Mithrandir> zdzichuBG: now is a bad time; please try later.
[09:02] <mdz> mjg59: I don't recall a grand announcement about it; it's a minor bug
[09:02] <zdzichuBG> Mithrandir: ok.
[09:02] <mjg59> mdz: It's an entire class of hardware that doesn't work
[09:02] <mdz> mjg59: it's an entire class of hardware that few people use, and it doesn't affect their ability to install or upgrade at all
[09:03] <mjg59> mdz: If you'd made that argument yesterday when the decision was made, sure
[09:03] <Mithrandir> mdz: if we hold up release for this kernel build anyway, it won't make a difference; building the kernel takes enough time that .eu won't be awake when it's done.
[09:03] <Mithrandir> as in, hold up the RC for it.
[09:04] <mdz> mjg59: and if it were in the upload Ben prepared, I wouldn't have objected to it, but here we are
[09:06] <mdz> BenC: up to you
[09:06] <cjwatson> I would like to ditch the cruft, mind you
[09:06] <mjg59> When it's a single line fix that has a significant effect on the hardware experence on the live CDs that are going to be mailed out by their thousands, I think it's relevant
[09:06] <fabbione> cjwatson: ++
[09:07] <BenC> Ok, already working on it, so give me 10 minutes
[09:07] <mdz> mjg59: I agree
[09:07] <mdz> mjg59: which is why I OK'd it earlier today
[09:07] <BenC> Mithrandir: can you just ditch that upload, or do I need to bump the version?
[09:07] <Mithrandir> BenC: I can reject it.
[09:07] <BenC> thanks
[09:08] <mdz> mjg59: what I'm asking from you is sensitivity to the fact that we're already under pressure here, and we still have a long way to go
[09:08] <Mithrandir> unless mdz tells me not to.  I think we should ditch it and get the mmc fix + the cleanups in.  If nothing else because it'll make me scream less when reading debdiffs for -proposed.
[09:09] <mdz> I am not
[09:09] <mdz> but this is it
[09:09] <mdz> we have already blown the release candidate
[09:10] <Mithrandir> Rejecting ubuntu/None (UNAPPROVED) 1/15
[09:10] <Mithrandir> ---------------------------------------------------------------------------
[09:10] <mdz> it's time for a measure of restraint
[09:10] <Mithrandir> Rejecting linux-source-2.6.20
[09:12] <Mithrandir> mdz: should we release the current set of images as herd-6 and skip RC, do RC on Monday or RC later (and then absolutely delay the release)?
[09:12] <fabbione> BenC: do you also have lrm / meta / backports ready?
[09:13] <BenC> fabbione: This is non-ABI changing
[09:13] <fabbione> ah cool
[09:13] <fabbione> so we just need a new d-i to pull in the kernel
[09:13] <fabbione> and new images
[09:13] <fabbione> much faster :)
[09:15] <mdz> Mithrandir: let's get this round of fixes in (kernel and n-m), then see where we stand tomorrow and decide then
[09:15] <cjwatson> I'll upload d-i nowish and Mithrandir can accept it when it's time
[09:15] <mdz> I'm leaning toward giving RC a miss and driving on to final
[09:16] <cjwatson> if that's ok with everyone?
[09:16] <mdz> but if we make good time, we could potentially do a late RC
[09:16] <Mithrandir> mdz: should I start spinning images tomorrow morning?  Experience shows I'm around a bit earlier than you both because of the TZ and because I can just roll out of bed and crawl to the room next door.
[09:16] <mdz> cjwatson: no objection here
[09:16] <Mithrandir> cjwatson: yes, thanks.
[09:16] <cjwatson> there was a sparc module addition in my tree for fabbione
[09:17] <fabbione> cjwatson: that's a blocker that needs fixing or people won't get keyboard working in d-i
[09:17] <fabbione> hem
[09:17] <mdz> Mithrandir: we want images ASAP, doesn't matter to me who does it so long as nobody steps on any toes
[09:17] <fabbione> you know that
[09:17] <fabbione> it was for mdz and Mithrandir 
[09:17] <cjwatson> it's in my upload; mdz/Mithrandir's call
[09:17] <Mithrandir> mdz: ok, I'm doing it first thing tomorrow then.
[09:17] <Mithrandir> cjwatson: diff?
[09:17] <cjwatson> diff -Nru /tmp/2PkqchyCYa/debian-installer-20061102ubuntu23/build/pkg-lists/cdrom/sparc.cfg /tmp/KiE8vNu761/debian-installer-20061102ubuntu24/build/pkg-lists/cdrom/sparc.cfg
[09:17] <mdz> cjwatson: if it's demonstrably a noop on !sparc, I am happy
[09:17] <cjwatson> --- /tmp/2PkqchyCYa/debian-installer-20061102ubuntu23/build/pkg-lists/cdrom/sparc.cfg   2007-03-22 09:19:40.000000000 +0000
[09:17] <cjwatson> +++ /tmp/KiE8vNu761/debian-installer-20061102ubuntu24/build/pkg-lists/cdrom/sparc.cfg   2007-04-11 13:39:42.000000000 +0100
[09:18] <cjwatson> @@ -9,6 +9,7 @@ ide-modules-${kernel:Version} ? pata-modules-${kernel:Version} ? usb-modules-${kernel:Version} ?
[09:18] <cjwatson> +input-modules-${kernel:Version} ? usb-discover
[09:18] <cjwatson> scsi-modules-${kernel:Version}
[09:18] <cjwatson> geez, IRC totally mangled that
[09:18] <cjwatson> --- /tmp/2PkqchyCYa/debian-installer-20061102ubuntu23/build/pkg-lists/cdrom/sparc.cfg   2007-03-22 09:19:40.000000000 +0000
[09:18] <cjwatson> +++ /tmp/KiE8vNu761/debian-installer-20061102ubuntu24/build/pkg-lists/cdrom/sparc.cfg   2007-04-11 13:39:42.000000000 +0100
[09:18] <cjwatson> @@ -9,6 +9,7 @@
[09:18] <cjwatson>  pata-modules-${kernel:Version} ?
[09:18] <cjwatson>  usb-modules-${kernel:Version} ?
[09:18] <cjwatson> +input-modules-${kernel:Version} ?
[09:18] <fabbione> mdz: no op on !sparc
[09:18] <cjwatson>  ide-modules-${kernel:Version} ?
[09:18] <cjwatson> and more random context
[09:18] <cjwatson> uploaded
[09:18] <Mithrandir> cjwatson: looks good to me.
[09:19] <BenC> upload in progress, I'll let you know when it's done
[09:19] <cjwatson> Mithrandir: I'm going to the pub shortly for some much-needed social interaction, but I'll be back later; I'm on my own in the house so couldn't really care less if I'm up late
[09:19] <mdz> Mithrandir: have you been in contact with Keybuk regarding the n-m fix?  it was looking good the last time I checked in with him
[09:19] <cjwatson> so I can drive image building and such if it happens before I fall asleep
[09:20] <Mithrandir> cjwatson: ok.  I'll try to make the kernel end up on palmer at least, but we're still talking 6-ish hours for the kernel, iirc.
[09:21] <BenC> be aware that the debdiff is still going to look crufty, because -13.21 had the cruft, this one doesn't
[09:22] <Mithrandir> BenC: ok.
[09:22] <BenC> the only change in this one is the one-liner mmx fix
[09:22] <BenC> mmc
[09:22] <Mithrandir> mdz: no, I'll speak with him now
[09:24] <mdz> Mithrandir: that needs to go in the final build, he's been organizing some testing but I'm unsure where it stands so far
[09:24] <Mithrandir> mdz: yes, I just prodded him on IRC and am sending him an email too.
[09:27] <BenC> Mithrandir: Done
[09:47] <Mithrandir> ok, linux-source accepted
[09:49] <salty-horse> hi. noticing the topic, where's the best to look get support for the new nvidia-glx package?
[09:54] <BenC> salty-horse: Upgrade your system to latest feisty
[09:54] <BenC> salty-horse: what sort of support do you need?
[09:55] <salty-horse> BenC, I *am* using feisty. Until the "new legacy" nvidia-glx package was created, I manually installed NVIDIA-Linux-x86_64-1.0-9631. then I --uninstalled it (and made sure no files remained) and installed nvidia-glx. When I run the nvidia driver I get the "Error: API mismatch: the NVIDIA kernel module has the version 1.0-7184, but this X module has the version 1.0-9631" error (as seen on https://bugs.launchpad.net/ubuntu/+sourc
[09:55] <salty-horse> e/linux-restricted-modules-2.6.20/+bug/96430 )
[09:57] <BenC> salty-horse: sounds like you have some local skew
[09:58] <BenC> salty-horse: Make sure you remove the nvidia-glx-legacy package, and install nvidia-glx, then restart your system
[09:58] <BenC> try "sudo apt-get --reinstall install linux-restricted-modules-2.6.20-14-generic nvidia-glx nvidia-glx-legacy-"
[09:58] <BenC> note the "-" on the end of nvidia-glx-legacy
[09:59] <salty-horse> according to dpkg -l "*nvidia*" only nvidia-glx is installed. I did notice that linux-restricted-modules contain all 3 nvidia kernel modules - that's intentional, right?
[10:00] <BenC> yes, but it should choose the right one to load
[10:01] <BenC> it's possible you have a left over file...hold a sec
[10:01] <BenC> sudo rm -f /lib/linux-restricted-modules/.nvidia_*
[10:01] <BenC> try that, and reboot
[10:01] <salty-horse> $ modprobe -l | fgrep nvidia
[10:01] <salty-horse> /lib/modules/2.6.20-14-generic/volatile/nvidia.ko
[10:01] <salty-horse> /lib/modules/2.6.20-14-generic/volatile/nvidia_legacy.ko
[10:01] <salty-horse> /lib/modules/2.6.20-14-generic/volatile/nvidia_new.ko
[10:01] <salty-horse> /lib/modules/2.6.20-14-generic/kernel/drivers/video/nvidia/nvidiafb.ko
[10:02] <BenC> there's nothing wrong there, it's lrm-video that is loading the wrong driver, most likely because that file /lib/linux-restricted-modules/.nvidia_legacy_installed, is still there
[10:02] <salty-horse> i have only .nvidia_new_installed - deleted it and restarting
[10:03] <salty-horse> btw, what does the restricted manager GUI do when I click on the checkbox to enable the driver? does it just update xorg.conf?
[10:04] <BenC> Yes, basically, and lrm-video will only load modules based on xorg.conf having it enabled
[10:04] <BenC> how do you have .nvidia_new_installed in there?
[10:04] <BenC> It would only be there if you install nvidia-glx-new
[10:04] <salty-horse> yes. and I deleted it just now.
[10:05] <BenC> just wondering how it got there
[10:06] <salty-horse> i have before.. when I nvidia-glx didn't work - glx-new hasn't as well and I tried to remove it. I think I got some conflicts then.. there was a conflict with dpkg-divert as well.. could it be that these packages' uninstallation methods are missing something? or is it more likely that i borked things manually?
[10:06] <salty-horse> ok, I'm restarting - is it enough to restart gdm?
[10:09] <BenC> kernel modules needs to be reloaded
[10:10] <mjg59> BenC: Did you have any additions to make to that dell.hk?
[10:10] <salty-horse> roger that
[10:15] <salty-horse> thanks BenC!
[10:16] <BenC> salty-horse: working?
[10:16] <salty-horse> glxgears works well
[10:18] <salty-horse> btw, nvidia-glx-legacy doesn't have nvidia-glx-new in "Conflicts:"
[10:19] <BenC> For anyone wanting to test HPA and PIIX changes, http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[10:19] <BenC> mmc fix is not in that build, but it's not as important
[10:19] <BenC> mjg59: ^^
[10:20] <BenC> salty-horse: Thanks, I'll get that fixed up
[10:20] <salty-horse> not sure if it matters, because the other two have glx-legacy :)
[10:20] <BenC> I think nvidia-glx-new has a conflicts with nvidia-glx-legacy, which should be enough
[10:21] <salty-horse> BenC, what's up with the bug report? each day there are new replies, mostly for support (out of the scope of the bug) - think they can be diverted to the new "Answers" section or to a post on the forums?
[10:23] <BenC> salty-horse: Sure, anything not related to 9631-being-available should be redirected
[11:18] <defendguin> mjg59, did you get a chance to look at that touchpad issue i was having?
[11:20] <mjg59> No
[11:42] <mjg59> BenC: Did the i2c issue get fixed?
[11:42] <BenC> mjg59: it's in-progress, IIRC
[11:43] <mjg59> So there'll have to be another upload anyway?
[11:43] <BenC> rtg was working on it
[11:43] <mjg59> Since it renders a load of machines unbootable?
[12:00] <mjg59> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96480/comments/30
[12:00] <mjg59> Uh
[12:01] <mjg59> Given that it renders some machines unbootable, how are they supposed to install?
[12:02] <mjg59> BenC: I'm really not happy with that bug being downgraded
[12:03] <BenC> mjg59: that's incorrect...but unless I get a tested or obvious patch in my hands in the next 60 minutes, it will have to get fixed in a post-release update
[12:05] <mjg59> BenC: It can't be fixed in a post-release update. The machines don't boot.
[12:05] <BenC> I can't say for sure, but I suspect we'll have a real quick point release
[12:05] <mjg59> The shipit CDs are going to be the originals
[12:05] <BenC> which means CD images and installers
[12:05] <mjg59> (Apparently)
[12:06] <BenC> I don't know what the plans are for shipit...it's possible that they may hold off for a point release, but I can't speak for that end of things
[12:07] <BenC> I wish we had gotten blacklist=foo,bar support into initramfs for things like i2c_ec :/
[12:07] <BenC> then again, it might not be too late
[12:08] <kylem> i think i need to yell louder, i asked for that in january...
[12:08] <kylem> we own initramfs-tools now though, don't we?
[12:08] <kylem> maybe i can hack something up when i get home tonight...
[12:08] <BenC> yeah, but no one ever took the time to implement it...not even the yellers :)
[12:09] <BenC> kylem: the script will have to make sure to copy it to /etc/modprobe.d/ on the root fs, even deleting the file if no blacklist is asked for
[12:11] <maks_> BenC blacklist in /etc/modprobe.d that is in the initramfs
[12:11] <BenC> maks_: For it to make sense, it has to blacklist in the rootfs too, else the module might get loaded later
[12:11] <maks_> BenC sorry i'm lost please explain
[12:12] <rtg_> BenC, mjg59: There are really 2 issues to the I2C bug. The i2c_ec module crash, and a much earlier crash that is a separate problem. The i2c_ec module now checks for a bogus parent and bails out, avoiding the fault.
[12:12] <BenC> rtg_: what is the earlier crash...like an oops, or a caught failure?
[12:12] <macd> are people experiencing the acpi bug (96480) on 2.6.17-11-generic also? 2.6.17-11-386 boots fine.
[12:13] <rtg_> Its not clear. The bug reporters aren't all that disciplined in their reporting.
[12:13] <maks_> BenC oh you want a bootparam blacklist
[12:13] <BenC> maks_: if someone wants to blacklist i2c_ec because it oopses on the install CD, then device probing later during install will reload it if the blacklist isn't kept in the rootfs
[12:13] <rtg_> BenC: I think its an ACPI fault early in the boot cycle on some platforms.
[12:13] <BenC> maks_: Right, something you can put on the command line for install
[12:15] <macd> rtg_, right right, I'll get a detailed bug posted.
[12:16] <mjg59> rtg_: Which upload contains the partial fix, then?
[12:16] <kylem> heh, i should go and buy a Mac Pro to get this i2c thing fixed, i can't reproduce it on my 4 ubuntu machines...
[12:17] <rtg_> mjg59: I committed yesterday, so it should be there. Ben?
[12:17] <mjg59> Because Ben's upload changelog doesn't mention it