[00:00] <RAOF> Hello, x86-64 assembly reference.  Do you have 400 pages worth of instruction definitions?  You do?  Guess it's lucky there's code already written!
[00:05] <bryceh_> dang sun, get out of my eyes and off my monitors
[00:20] <bryceh_> RAOF, did you see bug 732809?
[00:20] <ubot4`> Launchpad bug 732809 in mesa (Debian) (and 1 other project) "mesa update to 7.10.1-0ubuntu1 breaks ipython matplotlib (dup-of: 259219)" [Unknown,New] https://launchpad.net/bugs/732809
[00:20] <ubot4`> Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 121) (dups: 28) (heat: 300)" [High,Triaged] https://launchpad.net/bugs/259219
[00:21] <bryceh_> ah that's just the TLS bug, nevermind :-)
[00:24] <RAOF> bryceh_: I did indeed ;)
[00:24] <RAOF> And, barring assembly, I've got it done locally.
[00:34] <bryceh_> pity no feedback yet on bug 702090.  did I go overboard with the paint-by-numbers directions and scare everyone off?
[00:35] <ubot4`> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 6 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 72) (dups: 57) (heat: 520)" [High,Incomplete] https://launchpad.net/bugs/702090
[00:40] <bryceh_> apw, from my limited testing the vesafb kernel doesn't appear to *cause* issues near as I can tell.  If you wanted to just roll it out, we get enough automatic gpu error reports I think it would become pretty clear within a couple days whether it has eliminated the issue.  We should notice a flattening of the curve and no further bug reports filed with these codes.
[01:32] <RAOF> I WIN! (At causing glxinfo to segfault)
[01:42] <RAOF> And if you don't clobber registers mesa assumes aren't clobbered, glxinfo doesn't segfault either!
[02:16] <RAOF> Ahem.  And if you actually preserve the other registers, glxgears works, too.
[02:26] <bdrung> hi, my new sandbybridge system has frequent gpu lockups (bug #733006). is there something that i can do (test)?
[02:26] <ubot4`> Launchpad bug 733006 in xserver-xorg-video-intel (Ubuntu) "[sandybridge] GPU lockup 1a28f5a9 () (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733006
[02:43] <RAOF> bdrung: Is that before or after mesa 7.10.1?  There were lots of sandybridge fxxups in that.
[02:44] <bryceh_> looks like it - version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1-0ubuntu1
[02:45] <bryceh_> bdrung, unfortunately your gpu dump has a 00's for the error codes
[02:45] <bryceh_> [   49.302005] [drm:init_ring_common] *ERROR* render ring initialization failed ctl 00000000 head 00000000 tail 00000000 start 00000000
[02:45] <bryceh_> "render ring initialization", haven't heard of that one before
[02:46] <bryceh_> bdrung, so here are the things I'd suggest testing, in no particular order:
[02:46] <bryceh_> * boot an older kernel if you still have one installed.  That can help identify if it's a drm regression
[02:47] <bryceh_> * downgrade mesa.  Like raof says it has some changes for sandybridge.  Conceivably those changes could carry bugs too
[02:47] <bryceh_> bdrung, the above two are especially useful if this is a regression from it used to work right in the past
[02:48] <RAOF> * upgrade mesa; I think xorg-edgers is usable at the moment, and upstream's always more interested in bugs not fixed in the bleeding-edge.
[02:48] <bryceh_> * try the intel-drm-next kernel - http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/ - which will either identify if there might be a fix upstream, or else demonstrate it's an upstream bug
[02:51] <bryceh_> ok I am told I have a tired demanding pregnant wife needing some attention, so gtg
[02:52] <bryceh_> bdrung, hopefully the above helps.  Also keep filing apport bugs, sometimes it'll catch error codes when you're getting a string of 0's.
[02:53] <bryceh_> bdrung, there are a couple other people with similar error=0x00000 types of bugs for various chips, it's possible they're related.  I hesistate to send them upstream without more specifics but if we get enough reported will do so
[02:53] <bryceh_> l8r
[05:04] <Sarvatt> bdrung: try booting with with drm_kms_helper.poll=0 additionally please :)
[05:20] <Sarvatt> hmm, I guess updating lucid/maverick in xorg-edgers wont be that big a deal in the end, I just didn't want to backport the libdrm-nouveau1a rename since I'd have to rebuild crap like plymouth in there when the one built against 2.4.17 nouveau abi works fine but its just plymouth
[06:02] <RAOF> Bah.  When are those darned new Sony notebooks coming out?
[06:07] <bryceh_> check it --> http://www.bryceharrington.org/cgi-bin/upstreamer.cgi?bug=728823
[06:08] <bryceh_> attachment forwarding is partly in there to but it's sloooowwww so left it disabled for now
[06:11] <RAOF> Funky!
[06:14] <RAOF> Doh!
[06:14] <RAOF> Stupid IA32 assembler.
[07:17] <bryceh_> apw, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/733096
[07:17] <ubot4`> Launchpad bug 733096 in xserver-xorg-video-intel (Ubuntu) "[q45] GPU lockup 32b1ab02 (EIR: 0x00000010 ESR: 0x00000010 PGTBL_ER: 0x00000002 IPEHR: 0x01000000) (affects: 1) (heat: 6)" [Undecided,New]
[09:12] <ricotz> RAOF, hi
[09:14] <ricotz> RAOF, did you see issues like these yet? nvidia-blob: http://enyo.zakx.de/~angelos/docky.png -- intel: http://img713.imageshack.us/i/docky.png/
[09:51] <bdrung> good morning. i will try all your suggestions and report back.
[10:38] <bdrung> bryceh_: the drm-intel-next kernel crashes with an ops while booting
[10:44] <bryceh_> bdrung, the drm-next branch might be a bit more stable
[10:53] <bdrung> bryceh_: that crashes too (general protection fault)
[10:59] <bryceh_> bdrung, the fact that it's crashing is probably interesting and may be relevant on your original issue.  hope you're taking notes
[10:59] <bdrung> bryceh_: nope, but screenshots ;)
[11:00] <bdrung> now i am trying xorg-edgers
[11:02] <bryceh_> have I mentioned today how much I hate the intel video driver's bugginess?
[11:02] <bdrung> no and i have to agree
[11:03] <bdrung> i had to start Windows to verify that the hardware is ok and that it's only a software problem
[11:04] <bdrung> bryceh_: xorg-edgers brought no improvement
[11:05] <bdrung> still gpu lockups
[11:05] <bdrung> right after login
[11:05]  * bryceh_ nods
[11:05] <bryceh_> well, xorg-edgers won't make a difference if it's a kernel drm issue, which is what it's starting to sound like
[11:06] <bryceh_> I'm curious about the oops and the gpf
[11:06] <bryceh_> if those are unrelated that would be seriously unfortunate
[11:06] <bryceh_> more likely though, they are different reactions to the same or similar fundamental issue
[11:06] <bdrung> bryceh_: are they stored somewhere on the disk? will apport report them?
[11:07] <bryceh_> you could look in /var/crash - if that's empty apport won't report them
[11:07] <bryceh_> I *think* that apport might neglect to report them since they're not stock kernels, but I'm not sure
[11:08] <bryceh_> you can look in /var/log/kern.log* to see if those files show the errors
[11:08] <bryceh_> if not, I'd suggest rebooting to those kernels and capture dmesg
[11:08] <bdrung> how should i capture dmesg if they crash on booting?
[11:10] <bdrung> and the second question is: what workaround can i use to avoid those crashed to have a chance to run apport?
[11:10] <jcristau> netconsole
[11:11] <bdrung> what command do i need to report these problems?
[11:12] <bryceh_> bdrung, a photo to capture the dmesg output showing the OOPS or fault would be a starting point
[11:12] <bryceh_> sometimes you can ssh in and grab it
[11:13] <bryceh_> if you can't ssh in, that would suggest a deeper kernel issue
[11:13] <bryceh_> like, ssh with an ethernet cable, if wireless hasn't kicked in yet
[11:14] <bdrung> wow, launching the drm-next kernel in recovery mode works. i have a console and can run dmesg
[11:14] <bryceh_> for workarounds, if you snag the file from /var/crash/ that corresponds to the crash and copy it to another machine, there are ways to file it from the other machine
[11:15] <bdrung> here's the dmesg output of drm-intel-next: http://paste.ubuntu.com/578782/
[11:16] <bryceh_> [   11.620556] Process plymouthd (pid: 346, threadinfo ffff88041edfa000, task ffff88041b2ec440)\
[11:17] <bdrung> so plymouthd died?
[11:17] <bryceh_> looks like it
[11:17] <bryceh_> could try booting with splash disabled, see if that makes the crash go away
[11:18] <bryceh_> or uninstall plymouth (if that still works)
[11:18] <bdrung> how is the splash disabling parameter called?
[11:19] <bryceh_> I think you just delete 'splash' from the kernel cmdline
[11:19] <bryceh_> linux	/boot/vmlinuz-2.6.38-4-generic root=UUID=2b238928-f3f1-4074-b551-2cceff54c6a4 ro   quiet splash vt.handoff=7
[11:20] <bdrung> i copied all crash files from /var/crash to this machine.
[11:20] <bryceh_> so you'd just go into grub (hold down left shift during boot), trim out 'splash', and boot
[11:20] <bryceh_>        apport-cli [ --save file ] symptom | pid | package | program path | .apport/.crash file
[11:21] <bryceh_> APPORT_IGNORE_OBSOLETE_PACKAGES=true apport-cli <foo.crash>
[11:21] <bryceh_> ^ that should be the magic to get the report to file from your other machine
[11:24] <bdrung> apport-cli complains that the crash doesn't belong to an not installed package
[11:28] <bryceh_> hrm, yeah I should have added I'd never gotten that magic to work right myself
[11:29] <bryceh_> fwiw, the .crash file is largely text... you can upload it to one of your bug reports for reference.  I think I should be able to extract the errors from the file myself.
[11:29] <bryceh_> I don't like doing that in general, but for you...  ;-)
[11:31] <bdrung> removing plymouth let the drm-intel-next kernel boot and it's currently running without locking up
[11:31] <bdrung> so i can report the bug on the main machin
[11:31] <bdrung> e
[11:33] <bryceh_> sweet
[11:33] <bryceh_> bdrung, ok, so sounding like a kernel/plymouth type of bug.
[11:33] <bdrung> but i can't report the crashes because apport complained that the package are not ubuntu packages
[11:35] <bryceh_> yeah, like I mentioned earlier
[11:36] <bryceh_> just attach the .crash files to the bug report, and I'll sort it from there
[11:37] <bdrung> bryceh_: i could pastebin them
[11:38] <bryceh_> it's getting a bit late for me, I'd prefer if you attached them to one of your bug reports, and I'll look at it tomorrow
[11:38] <bryceh_> (3:30am... need to hit the sack soon)
[11:38] <bdrung> bryceh_: should i file it against the kernel package or intel?
[11:41] <bryceh_> kernel
[11:41] <bryceh_> make sure to tag it 'natty'
[11:42] <bryceh_> actually, if you know how, I'd suggest filing it against both 'linux' and 'plymouth'
[11:42] <bdrung> k, will do that
=== evilvish is now known as vish
[15:32] <bdrung> bryceh_: bug #733321 reported and crash logs attached
[15:32] <ubot4`> Launchpad bug 733321 in plymouth (Ubuntu) (and 1 other project) "[sandybridge] GPU lockups and other crashes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733321
=== bdmurray_ is now known as bdmurray
[16:45] <Sarvatt> bdrung: go figure you have the screwed up board mentioned here too http://www.phoronix.com/scan.php?page=article&item=intel_sandy_speed&num=1 :(
[16:52] <bdrung> Sarvatt: can you give me the pointer to the phoronix command that triggers the issue?
[16:52] <bdrung> Sarvatt: i have the same board (with an b3 stepping)
[16:53] <Sarvatt> just booting was screwed up for them, i'm trying to find any discussion on what the actual problems were
[16:55] <bdrung> Sarvatt: my system runs fine with the drm-intel-next kernel (after only one plymouth related boot crash -> bug #733321)
[16:55] <ubot4`> Launchpad bug 733321 in plymouth (Ubuntu) (and 1 other project) "[sandybridge] GPU lockups and other crashes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733321
[16:56] <bdmurray> bryceh_: I'm still seeing bug 726807
[16:56] <Sarvatt> bdrung: even without drm_kms_helper.poll=0 ?
[16:56] <ubot4`> Launchpad bug 726807 in xserver-xorg-video-ati (Ubuntu) "drawing of drop down boxes produces artifacts temporarily (affects: 1) (heat: 479)" [High,Triaged] https://launchpad.net/bugs/726807
[16:56] <bdrung> Sarvatt: not tested yet
[16:59] <Sarvatt> it looks like 2.6.38-rc8 should work if drm-intel-next works
[19:40] <ricotz> Sarvatt, hi
[19:41] <ricotz> Sarvatt, did you hear about some cairo breakages (with transformation matrizes) lately?
[19:46] <Sarvatt> ricotz: afraid not, whats up?
[19:47] <ricotz> Sarvatt, http://enyo.zakx.de/~angelos/docky.png
[19:47] <evilvish> Sarvatt: hey, i recall you mentioned to use for the x freeze: $ echo 0x001ee62d | eu-addr2line -e /usr/lib/debug/lib/libdrm_radeon.so.1.0.0   
[19:47] <evilvish>  and echo 0x001ee5da ; echo 0x001d35da ; echo 0x001d362d
[19:48] <evilvish> Sarvatt: should that be before the freeze or after? 
[19:48]  * evilvish forgot.. :s
[19:48] <ricotz> Sarvatt, this happens for people on archlinux and gentoo lately, which seems to be cairos fault or the mono 2.10 bindings
[19:48] <evilvish> i got this without those echo lines » http://launchpadlibrarian.net/66142834/gdb-Xorg-2.6.35-6.7-generic.txt and after echo » http://launchpadlibrarian.net/66142892/gdb-Xorg-2.6.35-6.7-generic-echo.txt
[19:48] <ricotz> Sarvatt, but i suspected cairo, mesa or xserver
[21:19] <Sarvatt> real fix for jcastro's pageflip problem - http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=fdc315a19a2c33da29dd87d4ca88f4e4407bd42d
[21:21] <bryceh_> Sarvatt, what was jcastro's bug #?
[21:22] <bryceh_> hm, bug 715330 maybe?
[21:22] <ubot4`> Launchpad bug 715330 in xserver-xorg-video-ati (Ubuntu) (and 2 other projects) "Freeze after login with KMS enabled on Radeon HD6310 (affects: 2) (heat: 124)" [High,Confirmed] https://launchpad.net/bugs/715330
[21:22] <bryceh_> yep
[21:23] <Sarvatt> yep, beat me to it (was digging through mail)
[21:23] <Sarvatt> also he's working on a fix for the AGP pageflip problem https://bugs.freedesktop.org/show_bug.cgi?id=35183 \o/
[21:23] <ubot4`> Freedesktop bug 35183 in DRM/Radeon "system freezes with 2.6.38-rc kernel and kms pageflip enabled" [Normal,New]
[21:25] <bryceh_> Sarvatt, ok flagged it for JFo
[21:25] <Sarvatt> awwh he changed it from Not-reported-usefully-by: Michael Larabel @ phoronix to Article-written-by: Michael Larabel @ phoronix
[21:26] <bryceh_> hehe
[21:26] <bryceh_> Sarvatt, feel free to close the -ati task if you think there's nothing more needed to be done on our end (unless you think it's worth leaving open just for tracking it)
[21:49] <cnd> bryceh_, heads up: I have asked for a FFe for XInput 2.1 support in xinput (the utility) (bug 733536)
[21:49] <ubot4`> Launchpad bug 733536 in xinput (Ubuntu) "Add XInput 2.1 support to xinput utility (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/733536
[21:50] <cnd> I'm outta here now though :)
[21:50] <cnd> see you later
[21:53] <bryceh_> cnd, ok thanks for the notice
[22:09] <Sarvatt> ricotz: please dont tell me it's https://bugs.launchpad.net/bugs/259219 too :)
[22:09] <ubot4`> Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 202) (dups: 66) (heat: 688)" [High,Triaged]
[22:15] <Sarvatt> ricotz: so whats needed to reproduce that docky problem?
[22:21] <ricotz> Sarvatt, unlikely that bug :P -- you would need mono 2.10, so not reproduceable on ubuntu/debian that easy
[22:22] <ricotz> looks like it is a mono/docky problem perhaps a change in the cairo bindings, pretty weird though