David Greaves wrote:
> Tejun Heo wrote:
>> Your controller is repeatedly reporting PHY readiness changed exception.
>> Are you reading the system image from the device attached to the first
>> SATA port?
>
> Yes if you mean 1st as in the one after the zero-th ...
I meant the first first (0th).
>> How reproducible is the problem? Does the problem go away or occur more
>> often if you change the drive you write the memory image to?
>
> I don't think there should be activity on the sda drive during resume
> itself.
>
> [I broke my / md mirror and am using some of that for swap/resume for now]
>
> I did change the swap/resume device to sdd2 (different controller,
> onboard sata_via) and there was no EH during resume. The system seemed
> OK, wrote a few Gb of video and did a kernel compile.
> I repeated this test, no EH during resume, no problems.
> I even ran xfs_fsr, the defragment utility, to stress the fs.
>
> I retain this configuration and try again tonight but it looks like
> there _may_ be a link between EH during resume and my problems...
>
> Of course, I don't understand why it *should* EH during resume, it
> doesn't during boot or normal operation...
EH occurs during boot, suspend and resume all the time. It just runs in
quiet mode to avoid disturbing the users too much. In your case, EH is
kicking in due to actual exception conditions so it's being verbose to
give clue about what's going on.
It's really weird tho. The PHY RDY status changed events are coming
from the device which is NOT used while resuming and it's before any
actual PM events are triggered. Your kernel just boots, swsusp realizes
it's resuming and tries to read memory image from the swap device.
While reading, the disk controller raises consecutive PHY readiness
changed interrupts. EH recovers them alright but the end result seems
to indicate that the loaded image is corrupt.
So, there's no device suspend/resume code involved at all. The kernel
just booted and is trying to read data from the drive. Please try with
only the first drive attached and see what happens.
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
