Hello.
Mark Lord wrote:
On Michael's real old ata_piix, somehow the ERR bit is set on phantom
device defeating our phantom device detection logic. We can relax
phantom device condition but that increases the risk of
misdetection on
actual IDENTIFY errors. Any ideas how we can nicely work around this
one?
..
Mmm.. I'm way out of the loop on this now,
so please pardon me suggesting things known not to work, but..
1. Pay attention to ATA status register on this chipset?
Eg. if it has BUSY, or reads 0x7f, then don't IDENTIFY?
2. Check for device signature before trying IDENTIFY?
3. Try a r/w test on the data register first, to see if there's
really hardware attached to it?
We already do 1, 2 and 3. The problem with phantom device is that the
existent device on the channel replies to acesses to the other
non-existent device and the NODEV_HINT detection is the last line of
defense which successfully evades all the other mechanisms. And now
we have this controller/device combination which successfully tricks
it too. :-(
..
Mmm.. but he's using "really old ata_piix" hardware, as in what Intel
once called the "Triton" (or Triton II) chipset.
The "original Triton" IDE is supported by pata_oldpiix.
Which I wrote support
for in drivers/ide, way back when.. and we never had this problem.
The support for the "original Triton" is drivers/ide/ is still broken
after all these years. The driver assumes that the slave IDE timing
register always present -- which the origina 82371FB didn't have. :-(
WBR, Sergei
--
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
