Gary Hade wrote: > Some of my random thoughts: > There does appear to be this invalid assumption that 0xFF status > always implies device-not-present. The status register access > restrictions in ATA/ATAPI-7 V1 5.14.2 include the statement "The > contents of this register, except for BSY, shall be ignored when > BSY is set to one." which the code does not honor. There is apparently > past experience that 0xFF status implies device-not-present for some > controllers (the odd clowns :) but I have no idea how common these are. The 0xff is the value we get when there is no device present and the motherboard manufacturer forgot to pull down the ATA bus. It's not very uncommon in cheap PATA world and, following the weird tradition, some SATA controllers choose to emulate 0xff if there is no device attached (link not established). Not sure how many of them does it but intel's SATA chipset is one of them, so we're pretty much stuck with it. ie. In many P/SATA setups, your patch would add 2 extra secs of waiting for empty ports. > We obviously can't get rid of the check but since we cannot clear > the read-only status register and there appears to be no specification > dictated upper limit on how long it should take for a software reset to > complete it just seems like we need to wait long enough to support the > slowest known device which may be the GoVault. Agreed but still hesitant to ack the patch. :-) I'm gonna work on parallel probing for libata. I think we can easily hide extra 2 secs of waiting with parallel probing. It will take some time but that seems to be the 'right' thing to do especially considering the fact that 150ms sleep has been enough for gazillions of ATA devices during last decade except for this GoVault drive. I'll leave this thread in my to-do folder and apply your patch after parallel probing is in place (optimistic ETA 1 month). How does that sound? 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
