Same here on Acer TM 2490. I did some testing just before few minutes and with
the same configuration and installed packages it sucessfuly resumes with 3149
kernel and fails with both 3189 and latest 3194 kernel.

More info: suspend works with all three, however when I try to resume with the
two newer my hard disk works for a while and then stops. Screen remains turned
off, as well as USB optical mouse.

Created attachment 155525 [details]
/var/log/messages from when I tested it

Adding /var/log/messages striped to include only info from the time I tested
suspend functionality with 3149, 3189 and 3194 kernel. Hope it helps. Also, I
can confirm, that resume broke in 3180 kernel build.

I just ran through building and testing some kernels. It was specifically
the change to the 2.6.21.2rc1 patchset that caused the breakage.

Please read my suspend/resume troubles I had with my laptop...

for summary read only comment #32

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240964#c32

I can try installing 3163 kernel on my existing fedora7 test 4 installation and
see what happens...

But I can't find 3163 kernel anywhere, just a bunch of dead links.
http://www.google.com/search?q=kernel-2.6.21-1.3163.fc7.i686.rpm&hl=en

Can you help me out? Where can I download older kernels for F7?

(In reply to comment #5)
> I can try installing 3163 kernel on my existing fedora7 test 4 installation and
> see what happens...
> 
> But I can't find 3163 kernel anywhere, just a bunch of dead links.
> http://www.google.com/search?q=kernel-2.6.21-1.3163.fc7.i686.rpm&hl=en
> 
> Can you help me out? Where can I download older kernels for F7?

In koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=8

I just finished installing, updating, testing, rebooting... and after 5 hours of
testing I can claim that the current F7 kernel 3194 has a major bug preventing
laptops to resume.

I installed Fedora Live CD 20070517 with kernel 3163 on my HP Compaq nx7300
laptop and suspend works great with quirks (I just sent patches for HAL
regarding this). After updating to latest updated version of all packages except
kernel suspend/resume still works great.

When I update kernel to 3194 suspend works great but resume freezes the laptop.
There. :)

If you need more proof please tell me.

davej suspected it might be timer changes, and suggested trying 'nohz=off'. This
didn't help for me.

I am in the same situation - stuck with 2.6.21-1.3176 on Acer Aspire 5610.
hw-uuid e121f58f-2418-479e-9683-defc088c2168. Will try nohz=off with
2.6.21-1.3209.fc7 and report back if it works...

Ok, I did some testing with vanila kernels and git-bisect and knowing the
3176.fc7 is based off vanila 2.6.21.1 and works and 3180.fc7 is based of
2.6.21.2-rc2 and does not work I set v2.6.21.1 as good and v2.6.21.2 as bad.
What was my surprise that with none of the bisect steps the suspend/resume
worked. So I extracted 2.6.21, applied 2.6.21.1 patches (form 3176 srpm) and
intalled the kernel, and suspend/resume didn't work. I am at the end of my wits.
I can edit the srpm and do hand bisect there, but I tried to remove/add some
patches to be more or less between 3176 and 3180 however the kernel compiled but
rpm didn't builded. I tried it twice with the same result: <probably some
process ID> killed. And classical rpmbuild error. 

I don't know what more I can do to check, which patch actualy breaks it. It
seems that the rpmed kernel has either specific config or specific patches that
made suspend/resume work, but some of the patches (about 35 minus already used 6
- that's about thirty patches, that's not so big number) from 2.6.21.2-rc2
apparently broke it.

Oh, and... I did the kernel compiling by make mrpoper, make oldconfig (asked me
only once and I left default setting there), make, make modules_install, make
install (the two latter as root...). Did I something wrong? Any ideas? Any
suggestions?

More info:

I just tried 3212.fc7 kernel from koji, and with the same result - resume after
suspend does not work. Screen turned off, USB mouse as well, HDD LED flashes and
that's all. So I am still stuck with 3176.fc7 kernel...

HDD LED is constantly on for me and I tried
http://people.freedesktop.org/~hughsient/quirk/quirk-advanced.html
with 3194.fc7 and got:
  hash matches drivers/base/power/resume.c:28
  hash matches device PNP0C0A:00
my /sys/bus/acpi/devices/PNP0C0A:00 has driver -> /sys/bus/acpi/drivers/battery
btw: nohz=off does not help

I will just add a "me too", my laptop is an HP Compaq nx9420 and suspend SEEMS
to work fine, but it doesn't wake up.

kernel 2.6.21-1.3194.fc7

kernel 2.6.21-1.3213.fc8 in rawhide does not have this problem, but it is still
present in the matching f7 kernel (2.6.12-1.3219.fc7).

Probably a 2.6.21 vs 2.6.22 thing.

Same here, 2.6.21-1.3213.fc8 resumes, 2.6.12-1.3219.fc7 not. With 
2.6.21-1.3213.fc8 however, postfix fails to start at boot, but after the 
system has finished loading it can (SeLinux=permissive)?!?

