Bug 196589

I can also confirm that 2.6.17-1.2139_FC5 breaks suspend-to-RAM on a Fujitsu
P7120 with a i915 graphics card.

2.6.16-1.2137_FC5 used to work fine (with some slight tweaks, like adding
'acpi_sleep=s3_sleep,s3_mode' to the kernel command line.

lspci output:

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 04) (prog-if 00 [VGA])
        Subsystem: Fujitsu Limited. Unknown device 12e2
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at b0080000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at 1400 [size=8]
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Memory at b0040000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: <access denied>

00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express
Graphics Controller (rev 04)
        Subsystem: Fujitsu Limited. Unknown device 12e2
        Flags: fast devsel
        Memory at 32000000 (32-bit, non-prefetchable) [disabled] [size=512K]
        Capabilities: <access denied>

Just to be clear, my machine is suspending and waking with settings used with
the previous kernel 2.6.16...  The display is just not waking.

I am having the identical problem on a Dell Latitude D600 with ATI Radeon R250
(FireGL 9000) video card and xorg driver.

Workaround (works on a Dell Latitude X1):

Add

Option "VBERestore" "true"

to your xorg.conf device section for your video device

And before suspend issue a chvt 8.  On resume, issue a chvt 8; chvt 7

I have added these commands to my sleep script.

Things are working fine for me now. Not sure if it was the recent update or the
switch to gnome-power-manager.

> before suspend issue a chvt 8.  On resume, issue a chvt 8; chvt 7

Fixes the same problem for me on Dell Latitude D800, using 'nv' driver.

Thanks!

Not sure if it's exactly relevant to this bug report or not but resuming from
suspend-to-disk with kernel-2.6.17-1.2139_FC5 kills the X-server (using i810)
for me, making the whole suspend/resume feature useless. Kernel boots, says
it's going to resume from the swap partition, starts reading, displays turns
white and after a while, busy cursor is displayed and then gdm is started - on
tty8. tty7 becomes unusable and this is added to /var/log/Xorg.0.log.old (and
Xorg.0.log is newely created):

(WW) I810(0): Fixing display offsets.
Error in I830WaitLpRing(), now is 471759872, start is 471757856
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 0
LP ring tail: 8 head: 0 len: 0 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 108 instps: 0
hwstam: ffff ier: 0 imr: ffff iir: 0
space: 131056 wanted 131064
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xdfb84000 at 0xb7efb000

Fatal server error:
lockup

Error in I830WaitLpRing(), now is 471764111, start is 471762110
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 0
LP ring tail: 10 head: 0 len: 0 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 108 instps: 0
hwstam: ffff ier: 0 imr: ffff iir: 0
space: 131048 wanted 131064

FatalError re-entered, aborting
lockup

2.6.17-1.2145_FC5 has the same problems.

Fixed in 2.6.17-1.2174_FC5.

(In reply to comment #9)
> Fixed in 2.6.17-1.2174_FC5.
 
Well, in my case, pm-hibernate is OK. pm-suspend causes a weird behavior: all
windows are "content-free", panel is empty, desktop icons are black... not really
usable desktop. If I enable VBERestore then IRQ 10 becomes disabled - no USB port
1, no sound; text on virtual terminals flickers wild. Not really usable desktop
either.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Created attachment 139027 [details]
/var/log/messages after resuming

Cool, looks like suspend-to-ram works again here. But, for some reason still no

sound was being produced after waking up, although the player application
didn't
show any error and no channel appeared to be muted. Attaching a part of log,
which
shows an problem at kernel/rwsem.c, among other messages.

Leaving in NEEDINFO as I'm actually not the reporter of this bug.

...Forgot to mention, sound started working again after running s-c-soundcard and
playing the test sound. Not sure what exactly helped, though.

the rwsem issue has been reported in a separate bug. I'll look into that soon.

For sound problems, the quickest way to get them fixed is to report them in the
upstream alsa bugtracker at https://bugtrack.alsa-project.org


I'm fairly confident this is going to be fixed for Austin too, so I'll close
this out. (Feel free to reopen if I'm wrong)