Canon scanner does not function on USB 3.0 ports

[vidrep]

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.

[waddlesplash]

It's very strange that there's no other errors before the missing TRBs come up...

[waddlesplash]

Does this still happen?

[vidrep]

Tested with hrev53678. No change. Device is not detected on USB3 ports.

[waddlesplash]

Please retest after hrev53851.

[vidrep]

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.

[waddlesplash]

Please post a new syslog.

[vidrep]

New syslog attached

[waddlesplash]

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.

[vidrep]

Tried with hrev53888:

KERN: usb hub 2: port 3: new device connected

KERN: usb_disk: device reports a lun count of 1

KERN: usb_disk: vendor_identification "Canon "

KERN: usb_disk: product_identification "MP620 series "

KERN: usb_disk: product_revision_level "0109"

KERN: usb_disk: got device name "Canon MP620 series 0109": No error

KERN: usb error xhci 0: TRB 0x196a8600 was not found in the endpoint!

KERN: slab memory manager: created area 0xffffffffc4001000 (12026)

[waddlesplash]

Please post the output of listusb both ways.

[vidrep]

Attached USB2.0 and USB3.0 listusb

[waddlesplash]

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.

[vidrep]

Here's a listusb with everything connected to USB3.0 ports; nothing on USB2.0 ports.

[waddlesplash]

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.

[pulkomandy]

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.

[waddlesplash]

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.

[vidrep]

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.

[vidrep]

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

[waddlesplash]

This looks like a bug in libusb's Haiku support code, at this point. PulkoMandy, any ideas here?

[pulkomandy]

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