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:
Created attachment 605345 [details] xorg.0.log file, all looks good
Created attachment 605346 [details] xorg.0.log.old, all looks good
Created attachment 605350 [details] messages showing the error
Additional info: the keyboard did not function, switching vt did not work, even the keyboard leds did not work.
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!
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.
Can confirm this using Mobility Radeon 4200. Also happens after resume from suspend...
It seems i reported it back again here (CAICOS: 863726 dup?)
seems fixed in 3.6.3-3.fc18.x86_64?
c#9 makes it sound like this might have been fixed. Can someone else confirm whether this is true or not?
(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...)
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.
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.
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.
suspended/resumed twice on the same versions of things as previous without incidents... let's hope I don't see this prob too often...
*** Bug 866992 has been marked as a duplicate of this bug. ***
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).
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.
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?
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.
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...
*** Bug 882059 has been marked as a duplicate of this bug. ***
This bug occurs in F18 as well. Bumping version.
*** Bug 883536 has been marked as a duplicate of this bug. ***
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)
Installed and will test, thought I haven't seen the issue for some time.
@Jerome: nothing changed. (Fedora rawhide)
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"...
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.
(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.
(In reply to comment #27) > @Jerome: nothing changed. (Fedora rawhide) What you mean by that? Still fails to restart?
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
(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)
(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])
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
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
(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...
(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"
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.
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).
(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...)
People test booting with iommu disabled iommu=off
(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).
Please test more thoroughly with iommu off
(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" :)
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.
Also try booting with iommu enabled and with amd_iommu=fullflush or with amd_iommu=force_isolation
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
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.
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!
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)
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!"
I did some more testing and it actually doesn't matter how many monitors are attached unfortunately.
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.
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.
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.
ok so once the following scratch build complete please test it, it should fix your issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=4958812
Alternatively to the kernel try this ddx : http://koji.fedoraproject.org/koji/taskinfo?taskID=4960042
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.
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
*** Bug 910559 has been marked as a duplicate of this bug. ***
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).
After installation "xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064.fc18" everything works OK. Thanks!
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.
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.
Ok closing now
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.