#14835: libusb syscall stalls when EHCI errors
------------------------------+------------------------------
Reporter: pulkomandy | Owner: mmlr
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Drivers/USB/EHCI | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
------------------------------+------------------------------
https://github.com/haikuports/haikuports/issues/1345
{{{
KERN: usb_disk: got device name "Canon MP620 series 0109": No error
KERN: usb error ehci -1: qtd (0xe4c7000) error: 0x40000148
KERN: usb error ehci -1: qtd (0xe30fa80) error: 0x801f8049
KERN: usb_disk: sending the command block wrapper failed: Device check-sum
error
KERN: usb error ehci -1: qtd (0xe30fc00) error: 0x00080248
KERN: usb error ehci -1: qtd (0xe30fe00) error: 0x00080248
KERN: usb error ehci -1: qtd (0xe310000) error: 0x00080248
KERN: usb hub 18: port 4: device removed
}}}
Error 0x80248 means we failed sending an 8 byte setup token, transaction
halted because device is in error state.
The transfer should either be retried, or the error raised to the calling
code by the mean of the USB transfer completion callback. But it seems
this never happens. As a result the ioctl syscall doing the operation
never returns.
From a quick look at the EHCI code, it appears that we don't call the
callback for cancelled transfers. We cancel transfers without calling the
callback if doing a "force" cancel, which happens in bus manager Pipe
destructor.
So basically, we could end up in this situation if the Pipe was deleted
while transfers where queued, and they were not properly cancelled.
I can produce a similar issue with sigrok-cli and an fx2lafw device.
I will be studying the bus manager code, but if someone with more
knowledge of the architecture could have a look, that would be great.
--
Ticket URL: <https://dev.haiku-os.org/ticket/14835>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.