[00:10] <saintly> hello hello, having vesa driver issues..
[00:10] <saintly> im trying to run Compiz, when i get this statement in the sytem check:
[00:11] <saintly>  Distribution:          Ubuntu 10.10
[00:11] <saintly>  Desktop environment:   Xfce
[00:11] <saintly>  Graphics chip:         Intel Corporation 82852/855GM Integrated Graphics Device (rev 01)
[00:11] <saintly>  Driver in use:         vesa
[00:11] <saintly>  Rendering method:      AIGLX
[00:11] <saintly> Checking if it's possible to run Compiz on your system...  [SKIP]
[00:11] <saintly>  Checking for hardware/setup problems...           [SKIP]
[00:11] <saintly> At least one check had to be skipped:
[00:11] <saintly>  Error: vesa driver in use 
[00:11] <saintly> Would you like to know more? (Y/n) y
[00:11] <saintly>  The vesa driver is not capable of running Compiz, you need to install
[00:11] <saintly>  the proper driver for your graphics card.
[00:15] <RAOF> saintly: I'd guess you've turned off kernel modesetting.
[00:16] <RAOF> Also, your we don't support compiz on your GPU, because if you try to turn it on you'll end up with seemingly-random X hangs.
[00:21] <saintly> so no luck for me eh
[00:50] <Sarvatt> on day evolution won't suck! only manage to get one email out before outgoing mail stops sending :)
[00:53] <RAOF> One day there'll be a mail client that doesn't suck.
[00:54] <Sarvatt> yeah its called gmail :)
[00:54] <RAOF> That handles threading *really* badly.
[00:54] <Sarvatt> ?!
[00:54] <JanC> Sarvatt: lol, Gmail is the worst mail client I ever used  :P
[00:54] <Sarvatt> i love how it handles threading, all my mailing lists are through gmail
[00:55] <JanC> even outlook/exchange is more standards-compliant  :P
[00:56] <JanC> (well, can be beat into being more standards-compliant, at least)
[00:56] <Sarvatt> guess it's back to thunderbird I go, wanted to give evolution a shot on the new PC since I never used it before
[00:57] <JanC> outside of crashes every 3-6 days, Evolution works fine here
[00:57] <RAOF> gmail handles *linear* threading brilliantly.  What it *doesn't* handle is forks in a thread.
[00:57] <Sarvatt> hmm hasn't crashed yet, but I have to close/reopen it to send email every darn day
[00:58] <Sarvatt> ahh ok I see what you mean, I just like how it puts the threads in every label if someone responds on another list
[00:58] <JanC> actually, Evolution crashes only every 1-2 weeks in maverick now
[00:59] <JanC> and I guess most peopel don't keep their mail client running for that long  ;)
[00:59] <Sarvatt> hell I wish I could have more than 3-4 days uptime on natty :)
[00:59] <JanC> I don't read mail on natty  ;)
[01:01] <JanC> Sarvatt: gmail hides your own answers to a list though, which really sucks...
[01:02] <JanC> especially when you are a list admin and have to explain that erratic behaviour to new contributors over and over again...
[01:02] <JanC> when people resend (and re-resend, etc.) their mails because they don't see them arrive
[02:23] <Sarvatt> bryceh: hmm, why hasn't nvidia-graphics-drivers-96 moved to -updates yet?
[02:23] <Sarvatt> (in maverick)
[02:23] <Sarvatt> looking at the patch list and saw that in there, its sitting in proposed
[02:23] <bryceh> Sarvatt, dunno, I think it needs promoted by pitti
[02:23] <bryceh> he may be on vacation
[02:24] <bryceh> Sarvatt, seb128 may be his backup
[02:24] <Sarvatt> i think it needs changes to other packages since it was blacklisted anyway, will ask tseliot
[15:39] <Sarvatt> hmm https://bugs.launchpad.net/ubuntu/+source/desktop-file-utils/+bug/592671 appears to be rearing its ugly head with the humble bundle games
[15:39] <ubot4> Launchpad bug 592671 in desktop-file-utils (Ubuntu) "application cache update (affects: 1) (heat: 19)" [Wishlist,New]
[16:26] <apw> Sarvatt, heard of any blank screen issues with Natty with recent x changes?  we seem to have a machine (marjo's) which has gained new bad behaviour back to old previously working kernels ... any suggestions as to which package to blame ?
[16:27] <Sarvatt> how recent? there haven't been any X changes in almost a month
[16:28] <Sarvatt> can ya point me at any channel with the info in the scrollback?
[16:28] <apw> Sarvatt, not X then, ... i would say his issue is about a week old, it came with the -10 kernel but booting back to -9 does not work correctly either any more
[16:28] <apw> Sarvatt, there is none, as he continuiously uses private messages for some reason (most annoying)
[16:28] <apw> Sarvatt, there is a bug however
[16:28] <apw> bug #693093
[16:28] <ubot4> Launchpad bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/693093
[16:28] <Sarvatt> oh, thanks, looking
[16:29] <Sarvatt> go figure it's against linux so wont have the informative logs in it :)
[16:29] <apw> Sarvatt, with the black screen issue on -10 he now gets what he describes as 'low resolution mode' on all older kernels too
[16:29] <apw> which sounds very strange indeed to me
[16:31] <apw> Sarvatt, indeed, but i did get the Xorg.log added
[16:31] <Sarvatt> vesafb picking 1024x768 on a 1024x600 panel, check..
[16:34] <Sarvatt> not seeing anything really obvious so far outside of that, slow at reading logs sorry :)
[16:35] <apw> Sarvatt, i know, to my eye X is happy so i'd expect a display
[16:35] <apw> he claims the backlight is visible
[16:36]  * apw tries to summon marjo
[16:38] <marjo_> apw: i'm here
[16:38] <apw> Sarvatt, the victim himself
[16:38] <apw> marjo_, you are able to ssh into this machine arn't you
[16:38] <Sarvatt> marjo_: can you try booting with vesafb.sucks=1 and see if it's any different?
[16:38] <apw> Sarvatt, is that a technical term
[16:39] <marjo_> apw: able to ssh in
[16:39] <Sarvatt> invalid module parameter stopping it from loading :)
[16:39] <apw> so foo.blacklist_me_dammit=1 would disable any module ?
[16:39] <Sarvatt> apw: yep, only way I know of to disable built in modules
[16:39] <apw> interesting
[16:40] <apw> we should define one which does the same thing ... for all modules
[16:40] <Sarvatt> blacklist=foo, but that doesn't always work
[16:40] <Sarvatt> if you have it in /etc/modules or something it'll load after the initrd is done even with blacklist=foo
[16:41] <apw> Sarvatt, do you think a drm.debug=0x4 might help us?
[16:42] <Sarvatt> i'm putting my bets on plymouth dying after the vesafb transition because it's happened so much in the past, but if not yeah
[16:42] <apw> Sarvatt, i think plymouth dies on most machines, but normally X can pick up from it and you just have more black than you wanted
[16:43] <Sarvatt> apw: i've had plymouth die at just the right time to where it gets stuck on a blank vt and can't recover giving me a black screen at boot more times than I can count
[16:44] <apw> Sarvatt, ahh not something i've met, but you do meet a lot more bust video than me
[16:44] <apw> marjo, was that a good or bad sign you logging in there
[16:46] <Sarvatt> apw: mostly it came from shoving plymouth in the initrd, it's so racy
[16:46] <marjo> Sarvatt: vesafb.sucks=1 does NOT make any diff;same result
[16:46] <marjo> Sarvatt: want me to try without vt.handoff=7 splash quiet
[16:46] <apw> marjo, is there any way you can video the boot?
[16:47] <marjo> apw: how?!
[16:47] <apw> subtle flickers etc can tell one loads about the issues
[16:47] <marjo> apw: there's really nothing to video
[16:47] <apw> marjo, i use my mobile normally
[16:47] <apw> marjo, does your grub go purple ?
[16:47] <Sarvatt> marjo: do you see the text splash or a logo? do you see the logo resize during the boot?
[16:47] <apw> Sarvatt, this is Natty (marjo right?)
[16:48] <marjo> apw: natty
[16:48] <Sarvatt> yeah I get a text splash maybe 1/10 boots
[16:48] <apw> so you should see 'bios, black with cursor (short), purple without cursor (long), plymouth maybe, black screen (short), maybe more plymouth, X
[16:49] <apw> marjo, what of that sequence do you see
[16:49] <apw> and for how long do you see each segment
[16:49] <apw> likely during the second black the backlight may go off
[16:49] <marjo> apw, Sarvatt: no logo, disk activity LED lights, drum heard, blank screen
[16:50] <apw> marjo, and before it goes black ?
[16:53] <Sarvatt> so its definitely screwed up early, sounds like vesafb isn't working for one (not that I imagine it would at 1024x768 on a 1024x600 panel)
[16:56] <apw> marjo, it is possible one of my machines is now exhibiting similar beahviour, though i am without backlight
[16:57] <Sarvatt> updating my screwed up netbook now to see if I hit it too
[16:58] <apw> something very off going on at the mo
[16:59] <marjo> apw: ack
[17:04] <Sarvatt> apw: heh, my screen dies too
[17:04] <Sarvatt> fades to white here though
[17:04] <Sarvatt> oh now it's light purple
[17:04] <apw> wtf is going on all of a sudden
[17:04] <apw> purple is normal after grub
[17:05] <Sarvatt> and then X started and its fine
[17:05] <Sarvatt> it was purple after grub, then it faded to white, then drew purple over the white
[17:05] <apw> wibble
[17:05] <marjo> Sarvatt: i don't see the "fade to white" on mine
[17:09] <apw> Sarvatt, ok whatever i have cleared after some minutes of ignoring it
[17:09] <apw> it continued to X
[17:10] <apw> and then hung ... what the helll
=== bdmurray_ is now known as bdmurray
[17:22] <Sarvatt_> jeeze, vesafb makes vt's suck, over 1 minute to get a dmesg
[17:22] <Sarvatt_> http://sarvatt.com/downloads/VID_20101222_121058.3gp
[17:27] <Sarvatt_> ah hah, thats with /lib/plymouth/renderers/drm.so moved out of the way, everything works fine using the drm renderer
[17:27] <apw> Sarvatt_, hrm
[17:27] <Sarvatt_> marjo: can you try sudo mv /lib/plymouth/renderers/frame-buffer.so{,.bak} and reboot?
[17:28] <apw> Sarvatt_, oh that kind of fade to white, thats the 'not refreshing the vram' look isn't it ?
[17:28] <apw> Sarvatt_, which kernel you got?
[17:28] <Sarvatt_> yeah
[17:28] <Sarvatt_> thats on -11
[17:29] <Sarvatt_> framebuffer renderer looks busted here
[17:29] <apw> bah
[17:29] <apw> something screwey is going on, these kernels worked last night
[17:29] <apw> and indeed my amd64 is still working
[17:30] <apw> but i am seeing wibble behaviour with 11 and 10 all of a suddent
[17:30] <apw> kernels i ahve been runnig for days
[17:32] <marjo> Sarvatt: done, rebooted and same behavior on -10
[17:32] <marjo> Sarvatt: want me to try on -11?
[17:33] <marjo> Sarvatt: trying -11 now
[17:33] <marjo> Sarvatt_ ^^^
[17:34] <Sarvatt_> marjo: thanks for trying, you want to move /lib/plymouth/renderers/frame-buffer.so.bak back to frame-buffer.so if it didnt do anything
[17:34] <Sarvatt_> apw: hope its no grub :)
[17:34] <apw> Sarvatt_, la la la cannot hear you
[17:35] <marjo> Sarvatt_ I misunderstood; i thought you said moving drm.so out of the way worked fine
[17:35] <Sarvatt_> marjo: nope moving it back worked fine, it was busted when it was using frame-buffer.so which it does some times because its racy
[17:36] <Sarvatt_> totally depends on how fast you boot as to what it uses from my experience with it
[17:37] <marjo> Sarvatt_ yikes! it's that "racy"?
[17:38] <marjo> Sarvatt_: ok moving either drm.so or frame-buffer.so out of the way results in same behavior on -10
[17:38] <marjo> Sarvatt_ so, no diff
[17:39] <Sarvatt_> struggling to see what else it could be outside of grub at this point..
[17:39] <bdmurray> bryceh: the right tag is regression-release for natty or any stable release
[17:39] <Sarvatt_> since its affecting old kernels you haven't run update-initramfs on so its not something in the initrd, and its happening early
[17:39] <apw> Sarvatt_, there is exactly no kernel drm changes from 2.6.36-rc6 -> -rc7 which is the diff between -10 and -11
[17:39] <apw> gurgle
[17:40] <marjo> Sarvatt_ here's what I've tried with no success
[17:40] <marjo> set gfxpayload=text
[17:41] <apw> and now -10 is showing the same symptoms a bit wtf
[17:41] <Sarvatt_> ah was going to ask that next, didn't help?
[17:41] <marjo> removed 'splash quiet vt.handoff=7'
[17:41] <Sarvatt_> apw: we tested the heck out of -10 yesterday for the grub thing too!
[17:41] <Sarvatt_> or was that another machine? sorry
[17:41] <marjo> Sarvatt_ in --verbose mode, last output is: "Running /scripts/init-bottom done'
[17:42] <apw> Sarvatt_, no this was the very same machine!
[17:42] <apw> Sarvatt_, thats how i know it worked ... and now .. its odd
[17:42] <apw> i want to cry
[17:42] <Sarvatt_> apw: have the old grub .debs in /var/cache/apt/archives?
[17:42] <Sarvatt_> my machine works so I can't test it
[17:43] <Sarvatt_> oh actually, if I move drm.so out of the way again I can test it, it was moved out of the way before when it was working
[17:43] <marjo> Sarvatt_ i've also tried removing "set gfxpayload=linux_gfx_mode" with no success
[17:44] <Sarvatt_> marjo: did this just start in the last day or so?
[17:45] <maxb> Is this the AOA150 thingy you asked me about testing last week, Sarvatt_ ?
[17:45] <Sarvatt_> maxb: nope that was a grub problem and got fixed in the most recent grub
[17:45] <apw> Sarvatt_, ok old grub is broken as expected on reboot, so i have the old one
[17:46] <marjo> Sarvatt_ no it started with my upgrading on 17 December 
[17:46] <maxb> Sarvatt_: ah, that must be the grub my ADSL is struggling with right now then :-)
[17:46] <Sarvatt_> apw: guess what
[17:46] <Sarvatt_> apw: your grub 20101210~verbose9 works
[17:47] <Sarvatt_> new grub 20101221 is bonkers, this may be an unrelated problem though
[17:49] <Sarvatt_> marjo: did it hang with a blinking underscore in the top left of the screen previously by any chance, or was it the same?
[17:50] <marjo> Sarvatt_ never hung w/ blinking underscore; always gets past the blinking underscore
[17:56] <apw> Sarvatt_, and you are able to boot this -11 kernel ok on you n270:
[17:56] <apw> ?
[17:56] <Sarvatt_> apw: yep, my problem is different, i only have a problem moving the plymouth drm renderer out of the way with the newer grub
[17:57] <apw> Sarvatt_, this is mad, so you can boot it and i could last night and cannot today ... this is just wibble
[17:57] <Sarvatt_> apw: maybe I shouldn't mention booting the kernel with no nx-emu works fine too :) as does stock -11 with your 20101210~verbose9 grub packages
[17:57] <apw> must be some kind of race with something something
[17:57] <marjo> Sarvatt_ FWIW here's what verbose mode tells me:
[17:58] <apw> yeah just went back to *verbose9* and it doens't work any better than the grub2 in the archive
[17:58] <marjo> Sarvatt_ init: plymouth state changed from post-start to running
[17:58] <marjo> Sarvatt_ init: Handling start event
[17:58] <Sarvatt_> apw: ah ok definitely a different problem I'm hitting then
[17:58] <marjo> Sarvatt_ drum heard; blank screen
[17:58] <Sarvatt_> hmm, wonder if plymouth:debug output would help
[18:01] <marjo> Sarvatt_ how? please advise
[18:03] <Sarvatt_> marjo: without a good boot to compare it to it probably wont be that helpful, but you can add plymouth:debug to the kernel command line in grub and a log will show up at /var/log/plymouth-debug.log
[18:07] <apw> Sarvatt_, i didn't think plymouth was in initramfs, so i don't need to regen those do i ?
[18:10] <Sarvatt_> oh whoops it is on my netbook according to lsinitramfs, maybe thats why the grub downgrade worked :)
[18:10] <Sarvatt_> shouldn't be by default unless you forced it at some point
[18:11] <apw> yeah doesn't seem to be
[18:11] <Sarvatt_> lets see if i can reproduce problems removing it
[18:12] <marjo> Sarvatt_ here's some suspicious plymouth:debug output:
[18:12] <marjo> [ply-utils.c]                               ply_open_module:Could not load module "/lib/plymouth/renderers/x11.so": /lib/plymouth/renderers/x11.so: cannot open shared object file: No such file or directory
[18:12] <marjo> ^M
[18:12] <marjo> [./plugin.c]                                create_backend:creating renderer backend for device /dev/dri/card0^M
[18:12] <marjo> [./plugin.c]                                   load_driver:Attempting to load driver 'i915'^M
[18:12] <marjo> [ply-terminal.c]                             ply_terminal_open:trying to open terminal '/dev/tty7'^M
[18:13] <Sarvatt_> http://pastebin.com/SMKx3JxY -- thats mine on a good boot
[18:13] <apw> Sarvatt_, i see we have a new udev 32 hours ago
[18:15] <marjo> Sarvatt_ ok, so your good boot has same "no such file or directory messages" as mine
[18:26] <apw> Sarvatt_, ok this looks to be something outside the kernel
[18:26] <apw> i regenerated the initramfs for my -10 kernel and not its bolloxed too
[18:26] <apw> now
[18:38] <Sarvatt_> does recovery work?
[18:51] <dijenerate> hi all
[18:52] <dijenerate> I'm running a series of systems for digital signage and already deployed machines have jaunty on them
[18:52] <dijenerate> they run intel 945gme chips on atom soc boards
[18:54] <bryceh> Sarvatt_, we ought to clean up / improve https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
[18:54] <dijenerate> we started to change some of our screens our to a custom display based Panasonic's Viera tc-p42c2x board... essentially a tv
[18:54] <dijenerate> now, 
[18:58] <dijenerate> now, we can't get any display res to work using the intel driver... 2.9.1-1ubuntu
[18:58] <dijenerate> does anyone have any suggestions that could help?
[18:58] <dijenerate> we cannot upgrade the os at this stage because of other hardware/software dependency issues
[18:58] <dijenerate> any ideas?
[18:58] <dijenerate> anyone?
[19:04] <apw> Sarvatt_, ok ... seems that the issue is that udev is borked
[19:04] <apw> Sarvatt_, and any kernel which has its initramfs rebuilt after the update gets fooked
[19:19] <Sarvatt_> apw: wow what the heck is going on, X didn't start for 216 seconds afte I removed plymouth from the initrd
[19:19] <Sarvatt_> http://pastebin.com/7VtnNJ1f
[19:19] <apw> Sarvatt_, that is the bug ... and you can confirm my finding
[19:19] <apw> Sarvatt_, boot an old kernel and then downgrade udev to the previous version
[19:20] <apw> Sarvatt_, that will re-regen your initramfs and fix you
[19:20] <Sarvatt_> i already did a update-initramfs -u -k 'all' and busted my old ones removing plymouth
[19:20] <apw> Sarvatt_, be good if you could try that as it would confirm udev is bust
[19:20] <apw> Sarvatt_, oh you may be in the poo you may need a USB stick then
[19:23] <apw> Sarvatt_, oh if you can get in over the network you are ok of course, i couldn't on mine without logining in which i couldn't do
[19:45] <apw> Sarvatt_, did you manage to downgrade udev ?
[19:45] <bryceh> bdmurray, so sounds like regression-development is being merged with regression-release?  Is that because bugs are tagged with the release name so can be distinguished that way?
[19:46] <bryceh> bdmurray, have you thought about maybe simplifying the tag to just 'regression'?
[19:46] <Sarvatt_> apw: yeah, guess I got booted? besides that fluke 216 second boot its no different
[19:46] <Sarvatt_> X up around 26 seconds in
[19:47] <apw> Sarvatt_, so downgrading udev sorted you as well?
[19:48] <Sarvatt_> i'm back to newer udev again and its fine, sorry to confuse you even more
[19:48] <apw> hrm odder
[19:48] <apw> i will try upgrading again, and see
[19:48] <Sarvatt_> last boot with the downgrade, X was up at 25 seconds in, this boot after upgrading again 26 seconds
[19:49] <bdmurray> bryceh: it was originally regression-potential but is now regression-release.  https://lists.ubuntu.com/archives/ubuntu-bugsquad/2010-October/002778.html
=== yofel_ is now known as yofel
[19:52] <Sarvatt_> well got the 216 second boot explained at least,  not used to it being silent in dmesg: Last checked:             Wed Dec 22 14:14:05 2010
[19:56] <Sarvatt_> apw: BAH wait a second here
[19:56] <Sarvatt_> [   20.810481] udev[381]: starting version 164
[19:56] <Sarvatt_> looks like i didn't upgrade again properly
[20:03] <Sarvatt_> udev 165: X up at 25 seconds, 29 seconds, 29 seconds, doesn't seem to be a problem
[20:04] <Sarvatt_> I got upstart and dbus upgrades going back to the new udev though
[20:13] <bryceh> Sarvatt_, apw, using your debugging discussions, I updated https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen a good bit
[20:15] <bryceh> Sarvatt_, apw, hopefully if others need to debug other kinds of black screen bugs they'll be able to use your approach to pin it down
[20:16] <Sarvatt_> If the kernel supports Mode Setting (KMS), it puts the video card into its preferred resolution using a frame buffer (vesafb). The framebuffer is initialized with a purple background. -- oh how I wish that was true, maybe 10 years ago when we had 4:3 monitors with native modes in the vbios :)
[20:17] <bryceh> if there already is a troubleshooting page for this kind of bug let me know so we can merge this into it; seems like these black screen boot problems are technically not X issues so this may not be the perfect place for the page
[20:17] <bryceh> (otoh people still blame X for these types of bugs so maybe it is)
[20:17] <bryceh> Sarvatt_, ok feel free to edit.  I made some guesses out of ignorance there ;-)
[20:18] <bryceh> or if you don't feel like wiki'ing just mention the corrections here and I'll make them in a bit
[20:21] <Sarvatt_> it's kind of hard because step 4 isn't exactly clear cut and depends on how fast you actually boot :) it'll start drawing to whatever is available and if the KMS fb gets loaded after it just resizes things to native from whatever it was using before
[20:22] <Sarvatt_> throwing plymouth in the initrd with gfxpayload=text I can get plymouth starting to draw before vesafb is even loaded like 1 second in so things use the text splash
[20:22]  * Sarvatt_ doesn't understand what grub is doing in the process at the moment
[20:35] <Sarvatt_> bryceh: this is going to be a novel but i'm editing it, do you realize how many possible varations in each step there are? :) plymouth picks different backends based on how many heads are plugged into the GPU on radeon for instance, cryptsetup being installed packs the gpu modules in the initrd so stuff happens earlier, and the copyfb stuff alters things
[20:38] <marjo> Sarvatt_ anything else I can try on my system, or just wait for udev fix?
[20:40]  * marjo assumes "udev is borked" is the root cause
[20:41] <Sarvatt_> marjo: the udev stuff isn't your problem most likely because it just got released yesterday, I'm out of ideas about what it could be
[20:41] <marjo> Sarvatt_ ack
[20:41] <bryceh> back
[20:41] <marjo> Sarvatt_ time to reinstall Alpha-1 on this puppy?
[20:42] <bryceh> Sarvatt_, whoa, didn't realize plymouth was trying to be so magical
[20:42] <bryceh> Sarvatt_, that's gotta be full of bugs
[20:42] <Sarvatt_> bryceh: why do you think I hate vesafb/vga16fb so much? :)
[20:42] <bryceh> heh
[20:42] <marjo> bryceh: through it's trying to be so magical, it seems to introduce "racy" conditions
[20:43] <marjo> Sarvatt_ and here it was the plymouth 2.7 change i was worrying about
[20:44] <marjo> hah!
[20:44] <bryceh> Sarvatt_, well, getting it docced a bit might help in diagnosing the problems, but it's probably ok if it's not exhaustive of all the options.  Stuff changes in the code faster than we can update docs typically, so a bit of generalizing may be worthwhile
[20:45] <bryceh> marjo, during boot is the worst place to have race conditions ;-)
[20:45] <marjo> s/plymouth/python
[20:45] <bryceh> I suppose it's that way in order to do fast boot
[20:45] <marjo> bryceh: ack
[20:46] <Sarvatt_> apw: were you able to reproduce it in that you were stuck on a black screen even after X started the same as marjo?
[20:49] <Sarvatt_> or was it some other issue?
[21:00] <Sarvatt_> it really looks like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/605667 to me, but vesafb.sucks=1 as well as GRUB_GFXPAYLOAD_LINUX=text should fix it if so an it's not.
[21:01] <ubot4> Launchpad bug 605667 in linux (Ubuntu) "Kernel Oops - unable to handle kernel NULL pointer dereference; RIP: 0010:[<ffffffff81365730>] [<ffffffff81365730>] fb_release+0x30/0x70 (affects: 2) (heat: 28)" [Medium,In progress]
[21:02] <Sarvatt_> (that was from last time we had gfxpayload=keep enabled along with vga16fb)
[21:13] <Sarvatt_> marjo: funny enough, windows 7 wont work on your eee without a bios upgrade because of that 1024x768 problem, it gets stuck with a black screen after the windows splash because it tries to use that invalid mode
[21:13] <Sarvatt_> they fixed it in bios 0602
[21:15] <Sarvatt_> not saying its the same problem but might be worth upgrading it anyway, i'm not sure you'll ever see a splash the way things are set up now with vesafb unless its later on from the drm renderer which can use 1024x600
[21:15] <marjo> Sarvatt_ but that doesn't explain why this system used to work, does it?
[21:17] <marjo> Sarvatt_ I'm tempted to install natty-Alpha1 just to convince myself; what do you think? i seem to be stuck anyway
[21:18] <Sarvatt_> nah your xorg log shows it using 1024x600, struggling to work out how it could break down like that
[21:18] <Sarvatt_> marjo: wait, when you say natty updates on december 17th broke it, do you mean you upgraded from maverick on december 17th?
[21:18] <marjo> Sarvatt_ no, i upgraded natty->natty
[21:19] <Sarvatt_> ah darn, that would have made more sense :)
[21:20] <Sarvatt_> in software center -> history, can you narrow it down to what you upgraded on the 17th?
[21:20] <marjo> Sarvatt_ do you think you've got everything you need from my system? if so, i'd like to install alpha1 on it
[21:21] <Sarvatt_> so many possibilities in the week of packages before that
[21:22] <marjo> Sarvatt_ yes, i was holding off my daily upgrade due to my concern re: python 2.7, then I got encouragement from doko and mvo, so i went for it!
[21:23] <marjo> and mvo and I couldn't narrow it down to an offending package; we both were tending towards a plymouth bug
[21:23] <marjo> we had ruled out grub, based on debugging
[21:27] <marjo> Sarvatt_ ok, i'm going to install natty-alpha1 and see how it breaks from there
[21:28] <marjo> Sarvatt_ maybe that will help us narrow down the problem
[22:57] <marjo> Sarvatt_ ping
[22:57] <Sarvatt_> marjo: heyo, any luck with alpha 1?
[22:57] <marjo> Sarvatt_ good news
[22:57] <Sarvatt_> oh?
=== Sarvatt_ is now known as Sarvatt
[22:58] <marjo> Sarvatt 2.6.37-3 boots; no high res
[22:58] <marjo> 2.6.37-5 boots; no high res
[22:59] <marjo> 2.6.37-7 all works! including 1024x600(16:9)
[22:59] <Sarvatt> hmm, -8 and higher don't?
[23:00] <marjo> Sarvatt i haven't gone further; what do you want from this working system before I try -9?
[23:01] <Sarvatt> marjo: is this on that new install, or did ya just install those on the old one?
[23:01] <marjo> Sarvatt? huh?
[23:01] <Sarvatt> those kernels, did you install a new alpha 1 install like you said and then tried out the older kernels, or did ya just try those on your old install?
[23:02] <marjo> Sarvatt: i installed natty-alpha1, but system still had all these old kernels lying around, so i started at -3 (alpha1) and started trying different kernels
[23:03] <marjo> Sarvatt: i just wanted to narrow down where things broke, since this system used to work fine
[23:03] <Sarvatt> marjo: /var/log/kern.log would be helpful
[23:04] <marjo> Sarvatt: ack
[23:06] <marjo> Sarvatt: attach to bug report or how do you want it?
[23:07] <Sarvatt> the bug please if thats ok
[23:13] <marjo> Sarvatt: done
[23:14] <marjo> Sarvatt: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693093
[23:14] <ubot4> Launchpad bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 2) (heat: 14)" [High,Confirmed]
[23:15] <Sarvatt> marjo: yeah digging through it now, wanted kern.log because it has the bad boots too and hopefully can spot the difference there
[23:16] <Sarvatt> marjo: I think what i'd do next is upgrade just the kernel to the latest so you can rule that out
[23:16] <marjo> Sarvatt: yes, back to -3
[23:16] <marjo> Sarvatt: latest == -11?
[23:16]  * Sarvatt nods
[23:17] <marjo> Sarvatt: with this system, even the trackpad works!
[23:18] <Sarvatt> dont believe the kernel is going to be the actual problem and we can rule it out right away if -11 works without all of the other stuff updated
[23:18] <Sarvatt> the trackpad didn't work before?!
[23:21] <Sarvatt> vesafb isn't getting used on your successful boot of -7 there
[23:21] <marjo> no the trackpad also stopped working at some point
[23:21] <marjo> Sarvatt: is that good? vesafb not getting used?
[23:22] <Sarvatt> hmm it isn't getting used in *any* of those boots, don't tell me we turned that on after alpha 1? :)
[23:26] <RAOF> No, it's still crazifying some of my systems.
[23:26] <RAOF> At least, last time I checked.
[23:31] <marjo> Sarvatt: boot into -11?
[23:32] <Sarvatt> marjo: yeah, leave the rest of the userspace at alpha 1 and try -11 out
[23:38] <marjo> Sarvatt: -11 works like a charm! w/ unity & trackpad & compiz
[23:38] <marjo> Sarvatt: so which of the 500+ packages is suspect? plymouth?
[23:41] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=33c08882c0d551afb28baef643279901dcc65fa9 was the only change to x-x-v-intel, hmm
[23:41] <Sarvatt> on december 13th
[23:43] <bryceh> Sarvatt, hmm
[23:43] <Sarvatt> x-x-v-intel, grub, udev are the prime suspects I think marjo, if anything I would try upgrading those one by one and see if it busts
[23:43] <Sarvatt> (sorry to be such a pain, really shooting in the dark here)
[23:43] <marjo> bryceh, Sarvatt: and breakage observed on 17 December...
[23:44] <marjo> Sarvatt: ok, will do; please no apologies
[23:50] <marjo> Sarvatt: upgrading grub2 first, ok?
[23:50] <Sarvatt> marjo: I would do x-x-v-intel first
[23:50] <Sarvatt> least invasive :)
[23:51] <Sarvatt> doesn't matter I guess
[23:51] <marjo> Sarvatt: how do i get x-x-v-intel?
[23:51] <bryceh> Sarvatt, do you suspect the above intel patch?  doesn't look like it could cause this particular problem but who knows
[23:51] <Sarvatt> udev might pull in a ton of other stuff
[23:51] <marjo> Sarvatt: so i think i'll do grub2 first (just for kicks)
[23:53] <Sarvatt> okie, was saying that because grub2 update is going to pull in all the vesafb mess, sudo apt-get install xserver-xorg-video-intel would do it
[23:54] <Sarvatt> bryceh: it doesn't look like it to me, but with copy-fb I'm not sure, need to go over this more
[23:55] <marjo> Sarvatt: i upgraded grub2 and now my system is broken (dark screen)
[23:55] <marjo> Sarvatt: w/ -11 kernel
[23:55] <Sarvatt> marjo: ok can you ssh in and get the dmesg and attach it to the bug and we can move it over to grub?
[23:57] <Sarvatt> its... complicated though. vesafb loading now and all and that machine thinks it has a 1024x768 vesa mode that it doesn't work with so it's going to be black with that..
[23:57]  * Sarvatt looks up vga= modes to try
[23:57] <marjo> Sarvatt: but isnt' that the exact problem i'm dealing with?
[23:58] <Sarvatt> kind of, I'm not sure why that is breaking the boot process completely
[23:58] <Sarvatt> for me using an invalid mode with vesafb just screws up the early part of the boot process and it recovers fine
[23:58] <marjo> Sarvatt: ack