| RAOF | Aug 22 17:59:50 Faye kernel: [ 299.663018] [Hardware Error]: Machine check events logged. Woo! | 09:44 |
|---|---|---|
| RAOF | That's why she's called Faye :) | 09:44 |
| === ara_ is now known as ara | ||
| Sarvatt | RAOF: every sandybridge system i've seen does that in 3.0+, and that one was named asuka before you named it faye :) | 15:14 |
| jcristau | i think #831336 should be reassigned somewhere that's not xterm | 17:43 |
| jcristau | like unity or something | 17:43 |
| bryceh | jcristau, did you look at GdmLog2.txt? | 18:00 |
| bryceh | *** glibc detected *** /usr/bin/Xorg: free(): corrupted unsorted chunks: 0x0000000002b844c0 *** | 18:00 |
| bryceh | however I can't tell that he was actually using gdm at the time of the crash rather than lightdm | 18:02 |
| jcristau | bryceh: ah, no, didn't see that one, i only looked at the most recent logs | 18:07 |
| bryceh | that was the only one I could find with an actual error | 18:07 |
| jcristau | i assumed the error, if any, would be in .xsession-errors | 18:08 |
| jcristau | which isn't in there i think | 18:08 |
| bryceh | nope; for xterm I should have that be automatically gathered | 18:08 |
| jcristau | it's more likely to have private data than the other logs i guess | 18:09 |
| bryceh | true | 18:09 |
| Dink | I was looking through xserver-xorg bugs and not sure if what I am experiencing is related to some "fixed" bugs #778490, #774978, #740785,#775705. When I start FF6 everything crashed and goes back to gdm login. Currently xserver-xorg-input-synaptics version 1.3.99+git20110116.0e27ce3a-0ubuntu12.1 | 18:43 |
| Dink | FF6 works fine when I run ubuntu in safe mode | 18:43 |
| Dink | This is 64bit natty running in vm | 18:48 |
| Dink | All I can get is | 18:54 |
| Dink | connect(4, {sa_family=AF_INET, sin_port=htons(6000),sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECO | 18:54 |
| Dink | NNREFUSED (Connection refused) | 18:54 |
| bryceh | Dink, collect a full backtrace (see http://wiki.ubuntu.com/X/Backtracing for details) | 19:37 |
| === yofel_ is now known as yofel | ||
| Dink | bryceh: I tried but before I could type backtrace while FF6 was running it killed X | 21:55 |
| bryceh | Dink, heh, do it from console or ssh | 21:56 |
| Dink | hmm so open up ff6 via gui while on a ssh/console session then try gdb ? | 21:57 |
| Dink | still not sure ff6 will stay open log enough but will try | 21:57 |
| bryceh | Dink, no you need to run X within gdb. See the url I gave you for directions how. | 21:59 |
| Dink | cool got it | 22:02 |
| Dink | Where do you want it ? | 22:03 |
| bryceh | Dink, in a bug report | 22:04 |
| Dink | (gdb) backtrace full | 22:04 |
| Dink | #0 0x00007f201f835335 in PrlCtlUpdateGLXSize () | 22:04 |
| Dink | from /usr/lib/xorg/modules/drivers/prlvideo_drv.so | 22:04 |
| Dink | Is that the stuff that should be outputted ? | 22:04 |
| RAOF | Yeah, that's the sort of thing which should be outputted. What's prlvideo? :) | 22:05 |
| bryceh | RAOF, sounds like a driver we don't support ;-) | 22:05 |
| Dink | Parallels | 22:06 |
| RAOF | bryceh: It does indeed, yes :) | 22:06 |
| Dink | I am running this in Parallels | 22:06 |
| bryceh | virtualized thingee | 22:06 |
| bryceh | Dink, ok you need to file a bug with Parallels | 22:06 |
| RAOF | Dink: So, it seems likely that the Parallels X driver has a bug; Firefox is generally excellent at triggering such things. | 22:06 |
| Dink | bryceh: ok thanks will do. | 22:07 |
| bryceh | sometimes with these virtualized video drivers, they need to rebuild their drivers to match what we're shipping in ubuntu | 22:07 |
| Dink | RAOF: thanks for the info. | 22:07 |
| bryceh | I don't know if that's what's happening here, but that's the most common issue we see with these drivers | 22:07 |
| bryceh | e.g. GLXSize makes me wonder if they need to update the prl driver to support mesa 7.11 which RAOF just put in relatively recently | 22:08 |
| bryceh | RAOF, heya | 22:09 |
| RAOF | bryceh: Good morning / evening :) | 22:09 |
| RAOF | Hm. Or maybe afternoon? | 22:09 |
| bryceh | RAOF, speaking of drivers we don't support, I wanted to get your thoughts on bug #815000 | 22:09 |
| bryceh | yep 3pm; High Naptime | 22:10 |
| bryceh | RAOF, I'm thinking we should bump that over to the kernel, but do you think there's anything we would/could/should do on the X end? | 22:12 |
| bryceh | ick... in more troubling news, looks like xvfb broke again... https://bugs.launchpad.net/~doko/+reportedbugs (bug #829470) | 22:13 |
| RAOF | I think you're right, and that should be a kernel bug. I'm pretty sure there should be a KMS poulsbo driver, but it doesn't seem to be loading. | 22:13 |
| bryceh | alright, I'll bump it | 22:13 |
| RAOF | Hm. Which of doko's bugs are you referring to? | 22:14 |
| bryceh | 829470 | 22:15 |
| bryceh | but I'd bet most of those are outcomes of broken xvfb | 22:15 |
| bryceh | so far not able to repro on my hw | 22:16 |
| RAOF | I'll see if it does here. | 22:18 |
| bryceh | xvfb in general seems not to fail (launching xterm or whatever). Going to try the build test in pygtk next | 22:19 |
| bryceh | RAOF, do you remember when we talked about maybe adding xvfb to the xorg-server build scripts, to catch these types of issues ourselves? Know if that idea went anywhere? | 22:20 |
| RAOF | Yeah. It has not yet gone anywhere. | 22:21 |
| bryceh | Xlib: extension "RANDR" missing on display ":99". | 22:33 |
| bryceh | hmm perhaps that's innocuous | 22:41 |
| RAOF | xvfb does not support RANDR, and I'm fairly sure that GTK no longer blows up if it's running on a server which does not support RANDR. | 22:43 |
| bryceh | yeah running the test locally I'm noticing the fatal error is actually TypeError: Unsupported type: <class 'gtk._gtk.WindowType'> | 22:44 |
| RAOF | So this doesn't seem to be an xvfb bug, but rather a failing test that's not reported well. | 22:44 |
| bryceh | yeah | 22:44 |
| bryceh | probably some gnome3 transition problem. | 22:50 |
| RAOF | Yeah, may well be. | 22:50 |
| bryceh | RAOF, we're still getting a lot of those false gpu hang bugs; thankfully real gpu hangs seem to be extremely rare | 22:53 |
| bryceh | on one of my upstream reports someone said they see it on ubuntu but not mandriva (or whatever that distro is called these days). | 22:54 |
| bryceh | RAOF, otoh apw seems not sure what else to look at on our end. we're running short on ideas | 22:56 |
| RAOF | bryceh: As in: we're running out of bugs for the kernel team to fix?! | 22:56 |
| RAOF | Oh, or that the GPU lockup doesn't seem to occur on Mandriva, and they're running the same kernel? | 22:57 |
| bryceh | right | 22:57 |
| bryceh | however as it's (usually) a symptomless-hang, you'd not notice it on a non-Ubuntu system unless you were specifically looking for it in dmesg | 22:58 |
| RAOF | Hah. Right. | 22:58 |
| RAOF | I presume apw has got the testers to try an upstream / drm-intel-next kernel? | 23:00 |
| bryceh | we've done that before, although not recently (if there's a particular fix you're thinking of) | 23:01 |
| bryceh | when he'd investigated before, he felt it wasn't the kernel code that was bad but rather an issue with how the drivers were being loaded | 23:02 |
| bryceh | ickle says the bug itself is an invalid memory issue, which makes me wonder if it's some sort of race condition during driver initialization | 23:03 |
| bryceh | then by the time the driver has faulted and reset, the memory is kosher (or gets re-initted) | 23:03 |
| bryceh | I'm also wondering if it has to do with something done during the great bootspeed optimization campaign | 23:04 |
| bryceh | unfortunately the gpu hang tools didn't really capture this properly until well after that work was done, so hard to correlate to that | 23:05 |
| bryceh | of course, I can't reproduce it on any of my machines | 23:06 |
| bryceh | such is the curse of being an X maintainer ;-) | 23:06 |
| bryceh | I've been trying to look for commonalities between different reporters, like if they have specific proprietary kernel modules loaded, or similar hardware or something. But from the recently reported bugs there's quite a bit of variance from person to person | 23:07 |
| RAOF | Is it the same GPU at least? | 23:09 |
| bryceh | current reports are against i915, 1945, 1965 | 23:11 |
| bryceh | I don't see it on my i945 | 23:11 |
| bryceh | s/l/i/g | 23:11 |
| bryceh | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.tag=oneiric+-kubuntu+-xubuntu+-ppc+-omit&field.tags_combinator=ALL | 23:11 |
| === techmik67 is now known as techmik | ||
| RAOF | Well, that's a nice wide range at least. :) | 23:15 |
| bryceh | even the arrandale chris van hoof gave me doesn't show it; and it's positively thick with bugs at the moment | 23:16 |
| bryceh | #830276 looks like a false gpu hang but appears to actually hang | 23:18 |
| bryceh | alright, enough bug work for the day... food, then xdiagnose. bbiab | 23:21 |
| Sarvatt | IPEHR: 0x7xxxxxxx have always been mesa problems if i'm remembering right, IPEHR: 0x018xxxxx were always hangs during dpms cycles | 23:36 |
| bryceh | Sarvatt, ooh good to know; would that happen to be documented anywhere that you know? | 23:37 |
| Sarvatt | nope just trends i noticed going through hundreds of bugs, we get a rash of 0x018xxxxx dpms bugs right after release every single release since lucid | 23:38 |
| Sarvatt | well its documented in the gpu docs | 23:38 |
| RAOF | As in the register specifications? | 23:38 |
| Sarvatt | yeah, why am I not finding it again.. | 23:41 |
| RAOF | This might be good to be documented on a wiki page? | 23:45 |
| bryceh | yep | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!