PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Mark Lord]

Guys,

I'm still lurking around in the shadows here, but something just
came to light on another project which might affect mainline.

We're using new, cheap 32GB Transcend MLC SSDs with a PATA interface.
Normally, folks would use UDMA with these, and never notice an issue.

But this project has only (very slow) PIO interfaces, and the SSDs
didn't work at first on the old kernel here.

The fix, was to increase the allowed amount of time for the drive
to assert DRQ after s/w issues a PIO WRITE to the drive.

The kernel I was using here had a 50msec timeout (ATA spec requires
at least 20msec), but this was insufficient for these SSDs.

I suspect the SSDs perform an ERASE operation on WRITE,
before asserting DRQ, and this takes a bit of time.

Not sure how much time, but we just bumped the timeout up
to a few seconds and all is working again.  Overkill, yes.

So.. how long does libata and current IDE allow for initial DRQ assertion?
It should probably be at least 500msec or more now.

Cheers

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Alan Cox]

> So.. how long does libata and current IDE allow for initial DRQ assertion?
> It should probably be at least 500msec or more now.

I think we need to rewrite the PIO code paths to use disable/enable_irq
masking first before getting into adding long delays on PIO paths.

Alan

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Robert Hancock]

Mark Lord wrote:
> Guys,
> 
> I'm still lurking around in the shadows here, but something just
> came to light on another project which might affect mainline.
> 
> We're using new, cheap 32GB Transcend MLC SSDs with a PATA interface.
> Normally, folks would use UDMA with these, and never notice an issue.
> 
> But this project has only (very slow) PIO interfaces, and the SSDs
> didn't work at first on the old kernel here.
> 
> The fix, was to increase the allowed amount of time for the drive
> to assert DRQ after s/w issues a PIO WRITE to the drive.
> 
> The kernel I was using here had a 50msec timeout (ATA spec requires
> at least 20msec), but this was insufficient for these SSDs.
> 
> I suspect the SSDs perform an ERASE operation on WRITE,
> before asserting DRQ, and this takes a bit of time.
> 
> Not sure how much time, but we just bumped the timeout up
> to a few seconds and all is working again.  Overkill, yes.
> 
> So.. how long does libata and current IDE allow for initial DRQ assertion?
> It should probably be at least 500msec or more now.

No idea about IDE, but libata does not wait at all for DRQ assertion 
specifically, after issuing the PIO command it waits for BSY to be 
deasserted and then expects either DRQ, DF or ERR to be set, else it's a 
host state machine violation and triggers error handling. According to 
the ATA spec, the device is specifically not allowed to set DRQ to one 
while BSY is not asserted.

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Mark Lord]

Alan Cox wrote:
>> So.. how long does libata and current IDE allow for initial DRQ assertion?
>> It should probably be at least 500msec or more now.
> 
> I think we need to rewrite the PIO code paths to use disable/enable_irq
> masking first before getting into adding long delays on PIO paths.
..

Yeah, that would be a good thing to do.
But in the meanwhile, a longer timeout there doesn't affect
any currently working systems -- they'll still wait only as long
as they currently do.  And a longer timeout *will* enable these
SSDs to work where they otherwise would not.

But perhaps the timeout is already long enough?
I don't know where the current timeout is hiding in libata.  :)

Cheers

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Robert Hancock]

Mark Lord wrote:
> Robert Hancock wrote:
> ..
>> No idea about IDE, but libata does not wait at all for DRQ assertion 
>> specifically, after issuing the PIO command it waits for BSY to be 
>> deasserted and then expects either DRQ, DF or ERR to be set, else it's 
>> a host state machine violation and triggers error handling. According 
>> to the ATA spec, the device is specifically not allowed to set DRQ to 
>> one while BSY is not asserted.
> ..
> 
> Okay, so how long does it wait for BSY=0 under that same circumstance?

Just the overall command completion timeout, it would appear.. usually 
30 seconds I believe.

IDE is really only waiting 50msec in this case? That seems rather 
wrong.. I don't see anywhere in the current ATA specs that requires the 
drive to respond within that time period.

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Sergei Shtylyov]

Hello.

Robert Hancock wrote:

