Forwarding this Ubuntu bug: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/389242 [Problem] X server froze. dri-debug tarball to follow. I did not have KMS enabled at the time. After trying to kill & respawn the X server, the machine proceeded to lock up completely. ProblemType: Bug Architecture: amd64 Date: Thu Jun 18 15:31:32 2009 DistroRelease: Ubuntu 9.10 MachineType: LENOVO 6371CTO Package: xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2 ProcCmdLine: root=/dev/mapper/hostname-root ro quiet splash ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.30-9.10-generic RelatedPackageVersions: xserver-xorg 1:7.4~5ubuntu21 libgl1-mesa-glx 7.4.1-1ubuntu2 libdrm2 2.4.11-0ubuntu1 xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2 xserver-xorg-video-ati 1:6.12.2-2ubuntu1 SourcePackage: xserver-xorg-video-intel Uname: Linux 2.6.30-9-generic x86_64 dmi.bios.date: 12/27/2006 dmi.bios.vendor: LENOVO dmi.bios.version: 7IET23WW (1.04 ) dmi.board.name: 6371CTO dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr7IET23WW(1.04):bd12/27/2006:svnLENOVO:pn6371CTO:pvrThinkPadT60:rvnLENOVO:rn6371CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 6371CTO dmi.product.version: ThinkPad T60 dmi.sys.vendor: LENOVO fglrx: Not loaded system: distro: Ubuntu architecture: x86_64kernel: 2.6.30-9-generic
Created attachment 26938 [details] dri_debug2.tgz
Created attachment 26939 [details] XorgLog.txt
Created attachment 26940 [details] CurrentDmesg.txt
fwiw, the dmesg attachment and Xorg log appear to be the ones for post-reboot - ones from the actual freeze are included in the dri_debug2.tgz.
Is there a way of reliably reproducing this? Also, intel-gpu-tools dumps some more interesting info as of some updates last night...
No, I have no way to reproduce this. And soon even less so, with karmic enabling kms by default shortly.
Well, I'm not sure what we should do with this one then... maybe mark it 'invalid' or 'wontfix'? If we don't have a way to reproduce it and the reporter is going to use something else w/o the bug...
Closing this as 'wontfix' is probably reasonable in that case. But in the future, is it going to be worth filing reports of unreproducible hangs? Does the new intel-gpu-tools provide enough information now that it will be possible to debug these without a simple test case?
The new tools (both the dumper and the kernel error collection) should help. And I wouldn't say that unreproducible bugs shouldn't be filed, unless the reporter won't be able to help further (as in this case, where you're moving to a non-crashy (fingers crossed) version of the software). Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.