Tejun Heo wrote: > I would be surprised if Kovid's sda not detected case is caused by this. > For GoVault (that's SATAPI right?), yeah, maybe. For an ATA disk, no > way (hopefully). > > Can you consult with quantum about it? If they verify your fix (ie, > GoVault sometimes take more than 150ms to transmit the first D2H Reg FIs > after SRST), I'll push similar patch upstream. > > Hmm.. or do we have to wait !BSY here as old IDE did? More thoughts. * IIRC, ata_piix reports 0xff if SATA link is broken. 0x80 or something similar if link established && waiting for the first FIS. Not sure whether this always holds but it tends to work that way. So, 0xff status means phy link broken, which shouldn't happen after SRST. Hmmm.. * Recently in ata_bus_softreset() and waiting functions, we've added the assumption status==0xff indicates empty port. This is taken from the IDE layer and proven to work for PATA devices. I'm not sure we can safely use this to SATA devices tho. If PHY is broken or the first FIS isn't received, arbitrary value (sometimes accidentally) chosen by the controller is used which may as well be 0xff. But, then again, many controllers do mean that there is no devices by 0xff status including ata_piix w/ its now infamous phantom device problems. I think we should honor 0xff iff SCR on/offline status is not available. How does that sound? -- 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
