Canon multifunction printer - Scan freezes

[vidrep]

hrev51328 x86_64

Canon MP620 Series Multifunction printer

Scanning a page with Sanity front end freezes at about 90% and stays in a loop

Attached screenshot1.png

Attached syslog

Attached listusb

[vidrep]

Below is typical output running sane_backend from the CLI:

Welcome to the Haiku shell.

~> scanimage --list-devices device `pixma:04A9172F_164654' is a CANON Canon PIXMA MP620 multi-function peripheral

~> scanimage --format=tiff --verbose --progress > test.tiff

scanimage: scanning image of size 638x877 pixels at 24 bits/pixel

scanimage: acquiring RGB frame

Progress: 93.4%

[diver]

This is probably a bug in libusb?

[pulkomandy]

libusb does not do much but forward things to Haiku's USB driver. So it's quite possibly on our side as well.

[vidrep]

I was able to attach the debugger to Sanity and debug all but one thread. I have attached the report.

[vidrep]

Tested hrev52212 x86_64 using usb_raw driver built from source patchset on Gerrit ​https://review.haiku-os.org/#/c/haiku/+/453/ and running Sanity from terminal.

With usb_raw driver blacklisted, and custom driver loaded per syslog: KERN: loaded driver /boot/system/non-packaged/add-ons/kernel/drivers/dev/bus/usb_raw

Canon multifunction detects scanner, and now produces a full scan of the document. It no longer sticks at 93.4% complete. However, after completing the scan, it gets stuck in a loop, and the "save as" button is never activated. The scanned document CAN be saved from the File->Save as... drop down menu. The printer LCD readout indicates "scanning..." in a perpetual loop. The saved document appears to be complete.

This is a positive step forward, but not a complete fix of the issue.

Sanity_terminal.txt attached

[vidrep]

Running scanimage from terminal results in the same as before, so maybe not better...

Welcome to the Haiku shell.

~> scanimage --list-devices device `pixma:04A9172F_164654' is a CANON Canon PIXMA MP620 multi-function peripheral ~> scanimage --format=tiff --verbose --progress > test.tiff scanimage: scanning image of size 638x877 pixels at 24 bits/pixel scanimage: acquiring RGB frame Progress: 93.4%

[pulkomandy]

Now I'm confused. The driver changes are only a first step. The new ioctl is not used by anything, so at this point is is just dead code and shouldn't change anything to the result. Only when this get merged, and then I update libusb to use it, we will have visible results from this change.

As I mentionned on IRC, running LIBUSB_DEBUG=9 someCommand will get us libusb debug logs in the terminal. This may provide some hints as to what goes wrong.

[vidrep]

The confusion was mine...

[vidrep]

I've attached a pair of logs using libusb built from latest souce in haikuports, and running the following commands:

LIBUSB_DEBUG=9 Sanity (selecting all of the visible output in the terminal and pasting to a text file)

LIBUSB_DEBUG=9 Sanity > libusb.txt 2>&1

libusb_terminal.txt for the first instance

libusb_debug.txt for the redirected instance

[vidrep]

In listusb_terminal.txt "Option 1 - Option 17 load very quickly, then the process stalls for a while before Option 18 - Option 25 complete loading. Only after that is it possible to start the scan, which then freezes at about 95% complete. At this point the only way to kill the process is to power off the printer.

[vidrep]

I believe this is a duplicate ticket of: https://dev.haiku-os.org/ticket/13495

[vidrep]

Tested with latest sane_backends 1.0.27-5 (currently a push request in HaikuPorts).

The Canon scanner only exhibits the described issues when connected over USB. Network scanning is working without issues. The revised sane_backends 1.0.27-5 now has PNG support compiled in. I was able to scan to all supported formats (PNG, TIFF, JPEG, PNM) without issue over a network connection.

[cocobean]

Submitted sane_backends-1.0.29 in Haikuports.

[cocobean]

@vidrep - Is this fixed now in current nightly (>=hrev55102)?

[vidrep]

Not fixed yet.

[vidrep]

Tested with hrev55399 x86_64 on both USB 2.0 and USB 3.0 ports. Device detection is very slow, and will crash when trying to scan. Debug report attached.