[RC410][FUJITSU SIEMENS AMILO Li 1718] suspend/resume failure

[Darrell Kavanagh]

Suspend to RAM appears OK, kernel oops on resume. Standard 9.04 Beta install, except I manually added /etc/modprobe.d/acerhk.conf: "options acerhk force_series=6805 autowlan=1" and added "acerhk" to /etc/modules to enable the wireless radio on/off hotkey on this machine (ref bug #257344).

All packages up to date as at 10:30 BST 1 April 2009.

ProblemType: KernelOops
Annotation: This occured during a previous suspend and prevented it from resuming properly.
Architecture: i386
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/share/apport/apportcheckresume
Failure: suspend/resume
InterpreterPath: /usr/bin/python2.6
Lsusb:
 Bus 001 Device 003: ID 0471:0828 Philips
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: FUJITSU SIEMENS AMILO Li 1718
Package: linux-image-2.6.28-11-generic 2.6.28-11.38
ProcAttrCurrent: unconfined
ProcCmdLine: root=UUID=ffcfaf1f-9b67-4784-a4ed-9b3ec1b2e6d0 ro quiet splash
ProcCmdline: /usr/bin/python /usr/share/apport/apportcheckresume
ProcEnviron: PATH=(custom, no user)
ProcVersionSignature: Ubuntu 2.6.28-11.38-generic
SourcePackage: linux
Tags: resume suspend
Title: [FUJITSU SIEMENS AMILO Li 1718] suspend/resume failure
UserGroups:

[Darrell Kavanagh (darrell)]

I should add that this behaviour is the same under intrepid when using the free ati driver, but suspend/resume works when using the fglrx driver in intrepid. I cannot test the fglrx driver in Jaunty as it causes a system freeze on starting X. Besides I would prefer to use the free driver.

[Tim Vasby-Burnie (tim-ubuntu)]

I can confirm this, also using a Li1718. Note I had not added acerhk.conf (as above). This is a vanilla Jaunty install. The laptop did not resume so I had to hold the power-button down to force poweroff.

[Darrell Kavanagh (darrell)]

More information:
pm-suspend from a virtual terminal while X is running results in the same failure to resume. However, pm-suspend from a virtual terminal when X is not running results in a successful resume.

[Darrell Kavanagh (darrell)]

Further information:

1. I have followed the instructions at https://wiki.ubuntu.com/DebuggingKernelSuspend, log attached.

2. Observed after attempted resume: power and wireless leds come on, suspend led goes off. Screen backlight is switched on (there is a flashing underscore cursor at the top left). System fan starts. System is completely unresponsive (caps lock, sysreq, does not function). After hard shutdown (hold down power button), switching on may not work - screen stays blank, POST screen info does not display, although system leds come on. I have corrected this by disconnecting the AC power cord, and power cycling again. On one occasion BIOS settings were reset to defaults.

[Darrell Kavanagh (darrell)]

Sorry, addendum to above:

3. The failure to resume still occurs when using the vesa instead of the radeon X driver.

[Darrell Kavanagh (darrell)]

This would seem to be an xorg-server problem rather than kernel (see notes above). All packages up to date as at 23:00 BST 22nd April, the problem still exists. I found a similar sounding bug at freedesktop.org, http://bugs.freedesktop.org/show_bug.cgi?id=19581 but this is different in that it stlll exists even when dri is disabled.

If there isn't enough information here, please advise me on what is required.

[Darrell Kavanagh (darrell)]

I'm now running Jaunty final, and suspend/resume now works when forcing use of the vesa driver by using an xorg.conf:

Section "Device"
Identifier "Configured Video Device"
Driver "vesa"
EndSection

Therefore the problem would seem to be in the xserver-xorg-driver-ati package, so I've added this bug to that package.
Perhaps my previous test using the vesa driver was flawed in some way.

I've also confirmed that resume does not work after having booted into X using the radeon driver, even if I switch to a VT, kill gdm and rmmod the radeon and drm modules. I have compared the active modules (lsmod) and running processes (ps aux) in the two cases:

1. Boot into a terminal using text kernel parameter
2. Boot into X, switch to VT, kill gdm, rmmod radeon, rmmod drm

and there is no difference in the modules in use and the processes running, however in case 1, suspend/resume works, and in case 2 resume fails as described above. It seems to my (uninformed) eye that starting X using the radeon driver causes a problem (perhaps putting the display hardware in a particular state) which prevents successful resume until after a reboot, even if X etc is subsequently killed.

I have also tried the packages from https://launchpad.net/~tormodvolden/+archive/ppa and the problem still exists. I hope this additional information is useful.

[Darrell Kavanagh (darrell)]

I should also add that I have experimented with pm-suspend quirks without success.

[Tormod Volden (tormodvolden)]

Please attach your Xorg.0.log as well.

[Tormod Volden (tormodvolden)]

This video card is reported in bug 305301 to hang on resume when DRI is on. Are you sure it crashes even if DRI is off? Please also attach your Xorg.0.log after disabling DRI.

[Darrell Kavanagh (darrell)]

After further testing I can confirm that the machine resumes correctly when DRI is disabled, but only if it has been rebooted after running X with DRI enabled. Disabling DRI in xorg.conf and then restarting X is not enough. My previous test without DRI must have been with no reboot after disabling DRI, only an Xserver restart.

For clarity:

1. Start X using radeon driver with DRI (the default) - resume from suspend fails.
2. Start X using radeon driver with DRI, then amend xorg.conf to disable DRI and restart X - resume from suspend fails.
3. Ensure computer is rebooted after disabling DRI - resume from suspend is successful.

Now with the benefit of an Xorg.0.log from the successful resume, it appears that In cases 1 and 2 above, the failing step is
(II) Open ACPI successful (/var/run/acpid.socket)
(at least it is the previous message "Leaving Restore TV" which is the last one written to Xorg.0.log before the crash).

See Xorg.0.log files attached.

[Tormod Volden (tormodvolden)]

Thanks. I think we can say this is a duplicate then.

[Darrell Kavanagh (darrell)]

Ok, but should bug 305301 then be marked as affecting xserver-xorg-video-ati?

[Tormod Volden (tormodvolden)]

The bug is most likely in the kernel (radeon-specific) drm code, that is why it is assigned to the kernel. But we can probably open a -ati task, just to have it visible on the -ati bug lists.

[Michalxo (michalxo)]

I am not sure about relevancy about this bug with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/449848 , but problem still persists as my last comment says :-(