Desktop freezes intermitently

[Rick Spencer]

Binary package hint: xorg

Occasionaly my screen will freeze. I can switch to a VT, but no processes are taking significant resources. If I switch back to VT7 the first time only the top panel can paint. If I switch to a VT and back again, none of the desktop can paint.

Please note that I have been writing code to integrate with the sound menu, and I have the vague feeling that this could be causing unity, and by extension compiz, some weird problems.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xorg 1:7.5+6ubuntu8
ProcVersionSignature: Ubuntu 2.6.37-12.26-generic 2.6.37
Uname: Linux 2.6.37-12-generic i686
Architecture: i386
DRM.card0.DVI.D.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1680x1050 1280x1024 1280x1024 1152x864 1024x768 1024x768 800x600 800x600 640x480 640x480 720x400
 edid-base64: AP///////wAQrBrQTExXMCsSAQOAKxt47r0jp1NGniUUUFulSwBxT4GAAQEBAQEBAQEBAQEBITmQMGIaJ0BosDYArg4RAAAcAAAA/wBSMjk3RDhBTjBXTEwKAAAA/QA4Sx5TDwAKICAgICAgAAAA/ABERUxMIFNQMjAwOVcKAEQ=
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Thu Jan 27 17:57:48 2011
DistUpgraded: Yes, recently upgraded Log time: 2010-11-16 11:51:47.558363
DistroCodename: natty
DistroVariant: ubuntu
GraphicsCard:
 Subsystem: Dell Device [1028:0279]
   Subsystem: Dell Device [1028:0279]
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
MachineType: Dell Inc. Studio Hybrid 140g
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.37-12-generic root=UUID=12138568-ff39-4528-a843-2081cf21c159 ro quiet splash vt.handoff=7
SourcePackage: xorg
dmi.bios.date: 09/26/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.0.6
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 0P096C
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: '01'
dmi.modalias: dmi:bvnDellInc.:bvr1.0.6:bd09/26/2008:svnDellInc.:pnStudioHybrid140g:pvr00:rvnDellInc.:rn0P096C:rvrA01:cvnDellInc.:ct3:cvr'01':
dmi.product.name: Studio Hybrid 140g
dmi.product.version: 00
dmi.sys.vendor: Dell Inc.
version.libdrm2: libdrm2 2.4.23-1ubuntu3
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10-1ubuntu1
version.xserver-xorg: xserver-xorg 1:7.5+6ubuntu8
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.13.2-1ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu1

[Bryce Harrington (bryce)]

Can you also post you /var/log/Xorg.0.log and /var/log/Xorg.0.log.old? apport is supposed to collect those files, no idea why it didn't in this case.

[Rick Spencer (rick-rickspencer3)]

Thanks bryceh. Attached and set back to New

[Bryce Harrington (bryce)]

Hi Rick,

We've had a bunch of bug reports about GPU freezes lately, which I've been focusing on most of this past week. This particular report doesn't have the instrumentation data needed to diagnose it, but I figured I can give you a run down of all the freezes I know about at this point.

By and large, all of the freezes are actually kernel bugs in the drm code, so it requires the kernel team to fix them. But we've been assisting on the X side with the triaging and where possible identifying kernel patches to make the kernel team's life easier. But ultimately it's going to be a matter of waiting for newer more stable kernel releases. The GPU hangs may magically go away (or be replaced by exciting new ones) as the kernel gets new RC's.

Anyway, here's some of the common "classes" of freezes I know about:

1. vesafb conflict causing lockup during boot. Bug #702090. Basically, the kernel has a generic video driver loaded as a fallback for plymouth and boot prettiness. When it comes time to load the intel kernel driver, the Intel driver locks up. Interestingly, most of the time the kernel is able to reset the GPU and keep on truckin' but it's enough to trigger apport. So it's sort of a false positive in those cases, however apw and I suspect this could also be triggering other issues so needs to be sorted out. The way to tell it's this kind of bug is because there is a line in dmesg like "ERROR* EIR stuck: 0x00000010, masking".

2. Freeze with black screen switching from Plymouth to X during boot. Bug #712173. Removing 'quiet/splash' makes things work right. So this is probably Plymouth messing up the GPU and leaving it in a busted state, so when it comes time for X to load, it can't and faults. Seems not to be terribly widespread but has come up in ISO testing. Really makes me wish we didn't have to use Plymouth. ;-)

3. ESR 0x00000001 random freeze during usage. I don't know what leads to this freeze, it seems to be of the "random lockup" variety. The distinguishing characteristic is that the GPU dump shows a 0x00000001 for the ESR parameter. I don't know if this means they're all dupes of the same root cause or just very similar kinds of failures.

4. There are also a few one-off freezes that appear to be unique to specific individuals and their hardware, and perhaps to a given kernel version. At least, the dmesg errors and GPU dumps don't match up to anyone else's bug reports. A lot of times these mysteriously go away after an update or two.

Generally, we have fair luck at pinpointing things when we get GPU dumps when apport catches the hang. Sometimes just seeing the dmesg from when it is hung is enough. Unfortunately in the case of this bug report the dmesg seems to be from when the system was working ok, so doesn't indicate what the freeze was.

Are you still experiencing the freeze? If you are, and apport isn't collecting the bug, then what we need collected is the output of 'intel_gpu_dump' and 'dmesg', and the /sys/kernel/debug/dri/0/i915_error_state file if it exists. dmesg usually includes a drm error message in this case, and the gpu dump has error codes that point to how the driver ...

[Rick Spencer (rick-rickspencer3)]

I do not think I am still experiencing this particular issue. I have been experience a freeze on alt-tab at times, but I can switch to VT, kill compiz, and then use unity --reset to get back to work. I chalked this up to a compiz bug. I have updated today, and will log a bug report for that freeze should it occur again. For safe measure, I will grab the data that you asked for here.

In any case, I think this particular bug report is probably not worth tracking atm. Please feel free to set it to invalid or otherwise close it.

[Bryce Harrington (bryce)]

Alright, thanks, I'll close it. Typically apport catches freezes and pops up a report dialog, so if the freezes come back it's best to just go ahead and file a new bug report that way.

So, sounds like your freeze may have fallen into category #4. Perhaps upgrading from .37 to .38 resolved it.

[Travis Watkins (amaranth)]

When this happens attaching gdb to compiz shows it is stuck waiting in a call to glXWaitVideoSyncSGI so it's not going to be a compiz issue here.

Upgrading to 2.6.38 didn't solve it, I still get this every other day or so. Next time it happens I'll see if I can get any info. Apport doesn't collect any info, probably because the driver failed to restart the GPU.

[Bryce Harrington (bryce)]

@Travis, actually apport *should* fire off if the GPU can't be restarted. However, there definitely are cases in the wild where for some reason the kernel doesn't fire off the event. NFI why though. Definitely would be nice to fix.

In any case, if apport doesn't get activated automatically, you could ssh in and I think you may be able to manually run the script /usr/share/apport/apport-gpu-error-intel.py, or even just collect the stuff directly (the output of 'intel_gpu_dump' and 'dmesg', and the /sys/kernel/debug/dri/0/i915_error_state file if it exists).

[Jeremy Foshee (jeremyfoshee)]

Hi Rick,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]