GPU lockup on AMD A4-3400 APU when starting X server on opensource drivers. (works fine with fglrx)
Submitted by Azari
Assigned to Default DRI bug account
Description
I've had this lockup on this machine for the past few years, across several different kernel versions, different distributions, etc. Booting with KMS works fine, but the second a graphical environment starts (whether X or wayland-based), it locks up.
Booting Ubuntu with user-space mode-setting works, and then I can install FGLRX from there and everything works fine. After speaking with airlied on IRC, they suggested it could be a workaround that AMD has put into FGLRX that never made it into the opensource drivers, and that AMD might have to look into it.
CPU/GPU : A4-3400
Motherboard : GA-A75M-D2H ( http://www.gigabyte.com/products/product-page.aspx?pid=3930#ov )
journalctl log of the lockup:
------------------------------------------------------------
Jan 27 18:28:32 miku dbus-daemon[374]: Successfully activated service 'org.freedesktop.systemd1'
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: ring 0 stalled for more than 10000msec
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000003 on ring 0)
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: Saved 55 dwords of commands on ring 0.
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GPU softreset: 0x00000009
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS = 0xB1403828
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0 = 0x28000007
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1 = 0x00000007
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS = 0x20000840
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS2 = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x40000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00008000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x80228643
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00D034_DMA_STATUS_REG = 0x44C83D57
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_SOFT_RESET=0x00007F6B
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_SOFT_RESET=0x00000100
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS = 0x00003828
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE0 = 0x00000007
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GRBM_STATUS_SE1 = 0x00000007
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS = 0x20000040
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: SRBM_STATUS2 = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008674_CP_STALLED_STAT1 = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008678_CP_STALLED_STAT2 = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00867C_CP_BUSY_STAT = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_008680_CP_STAT = 0x00000000
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: R_00D034_DMA_STATUS_REG = 0x44C83D57
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: GPU reset succeeded, trying to resume
Jan 27 18:28:42 miku kernel: [drm] Found smc ucode version: 0x00011100
Jan 27 18:28:42 miku kernel: [drm] PCIE GART of 1024M enabled (table at 0x0000000000274000).
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: WB enabled
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8800c613fc00
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff8800c613fc0c
Jan 27 18:28:42 miku kernel: radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc90002432118
Jan 27 18:28:42 miku kernel: [drm] ring test on 0 succeeded in 1 usecs
Jan 27 18:28:42 miku kernel: [drm] ring test on 3 succeeded in 3 usecs
Jan 27 18:28:42 miku kernel: [drm] ring test on 5 succeeded in 1 usecs
Jan 27 18:28:42 miku kernel: [drm] UVD initialized successfully.
Jan 27 18:28:52 miku kernel: radeon 0000:00:01.0: ring 0 stalled for more than 10370msec
Jan 27 18:28:52 miku kernel: radeon 0000:00:01.0: GPU lockup (current fence id 0x0000000000000002 last fence id 0x0000000000000004 on ring 0)
Jan 27 18:28:52 miku kernel: [drm:r600_ib_test [radeon]] ERROR radeon: fence wait failed (-35).
Jan 27 18:28:52 miku kernel: [drm:radeon_ib_ring_tests [radeon]] ERROR radeon: failed testing IB on GFX ring (-35).
Jan 27 18:29:22 miku systemd[1]: Started Getty on tty2.
Activity
Attachment 121337, "dmesg log from the machine in question.":
dmesg_log.txtAttachment 121338, "Xorg log file from the machine in question.":
Xorg.0.logI forgot to add the PCI ID for the GPU in the initial report, it's 1002:9644
I have also added an attachment with lspci output for all the other devices, as well as attachments of the dmesg ouput and the xorg log.Attachment 121339, "lspci output with pci IDs for everything, from the machine in question.":
lspci_full.txt
@agd5fsubmitted a patch:Does this kernel patch help?
Patch 121340, "possible fix":
0001-drm-radeon-adjust-the-SX-constants-for-SUMO2.patch
(In reply to Alex Deucher from comment 4)
Created attachment 121340 [details] [review]
possible fix
Does this kernel patch help?
I just finished compiling and testing a kernel with that patch; it didn't help, it still has the same issues. =(
Thanks for the prompt reply by the way.I have something new to report after doing more testing.
It seems that if I launch weston with the pixman backend (weston --use-pixman), that works, but meanwhile, startx with 'exec twm' in .xinitrc doesn't work on first attempt, it causes the lockup.
However, after the lockup, if i try to startx again (still with twm), it suddenly works and i can start applications in twm and use the desktop. I managed to reproduce this with Xfce as well, the first 'startxfce4' after bootup will fail and lockup the GPU, and after it resets, I try again and Xfce works.
One thing of note is that when I finally do manage to get a DE started (after the GPU has locked up and reset once), glxinfo shows only "gallium on llvmpipe"; no hardware acceleration available.
So whatever is causing the lockup is something that X does at startup (even when a minimal X window manager like twm is used), but weston-pixman doesn't do.Attachment 121447, "startx with 'exec twm' in .xinitrc right after bootup; causes lockup.":
startx_twm_lockup__Xorg.0.logAttachment 121448, "second attempt after lockup; startx with 'exec twm' in .xinitrc suddenly works fine.":
startx_twm_afterlockup__Xorg.0.log(In reply to Alex Deucher from comment 7)
Check your xorg log and make sure acceleration is enabled.
It seems that acceleration disables itself after the first startx attempt locks up the GPU:
[ 326.027] (--) RADEON(0): Chipset: "SUMO2" (ChipID = 0x9644)
[ 326.027] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
[ 326.027] (II) Loading sub module "shadow"
[ 326.027] (II) LoadModule: "shadow"
[ 326.027] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 326.047] (II) Module shadow: vendor="X.Org Foundation"
[ 326.047] compiled for 1.18.0, module version = 1.1.0
[ 326.047] ABI class: X.Org ANSI C Emulation, version 0.4
[ 326.047] (II) RADEON(0): KMS Color Tiling: disabled
[ 326.047] (II) RADEON(0): KMS Color Tiling 2D: disabled
[...]
[ 326.247] (WW) RADEON(0): Direct rendering disabled
[ 326.247] (II) RADEON(0): Acceleration disabled
[...]
[ 326.252] (II) AIGLX: Screen 0 is not DRI2 capable
[ 326.252] (EE) AIGLX: reverting to software rendering
[ 326.329] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 326.331] (II) AIGLX: Loaded and initialized swrast
[ 326.331] (II) GLX: Initialized DRISWRAST GL provider for screen 0
The full log is in this attachment: https://bugs.freedesktop.org/attachment.cgi?id=121448
I also uploaded another xorg log from the first attempt that causes the lockup, in case you want to see the difference between the two or something.This issue hasn't had any activity since 2019-11-19. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.
