Hello, Gary.

Gary Hade wrote:

quoted

quoted

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