Mark Lord wrote:
Okay, here's the syslog. Find the lines that begin with ">>>>> ",
and you'll see ata_pci_device_resume followed by two
ata_scsi_device_resume.
Thanks.
One thought about Linus's one-liner (and the original patch),
is that two seconds may be too short --> I'd suggest a 10-second
timeout there for notebook drive spin-up. Or one could be very
paranoid and use the standard ATA 31-second timeout.
I wonder if your faster 64-bit machine had that problem?
(two seconds not long enough, whereas my 32-bit machine is slower
gettting to that point, so two-seconds is then enough?).
Well, there's a udelay() in there to guarantee the timing, and 64-bit
machine is definitely newer and faster, so I doubt that would explain
the hardlock I see. I'll test a longer ata_busy_wait() anyway, just to
be sure.
Overall we _really really_ need to do full controller init. I'm
honestly surprised the delay hack works, because the resume skips ALL of
the controller init in piix_sata_probe(). Since the Linus patch doesn't
touch PCS at all, it is _luck_ that the controller silicon gives you a
useful value when it goes to PCI D0 state.
I posted a version that does full bus probe as "[PATCH alt4] libata
resume fixes" just now.
Jeff
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
