Bug 64072

Please attach the dmesg output from after the problem occurred.

How, if I can't switch to a tty due to a frozen system?

Via ssh from another machine, or from a log file after a reboot.

Created attachment 78665 [details]
dmesg right after crash

Here's the dmesg-log from a few seconds after a normal bootup with a resulting crash.

I have a dell xps1640 too and I also have exactly the same problem : GPU lockups during startup that result in a black screen after boot process (during the start of xorg). I think all people that have a xps 1640 with HD 3670 have the same problem...

Created attachment 78836 [details]
Specifications of my laptop

In dmesg, we can see this :
Apr 28 16:24:18 mat-laptop kernel: [ 35.584061] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec
Apr 28 16:24:18 mat-laptop kernel: [ 35.584069] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000003 last fence id 0x0000000000000001)
Apr 28 16:24:18 mat-laptop kernel: [ 35.585105] radeon 0000:01:00.0: Saved 89 dwords of commands on ring 0.
Apr 28 16:24:18 mat-laptop kernel: [ 35.585108] radeon 0000:01:00.0: GPU softreset: 0x00000003
Apr 28 16:24:18 mat-laptop kernel: [ 35.745021] radeon 0000:01:00.0: R_008010_GRBM_STATUS = 0xA0003030
Apr 28 16:24:18 mat-laptop kernel: [ 35.745024] radeon 0000:01:00.0: R_008014_GRBM_STATUS2 = 0x00000003
Apr 28 16:24:18 mat-laptop kernel: [ 35.745026] radeon 0000:01:00.0: R_000E50_SRBM_STATUS = 0x200200C0
Apr 28 16:24:18 mat-laptop kernel: [ 35.745029] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000
Apr 28 16:24:18 mat-laptop kernel: [ 35.745031] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000
Apr 28 16:24:18 mat-laptop kernel: [ 35.745033] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000800
Apr 28 16:24:18 mat-laptop kernel: [ 35.745036] radeon 0000:01:00.0: R_008680_CP_STAT = 0x800000C1
Apr 28 16:24:18 mat-laptop kernel: [ 35.745038] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00007FEE
Apr 28 16:24:18 mat-laptop kernel: [ 35.759919] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00000001
Apr 28 16:24:18 mat-laptop kernel: [ 35.774806] radeon 0000:01:00.0: R_008010_GRBM_STATUS = 0xA0003030
Apr 28 16:24:18 mat-laptop kernel: [ 35.774808] radeon 0000:01:00.0: R_008014_GRBM_STATUS2 = 0x00000003
Apr 28 16:24:18 mat-laptop kernel: [ 35.774811] radeon 0000:01:00.0: R_000E50_SRBM_STATUS = 0x200280C0
Apr 28 16:24:18 mat-laptop kernel: [ 35.774813] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000
Apr 28 16:24:18 mat-laptop kernel: [ 35.774815] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000
Apr 28 16:24:18 mat-laptop kernel: [ 35.774818] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000
Apr 28 16:24:18 mat-laptop kernel: [ 35.774820] radeon 0000:01:00.0: R_008680_CP_STAT = 0x80100000
Apr 28 16:24:18 mat-laptop kernel: [ 35.780569] radeon 0000:01:00.0: GPU reset succeeded, trying to resume
Apr 28 16:24:18 mat-laptop kernel: [ 35.797540] [drm] probing gen 2 caps for device 8086:2a41 = 1/0
Apr 28 16:24:18 mat-laptop kernel: [ 35.947561] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
Apr 28 16:24:18 mat-laptop kernel: [ 35.947598] radeon 0000:01:00.0: WB enabled
Apr 28 16:24:18 mat-laptop kernel: [ 35.947601] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880133b34c00
Apr 28 16:24:18 mat-laptop kernel: [ 35.947604] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff880133b34c0c
Apr 28 16:24:18 mat-laptop kernel: [ 36.129762] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
Apr 28 16:24:18 mat-laptop kernel: [ 36.129765] [drm:r600_resume] *ERROR* r600 startup failed on resume

I suspect a regression introduced by hyperz support in mesa on ati...

