Bug 37452 - System frezees trying to resume from suspend when using the "radeon.modeset=0" kernel parameter
System frezees trying to resume from suspend when using the "radeon.modeset=0...
Status: CLOSED DOCUMENTED
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
All Linux
: P1 normal
Assigned To: power-management_other
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2011-06-13 18:49 UTC by videoclocknet
Modified: 2011-06-30 19:47 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.38
Tree: Mainline
Regression: No


Attachments
dmesg output running 2.6.38-8 kernel - X works (64.74 KB, text/plain)
2011-06-14 08:04 UTC, videoclocknet
Details
dmesg output running 2.6.35-28 kernel - X does not work (56.88 KB, text/plain)
2011-06-14 08:07 UTC, videoclocknet
Details
/var/log/Xorg.0.log (32.67 KB, text/x-log)
2011-06-14 08:10 UTC, videoclocknet
Details
/var/log/Xorg.0.log on 2.6.35 kernel from shell (22.83 KB, text/plain)
2011-06-14 09:21 UTC, videoclocknet
Details
/var/log/Xorg.0.log after uninstalling fglrx (64.21 KB, text/x-log)
2011-06-21 10:18 UTC, videoclocknet
Details

Description videoclocknet 2011-06-13 18:49:28 UTC
Using 2.6.38 kernel 32 bits in Ubuntu 11.04,

My Acer TravelMate 7720G randomly crashes trying to resume from suspend.

What happens:

1) I close the cover o I click "suspend"
2) The laptop suspends correctly: the led changes from green colour to brown colour and gets to blink and the "electricity sound" disappears.
3) When I press the shut down button or some key to resume, sometimes it does, sometimes it does not.

When it does not: when I press some key or the shutdown button to resume, the "electricity sound" returns, but immediately it disappears during a second approximately and then returns again, staying all the time the screen off. Then the electricity sound continues forever, but any key/button has no effect, losing all the work I was doing before suspend.

When it does: I don't hear the "one second sound off". Since I hear the "electricity sound", it remains.




When I say "electricity sound" I refer to the sounds of power, fan and things like this. I don't know the exact word, but you may understand it

Regards
Comment 1 videoclocknet 2011-06-13 18:55:09 UTC
The "uname -r" output shows me:
2.6.38-8-generic


I don't know if it happens in older/newer kernel versions

Regards
Comment 2 Rafael J. Wysocki 2011-06-13 19:07:50 UTC
Well, it's hard to say what the reason is.

What graphics adapter/driver do you use?
Comment 3 Len Brown 2011-06-14 01:42:22 UTC
Does hibernation work any better than suspend to memory?
Does it work in newer or older kernels, such as 2.6.39
and 2.6.37?
Comment 4 videoclocknet 2011-06-14 08:02:30 UTC
Rafa, my graphics card is:
ATI Mobility Radeon HD 2400 XT Hypermemory

My graphics driver is fglrx. The version and info can be read from the attached logs (/var/log/Xorg.0.log)

casa@casa:~$ lsmod | grep fglrx
fglrx                2476698  3 
casa@casa:~$


Len, hibernation and resume from hibernation work perfectly in 2.6.38-8. In this case, when the laptop is hibernating, the shutdown led does not appear as brown nor blinking, but it's off. Pressing the shutdown button from here gets to resume from hibernate perfectly.

You can read the dmesg output in the attached log running 2.6.38-8


The other version kernel I've tried is 2.6.35, which is my old kernel. With this, X is not loaded. It's rare, because X was working when I was using this kernel in the past. You can read the dmesg output I've got from Ctrl+Alt+F1 terminal.

