Hello,

David Greaves wrote:

Just to be clear. This problem is where my system won't resume after s2d
unless I umount my xfs over raid6 filesystem.

This is really weird.  I don't see how xfs mount can affect this at all.

[--snip--]

So now this compiles but it does cause the problem:

umount /huge
echo platform > /sys/power/disk
echo disk > /sys/power/state
# resumes fine

mount /huge
echo platform > /sys/power/disk
echo disk > /sys/power/state
# won't resume

How hard does the machine freeze?  Can you use sysrq?  If so, please
dump sysrq-t.

  Behavior difference introduced by the

quoted

reimplementation is serialization of resume sequence, so it takes more
time.  My test machine had problems resuming if resume took too long
even with the previous implementation.  It didn't matter whether the
long resuming sequence is caused by too many controllers or explicit
ssleep().  If time needed for resume sequence is over certain threshold,
machine hangs while resuming.  I thought it was a BIOS glitch and didn't
dig into it but you might be seeing the same issue.

given the mount/umount thing this sounds unlikely... but what do I know?

No I don't think this is the same problem either.  The problem I
described happened during resume from s2ram.

resume does throw up:
ATA: abnormal status 0x7F on port 0x0001b007
ATA: abnormal status 0x7F on port 0x0001b007
ATA: abnormal status 0x7F on port 0x0001a407
ATA: abnormal status 0x7F on port 0x0001a407

which I've not noticed before... oh, alright, I'll check...
reboots to 2.6.21, suspend, resume...
nope, not output on resume in 2.6.21

The messages don't really matter.

Thanks.

-- 
tejun