Opened 5 years ago
Last modified 3 years ago
#15333 assigned bug
Canon scanner does not function on USB 3.0 ports
| Reported by: | vidrep | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Drivers/USB | Version: | R1/Development |
| Keywords: | Cc: | pulkomandy | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
hrev53458 x86_64
Hardware: Canon MP620 multifunction printer
Software: Sanity 0.6-5, sane_backends 1.0.27-4, libusb 1.0.22-4
When connecting a Canon MP620 multifunction printer to a USB 2.0 port, it functions normally. Connecting to any USB 3.0 port, whether on-board, or on a plug-in card results in no functionality.
Attachments (13)
Change History (33)
by , 5 years ago
| Attachment: | USB_2.0.syslog added |
|---|
by , 5 years ago
| Attachment: | USB_3.0.syslog added |
|---|
by , 5 years ago
| Attachment: | listdev.txt added |
|---|
by , 5 years ago
| Attachment: | Canon MP620 USB 2.0 added |
|---|
by , 5 years ago
| Attachment: | Canon MP620 USB 3.0 added |
|---|
comment:1 by , 5 years ago
| Component: | Drivers/USB → Drivers/USB/XHCI |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:5 by , 5 years ago
Tested again with hrev53855. Printer works on USB 3.0 port, but scanner is not detected (same as before). Plugging it into a USB 2.0 port, scanner is detected again.
by , 5 years ago
comment:8 by , 5 years ago
The first "...was not found in the endpoint!" is strange, but the "Length invalid" error seems more relevant, I think. I need to investigate more.
by , 5 years ago
by , 5 years ago
| Attachment: | listusb_USB2.0.txt added |
|---|
by , 5 years ago
| Attachment: | listusb_USB3.0.txt added |
|---|
comment:12 by , 5 years ago
| Cc: | added |
|---|---|
| Component: | Drivers/USB/XHCI → Drivers/USB |
USB2:
04a9:172f /dev/bus/usb/1/0/5 "Canon, Inc." "PIXMA MP620" ver. 0109
USB3:
04a9:172f /dev/bus/usb/0/2 "Canon, Inc." "PIXMA MP620" ver. 0109
As far as I can tell, the only differences are that in the USB2 case, it is attached to a hub; whereas in the USB3 case, it's directly attached to the root hub. Perhaps there is some problem with the way libusb or Sanity enumerate devices here? It's hard to say; but I doubt at this point that it is really an XHCI issue.
CC'ing PulkoMandy; perhaps he has some ideas of what might be tried to further diagnose the problem.
comment:13 by , 5 years ago
Here's a listusb with everything connected to USB3.0 ports; nothing on USB2.0 ports.
by , 5 years ago
| Attachment: | listusb_allUSB3.0.txt added |
|---|
by , 5 years ago
| Attachment: | listusb-v_USB2.txt added |
|---|
by , 5 years ago
| Attachment: | listusb-v_USB3.txt added |
|---|
comment:14 by , 5 years ago
The endpoints are indeed the same.
Vidrep reports on IRC:
5:37 PM <Vidrep_64> when attached to a USB 3 port, and running Sanity, it doesn't detect the scanner, and Sanity keeps running in deskbar. Only way to kill it is reboot.
That sounds like a usb_raw driver issue.
comment:15 by , 5 years ago
It's probably the same bug I have with my Saleae Logic Analyzer clone and a few other devices. A syscall that never returns. You can confirm this by attaching Debugger to the frozen app, and saving a debug report from there.
There is this change for EHCI but I have no idea if it's the right thing to do: https://review.haiku-os.org/c/haiku/+/1424
Since here the problem is in XHCI, I doubt it is all there is to this.
comment:16 by , 5 years ago
Uh, that change is in usb_raw, so all bus drivers are affected. The question is if it works or not, and given no devices are removed, it seems this case is indeed different. It's strange there's no errors and there's still a hang in this ticket.
comment:17 by , 3 years ago
I tried again using hrev55399 x86_64 The device is detected on the USB 3.0 port, but crashes as soon as you try to scan. I've attached a debug report, just in case it may be of use in diagnosing the issue.
by , 3 years ago
| Attachment: | Sanity-7522-debug-08-09-2021-19-06-52.report added |
|---|
comment:18 by , 3 years ago
Tested today with hrev55443 x86_64 Now it crashes on both USB 2.0 port as welll as USB 3.0 port as soon as a preview or scan is initialized. Debug report for both crashes is the same as attached in comment:17
comment:19 by , 3 years ago
This looks like a bug in libusb's Haiku support code, at this point. PulkoMandy, any ideas here?
comment:20 by , 3 years ago
What usually happens with libusb is someone updates it from upstream without checking anything.
Usually, upstream will have added new OS specific callbacks that we don't implement and filled this table: https://github.com/libusb/libusb/blob/master/libusb/os/haiku_usb_raw.cpp#L182 with NULL pointers. When the transfer worker is asked to call these functions, it crashes.
We need to identify which of these callbacks is needed, and implement it. There are a lot of NULL in the table but these sometimes are optional or have fallback cross-platform implementations. You can find this by:
- Implementing callbacks until it starts working
- Adding traces to the SANE and/or libusb code to see which one it is trying to do when it crashes
- Deduce which one it is from the assembler instructions in the debug report, which probably uses some kind of offset into this table
It's very strange that there's no other errors before the missing TRBs come up...