Ooops!  That should be:

  ACPI S3 on my ThinkPad T42p has worked very reliably with 
  every FC5 kernel *except* kernel-2.6.17-1.2139_FC5.i686

Same here.  I have a Dell D820.  Suspend used to work just fine.  Matter of
fact, it was great.  Now it seems to wake up, at least the power synbol no
longer "throbs" but is constant, but no response from network, keyboard, etc.  I
have to do a hard shutdown.

This is all I have in the /var/log/messages about the suspend:
--BEGIN--
Jun 27 08:23:21 dufus gnome-power-manager: Suspending computer because the DBUS
method Suspend() was invoked
Jun 27 08:23:21 dufus NetworkManager: <information>     Going to sleep.
Jun 27 08:23:21 dufus avahi-daemon[2700]: Interface eth0.IPv4 no longer relevant
for mDNS.
Jun 27 08:23:21 dufus avahi-daemon[2700]: Leaving mDNS multicast group on
interface eth0.IPv4 with address 192.168.250.164.
Jun 27 08:23:21 dufus avahi-daemon[2700]: Withdrawing address record for
192.168.250.164 on eth0.
Jun 27 08:23:21 dufus dhclient: DHCPRELEASE on eth0 to 192.168.250.38 port 67
Jun 27 08:23:21 dufus dhclient: send_packet: Network is unreachable
Jun 27 08:23:21 dufus dhclient: send_packet: please consult README file
regarding broadcast address.
Jun 27 08:23:21 dufus logger: Activating firewall script generated Thu Jun 15
15:46:51 2006  by bpm
Jun 27 08:23:21 dufus dhcdbd: dhco_input_option: Value -1 cannot be converted to
type L
Jun 27 08:23:21 dufus dhcdbd: dhco_parse_option_settings: bad option setting:
old_dhcp_lease_time = -1
Jun 27 08:23:21 dufus NetworkManagerDispatcher: ntpd is running, stop
Jun 27 08:23:21 dufus ntpd[3520]: ntpd exiting on signal 15
Jun 27 08:23:28 dufus kernel: Freezing cpus ...
--END--

Same problem for me on Dell Latitude D800, using 'nv' driver.

Works fine with previous kernel.

The problem is that the display isn't getting reset... suspend still works OK in
console mode (runlevel 3), but in X, it resumes, but there is no display.

I've tried adding 
Option    "VBERestore" "true"
to the xorg.conf but it hasn't made a difference.

Thanks

duplicate of bug 196589, see workaround there

Hi Barry, this is *not* a duplicate of bug 196589 as you suggest.  I've 
tried the xorg.conf workaround:

  # in Section "Device" for the video card
  Option "VBERestore" "true"

and had no luck.  Further, I've tried the ACPI S3 susp/resume with and 
without all of the kernel options listed above and it makes no difference. 
In all cases, the machine locks up *hard*.  Only removing the battery will 
shut it down.  I've also tried removing various kernel modules before the 
suspend in hopes that it would help but it doesn't.

Also, the kernel fails to boot on this laptop about 1/2 of the time (again,
with hard lockups) but perhaps that is a separate issue...?

I don't think any of the above can be explained by hw problems since the 
laptop works very nicely and very reliably with all previous FC5 kernels 
[except the botched kernel that was pulled from the repo... :-)].

The same happens on Thinkpad T41 with Radeon Mobility graphics. After going to
S3 ACPI state it freezes just after spotting the suspend signature in swap
partition. Switching to previous kernel cures everything.

Hi folks, a friend suggested that I use:

  /usr/bin/pm-suspend

instead of:

  echo mem > /sys/power/state

[which I had been using for a long time and had worked nicely] and now 
ACPI S3 works for me with 2.6.17-1.2139 on a ThinkPad T42p.  So, from 
my perspective, this bug is fixed!  Does pm-suspend fix things for 
anyone else here?

Oh, and my sincere apologies to Barry if this is indeed a duplicate of 
bug 196589 as suggested above...

Sorry, I do not think this bug is fixed.  On my D820, I do a fn-esc key to
suspend.  It does not work with kernel-2.6.17-1.2139_FC5.i686.  The other
kernels work fine.  Also /usr/bin/pm-suspend is just a work around, not a fix.

Hi Brian, can you please check whether /usr/bin/pm-suspend works with 
2.6.17-1.2139 on your D820?

Hi Ed, no it does not.  Sorry.

I am seeing the same (or very similar) on a Lenovo r51,
http://www.charlescurley.com/Lenovo.R51.html. The suspend and resume work except
that I do not get the display back. I can SSH in to the box and perform a
graceful reboot which works successfully.

