[00:52]  * lifeless embuginates
[02:33] <emma> how is the Ubuntu Kernel different than other linux kernels or the one that Linus makes?
[02:49] <johanbr> see for instance http://people.canonical.com/~pgraner/talks/SELF-09/SELF-kernel-talk.pdf
[04:01] <psusi> weird... CONFIG_PM_DISABLE_CONSOLE seems to be set in all Ubuntu kernels... but as of 2.6.35 in maverick, this option seems to cause my video card to not be initialized after resume from suspend... the monitor just remains powered off.. if I build the Ubuntu 2.6.35 kernel sources with this config option set to n ( otherwise exact same config as 2.6.35-3 currently in maverick ) it works fine...
[04:02] <psusi> the option is set in lucid and prior kernels, but they also work fine...
[08:27] <stenten> Is there that much difference between the -lucid and -maverick mainline kernels? Can Lucid users who report bugs still test with the current -maverick kernel?
[08:32] <smb> stenten, If I explain this right, the difference is the base configuration used either from Lucid or Maverick. But the differences should be little enough to give useful results when testing
[08:35] <apw> right, its the configuration and build machines which come from the release specified.  lucid and maverick have not divereged much as yet, i am running a maverick kernel here on my lucid install
[08:35]  * apw waves morning
[08:35] <lifeless> apw: hi
[08:35] <lag> Morning
[08:35]  * smb waves back
[08:36]  * amitk waves
[08:40] <stenten> smb, apw: thanks, that makes perfect sense. Thanks!
[08:44] <cking> forgot to say "morning!" earlier.
[08:47] <smb> cking, Meh, me too while still walking through emails
[08:48]  * cking got too focused on looking a S3 issue..
[08:52] <smb> cking, You suspended yourself
[08:53]  * smb remembers he wanted to speak to apw this morning but forgot what that was about. Doh!
[08:53] <apw> lucky escape for me then
[08:54] <cking> smb, that's where a paper and pen comes in handy 
[08:54] <smb> Depends on *when* you think of it
[08:54] <cking> normally 3am for me
[08:55] <amitk> so, any chance that the unified debian packaging will make it into lucid and karmic?
[08:55] <smb> amitk, Depends on our supporters. :-P
[08:56] <amitk> Did you find any after cjwatson refused it?
[08:56] <smb> Not yet that I know of
[08:56] <RAOF> apw: Maybe it was about how investigating drm.debug is going? :)
[08:57] <apw> RAOF, i think sconklin is on that one thankfully, so i think back to bed for me
[09:04] <smb> Speaking of gfx, I was thinking of doing a debugging backlight issues page. (just remembered that was one of the things I wanted to ask). Where would that best fit in the new structure of wiki pages?
[09:05] <apw> Kernel/Debugging/Backlight perhaps, linking to Kernel/Debugging of course
[09:06] <smb> Oh and RAOF, I have a case of messed up EDID info here which I think I somehow isolated to come from my keyboard and display switch. If I connect the monitor directly it is ok. For those kind of checksum wrong. Is there a bug you are tracking specifically, should we make a new one?
[09:06] <smb> apw, Ok, sounds reasonable
[09:08] <RAOF> smb: Hm.  That certainly matches at least one bug I can think of off the top of my head, but I don't have a meta-bug about it.
[09:09] <RAOF> I'm not entirely sure what can be done about KVM switches, actually.  If they're corrupting the EDID then the driver is basically going to have to fall back on a list of standard modes.
[09:09] <apw> RAOF, in the 35-rc1 kernel it seems that the edid processing is triggering the kslowdNNN eating my cpu issue, you know anything about it?
[09:10] <apw> RAOF, one thing we need to better test and document is the kernel command line incantion to add/select a mode when one is not present
[09:10] <smb> I think to remember there were a lot of edid_valid *ERROR* EDID checksum is invalid, remainder is x bugs floating around. In my case x seemed to change every now and then.
[09:10] <RAOF> apw: Haven't seen that one come up, but I do recall some edid processing changes that got merged about then.
[09:10] <smb> RAOF, The thing is pre-kms I believe the same switch was handled correctly
[09:11] <smb> So it maybe ignored remainders or what not
[09:11] <RAOF> It might have just been more lax, yeah.
[09:12] <smb> It would not be the first diver adding code for the madness of hw-vendors
[09:12] <smb> err, driver even
[09:13] <smb> RAOF, Would you happen to have a link or doc at hand that describe how the EDID is *supposed *to be. Then I might compare that to the actual results and give better feedback there.
[09:17] <RAOF> http://docs.google.com/viewer?a=v&q=cache:mYmWXgIUta0J:www.x.org/wiki/XDC2007Notes%3Faction%3DAttachFile%26do%3Dget%26target%3DXorg_2007-EDID-JMiseli.pdf+site:x.org+edid&hl=en&gl=au&pid=bl&srcid=ADGEESg0T1gecuIUJeX1isUAslw2l6RpRzhZaOymJPsc6FVEZW4NBHkG8yBPYN7wfKuw02ixtDcRz_3BtPY9b2yLCXw_vXnQYy5gTCiKzFRvjLdVr76hOieixbLRL0eYq2T-3TpiirHo&sig=AHIEtbRTUG0TlIT9VjXCPJgaYFKgp_XRRA has a bit of an overview.
[09:17] <RAOF> Ooh.  That's perhaps a longer URL than I was expecting :)
[09:20] <RAOF> Wikipedia has a reasonable specification http://en.wikipedia.org/wiki/Extended_display_identification_data
[09:20] <smb> Cool, ok. lets see how far I get with that
[09:29] <RAOF> Time to head home.  Catch you later!
[10:14] <kraut> moin
[10:48] <amitk> second time in two days that my x-session got killed automatically and I came back to gdm with this in dmesg:
[10:48] <amitk> [15269.573089] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2
[10:48] <amitk> [15272.860288] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
[10:48] <amitk> [15272.877597] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
[10:51] <jk--> amitk: anything interesting in Xorg.log.0.old?
[10:53] <RAOF> amitk: That's just nouveau being chatty - it's closing the channel that the DDX had opened.
[10:58] <amitk> jk--: yeah, 
[10:58] <amitk> Backtrace:
[10:58] <amitk> 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a3248]
[10:58] <amitk> 1: /usr/bin/X (0x400000+0x655ad) [0x4655ad]
[10:58] <amitk> 2: /lib/libpthread.so.0 (0x7fe0a36fa000+0xf8f0) [0x7fe0a37098f0]
[10:58] <amitk> 3: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fe0a062b000+0x9e27) [0x7fe0a0634e27]
[10:58] <amitk> 4: /usr/bin/X (0x400000+0x130ed0) [0x530ed0]
[10:58] <amitk> 5: /usr/lib/xorg/modules/extensions/libextmod.so (0x7fe0a14e9000+0xf76d) [0x7fe0a14f876d]
[10:58] <amitk> 6: /usr/bin/X (0x400000+0x30c3c) [0x430c3c]
[10:58] <amitk> 7: /usr/bin/X (0x400000+0x261aa) [0x4261aa]
[10:58] <amitk> 8: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe0a23f2c4d]
[10:59] <amitk> 9: /usr/bin/X (0x400000+0x25d59) [0x425d59]
[10:59] <amitk> Segmentation fault at address 0x7fe09d60d000
[10:59] <jk--> amitk: before that? there should be the reason for the server exiting
[10:59] <amitk> Caught signal 11 (Segmentation fault). Server aborting
[10:59] <amitk> just filing a new bug
[10:59] <jk--> ah, segfault
[10:59] <RAOF> amitk: Has apport triggered?
[11:00] <amitk> RAOF: nope, I guess because the X server gets killed and returns me to GDM?
[11:01] <amitk> should apport be able to trigger from a new x session?
[11:01]  * abogani2 waves
[11:01] <RAOF> It should be able to grab the crash as it goes down.
[11:03] <RAOF> Because it's just listening to the core dump from the kernel.
[11:03] <abogani2> apw: Please don't forget me! :-)
[11:06] <amitk> RAOF: bug 595022
[11:06] <ubot2> Launchpad bug 595022 in xorg (Ubuntu) "noveau driver segfaults and kills X session (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595022
[11:09] <amitk> apw: you really edit 20 wiki pages at the same time!
[11:12] <RAOF> amitk: Ta.  If it's really easy to reproduce, a proper backtrace would make that easier to deal with.
[11:16] <amitk> RAOF: you want me to install the debug packages for X?
[11:18] <RAOF> They may help, but a nicely symbolic backtrace would be better.  You may be able to get that by turning on apport - it looks like you're running Lucid, which will have apport disabled.
[11:19] <apw> amitk, heh i don't know why you always think that.  i am moving stuff around so i am editing 2 or 3 at once ... but not more
[11:20] <amitk> apw: I think that because I see 30 emails with wiki updates from you over 20 different files
[11:20] <apw> heh but that is over several hours
[11:21] <amitk> RAOF: aah, i keep forgetting that we turn off apport after release. I've turned in on now.
[11:24] <apw> amitk, but yes i have been doing my 'half hour' of wiki gardening today ... i am hoping someone else will do theirs this week
[11:39]  * apw bitches about kslowd indeed causing slowness :/
[11:54] <cking> apw, perhaps kslowd should be called kveryslowd
[11:56] <apw> kcrunchycursord
[12:10] <cking> kannoyapwd?
[12:25] <apw> cking, kgettinghitwithadamnhammerd
[12:33] <cking> heh
[12:46] <apw> cking, well its definatly i915 losing its mind
[12:46] <apw>   0   897 ffff88012bb07510 12  20ms DRM_CRTC_HELPER: i915@pci:0000:00:02.0
[12:51] <nessita> hello everyone! Can anyone help me debugging why my sound is gone after installing the updates for maverick?
[12:54] <cwillu_at_work> nessita, every week a random module is removed from maverick just to make sure that the only people using maverick are the ones who know that it's unsupported ;)
[12:54] <apw> cwillu_at_work, thanks for your confidence
[12:55] <apw> nessita, you have no sounds at all ?
[12:55] <nessita> cwillu_at_work: I've been asked to install it, I work for the company ;-)
[12:55] <apw> what does aplay -l return
[12:55] <cwillu_at_work> apw, you're welcome.  I don't credit many people with the aptitude to pull off such stunts :)
[12:55] <nessita> apw: not at all that I can tell
[12:55] <nessita> apw: **** List of PLAYBACK Hardware Devices ****
[12:55] <nessita> card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog]
[12:55] <nessita>   Subdevices: 1/1
[12:55] <nessita>   Subdevice #0: subdevice #0
[12:55] <nessita> card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital]
[12:55] <nessita>   Subdevices: 1/1
[12:55] <nessita>   Subdevice #0: subdevice #0
[12:56] <apw> nessita, so the kernel has recognised the card at least
[12:56] <nessita> alsamixer has all settings at the top values
[12:56] <apw> have you checked the alsamixer settings, to confirm that the volumes are up and not muted
[12:56] <nessita> yes
[12:56] <apw> could you test with headphones to confirm that those do not work either
[12:57] <nessita> apw: I'm testing with those
[12:57] <nessita> I tried front and back plugs
[12:57] <apw> so it doesn't work with or without headphones
[12:57] <nessita> apw: well, without I coulnd't say, I have no speakers
[12:58] <apw> nessita, what sort of machine is this??
[12:58] <nessita> apw: a desktop machine, with no speaker but great view!
[13:00] <nessita> I must confess I feel like I'm loosing my computer slowly. First the eth0 was gone, then the nvidia drivers, and now the sound! /me cries
[13:01] <apw> nessita, ok so first thing to do is file a bug against alsa-driver, that should get the information needed by the sound peeps to debug it
[13:02] <apw> nessita, i normally don't update my userspace this early in the cycle, though i am using and suffering with the latest kernel
[13:02] <apw> ubuntu-bug alsa-driver
[13:02] <apw> ^^ should do the trick
[13:02] <nessita> apw: on it
[13:02] <apw> nessita, what ethernet card do you have ?  and have you filed a bug on that?  if not file one against linux
[13:02] <nessita> ah! "package alsa-driver does not exist"
[13:03] <apw> wtf
[13:03] <nessita> apw: yes, the eth0 issue was follow up by tgardner, last conclusion is that I have to flash my BIOS but so far I haven't been able to
[13:03] <nessita> apw: wanna a screenshot?
[13:07] <cwillu_at_work> apw, what do you know about compiling/hacking on alsa against recent kernels?
[13:07] <apw> wtf you really really are meant to be able to file bugs on alsa-driver
[13:07] <apw> we even have an apport package_hook to make sure it wors
[13:07] <apw> works
[13:08]  * apw goes and moans
[13:08] <cwillu_at_work> nessita, /usr/share/apport/package-hooks/source_alsa-driver.py exists?
[13:09]  * apw is getting the same failure yet i have that file
[13:09] <nessita> cwillu_at_work: yes, -rw-r--r-- 1 root root 187 2010-06-04 11:36 /usr/share/apport/package-hooks/source_alsa-driver.py
[13:09] <apw> cwillu_at_work, not much more than the stuff we have done in the lbm packages
[13:09] <nessita> apw: ah, so no need for the screenshot
[13:10] <apw> nessita, na one sec let me find out whats going on
[13:10] <cwillu_at_work> ah, damnit, I forgot to install sshd on my maverick box at home
[13:11] <apw> cwillu_at_work, a common error on my end
[13:11] <cwillu_at_work> rebuilding ubuntu's kernel packages has always been a bit mysterious to me
[13:11] <nessita> apw: thanks, I'll be around
[13:41] <apw> smb, hey we are meant to file audio bugs against alsa-driver right ?
[13:45] <apw> nessita, hey it seems that ubuntu-bug audio is the new way forward
[13:46] <nessita> apw: ok, then, filling the bug
[13:47] <nessita> apw: gah, non of the options fit my issue
[13:48] <nessita> shall I pick random? :-P
[13:52] <apw> yeah pick one ... stupid interface
[13:52] <apw> probabally the first one
[13:54] <nessita> apw: hum, the tool says "the following mixer control(s) are set quite low: Master is muted..."
[13:54] <nessita> I'm seeing alsamixer and all is 100%
[13:54] <apw> nessita, hrm
[13:55] <nessita> apw: duh
[13:55] <apw> nessita, can you get me a screen shot of your alsa mixers please
[13:55] <nessita> no need, it was muted indeed, but volume at 100%
[13:55] <apw> nessita, ahh, and are you now deafen by the sound ?
[13:56] <nessita> apw: not yet
[13:56] <apw> i get quite the oopossite effect here, the machine loves to unmute things on me
[13:56] <dgtombs> hi all, anybody know what mainline build is equivalent to the current maverick kernel?
[13:56] <apw> v2.6.35-rc3
[13:56] <dgtombs> thank you!
[13:56] <nessita> apw: so, any idea why updates muted everything?
[13:56] <apw> dgtombs, you can tell by looking at /proc/version_signature
[13:56] <dgtombs> thanks, i'm not running maverick though :) just triaging repots
[13:57] <apw> nessita, heh no, my experience is the opposite that it unmutes things and embaresses me in meetings
[13:58] <apw> dgtombs, ahh i like the sound of you triaging bugs for maverick ... is jfo helping you ?
[13:58] <JFo> apw, not yet
[13:58] <apw> JFo <-> dgtombs 
[13:59] <apw> jfo is our main triager and knows all the tricks
[13:59] <dgtombs> heh
[13:59] <JFo> dgtombs, have you seen the new pages at https://wiki.ubuntu.com/Kernel/BugTriage ?
[13:59] <apw> can point you to the documentation we have made and all that fun stuff
[13:59] <dgtombs> i'm not doing that much, just taking care of a few bugs i'm subscribed to
[13:59] <nessita> apw: well, anyways, thank you very much. An since we're at it, any idea is it safe to install nvidia drivers? last time xserver update removed them
[13:59] <JFo> every bit helps dgtombs 
[13:59] <dgtombs> :)
[13:59] <tgardner> nessita, its policy with the ALSA bunch to mute master on an update.
[14:00] <nessita> tgardner: oh, and how ddo you deal with the avalanche of bugs after that? 
[14:00] <apw> nessita, i don't know i'd be using them with it yet, i suspect they won't work as the kernel has jumped an enourmous ammount
[14:00] <tgardner> nessita, we all get pissed off :)
[14:00] <nessita> heh
[14:00] <apw> nessita, well as you noticed it checked and told you off when you tried to file a bug :)
[14:01] <nessita> tgardner: so, I was also looking for you. I haven't been able to flash my BIOS because the BIOS update provided by Intel requires executing an .exe file at boot time. Any idea how can I make a USD stick bootable so I can run that .exe?
[14:01] <nessita> apw: right :-)
[14:03] <nessita> tgardner: I have no floppy disk nor CD-DVD rom, so for now USB is my only bet
[14:03] <tgardner> nessita, oh crud. lemme research that. I used to have a DOS USB gizmo.
[14:04] <nessita> tgardner: the other option is to execute the .exe in a running win**** but my religion won't allow it
[14:05] <mjg59> nessita: Get a freedos boot image, mount it via loopback, put the .exe on it, boot it via grub using memdisk
[14:05] <tgardner> nessita, I understand :) I'm down to just one Windoze box 'cause I can't figure out how to load my nano ipod with books on tape from audible.com
[14:06] <nessita> mjg59: you make it sound so easy...
[14:06] <nessita> mjg59: have a link that provides some more details? like how to mount via loopback?
[14:07] <mjg59> mount -o loop disk.img /mnt
[14:08] <nessita> mjg59: see? you make it sound so easy :-)
[14:08] <nessita> mjg59: ok, and how can I boot it using memdisk?
[14:08] <cnd> apw: https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-Firmware
[14:09] <tgardner> nessita, http://syslinux.zytor.com/wiki/index.php/MEMDISK
[14:10] <nessita> tgardner, mjg59: thank you
[14:10] <dgtombs> jfo: question if you don't mind. i've got bug 406515, it's broken in lucid & maverick still, but fixed in latest mainline. the upstream linux task is currently Invalid, should i manually set it to Fix Released even though it was never reported upstream?
[14:10] <ubot2> Launchpad bug 406515 in linux (Ubuntu) (and 5 other projects) "[Karmic & Lucid Beta 1] Brightness fn keys lost functionality (Lenovo laptops) (affects: 38) (dups: 1) (heat: 218)" [Medium,Confirmed] https://launchpad.net/bugs/406515
[14:11]  * tgardner bounces for a kernel updatae
[14:11]  * JFo looks
[14:12] <JFo> dgtombs, no, that is the bugwatch
[14:12] <JFo> it gets updated automatically based on whatever bug it is watching upstream
[14:12] <dgtombs> jfo: correct, but there is no bugwatch for this bug
[14:12] <JFo> so it would get changed back to Invalid most likely
[14:12] <JFo> if you were to change it
[14:13] <dgtombs> it's an unlinked upstream task
[14:13] <JFo> yeah, I'd just leave it like that
[14:13] <dgtombs> ok
[14:13] <dgtombs> thanks!
[14:13] <JFo> my pleasure
[14:13] <dgtombs> jfo: and if you'd like to set to Triaged that would be cool, too :)
[14:13]  * JFo looks again
[14:15] <JFo> hmm, apw you are actually assigned to that bug ^^
[14:15] <JFo> bug 406515
[14:15] <ubot2> Launchpad bug 406515 in linux (Ubuntu) (and 5 other projects) "[Karmic & Lucid Beta 1] Brightness fn keys lost functionality (Lenovo laptops) (affects: 38) (dups: 1) (heat: 218)" [Medium,Triaged] https://launchpad.net/bugs/406515
[14:15] <apw> jfo best to assume i have forgotten all about it
[14:15] <JFo> heh, that was my assumption
[14:15] <dgtombs> heh, i think some of you are a little over-assigned :)
[14:15] <JFo> want me to remove the assignment?
[14:19] <dgtombs> in fact, if someone wouldn't mind taking a look at bug 421985, i think it should be Incomplete instead of In Progress (in fact, expired by now), but it's assigned to smb so i don't want to change it.
[14:19] <ubot2> Launchpad bug 421985 in linux (Ubuntu) "System Suspends/Hibernates when AC is unplugged (affects: 17) (heat: 107)" [Undecided,In progress] https://launchpad.net/bugs/421985
[14:20] <tgardner> that smb is such a slacker
[14:20] <smb> I have no problem in unassining myself
[14:21] <dgtombs> smb: your choice of course, i don't want to step on any toes :)
[14:21] <dgtombs> pgraner seems to have forgotten about it unfortunately
[14:21] <smb> dgtombs, Actually I might long time ago forgot about it
[14:22] <smb> pgraner, Actually that one was reported by you...
[14:22] <dgtombs> see why i was scared to mess with it? :)
[14:22] <pgraner> smb: which one
[14:22] <dgtombs> pgraner: bug 421985
[14:22] <ubot2> Launchpad bug 421985 in linux (Ubuntu) "System Suspends/Hibernates when AC is unplugged (affects: 17) (heat: 107)" [Undecided,In progress] https://launchpad.net/bugs/421985
[14:23] <smb> pgraner, The above. About suspending when removing battery on you Colovo
[14:23] <pgraner> smb: Ah sorry I did forget about it, the colovo fried it power supply so its not operational anymore
[14:23] <dgtombs> hah
[14:23] <dgtombs> i
[14:24] <dgtombs> i'll invalidate it then, i have more time than you do smb
[14:24] <pgraner> smb: I really need to get it a new supply, I just forget everytime I'm out
[14:24] <dgtombs> oh hmm
[14:24] <smb> dgtombs, There seem to be others that had been affected
[14:24] <dgtombs> smb: i think it's false duplicates
[14:25] <dgtombs> there's a big bug with unplugging A/C and upower reported critical battery for a sec, affects lots of cheap netbooks. but pgraner's bug seems different
[14:25] <smb> dgtombs, Ok, I let you check and invalidate it if you think those are other problem. The Colova had AFAI remember issues when reporting the batery level.
[14:26] <smb> I will unassign myself for now
[14:26] <dgtombs> ok. thanks for the help guys!
[14:41] <Keybuk> apw: hai
[14:42] <apw> Keybuk, hi ya
[14:42] <Keybuk> just been testing the initargs kernel
[14:42] <apw> Keybuk, hows it looking
[14:42] <Keybuk> found a bug with it
[14:42] <Keybuk> it's passing all the arguments properly by default, so I get "ro" and "quiet" as well as "splash" which is ideal
[14:43] <Keybuk> but when you add init=... it still passes the arguments that came before it
[14:43] <Keybuk> this breaks init=/bin/bash
[14:43] <apw> Keybuk, i am supprised by that, as i thought init= did a full reset
[14:43] <apw> i'll have a look and see whats causing that
[14:43] <apw> i cirtinaly did not aim to change that functionality
[14:43] <Keybuk> k, that was the only problem though
[14:43] <Keybuk> otherwise it was all good
[14:44] <apw> ok will go poke it
[14:50] <apw> Keybuk, hrm how did you confirm this?  as the init= implementation is to zap all existing args ... it won't zap the environment though
[14:50] <Keybuk> I booted with init=/bin/bash and it failed because "ro: no such file or directory" ;-)
[14:51] <Keybuk> (as the kernel called init=/bin/bash ro quiet splash -- so bash intepreted ro as a script to run)
[14:52] <apw> hrm
[14:56] <Keybuk> I also tried a shell script that echo'd the command-line it received, that shows the previous args too
[14:58] <apw> Keybuk, most perplexing as the handling of init= is unchanged as is the method by which they are inserted into the array
[14:58] <apw> so its behaviour seems hard to have affected
[14:58] <apw> can you do the same test with a stock kernel to confirm its working ever
[14:58]  * apw installs the test kernel in parrallel to retest, as he thought he had also tested this
[14:59] <apw> Keybuk, ok i've managed to reproduce it here ... will debug it
[15:00] <amitk> "Slashdot: Location Services Raise Privacy Concerns" - really??! Who would've thunk?
[15:01] <Keybuk> works just fine on mainline and stock ubuntu
[15:02] <tgardner> amitk, and you wonder why I'm such a luddite?
[15:02] <apw> Keybuk, yeah most odd, how i missed testing it i don't know
[15:03] <Keybuk> is only the initargs kernel that passes the args before init=
[15:03] <Keybuk> talking of mainline kernels
[15:03] <Keybuk> iwl3945 doesn't work in mainline either - what should I do now?
[15:04] <amitk> tgardner: your next phone is going to be a 'smart'phone, whether you like it or not. _That_ is what you should be worried about.
[15:04] <apw> so not working in either maverick or mainline kernels hrm ... i guess we need a bug filed with that info
[15:04] <tgardner> amitk, yeah, I know. I've been dragging my feet.
[15:04] <apw> tgardner, you heard anytihng about iwl3945 breaking?
[15:04] <tgardner> apw, nope. how is it breaking?
[15:05] <apw> Keybuk, ^^
[15:05] <Keybuk> tgrnot associating via WPA
[15:05] <Keybuk> tgardner: not assoc...
[15:05] <tgardner> Keybuk, does it work with a simple open AP ?
[15:06] <tgardner> there are some scanning patches in the pipeline from Intel, but they'll have to wain until -rc4
[15:07] <tgardner> wait*
[15:07] <Keybuk> tgardner: I don't have a simple open AP to test with
[15:07] <Keybuk> scanning seems to work fine, it can see the networks, just not join them
[15:08] <tgardner> I'm not sure I have one of those gizmos anymore. All I have are i4965.
[15:08]  * apw sends Keybuk to starbucks
[15:10] <Keybuk> ooh, hang on, there's a wifi router inside my modem
[15:10] <Keybuk> I can enable that
[15:11] <Keybuk> at least, I could if Linux wasn't shit
[15:14] <Keybuk> tgardner: it can associate to the open AP, but packet delivery appears to be failing
[15:16] <tgardner> Keybuk, ok, start a bug report and I'll see if I can get Reinette's attention with it.
[15:16] <Keybuk> ah, no
[15:16] <Keybuk> I hadn't enabled the DHCP server ;-)
[15:16] <Keybuk> it works fine in open AP mode
[15:16] <Keybuk> so it's WPA that doesn't work
[15:16] <apw> Keybuk, can you up it to WEP and test that perhaps
[15:16] <tgardner> Keybuk, still, a lot of folks use WPA. Is it WPA/PSK using TKIP ?
[15:17] <Keybuk> yus
[15:17] <Keybuk> WPA2 to be precise
[15:17] <tgardner> Keybuk, right, thats the most common setup
[15:18] <Keybuk> WEP seems fine
[15:18] <tgardner> Keybuk, so, it likely has something to do with key exchange
[15:21] <Keybuk> WPA1 doesn't work
[15:24] <Keybuk> huh, weird
[15:24] <Keybuk> it seems that the DHCPDISCOVER is getting out
[15:24] <Keybuk> but it's the return packets that aren't
[15:25] <tgardner> Keybuk, so its completing assoc, but can't receive directed data packets?
[15:26] <Keybuk> sounds it
[15:27] <tgardner> Keybuk, get all of this in a bug and assign me to it. it seems like a serious regression that we'd like to fix.
[15:27] <Keybuk> if you don't fix it, I know where you live
[15:27] <Keybuk> and I can have mini screwdrivers
[15:27] <Keybuk> I can swap one of your 4965 mini-pci cards with this one

