[haiku-bugs] Re: [Haiku] #15569: usb_disk stalls & unmounts when large I/O transfers are not queued
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Thu, 12 Mar 2020 19:37:19 -0000
#15569: usb_disk stalls & unmounts when large I/O transfers are not queued
--------------------------------+----------------------------
Reporter: X512 | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Drivers/Disk/USB | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
--------------------------------+----------------------------
Comment (by waddlesplash):
At the hardware level there does not appear to be any constraint, so, if
we know we will be reading a very large chunk, I don't see why we
shouldn't do that in a single go.
Well, for XHCI at least, "event data" notifications have a 24-bit size
value (16MB max when unsigned), and after that it wraps. We could
restructure the XHCI driver to insert more than one "event data" item as
necessary, but this would require doing pretty different accounting vs.
what we are doing now.
What happens here is that the first step succeeds, but the second one
fails. This leaves the device waiting for the data transfer forever.
Is there any chance to send more than one transfer to handle one SCSI
command? Or is that not allowed by the specification?
I don't see why it should be usb_disk responsibility to split the
transfer in smaller chunks. It can't know the limitations of the
underlying levels, and should let those decide how to handle things.
Well, I don't know what SATA does, but NVMe at least has a "max transfer
size" and the driver internally breaks up transfers larger than that.
Also, why should it be the I/O scheduler's job to take care of this? If
the I/O scheduler wants to transfer 16MB of data, the driver needs to
decide the most efficient way to do that, not the I/O scheduler. All
drivers currently do that (I hope) the most efficient way for them, so
usb_disk should do the same here.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/15569#comment:12>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
