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