Hello,

David Greaves wrote:
quoted text
> 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--]
quoted text
> 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.

quoted text
>   Behavior difference introduced by the
>> 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.

quoted text
> 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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/