Is it possible I don't have the proper graphics driver? Do you recommend me to use another one?
Comment 5 videoclocknet 2011-06-14 08:04:26 UTC
Created attachment 61952 [details]
dmesg output running 2.6.38-8 kernel - X works
Comment 6 videoclocknet 2011-06-14 08:07:22 UTC
Created attachment 61962 [details]
dmesg output running 2.6.35-28 kernel - X does not work
Comment 7 videoclocknet 2011-06-14 08:10:01 UTC
Created attachment 61972 [details]
/var/log/Xorg.0.log
Comment 8 videoclocknet 2011-06-14 09:18:24 UTC
The Xorg.0.log I did in the last post was running 2.6.38.

Next I've booted on 2.6.35 and from the Ctrl+Alt+F1 shell I've executed "X" as a command. Then I've saved the /var/log/Xorg.0.log , which can also be read in the new attachment. I've uploaded this, because I can read in the last line:

[   338.995] (EE) fglrx(0): firegl_SetSuspendResumeState FAILED -9.

I don't know if it's because I was working from the shell or  because this driver does not work with  2.6.35 or because exhibits the initial issue 

Currently, all attempts to suspend and resume from 2.6.38 gets to crash, so I can't provide a dmesg from a succesful resume from suspend.


Regards
Comment 9 videoclocknet 2011-06-14 09:21:05 UTC
Created attachment 61992 [details]
/var/log/Xorg.0.log on 2.6.35 kernel from shell
Comment 10 Len Brown 2011-06-21 01:53:23 UTC
The binary fglrx driver taints the Linux kernel
and the result is something that only the supplier
of the fglrx driver can support -- we can't.

Please re-open if you still have a problem when
running the open source "radeon" driver instead of the
binary "fglrx" driver.
Comment 11 videoclocknet 2011-06-21 10:17:18 UTC
I've uninstalled the fglrx driver and it still crashes trying to resume from suspend. You can read the new /var/log/Xorg.0.log after uninstalling fglrx.

However, there are good news too: suspend and resume from suspend work perfectly booting from the Ubuntu 11.04 LIVE CD, which has 2.6.38-8 kernel too.

I've copied the full /etc/acpi folder from the LIVE CD to the hard drive installation without success.

So the question is:
From the kernel side, is there any difference between suspend/resume booting from a Linux LIVE CD and booting from a hard drive installation?
Comment 12 videoclocknet 2011-06-21 10:18:46 UTC
Created attachment 63082 [details]
/var/log/Xorg.0.log after uninstalling fglrx
Comment 13 videoclocknet 2011-06-21 15:02:04 UTC
Mystery solved. The issue happens when using the "radeon.modeset=0" kernel parameter.

In my /etc/default/grub file the GRUB_CMDLINE_LINUX_DEFAULT entry was:
GRUB_CMDLINE_LINUX_DEFAULT="radeon.modeset=0 quiet splash"

And I've changed to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

The system suspends/resumes from suspend very well now.

Must I change the bug title to something like 'System frezees trying to resume from suspend when using the "radeon.modeset=0" kernel parameter' ?

Regards
Comment 14 videoclocknet 2011-06-21 15:09:04 UTC
I have to add that I don't know if it also happens with:
1) Different "radeon.modeset" values
2) Different graphic cards
3) Different kernel versions

Regards
Comment 15 videoclocknet 2011-06-29 14:07:40 UTC
I've changed the bug title to clarify the circumstances in which the bug happens
Comment 16 videoclocknet 2011-06-30 06:58:55 UTC
I've tried with 3.0-rc5 kernel and the bug still happens to me.
Comment 17 Rafael J. Wysocki 2011-06-30 10:34:14 UTC
Does resume work without radeon.modeset=0 ?
Comment 18 videoclocknet 2011-06-30 16:39:25 UTC
(In reply to comment #17)
> Does resume work without radeon.modeset=0 ?

Yes, with 2.6.38-8 and 3.0-rc5 kernels, resume works perfectly without radeon.modeset=0.

In both kernels, when I use radeon.modeset=0, resume doesn't work most times
Comment 19 Rafael J. Wysocki 2011-06-30 18:36:54 UTC
OK, so this is as expected.  KMS is _required_ for suspend/resume to work,
which is a known fact in general.

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