This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 849347 - radeon driver cannot handle restarting xorg server sometimes (fails with: *ERROR* Failed to parse relocation -35!)
radeon driver cannot handle restarting xorg server sometimes (fails with: *ER...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
18
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
RejectedNTH
:
: 866992 882059 883536 910559 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-18 12:04 EDT by Reartes Guillermo
Modified: 2013-10-25 11:29 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 910559 (view as bug list)
Environment:
Last Closed: 2013-02-25 09:51:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg, f17, when the error happened (203.73 KB, application/octet-stream)
2012-08-18 12:04 EDT, Reartes Guillermo
no flags Details
xorg.0.log file, all looks good (44.29 KB, text/plain)
2012-08-18 12:06 EDT, Reartes Guillermo
no flags Details
xorg.0.log.old, all looks good (44.17 KB, text/plain)
2012-08-18 12:07 EDT, Reartes Guillermo
no flags Details
messages showing the error (2.05 MB, text/plain)
2012-08-18 12:09 EDT, Reartes Guillermo
no flags Details

  None (edit)
Description Reartes Guillermo 2012-08-18 12:04:52 EDT
Created attachment 605344 [details]
dmesg, f17, when the error happened

Description of problem:

I had an user (user4) that holds self compiled KDE-SC builds.
I had my user, which uses Fedora's KDE.
This happened only one time for now.

I was going to test my KDE-SC build (because i am trying to reproduce
another bug) on that user.This worked normaly exept for this one time.
I was logged with my user, then choose Leave -> Switch User (KDE).
The result was strange, KDM was bypassed! i jumped directly to te
user4's desktop, and after logout, the screen went black until y logged
in over ssh and reboot the machine.

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
radeon 0000:01:00.0: GPU reset succeed
[drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
radeon 0000:01:00.0: WB enabled
radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880423b94c00
[drm] ring test on 0 succeeded in 2 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!

This went so until i rebooted the system.
After rebooting, i tried again and i could not reproduce the issue.

Version-Release number of selected component (if applicable):

Fedora: 17
kernel: 3.5.1-1.fc17.x86_64
xorg-x11-drv-ati.x86_64  6.14.4-6.20120602git930760942.fc17

How reproducible:
it happened only one time, so far.

What i did:
1. login normal user
2. use kde switch user to start a new user 
3. kdm is bypassed and one gets to user4's desktop without a password
4. logout user4
5. black screen.

Actual results:
black screen

Expected results:
normal xorg's switch user

Additional info:
Comment 1 Reartes Guillermo 2012-08-18 12:06:22 EDT
Created attachment 605345 [details]
xorg.0.log file, all looks good
Comment 2 Reartes Guillermo 2012-08-18 12:07:04 EDT
Created attachment 605346 [details]
xorg.0.log.old, all looks good
Comment 3 Reartes Guillermo 2012-08-18 12:09:57 EDT
Created attachment 605350 [details]
messages showing the error
Comment 4 Reartes Guillermo 2012-08-18 12:11:10 EDT
Additional info:

the keyboard did not function, switching vt did not work, even the keyboard leds did not work.
Comment 5 Jan Sedlák 2012-09-26 08:26:55 EDT
It's still happening in F18 Alpha. Here is my smolt profile: http://www.smolts.org/client/show/pub_e17529fc-c1b4-4546-9b15-fccf5e9b00e6. It happened when I tried to switch to console (ctrl+alt+f2) and back (alt+f1) several times. Dmesg output was:
[  238.214785] radeon 0000:01:00.0: GPU reset succeeded, trying to resume
[  238.238226] [drm] probing gen 2 caps for device 1002:5a16 = 2/0
[  238.238231] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[  238.243788] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[  238.244227] radeon 0000:01:00.0: WB enabled
[  238.244230] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff88012e96fc00
[  238.260590] [drm] ring test on 0 succeeded in 1 usecs
[  238.477665] [drm] ib test on ring 0 succeeded in 0 usecs
[  238.478161] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
Comment 6 Artur Flinta 2012-09-26 10:32:21 EDT
Same issue for me. My smolt profile:
http://www.smolts.org/client/show/pub_5c022204-5f73-41b3-a89a-21f59c8c9e4b
According to HP specification my graphics is AMD FirePro M5950.
Comment 7 redhat 2012-09-30 10:09:19 EDT
Can confirm this using Mobility Radeon 4200. Also happens after resume from suspend...
Comment 8 Reartes Guillermo 2012-10-26 18:28:10 EDT
It seems i reported it back again here (CAICOS: 863726 dup?)
Comment 9 redhat 2012-10-27 21:37:21 EDT
seems fixed in 3.6.3-3.fc18.x86_64?
Comment 10 Tim Flink 2012-12-13 05:13:37 EST
c#9 makes it sound like this might have been fixed. Can someone else confirm whether this is true or not?
Comment 11 redhat 2012-12-13 09:47:17 EST
(In reply to comment #10)
> c#9 makes it sound like this might have been fixed.

Sorry, it was just kind of an anomaly that it works several times. It's definitely not fixed. (I'm using fc17 install media kernel - 3.3.4 i think - but I'm happy to test anything you like...)
Comment 12 Adam Williamson 2012-12-19 16:08:11 EST
Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . Rejected as NTH - this seems limited in impact and severity and it's too late to be meddling with graphics drivers for non-showstopper issues. It can be fixed well with an update, if a fix appears.
Comment 13 Brian Wheeler 2013-01-19 09:59:25 EST
Its happening every time on suspend/resume on my laptop so it really sucks.

I did an upgrade from f17 and I'm running XFCE.
Comment 14 Hin-Tak Leung 2013-01-19 15:01:32 EST
Just happened to me, on an up-to-date F18 system, coming out of suspend. I thought it was a new regression, as I could suspend/resume well enough every few days until now.

When coming out of suspend, the screen flickered but could not re-establish; have to reboot to get a usable machine back. The log is filled with the below, every second or so, before reboot (i.e. tens to hundred of times):
--------
Jan 19 18:57:22 localhost kernel: [160042.300504] [drm] radeon: ring at 0x0000000080001000
Jan 19 18:57:22 localhost kernel: [160042.300532] [drm] ring test succeeded in 0 usecs
Jan 19 18:57:22 localhost kernel: [160042.711097] [drm] ib test succeeded in 0 usecs
Jan 19 18:57:22 localhost kernel: [160042.711139] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
Jan 19 18:57:22 localhost kernel: [160042.712170] radeon 0000:01:05.0: GPU reset succeeded, trying to resume
Jan 19 18:57:23 localhost kernel: [160043.539159] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
Jan 19 18:57:23 localhost kernel: [160043.559446] [drm] PCIE GART of 512M enabled (table at 0x0000000035C00000).
Jan 19 18:57:23 localhost kernel: [160043.559483] radeon 0000:01:05.0: WB enabled
Jan 19 18:57:23 localhost kernel: [160043.559494] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x0000000080000000 and cpu addr 0xffff8800363b8000
--------------

kernel-3.7.2-201.fc18.x86_64
libdrm-2.4.40-1.fc18.x86_64
xorg-x11-drv-ati-7.0.0-0.8.20121015gitbd9e2c064.fc18.x86_64

The last two times I suspended/resumed okay was
with kernel-3.7.1-5.fc18.x86_64 a few days ago and 3.7.1-2.fc18.x86_64 about 12 days ago, according to the logs.

I have had the same libdrm and xorg-x11-drv-ati for nearly a month (upgraded to F18 around 22th of December) so if it is a regression, it would be the kernel.


BTW, I am rumming gnome-3 in fallback mode, if that matters.
Comment 15 Hin-Tak Leung 2013-01-20 12:32:10 EST
suspended/resumed twice on the same versions of things as previous without incidents... let's hope I don't see this prob too often...
Comment 16 redhat 2013-01-21 07:43:17 EST
*** Bug 866992 has been marked as a duplicate of this bug. ***
Comment 17 Matt Hirsch 2013-01-22 01:00:57 EST
Possible duplicate bug:

https://bugzilla.redhat.com/show_bug.cgi?id=883536

I'm also experiencing this (my info is in the above bug report).
Comment 18 Matt Hirsch 2013-01-24 02:34:12 EST
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, however I only started hitting this problem in f18, and only ever during a suspend, not with console switching. So perhaps this will not work for everyone.
Comment 19 Hin-Tak Leung 2013-01-24 07:21:48 EST
See this problem a 2nd time - with 3.7.2-204.fc18.x86_64 . BTW, there is a --quirk-radeon-off switch in pm-utils - anybody knows what it is supposed to do and what problems it solves?
Comment 20 Matt Hirsch 2013-01-24 11:52:23 EST
After further testing unfortunately my above solution doesn't reliably work for me either. I guess I was lucky (unlucky?) enough for it to have randomly worked when I tried that last night. 

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 21 Jean-François Fortin Tam 2013-01-25 22:04:41 EST
If any of you have the knowledge to do that, upstream (https://bugs.freedesktop.org/show_bug.cgi?id=54133) needs somebody to bisect this to locate when exactly the issue originated...
Comment 22 Jon Dufresne 2013-01-26 14:36:54 EST
*** Bug 882059 has been marked as a duplicate of this bug. ***
Comment 23 Jon Dufresne 2013-01-26 14:43:14 EST
This bug occurs in F18 as well. Bumping version.
Comment 24 Jon Dufresne 2013-01-26 14:45:36 EST
*** Bug 883536 has been marked as a duplicate of this bug. ***
Comment 25 Jerome Glisse 2013-01-30 15:21:46 EST
Please try if installing mesa package from this scratch build helps :

http://koji.fedoraproject.org/koji/taskinfo?taskID=4915728

You need to at least install mesa-libGL mesa-dri-drivers (from this build)
Comment 26 Michal Nowak 2013-01-30 16:26:43 EST
Installed and will test, thought I haven't seen the issue for some time.
Comment 27 redhat 2013-01-30 20:15:23 EST
@Jerome: nothing changed. (Fedora rawhide)
Comment 28 Jean-François Fortin Tam 2013-01-30 20:16:13 EST
Hi Jérome,
I tried installing all the non-"devel" rpm packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=4915729 by doing a "yum install *.rpm", but I get a dependency problem:

Error: Package: cairo-1.12.8-2.fc18.i686 (@fedora)
           Requires: libGL.so.1
           Removing: mesa-libGL-9.0.1-3.fc18.i686 (@updates)
               libGL.so.1
           Updated By: mesa-libGL-9.0.1-4.fc18.x86_64 (/mesa-libGL-9.0.1-4.fc18.x86_64)
               Not found
           Available: mesa-libGL-9.0.1-1.fc18.i686 (fedora)
               libGL.so.1

Error: Package: mesa-libGLU-9.0.0-1.fc18.i686 (@fedora)
           Requires: libGL.so.1
           Removing: mesa-libGL-9.0.1-3.fc18.i686 (@updates)
               libGL.so.1
           Updated By: mesa-libGL-9.0.1-4.fc18.x86_64 (/mesa-libGL-9.0.1-4.fc18.x86_64)
               Not found
           Available: mesa-libGL-9.0.1-1.fc18.i686 (fedora)
               libGL.so.1


Same conflict if I try to do a yum install for only the two packages (mesa-libGL and mesa-dri-drivers) you suggested, or if I try to do it with "rpm -i"...
Comment 29 Adam Williamson 2013-01-30 20:22:55 EST
can you remove the i686 packages temporarily? your problem is happening because you have both i686 and x86_64 cairo and mesa installed, but jerome only provided an x86_64 scratch build.
Comment 30 Hin-Tak Leung 2013-01-30 21:14:40 EST
(In reply to comment #29)
> can you remove the i686 packages temporarily? your problem is happening
> because you have both i686 and x86_64 cairo and mesa installed, but jerome
> only provided an x86_64 scratch build.

That's not true - jerome's url links to both i686 and x86_64 builds. Here is the wget from my command history (I missed mesa-libgbm.i686 in the first 'yum localupdate' so yum was trying to get the newer matching mesa-libgbm.i686 from fedora/updates which fails, obviously).

Yes, if you are on a bi-arch system it means you probably have to do the whole 10+ packages like I do: 

wget -m http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/khrplatform-devel-9.0.1-4.fc18.noarch.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-dri-drivers-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-dri-filesystem-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libEGL-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libEGL-devel-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libgbm-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libGL-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libGL-devel-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libGLES-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libOSMesa-devel-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5729/4915729/mesa-libglapi-9.0.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/5730/4915730/mesa-dri-drivers-9.0.1-4.fc18.i686.rpm http://kojipkgs.fedoraproject.org//work/tasks/5730/4915730/mesa-dri-filesystem-9.0.1-4.fc18.i686.rpm http://kojipkgs.fedoraproject.org//work/tasks/5730/4915730/mesa-libEGL-9.0.1-4.fc18.i686.rpm http://kojipkgs.fedoraproject.org//work/tasks/5730/4915730/mesa-libGL-9.0.1-4.fc18.i686.rpm http://kojipkgs.fedoraproject.org//work/tasks/5730/4915730/mesa-libGL-devel-9.0.1-4.fc18.i686.rpm http://kojipkgs.fedoraproject.org//work/tasks/5730/4915730/mesa-libglapi-9.0.1-4.fc18.i686.rpm 

  wget -m kojipkgs.fedoraproject.org/work/tasks/5730/4915730/mesa-libgbm-9.0.1-4.fc18.i686.rpm

I did 
   ls /var/lib/yum/yumdb/m | grep mesa | cut -f 2- -d - | sort | grep i686
   ls /var/lib/yum/yumdb/m | grep mesa | cut -f 2- -d - | sort | grep -v i686
first to see what I have installed. YMMV, depending on how complete your i686 dev environment in a biarch system is.
Comment 31 Michal Nowak 2013-01-31 02:46:54 EST
(In reply to comment #27)
> @Jerome: nothing changed. (Fedora rawhide)

What you mean by that? Still fails to restart?
Comment 32 Matt Hirsch 2013-01-31 05:48:54 EST
The x86_64 rpms from that koji link solved the suspend problem for me. 

$ lspci | grep VGA
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series]

$ uname -a
Linux wick 3.7.4-204.fc18.x86_64 #1 SMP Wed Jan 23 16:44:29 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -qa | grep mesa
mesa-libGL-9.0.1-4.fc18.x86_64
mesa-dri-filesystem-9.0.1-3.fc18.x86_64
mesa-libGLU-9.0.0-1.fc18.x86_64
mesa-dri-filesystem-9.0.1-3.fc18.i686
mesa-libGLES-9.0.1-4.fc18.x86_64
mesa-dri-drivers-9.0.1-3.fc18.x86_64
mesa-libwayland-egl-9.0.1-4.fc18.x86_64
mesa-libgbm-9.0.1-3.fc18.i686
mesa-libEGL-9.0.1-3.fc18.i686
mesa-libglapi-9.0.1-4.fc18.x86_64
mesa-libOSMesa-9.0.1-4.fc18.x86_64
mesa-dri-drivers-9.0.1-3.fc18.i686
mesa-libGL-9.0.1-3.fc18.i686
mesa-libglapi-9.0.1-3.fc18.i686
mesa-libxatracker-9.0.1-4.fc18.x86_64
mesa-libgbm-9.0.1-4.fc18.x86_64
mesa-libEGL-9.0.1-4.fc18.x86_64
Comment 33 redhat 2013-01-31 06:18:18 EST
(In reply to comment #31)
> (In reply to comment #27)
> > @Jerome: nothing changed. (Fedora rawhide)
> 
> What you mean by that? Still fails to restart?

Yes. And still resume-from-suspend/switch-vt problems. Following produces this problem ever since i installed kernel 3.5 (which is the reason why i'm still on 3.3.4.fc17): 
1. Login
2. Start glxgears
3. STRG-ALT-F2
4. STRG-ALT-F1
5. Loop steps 3 and 4 until it breaks (usually not needed if glxgears running, but as this is still a bit random to me, i want to be sure)
Comment 34 Michal Nowak 2013-01-31 06:40:19 EST
(In reply to comment #33)
> Yes. And still resume-from-suspend/switch-vt problems. Following produces
> this problem ever since i installed kernel 3.5 (which is the reason why i'm
> still on 3.3.4.fc17): 
> 1. Login
> 2. Start glxgears
> 3. STRG-ALT-F2
> 4. STRG-ALT-F1
> 5. Loop steps 3 and 4 until it breaks (usually not needed if glxgears
> running, but as this is still a bit random to me, i want to be sure)

Fairly good reproducer. No change with those new packages.

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Thames XT/GL [Radeon HD 7600M Series] (prog-if 00 [VGA controller])
Comment 35 Fedora Update System 2013-01-31 15:05:38 EST
mesa-9.0.1-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mesa-9.0.1-4.fc18
Comment 36 Jerome Glisse 2013-01-31 15:09:28 EST
So it seems there is different bugs. People for who the update doesn't solve the issue please each one of you open a new bug and attach full dmesg and xorg log. Also provide a small description of your setup (number of screen, resolution, orientation (portrait/landscape...)) and a typical reproducer.

At this point it's one person one bug rules. Thanks
Comment 37 Michal Nowak 2013-01-31 16:10:09 EST
(In reply to comment #36)
> So it seems there is different bugs. People for who the update doesn't solve
> the issue please each one of you open a new bug and attach full dmesg and
> xorg log. Also provide a small description of your setup (number of screen,
> resolution, orientation (portrait/landscape...)) and a typical reproducer.
> 
> At this point it's one person one bug rules. Thanks

Well at least for me it was bug 883536 but it was closed as a dupe of this one...
Comment 38 redhat 2013-02-02 16:50:51 EST
(In reply to comment #36)
> So it seems there is different bugs. People for who the update doesn't solve
> the issue please each one of you open a new bug and attach full dmesg and
> xorg log. Also provide a small description of your setup (number of screen,
> resolution, orientation (portrait/landscape...)) and a typical reproducer.
> 
> At this point it's one person one bug rules. Thanks

I'm not sure, but i would say that's still the same bug as "the other". As this problem is not that easy to reproduce, it might be that those who think the new rpms solved the problem are simply wrong and that the bug might occur again for them. Just to make sure, i again tested with newest kernel and new rpms and i still get the problem with logs as mentioned by op with the exception that it adds another "ring" (which is graphics card dependant afaik). So saying it's another bug is not reasonable, the update maybe just removed a way to produce it.

[  557.701038] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[  557.702804] radeon 0000:01:05.0: GPU reset succeeded, trying to resume
[  557.715775] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
[  557.716142] radeon 0000:01:05.0: WB enabled
[  557.716147] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff88022c054c00
[  557.716150] radeon 0000:01:05.0: fence driver on ring 3 use gpu addr 0x00000000a0000c0c and cpu addr 0xffff88022c054c0c
[  557.748492] [drm] ring test on 0 succeeded in 0 usecs
[  557.748552] [drm] ring test on 3 succeeded in 1 usecs
[  557.748838] [drm] ib test on ring 0 succeeded in 0 usecs
[  557.749222] [drm] ib test on ring 3 succeeded in 1 usecs
[  559.035863] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!

PS: I like how this has been said to be a "non-showstopper" after I had it more than three month and suddenly as people start using f18, somebody noted that it might be silly to say lack of stable standby/vt-switch on some notebook graphics is a "non-showstopper"
Comment 39 Matt Hirsch 2013-02-03 08:59:24 EST
Ok, I have to say that the above package has not completely fixed this problem for me, as I reported earlier. Pre 9.0.1-4, my laptop never successfully resumed. After installing the new packages, I was able to suspend and resume a few times successfully, and concluded that the new version had fixed the problem. However, after using the laptop for some time, I've found that I do still run into this problem occasionally.

Sorry for any confusion I caused.
Comment 40 Jerome Glisse 2013-02-04 11:57:42 EST
FYI

This bug encompass severals bugs. One is fixed by the mesa build which include a patch to avoid over memory commitment in cs. The other is GPU lockup (-35 == EDEADLK).
Comment 41 redhat 2013-02-05 07:23:29 EST
(In reply to comment #40)
> FYI
> 
> This bug encompass severals bugs. One is fixed by the mesa build which
> include a patch to avoid over memory commitment in cs. The other is GPU
> lockup (-35 == EDEADLK).

I might be wrong, but I think you mixed up this and another bug (896170), as I could not find anything memory commitment related in this bugreport and comments. This report mainly states the "Failed to parse relocation -35!"-Error, which seems to have no solution by now other than to downgrade kernel to <3.5 (which may provokes other problems...)
Comment 42 Jerome Glisse 2013-02-05 10:57:31 EST
People test booting with iommu disabled iommu=off
Comment 43 redhat 2013-02-05 12:49:16 EST
(In reply to comment #42)
> People test booting with iommu disabled iommu=off

System is horribly slow on some actions and it seems like my wifi is broken, but no problem with graphics; vt-switch/standby seem to work as it should (though i'm not completely sure as I could only do a few tests).
Comment 44 Jerome Glisse 2013-02-05 16:14:51 EST
Please test more thoroughly with iommu off
Comment 45 redhat 2013-02-07 09:31:45 EST
(In reply to comment #44)
> Please test more thoroughly with iommu off

Well everything i tested with graphics (including 3d, standby) worked - even with multiple tests. 
At this state is nearly unuseable as disabling iommu breaks ethernet and wifi - but i don't think that you would suggest disabling iommu as a permanent "solution" :)
Comment 46 Jerome Glisse 2013-02-07 10:25:49 EST
Did you verified that with iommu off you were getting GPU acceleration (glxinfo | grep render) ?

Note also that iommu off should not break your ethernet or wifi driver those driver have bug if it's the case.
Comment 47 Jerome Glisse 2013-02-07 10:42:51 EST
Also try booting with iommu enabled and with amd_iommu=fullflush or with amd_iommu=force_isolation
Comment 48 redhat 2013-02-07 13:10:06 EST
As Gnome-Shell worked and animation were flawless, glxgears ran at 60hz (vsync) in fullscreen and gnome about screen shows gallium for graphics i assumed gpu acceleration to be working (my cpu is too weak to render gnome-shell animations...)
yeah i already knew my wifi and ethernet drivers are buggy (brcmsmac was staging a year ago and still only supports a part of the features) but most bugs are fixed by reloading the modules, so it never was a big problem for me...
I'll also try those other iommu-flags when there is some spare time the next days
Comment 49 Fedora Update System 2013-02-07 21:08:35 EST
mesa-9.0.1-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 50 Vann Walke 2013-02-08 15:36:20 EST
My results:

iommu=off - tons of error messages on boot, dumped me into emergency single user mode and the keyboard wasn't functional.  Didn't spend any time troubleshooting, just rebooted.

amd_iommu=fullflush - booted, but quickly exhibited the same problem when switching between two users X sessions on first attempt(using CTRL-ALT-Fn).  Hang - no graphics, keyboard doesn't work.  Log shows the "-35" error.

amd_iommu=forceisolation - booted, seemed to work... was able to do about 20 switches.  But, then hung with same behavior.  Not sure if the timing was an anomoly or actually meaningful.  

Not sure if this helps.  Let me know if I can do any more testing.  For now, I'm going to try and get back to doing real work!
Comment 51 Pawel Dys 2013-02-09 03:38:23 EST
If this bug is duplicate to https://bugzilla.redhat.com/show_bug.cgi?id=901984 I've had the same results as Vann Walke above (see my comment: https://bugzilla.redhat.com/show_bug.cgi?id=901984#c4)
Comment 52 Christian Klomp 2013-02-09 07:30:38 EST
This isn't completely fixed, for me it still happens but only when I have two monitors attached.

My case isn't completely the same because I use Gnome with GDM but the results are similar: switch to vty, then back to GDM and I have a black screen. also many times suspend to ram doesn't resume right, i.e. black screen and the dmesg errors.
At those points it doesn't seems to hang yet, but it does after trying to restart Xorg and/or GDM.

For me it started with F17/Linux 3.6 and with F18/Linux 3.7 it has gotten worse.

The mesa patch did sped up Radeon and I do not see the "...Failed to parse relocation -12!" line any more, but hooking up my second monitor (which isn't even enabled in the desktop environment) ultimately still results in "...Failed to parse relocation -35!"
Comment 53 Christian Klomp 2013-02-09 07:55:12 EST
I did some more testing and it actually doesn't matter how many monitors are attached unfortunately.
Comment 54 Jean-François Fortin Tam 2013-02-10 23:13:05 EST
Just adding a note: I reopened and de-duplicated bug #883536 (as suggested in comment #36 here) since all my symptoms are still there both when switching VTs or resuming from suspend.
Comment 55 Hin-Tak Leung 2013-02-12 16:05:34 EST
cloned and filed mine as 910559 . For me the problem only started after upgrading to f18. I was suspending/resuming with kernel 3.7.x with up-to-date f17 userland very happily and very regularly until the upgrade.
Comment 56 Rui Mota 2013-02-12 18:00:36 EST
It happens to me also.
I confirm this problem started since I installed a fresh F18.
Just by closing the laptop lid or by switching from graphic to text terminals and going back to graphic.
The laptop gets unresponsive blinking screen and I have to force a power off.
Comment 57 Jerome Glisse 2013-02-13 13:38:28 EST
*** Bug 883536 has been marked as a duplicate of this bug. ***
Comment 58 Jerome Glisse 2013-02-13 13:40:29 EST
ok so once the following scratch build complete please test it, it should fix your issue:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4958812
Comment 59 Jerome Glisse 2013-02-13 15:48:45 EST
Alternatively to the kernel try this ddx :
http://koji.fedoraproject.org/koji/taskinfo?taskID=4960042
Comment 60 Matt Hirsch 2013-02-13 21:15:01 EST
After installing only xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18.x86_64.rpm I have not been able to reproduce the bug. I have run multiple suspend/resume cycles, run glxgears while switching vts back and forth, and have not triggered the bug.

I am still running kernel-3.7.6-201.fc18.x86_64.

I have not yet tried the new kernel, but it seems the new ati driver package fixed it for me. However, I have been fooled in the past on this one, so I will continue using it for some time before I'll be fully convinced that its a fix. I'll report back in a couple days.
Comment 61 Fedora Update System 2013-02-14 10:29:13 EST
xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18
Comment 62 Jerome Glisse 2013-02-14 10:36:25 EST
*** Bug 910559 has been marked as a duplicate of this bug. ***
Comment 63 Fedora Update System 2013-02-15 00:00:08 EST
Package xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-2487/xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18
then log in and leave karma (feedback).
Comment 64 Pawel Dys 2013-02-15 12:15:23 EST
After installation "xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18" everything works OK. Thanks!
Comment 65 Gabriel M. Elder 2013-02-15 13:08:49 EST
I've been testing the aforementioned updated ati driver, and it seems to be working well for me so far (tango lignum). The symptoms that I was seeing was the flashing display and unresponsive keyboard when trying to resume from suspend, intermittently (~66% of the time... race conditions; grrr). I then had to ssh in and kill the desktop session, which returned the display to the gdm login screen.

FWIW, this is on a lenovo t60 thinkpad:

lspci -nn ---> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI M52 [Mobility Radeon X1300] [1002:7149]

I did not have any display or suspend/resume problems when I was still running f17, but since f18, ran into this bug, which, as far as I'm concerned, was indeed a showstopper. Additional mentions at:

http://lists.fedoraproject.org/pipermail/users/2013-January/428936.html
http://lists.fedoraproject.org/pipermail/users/2013-February/430762.html

I will pass the good news on to them there, and I thank you.
Comment 66 redhat 2013-02-15 14:46:16 EST
I can confirm that newest drv-ati package fixes the problems with kernel 3.7.6 (fc18) and 3.8.0rc7 (rawhide). Thanks for your ongoing support in this case.
Comment 67 Jerome Glisse 2013-02-25 09:51:02 EST
Ok closing now
Comment 68 Fedora Update System 2013-02-28 01:55:56 EST
xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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