Created attachment 45728 [details] lspci -v When trying to resume from suspend, the computer freezes totally, after a second or so. Nothing can be found in the logs, because loging doesn't even start until then. Resuming from hibernation works fine. I've realised, that if i delete the i2c-algo-bit.ko file (therefore preventing it from being loaded) the resume/suspend will work fine, but there is no compositing, sadly. Using "nomodeset", and trying resume from suspend failed. It is an RC415ME chip (it is written on it). This bug was also submitted a long time ago here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/577340/
Created attachment 45729 [details] Xorg.0.log
Removing i2c-algo-bit.ko prevents radeon from loading since it depends on it; that's why 3D/compositing fail. Please attach your xorg log and dmesg output both with and without i2c-algo-bit.ko present.
Created attachment 45733 [details] Dmesg - i2c_algo_bit loaded
Created attachment 45734 [details] Dmesg - i2c_algo_bit NOT loaded, before suspending
Created attachment 45735 [details] Dmesg - i2c_algo_bit NOT loaded, after a succesful resume
Created attachment 45736 [details] Xorg.0.log - i2c_algo_bit NOT loaded
Created attachment 45737 [details] Lsmod - i2c present
Created attachment 45738 [details] lsmod - i2c NOT present
I've made a custom kernel, and applied this (I modified the nx6125's patch a bit): --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -3171,6 +3171,14 @@ void radeon_combios_asic_init(struct drm_device *dev) rdev->pdev->subsystem_device == 0x30a4) return; + /* quirk for rs4xx FSC Amilo Li1718 laptop to make it resume + * - it hangs on resume inside the dynclk 1 table. + */ + if (rdev->family == CHIP_RS480 && + rdev->pdev->subsystem_vendor == 0x103c && + rdev->pdev->subsystem_device == 0x10fb) + return; + /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) I haven't been able to resume with it correctly, but, in some cases, the system froze a little bit after, than before. These times, the lcd got backlit, and some broken images, lines, colours, dots appeared.
Created attachment 45792 [details] lspci -vnn on my Toshiba Satellite L35-S2366 This bug has been around for more than 3 years for me. My experience is that if in the xorg.conf file I put Option "DRI" "off" I can resume from suspend if booting with radeon.modeset=0 kernel option. That does not give me 3D acceleration. If I put Option "DRI" "on" I lose resume, no matter what the kernel option is, however get 3D. I tried a variety of kernel and usually grab and build the freshest stable release from the kernel.org E.g., currently it is 2.6.38.3 (Apr 17)
Forgot to mention one more thing related to the Karesz' last comment. Neither Alex' patch from https://bugs.freedesktop.org/show_bug.cgi?id=29062 , nor the simple "return;" statement (without any if's to fight that DYN CLK 1 table issue) made any progress for me (including the recent 2.6.38.2 build)
Created attachment 45921 [details] an unsuccessful wakeup attempt kernel log As I already mentioned this in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/577340, repeating it here. After I tried to unsuccessfully install fglrx, which I removed while running full 3D, I subsequently tried to suspend and resume. The resume did not work, however, I saw one of the vt's with the kernel log in it. It appears to be a log of the wakeup attempt with a couple of stack traces. Not sure if it can shed any new light on our issue and attach that piece of kern.log here.
Any news on this?
I'm a little confused, <a href="https://bugs.freedesktop.org/attachment.cgi?id=45729">this Xorg.0.log</a> is marked as a patch, but I'm not really sure, if it is.
No Karesz, it is not a patch.
Created attachment 46931 [details] A failed resume's recurring log- Fedora 15 beta I've made a bootable live Fedora 15 beta USB, booted, and noticed, that gnome3 had only a suspend in it's "live user options" menu, so I clicked it. It suspended correctly, as expected. Then I pressed the power button, to see whether it resumes, or not. It doesn't, but the screen got backlit, and this message kept running on the screen. Pressing ctrl+alt+F3 stopped it, and I was able to take a photo of it (don't know how to get this message in text form), and I enhanced it a little.
Created attachment 46933 [details] failed resume attempts log I've just typed the image above. Hopefuly it's more help this way.
Any news on this one?
(In reply to comment #18) As far as the 3.0.0-rc5 is concerned, there is no good news for this card, unfortunately.
Okay, I had some time, and tried this: I've made this script: #!/bin/sh sync echo 1 > /sys/power/pm_trace echo mem > /sys/power/state (from here: http://lxr.linux.no/linux+v2.6.34.1/Documentation/power/s2ram.txt ) I've rebooted after the failed resume process, and looked for the Magic number in dmesg. I've found this: [ 1.104884] PM: Hibernation image not present or could not be loaded. [ 1.104907] registered taskstats version 1 [ 1.105184] Magic number: 3:841:901 [ 1.105360] rtc_cmos 00:04: setting system clock to 2011-07-05 20:53:56 UTC (1309899236) [ 1.105365] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 1.105367] EDD information not available. [ 1.105548] Freeing unused kernel memory: 700k freed I haven't found any "hash matches...." lines. How to continue?
Hey! I've made an ubuntu 11.10 (64bit) live usb-stick. After 4 failures, it finally resumed OK from suspend. Tried it again, and it failed. I'm linking the dmesg output. Maybe this will help.
Created attachment 52129 [details] dmesg output after a succesful resume
Comment on attachment 52129 [details] dmesg output after a succesful resume Kernel it is using: 3.0.0-12
Okay, hi again. So, I don't know what you just did, but resume from suspend just works like a charm now. Since I don't want it to fail again, I'm sharing this information with you. Any tips on why is it working?
Fixed with this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=acf88deb8ddbb73acd1c3fa32fde51af9153227f
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.