Howdy, Gary Hade wrote: > I noticed that Tejun recently provided a "libata: handle 0xff status > properly" patch that is now in mainline that improves this code > re: http://marc.theaimsgroup.com/?l=linux-ide&m=116038642105802&w=2 > but I found that the check still failed but more silently and with no > retries. > > I decided to try increasing the delay that preceeds the above > check [ msleep(150); ] and found that a change from 150ms to > 1000ms caused the problem to disappear. Aieeee, 150ms not enough for the device to send the first FIS after SRST? > I then replaced the msleep(150); with: > { > int i, ms = 5; > msleep(ms); > ata_port_printk(ap, KERN_INFO, "status @ %d ms: 0x%x\n", > ms, ata_check_status(ap)); > for (i = 1; i <= 20; i++) { > ms += 50; > msleep(50); > ata_port_printk(ap, KERN_INFO, "status @ %d ms: 0x%x\n", > ms, ata_check_status(ap)); > } > } > > Output for two cable placement configurations (0xFF check failure > and 0xFF check success) are included below. Note that there are > cable placement configurations for both the hard drive and > GoVault where the initial status is 0xff. i.e. both transition > from 0xff to 0x7f when BSY bit is cleared but it is taking MUCH > longer for the GoVault (600-700ms for GoVault and <5ms for > hard drive). It does not appear that the 0xff starting status > is device specific. > > So, it appears that we have a situation with this SATA controller > where a 0xFF status is not an accurate indication that there is > no device. > > Although the 150ms to 1000ms delay increase works for the GoVault > device I am not sure if it is the best long term fix for the problem. 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? -- 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