Preliminary examination of the log entries suggests a normal suspend. I can
provide "before" (2133 kernel) and "after" (2139) suspend log entries if you'd
like to see them.

I have seen the problem with the radeonfb driver in place. I haven't tried it
without the radeonfb driver. Nor have I tried any of the proposed workarounds
listed here or on the Fedora Core list. My workaround is to fall back to 2133,
the previous kernel.

I have an ipw2200 wireless card. The 2139 kernel uses the 3.0 firmware; the 2133
uses the 2.4 firmware. This is probably not relevant, but, given how
obstreperous this card has been, who knows...

I use the xorg radeon drivers, not the ATI ones, as noted on my web page.

Grub boot stanza is as follows:

title Fedora Core (2.6.17-1.2139_FC5)
        root (hd0,2)
        kernel /vmlinuz-2.6.17-1.2139_FC5 ro root=LABEL=/ video=radeonfb
        initrd /initrd-2.6.17-1.2139_FC5.img

and similarly for other kernels.

Hi Charles, did you try VBERestore per bug 196589 ?  I added it:

  Section "Device"
        Identifier  "Videocard0"
        # ...other stuff...
        Option      "VBERestore" "true"
  EndSection

and perhaps it will help you bring the display back to life on resume?

(In reply to comment #12)
> Hi Charles, did you try VBERestore per bug 196589 ?  I added it:
> 
>   Section "Device"
>         Identifier  "Videocard0"
>         # ...other stuff...
>         Option      "VBERestore" "true"
>   EndSection
> 
> and perhaps it will help you bring the display back to life on resume?


No, I had not (as I said). However, I tried it just now. It did not work. I see
a very different display. Previously I had seen a blank display, all black. With
this change, I saw black with a lot of green crud all over the place, in a
repeating pattern. From having worked on video drivers, I suspect an attempt to
restore to a different resolution than what the display was actually set to.

While I had it in the failed state, I tried the keyboard, and found it deader
than a lawyer's ethics. SSH continued to work.

I then commented that out, and (per Ed Hill's suggestion in comment #7 above) tried 

    # echo -n mem > /sys/power/state
    /usr/bin/pm-suspend

in /etc/acpi/actions/sleep.sh

That worked.

From this and some googling, I suspect we may have more than one bug
masquerading as one because they show very similar symptoms. However, no one fix
is reliable, and different people report different symptoms. E.g. some folks
report a total lockup, other not; some report that the keyboard works; others
not; etc.

Hi folks, I'm happy to report that the latest update 2.6.17-1.2145_FC5
has just completed a successful suspend/resume cycle using pm-suspend on
my ThinkPad T42p.  Its only one cycle, but nonetheless a good sign!!!

Also, in case anyone is interested, I'm using the kmod-fglrx bits from 
"that other repo".

Hi All,

Thought I would share my experiences with suspend to try and help improve suspend/hibernate 
support.

I have a dell 8600 running FC5, with an nvidia graphics card (geforce go 5650) and use the livna 
kmod-nvidia  binary driver (output from lspci is at the end of this post, If more info is useful, let me 
know).

SInce upgrading from FC4 to FC5 suspend to ram and to suspend to disk has worked *almost* 
flawlessly for me, modulo having to perform a few tweaks to get the nvidia driver going (I boot 
with agp=off in order to disable agpgart, and use the Xorg option  'Option  "NvAgp" "1"' to use the 
nvidia agp driver. I also had to tweak /etc/pm/functions-nvidia to comment out /usr/sbin/vbetool 
post in resume_video(), following a suggestion from the nvidia forum )

This was all with the 2.6.16 kernels (the last one being 2.6.16-1.2133_FC5). recently though, I 
upgraded to 2.6.17-1.2139_FC5 and with this suspend broke for me. I admit I did not get chance to 
try all the suggestions in the bug report, since subsequently 2.6.17-1.2145_FC5 which seems to 
have somehow fixed the problem (although, I don't know why ??).

As I said, I originally planned to submit my own "me-too" to this bug, but 2.6.17-1.2145_FC5 "fixed" 
things before I got a chance. I add my comments now just incase it helps people understand 
whats wrong, if there still is a problem, and also to add my voice to those who care if 
suspend/hibernate work with FC (which is actually one of the main reasons I use it over over 
distros...)

jonesc@localhost ~ > /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI 
Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI 
Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI 
Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller 
(rev 01)
01:00.0 VGA compatible controller: nVidia Corporation NV31M [GeForce FX Go5650] (rev a1)
02:00.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
02:01.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 02)
02:01.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller
02:03.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)

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.

I am happy to say that it works for suspend.  I've not tried hibernate.
This is for a dell d820 & nvidia x86-1.0-9626