Tejun Heo wrote:
Justin Mattock wrote:
Can you please post the result of "lspci -nn". The error per-se is
okay.
The drive failed to respond to IDENTIFY at the first try but on
retrial it
responded okay.
Hello; Thank you for the response.
I guess you can say I have a tendancy to freak out or panic with
little things like that,
below is lspci -nn.
Hmm... ICH7. I recently had a different bug report on < ICH7 (don't
remember whether it was 4, 5 or 6). In that case, the drive went
completely offline after resume. It never came back after retries. It
seemed like the device needed hardreset after waking up from sleep which
we currently only support for >= ICH8).
Mark, you played with the hardreset bits in PCS (right?) register. What
do you think about adding it? Last time I played with it, the presence
detection seemed unreliable so hotplug might not work too well but as
long as the hardreset itself works we can augment it with follow up srst
for cases like this.
..
What I did back in 2007 was, implement hot plug/unplug for ICH5,
done by polling the PCS bits.
It works, and is reportedly quite reliable, even though there is still a
tiny theoretical loophole where the chipset could lock up.
The glitch on ICH5, at least, is that the PCS bits work fine for detecting
drive insertions, but not drive removals. To detect a drive removal,
one has to first toggle the enable line (1..0..1) in PCS, and then wait
for the PHY to try and sync up afterwards (microseconds).
The code didn't go upstream because it conflicted somewhat with the pending
hotplug polling framework you had in development at the time. :)
What's the scoop with that now, anyways? The sata_mv driver will eventually
want hotplug polling to deal with port multiplier ports -- it cannot use AN.
Cheers
--
To unsubscribe from this list: 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
