Hello!
The system running the current mainline Linux shows black screen for me reliably if I run the unshield program on xterm. Linux 3.7 is OK.
The bisection found the first bad commit:
deab48f140d28d788cb2b5705761a92b02e3440d Alex Deucher alexander.deucher@amd.com
drm/radeon: add dma engine support for vm pt updates on si (v2)
Async DMA has a special packet for contiguous pt updates which saves overhead.
v2: rebase
It can be reverted on top on the mainline Linux, but I still get the black screen. I guess it's the first commit that is bad for my video card, but not the only one.
While bisecting, I noticed another manifestation of the problem - unshield would hang for a few seconds and continue. Following appears in the kernel log:
[ 31.476089] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 31.476094] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000006 last fence id 0x0000000000000005)
# lspci -vnn -s 01:00.0 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] [1002:94c3] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:01c2] Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f5000000 (64-bit, non-prefetchable) [size=64K] I/O ports at b000 [size=256] [virtual] Expansion ROM at f4000000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: radeon
The kernel .config file is attached.
On Fri, Dec 21, 2012 at 10:33 AM, Pavel Roskin proski@gnu.org wrote:
Hello!
The system running the current mainline Linux shows black screen for me reliably if I run the unshield program on xterm. Linux 3.7 is OK.
The bisection found the first bad commit:
deab48f140d28d788cb2b5705761a92b02e3440d Alex Deucher alexander.deucher@amd.com
drm/radeon: add dma engine support for vm pt updates on si (v2) Async DMA has a special packet for contiguous pt updates which saves overhead. v2: rebase
That patch only affects SI chips which yours is not, so it's probably not what's causing problems for you.
It can be reverted on top on the mainline Linux, but I still get the black screen. I guess it's the first commit that is bad for my video card, but not the only one.
While bisecting, I noticed another manifestation of the problem - unshield would hang for a few seconds and continue. Following appears in the kernel log:
[ 31.476089] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec [ 31.476094] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000006 last fence id 0x0000000000000005)
# lspci -vnn -s 01:00.0 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] [1002:94c3] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:01c2] Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f5000000 (64-bit, non-prefetchable) [size=64K] I/O ports at b000 [size=256] [virtual] Expansion ROM at f4000000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: radeon
This looks like a duplicate of this issue: http://lists.freedesktop.org/archives/dri-devel/2012-December/032139.html http://lists.freedesktop.org/archives/dri-devel/2012-December/032291.html
Some of the ttm changes in 3.8 seem problematic.
Alex
Hello, Alex!
Thank you for your reply!
Quoting Alex Deucher alexdeucher@gmail.com:
That patch only affects SI chips which yours is not, so it's probably not what's causing problems for you.
OK, maybe. Bisection can lead to a wrong commit if the problem is not 100% reproducible.
This looks like a duplicate of this issue: http://lists.freedesktop.org/archives/dri-devel/2012-December/032139.html http://lists.freedesktop.org/archives/dri-devel/2012-December/032291.html
Some of the ttm changes in 3.8 seem problematic.
I'm away wrong that system until Wednesday. I'll try that patch. If it doesn't help, I'll repeat the bisection.
Hello, Alex!
Sorry for delay with the reply! It turns out I made a huge blunder while bisecting. I assumed that the radeon drivers would load from lib/modules, so I didn't bother running "make install" once I saw that only the modules are recompiled. In fact, the video modules were loaded from initrd (unlike, say, WiFi drivers I'm used to deal with), so skipping "make install" would leave me with the drivers from the previous iteration.
The commit that introduces the problem is actually 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 drm/radeon: use async dma for ttm buffer moves on 6xx-SI
I could fix it simply by reverting the first chunk, that is, the part modifying r600_asic.
I tried the current mainline kernel 3.8.0-rc2+ (commit 5f243b9b46a22e5790dbbc36f574c2417af49a41) and it doesn't have the problem! However, the chunk of the "bad" patch can still be reverted with no conflicts.
So I assume the problem was fixed in another place.
If you want, I can make another bisect to find the commit that fixed the problem. But if you have an idea what it was, then that it :)
Just a reminder, the problem is a hang when running unshield on some proprietary Windows drivers in xterm on Fedora 17 x86_64 with Radeon RV610.
Hello Alex,
I've bisected the change that fixed the problem. I wanted to make sure it wasn't some random change. The good news is that it wasn't!
The winner is:
commit 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb Author: Alex Deucher alexander.deucher@amd.com Date: Wed Jan 2 18:30:21 2013 -0500
drm/radeon/r6xx: fix DMA engine for ttm bo transfers
count must be a multiple of 2. Fixes crashes on R6xx chips reported by a number of people.
Cc: Borislav Petkov bp@alien8.de Cc: Markus Trippelsdorf markus@trippelsdorf.de Reviewed-by: Jerome Glisse jglisse@redhat.com Tested-by: Jerome Glisse jglisse@redhat.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
:040000 040000 f641a4e6cb7ac7426a8a80f3a4cf51a6320f95d4 e974cd1737fafb82c6dc8f85dbcdf6cacfea893a M drivers
Thank you!!!
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Pavel Roskin