[03:49] <bgamari> Does anyone know where the sata-sil24 driver can be found in the Karmic kernels?
[03:49] <bgamari> I can only find it in the -ec2 kernel
[12:30] <BenC> good morning
[12:35] <smb> Good morning BenC 
[13:13] <Q-FUNK> howdy!  could someone tell me what was the URL to Ubuntu packages of vanilla kernels?
[13:14] <tgardner> Q-FUNK, http://kernel.ubuntu.com/~kernel-ppa/mainline/
[13:15] <Q-FUNK> tgardner: thanks!
[13:19] <apw> bouncy tgardner 
[13:19] <tgardner> apw, at least mine rebooted OK
[13:20] <apw> maybe that is why keybuk is missing, he can't boot
[13:20] <smb> This time it rebooted as well
[13:20] <apw> smb, hrm ... not another race
[13:21] <tgardner> I should go back and retry the Tylersburg with bind mounts. Its pretty much guaranteed to hang.
[13:25] <smb> apw, Gah, and it would be nice if this would not always put sda6 into mtab when I am on sda8
[13:25] <apw> hrm
[13:25] <amitk> ericm_: wrong list
[13:36] <smb> apw, Ok, at least that strangeness is solved. It does not matter what uuid you have in fstab for root as long as the grub line is correct. But mtab will get confusing if you do
[13:52] <smb> apw, Bringing up gfx seems to be racy. With plymouth it seems to get stuck at some point. Without I sometimes get text login and sometimes it wors
[13:52] <smb> works
[13:53] <smb> Hm, seems to be having the "enter" drop to gdm problem
[14:06] <smb> apw, Are you aware of issues like "after suspend-resume, screen on i915 may go completely blank at random times"
[14:06] <apw> smb, is this something you are seeing?
[14:06] <apw> smb, does suspend/resume fix it
[14:07] <smb> apw, or not seeing my contents, yes
[14:07] <apw> smb is this an older i915 chipset ?
[14:07] <smb> apw, Let me try after the upgrade I do over ssh is done
[14:07] <smb> apw, likely
[14:07] <apw> if all the above are yes ... then reboot with i915.powersave=0 and let me know if that fixes it
[14:07] <smb> apw, Its the Aspire one
[14:08] <smb> apw, Ack
[14:08] <apw> akgraner is meant to be reporting back today as she was seeing randomness too and was trying powersave off for older kit ... ak ?
[14:08] <smb> apw, I usually get a screen goes crazy for a few seconds warning slightly before
[14:09] <apw> smb seen the same on my atom as well, think older less featureful i915 still needs powersave
[14:09] <akgraner> apw, hey- yeah I need to figure out who to right it up? :-(  without using words like the "thingy" the "watchchacallit" and such :-)
[14:09] <akgraner> s/who/how :-)
[14:09] <apw> Sarvatt, you were mentioning this i915.powersave=0 requirement for older i915
[14:10] <akgraner> but it only locked up once and I think it has to do with the mouse
[14:10] <apw> Sarvatt, i think i was hoping for a bug from you with the 'whihc ones are still afected' boundary
[14:10] <apw> akgraner, well thats a vast improvement over 25 times in a day ... so i think you qualify as fixed for the original bug with powersave=0
[14:10]  * apw will hastle Sarvatt to find out if they know the split
[14:10] <smb> apw, Is 945GME considered old?
[14:11] <akgraner> apw - I am happy and it wasn't so locked up that I had to reboot that time
[14:11] <apw> smb, i don't think its old in terms of age but older in terms of technology, lile 965 and newer powersave works and 945 and older does not ... but i don't have the exact boundary to add the switch
[14:12] <apw> will hastle graphicy people to find out
[14:12] <akgraner> apw, this is one time I am going to sit down with pgraner and reproduce this problem had seek some help  from him on documenting this for you
[14:13] <apw> akgraner, the powersave one?
[14:13] <smb> apw, Ok, and I test here. Powersaving sounds quite reasonable. It seems to put contents up. Though backlight is still on (and gets affected by inactivity and typing)
[14:13] <smb> I mean to put no contents up
[14:13] <akgraner> apw, yep - I don't know how to file bugs without using apport and well it didn't work for this particular problem
[14:14] <apw> smb, powersave at that level doesn't do anything visible, it down and up clocks the output dacs on activity in the framebuffer
[14:14] <apw> akgraner, just find the +filebug link and file it manually
[14:14] <apw> just say "i915: graphics hangs with i915.powersave=1 on some cards"
[14:15] <smb> apw, Well powering down all clocks _is_ somewhat visible
[14:15] <apw> and let me know the number
[14:15] <tgardner> akgraner, http://bugs.launchpad.net/ubuntu/+filebug
[14:15] <apw> smb, its not meant to turn them all off
[14:15] <akgraner> tgardner, thanks :-)
[14:15] <akgraner> apw, I'll do this now :-)
[14:16] <smb> apw, If that helps anybody:
[14:16] <smb> Interrupt enable:    00028c53
[14:16] <smb> Interrupt identity:  00000000
[14:16] <smb> Interrupt mask:      fffd73ae
[14:16] <smb> Pipe A stat:         00000000
[14:16] <smb> Pipe B stat:         80000302
[14:17] <smb> Interrupts received: 1009
[14:17] <smb> Current sequence:    3186277
[14:17] <smb> Waiter sequence:     0
[14:17] <smb> IRQ sequence:        3186019
[14:17] <apw> smb, if it stays like that thats a gpu hang
[14:17] <smb> apw, It does
[14:17] <apw> specifically the current and irq sequence numbers
[14:18] <apw> then we need to get a GPU hang dump off it
[14:18] <apw> and a bug, blah blah blah
[14:19] <smb> I think waiter sequence 0 is not very good at all. Let me collect and if powersave fixes it put it there
[14:36] <apw> smb ta
[14:40] <akgraner> apw, I think I did this right :-)  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539609
[14:40] <ubot3> Malone bug 539609 in linux "i915.powersave causes desk top to hang." [Undecided,New] 
[14:41] <BenC> I wonder if powersave is what is killing my d420
[14:42] <akgraner> tgardner, the link you gave me redirects to this page - https://help.ubuntu.com/community/ReportingBugs - didn't know if you knew that  or not  :-) 
[14:42] <BenC> [35198.621213] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[14:42] <BenC> [35198.621232] render error detected, EIR: 0x00000000
[14:42] <JFo> what link was it akgraner?
[14:42] <BenC> akgraner: do you get that in your kernel log at all?
[14:43] <tgardner> akgraner, hmm, it doesn't do that for me. the Launchpad folks are making it really tough to submit a bug that doesn't conform to one of their categories
[14:43] <akgraner> apw - for the can you reproduce this bug" - I put no, b/c the was no maybe button however I think I can.
[14:44] <akgraner> JFo, http://bugs.launchpad.net/ubuntu/+filebug
[14:44] <apw> akgraner, s'ok in this case as i know what the bug is and how to fix it, just need input from X on which cards are affected
[14:44] <JFo> heh, no maybe button... you kill me
[14:45] <akgraner> BenC, is there a GUI for getting to the kernel log?
[14:46] <BenC> akgraner: I just did "dmesg" from a terminal
[14:46] <BenC> akgraner: also, /var/log/kern.log
[14:47] <akgraner> BenC, not I don't seem to have that message
[14:47] <akgraner> s/not/nope
[14:48] <smb> BenC, For what its worth, I got that neither
[14:48] <akgraner> JFo, well I think there should be a "maybe" and a "several times a day" button :-)
[14:48] <JFo> heh
[14:49] <akgraner> JFo, but seeing as how I am just now learning how to file bugs - it might just be me :-)
[14:54] <BenC> smb, akgraner: Ok, guess I have a diff problem, but I'm going to test the powersave disable anyway :)
[14:54] <bjf> ##
[14:54] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:54] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:54] <bjf> ##
[14:54] <BenC> right now I've left it in low graphics mode and haven't had a lockup or resume failure in a few days
[14:59] <manjo> apw did you do an upgrade on your 10v today? 
[15:00] <apw> manjo, nope ... always risky around now
[15:00] <apw> problems?
[15:00] <manjo> apw, after I upgrade and reboot I just got the logo spinning and no progress...
[15:00] <apw> smb, sound like your issue?
[15:00] <manjo> apw, looks like my root was mounted readonly and I had a ton of uread ahead messages 
[15:00] <smb> Yeah could be
[15:01] <manjo> my 10v has ssd 
[15:01] <smb> manjo, Does pressing "s" help?
[15:01] <manjo> smb, trying again 
[15:02] <manjo> now its searching for disk errors ... I will let it complete .. 
[15:03]  * BenC plays the wait-and-see game now
[15:05] <manjo> hmmm disk check is taking for ever at 73% 
[15:08] <apw> heh BenC do what i am doing, wait till smb et al stop whining :)
[15:08] <apw> ok missive on built-in modules on the kernel-team list ...
[15:08] <apw> ok missive on built-in modules on the kernel-team list ...
[15:09]  * tgardner suspects apw is mumbling to himself out load again.
[15:09] <smb> apw, ?
[15:10] <cking> won't be the first time either
[15:10] <smb> cking, tgardner Guess he wanted to draw some attention to some mail
[15:13] <BenC> hehe
[15:26] <manjo> apw, how come we are reviewing this now ? 
[15:27] <smb> apw, Keybuk Seems there is something still not quite right with plymouth. I get see the splash screen turn to one with the 4 dots lightened and then have a crash report for plymouthd and a daemon I cannot kill together with X running. I was able to kill X, this caused the plymouthd to end and gdm to start
[15:29] <smb> At that point in time I could ssh in, but mouse and keyboard locally were not responding
[15:29] <Keybuk> smb: got the crash report?
[15:29] <Keybuk> a segfault of plymouth tends to be quite catastrophic thanks to this bit of the kernel being written by spastics
[15:29] <smb> Keybuk, Its still there
[15:33] <Keybuk> "it" ?
[15:34] <smb> Keybuk, Uploading, just a sec
[15:41] <smb> Keybuk, It is bug 539655
[15:41] <ubot3> Malone bug 539655 in plymouth "Boot screen locks up while X starts" [Undecided,New] https://launchpad.net/bugs/539655
[15:44] <Keybuk> you see all four dots fill?
[15:44] <Keybuk> does it jump to all four dots?
[15:44] <smb> Keybuk, yes
[15:44] <Keybuk> ok
[15:44] <Keybuk> that means X should be starting
[15:45] <smb> Keybuk, It was running
[15:45] <smb> Just not displayed
[15:45] <Keybuk> you said there was a segfault?
[15:45] <smb> Keybuk, maybe not correctly stated. I meant the report in /var/crash
[15:45] <Keybuk> that's unrelated
[15:46] <Keybuk> you're on Ubuntu not Kubuntu right?
[15:46] <smb> Right
[15:46] <smb> When I logged in plymouthd was in state D
[15:46] <Keybuk> But ssh login works and shows a plymoutd process (in state D), the call to stop it and an X process running.
[15:47] <Keybuk> ..
[15:47] <Keybuk> could you attach this "ps" output to the bug
[15:47] <Keybuk> also I don't suppose you could gdb attach to plymouthd and get a backtrace?
[15:47] <smb> Let me try whether it gets into the same state again.
[15:48] <smb> Those things tend to go away when one looks too close
[15:49] <smb> Grr, disk check
[15:49] <smb> Hm, seems the similar fate.
[15:49] <smb> Goes to 70% and then there is a flicker
[15:50] <smb> Then it comes back with 70% but stops moving
[15:53] <smb> Keybuk, Hm, not using gdb too often... How would I break to a gdb command line after attaching to the process
[15:54] <Keybuk> does it not break?
[15:54] <Keybuk> ooh, kernel bug
[15:54] <Keybuk> strace instead of gdb?
[15:54] <smb> No it just tells me attached to process x and stays there
[15:54] <manjo> Keybuk, I see the same issue 
[15:54] <smb> I don't think it will show much as it seems to be stuck
[15:54] <Keybuk> yikes
[15:54] <Keybuk> right, it's stuck in a syscall
[15:54] <Keybuk> which syscall?
[15:55] <manjo> init: plymouth main process (318) killed by SEGV signal 
[15:55] <Keybuk> manjo: can you get that segfault?
[15:55] <manjo> Keybuk, trying ... I tried to switch VT and it seems to be frozen ... restarting 
[15:56] <Keybuk> yes, you'll need to ssh in etc
[15:58] <manjo> s**t looks like I messed up my filesyste ... now I cannot seem to mount my / 
[15:59] <Keybuk> manjo: I've done that about twice a day for the last two weeks :p
[16:00] <smb> Keybuk, strace seems to lockup too, but maybe /proc/x/wchan = nouveau_gem_ioctl_cpu_fini helps?
[16:01] <manjo> Keybuk, how did you manage to fix ? I don't seem to be able to fsck it ... tried init=/bin/bash and fsck but does not fix 
[16:02] <BenC> Xorg restarting randomly is a painful experience
[16:03] <Keybuk> manjo: oh, I just blast and reinstall the machines
[16:03] <manjo> heh!
[16:03] <Keybuk> smb: oh, yes, that helps :D
[16:03] <Keybuk> smb: that helps a lot
[16:04] <smb> Keybuk, Likely you can now point at the kernel :-P
[16:04] <Keybuk> oh yes
[16:04] <Keybuk> that's a card hang
[16:04] <Keybuk> iirc
[16:04] <Keybuk> it's waiting for a command response from the gpu I think
[16:04] <smb> Keybuk, Well not completely
[16:05] <smb> As I can kill -9 X and then everything works
[16:05] <Keybuk> yeah it's X that's hanging here not plymouth afaict
[16:05] <Keybuk> if you see all four dots, plymouth is gone
[16:06] <Keybuk> well, other than waiting to close the drm connection once X has it
[16:06] <Keybuk> if X hangs, plymouth will just be waiting for X to go
[16:07] <smb> Seems plymouthd waits for some final drm response while X already started up somewhat but the screen rendered is the plymouth screen and keys seem to go not to X as well
[16:07] <Keybuk> no, not that I know of
[16:08] <Keybuk> plymouth is just trying to close the drm file descriptor
[16:08] <Keybuk> actually
[16:08] <Keybuk> sorry
[16:08] <Keybuk> I'm talking crap
[16:08] <Keybuk> you're on nouveau
[16:08] <Keybuk> you have just one monitor right?
[16:09] <smb> right
[16:09] <Keybuk> so there should be no DRM involved here
[16:09] <Keybuk> I'll have to check the code in a sec, but I'm pretty sure plymouth just uses the frame-buffer renderer on single-monitor nouveau
[16:09] <Keybuk> plymouth doesn't really like GEM
[16:09] <apw> plymouth is pretty damn picky
[16:10] <smb> Keybuk, OK, and I attach the ps-ax and wchan info to the bug for completeness
[16:10] <Keybuk> please
[16:10] <Keybuk> apw: not really, GEM is pretty crappy to program
[16:10] <Keybuk> it's harder than just writing to the frame buffer
[16:10] <Keybuk> and slower
[16:10] <Keybuk> so on GEM drivers, plymouth writes to the frame buffer
[16:10] <Keybuk> unless you have multi-head, in which case it grudgingly deals with GEM so it can use each native resolution
[16:10] <Keybuk> oh, right
[16:11] <Keybuk> and there's no way to do the "leave what I just had on the screen" with GEM
[16:11] <Keybuk> so you always get a black screen
[16:11] <Keybuk> (that's probably half of the reason it avoids GEM actually)
[16:11] <apw> ahh ... i found external screens even on intel sucked with plymouth
[16:11] <apw> triggering all sorts of resolution changes
[16:11] <Keybuk> huh
[16:11] <Keybuk> that shouldn't be the case
[16:12] <Keybuk> Intel is TTM
[16:12] <Keybuk> Plymouth likes TTM
[16:12] <apw> plymouth did nice things, purple on main, and black on external (with the logo)
[16:12] <Keybuk> huh
[16:12] <Keybuk> it's supposed to be purple on each
[16:12] <apw> and then gdm got pissed off and reset the resolution and mirrored t
[16:12] <Keybuk> each in their native resolution
[16:12] <Keybuk> logo centered on each
[16:12] <Keybuk> oh, maybe gdm sucks ;)
[16:12] <apw> to both ... and then on login it switched back
[16:12] <Keybuk> plymouth is doing pure DRM + FB
[16:13] <Keybuk> so it's more like wayland than X
[16:13] <apw> i couldn't see purple under the external screen logs
[16:13] <apw> logo
[16:13] <Keybuk> neat test of plymouth multi-head
[16:13] <apw> Keybuk, oh i did wonder on the purple background, could it be made to stop one 'character' from each side?
[16:13] <Keybuk> while running X :
[16:13] <Keybuk>   sudo plymouthd; sudo plymouth --show-splash
[16:14] <apw> to avoid the cursor cuttting holdes in it
[16:14] <Keybuk> apw: you shouldn't see the cursor
[16:14] <apw> Keybuk, that didn't work at all well
[16:14] <Keybuk> apw: what version of plymouth are you running?
[16:15] <apw> ii  plymouth                                          0.8.0~-12                                              graphical boot animation and logger - main p
[16:15] <apw> i got both the splashes on my left monitor, at about 1/4 natural resolution
[16:15] <Keybuk> eeeeeep
[16:15] <Keybuk> yeah don't run that on that version of plymouth ;)
[16:15] <Keybuk> right, that's what you should see - it just makes two X windows of different sizes to test that themes scale and centre properly
[16:16] <Keybuk> anyway your plymouth is awy out of date
[16:16] <Keybuk> you have the buggy crap plymouth
[16:16] <apw> oh ok then it worked :)
[16:16] <Keybuk> unfortunately, you're about to lose your X server
[16:16] <Keybuk> :D
[16:16] <apw> i have a plymouth thats is sufficinetly old that boot works for me
[16:16] <Keybuk> no, you have the one before I fixed it all
[16:16] <Keybuk> it always generally worked on intel though
[16:16] <apw> i am waiting for smb to stop whining his boot doesn't work at all with your new stuff
[16:16] <apw> before i install it :)
[16:16] <Keybuk> from the sound of it, smb's problem is nouveau related
[16:17] <smb> :-P
[16:17] <Keybuk> talking of nouveau
[16:17] <Keybuk> I have a laptop here with an nvidia card in it
[16:17] <Keybuk> how do I install?
[16:17] <apw> yep, ...
[16:17] <apw> nouveau is default
[16:17] <Keybuk> yes
[16:17] <apw> either it works or it doesn't
[16:17] <Keybuk> and I get a screen full of crap and corruption
[16:18] <smb> Sounds my last ati install
[16:18] <apw> noodeset help at all?
[16:18] <apw> nomodeset ?
[16:18] <Keybuk> how do I add that now we don't have a boot menu?
[16:18] <apw> Keybuk, now you'd have to ask someone in foundations about that :)
[16:18] <Keybuk> :D
[16:18] <smb> There is one if you press escape
[16:18] <apw> hold shift i assume?
[16:19] <apw> oh hrm a different button?  most unintuitive
[16:19] <Keybuk> this is on the installer - SYSLINUX :p
[16:19] <apw> gurgle
[16:19] <apw> beep
[16:19]  * Keybuk changes the config on the USB key :p
[16:19] <apw> your call could not be connected at this time
[16:19] <apw> though it sounds like ESC is worth a shot, i suspect smb has been using it a lot
[16:19] <smb> While doing the kvm tests, yes
[16:20] <smb> The picture you see is very much _not_ intuitive
[16:20] <Keybuk> does nouveau work on *anything* ?
[16:20] <apw> Keybuk, and where is my x-server going?
[16:20] <Keybuk> apw: well, when you get bored and run "sudo plymouth quit"
[16:20] <apw> Keybuk, i have been told by bryceh yes
[16:20] <Keybuk> apw: save your work first
[16:20] <Keybuk> really?
[16:20] <smb> Speaking of intuitivity, the [SM] on mountall is another example :-P
[16:20] <Keybuk> because I have two nvidia machines
[16:20] <apw> Keybuk, oh i went for killall plymouthd, seemed to work
[16:20] <Keybuk> and I have never seen nouveau work :p
[16:20] <Keybuk> apw: ah ;P
[16:20] <Keybuk> apw: you might be lucky there
[16:21] <apw> seems i was lucky :)
[16:21] <smb> Keybuk, It worked before todays update
[16:21] <Keybuk> smb: mountall likes pain
[16:21] <apw> bryceh, hey ... where are our testing results for Nouveau
[16:21] <apw> i am sure we have some around here somewhere
[16:21] <Keybuk> fortunately these machines are all Dells
[16:21] <Keybuk> and we don't have any kind of relationship with Dell
[16:21] <apw> sadly i have nothing but intel h/w so i cannot test myself
[16:21] <smb> Keybuk, And it works mostly when I disable plymouth. *grrr*
[16:21] <Keybuk> and Dell would never ship an NVIDIA card or chip anyway

