Hello, Gary. Gary Hade wrote: >>> 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. >> Thanks. If you think that changes to increase the delays are >> the way to go (at least until we can find a better solution) >> I can provide patches. > > Tejun, > I haven't heard anything from you on this so I'm including a delay > increase patch against 2.6.20-rc6 for the 'ata-piix' case below. > I hope that you, Jeff, and others find this acceptable. Sorry about being unresponsive. The thing is that the change adds unnecessary 2 secs of delay to a lot of other normal device-not-present cases, so I was hesitant to ack the patch. I'll give it more thoughts (and respond timely this time :-) > With respect to the 'ahci' case w/2.6.20-rc6 the GoVault device is > useable following boot although the below messages are being logged > during initialization. Please let me know if you have any thoughts > on this. > scsi1 : ahci > ata2: softreset failed (port busy but CLO unavailable) > ata2: softreset failed, retrying in 5 secs > ata2: port is slow to respond, please be patient (Status 0x80) > ata2: port failed to respond (30 secs, Status 0x80) > ata2: COMRESET failed (device not ready) > ata2: hardreset failed, retrying in 5 secs > ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata2.00: ATAPI, max UDMA/66 > ata2.00: configured for UDMA/66 The above should have been fixed in 2.6.20-rc6. Please test it. It was caused by the ahci driver incorrectly clearing ahci CAP register and fixed recently. 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