Same here, 2.6.21-1.3213.fc8 suspend and resumes ok
2.6.21-1.3209.fc7 does not

Same here on a Gateway M255. witht he F7 kernel it woudl not resume at all. With
the F8 kernel, it works _once_. Suspend/Resume/Suspend/Resume again, won't
resume the 2nd time, it acts just like the F7 kernel, does anyone else have the
same problem with the F8 one, or is it just me?

on a thinkpad T60p, with kernel 2.6.21-1.3228.fc7, suspend to ram failed to wake
up, until I disabled hpet. 

After applying selectively patches from the src.rpm, I came to the conclusion
that linux-2.6-clockevents-fix-resume-logic.patch caused problems. Only applying
patches 10-99, 200-299, and 2402, (and excluding 2403 aka
linux-2.6-clockevents-fix-resume-logic.patch) made the kernel resume from
suspend, without the need to disable hpet, but it failed to resume after a
second suspend. Between the first and the second suspend, the kernel also
complained about soft lockups (if needed, I can produce the stack trace). 

Disabling hpet at boot time allows me to resume from suspend several times with
kernel 2.6.21-1.3228.fc7, that's why I think that
linux-2.6-clockevents-fix-resume-logic.patch is only a part of the problem.

echo 1 > /proc/sys/kernel/acpi_video_flags was required to properly restore the
video on resume. I made my tests with init=/bin/bash. And my mkinitrd preloads
modules ata_piix ahci.

is anybody at fedora or redhat looking at this? can you make us some beta kernel
without bad patches so that it gets out laptops to suspend and resume ok?

Richard Hughes has a webpage for diagnosing this:
http://people.freedesktop.org/~hughsient/quirk/

Chuck please read my replies on this bug and my other bugs that I link to before
posting generic reply. I actively work with Hugh and on his Quirks page and this
is not enough to fix this bug. We need fedora/red hat developers to iron this
bugs out or make some test kernels for us to test using info in comment #18.

I'm not sure what the status of the clockevents patch is. It's not upstream.
Thomas, can you look at this?

I tested the suspend on the newest kernels - one stable and one rawhide. On
identical system configuration (fully updated F7). Note that the rawhide kernel
has a problem with loading modules, but boots...

RESULTS:

kernel-2.6.21-1.3228.fc7:
suspend: ok
resume: screen black, optical usb mouse not turned on, hdd LED on for about a
half a minute than it turns off, HDD however show no activity (i.e. no sound of
it could be heard). CTRL+ALT+F1 does nothing, even if I try to log in and type
find / nothing happens (screen remains black, HDD LED turned off, apparently no
action). Computer most likely frozen.

kernel-2.6.23-0.15.rc0.git1.fc8:
suspend: ok
resume: ok

kernel-2.6.23-0.29.rc0.git6.fc8.i686 works fine for me (suspend to RAM/disk) 
with FC7, while 2.6.22.1-20.fc7 locks the system at resume after suspend (to 
RAM).
Martin, thank you for the fc8 kernel on fc7 tip :-)

I'm running 

# uname -r
2.6.22-8.fc7

and my laptop suspends but locks on resume.

(In reply to comment #25)
> # uname -r
> 2.6.22-8.fc7
> 
> and my laptop suspends but locks on resume.

please try kernel-2.6.23-0.29.rc0.git6.fc8.i686 or 
kernel-2.6.23-0.30.rc0.git6.fc8.i686, they both work fine for me (ex: 
http://koji.fedoraproject.org/koji/buildinfo?buildID=11395)

I'll try to run every 2.6.23-xx kernel and find the version in which it starts 
to work for me... if time permits...

# uname -a
Linux fedora7 2.6.23-0.29.rc0.git6.fc8 #1 SMP Mon Jul 16 17:14:27 EDT 2007 i686
i686 i386 GNU/Linux

# lshal |grep quirk
  power_management.quirk.vbe_post = true  (bool)
  power_management.quirk.vbemode_restore = true  (bool)


suspend: ok

resume: screen black, HDD however show no activity (i.e. no sound of
it could be heard). CTRL+ALT+F1 does nothing, even if I try to log in and type
find / nothing happens (screen remains black, HDD LED turned off, apparently no
action). Computer most likely frozen.

I have HP Compaq nx7300 laptop

Just for the record, with kernel-2.6.23-0.29.rc0.git6.fc8.i686 my laptop 
suspends to RAM and resumes fine. With the next possible (git14 I think) 
kernel it does not work again... :-(   (Acer Aspire 5610)

I compiled 2.6.23-rc2 with configuration based on fedora's kernels but turned 
off the new PATA/IDE subsystem (now I have /dev/hda instead of /dev/sda and 
IPv6 disabled) and suspend to ram works again. My previous attempt (2.6.23-rc1 
I think) with the new PATA/IDE subsystem failed.
I will recompile and try rc2 with the new subsystem if that would help...

For the record, kernel parameter hpet=disable fixed thing for me with fc7, fc8 
seems to not need this any more :-)

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

closing based on comment #30