[16:22] <apw> Keybuk, i soooooo wish
[16:22] <apw> need to know if nomodeset works on them if modeset does not
[16:22] <apw> and if so we need to record that and blacklist them
[16:22] <apw> have patches to allow blacklisting, just no list of black
[16:22] <Keybuk> smb: does it work if you remove "splash" from the cmdline?
 hmm... with the latest nouveau bits from the ppa, the boot hangs at the plymouth splash screen, just before switching to gdm
 booting without splash works
[16:23] <apw> someone else on #u-x bitching about something changing
[16:23] <Keybuk> meh
[16:23] <Keybuk> I really need some hardware for this
[16:23] <smb> Keybuk, Yes, well mostly, sometimes X does not start, but other times it does
[16:23] <Keybuk> *all* of our reported problems are nvidia now
[16:23] <apw> as nouveau hasn't changes for ages... i suspect that there is something else at work here
[16:23] <apw> smb, yours worked until today right?
[16:23] <apw> yesterday and the day before?
[16:23] <smb> Right
[16:24] <apw> and the kernel has not changed
[16:24] <smb> But I cannot say when my last update was
[16:24] <Keybuk> until today ?!
[16:24] <apw> so ... whatever it is its not the nouveau driver
[16:24] <apw> smb, your logs will tell you when yo last updated before that
[16:24] <apw> and see if the kernel changed in the pile
[16:24] <Keybuk>  /var/log/dpkg.log ftw
[16:24] <Keybuk> also see if plymouth or X changed
[16:24] <smb> But at least I had either your franken kernel or -16
[16:24] <Keybuk> or gdm for that metter
[16:26] <smb> apw, Keybuk Seems at least linux-image-2.6.32-16.25 was installed today as well.
[16:27] <apw> smb what did you have before kernel wise
[16:27] <Keybuk> grep "update linux-image" /var/log/dpkg.log
[16:27] <Keybuk> err
[16:27] <Keybuk> grep "upgrade linux-image" /var/log/dpkg.log
[16:29] <smb> That seems to be the meta package numbers...
[16:29] <smb> upgrade linux-image-generic 2.6.32.15.16 2.6.32.16.17
[16:30] <smb> Strangely dpkg -l tells me -15.22 was last but I am pretty sure I did apw's preview kernels there for testing
[16:31] <apw> was that with the nouveau backport?
[16:31] <apw> as in with LBM
[16:31] <smb> Once with LBM, but also your drmbackport version in kernel
[16:32] <smb> But that package were -15.21~xxx
[16:32] <smb> so got replaced in between
[16:32] <apw> smb, ahh yes would have
[16:35] <Keybuk> so nouveau was changed today
[16:35] <Keybuk> and things started breaking today? :p
[16:35] <smb> Keybuk, I had the same version of nouveau before. Just as a testing kernel.
[16:38] <smb> Keybuk, But to be honest, plymouth was turned of before because of the press enter to die bug on 64bit. I turned it back on as there was a problem that looked like mountall waiting for something but not telling issue
[16:39] <Keybuk> *sigh*
[16:39] <smb> Some days you forget where you started because every step takes you to another issue
[16:39] <Keybuk> yes, I understand :-/
[16:39] <Keybuk> but this is a problem we really need to fix
[16:39] <Keybuk> it's a bit disheartening actually
[16:39] <Keybuk> I have a large pile of hardware here
[16:40] <Keybuk> and the only machines that can boot right now are the Intel ones
[16:40] <Keybuk> (pure Intel)
[16:40] <Keybuk> Intel with ATI graphics => won't boot
[16:40] <Keybuk> Intel with NVIDIA graphics => won't boot
[16:40] <Keybuk> AMD64 with NVIDIA graphics => won't boot
[16:40] <Keybuk> etc.
[16:40] <Keybuk> from my, admittedly limited, testing pool, I've come to the conclusion that this will be our worst release ever for hardware support
[16:41] <smb> Probably we need to find out whether it needs a step back and not have splash for anything than intel helps
[16:41] <Q-FUNK> karmic wasn't too good either.
[16:42] <Keybuk> Q-FUNK: karmic at least works on all of the machines here
[16:42] <Keybuk> smb: but it isn't just splash
[16:42] <Keybuk> like this one I'm trying to install right now
[16:42] <Keybuk> Dell Latitude D620
[16:42] <Q-FUNK> Keybuk: not here.
[16:42] <Keybuk> this is pretty much one of our bread-and-butter machines
[16:42] <JFo> Keybuk, my D620 is working fine
[16:42] <Keybuk> a lot of us have Dell Latitude Dx[23]0
[16:43] <Keybuk> JFo: with nvidia or intel graphics?
[16:43] <JFo> but then I did an upgrade
[16:43] <JFo> nvidia
[16:43] <Keybuk> it works with modeset?
[16:43] <JFo> is is exactly as installed
[16:43] <Keybuk> because all I got when trying to boot today's daily was a corrupt screen
[16:43] <JFo> I have made no boot mods
[16:43] <Keybuk> modeset=0 seems to work, but with the wrong resolutions
[16:44] <JFo> Keybuk, let me reboot and I will let you know if today's update causes any problems
[16:44] <JFo> brb... either here or on my mini
[16:45] <bjf> ## 
[16:45] <bjf> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
[16:45] <bjf> ##
[16:47] <JFo> Keybuk, the only issue I am seeing is that the font for the splash is not correct
[16:47] <JFo> it isn't the new style
[16:47] <Keybuk> font?
[16:48] <JFo> yeah, the new looking ubuntu font 
[16:48] <Keybuk> what font? :p
[16:48] <JFo> heh
[16:48] <Keybuk> could you describe the splash screen for me? <g>
[16:48] <JFo> :-P
[16:48] <JFo> it is purple

