Bug 883536 - AMD Radeon HD 5450 (Gallium driver) does not wake from VT switch or suspend/resume in Fedora 18 (*ERROR* Failed to parse relocation -35!)
Summary: AMD Radeon HD 5450 (Gallium driver) does not wake from VT switch or suspend/r...
Keywords:
Status: CLOSED DUPLICATE of bug 849347
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 18
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-04 20:17 UTC by Jean-François Fortin Tam
Modified: 2013-03-18 21:42 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 18:38:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jean-François Fortin Tam 2012-12-04 20:17:22 UTC
I have a Radeon HD 5450, identified as follows in lspci:

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450/6350]

GNOME 3.6 says I am indeed running the Gallium 0.4 driver for "AMD Cedar".


In Fedora 18 with all the latest updates, putting the computer to sleep works, but resuming will result in a black screen (the monitor turns off) and locked up system: the keyboard LEDs (numlock, capslock) will not respond. Switching to another terminal with ctrl+alt+F2/3/4 does not work. However, the machine is still accessible through SSH.

Another way to reproduce it (strangely enough) is simply locking the gnome session, asking the lock shield to "log in as another user", then choosing the same user to log back in... which will trigger the bug.

Running "dmesg", I see the following suspicious messages being repeated 132 times:


[  503.508378] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[  503.509443] radeon 0000:01:00.0: GPU reset succeeded, trying to resume
[  503.521652] [drm] probing gen 2 caps for device 8086:29c1 = 1/0
[  503.523433] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[  503.523522] radeon 0000:01:00.0: WB enabled
[  503.523526] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8801608ddc00
[  503.539694] [drm] ring test on 0 succeeded in 1 usecs
[  503.740507] [drm] ib test on ring 0 succeeded in 0 usecs

[  503.740522] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[  503.741622] radeon 0000:01:00.0: GPU reset succeeded, trying to resume
[  503.758948] [drm] probing gen 2 caps for device 8086:29c1 = 1/0
[  503.760659] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[  503.760742] radeon 0000:01:00.0: WB enabled
[  503.760745] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8801608ddc00
[  503.776901] [drm] ring test on 0 succeeded in 1 usecs
[  503.977508] [drm] ib test on ring 0 succeeded in 0 usecs

...etc.


I had no such problems with Fedora 17 even with its latest (3.6.7?) kernel. Please let me know what information I can provide to solve this.

Comment 1 Jean-François Fortin Tam 2012-12-04 20:32:42 UTC
Ugh, while it was reliably reproducible with the two methods above, the bug has now stopped occuring after a few tries (and yet I did not change software packages, settings or hardware).

Comment 2 Jean-François Fortin Tam 2012-12-05 05:05:38 UTC
Later on during the day, I gave it another try and the problem was reproducible again. I tested by simply booting the computer up to the login screen, and asking it to suspend from the login screen.

The issue seems to occur randomly.

Comment 3 Jorge Martínez López 2013-01-18 12:08:11 UTC
I am experiencing the same problem. It seems that I can trigger it by just switching to a terminal (Ctrl+Alt+F2) and switching back to X11:

Jan 18 10:09:51 baraddur systemd[1]: SELinux Got Sender :1.0
Jan 18 10:09:51 baraddur systemd[1]: Starting Getty on tty2...
Jan 18 10:09:51 baraddur systemd[1]: Started Getty on tty2.
Jan 18 10:09:54 baraddur kernel: [  331.839412] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
Jan 18 10:09:54 baraddur kernel: [  331.839431] [drm] Disabling audio support
Jan 18 10:09:54 baraddur kernel: [  331.840489] radeon 0000:01:05.0: GPU reset succeeded, trying to resume
Jan 18 10:09:54 baraddur kernel: [  331.851558] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
Jan 18 10:09:54 baraddur kernel: [  331.851604] radeon 0000:01:05.0: WB enabled
Jan 18 10:09:54 baraddur kernel: [  331.851607] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff8801fe84ac00
Jan 18 10:09:54 baraddur kernel: [  331.882812] [drm] ring test on 0 succeeded in 1 usecs
Jan 18 10:09:54 baraddur kernel: [  331.882814] [drm] Enabling audio support
Jan 18 10:09:54 baraddur kernel: [  331.885267] [drm] ib test on ring 0 succeeded in 0 usecs
...
(The errors repeat)