[15:27] <tgardner> Keybuk, ah, you know approx where I live, but not _when_ I'll be there :)
[15:28] <Keybuk> tgardner: you don't have to be in
[15:30]  * Keybuk is quite worried that the only working computer in his house is running Mac OS X
[15:30] <Keybuk> actually, technically, the three working devices in my house are all running Mac OS X
[15:32] <tgardner> Keybuk, thats a fairly broad statement. I have at least one laptop thats working quite well with Maverick.
[15:32] <Keybuk> my laptop (maverick) won't associate to the wifi
[15:32] <Keybuk> my desktop powers off if USB devices are attached
[15:33] <tgardner> Keybuk, so, you never have to hit the power switch again? Isn't that a feature?
[15:33] <Keybuk> actually, that's unfair; the server is still purring on nicely ;-)
[15:34] <tgardner> that reminds me, I need to do some server upgrades.
[15:34] <Keybuk> and the PS/3 isn't running Mac OS X
[15:35] <tgardner> is that the port that Colin and Ben did?
[15:36] <Keybuk> the PS/3 is running PS/3 ;-)
[15:36] <Keybuk> you can't run Linux on them anymore
[15:36] <Keybuk> (and I never tried)
[15:36] <tgardner> tahts what I thought. Seems like it was Feisty timeframe
[15:38] <Keybuk> Colin would remember, though probably not a good idea to ask, I think the nightmares have only recently stopped
[15:38] <Keybuk> Kirsten hasn't remarked on him sitting bolt upright in bed and screaming "CEEEEELLLLLLLLLLLLLLLLLLLLLLLLLLLLLL!" in a Kahn-like way for a while
[15:39] <kirkland> hey apw, where are those daily vanilla kernels?
[15:39] <tgardner> kirkland, http://kernel.ubuntu.com/~kernel-ppa/mainline
[15:40] <apw> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[15:40] <Keybuk> kirkland: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[15:40] <kirkland> tgardner: Keybuk: thanks
[15:40] <kirkland> tgardner: any known, bad crypto regressions with 2.6.34?
[15:41] <tgardner> kirkland, not that have brought to my attention
[15:41] <tgardner> benn brought*
[15:41] <kirkland> tgardner: we're having a strange eucalyptus issue
[15:42] <kirkland> tgardner: only happens when we're decrypting an image, which should be happening entirely in userspace
[15:42] <kirkland> tgardner: UEC on Maverick with Maverick's kernel doesn't work (ie, can't do that decryption)
[15:42] <kirkland> tgardner: UEC on Maverick with Lucid's kernel works fine
[15:42] <tgardner> kirkland, reading from an encrypted mount?
[15:43] <kirkland> tgardner: i'm not entirely sure;  i think it's some userspace decryption in the Java code
[15:43] <tgardner> kirkland, hmm, how does that use kernel encrypt/decrypt ?
[15:44] <kirkland> tgardner: no idea;  we just know that it works when running one kernel, but not the other
[15:44] <kirkland> tgardner: i'm not working on this directly, just trying to get the guys focused in the right direction
[15:45] <tgardner> kirkland, does that java machine fail in other ways?
[15:46] <kirkland> tgardner: not sure;  my guess is that it was always doing something slightly wrong somehow, and with newer kernels, the failure is more pronounced
[15:46] <kirkland> tgardner: we'll dig
[15:46] <kirkland> Daviey: ping
[15:46] <Daviey> kirkland:  o/
[15:46] <tgardner> kirkland, k, I'll await word back from you
[15:48] <kirkland> Daviey: see the discussion up there between me and tgardner 
[15:48] <kirkland> Daviey: regarding UEC in maverick
[15:48] <kirkland> Daviey: are you working this issue actively, or is it background?
[15:49] <apw> tgardner, i wonder if it could be using a loop back encrypted mount sort of thing ?
[15:49] <apw> tgardner, and i wonder if it and wpa2 not working could be related, they are both encrypted
[15:49] <Daviey> kirkland: both.. at the moment none of UEC works.. so it's hard to test that issue
[15:50] <Daviey> apw: I did wonder if it's a lack of entropy or something
[15:50] <apw> Daviey, i would expect it to hang in that case perhaps
[15:50] <Daviey> Either way, ttx reproduced it today on latest maverick kernel with Alpha1 userspace.
[15:51] <Daviey> (i've also just reproduced it that was aswell)
[15:51] <tgardner> apw, if that were the case then no iwlwifi device would work, right?
[15:51] <apw> tgardner, fair comment, are you using wpa2 ?
[15:51] <tgardner> apw, AFAIK
[15:52] <ttx> It's definitely triggered by the kernel change... not sure if it's just a stricter kernel no longer supporting borderline cases, or just a plain regression
[15:52]  * apw has wep here due to a crappy work laptop the lass has
[15:52] <tgardner> wpa something, probably WPA2
[15:52] <apw> ttx, need to find out what it exactly doing ...
[15:52] <tgardner> ttx, kirkland: is there any dmesg bitching?
[15:53] <ttx> tgardner: rebooting and checking
[15:53] <ttx> fwiw the code does a java-bsead block decipher and complains about a bad padding
[15:53] <tgardner> ttx, actually, I was wondering if the java machine was causing any complaints by the kernel
[15:53] <ttx> based*
[15:54] <ttx> i was wondering how much the jdk/javax.crypto/bouncycastle stuff was relying on kernel functions to do that decipher
[15:55] <kirkland> tgardner: -> daviey for the dmesg
[15:57] <Daviey> i saw no dmesg help
[15:58] <Daviey> i can try again, but i remember being suprised it seemed to be kernel related, but nothing in dmesg
[15:58] <Keybuk> my dmesg is full of irqbalance respawning
[15:58] <Daviey> Keybuk: I think that is kvm related
[15:58] <ttx> Keybuk: bug 594509
[15:58] <ubot2> Launchpad bug 594509 in irqbalance (Ubuntu) "irqbalance main process ended, respawning (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/594509
[15:59] <Keybuk> Daviey: no, it's because the script is wrong
[15:59] <Daviey> ok
[15:59] <Keybuk> another upstart job that wasn't checked by the foundations team
[15:59] <ttx> no, it's just a bug in that upstart script
[15:59] <ttx> Keybuk: it was... but then got "fixed"
[15:59] <Keybuk> it's still wrong here today
[15:59] <ttx> by "fixed" I mean a bugfix introduced a bug
[15:59] <apw> he means you checked, then they "fixed" it into brokenness
[16:00] <ttx> apw: exactly
[16:02] <Daviey> Keybuk: I know you mentioned that upstart confs should be passed through foundations, but is there any hope of better docs this cycle?
[16:02] <Keybuk> Daviey: do you feel like you're in a documentation writing mood?
[16:02]  * Daviey hides
[16:03] <apw> Keybuk, who says 'unexpectedly disconnected from boot status daemon' ?
[16:04] <ttx> Daviey, kirkland: I'll try to reproduce on i386
[16:05] <Daviey> ttx: Is it worth it?
[16:07] <ttx> Daviey: might help in finding where it comes from (if it works there)
[16:07] <ttx> hrm, looks like I don't have that ISO.
[16:07] <ttx> so that's not for today.
[16:08] <Daviey> ttx: if you think there is merit in the test, i'll do it
[16:08] <ttx> Daviey: bisecting kernels to find which one "breaks" it is much more interesting
[16:08] <ttx> but also more time-intensive
[16:08] <apw> Keybuk, you know i am not sure this is is actually the kernel doing this
[16:09] <Daviey> apw: I was pretty surprised to find rolling back the kernel to lucid resolved it.. i had to check it again.
[16:09] <apw> Keybuk, i'll put that another way, i think that the initramfs is doing something odd _too_
[16:09] <Keybuk> apw: "doing this" ?
[16:09] <Daviey> Somewhat suprising to see kernel having such an issue with userspace
[16:10] <Keybuk> apw: I don't think initramfs does much interesting in this regard
[16:10] <Keybuk> it just copies its args to the userspace
[16:10] <Keybuk> I can test again without initramfs, one sec
[16:10] <apw> Keybuk, i don't think you need to am still poking
[16:10] <apw> but there is an odd interaction with initramfs as it runs some scripts before erroring about ro
[16:10] <apw> which is somewhat unexpected
[16:11] <Keybuk> sure it would
[16:11] <Keybuk> initramfs would run fine, it's a shell script and ignores its arguments
[16:12] <apw> so i'd have to have also _not_ honoured the init= and initramfs final step must do so
[16:13] <Keybuk> not sure I'm following you there ;-)
[16:14] <apw> Keybuk, heh .. i'll go confirm my theory and get back to you
[16:28] <JFo> apw, you are referring to https://wiki.ubuntu.com/Kernel/FAQ?action=show&redirect=KernelTeam%2FFAQ yes?
[16:28] <JFo> ack!
[16:28] <JFo> oh, it's a redirect
[16:28] <JFo> whew
[16:32] <JFo> smb, this is the test of the item: [jeremyfoshee] Jeremy to document the patch review process for kernel: TODO
[16:33] <tgardner> apw, note the mammoth initramfs-tools (0.96.1ubuntu1) update uploaded 90 minutes ago
[16:34] <apw> tgardner, yeeks no thank  you ...
[16:35] <tgardner> apw, well, you _were_ just grunging around in init scripts
[16:35]  * JFo sprays it with bug spray
[16:35] <apw> tgardner, indeed ... and i even less want to look in there now :)
[16:51] <tgardner> apw, do you know how I can restart a KVM image after using testdrive to install it?
[16:51] <apw> tgardner, you can run something to get it up ... virtmanager i think it is
[16:52] <tgardner> apw, k
[16:54] <JFo> <-lunch
[16:59] <maks_> happy cjwatson did the sync, was about time  :)
[17:14] <bjf> is it possible to install just the alsa drivers from lucid-lbm or when I check "Ubsupported updates (lucid-backports)" do I just get it all?
[17:15] <tgardner> bjf, AFAIK there are separate packages for each
[17:16] <tgardner> bjf, install linux-backports-modules-alsa-lucid-generic
[17:18] <smb> Yep, they are nicely spearated now
[17:19]  * manjo heading out to radio shack to buy cables 
[17:19]  * manjo getting lunch will be back soon
[17:21] <kamal> tgardner: fyi, all your testdrive KVM images are down in $HOME/.cache/testdrive/img and you can start them directly from there with e.g. kvm -m 2048 whatever.img   ( -usbdevice tablet  is useful too )
[17:22] <tgardner> kamal, ah, thanks. it was that bit ' kvm -m 2048 whatever.img' that I was looking for. my memory is like a sieve.
[17:23] <kamal> tgardner: man kvm   is an interesting read btw
[17:24] <tgardner> kamal, I have trouble distinguishing the difference between kvm, libvirt, qemu, et al.
[17:24] <kamal> $ ls -l `which kvm`
[17:24] <kamal> /usr/bin/kvm -> qemu-system-x86_64
[17:26] <kamal> and 'man kvm' yields the man page for qemu, actually :-)
[17:28] <cnd> cking: https://launchpad.net/ubuntu/+source/pm-utils-powersave-policy/0.3.1
[17:33] <apw> Keybuk, did you get those union-mount tools built again ?  i was thinking of doing some testing on them 
[17:33] <Keybuk> apw: no
[17:35] <tgardner> kamal, do you have a recipe for simple kvm bridged networking in the guest? I have the host bridge initialized, but cannot seem to get the guest to _not_ use the internal NAT network on 10.0.2.0.
[17:35] <kamal> tgardner: no, sorry -- I've always just used the NAT for simple things like moving files to and from the host
[17:36] <tgardner> kamal, hmm, I want a guest that can provide a service
[17:36] <kamal> google:  kvm network bridge    <-- some interesting looking stuff maybe
[17:37] <tgardner> kamal, the setup info has changed from Karmic to Lucid, and its all a bit confusing. maybe I'll bug Barcet
[17:37] <kamal> tgardner: good luck
[18:28] <ogasawara> make[2]: *** [drivers] Error 2
[18:28] <ogasawara> make[1]: *** [sub-make] Error 2
[18:28] <ogasawara> make[1]: INTERNAL: Exiting with 59 jobserver tokens available; should be 64!
[18:28] <ogasawara> anyone ever see that build failure before?
[18:29] <ogasawara> on emerald using armel chroot
[18:29] <tgardner> ogasawara, thats weird. emerald or tyler?
[18:29] <ogasawara> emerald
[18:29] <ogasawara> I'll try kicking the build off again to see if I can reproduce
[18:29] <tgardner> ogasawara, hmm, I wonder if the armel schroot has problems.
[18:30] <tgardner> ogasawara, if the x86* builds completed, then the arm build would also likely complete given the simple patches you are removing. you should upload anyways.
[18:30] <ogasawara> tgardner: ack
[18:38] <manjo> tgardner, so can I send out the patch with the test results and pgraner-afk can add his test finding to it too ?
[18:38] <tgardner> manjo, sure
[18:38] <tgardner> manjo, if it looks like its not gonna kill all our kittens, then I can make the change to modprobe and do the upload
[18:40] <bjf> manjo, when we make the switch, let ronoc & TheMuso know and they can do some audio testing
[18:40] <manjo> bjf, ok
[18:43] <tgardner> cnd, you could hassle someone on the archive team if you like: https://wiki.ubuntu.com/ArchiveAdministration#Archive days
[18:44] <cnd> tgardner: I think pitti may have mentioned he would review it for me
[18:44] <cnd> said he could be a sponsor OR an archive reviewed
[18:44] <cnd> reviewer
[18:44] <cnd> but not both
[18:44] <bjf> manjo, see http://www.ffado.org/?q=release/2.0.1
[18:44] <cnd> so I asked you to upload, and I'll ping him about the second step
[18:46] <manjo> bjf, the old modules will still be available in case the new ones don't work for some people 
[18:46] <manjo> pgraner, I will put up a wiki asap
[18:47] <pgraner> manjo: thanks, I also have a DV camera so I can test video as well
[18:48] <manjo> pgraner, using kino &/or dvgrab ?
[18:48] <pgraner> manjo: both + v4linux2
[18:49] <manjo> tgardner, I sent out the patch with test results to ukml
[18:51] <tgardner> manjo, ack
[19:01] <manjo> pgraner, https://wiki.ubuntu.com/Kernel/SwitchFirewireStack
[19:03] <manjo> pgraner, when you are done testing can you please share your results on the email thread on ukml (subject: [Maverick] switch to new firewire stack.) I introduced the patch to switch in that email. 
[19:03] <manjo> pgraner, so that we have some doc on testing done 
[19:03] <pgraner> manjo: sure thing
[19:23] <JFo> manjo, will there be a PPA kernel to test for the CFT or just a regular kernel?
[19:23] <JFo> BTw, I did see the myth ml that you want this sent to as well
[19:23] <JFo> I have added that to the CFT
[19:26] <JFo> pgraner, sent the triage summit mail to devel
[19:32] <JFo> ogasawara, do you know where our Call for testing page is?
[19:32] <JFo> I know i was there recently
[19:32] <JFo> just can't find it now
[19:32] <ogasawara> JFo: hrm, I don't.  I actually don't remember us having one :/
[19:33] <JFo> I could swear I saw one
[19:33] <JFo> hope I didn't dream it
[19:35] <manjo> JFo, the changes to kernel are already there in Maverick and Lucid, switch accounts to blacklisting old modules & (auto) whitelist new modules 
[19:35] <JFo> ok
[19:35] <manjo> JFo, I have a wiki on how to do the switch on ubuntu 
[19:35] <JFo> saw that
[19:35] <manjo> coo
[19:35] <manjo> cool
[19:35] <JFo> so this can be tested on both kernels?
[19:35] <manjo> bjf, suggest couple more places where you can send cft to 
[19:35] <JFo> ok
 manjo, when we make the switch, let ronoc & TheMuso know and they can do some audio testing
 bjf, ok
