Re: question about boot time drive initialization

Re: question about boot time drive initialization

[Tejun Heo]

[CC'ing jeff and linux-ide, hope you don't mind]

Hello, Eric D. Mudama.

Eric D. Mudama wrote:
> Immediately following POR (power on reset) it takes our hardware a few
> milliseconds to initialize and test our own hardware.  Near the end of
> that window, our drive will respond to COMRESET with a COMINIT.
> 
> The FIS34 won't be generated until after the drive has spun up
> successfully and loaded it's code from the media.  This is expected to
> take anywhere from 3-7 seconds for desktop drives with 1-4 platters.
> Notebooks spin up significantly faster.

I see.

> Is power always active in this infrastructure, and will the host
> respond to COMINIT with either a COMRESET or a COMWAKE?  If so, I'd
> just wait for the FIS34.  If you don't see a FIS34 within say 10
> seconds, I'd hit the drive with a COMRESET.

The problem I'm having is that not all controllers can catch the initial 
FIS34 reliably after hotplugging.  sil3112/4 family seems to always 
catch the FIS thus reliably clearing ATA_BUSY (they seem to set ATA_BUSY 
automatically when PHY status changes then clears it on the reception of 
ATA_BUSY).

But for more complex controllers, it's not always the case.  sil3124/32 
actually doesn't have single TF image.  TF images are tied to commands. 
  No command, no TF regs.  So, the controller doesn't provide indication 
for the first FIS.  Fortunately, issuing SRST makes the controller wait 
for ATA_BUSY reliably.  I don't know whether the controller waits for 
!ATA_BUSY before issuing SRST (unlikely), or the drive handles SRST 
okay, or the controller simply ignores R_ERR on SRST issue and thinks 
SRST completed when it actually receives the first FIS34.

ATM, AHCI seems a little bit worse.  Unlike sil3124/32, it can wait for 
the first FIS34 but it fails more often than not.  The drives are 
transmitting FIS34 (thus 3112/4 works) but AHCI sometimes choose to 
ignore it (nothing appears in the FIS reception area) and eventually 
times out.  Adding delays here and there seems to make things work but 
it seems like a lousy solution.  Argghhh...

This problem becomes more evident with PM.  PM spec omits the 'waiting 
for the first FIS34' part in the initialization sequence because 
controllers might not be able to handle the FIS.  Actually, when a new 
device gets plugged the port's X bit is turned on and all FIS 
transmissions are blocked.  So, there's no way for the host controller 
to tell whether the device is ready for command or not and has no other 
way than issuing SRST blindly after resuming the link.

On EH case (transient link failure), this is okay as the drive can 
handle the SRST okay, but it seems to cause problems on hotplug case. 
What happens is the controller issues SRST before the drive transmits 
the first FIS34.  As said above, this is the spec-sanctioned enumeration 
sequence.

I'm getting a lot of timeouts on the first reset after hotplug and still 
diddling with delays.  Any thoughts on how this should be solved?  Can 
drives handle SRST before it enters idle state after POR?

Thanks a lot and you're right on spot.

-- 
tejun

Re: question about boot time drive initialization

[saeed bishara]

> > Is power always active in this infrastructure, and will the host
> > respond to COMINIT with either a COMRESET or a COMWAKE?  If so, I'd
> > just wait for the FIS34.  If you don't see a FIS34 within say 10
> > seconds, I'd hit the drive with a COMRESET.

I have seen some SATA drives that sends their FIS34 only after 16 seconds.

> This problem becomes more evident with PM.  PM spec omits the 'waiting
> for the first FIS34' part in the initialization sequence because
> controllers might not be able to handle the FIS
or maybe the PM is still in Laegacy mode and the FIS34 comes from port 0.

.  Actually, when a new
> device gets plugged the port's X bit is turned on and all FIS
> transmissions are blocked.  So, there's no way for the host controller
> to tell whether the device is ready for command or not and has no other
> way than issuing SRST blindly after resuming the link.
>
> On EH case (transient link failure), this is okay as the drive can
> handle the SRST okay, but it seems to cause problems on hotplug case.
> What happens is the controller issues SRST before the drive transmits
> the first FIS34.  As said above, this is the spec-sanctioned enumeration
> sequence.
>
> I'm getting a lot of timeouts on the first reset after hotplug and still
> diddling with delays.  Any thoughts on how this should be solved?  Can
> drives handle SRST before it enters idle state after POR?
>
yes, this is quoted from the ATA-6 standard , section 9.2 (Software
reset protocol)
"If the host sets the SRST bit in the Device Control register to one
before devices have completed execution of the software reset
protocol, then the devices shall restart execution of the software
reset protocol from the beginning."

I've been dealing with Sata drives for along time, and alwasy I sent
sw reset immediatly after OOB sequence (in order to detect PM), all
drives did ok with that, except for one single model, and that was
decalred as bug of the drive and fixed in updated firmware.

BTW, how do distenguesh between PM and ATAPI device? both of them have
the same signature?

saeed

Re: question about boot time drive initialization

[Tejun Heo]

Hello,