$ uname -ar
Linux baraddur.jorgeml.net 3.7.2-201.fc18.x86_64 #1 SMP Fri Jan 11 22:16:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$lspci -vv 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880 [Radeon HD 4290] (prog-if 00 [VGA controller])
	Subsystem: Giga-byte Technology Device d000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 4 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
	Region 1: I/O ports at be00 [size=256]
	Region 2: Memory at fd6e0000 (32-bit, non-prefetchable) [size=64K]
	Region 5: Memory at fd500000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: <access denied>
	Kernel driver in use: radeon

Comment 4 Matt Hirsch 2013-01-22 05:38:27 UTC
I have this same problem, as described above, now with kernel 3.7.2-204.

...
[  139.736410] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[  139.737789] radeon 0000:01:05.0: GPU reset succeeded, trying to resume
[  139.752150] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
[  139.752605] radeon 0000:01:05.0: WB enabled
[  139.752615] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff8801ff7d3c00
[  139.752937] radeon 0000:01:05.0: setting latency timer to 64
[  139.786102] [drm] ring test on 0 succeeded in 0 usecs
[  139.786134] [drm] ib test on ring 0 succeeded in 0 usecs
...

$ uname -ar
Linux wick 3.7.2-204.fc18.x86_64 #1 SMP Wed Jan 16 16:22:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -vv -s 01:05.0
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series] (prog-if 00 [VGA controller])
	Subsystem: Hewlett-Packard Company Device 1604
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 1: I/O ports at 3000 [size=256]
	Region 2: Memory at f0300000 (32-bit, non-prefetchable) [size=64K]
	Region 5: Memory at f0200000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: <access denied>
	Kernel driver in use: radeon

Comment 6 Matt Hirsch 2013-01-24 07:35:02 UTC
Here is a potential workaround for the suspend part of this.

Create a file in /etc/pm/config.d called whatever you like (e.g. radeon).

Put this line in the file:

SUSPEND_MODULES="radeon";

The radeon module is removed before suspend and reinserted afterwards. My system seems stable afterwards.

Comment 7 Matt Hirsch 2013-01-24 07:41:27 UTC
Here is a potential workaround for the suspend part of this.

Create a file in /etc/pm/config.d called whatever you like (e.g. radeon).

Put this line in the file:

SUSPEND_MODULES="radeon";

The radeon module is removed before suspend and reinserted afterwards. My system seems stable afterwards.

Comment 8 Jean-François Fortin Tam 2013-01-24 14:05:46 UTC
Nope, that doesn't work for me, still fails to resume after 1-3 tries. Furthermore, the fact that the radeon will hang in the same way by just switching virtual terminals with ctrl+alt+F3 and ctrl+alt+F1 (no suspend required) tells me it has nothing to do with power management.

Comment 9 Matt Hirsch 2013-01-24 16:50:23 UTC
After further testing unfortunately it doesn't work for me either. I guess I was lucky (unlucky?) enough for it to have randomly worked when I tried that last night. I haven't run into the problem when switching to the console.

Interestingly, I don't need a full reboot to fix the problem after it happens. It's enough to ssh in, run 'init 3' to switch out of graphics mode, and then 'init 5' to switch back.

Comment 10 Jean-François Fortin Tam 2013-01-26 03:12:47 UTC
Also related: bug #882059

Comment 11 Jon Dufresne 2013-01-26 19:45:36 UTC

*** This bug has been marked as a duplicate of bug 849347 ***

Comment 12 Jean-François Fortin Tam 2013-02-11 04:05:53 UTC
Reopening. Still seeing the problem after the latest updates of mesa-* from bug #849347

Comment 13 Jérôme Glisse 2013-02-13 18:38:28 UTC
Ok found the issue and they are duplicate.

*** This bug has been marked as a duplicate of bug 849347 ***

Comment 14 murenti 2013-03-18 21:37:13 UTC
I have Linux 18 64b
Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

When Fedora (Not me) comes out of sleep the wireless can't reconnect to the router.  This also happened with Fedora 16 and I upgraded to Fedora 17 which fixed the issue but this time I would be grateful for a fix, can you please help?

Comment 15 Jorge Martínez López 2013-03-18 21:40:32 UTC
murenti, please open a separate bug for your issue as it is not related to this one.

Comment 16 murenti 2013-03-18 21:42:22 UTC
Ok, many thanks, I have been searching for a current post, sorry I will open a new ticket.  Before I do that I am going to explore some wireless software updates and checks and then come back if I need to.
Many thanks for quick response


Note You need to log in before you can comment on or make changes to this bug.