[19:36] <JFo> yeah, saw that
[19:36] <JFo> any others?
[19:36] <manjo> yes sir, when it makes into the distro we should be all set 
[19:36] <JFo> I plan to send to QA, devel, etc.
[19:37] <JFo> manjo, so there is a patch that needs SRU for lucid?
[19:37] <bjf> jfo, manjo, this will cause breakage if not coordinated a little with an upload of FFADO
[19:37] <JFo> or?
[19:37] <JFo> bjf, I see
[19:37]  * JFo notes that 
[19:37] <JFo> I see your ffado link above bjf
[19:37]  * JFo looks it over
[19:37] <manjo> JFo, no we will not sru for lucid 
[19:38] <manjo> JFo, coz its an LTS
[19:38] <JFo> ok, so no testing in Lucid
[19:38] <manjo> right only maverick
[19:38] <JFo> ok
[19:38] <manjo> but I did test on Lucid and it works fine too
[19:38] <JFo> ok
[19:38] <manjo> bjf, just curious why is FFADO imp ? 
[19:39] <bjf> manjo, i don't know much about it but i am assuming that is used by pro-audio folks
[19:40] <manjo> ah
[19:40] <apw> tgardner, i think the new initramfs tools are broken
[19:40] <tgardner> apw, bummer, how so?
[19:40] <apw> tgardner, actually not 100% sure its them
[19:41] <apw> but kernel failed to install on an upgraded system
[19:41] <tgardner> apw, not good.
[19:41] <apw> Invalid prameter, 2.6.35-3-generic
[19:42] <ogasawara> apw: I think that's the bug cjwatson pinged me about
[19:42] <apw> ogasawara, whats the word there?
[19:42] <ogasawara> [10:26:59] <cjwatson> ogasawara: heads-up on bug 595178, you're probably going to see a few dups of that while my fix percolates through the buildds
[19:42] <ogasawara> [10:27:01] <ubottu> Launchpad bug 595178 in grub2 (Ubuntu) "package linux-image-2.6.35-2-generic 2.6.35-2.3 failed to install/upgrade: subproces installed post-installation script gaf een foutwaarde 1 terug" [High,Fix released] https://launchpad.net/bugs/595178
[19:42] <ogasawara> [10:27:23] <ogasawara> cjwatson: ack, thanks
[19:42] <ogasawara> [10:27:39] <cjwatson> the "Invalid parameter, 2.6.35-2-generic" bit in the dpkg terminal log is the relevant one
[19:42] <ogasawara> [10:27:44] <ogasawara> JFo: ^^ fyi
[19:42] <ogasawara> [10:27:54] <cjwatson> upstream patch that snuck in without my noticing
[19:42] <ogasawara> apw: ^^ in #ubuntu-devel
[19:42] <ubot2> Launchpad bug 595178 in grub2 (Ubuntu) "grub-mkconfig stopped ignoring extra non-option arguments, breaking kernel postinst hooks (affects: 2) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/595178
[19:42] <ubot2> ogasawara: Error: Bug #595178 is private.
[19:42] <ubot2> Launchpad bug 595178 in grub2 (Ubuntu) "grub-mkconfig stopped ignoring extra non-option arguments, breaking kernel postinst hooks (affects: 2) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/595178
[19:42] <apw> ahh grub2 huh ... well thats something
[19:42] <apw> ogasawara, so we wait for grub to be fixed i assume
[19:43] <ogasawara> apw: yep
[19:43] <tgardner> apw, grab the source, build it locally
[19:43]  * JFo monitors the bug flow
[19:57] <psusi> I'm confused... last night I had narrowed down a suspend problem to CONFIG_PM_DISABLE_CONSOLE... it appeared in a number of places in the 2.6.35-rc3-3 source tree I got from apt-get install linux-source... now that I'm using git, I can only find one reference to it in the code, and not at all in the Kconfig files, and no references to it whatsoever in linus's tree
[20:05] <ogasawara> psusi: that looks like it came from an Ubuntu SAUCE patch
[20:05] <ogasawara> psusi: commit 6063b4dc3721a63d70f81522fa130372ded60b45
[20:05] <ogasawara> Author: Amit Kucheria <amit.kucheria@ubuntu.com>
[20:05] <ogasawara> Date:   Fri May 23 11:43:45 2008 +0300
[20:05] <ogasawara>     UBUNTU: SAUCE: pm: Config option to disable handling of console during suspend/resume
[20:05] <ogasawara>     
[20:05] <ogasawara>     Signed-off-by: Amit Kucheria <amit.kucheria@ubuntu.com>
[20:05] <ogasawara>     
[20:05] <psusi> ogasawara: yes, it does..
[20:05] <ogasawara>     Signed-off-by: Ben Collins <ben.collins@canonical.com>
[20:06] <tgardner> ogasawara, that one goes way back, feisty/gutsy days
[20:06] <ogasawara> I wonder if we still need to carry that patch
[20:06] <ogasawara> amitk: ^^ thoughts?
[20:06] <psusi> it seems to be breaking resume for me... with that setting on, my display never powers back on after resume
[20:06] <psusi> worked fine in lucid
[20:07] <bjf> pgraner, i'm running just fine from a stick using today's live image
[20:07] <psusi> with maverick it never powers back on... I traced it last night to this setting... if I build it myself and set it to n, display works fine
[20:07] <ogasawara> psusi: can you file a bug, might be reason enough to drop that sauce patch
[20:07] <psusi> did... bug #594885
[20:07] <ubot2> Launchpad bug 594885 in linux (Ubuntu) "Maverick kernel breaks video on resume from suspend (affects: 2) (heat: 12)" [Undecided,Incomplete] https://launchpad.net/bugs/594885
[20:08] <tgardner> ogasawara, I think that one has definitely decayed into crack
[20:08] <ogasawara> tgardner: maybe I'll rip it out and see if anyone else screams
[20:08] <tgardner> ogack from me
[20:09] <tgardner> ogasawara, ^^
[20:11] <pgraner> bjf: hmmm its an intel series 4, using i915 works fine under lucid won't under maverick
[20:11] <pgraner> bjf: I'm installing lucid now and will add the maverick kernel and see what that does
[20:13] <ogasawara> psusi: I'll get with Amit and confirm it's ok to drop and then I'll rip it out
[20:14] <bjf> pgraner, mine says mobile 4 series, integrated graphics, intel, i915 driver
[20:14] <psusi> ogasawara: ok... I'd like to understand why it is only now causing a problem though... worked fine in lucid and karmic...
[20:16] <ogasawara> psusi: can you priv msg me your email address, I'll CC on discussions to the mailing list
[20:16] <psusi> hrm... actually... I wonder... I never really looked into why but in lucid, whenever I would resume, the screen would come up with a bunch of snow.. white noise background... for a few seconds, then go to the blank screen saver until touching a key to get the password prompt.... maybe this patch was causing that
[20:17] <psusi> psusi@cfl.rr.com
[20:17] <ogasawara> thx
[20:20] <psusi> hrm... I wonder... I think there is an early stage of resume where some quirks can initialize the display.. I bet in lucid such a quirk is what initialized the display, but left the frame buffer full of trash, which would explain the snow... then after the resume finished, x wrote to the frame buffer... and since then upstream has disabled that quirk so early initialization is not done now,...
[20:20] <psusi> ...so the display is not initialized until vt_move_to_console() is called... which never happens with PM_DISABLE_CONSOLE
[20:59]  * ogasawara lunch
[21:14] <amitk> ogasawara: I think that patch was to allow debugging suspend, there are better ways now. Drop it!
[22:03] <ogasawara> amitk: sweet, thanks
[23:48] <lifeless> JFo: hi
[23:50] <lifeless> JFo: I filed a bug about wifi N support and you asked me to test the mainline build; what chance that that will fry my [production] laptop (e.g. by having a buggy ext4 or something like that)
[23:50] <lifeless> JFo: the wiki page says 'the kernel team does not support these kernels' which seems to be in direct opposition to asking folk to try them ?
[23:51] <manjo> lifeless, what bug# ? 
[23:52] <lifeless> sec, archived the mail already
[23:52] <lifeless> bug 594889
[23:52] <ubot2> Launchpad bug 594889 in linux (Ubuntu) "WiFi Link 6000 Series (rev 35) crashes regularly on N network (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/594889
[23:53] <lifeless> Its the machine stefan and andy were giving me test SD cards to get hardware quirk data on
[23:54] <lifeless>  - x201s, the one that there was a worry about an SRU regression on the first day of UDS :)
[23:54] <manjo> lifeless, there is std disclaimer with mainline builds because it is not a std kernel that the distro releases, it is meant only for testing purposes
[23:54] <lifeless> right
[23:54] <lifeless> I'm trying to assess the risk
[23:55] <lifeless> I have a known bug interfering with analysing optimising bzr performance, vs running an unreleased kernel mainline
[23:55] <manjo> lifeless, the problem is ... it is not possible for us to access the risk coz its a crack of the day kernel .. 
[23:55] <lifeless> manjo: exactly!
[23:56] <lifeless> manjo: so, I think I'd much rather have another SD card given to me in prague
[23:56] <lifeless> I can probably bring my N wifi AP with me
[23:57] <manjo> lifeless, sounds like an alternative 
[23:57] <manjo> ^ good 
[23:57] <lifeless> I'm a little averse to unquantifiable risk on production machines
[23:57] <lifeless> :)
[23:57] <manjo> sure understandable
[23:58] <lifeless> ok, I'll organise to bring the AP it has trouble with and will pop into the kernel room there
[23:58] <manjo> when you say link crashes you mean disconnects ? 
[23:59] <lifeless> manjo: its a little hard to pin down precisely.
[23:59] <lifeless> manjo: the firmware reboots seem to correlate pretty nicely with it completely giving up.
[23:59] <lifeless> manjo: a driver unload+load then makes it happy again.