[16:48] <JFo> :)
[16:48] <Keybuk> and what does it have written on it?
[16:48] <JFo> Ubuntu 10.04
[16:48] <Keybuk> see
[16:48] <Keybuk> I knew you had mode setting disabled
[16:49] <Keybuk> and I, again, adore the fact that we fooled you
[16:49] <JFo> it isn't anything I myself have done then
[16:49] <JFo> and it is new, because it was working before
[16:49] <JFo> about 2 days ago it changed to that
[16:49] <Keybuk> working before > you had an ubuntu logo before?
[16:49] <JFo> yes
[16:49] <JFo> and the nice new font :)
[16:50] <lamont> hey, what do you know
[16:50] <JFo> nice hat lamont :)
[16:50] <Keybuk> JFo: sounds like someone blacklisted your card maybe?
[16:50] <Keybuk> dunno
[16:50] <Keybuk> but yes
[16:50] <Keybuk> what you have there is just a plain text splash screen :p
[16:51] <JFo> Keybuk, maybe, but it wasn't me
[16:51] <JFo> came in by way of updates
[16:51] <Keybuk> it only looks a bit like a real one, because I discovered how to reprogram the VGA palette so I could have purple backgrounds and orange text :p
[16:51] <lamont> bjf: totally not my problem now.
[16:51] <JFo> ah hah!
[16:51] <Keybuk> those "."s that are animating are just printf (".") :p
[16:51] <JFo> I see
[16:51] <Keybuk> and that's just printf ("Ubuntu 10.04") :p
[16:51] <JFo> so I wonder why it changed
[16:51] <Keybuk> that, I don't know
[16:51] <JFo> it looked very nice just a few days ago
[16:51] <Keybuk> are you using xorg-edgers ? :p
[16:51] <JFo> nope
[16:52] <JFo> do I need to be?
[16:53] <JFo> 01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
[16:53] <JFo> that is my card ^^
[16:56] <JFo> bryceh, do you know of any blacklisting on that card? ^^
[16:56] <Keybuk> that's the same one I have here
[16:56] <JFo> anything that would have been added recently?
[16:56] <JFo> hmmm
[16:56] <Keybuk> which is unsurprising
[17:00] <bjf> ##
[17:00] <bjf> ## Meeting starting now
[17:00] <bjf> ##
[17:01]  * jjohansen here
[17:01] <smb> but not there
[17:02] <jjohansen> hehe, thanks
[17:03] <smb> Keybuk, Without splash it seems to be a 50:50 chance X comes up. If it does not I get a 
[17:04] <smb> (EE) PreInit returned NULL for ""Macintosh mouse button emulation""
[17:16] <Keybuk> JFo: grep -r nouveau /etc/modprobe.d
[17:23] <JFo> Keybuk, sorry for the delay
[17:23] <JFo> jfo@jfo-lappy:~$ grep -r nouveau /etc/modprobe.d
[17:23] <JFo> /etc/modprobe.d/nvidia-graphics-drivers.conf:blacklist nouveau
[17:23] <JFo> /etc/modprobe.d/nvidia-graphics-drivers.conf:blacklist lbm-nouveau
[17:23] <Keybuk> so you're using nvidia-glx :p
[17:24] <JFo> hmmm
[17:24]  * JFo did not know that
[17:24] <JFo> how can I change it back?
[17:24] <Keybuk> do your windows have drop-shadows and 3D madness?
[17:24] <bryceh> JFo, to my knowledge we have not blacklisted any cards.  apw can correct me
[17:24] <smb> Not normally I gues
[17:24] <apw> yeah i think that means he has binary drivers installed
[17:24] <JFo> bryceh, I think Keybuk just showed me the way to the promised land
[17:24] <bryceh> JFo, hmm you know it would probably be good for both me and you to know exactly where to look in the kernel for the list of blacklisted kms cards
[17:24] <JFo> :)
[17:24] <JFo> bryceh, yessir
[17:25] <Keybuk> bryceh: since you're here
[17:25] <bryceh> JFo oh you found it
[17:25] <JFo> heh
[17:25] <Keybuk> and I happen to have that exact same card
[17:25] <bryceh> wait no
[17:25] <Keybuk> and are having issues with it
[17:25] <Keybuk> (which is how we got onto the whole thing in the first place)
[17:25] <bryceh> yeah we need to find where in the kernel the blacklist lives now
[17:25] <Keybuk> how would I find out why modesetting is crap
[17:25] <apw> modesetting blacklist is in my tree only as all of the lists are empty
[17:26] <smb> Keybuk, For that "working mostly" here. Do you think there could be a boot race on the stupid macintosh mouse emulation device?
[17:26] <bryceh> Keybuk, because nVidia does not release their documentation?
[17:26] <JFo> heh
[17:27] <Keybuk> bryceh: no, I mean how to debug it or improve it
[17:27] <Keybuk> this laptop just gets crap on the screen if modeset is on
[17:27] <Keybuk> smb: can't see why - X does hotplug of input devices now
[17:27] <Keybuk> you can rip out that kernel drive and plug it back later, and X will deal
[17:28] <smb> Keybuk, (EE) PreInit returned NULL for ""Macintosh mouse button emulation""
[17:28] <smb> Just because that is the error on failures
[17:28] <bryceh> Keybuk, bug#?  Did you take a photo of the crap?
[17:28] <Keybuk> smb: that's a bryce bug
[17:29] <Keybuk> bryceh: I don't have a bug# - is there a different set of nouveau drivers I can try
[17:29] <Keybuk> what package should I file a bug on?
[17:29] <bryceh> Keybuk, xserver-xorg-video-nouveau
[17:29] <bryceh> RAOF is the man with the plan for nouveau and can follow up from there
[17:30] <bryceh> but general X bug rules apply...  ubuntu-bug xserver-xorg-video-nouveau, and attach a photo showing the corruption
[17:30] <Keybuk> ok
[17:30] <Keybuk> what about trying later drivers, is that possible?
[17:30] <bryceh> if the system is frozen too, usually a gpu dump is needed but I don't know how to collect that on nouveau
[17:31] <Keybuk> system seems mostly fine
[17:31] <bryceh> Keybuk, well what you need is probably kernel stuff
[17:31] <bryceh> Keybuk, so running mainline might make sense
[17:31] <Keybuk> xorg-edgers won't help then?
[17:32] <bryceh> no, it's a kms driver and so almost certainly a bug in the kernel side of things
[17:32] <Keybuk> that makes sense actually
[17:32] <Keybuk> since this doesn't work for plymouth either
[17:32] <bryceh> I mean, I don't know exactly what the issue is, "crap" is insufficiently descriptive
[17:32] <Keybuk> err, just crap
[17:32] <Keybuk> whatever was at that particular memory address
[17:32] <Keybuk> changes a bit if you move the mouse or try and VT switch
[17:32] <Keybuk> but just crap :p
[17:33] <bryceh> Keybuk, all I can think of is you must have a feces flinging monkey as a pet or something
[17:33] <Keybuk> lol
[17:34] <Keybuk> if said monkey threw pixels at the screen, you'd have what I see
[17:34] <bryceh> another thing that can be done is to force it to use fbdev via your xorg.conf
[17:35] <Keybuk> won't help
[17:35] <bryceh> if that's still buggy then that points the finger more strongly at kms issues
[17:35] <Keybuk> even fbcon has the same crap
[17:35] <Keybuk> yeah, I suspect this is entirely kernel side
[17:35] <bryceh> ok then :-)
[17:35] <bryceh> yeah xorg-edgers would be of no help then
[17:36] <bryceh> Keybuk, and you tested and found that the issue goes away if nouveau.modeset=0 ?
[17:36] <Keybuk> so when you boot with nouveau.modeset=0, what driver gets used?
[17:36] <Keybuk> yes
[17:37] <bryceh> that turns off kms.  -nv would be used in this case
[17:37] <Keybuk> ah right
[17:37] <bryceh> or in theory it would be -nv.  It might go to -vesa.  Check Xorg.0.log
[17:37] <bryceh> btw did you mention if X hung as well when getting the corruption?
[17:38] <Keybuk> vesa by the looks of it
[17:38] <Keybuk> hard to tell whether X is hung or not
[17:39] <bryceh> oh, well if you can get a photo of the screen, it really does help.  the developers can discern where in memory the fault is happening by the style of corruption and length of lines (if any)
[17:39] <Keybuk> filed bug #539730 for you
[17:39] <ubot3> Malone bug 539730 in xserver-xorg-video-nouveau "Nothing useful on screen.  Dell Latitude D620.  nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]" [Undecided,New] https://launchpad.net/bugs/539730
[17:39] <Keybuk> it has a photo
[17:39] <bryceh> great
[17:39] <manjo> ogasawara, can I use arsenal scripts to give me a list of all the suspend/resume bugs opened in the last 2 weeks ? 
[17:40] <Keybuk> stupid observation
[17:40] <Keybuk> but when plymouth is running, the screen is differently distored
[17:40] <Keybuk> it almost looks like it might be sideways
[17:40] <Keybuk> like that photo, if you imagine that the strange white bar is the top and bottom panels
[17:40] <ogasawara> manjo: I don't think date based searches are available, you'd have to sort of brute force it checking the date created field
[17:41] <Keybuk> when I render to the fb with plymouth, I get a blotch of white, near the left of the screen
[17:41] <Keybuk> which could almost be the logo, screwed up
[17:41] <manjo> ogasawara, in arsenal/kernel/contrib/ which script can I use to do that ? 
[17:41] <Keybuk> maybe I'll add that photo to the bug
[17:41] <smb> bryceh, Just a quick check, do these sound like you seen those before?
[17:41] <smb> (EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed (/usr/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)
[17:41] <smb> (EE) AIGLX: reverting to software rendering
[17:41] <smb> (EE) PreInit returned NULL for ""PS/2 Logitech Mouse""
[17:41] <smb> (EE) PreInit returned NULL for ""Macintosh mouse button emulation""
[17:42] <bryceh> smb, yeah I've seen those lots and lots
[17:42] <ogasawara> manjo: but you can get a rough idea if you just search bugs tagged suspend and resume and sort by newest first
[17:42] <bryceh> smb, I suspect they're innocuous.  I see them in systems that are otherwise functioning fine.
[17:42] <ogasawara> manjo: you don't exactly need a launchpad lib script
[17:43] <bryceh> smb, but I don't know for certain.  If they're innocuous it might make sense to suppress them to avoid confusion but I've not had time to look into it
[17:43] <smb> bryceh, Hm, ok. Probably I should check the working case then. It seems I get X not starting in some cases
[17:43] <bryceh> Keybuk, ok looking at the photo it sort of looks like just a modeline construction bug
[17:43] <JFo> pgraner, when you get a sec, who was the Launchpad guy (Malone) that you and I talked about?
[17:43] <cnd> what do I need to do to make a karmic linux deb? I've run fdr binary-generic, but it stopped after building everything (it didn't do any packaging)
[17:44] <Keybuk> bryceh: but this affected fb too
[17:44] <bryceh> Keybuk, I've got a nouveau kms system here with a similar problem (different result on screen - the picture cycles like vertical hold is broken)
[17:44] <bryceh> Keybuk, but exactly
[17:45] <bryceh> Keybuk, KMS is what constructs modelines now, so the algorithm may be buggy
[17:45] <bryceh> Keybuk, when they move code into the kernel they've had a tendency to rewrite the modeline construction logic (guess it needed a cleanup or something) and it's not quite the same as with UMS
[17:45] <bryceh> this is just a guess though... but we ran into a spate of these kinds of bugs with -intel
[17:46] <bryceh> a common situation is typically its something like it doesn't quite grok the monitor's edid so enters a fallback logic case, which differs in the kms implementation vs the ums implementation
[17:47] <ogasawara> manjo: if you're really wanting to script it, it doesn't look like arsenal/contrib/linux has any good examples for what you're wanting, better to just use the apidoc - https://launchpad.net/+apidoc/
[17:47] <Keybuk> http://launchpadlibrarian.net/41045879/photo.jpg
[17:47] <Keybuk> that's what plymouth gets on the screen
[17:47] <JFo> wow
[17:47] <JFo> that is new and exciting Keybuk 
[17:48] <manjo> ogasawara, looking .. I was using LP "brute force find me latest bugs" method... thought arsenal was more sophisticated search 
[17:49] <bryceh> Keybuk, interesting to see you're using -pae for the kernel...  I've seen several other bug reports from people with -pae
[17:50] <smb> bryceh, Ok, the EE's are in there all the time. The only difference in non-working seems to be a "(II) NOVEAU(0): NVLeaveVT is called". And strangely I just had a "enter drops you out of X to gdm" but splash is disabled...
[17:51] <bryceh> (II) NOUVEAU(0): Manufacturer: LPL  Model: e0  Serial#: 0
[17:51] <bryceh> interesting, we had a number of quirks for LPL's
[17:53] <bryceh> smb, NVLeaveVT sounds like it could be shutting off the vt.  Does vt switching bring it back?
[17:54] <Keybuk> I can try not using PAE too if that helps
[17:54] <smb> bryceh, Forgot to try that. Let me try to let it fail again
[17:55] <bryceh> Keybuk, well it could help isolate if it is unique to -pae code
[17:55] <bryceh> like if there were differences in the drm between the two kernels that might be useful to know
[17:55] <Keybuk> sure
[17:55] <Keybuk> btw, wasn't there supposed to be some kind of backports module package installed?
[17:57] <bryceh> Keybuk, we ended up bagging that and just pulled all the new drm into the lucid kernel
[17:57] <Keybuk> is it still called lbm-nouveau though?
[17:57] <bryceh> Keybuk, which had the blogs all aflutter
[17:59] <bryceh> no, afaik there should be no lbm-nouveau bits left.
[17:59] <Keybuk> so I can drop those patches to support that name? ;p
[17:59] <bryceh> Keybuk, check with RAOF on that
[18:12] <bryceh> Keybuk, with -vesa loaded can you run `xrandr --verbose` and attach to the bug report?
[18:13] <Keybuk> sure, just going to try two other kernels as well
[18:13] <Keybuk> they're installing atm
[18:13] <Keybuk> but will reboot to non-pae
[18:13] <Keybuk> then to pae with vesa
[18:13] <Keybuk> then to mainline
[18:18] <bryceh> hmm
[18:19] <bryceh> apw, is there a better place to look for a kernel log with details about mode selection?
[18:19] <apw> than dmesg ?
[18:19] <bryceh> apw, we're collecting dmesg which has a few lines from the drm code but nothing about modeselection (at least not in keybuk's case)
[18:21] <apw> bryceh, ca
[18:21] <apw> can't say i have looked for that info anywhere lese
[18:21] <bryceh> also is there some way to force the modeline selection like we used to do in xorg.conf?
[18:21] <apw> i wonder if it is expsed on sysfs
[18:22] <apw> bryceh, i think we asked you that, and to my knowledge there is not
[18:22] <apw> which seems like a major fook up to me
[18:22] <apw> didn't you suggest where it might be added
[18:22] <bryceh> yeah
[18:22] <bryceh> hrmble
[18:23] <Keybuk> bryceh: xrandr --verbose added to debug
[18:23] <bryceh> I like how upstream rolls out code with no provisions for working around problems.  "Lalala I live in a perfect world"
[18:24] <apw> bryceh, you can work round it using xrandr
[18:24] <apw> as in you can add modes and then select them using that
[18:24] <apw> i doubt that is much use though
[18:24] <bryceh> Keybuk, Oho!
[18:24] <bryceh> 0mm x 0mm
[18:25] <bryceh> but that's weird, Xorg.0.log definitely sees the dimensions properly
[18:25] <bryceh> Keybuk, can you run `get-edid | parse-edid` (from the read-edid package) and attach that
[18:26] <Keybuk> in -vesa again?
[18:26] <mjg59> My recollection is that the edid block in -vesa doesn't actually get hooked up to randr
[18:26] <apw> bryceh, so i think there is support in there for adding basic modes ... if no edid is found we add 1024x768 for instance.  but the interface i've seen doesn't have the other numbers, the frequency ranges ... so not sure if that is going to do the trick even if we exposed it
[18:26] <tgardner> cnd, what're you thinking about bug #513848? I just can't see that it looks like a bug.
[18:26] <ubot3> Malone bug 513848 in linux "[karmic] CPU load not being reported accurately" [Low,New] https://launchpad.net/bugs/513848
[18:26] <Keybuk> could I run get-edid | parse-edid from the nouveau side?
[18:26] <Keybuk> I can ssh in ;)
[18:27] <bryceh> mjg59, ah that explains that
[18:27] <bryceh> Keybuk, yeah read-edid seems to work even if X is not running
[18:28] <Keybuk> bryceh: have pasted to bug
[18:28] <Keybuk> it has errorz
[18:28] <Keybuk> The EDID data should not be trusted as the VBE call failed
[18:28] <Keybuk> Error: output block unchanged
[18:28] <bryceh> but it can give different results from what X sees... which can be good or bad
[18:28] <bryceh> mm
[18:28] <bryceh> Keybuk, this was run as root?
[18:30] <Keybuk> bryceh: yes
[18:34] <bryceh> apw, any chance the kernel provides a dump of EDID in sysfs?
[18:34] <bryceh> man I suck at debugging in this new kms world
[18:37] <apw> bryceh, me too
[18:38] <apw> bryceh, /sys/class/drm has lots of fun in it
[18:38] <apw> including the edid for each port
[18:38] <bryceh> ooh
[18:38] <apw> apw@dm$ cat /sys/class/drm/card0-LVDS-1/modes
[18:38] <apw> 1920x1200
[18:39] <apw> and on my external vga port it has all the possible modes
[18:39] <bryceh> ok so the binary edid is there
[18:40] <bryceh> now how do we turn that into something we can read...
[18:40] <apw> there is a program isn't there?
[18:40] <apw> one we use to get them from the raw device
[18:40] <apw> bet it can read them
[18:40] <Keybuk> it can
[18:41]  * apw installs something to see
[18:42] <apw> apw@dm$ parse-edid </sys/class/drm/card0-VGA-1/edid
[18:42] <apw> parse-edid: parse-edid version 2.0.0
[18:42] <apw> parse-edid: EDID checksum passed.
[18:42] <apw> bryceh, ^^ and lots and lots of poop
[18:43] <apw> in a nice monitor section
[18:43] <Keybuk> pasted what I see to bug #539730
[18:43] <ubot3> Malone bug 539730 in xserver-xorg-video-nouveau "[G72M] Screen corruption when using KMS.  Dell Latitude D620 / Quadro NVS 110M/GeForce Go 7300" [Undecided,New] https://launchpad.net/bugs/539730
[18:43] <bryceh> heh I was just about to paste that myself ;-)
[18:43] <bryceh> Keybuk, great
[18:43] <apw> apw@dm$ cat modes
[18:43] <apw> 1280x1024
[18:43] <apw> 1280x1024
[18:43] <apw> 1024x768
[18:43] <apw> 1024x768
[18:43] <apw> 1024x768
[18:43] <apw>  
[18:43] <apw> [...]
[18:44] <apw> i note that there are more than one of each and no explanation as to why ... presume other parameters changing which arn't shown
[18:44] <Keybuk> mainline kernel DOES NOT WORK at all! :p
[18:44] <tgardner> sbeattie, are you happy with the resolution of bug #454827? the confile states 'Conflicts: hotplug (<< 0.0.20040105-1), linux-image-2.6.31-21-server' for -virtual.
[18:44] <ubot3> Malone bug 454827 in linux "linux-image-2.6.31-14-server and linux-image-2.6.31-14-virtual don't list a conflict with each other, but both provide vmlinuz-server on amd64" [Medium,In progress] https://launchpad.net/bugs/454827
[18:44] <Keybuk> mmm PANIC
[18:44] <tgardner> confile --> debian/control
[18:44] <apw> with lucid userspace?
[18:45] <smb> bryceh, Damn, that took a while to get it again. Yes, switching terminals brings up X. And then enter drops out of it to gdm. (I thought that was related to plymouth)
[18:46] <Keybuk> apw: yes
[18:46] <Keybuk> apw: I don't think I'm even reaching userspace
[18:46] <apw> nice, whats the panic
[18:46] <Keybuk> somewhere under do_initcalls
[18:46] <Keybuk> the panic is > 25 lines
[18:48] <smb> apw, Just on the positive side, up to now I had no blank-out in i915 until now. But I try to give it a bit more work.
[18:48] <apw> smb, is that with powersave = ?
[18:48] <smb> apw, powersave = 0
[18:48] <Keybuk> apw: just mailed it you
[18:50] <bryceh> smb, enter->crash does sound like the standard plymouth crash, but I thought that was fixed
[18:50] <Keybuk> hah
[18:50] <Keybuk> mainline kernels don't have nouveau anyway, do they? :p
[18:51] <bryceh> mainline 2.6.33 does
[18:51] <bryceh> not .32
[18:51] <smb> bryceh, Right. And I boot without 'splash' anyway
[18:52] <Keybuk> ah
[18:52] <Keybuk> 34 doesn't
[18:52] <mjg59> Keybuk: Does
[18:53] <mjg59> I mean, *your* mainline kernels might not
[18:53] <Keybuk> I blame apw
[18:53] <Keybuk> he's probably using the edgy kernel config or something
[18:53] <apw> what now?  /me self flagilates
[18:53] <apw> yes the mainline kernels are all poop as they are karmic kernels
[18:53] <apw> as in built for karmic.  i am testing the fixes to allow us to generate them for
[18:54] <apw> multiple releases right now ... indeed the first -lucid one was done today
[18:54] <apw> but until we get the perf patches reviewed and into the archive they don't build cause of perf
[18:54] <apw> so we still don't have them ... /me hopes smb will review those linux-tools patches 
[18:55] <smb> apw, More review. *sigh*
[18:56] <apw> smb sorry man, and it debian rules changes ... always popular
[18:56] <sbeattie> tgardner: #454827> yes, that would be the resolution I'd like to see on amd64 
[18:56] <smb> apw, But I think for mainline .32 kernel they are always without drm .33 because they are mainline
[18:56] <apw> right
[18:56]  * Keybuk wonders how long it'd take to get to South London so he can punch apw in the face
[18:56] <Keybuk> :D
[18:56] <apw> its the .33 kernels hwich build with the wrong ones
[18:57] <tgardner> sbeattie, I think that _is_ the current control file content in karmic
[18:57]  * apw thanks Keybuk for his concern
[18:57] <Keybuk> apw: so do you have a .34-rc1 anywhere with the lucid config? :p
[18:57] <Keybuk> or a .33 even
[18:57] <apw> Keybuk, not at the moment
[18:57] <apw> as lucid builds don't work on mainlne ... they will shortly i ho[e
[18:57]  * smb goes loking for those perf changes
[18:57] <sbeattie> tgardner: has -21- been published anywhere? I don't see it.
[18:57] <apw> hope, i need to pull out perf ... and those patches are the ones
[18:58] <JFo> well, that was interesting. Evolution just tried to fry my machine
[18:58] <JFo> my load average was 15
[18:58] <JFo> looks like it got hung up trying to send a message
[18:58] <tgardner> sbeattie, I'm thinking its been there much longer then -21. Still looking.
[18:59] <smb> tgardner, Are you talking about a Karmic abi number=
[18:59] <smb> ?
[19:00] <tgardner> smb, no, the conflicts statement in the -virtual package definition
[19:00] <sbeattie> tgardner: it'snot the case for -19 or -20's amd64 image.
[19:00] <sbeattie> (it's not, even)
[19:00] <tgardner> sbeattie, its only in -virtual
[19:00]  * smb shuts off then
[19:00] <tgardner> they don't mutually conflict
[19:00] <sbeattie> tgardner: sorry, yes, that's what I mean.
[19:01] <Keybuk> apw: so no kernel I can try to see whether nouveau issues are fixed upstream>
[19:02] <sbeattie> tgardner: http://paste.ubuntu.com/396310/
[19:02] <sbeattie> (output from apt-cache show linux-image-2.6.31-{19,20}-virtual)
[19:02] <tgardner> sbeattie, wtf? amd64 conflicts with linux-image-2.6.31-19-generic-pae
[19:02] <tgardner> looks like bogus logic in the control file construction
[19:03] <sbeattie> tgardner: hence the bug report.
[19:03] <tgardner> hmm, I'll keep digging. what about the complainers in the LP report that don't tlike the conflicts? Do I just tell them tough?
[19:05] <smb> How useful, the battery indicator blinks away when I unplug AC...
[19:09] <sbeattie> tgardner: yeah, the packages will attempt to install the same vmlinuz file and thus apt-get will break.
[19:10] <sbeattie> so there needs to be a conflict there.
[19:12] <tgardner> sbeattie, right, the logic implies that there _should_ be a conflicts, but its putting in the wrong one and I'm not quite sure why.
[19:14] <tgardner> I'll get it figured out in a bit
[19:35] <manjo> apw, I am running a bunch on wgets downloading attachements from a 50 or so bugs, and causes my system to slow down a lot, xorg uses 90% of my cpu 
[19:36] <manjo> apw, bryceh any idea why ? 
[19:40] <bryceh> manjo, nope
[19:41] <manjo> bryceh, its has started to kill some processes like firefox etc randomly 
[19:43] <manjo> bryceh, after my script is one ... xorg takes 10-30% where as it was taking 90-100% of my cpu earlier, making switching workspace and refreshing windows very slow. 
[19:43] <manjo> strange 
[19:44] <bryceh> manjo, high X cpu issues are hardly ever actually a bug in X
[19:44] <bryceh> the X server is a server, so it is usually client process which drive X cpu load
[19:44] <bryceh> (see Ubuntu-X wiki for detailed explanation + troubleshooting advice)
[19:45] <manjo> bryceh, wow I have a ton of  [19:45] <manjo> apw, ^
[19:46] <manjo> bryceh, looks like my wireless driver was crapping out 
[19:46] <manjo> [   19.898140] --> Error 2 opening /etc/Wireless/RT2860STA/RT2860STA.dat
[19:46] <manjo> followed by the message above 
[19:48] <tgardner> manjo, that looks like a staging driver.
[19:48] <manjo> tgardner, yes
[19:49] <tgardner> manjo, perhaps you should figure out if its already fixed upstream, and send a patch if not.
[19:50] <manjo> tgardner, I am on it 
[19:50] <tgardner> manjo, I assume you suspect this is the reason for your high load average?
[19:50] <manjo> tgardner, yes I that is my guess...
[19:50] <manjo> but not sure why X was at 100+ %
[19:51] <manjo> tgardner, it was really really crappy slowness I experienced
[19:51] <manjo> it was killing any apps that I had opened like the 5 firefox sessions I had 
[19:51] <tgardner> not too surprising
[19:52] <manjo> switching workspace took for ever 
[19:52] <manjo> and I am on a Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
[19:52] <manjo> tgardner, ^
[19:53] <manjo> it was dog bleeping slow 
[19:53] <tgardner> mayhap you should use a different wireless gizmo
[19:53] <manjo> :) heh
[19:54] <manjo> tgardner, /etc/Wireless/RT2860STA/RT2860STA.dat is that fw ? 
[19:54] <tgardner> manjo, no, IIRC one of the RT drivers was trying to read a settings file
[19:54] <manjo> there is no such  file 
[19:55] <tgardner> its pure bogosity
[20:04] <manjo> smb, around ? 
[20:05] <gnarl> no he is off
[20:47] <manjo> JFo, I want to add a common comment to a list of bugs .. how do I do that ? 
[20:56] <JFo> add it as you process through them individually. I know of no way to do it in bulk either via LPlib nor the web interface
[20:56] <ogasawara> manjo: I've got a stock reply script, just a sec
[20:57] <manjo> ogasawara, this is a monkey script ? 
[20:57] <ogasawara> manjo: arsenal
[20:57] <ogasawara> manjo: look at arsenal/contrib/linux/stock-reply-bugs-with-patches.py for an example
[20:59] <manjo> ogasawara, got it... does it take a listfile or just list the bugs on command line ? 
[20:59] <manjo> ogasawara, sorry I am py ignorant 
[21:00] <bjf> manjo, I can put something together for you pretty quick (i think)
[21:00] <manjo> bjf, cool
[21:01] <bjf> manjo, let me look at the script ogasawara pointed you at, I've got it here
[21:01] <manjo> bjf, stand alone script ? not sure how to run the script thro arsenal framework
[21:01] <manjo> ogasawara, ^
[21:02] <manjo> bjf, we got no wiki magic on arsenal currently 
[21:02] <bjf> manjo, np, I use the arsenal_lib, I'll get you setup
[21:02] <ogasawara> manjo: you'll likely want to tweak the script to just run without any params
[21:02]  * manjo notes that he MUST learn py
[21:02]  * manjo moves it to the top if his list 
[21:46] <Q-FUNK> hm. is there some magic trick to be able to run lilo inside a chroot that's on a compact flash?
[21:47] <Q-FUNK> I was revisting https://bugs.launchpad.net/ubuntu/+source/linux/+bug/241307 and tried installing a new kernel.  it fails, so now I have to restore the old kernel.
[21:47] <ubot3> Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] 
[21:48] <Q-FUNK> the only problem is, this is an antiquated system with a non-BIOS that only boots off a deprecated version of lilo.
[21:48] <Q-FUNK> now, I would somehow need to be able to run lilo from the outside
[21:49] <mjg59> lilo -R
[21:49] <mjg59> Wait, no, not that one
[21:49] <mjg59> lilo -r
[21:49] <mjg59> -R is remember, -r is root
[21:55] <bjf> manjo, still there?
[21:57] <Q-FUNK> ah, yes.  that did the trick
[21:57] <Q-FUNK> mjg59: thanks
[21:57] <Q-FUNK> and now for something completely different:  how would I disable IDE DMA on kernel 2.6.23 ?
[21:58] <Q-FUNK> I thoguht that nodma=ide0 would be it, but it doesn't seem to have any effect.
[22:07] <Keybuk> RAOF: damnit, can't find quiet channel
[22:07] <Keybuk> 'twas the night before beta ...
[22:07] <Keybuk> so right
[22:07] <Keybuk> lbm-nouveau
[22:07] <Keybuk> what is that used for today? what will it be used for once lucid is released?
[22:08] <RAOF> lbm-nouveau is not used in Lucid at all.
[22:10] <RAOF> lbm-nouveau *is* used in the testing PPA, which is there to allow users to easily test more current nouveau when they run into bugs.
[22:11] <RAOF> So, it's slightly convenient to have lbm-nouveau patches in Lucid, but ask for them to be dropped and I'd be happy to do so.
[22:12] <Keybuk> right
[22:12] <Keybuk> but we'll want to use that PPA even once lucid is released
[22:12] <Keybuk> and once m is current right?
[22:12] <RAOF> Yes.
[22:13] <RAOF> But it wouldn't be hard to drop lbm from the PPA and instead upload a full kernel with a different drm backported.
[22:14] <Keybuk> sure, sure
[22:14] <Keybuk> but it's harder than what you're doing now, right?
[22:14] <Keybuk> I was only tidying up, and noticed we now put nouveau in the kernel
[22:14] <Keybuk> so wondered whether the patch was still needed
[22:14] <Keybuk> if we're still using lbm-nouveau, then I'll keep the patch :)
[22:15] <RAOF> Ok.  Yeah, it does make it a little easier to just build lbm-nouveau.
[22:15] <Keybuk> so let's keep it :D
[22:15] <Keybuk> so, other question on that PPA
[22:15] <Keybuk> if I'm having issues with nouveau on a particular card, does that contain an updated kernel with updated KMS bits?
[22:16] <RAOF> Yes.  lbm-nouveau contains the updated kernel KMS bits.
[22:17] <Keybuk> ok
[22:17] <Keybuk> and those are > lucid right now?
[22:17] <Keybuk> also *grr* our kernel doesn't have mmiotrace enabled
[22:18] <RAOF> Yup.  It adds some overhead, even when not being used.
[22:18] <Keybuk> it does?  I thought it was enabled/disabled through the tracing infrastructure now
[22:18] <RAOF> They are > lucid right now; they're current as of a couple of days ago.
[22:18] <Keybuk> don't suppose you have an mmiotrace-enabled kernel nearby?
[22:19] <RAOF> I don't; that's something else I want in a PPA.
[22:19] <Keybuk> bleh
[22:19] <Keybuk> ok
[22:19]  * Keybuk opens a window
[22:20] <RAOF> I did investigate whether to request we turn on mmiotrace in the default kernel; upstream said that there was still some overhead involved, so I dropped it.
[22:22] <Keybuk> Mmiotrace feature is compiled in by the CONFIG_MMIOTRACE option. Tracing is
[22:22] <Keybuk>   25 disabled by default, so it is safe to have this set to yes.
[22:22] <Keybuk> from mmiotrace.txt in the kernel source
[22:22] <Keybuk> but anyhoo
[22:22] <Keybuk> my room is too warm anyway
[22:39] <Keybuk> ok
[22:39] <Keybuk> how the hell do I disable kernel flavours now ?!
[22:41] <Keybuk> ah, right
[22:41] <Keybuk> debian.master
[22:58] <Keybuk> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
[22:58] <Keybuk> now I sha'n't forget every damned time