(In reply to comment #7)
> I suspect a regression introduced by hyperz support in mesa on ati...

You can test that by disabling HyperZ via the environment variable R600_HYPERZ=0, e.g. in /etc/profile, or using Mesa 9.1.2, where HyperZ is disabled by default.

BTW, that's the version of the libgl1-mesa-dri package installed?

I doubt its hyperz related, comments seems to say that it happens during boot at which point there is no real 3D GPU user (unless some distro do crazy thing).

(In reply to comment #8)
> (In reply to comment #7)
> > I suspect a regression introduced by hyperz support in mesa on ati...
> 
> You can test that by disabling HyperZ via the environment variable
> R600_HYPERZ=0, e.g. in /etc/profile, or using Mesa 9.1.2, where HyperZ is
> disabled by default.
> 
> BTW, that's the version of the libgl1-mesa-dri package installed?

mesa package on ubuntu 13.04 is 9.1.1, with R600_HYPERZ=0 in /etc/profile, the bug still remains.

(In reply to comment #9)
> I doubt its hyperz related, comments seems to say that it happens during
> boot at which point there is no real 3D GPU user (unless some distro do
> crazy thing).

I was assuming it might happen during automatic login into Unity, or maybe the Ubuntu display manager uses GL as well. Maybe Lars or Mathieu can clarify at which point of the boot process it happens.

Also, if you can boot in recovery mode, does the problem occur if you just run something like 'X -retro -pogo'?

For me, it happens during the switch from the ubuntu logo (during bootup) to the lightdm greeter. As soon as the system tries to switch the resolution, it locks up.

Does:
Option "NoAccel" "True"
in the device section of your xorg.conf help?

As stated, it doesn't change the behaviour at all.

(In reply to comment #11)
> (In reply to comment #9)
> > I doubt its hyperz related, comments seems to say that it happens during
> > boot at which point there is no real 3D GPU user (unless some distro do
> > crazy thing).
> 
> I was assuming it might happen during automatic login into Unity, or maybe
> the Ubuntu display manager uses GL as well. Maybe Lars or Mathieu can
> clarify at which point of the boot process it happens.
> 
> Also, if you can boot in recovery mode, does the problem occur if you just
> run something like 'X -retro -pogo'?

X -retro command work, I see a grey sreen with a cursor that I can move. If I add -retro -pogo option, it starts and stops without problem. If I run X or startx or lightdm, black screen and GPU lockup is noticed

Created attachment 79000 [details]
Xorg.conf with noAccel

Same problem with : Option "NoAccel" "True"

Can you try a fedora live cd. Just to rule out any ubuntu customization

(In reply to comment #15)
> X -retro command work, I see a grey sreen with a cursor that I can move. If
> I add -retro -pogo option, it starts and stops without problem. If I run X
> or startx or lightdm, black screen and GPU lockup is noticed

Does 'R600_HYPERZ=0 startx' make any difference? Can you redirect the startx stdout/stderr output and see if there's anything suspicious in there?

(In reply to comment #18)
> (In reply to comment #15)
> > X -retro command work, I see a grey sreen with a cursor that I can move. If
> > I add -retro -pogo option, it starts and stops without problem. If I run X
> > or startx or lightdm, black screen and GPU lockup is noticed
> 
> Does 'R600_HYPERZ=0 startx' make any difference? Can you redirect the startx
> stdout/stderr output and see if there's anything suspicious in there?

No difference with 'R600_HYPERZ=0 startx', here is the redirect of stdout/stderr using this command : startx >file.log 2>&1
I noticed nothing really interresting

(In reply to comment #17)
> Can you try a fedora live cd. Just to rule out any ubuntu customization

I will do it as soon as possible. But I don't understand this thing : ubuntu 13.04 livecd is working great, the problem occurs once you have installed the system on your disk (even if you don't update last packages of the system)

Created attachment 79050 [details]
startx >file.log 2>&1

Bug seems to be solved with linux 3.9 kernel ! Installing this package solved this bug :
http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2013-05-09-saucy/linux-image-3.9.0-999-generic_3.9.0-999.201305090424_amd64.deb

Lars Kumbier, Ubuntu 13.04 reached EOL on January 27, 2014. For more on this, please see https://wiki.ubuntu.com/Releases .

If this is reproducible in a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.