PIO with SSDs: needs a long DRQ-after-command timeout for WRITEs
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
Quoted 2 lines
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
Quoted 5 lines · Alan Cox
Quoted 2 lines
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
Quoted 9 lines · Mark Lord
Quoted 5 lines · Alan Cox
Quoted 2 lines
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...
Quoted 7 lines
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
Quoted 18 lines · Bartlomiej Zolnierkiewicz
Quoted 8 lines · Mark Lord
Quoted 4 lines · Alan Cox
Quoted 2 lines
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...
Quoted 5 lines
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.
Quoted 6 lines
Quoted 2 lines
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_DRQin <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
Quoted 17 lines · 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.
Quoted 8 lines
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.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Mark Lord
Robert Hancock wrote:
..Quoted 1 line
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.
Hello.
Quoted 7 lines · Robert Hancock
Quoted 5 lines
Quoted 1 line
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.
Quoted 1 line
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
Quoted 3 lines · Robert Hancock
Quoted 1 line
Quoted 1 line
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