saeed bishara wrote:
>> > Is power always active in this infrastructure, and will the host
>> > respond to COMINIT with either a COMRESET or a COMWAKE?  If so, I'd
>> > just wait for the FIS34.  If you don't see a FIS34 within say 10
>> > seconds, I'd hit the drive with a COMRESET.
> 
> I have seen some SATA drives that sends their FIS34 only after 16 seconds.

I heard that some external storage products which emulate SATA interface 
take pretty long time to get ready after power-on.

[--snip--]
>> I'm getting a lot of timeouts on the first reset after hotplug and still
>> diddling with delays.  Any thoughts on how this should be solved?  Can
>> drives handle SRST before it enters idle state after POR?
>>
> yes, this is quoted from the ATA-6 standard , section 9.2 (Software
> reset protocol)
> "If the host sets the SRST bit in the Device Control register to one
> before devices have completed execution of the software reset
> protocol, then the devices shall restart execution of the software
> reset protocol from the beginning."

Yes, I've checked that clause too, but it only applies to SRST - if SRST 
is issued before the previous SRST isn't finished, honor the second SRST.

And the same document says, in section 9.1 (Power-on and hardware reset 
protocol).

"The host should not set the SRST bit to one in the Device Control 
register or issue a DEVICE RESET command while the BSY bit is set to one 
in either Device Status register as a result of executing the power-on 
or hardware reset protocol.  If the host sets the SRST bit in the Device 
Control register to one or issues a DEVICE RESET command before devices 
have completed execution of the power-on or hardware reset protocol, 
then the devices shall ignore the software reset or DEVICE RESET command."

So, the standard specifically forbids it.  The second half is a bit 
comforting though.

> 
> I've been dealing with Sata drives for along time, and alwasy I sent
> sw reset immediatly after OOB sequence (in order to detect PM), all
> drives did ok with that, except for one single model, and that was
> decalred as bug of the drive and fixed in updated firmware.

Hmmm.. weird.  That's not what I'm seeing.  AHCI reports command issue 
failure if something goes wrong while transmitting D2H fis for a command 
(probably when it sees R_ERR).  If I issue SRST shortly after power-on, 
AHCI fails SRST due to command issue failure.  So, it seems that the 
device rejects SRST before it transmits the first FIS34.

If I put the same device on sil3124/32 and perform HRST then SRST in a 
few secs, about the same thing seems to happen but sil3124/32 times out 
rather than reporting error immediately.

> BTW, how do distenguesh between PM and ATAPI device? both of them have
> the same signature?

This is the relevant comment.

	/* Apple's open source Darwin code hints that some devices only
	 * put a proper signature into the LBA mid/high registers,
	 * So, we only check those.  It's sufficient for uniqueness.
	 *
	 * ATA/ATAPI-7 (d1532v1r1: Feb. 19, 2003) specified separate
	 * signatures for ATA and ATAPI devices attached on SerialATA,
	 * 0x3c/0xc3 and 0x69/0x96 respectively.  However, SerialATA
	 * spec has never mentioned about using different signatures
	 * for ATA/ATAPI devices.  Then, Serial ATA II: Port
	 * Multiplier specification began to use 0x69/0x96 to identify
	 * port multpliers.  ATA/ATAPI-7 dropped descriptions about
	 * 0x3c/0xc3 and 0x69/0x96 shortly and described them as
	 * reserved for SerialATA.
	 *
	 * We follow the current spec and consider that 0x69/0x96
	 * identifies a port multiplier.  If there is an ATAPI device
	 * which returns 0x69/0x96 as its signature, we'll have to
	 * implement 'try PM, then try ATAPI' logic.
	 */

-- 
tejun

Re: question about boot time drive initialization

[saeed bishara]

> Hmmm.. weird.  That's not what I'm seeing.  AHCI reports command issue
> failure if something goes wrong while transmitting D2H fis for a command
you mean H2D, don't you?

> (probably when it sees R_ERR).  If I issue SRST shortly after power-on,
> AHCI fails SRST due to command issue failure.  So, it seems that the
> device rejects SRST before it transmits the first FIS34.

there is also the possiblity that the AHCI doesn't issue the FIS34 as
long as the BSY bit in the Status shadow register is set. so it's not
the disk fault. I have taken a look at the AHCI spec, and found that
you need to use the Commnad List Override (CLO) feature in order to
send FIS while BSY is set. do you use that ?

Re: question about boot time drive initialization

[Tejun Heo]

saeed bishara wrote:
>> Hmmm.. weird.  That's not what I'm seeing.  AHCI reports command issue
>> failure if something goes wrong while transmitting D2H fis for a command
> you mean H2D, don't you?

Yeap.

>> (probably when it sees R_ERR).  If I issue SRST shortly after power-on,
>> AHCI fails SRST due to command issue failure.  So, it seems that the
>> device rejects SRST before it transmits the first FIS34.
> 
> there is also the possiblity that the AHCI doesn't issue the FIS34 as
> long as the BSY bit in the Status shadow register is set. so it's not
> the disk fault. I have taken a look at the AHCI spec, and found that
> you need to use the Commnad List Override (CLO) feature in order to
> send FIS while BSY is set. do you use that ?

AHCI driver does CLO if necessary before issuing SRST, so I don't think 
CLO is the issue here.

-- 
tejun