| Priority | medium |
|---|---|
| Bug ID | 60802 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman) |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | alexandre.f.demers@gmail.com |
| Hardware | Other |
| Status | NEW |
| Version | unspecified |
| Component | DRM/Radeon |
| Product | DRI |
Since temporary fix for bug 58354, I'm able to test some applications once again and I've found out some rendering issues. In Unigine Tropics, Unigine Heaven and under another test that used to be OK (I'll come back with its name soon, I think it was Amnesia's render test), some textures are not rendered correctly with kernel 3.8-rc7 (vanilla), but are OK with kernel 3.7.7 from Archlinux 64. I'm pretty sure an earlier 3.8-rcX was rendering OK with the "still unamed" application. I'm testing with latest mesa and drm on a XFX HD6950. I'll try to bisect it later.
It seems I'll have to bisect because even 3.8-rc1 displays the corruption. I'm attaching a screenshot from RendererFeattest as a corrupted reference.
Created attachment 74793 [details]
Corrupted texture on background
But the texture on the cubes seems to be ok
(In reply to comment #2) > Created attachment 74793 [details] > Corrupted texture on background > > But the texture on the cubes seems to be ok The text is also corrupted
bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher <alexander.deucher@amd.com> Date: Thu Dec 13 18:57:07 2012 -0500 drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| What | Removed | Added |
|---|---|---|
| Summary | Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman) | (bisect 8696e33f06b0c52195152cc6a0e3d52233f486c1) Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman) |
| What | Removed | Added |
|---|---|---|
| Summary | (bisect 8696e33f06b0c52195152cc6a0e3d52233f486c1) Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman) | Corruption with DMA ring on cayman |
| Product | DRI | Mesa |
| Component | DRM/Radeon | Drivers/Gallium/r600 |
(In reply to comment #4) > bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 > commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 > Author: Alex Deucher <alexander.deucher@amd.com> > Date: Thu Dec 13 18:57:07 2012 -0500 > > drm/radeon: bump version for CS ioctl support for async DMA > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> That just enables the use of DMA by the 3D driver, so the issue is in mesa. This looks like a duplicate of bug 60236.
(In reply to comment #5) > (In reply to comment #4) > > bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 > > commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 > > Author: Alex Deucher <alexander.deucher@amd.com> > > Date: Thu Dec 13 18:57:07 2012 -0500 > > > > drm/radeon: bump version for CS ioctl support for async DMA > > > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > > That just enables the use of DMA by the 3D driver, so the issue is in mesa. > This looks like a duplicate of bug 60236. You are right, that's what I thought about the bad identified commit. I don't have the same symptoms as in bug 60236, but I'll have a look anyway. Otherwise, I'll use kernel 3.8-rc7 and I'll bisect mesa to track the bug down.
So I followed bug 60236. I sync mesa since the proposed mesa patch had already been pushed. I tested with kernel 3.8.0 and the bug was still there. I then applied the proposed kernel patch over 3.8.0 (after fixing it because it was not properly applying), built and restarted using this newly built kernel. Result: the bug is still there and the same. So this bug is not the same as bug 60236. I'll try to bisect mesa in the next couple of days. BTW, I bought Bastion on Steam and tested it. The same bug appears (or not exactly as for the demos depending of the kernel I was using), so it is not limited to some demo cases.
Culprit commit in mesa identified as: 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc Author: Jerome Glisse <jglisse@redhat.com> Date: Mon Jan 7 17:45:59 2013 -0500 r600g: add async for staging buffer upload v2 v2: Add virtual address to dma src/dst offset for cayman Signed-off-by: Jerome Glisse <jglisse@redhat.com> :040000 040000 4ef6e784f3acb7f21da0c5e1923810c78917d16d 55f0ce7d9793ce04d392fc7943059545053a9d79 M src So, it is the same commit as for bug 60236, but applying patches from it doesn't help.
I got similar looking corruptions in Counter Strike: Source and Trine 2 (via Steam) since my update from kernel 3.7.9 to 3.8.0 this morning (Arch Linux x86_64, newest mesa from git). When I get back from the university I will check if I can confirm your commit as the culprit.
Ok, I tested it and I can confirm commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc as the culprit for the corruption in Trine 2. Counter Strike: Source seems to be another problem, I will bisect it tomorrow and open a new bug for it.
I also noticed this in dmesg: [ 3385.870124] radeon 0000:01:00.0: GPU fault detected: 146 0x0005d004 [ 3385.870138] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00002400 [ 3385.870146] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x050D0004 [ 3385.870153] radeon 0000:01:00.0: GPU fault detected: 146 0x0005a004 [ 3385.870160] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870165] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870172] radeon 0000:01:00.0: GPU fault detected: 146 0x0005e004 [ 3385.870178] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870183] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870189] radeon 0000:01:00.0: GPU fault detected: 146 0x0025a004 [ 3385.870195] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870200] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870206] radeon 0000:01:00.0: GPU fault detected: 146 0x00059004 [ 3385.870211] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870217] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870223] radeon 0000:01:00.0: GPU fault detected: 146 0x0065e004 [ 3385.870228] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870233] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870239] radeon 0000:01:00.0: GPU fault detected: 146 0x0035a004 [ 3385.870245] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870250] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ 3385.870256] radeon 0000:01:00.0: GPU fault detected: 146 0x0075e004 [ 3385.870261] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ 3385.870267] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 [ I don't know exactly for how long it has been happening, but this recent for sure since it was not there about 2 weeks ago.
I got this too, but this was already there before I updated to the 3.8.0 kernel. So I think it has nothing to do with this problem.
(In reply to comment #12) > I got this too, but this was already there before I updated to the 3.8.0 > kernel. So I think it has nothing to do with this problem. Thanks for letting me know. I may know an already opened bug about it...
(In reply to comment #11) > I also noticed this in dmesg: > [ 3385.870124] radeon 0000:01:00.0: GPU fault detected: 146 0x0005d004 > [ 3385.870138] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00002400 > [ 3385.870146] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x050D0004 > [ 3385.870153] radeon 0000:01:00.0: GPU fault detected: 146 0x0005a004 > [ 3385.870160] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870165] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ 3385.870172] radeon 0000:01:00.0: GPU fault detected: 146 0x0005e004 > [ 3385.870178] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870183] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ 3385.870189] radeon 0000:01:00.0: GPU fault detected: 146 0x0025a004 > [ 3385.870195] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870200] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ 3385.870206] radeon 0000:01:00.0: GPU fault detected: 146 0x00059004 > [ 3385.870211] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870217] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ 3385.870223] radeon 0000:01:00.0: GPU fault detected: 146 0x0065e004 > [ 3385.870228] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870233] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ 3385.870239] radeon 0000:01:00.0: GPU fault detected: 146 0x0035a004 > [ 3385.870245] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870250] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ 3385.870256] radeon 0000:01:00.0: GPU fault detected: 146 0x0075e004 > [ 3385.870261] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00000000 > [ 3385.870267] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x00000000 > [ > > I don't know exactly for how long it has been happening, but this recent for > sure since it was not there about 2 weeks ago. Can you bisect mesa to see when this started?
Yes, I will. Should I begin by looking on the kernel's side or on mesa's side?
I am currently bisecting mesa to see where the dmesg output starts.
(In reply to comment #15) > Yes, I will. Should I begin by looking on the kernel's side or on mesa's > side? It's most likely a mesa issue.
Ok, just finished bisecting, this is the first commit with the= dmesg errors: e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit commit e110c98cae0ceae47db6cf26c08707505ce92479 Author: Alex Deucher <a= lexander.deucher@amd.com> Date: Sun Jan 27 22:13:52 2013 -0500 r600g: don't emit WAIT_UNTIL on cayman/TN (v2) It shouldn't be needed and older kernels don't support it. v2: Replace with PS partial flush as before. Fixes: https://bugs.freedesktop.org/show_bug.c= gi?id=3D59945 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Marek Ol=C5=A1=C3=A1k <maraeo@gmail.com> And if I remember correctly I first noticed it with kernel 3.7.5 or 3.7.6, = but I thing this was also around the time this mesa commit was pushed so it may have nothing to do with this kernel versions.
(In reply to comment #= 18) > Ok, just finished bisecting, this is the first c= ommit with the dmesg errors: >=20 > e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit > commit e110c98cae0ceae47db6cf26c08707505ce92479 > Author: Alex Deucher <alexander.deucher@amd.com> > Date: Sun Jan 27 22:13:52 2013 -0500 >=20 > r600g: don't emit WAIT_UNTIL on cayman/TN (v2) >=20=20=20=20=20 > It shouldn't be needed and older kernels don't support > it. >=20=20=20=20=20 > v2: Replace with PS partial flush as before. >=20=20=20=20=20 > Fixes: > https://bugs.freedesktop.org/show_bug.c= gi?id=3D59945 >=20=20=20=20=20 > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > Reviewed-by: Marek Ol=C5=A1=C3=A1k <maraeo@gmail.com> >=20 > And if I remember correctly I first noticed it with kernel 3.7.5 or 3.= 7.6, > but I thing this was also around the time this mesa commit was pushed = so it > may have nothing to do with this kernel versions. I'll double check if I'm getting the same thing as you. If this is right, we should open a different bug to track it.
(In reply to comment #= 18) > Ok, just finished bisecting, this is the first c= ommit with the dmesg errors: >=20 > e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit > commit e110c98cae0ceae47db6cf26c08707505ce92479 > Author: Alex Deucher <alexander.deucher@amd.com> > Date: Sun Jan 27 22:13:52 2013 -0500 >=20 > r600g: don't emit WAIT_UNTIL on cayman/TN (v2) >=20=20=20=20=20 > It shouldn't be needed and older kernels don't support > it. >=20=20=20=20=20 > v2: Replace with PS partial flush as before. >=20=20=20=20=20 > Fixes: > https://bugs.freedesktop.org/show_bug.c= gi?id=3D59945 >=20=20=20=20=20 > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > Reviewed-by: Marek Ol=C5=A1=C3=A1k <maraeo@gmail.com> >=20 > And if I remember correctly I first noticed it with kernel 3.7.5 or 3.= 7.6, > but I thing this was also around the time this mesa commit was pushed = so it > may have nothing to do with this kernel versions. I ended up with a different commit than yours when bisecting: 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc It's the one just prior yours and it is also the one identified as being the culprit of the current bug (comment = 8). Could you check a second time?
(In reply to comment #20) > I ended up with a different commit than yours when bisecting: > 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit > commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc > > It's the one just prior yours and it is also the one identified as being the > culprit of the current bug (comment 8). Could you check a second time? I just build 325422c49449acdd8df1eb2ca8ed81f7696c38cc but I can't trigger any dmesg output. What do you use to test for it?