Bug 44121
Summary: | Reproducible GPU lockup CP stall on Radeon HD 6450 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Jean Delvare (jdelvare) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | alexdeucher |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.5-rc5 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
properly disable render backend
properly disable render backend possible fix possible fix |
Description
Jean Delvare
2012-07-01 19:54:00 UTC
Can you dump the following registers using radeonreg or avivotool (http://cgit.freedesktop.org/~airlied/radeontool/) with the patch applied and reverted and attach both results? CC_RB_BACKEND_DISABLE (0x98F4) CC_SYS_RB_BACKEND_DISABLE (0x3F88) GC_USER_RB_BACKEND_DISABLE (0x9B7C) CC_GC_SHADER_PIPE_CONFIG (0x8950) GB_BACKEND_MAP (0x98FC) (as root): radeonreg regmatch 0x98F4 etc. With 3.5-rc5 kernel (failing) : 0x98F4 0x00000001 (1) 0x3F88 0x00000001 (1) 0x9B7C 0x00000000 (0) 0x8950 0xfffcf001 (-200703) 0x98FC 0x00000000 (0) With commit 416a2bd2 reverted (working) : 0x98F4 0x00000001 (1) 0x3F88 0x00000001 (1) 0x9B7C 0x00fe0000 (16646144) 0x8950 0xfffcf001 (-200703) 0x98FC 0x00000000 (0) So, value of register GC_USER_RB_BACKEND_DISABLE (0x9B7C) differs. Created attachment 74671 [details]
properly disable render backend
Does this patch fix it ?
I tested the patch in comment #3 but unfortunately it doesn't solve the problem. With this patch applied, I get: 0x98F4 0x00000001 (1) 0x3F88 0x00000001 (1) 0x9B7C 0x00fe0000 (16646144) 0x8950 0xfffcf001 (-200703) 0x98FC 0x00000000 (0) 0x8954 0x00000000 (0) So the value of register 0x9B7C is correct now, but this was not sufficient. Created attachment 74701 [details]
properly disable render backend
This one ?
Created attachment 74711 [details]
possible fix
or this variant. Although AFAIK, programming the USER register variants shouldn't be necessary as the default values (0) are valid.
Does booting up a clean kernel without any patches applied or reverted work if you manually set the following registers to their "patch reverted" values using radeonreg? Just to be sure, write all of them even if the values are the same. Do this without X running. 0x98F4 0x3F88 0x9B7C 0x8950 0x98FC 0x8954 e.g., radeonreg regset 0x8950 0xfffcf001 Patch from comment #6 doesn't work, testing patch from comment #7 now. Patch from comment #7 did not work either. Then I followed the instructions from comment #8, but it also did not help. Created attachment 74771 [details]
possible fix
Another possible fix, but I don't think it will help as it touches things never previously touched. I don't think the issue is the USER registers, but it's worth a shot I suppose.
Patch from comment #11 didn't work at all, not only it didn't fix the original issue but it even caused additional trouble (gdm wouldn't even show up.) Reproducibility information: * I cannot reproduce the GPU lockup on a Radeon HD 4350 card. * On the Radeon HD 6450, I can reproduce the GPU lockup with applications other than Firefox. I was able to do so with Claws Mail for example. The parent window has to be maximized for it to happen. Then, as soon as a title-less dialog box is opened (for example by pressing Ctrl+S for "Save As..."), the GPU lockup happens. I managed to fix the problem with a user-space stack update. I updated: * libdrm from version 2.4.26 to 2.4.33 * Mesa from version 7.11 to 8.0.3 * from xorg-x11-libX11 version 7.6 to libX11 version 1.5.0 and I no longer see the GPU lockup. So I guess I can close this bug as invalid, if the actual bug was in user-space. That's the problem with GPU drivers. It's impossible to test every combination of userspace and kernel drivers and there can be very subtle bugs with certain combinations like this one that are almost impossible to track down. |