Hello, all.
As far as I can remember, the people in To: are all the ones who have
reported ata_piix PCS related device misdetection problem. This goes
way back to Nov, 2005 and, sorry, hasn't been resolved yet. Each time I
and other libata developers come up with a solution, it either doesn't
fix all the cases or creates a new case.
The following is my recollection of ata_piix PCS problem. It's from the
top of my head so might be inaccurate. Don't hesitate to correct me.
The first reports are from jfs@xxxxxxxxxxxxxxxx and 0602@xxxxxx IIRC,
both cases were on I6300 ESB (ICH5 variant). This was solved by adding
PIIX_FLAG_IGNORE_PCS to the entry. The intel doc also states that PCS
present bits on this controller cannot be used for device detection.
Note that this is before new EH was implemented.
Then, June this year, stevenm@xxxxxxx filed bug #6724 on kernel v2.6.17.
It was regular ICH5 which curiously clears PCS to zero between probing
of the first port and the second. It didn't matter whether the PCS
register itself was written to or not. It just clears to zero while
libata is probing the first port.
http://bugzilla.kernel.org/show_bug.cgi?id=6724
There were two proposed solutions. One was to cache PCS during
initialization, the other to ignore PCS on all ICH5s. Both fixed
stevenm@xxxxxxx's case. Note that this was before Jeff's
fix-over-zealous-PCS-update patch.
I think there were a few similar reports. ICH8 came into the scene
which used different PCS layout and had ghost device detection problem
which can delay boot process a lot - ICH7 also has the same issue. So,
at the time, PCS seemed unreliable while standard ATA device detection
procedure worked okay on ICH5 while the opposite was true for ICH7 and
later. So, we added IGNORE_PCS to ICH5 while honoring PCS strictly on
other controllers.
As we were seeing multiple problems across different controllers,
several attempts were made to alleviate the situation. W/ IGNORE_PCS
added to ICH5 and other PCS related updates, it seemed that we had
everything right, which wasn't the case, unfortunately.
kaos@xxxxxxxxxx reported v2.6.18-rc5 sometimes failed to detect devices
on ICH7 after soft reboots - PCS reported 0. I thought this was related
to fix-overzealous-PCS-update patch and proposed a fix but it didn't
work. Then, nabiki@xxxxxxxxxxx filed bug #7166.
http://bugzilla.kernel.org/show_bug.cgi?id=7166
The bug report says that 2.6.17.13 failed to probe the secondary port.
2.6.17.13 does not have either of honor-PCS or
fix-overzealous-PCS-update, but has new EH and some other PCS related
updates. But, I'm not sure whether those changes cause the problem or
it's just getting reported now as it occurs intermittently.
Another interesting input is that, IIRC, more than one people including
Keith, reported that the problem seems to be related to timing issue -
whether i386 or x86_64 kernel was used, whether kdb was compiled in or not.
So, that the current situation according to my not-so-accurate memory.
At this point, I'm curious how intel does it in their Windows driver. I
think we should replicate its behavior if possible. Any other ideas?
Thanks.
--
tejun
-
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