>>> No idea about IDE, but libata does not wait at all for DRQ assertion 
>>> specifically, after issuing the PIO command it waits for BSY to be 
>>> deasserted and then expects either DRQ, DF or ERR to be set, else 
>>> it's a host state machine violation and triggers error handling. 
>>> According to the ATA spec, the device is specifically not allowed to 
>>> set DRQ to one while BSY is not asserted.

>> ..

>> Okay, so how long does it wait for BSY=0 under that same circumstance?

> Just the overall command completion timeout, it would appear.. usually 
> 30 seconds I believe.

    I don't think it's as long as that with libata.

> IDE is really only waiting 50msec in this case? That seems rather 
> wrong.. I don't see anywhere in the current ATA specs that requires the 
> drive to respond within that time period.

    It's waiting the whole 50 ms where the maximum specified by the original 
ATA was 20 ms. What seems really wrong to me is making the host poll for BSY=0 
for an indeterminate time -- though it's always been a really stupid part of 
the ATA command protocol. Well, at least it never stroke anybody before those 
insane SSDs appeared on market. :-)

WBR, Sergei

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Sergei Shtylyov]

Robert Hancock wrote:

>>> No idea about IDE, but libata does not wait at all for DRQ assertion 
>>> specifically, after issuing the PIO command it waits for BSY to be 
>>> deasserted and then expects either DRQ, DF or ERR to be set, else 
>>> it's a host state machine violation and triggers error handling. 
>>> According to the ATA spec, the device is specifically not allowed to 
>>> set DRQ to one while BSY is not asserted.

> IDE is really only waiting 50msec in this case? That seems rather 

    The whole 100 ms if you look at how WAIT_DRQ is #define'd...

MBR, Sergei

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Bartlomiej Zolnierkiewicz]

On Wednesday 31 December 2008, Mark Lord wrote:
> Alan Cox wrote:
> >> So.. how long does libata and current IDE allow for initial DRQ assertion?
> >> It should probably be at least 500msec or more now.
> > 
> > I think we need to rewrite the PIO code paths to use disable/enable_irq
> > masking first before getting into adding long delays on PIO paths.
> ..
> 
> Yeah, that would be a good thing to do.

Unless shared IRQs come into the picture -- in such case disabling IRQ
for 0.5sec doesn't sound too sexy...

> But in the meanwhile, a longer timeout there doesn't affect
> any currently working systems -- they'll still wait only as long
> as they currently do.  And a longer timeout *will* enable these
> SSDs to work where they otherwise would not.
> 
> But perhaps the timeout is already long enough?
> I don't know where the current timeout is hiding in libata.  :)

When it comes to IDE the timeout is defined by WAIT_DRQ in <linux/ide.h>
and is currently set to 100ms.  There should be no problem with increasing
it if it would help to get some devices to work (please just send a patch).

Thanks,
Bart

Re: PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs

[Mark Lord]

Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 31 December 2008, Mark Lord wrote:
>> Alan Cox wrote:
>>>> So.. how long does libata and current IDE allow for initial DRQ assertion?
>>>> It should probably be at least 500msec or more now.
>>> I think we need to rewrite the PIO code paths to use disable/enable_irq
>>> masking first before getting into adding long delays on PIO paths.
>> ..
>>
>> Yeah, that would be a good thing to do.
> 
> Unless shared IRQs come into the picture -- in such case disabling IRQ
> for 0.5sec doesn't sound too sexy...
> 
>> But in the meanwhile, a longer timeout there doesn't affect
>> any currently working systems -- they'll still wait only as long
>> as they currently do.  And a longer timeout *will* enable these
>> SSDs to work where they otherwise would not.
>>
>> But perhaps the timeout is already long enough?
>> I don't know where the current timeout is hiding in libata.  :)
> 
> When it comes to IDE the timeout is defined by WAIT_DRQ in <linux/ide.h>
> and is currently set to 100ms.  There should be no problem with increasing
> it if it would help to get some devices to work (please just send a patch).
..

That's probably enough.  50msec wasn't, so we just bumped to a few seconds
in the custom kernel and sent them on their way happy.

But if it pops up again here (timeout waiting for initial DRQ),
then we all know what to do about it, I suppose.
Most people will never notice a problem, because most systems
aren't stuck in the PIO-only dark ages now.  :)

Cheers