Does the following patch fix the problem?
Yes, it does - thanks!
Jan
*
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index e75966b..39627c7 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -679,24 +679,20 @@ static void
Jan Beulich wrote:
Do you have any real case where the above behavior causes problem?
It's not strictly a problem (i.e. nothing really mis-behaves), but it made
me wonder why the box I saw this on gets 6 ahci device instances set
up when spec as well as port map say there ought to be only 5.
Jan Beulich wrote:
I understand your concern, but I think you also understand mine. So
I'm not really asking for general reversal of the logic, but to perhaps
make it just a little smarter. The (not generally usable according to
what you said earlier) experiment I made was to use the smaller
Tejun Heo [EMAIL PROTECTED] 02/02/08 9:16 AM
Jan Beulich wrote:
Jeff,
while I realize that Intel's documentation may not be consistent with
anything more generic (which I don't know where to look for), this
current behavior seems to contradict what Intel documents for ESB2:
23.3.1.4 PI
Well, two values don't agree with each other and we know for a fact that
vendors sometimes get PI wrong, so we trust n_ports in such cases. We
can reverse the behavior but that's likely to cause more problems than
it fixes.
I understand your concern, but I think you also understand mine. So
I'm
Yes, we can be more smart if necessary. I don't know. The hardware is
clearly violating the spec which requires those two values to agree.
So are you saying the ESB2 spec is violating a higher level spec? I know
almost nothing about AHCI, so please forgive that question...
What status values
Jan Beulich wrote:
Jeff,
while I realize that Intel's documentation may not be consistent with
anything more generic (which I don't know where to look for), this
current behavior seems to contradict what Intel documents for ESB2:
23.3.1.4 PI – Ports Implemented Register (D31:F2)
Address
Jeff,
while I realize that Intel's documentation may not be consistent with
anything more generic (which I don't know where to look for), this
current behavior seems to contradict what Intel documents for ESB2:
23.3.1.4 PI – Ports Implemented Register (D31:F2)
Address Offset: ABAR + 0Ch–0Fh
