On Tuesday 08 August 2006 12:43, Jens Axboe wrote:

On Tue, Aug 08 2006, Jiri Slaby wrote:

quoted

Rafael J. Wysocki wrote:

quoted

On Monday 07 August 2006 18:23, Jason Lunz wrote:

quoted

In gmane.linux.kernel, you wrote:

quoted

quoted

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/

I tried it and guess what :)... swsusp doesn't work :@.

This time I was able to dump process states with sysrq-t:
http://www.fi.muni.cz/~xslaby/sklad/ide2.gif

My guess is ide2/2.0 dies (hpt370 driver), since last thing kernel 
prints is suspending device 2.0

Does it go away if you revert this?
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch

That should only affect resume, not suspend, but it does mess around
with ide power management. Is this maybe happening on the *second*
suspend?

quoted

-hdc: ATAPI 63X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
+hdc: ATAPI CD-ROM drive, 0kB Cache, UDMA(33)

This looks suspicious. -mm does have several ide-fix-hpt3xx patches.

I found that git-block.patch broke the suspend for me.  Still have no idea
what's up with it.

I suspect elevator changes. The wait_for_completion is not woken in
ide-io by ll_rw_blk. But I don't understand block layer too much.

The ide changes are far more likely, it's probably missing a completion.

Actually I think the commit f74bf2e6b415588e562fdcfdd454d587eb33cd46
(Remove ->waiting member from struct request) is wrong, because
generic_ide_suspend() uses the end_of_io member of rq to pass the PM data
to ide_do_drive_cmd() where the pointer gets overwritten by &wait (must_wait
is "true", because action == ide_wait).  Previously &wait was stored in
rq->waiting and it didn't overwrite the PM data.

Haven't tested yet, though.

Greetings,
Rafael