Discussion:
Scanner failure when connected via USB3
(too old to reply)
Mike Cloaked
2014-09-11 09:19:25 UTC
Permalink
For some time I have been having an issue with xsane hanging when
connecting to a Canoscan LIDE 210 flatbed scanner with a laptop that only
has USB3 ports, when the same scanner works flawlessly when connected to a
laptop which only has USB2 ports.

I have seen similar issues reported for other scanners in the Ubuntu
forums, though I am using arch linux.

I came across a posting very recently that suggested that when a scanner is
connected to a USB3 port that using the vuescan package the scanner works
without any problem.

So I decided to test this for a laptop running current up-to-date arch
linux that only has USB3 ports. With xsane running in KDE the scanner
hangs reliably every time. Restarting the system and scanning with the
vuescan package gives reliable flawless operation without any other change
to the system or connections.

This would seem to indicate that there is some kind of bug in the sane
packages. I have tried in the past to find out how to diagnose this issue
but I don't know where to begin to get logs that might help in finding
where the problem lies.

I will be happy to provide diagnostics but I will be tied up until 1st
October - but after that I can run tests and generate logs to upload if a
developer can suggest what I need to do to get the diagnostic information.

It would be very nice to get to a solution for this issue as there is
almost exclusively USB2 scanner hardware, and increasingly people will be
running machines that have USB3 capability with xhci rather than ehci
modules in the kernel.
--
mike c
Jorge Fábregas
2014-09-13 00:34:46 UTC
Permalink
Post by Mike Cloaked
This would seem to indicate that there is some kind of bug in the sane
packages. I have tried in the past to find out how to diagnose this issue
but I don't know where to begin to get logs that might help in finding
where the problem lies.
Hi Mike,

I have the same scanner & had exactly the same issue when I recently
replaced my desktop computer. I spent quite some time trying to figure
out what was the cause & indeed there are plenty of people with this
problem! The bug seems to be within the xhci_hcd kernel module.

The thing is that my computer has some USB 2 ports on the back and the
scanner still didn't work there. What surprised me was that dmesg still
showed "xhci_hcd" as being used by those USB 2 ports. So, it seems
that, on my computer, even though I'm connecting the scanner to a USB 2
port on the back, it is still been routed internally to the USB3 host
controller.

I then went to my BIOS and found an option , under the USB section,
called "USB Debug Support", that said:

"Select whether to enable or disable the USB port 6 debug capability.
Note: If the function is enabled, the port 6 will work as an USB 2.0 port".

I enabled it and placed my scanner on that particular port and bingo
(dmesg showed ehci-pci as being used) & the scanner worked perfectly
fine. Of course, this is a workaround (not a fix) but I'm happy to use
it in the meantime. This is a Lenovo workstation & I'm lucky to have
that option (to enable USB 2 for just one particular port without
affecting the rest of my USB 3 ports).

This thread pointed me to the right direction:

http://askubuntu.com/questions/457901/usb-2-0-device-scanner-does-not-work-with-xhci-hcd-on-usb-3-0-system

Try to see if there's such an option on your BIOS.

HTH,
Jorge

p.d. I'm using Fedora 20
m. allan noah
2014-09-22 20:57:25 UTC
Permalink
Mike- when you get back to the machine, maybe you could make some
logs. If we could see a usb log of what scanimage does and what
vuescan does, we might be able to find a difference. The problem will
be figuring out how to both reduce the volume of data the the bare
minimum which reproduces the problem, and also doing exactly the same
thing in both cases. I might be as simple as a 'scanimage --help'
multiple times in a row, and starting/stopping vuescan multiple times.
I'm not sure how to tell the kernel to enable usb logging, but I bet
google will tell you :)

allan
For some time I have been having an issue with xsane hanging when connecting
to a Canoscan LIDE 210 flatbed scanner with a laptop that only has USB3
ports, when the same scanner works flawlessly when connected to a laptop
which only has USB2 ports.
I have seen similar issues reported for other scanners in the Ubuntu forums,
though I am using arch linux.
I came across a posting very recently that suggested that when a scanner is
connected to a USB3 port that using the vuescan package the scanner works
without any problem.
So I decided to test this for a laptop running current up-to-date arch linux
that only has USB3 ports. With xsane running in KDE the scanner hangs
reliably every time. Restarting the system and scanning with the vuescan
package gives reliable flawless operation without any other change to the
system or connections.
This would seem to indicate that there is some kind of bug in the sane
packages. I have tried in the past to find out how to diagnose this issue
but I don't know where to begin to get logs that might help in finding where
the problem lies.
I will be happy to provide diagnostics but I will be tied up until 1st
October - but after that I can run tests and generate logs to upload if a
developer can suggest what I need to do to get the diagnostic information.
It would be very nice to get to a solution for this issue as there is almost
exclusively USB2 scanner hardware, and increasingly people will be running
machines that have USB3 capability with xhci rather than ehci modules in the
kernel.
--
mike c
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
Olaf Meeuwissen
2014-09-23 22:57:47 UTC
Permalink
Post by m. allan noah
Mike- when you get back to the machine, maybe you could make some
logs. If we could see a usb log of what scanimage does and what
vuescan does, we might be able to find a difference. The problem will
be figuring out how to both reduce the volume of data the the bare
minimum which reproduces the problem, and also doing exactly the same
thing in both cases. I might be as simple as a 'scanimage --help'
multiple times in a row, and starting/stopping vuescan multiple times.
I'm not sure how to tell the kernel to enable usb logging, but I bet
google will tell you :)
$ sudo modprobe usbmon
$ sudo wireshark

and selecting the right USB bus to capture traffic on. The `usbmon#`
numbers match the bus numbers that `lsusb` outputs.

Hope that helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
Mike Cloaked
2014-10-26 16:28:21 UTC
Permalink
Post by Olaf Meeuwissen
Post by m. allan noah
Mike- when you get back to the machine, maybe you could make some
logs. If we could see a usb log of what scanimage does and what
vuescan does, we might be able to find a difference. The problem will
be figuring out how to both reduce the volume of data the the bare
minimum which reproduces the problem, and also doing exactly the same
thing in both cases. I might be as simple as a 'scanimage --help'
multiple times in a row, and starting/stopping vuescan multiple times.
I'm not sure how to tell the kernel to enable usb logging, but I bet
google will tell you :)
$ sudo modprobe usbmon
$ sudo wireshark
and selecting the right USB bus to capture traffic on. The `usbmon#`
numbers match the bus numbers that `lsusb` outputs.
Hope that helps,
Sorry about the delay - things got a bit hectic this month - the coming
week looks a little easier so I will set up to test the scanner for usb
logs during the coming week, and once I have captured some logging
information I will post back.
--
mike c
Mike Cloaked
2014-10-27 11:00:59 UTC
Permalink
On Tue, Sep 23, 2014 at 11:57 PM, Olaf Meeuwissen <
Post by Olaf Meeuwissen
Post by m. allan noah
Mike- when you get back to the machine, maybe you could make some
logs. If we could see a usb log of what scanimage does and what
vuescan does, we might be able to find a difference. The problem will
be figuring out how to both reduce the volume of data the the bare
minimum which reproduces the problem, and also doing exactly the same
thing in both cases. I might be as simple as a 'scanimage --help'
multiple times in a row, and starting/stopping vuescan multiple times.
I'm not sure how to tell the kernel to enable usb logging, but I bet
google will tell you :)
$ sudo modprobe usbmon
$ sudo wireshark
and selecting the right USB bus to capture traffic on. The `usbmon#`
numbers match the bus numbers that `lsusb` outputs.
Hope that helps,
Sorry about the delay - things got a bit hectic this month - the coming
week looks a little easier so I will set up to test the scanner for usb
logs during the coming week, and once I have captured some logging
information I will post back.
--
mike c
I had a little time this morning available to test the scanner. I am
testing on a Lenovo Y510p laptop with usb3 ports. The laptop is running
arch linux fully up to date with kernel 3.17.1-1-ARCH.
local/kdegraphics-ksaneplugin 4.14.2-1
A scan plugin that implements the scanning
local/libksane 4.14.2-1
An image scanning library
local/perl-common-sense 3.73-1
Implements some sane defaults for Perl programs
local/sane 1.0.24-3
Scanner Access Now Easy
local/sane-frontends 1.0.14-7
A set of frontends for SANE.
local/xsane 0.999-1
A GTK-based X11 frontend for SANE and plugin for Gimp.
local/xsane-gimp 0.999-1
XSane Gimp plugin
I was following the guide at
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
# ls /sys/kernel/debug/usb/usbmon/
0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
Checking which bus was used when the scanner was plugged in was bus 1 from
the lsusb command.
The after pulling the usb cable out I did
# cat /sys/kernel/debug/usb/usbmon/1u >
/home/mike/Documents/debugging/scanner/vuescan.mon.out
and then re-inserted the scanner usb cable into the usb3 port, and started
up vuescan.
After doing a single scan I stopped the log and saved it.
Then I did the same but using xsane from the GIMP - and it reliably
crashed xsane, but it also zeroed out the usb monitor log file! Eventually
I was able to stop the monitor stream and save the file before xsane
finished crashing, and whilst the scanner was still producing a continuous
screaming noise, I safeguarded the file as xsane1.mon.out.
Both these files are attached. I have not tried to get wireshark to
analyse the data as I am not sure how to do it.
Are these two log files a help in getting some diagnostics?
Thanks
Mike
--
mike c
I am re-sending this without the logfile attachments as they were too big
to be accepted on the list and the original is held for moderation. I could
post the logs to a cloud temporary file?

By the way with xsane when I first plug in the scanner and start xsane via
the GIMP it does begin to work and indeed completes a pre-scan. However if
I select 300dpi resolution and ask it to to a full scan then that is when
it reliably crashes and the scanner screams for some time but eventually
stops. If I restart xsane it sometimes crashes almost straight away but
sometimes looks as though it has started again but crashes almost as soon
as I try to do anything with it.
--
mike c
m. allan noah
2014-10-27 11:20:23 UTC
Permalink
try compressing your attachments.

allan
On Tue, Sep 23, 2014 at 11:57 PM, Olaf Meeuwissen
Post by Olaf Meeuwissen
Post by m. allan noah
Mike- when you get back to the machine, maybe you could make some
logs. If we could see a usb log of what scanimage does and what
vuescan does, we might be able to find a difference. The problem will
be figuring out how to both reduce the volume of data the the bare
minimum which reproduces the problem, and also doing exactly the same
thing in both cases. I might be as simple as a 'scanimage --help'
multiple times in a row, and starting/stopping vuescan multiple times.
I'm not sure how to tell the kernel to enable usb logging, but I bet
google will tell you :)
$ sudo modprobe usbmon
$ sudo wireshark
and selecting the right USB bus to capture traffic on. The `usbmon#`
numbers match the bus numbers that `lsusb` outputs.
Hope that helps,
Sorry about the delay - things got a bit hectic this month - the coming
week looks a little easier so I will set up to test the scanner for usb logs
during the coming week, and once I have captured some logging information I
will post back.
--
mike c
I had a little time this morning available to test the scanner. I am
testing on a Lenovo Y510p laptop with usb3 ports. The laptop is running arch
linux fully up to date with kernel 3.17.1-1-ARCH.
local/kdegraphics-ksaneplugin 4.14.2-1
A scan plugin that implements the scanning
local/libksane 4.14.2-1
An image scanning library
local/perl-common-sense 3.73-1
Implements some sane defaults for Perl programs
local/sane 1.0.24-3
Scanner Access Now Easy
local/sane-frontends 1.0.14-7
A set of frontends for SANE.
local/xsane 0.999-1
A GTK-based X11 frontend for SANE and plugin for Gimp.
local/xsane-gimp 0.999-1
XSane Gimp plugin
I was following the guide at
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
# ls /sys/kernel/debug/usb/usbmon/
0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
Checking which bus was used when the scanner was plugged in was bus 1 from
the lsusb command.
The after pulling the usb cable out I did
# cat /sys/kernel/debug/usb/usbmon/1u >
/home/mike/Documents/debugging/scanner/vuescan.mon.out
and then re-inserted the scanner usb cable into the usb3 port, and started
up vuescan.
After doing a single scan I stopped the log and saved it.
Then I did the same but using xsane from the GIMP - and it reliably
crashed xsane, but it also zeroed out the usb monitor log file! Eventually
I was able to stop the monitor stream and save the file before xsane
finished crashing, and whilst the scanner was still producing a continuous
screaming noise, I safeguarded the file as xsane1.mon.out.
Both these files are attached. I have not tried to get wireshark to
analyse the data as I am not sure how to do it.
Are these two log files a help in getting some diagnostics?
Thanks
Mike
--
mike c
I am re-sending this without the logfile attachments as they were too big to
be accepted on the list and the original is held for moderation. I could
post the logs to a cloud temporary file?
By the way with xsane when I first plug in the scanner and start xsane via
the GIMP it does begin to work and indeed completes a pre-scan. However if
I select 300dpi resolution and ask it to to a full scan then that is when it
reliably crashes and the scanner screams for some time but eventually stops.
If I restart xsane it sometimes crashes almost straight away but sometimes
looks as though it has started again but crashes almost as soon as I try to
do anything with it.
--
mike c
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-10-27 15:45:05 UTC
Permalink
Post by m. allan noah
try compressing your attachments.
allan
Here are the two attachments gzipped. Hopefully this will be within the
file size limits.
Mike
Looks like they are still too large at around 400kB in total. I'll try to
find a cloud pastebin or similar.
--
mike c
Mike Cloaked
2014-10-27 15:57:29 UTC
Permalink
Post by Mike Cloaked
Post by m. allan noah
try compressing your attachments.
allan
Here are the two attachments gzipped. Hopefully this will be within the
file size limits.
Mike
Looks like they are still too large at around 400kB in total. I'll try to
find a cloud pastebin or similar.
--
mike c
OK you should be able to access the two log files at
http://www.4shared.com/folder/ikzwN7aI/_online.html
--
mike c
m. allan noah
2014-11-04 01:52:00 UTC
Permalink
I've tried to make sense of these logs, but they seem to contain data
from multiple devices, and none of it looks like commands for a
fujitsu scanner. Can you try again to capture something from the
scanner specifically, instead of the entire bus?

allan
Post by m. allan noah
try compressing your attachments.
allan
Here are the two attachments gzipped. Hopefully this will be within the file
size limits.
Mike
--
mike c
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-11-04 07:55:53 UTC
Permalink
Post by m. allan noah
I've tried to make sense of these logs, but they seem to contain data
from multiple devices, and none of it looks like commands for a
fujitsu scanner. Can you try again to capture something from the
scanner specifically, instead of the entire bus?
allan
The scanner is a Canoscan LIDE 210 not Fujitsu - I will try to do a
capture from the scanner part of the bus alone, but it will probably be the
weekend before I can do it as I am full tied up this week. At the time I
did the previous captures the only usb device that was attached to the
machine was the scanner. There was not even a mouse attached.

I'll post back when I get a chance to run the new capture.
--
mike c
m. allan noah
2014-11-04 11:58:36 UTC
Permalink
Oh, my bad- I got confused about which scanner was being used. No
wonder the packets looked strange :)

allan
Post by m. allan noah
I've tried to make sense of these logs, but they seem to contain data
from multiple devices, and none of it looks like commands for a
fujitsu scanner. Can you try again to capture something from the
scanner specifically, instead of the entire bus?
allan
The scanner is a Canoscan LIDE 210 not Fujitsu - I will try to do a capture
from the scanner part of the bus alone, but it will probably be the weekend
before I can do it as I am full tied up this week. At the time I did the
previous captures the only usb device that was attached to the machine was
the scanner. There was not even a mouse attached.
I'll post back when I get a chance to run the new capture.
--
mike c
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2015-02-04 20:16:52 UTC
Permalink
It looks like there is long standing related work still continuing to make
progress on a possible fix in the xhci usb kernel code for usb2 scanners
being problematic when plugged into usb3 ports - see the thread at:

http://www.spinics.net/lists/linux-usb/msg120507.html

Maybe at some point there will be fixed xhci code in the kernel that will
allow usb2 scanners to work with usb3 ports on computers!
--
mike c
m. allan noah
2015-02-04 20:42:29 UTC
Permalink
I recently put in a patch to sane-backends usb support to work around
this issue. You might try upgrading to development version.

allan
Post by Mike Cloaked
It looks like there is long standing related work still continuing to make
progress on a possible fix in the xhci usb kernel code for usb2 scanners
http://www.spinics.net/lists/linux-usb/msg120507.html
Maybe at some point there will be fixed xhci code in the kernel that will
allow usb2 scanners to work with usb3 ports on computers!
--
mike c
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
m. allan noah
2015-02-04 21:00:02 UTC
Permalink
I hit send before I finished writing: I also am hopeful that we can
fix this issue for real in the kernel- the patch discussed in that
thread seems to perform the same action as my workaround. An in-kernel
fix will correct this for many devices, not just scanners.

allan
Post by m. allan noah
I recently put in a patch to sane-backends usb support to work around
this issue. You might try upgrading to development version.
allan
Post by Mike Cloaked
It looks like there is long standing related work still continuing to make
progress on a possible fix in the xhci usb kernel code for usb2 scanners
http://www.spinics.net/lists/linux-usb/msg120507.html
Maybe at some point there will be fixed xhci code in the kernel that will
allow usb2 scanners to work with usb3 ports on computers!
--
mike c
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2015-02-04 21:50:00 UTC
Permalink
Post by m. allan noah
I hit send before I finished writing: I also am hopeful that we can
fix this issue for real in the kernel- the patch discussed in that
thread seems to perform the same action as my workaround. An in-kernel
fix will correct this for many devices, not just scanners.
allan
Post by m. allan noah
I recently put in a patch to sane-backends usb support to work around
this issue. You might try upgrading to development version.
allan
This sounds very positive and hopefully will make a difference to a lot of
people when it gets into the released kernel. I will be keeping an eye out
for these patches in the test kernels and will try to test before release
likely via the [testing] arch repo if I can find time to do it. I have not
built kernels in a while but if I have time I may build a test kernel
before a kernel with the patches reaches arch linux [testing]. I will look
forward to seeing this come to fruition.
--
mike c
Olaf Meeuwissen
2014-10-28 00:02:19 UTC
Permalink
On Tue, Sep 23, 2014 at 11:57 PM, Olaf Meeuwissen <
Post by Olaf Meeuwissen
$ sudo modprobe usbmon
$ sudo wireshark
and selecting the right USB bus to capture traffic on. The `usbmon#`
numbers match the bus numbers that `lsusb` outputs.
I had a little time this morning available to test the scanner. I am
testing on a Lenovo Y510p laptop with usb3 ports. The laptop is running
arch linux fully up to date with kernel 3.17.1-1-ARCH.
[snip]
I was following the guide at
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
# ls /sys/kernel/debug/usb/usbmon/
0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
Checking which bus was used when the scanner was plugged in was bus 1 from
the lsusb command.
The after pulling the usb cable out I did
# cat /sys/kernel/debug/usb/usbmon/1u >
/home/mike/Documents/debugging/scanner/vuescan.mon.out
and then re-inserted the scanner usb cable into the usb3 port, and started
up vuescan.
After doing a single scan I stopped the log and saved it.
Then I did the same but using xsane from the GIMP - and it reliably crashed
xsane, but it also zeroed out the usb monitor log file! Eventually I was
able to stop the monitor stream and save the file before xsane finished
crashing, and whilst the scanner was still producing a continuous screaming
noise, I safeguarded the file as xsane1.mon.out.
Both these files are attached. I have not tried to get wireshark to
analyse the data as I am not sure how to do it.
The idea is that you start/stop capturing USB traffic with wireshark
rather than cat whatever is left in the /sys/kernel/debug/usb/usbmon/
files. Wireshark will read off that and presents you with an easier to
digest view of what went on.

If you don't have a GUI on the machine with the scanner, you can use
tshark instead to save to file and view it elsewhere. Read the manual
page for instructions.
Are these two log files a help in getting some diagnostics?
Not unless you're a USB kernel buff, which I'm not ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-10-28 09:04:37 UTC
Permalink
Post by Olaf Meeuwissen
The idea is that you start/stop capturing USB traffic with wireshark
rather than cat whatever is left in the /sys/kernel/debug/usb/usbmon/
files. Wireshark will read off that and presents you with an easier to
digest view of what went on.
If you don't have a GUI on the machine with the scanner, you can use
tshark instead to save to file and view it elsewhere. Read the manual
page for instructions.
Are these two log files a help in getting some diagnostics?
Not unless you're a USB kernel buff, which I'm not ;-)
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
OK I will have a look at using wireshark to try to capture something more
compact and more useful. Probably be a couple of days before I get a block
of time to do it, and then I'll post back.
--
mike c
m. allan noah
2014-10-28 13:21:36 UTC
Permalink
I was able to somewhat parse the logs using a bit of perl. I am
suprised about the difference in file size. Where you making the scans
with the same parameters in both cases?

allan
On Tue, Oct 28, 2014 at 12:02 AM, Olaf Meeuwissen
Post by Olaf Meeuwissen
The idea is that you start/stop capturing USB traffic with wireshark
rather than cat whatever is left in the /sys/kernel/debug/usb/usbmon/
files. Wireshark will read off that and presents you with an easier to
digest view of what went on.
If you don't have a GUI on the machine with the scanner, you can use
tshark instead to save to file and view it elsewhere. Read the manual
page for instructions.
Are these two log files a help in getting some diagnostics?
Not unless you're a USB kernel buff, which I'm not ;-)
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
OK I will have a look at using wireshark to try to capture something more
compact and more useful. Probably be a couple of days before I get a block
of time to do it, and then I'll post back.
--
mike c
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-10-28 16:00:27 UTC
Permalink
Post by m. allan noah
I was able to somewhat parse the logs using a bit of perl. I am
suprised about the difference in file size. Where you making the scans
with the same parameters in both cases?
allan
OK - I have been working on this with a bit of free time today. First to
answer your question the vuescan scan of the sample document completed
without error whereas the scan with xsane failed to complete and hung
before it did very much which may explain the difference in the file sizes.

Secondly i set up wireshark this afternoon, and got it all running to
capture usb data on the bus that the scanner is connected to. Having
completed a capture for a vuescan run scanning the same docuument as
previously. I then reset the scanner, and wireshark, and ran a scan in
xsane - but instead of hanging it worked! The only change since the
previous time I booted the same laptop is that I ran a system update - but
there was no obvious package that was updated that would have contributed
to the changed behaviour!

So I have the usb packet capture files for vuescan doing a single complete
scan, a 2nd capture for xsane doing a pre-scan, and two runs where a full
scan of the document at 300 dpi was made successfully with xsane with the
scan window left untouched from the pre-scan, as well as one with the scan
window set to the reduced image for the small document on the platten.

However this is the first time that the scanner has ever worked to complete
a scan with xsane. I have looked through the package dependency tree to
see which package may be a dependent one for xsane that was updated after
booting the machine today. The only one was mesa and maybe mesa-dri but I
would have been surprised if that update affected the scanner operation
from within arch linux. I was also beginning to suspect the libusb package
until today but that was not one of the packages that was updated.

So right now I am perplexed, but I will boot the machine again in the next
day or so, and run exactly the same test to see if it still works as it did
today, and will report back on the outcome. It would be nice to know if
indeed one the the package updates did result in the change or if this it
is that the scanner will most of the time still fail to work.

I have the packet capture files as well as the packet-dissection text as a
set of files, and after setting up the test again next time if the scan
fails as usual I will capture the data for that as well.

Mike
--
mike c
Mike Cloaked
2014-10-28 16:23:10 UTC
Permalink
Post by Mike Cloaked
OK - I have been working on this with a bit of free time today. First to
answer your question the vuescan scan of the sample document completed
without error whereas the scan with xsane failed to complete and hung
before it did very much which may explain the difference in the file sizes.
Secondly i set up wireshark this afternoon, and got it all running to
capture usb data on the bus that the scanner is connected to. Having
completed a capture for a vuescan run scanning the same docuument as
previously. I then reset the scanner, and wireshark, and ran a scan in
xsane - but instead of hanging it worked! The only change since the
previous time I booted the same laptop is that I ran a system update - but
there was no obvious package that was updated that would have contributed
to the changed behaviour!
So I have the usb packet capture files for vuescan doing a single complete
scan, a 2nd capture for xsane doing a pre-scan, and two runs where a full
scan of the document at 300 dpi was made successfully with xsane with the
scan window left untouched from the pre-scan, as well as one with the scan
window set to the reduced image for the small document on the platten.
However this is the first time that the scanner has ever worked to
complete a scan with xsane. I have looked through the package dependency
tree to see which package may be a dependent one for xsane that was updated
after booting the machine today. The only one was mesa and maybe mesa-dri
but I would have been surprised if that update affected the scanner
operation from within arch linux. I was also beginning to suspect the
libusb package until today but that was not one of the packages that was
updated.
So right now I am perplexed, but I will boot the machine again in the next
day or so, and run exactly the same test to see if it still works as it did
today, and will report back on the outcome. It would be nice to know if
indeed one the the package updates did result in the change or if this it
is that the scanner will most of the time still fail to work.
I have the packet capture files as well as the packet-dissection text as a
set of files, and after setting up the test again next time if the scan
fails as usual I will capture the data for that as well.
I ran one final test before closing the machine down this evening. The
scanner failed and hung when trying to trying to scan for devices. At this
point I stopped wireshark and saved the files since the output was very
small.

The analysis showed malformed packets. See attached files - which are
small enough to be accepted in this list as attachments. The .pcapng file
can be replayed in wireshark.

I unplugged and re-plugged the scanner - and it was detected normally
showing normal systemd journal logging. Xsane connected to it and it
completed a full scan without error. So it would seem that whether or not
the scanner works when connected to usb3 is intermittent. Sometimes it
initialises correctly and sometimes it does not.

I will run more tests and report when I can.

Mike
--
mike c
Olaf Meeuwissen
2014-10-28 23:28:36 UTC
Permalink
Post by Mike Cloaked
Secondly i set up wireshark this afternoon, and got it all running to
capture usb data on the bus that the scanner is connected to. Having
completed a capture for a vuescan run scanning the same docuument as
previously. I then reset the scanner, and wireshark, and ran a scan in
xsane - but instead of hanging it worked! The only change since the
previous time I booted the same laptop is that I ran a system update - but
there was no obvious package that was updated that would have contributed
to the changed behaviour!
Not obvious to you perhaps but maybe someone else? Would you happen to
have the full list of packages (as well as their old and new versions)?
Maybe someone will spot something.

BTW, did you boot with the same kernel?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-10-29 09:48:29 UTC
Permalink
Post by Olaf Meeuwissen
Post by Mike Cloaked
Secondly i set up wireshark this afternoon, and got it all running to
capture usb data on the bus that the scanner is connected to. Having
completed a capture for a vuescan run scanning the same docuument as
previously. I then reset the scanner, and wireshark, and ran a scan in
xsane - but instead of hanging it worked! The only change since the
previous time I booted the same laptop is that I ran a system update -
but
Post by Mike Cloaked
there was no obvious package that was updated that would have contributed
to the changed behaviour!
Not obvious to you perhaps but maybe someone else? Would you happen to
have the full list of packages (as well as their old and new versions)?
Maybe someone will spot something.
BTW, did you boot with the same kernel?
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
Yes I do have the full list of packages that were updated in the pacman log
- I am away from that laptop at the moment, but later today I will post the
full list of updated packages from the pacman log. Yes it was booted with
the same kernel though the kernel was updated from 3.16 to 3.17 only a few
days ago and is now running with the new kernel.

The other thing I had wondered/thought about was that it might be a partial
hardware failure. However the same usb3 port on the laptop where the
scanner was plugged in was used to plug in an external usb hard drive and
that works without any problems. Also the scanner was plugged in to a
different laptop with only usb2 ports and it was fine with xsane on that
laptop. So that suggests that the hardware is not the problem either at the
laptop port or for the scanner.

I also separately have a multifunction printer/scanner (Samsung SCX4500W)
that was working fine as both printer and scanner when connected via usb2
to a previous desktop that only had usb2 ports, but that machine is now
replaced with a new desktop that only has usb3 ports - the MFP works
without any error connected to a usb3 port for the printer functions but
the scanner hangs xsane whilst connected to the same physical port.
However the scanner when connected via its ethernet wired network
connection works fine from xsane using tcp. So the scanner function seems
to work provided it is not connected to a usb3 port. That desktop also runs
arch linux. A few months ago I tested this MFP plugging into the laptop
with usb3 ports and xsane hung when scanning was attempted on the laptop
via usb3 as well.

The combined set of information from these tests seems to indicate that
there is an issue with usb2 printers connected to a machine via usb3 when
using sane, though of course I only have archlinux so I don't know if the
same scanners would work properly when connected via usb3 to a machine
running a different version of linux where the package sets are versioned
differently? If anyone has either of the two scanners that I have, and are
running Ubuntu, Fedora,Mint or another version of linux in a machine with
usb3 ports it would be a very useful comparison?

This evening I should have a bit more time to try the Canon LIDE 210 again
on the laptop that I have been having usb3 problems for scanning, and will
try to capture usb data for a partial scan and fail situation, and I will
post the package update list in the same post.
--
mike c
Mike Cloaked
2014-10-29 19:51:14 UTC
Permalink
Post by Mike Cloaked
Yes I do have the full list of packages that were updated in the pacman
log - I am away from that laptop at the moment, but later today I will post
the full list of updated packages from the pacman log. Yes it was booted
with the same kernel though the kernel was updated from 3.16 to 3.17 only a
few days ago and is now running with the new kernel.
The other thing I had wondered/thought about was that it might be a
partial hardware failure. However the same usb3 port on the laptop where
the scanner was plugged in was used to plug in an external usb hard drive
and that works without any problems. Also the scanner was plugged in to a
different laptop with only usb2 ports and it was fine with xsane on that
laptop. So that suggests that the hardware is not the problem either at the
laptop port or for the scanner.
I also separately have a multifunction printer/scanner (Samsung SCX4500W)
that was working fine as both printer and scanner when connected via usb2
to a previous desktop that only had usb2 ports, but that machine is now
replaced with a new desktop that only has usb3 ports - the MFP works
without any error connected to a usb3 port for the printer functions but
the scanner hangs xsane whilst connected to the same physical port.
However the scanner when connected via its ethernet wired network
connection works fine from xsane using tcp. So the scanner function seems
to work provided it is not connected to a usb3 port. That desktop also runs
arch linux. A few months ago I tested this MFP plugging into the laptop
with usb3 ports and xsane hung when scanning was attempted on the laptop
via usb3 as well.
The combined set of information from these tests seems to indicate that
there is an issue with usb2 printers connected to a machine via usb3 when
using sane, though of course I only have archlinux so I don't know if the
same scanners would work properly when connected via usb3 to a machine
running a different version of linux where the package sets are versioned
differently? If anyone has either of the two scanners that I have, and are
running Ubuntu, Fedora,Mint or another version of linux in a machine with
usb3 ports it would be a very useful comparison?
This evening I should have a bit more time to try the Canon LIDE 210 again
on the laptop that I have been having usb3 problems for scanning, and will
try to capture usb data for a partial scan and fail situation, and I will
post the package update list in the same post.
Here is the list of packages updated in the past few days:

[2014-10-23 16:08] [PACMAN] upgraded linux (3.16.4-1 -> 3.17.1-1)
[2014-10-23 16:08] [PACMAN] upgraded linux-headers (3.16.4-1 -> 3.17.1-1)
[2014-10-23 16:08] [PACMAN] upgraded lirc-utils (1:0.9.1.a-5 -> 1:0.9.1.a-7)
[2014-10-23 16:08] [PACMAN] upgraded oxygen-gtk2 (1.4.5-1 -> 1.4.6-1)
[2014-10-23 16:08] [PACMAN] upgraded oxygen-gtk3 (1.4.0-2 -> 1.4.1-1)
[2014-10-23 16:08] [PACMAN] upgraded perl-net-ssleay (1.63-2 -> 1.66-1)
[2014-10-23 16:08] [PACMAN] upgraded python2-pillow (2.6.0-1 -> 2.6.1-1)
[2014-10-23 16:08] [PACMAN] upgraded unrar (1:5.1.7-1 -> 1:5.2.1-1)
[2014-10-27 09:41] [PACMAN] Running 'pacman -Syu'
[2014-10-27 09:41] [PACMAN] synchronizing package lists
[2014-10-27 09:41] [PACMAN] starting full system upgrade
[2014-10-27 09:41] [PACMAN] upgraded acpid (2.0.23-1 -> 2.0.23-2)
[2014-10-27 09:41] [PACMAN] upgraded ctags (5.8-4 -> 5.8-5)
[2014-10-27 09:41] [PACMAN] upgraded dkms (2.2.0.3-14 -> 2.2.0.3-15)
[2014-10-27 09:41] [PACMAN] upgraded dovecot (2.2.14-1 -> 2.2.15-1)
[2014-10-27 09:41] [PACMAN] upgraded firefox (33.0-2 -> 33.0.1-1)
[2014-10-27 09:41] [ALPM] warning: /etc/conf.d/fluidsynth installed as
/etc/conf.d/fluidsynth.pacnew
[2014-10-27 09:41] [PACMAN] upgraded fluidsynth (1.1.6-3 -> 1.1.6-4)
[2014-10-27 09:41] [PACMAN] upgraded geoclue2 (2.1.8-2 -> 2.1.10-1)
[2014-10-27 09:41] [PACMAN] upgraded gtk3 (3.14.3-2 -> 3.14.4-1)
[2014-10-27 09:41] [PACMAN] upgraded imagemagick (6.8.9.8-1 -> 6.8.9.9-1)
[2014-10-27 09:41] [PACMAN] upgraded iproute2 (3.15.0-1 -> 3.17.0-1)
[2014-10-27 09:41] [PACMAN] upgraded ktoblzcheck (1.43-2 -> 1.47-1)
[2014-10-27 09:41] [PACMAN] upgraded libqmi (1.10.2-1 -> 1.10.4-1)
[2014-10-27 09:41] [PACMAN] upgraded libraw (0.16.0-2 -> 0.16.0-3)
[2014-10-27 09:41] [PACMAN] upgraded mesa-dri (10.3.1-1 -> 10.3.2-1)
[2014-10-27 09:41] [PACMAN] upgraded mesa (10.3.1-1 -> 10.3.2-1)
[2014-10-27 09:41] [PACMAN] upgraded mesa-libgl (10.3.1-1 -> 10.3.2-1)
[2014-10-27 09:41] [PACMAN] upgraded libva (1.4.0-1 -> 1.4.1-1)
[2014-10-27 09:41] [PACMAN] upgraded libva-intel-driver (1.4.0-1 -> 1.4.1-1)
[2014-10-27 09:41] [PACMAN] upgraded libvncserver (0.9.9-3 -> 0.9.10-1)
[2014-10-27 09:41] [PACMAN] upgraded libxml2 (2.9.1-5 -> 2.9.2-1)
[2014-10-27 09:41] [PACMAN] upgraded mesa-vdpau (10.3.1-1 -> 10.3.2-1)
[2014-10-27 09:41] [PACMAN] upgraded neon (0.30.0-1 -> 0.30.1-1)
[2014-10-27 09:41] [PACMAN] upgraded perl-xml-sax-expat (0.51-2 -> 0.51-3)
[2014-10-27 09:41] [PACMAN] upgraded tzdata (2014h-1 -> 2014i-1)
[2014-10-27 09:41] [PACMAN] upgraded upower (0.99.0-3 -> 0.99.1-2)
[2014-10-27 09:41] [PACMAN] upgraded webkitgtk (2.4.6-3 -> 2.4.7-1)
[2014-10-27 09:41] [PACMAN] upgraded webkitgtk2 (2.4.6-3 -> 2.4.7-1)
[2014-10-27 09:41] [ALPM-SCRIPTLET] :: Xfce Power Manager no longer
provides a tray icon.
[2014-10-27 09:41] [ALPM-SCRIPTLET] Please add the new Power Manager
Plugin to your panel.
[2014-10-27 09:41] [PACMAN] upgraded xfce4-power-manager
(1.2.0.212.g75107db-1 -> 1.4.1-2)
[2014-10-27 09:42] [PACMAN] Running 'pacman -S libva-vdpau-driver'
[2014-10-27 09:42] [PACMAN] installed libva-vdpau-driver (0.7.4-2)
[2014-10-27 09:47] [PACMAN] Running 'pacman -U
/home/mike/Documents/install_stuff/aur/vuescan/vuescan-9.4-1-x86_64.pkg.tar.xz'
[2014-10-27 09:47] [PACMAN] installed vuescan (9.4-1)
[2014-10-27 10:44] [PACMAN] Running 'pacman -Syu'
[2014-10-27 10:44] [PACMAN] synchronizing package lists
[2014-10-27 10:44] [PACMAN] starting full system upgrade
[2014-10-28 14:25] [PACMAN] Running 'pacman -Syu'
[2014-10-28 14:25] [PACMAN] synchronizing package lists
[2014-10-28 14:25] [PACMAN] starting full system upgrade
[2014-10-28 14:25] [PACMAN] upgraded curl (7.38.0-2 -> 7.38.0-3)
[2014-10-28 14:25] [PACMAN] upgraded gramps (2:4.1.0-1 -> 2:4.1.1-1)
[2014-10-28 14:25] [PACMAN] upgraded ruby (2.1.3-2 -> 2.1.4-1)
[2014-10-28 14:27] [PACMAN] Running 'pacman -S wireshark-qt'
[2014-10-28 14:27] [ALPM-SCRIPTLET] NOTE: To run wireshark as normal user
you have to add yourself into wireshark group
[2014-10-28 14:27] [PACMAN] installed wireshark-cli (1.12.1-1)
[2014-10-28 14:27] [PACMAN] installed wireshark-qt (1.12.1-1)
[2014-10-29 19:34] [PACMAN] Running 'pacman -U
/home/mike/Documents/install_stuff/aur/google-chrome/google-chrome-38.0.2125.111-1-x86_64.pkg.tar.xz'
[2014-10-29 19:34] [ALPM-SCRIPTLET] ==> Updating desktop MIME database...
[2014-10-29 19:34] [ALPM-SCRIPTLET] ==> Updating icon cache..
[2014-10-29 19:34] [ALPM-SCRIPTLET] ==> NOTE: The binary is called:
'google-chrome-stable'
[2014-10-29 19:34] [PACMAN] upgraded google-chrome (38.0.2125.104-1 ->
38.0.2125.111-1)
[2014-10-29 19:35] [PACMAN] Running 'pacman -S ttf-liberation'
[2014-10-29 19:35] [ALPM-SCRIPTLET] Updating font cache... done.
[2014-10-29 19:35] [PACMAN] installed ttf-liberation (2.00.1-4)
[2014-10-29 19:35] [PACMAN] Running 'pacman -Syu'
[2014-10-29 19:35] [PACMAN] synchronizing package lists
[2014-10-29 19:35] [PACMAN] starting full system upgrade
[2014-10-29 19:35] [PACMAN] upgraded cairo (1.14.0-1 -> 1.14.0-2)
[2014-10-29 19:35] [PACMAN] upgraded cantata (1.4.2-1 -> 1.5.0-1)
[2014-10-29 19:35] [PACMAN] upgraded filesystem (2014.07-1 -> 2014.10-3)
[2014-10-29 19:35] [PACMAN] upgraded firefox (33.0.1-1 -> 33.0.2-1)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-libkdepim (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-akonadiconsole (4.14.2-1 ->
4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-akregator (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-blogilo (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-console (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kaddressbook (4.14.2-1 ->
4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kalarm (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kjots (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kleopatra (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kmail (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-knode (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-knotes (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kontact (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-korganizer (4.14.2-1 ->
4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-kresources (4.14.2-1 ->
4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-ktimetracker (4.14.2-1 ->
4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded kdepim-ktnef (4.14.2-1 -> 4.14.2-2)
[2014-10-29 19:35] [PACMAN] upgraded krb5 (1.12.2-1 -> 1.13-1)
[2014-10-29 19:35] [PACMAN] upgraded libgphoto2 (2.5.4-1 -> 2.5.5.1-1)
[2014-10-29 19:35] [PACMAN] upgraded libutil-linux (2.25.1-1 -> 2.25.2-1)
[2014-10-29 19:35] [ALPM] warning: /etc/pacman.d/mirrorlist installed as
/etc/pacman.d/mirrorlist.pacnew
[2014-10-29 19:35] [PACMAN] upgraded pacman-mirrorlist (20140901-1 ->
20141028-1)
[2014-10-29 19:35] [PACMAN] upgraded util-linux (2.25.1-1 -> 2.25.2-1)
[2014-10-29 19:35] [PACMAN] upgraded wget (1.15-1 -> 1.16-2)
--
mike c
Mike Cloaked
2014-10-29 20:01:38 UTC
Permalink
I have run some more tests this evening - after starting the wireshark
program, I set the systemd journal to log with -f to watch output, and
first simply plugged in the scanner.

Journal log gave:
ct 29 19:39:51 lenovo2 kernel: usb 3-4: new high-speed USB device number 4
using xhci_hcd
Oct 29 19:39:51 lenovo2 kernel: WARNING! power/level is deprecated; use
power/control instead

The wireshark usbmonitor file ( replayable as input to wireshark), and text
packet dissector files are attached.

At this stage xsane was not started, and only the hardware was plugged in.

I also note that the arch linux wiki on Sane mentions:
You may also get this error loged while attempting to scan:
kernel: usb 1-2: new high-speed USB device number 8 using xhci_hcd
kernel: WARNING! power/level is deprecated; use power/control instead
The fix is: In the UEFI/BIOS change the setting under USB configuration,
xhci pre-boot mode from enabled to disabled.

This implies that usb3 is problematic and switches off fast usb3 if xhci
pre-boot mode was disabled!

As soon as I started xsane, it appeared to start normally and presented the
gui to "Acquire Preview". As soon as I clicked to acquire preview the
scanner screamed and xsane hung. I will attach the logs fro wireshark for
this second stage in a separate email shortly. However I left the system
to itself and after some 10 seconds or so it stopped screaming and
presented a small popup dialogue box saying that the device was not found.

At that point I also noticed that the journal log showed:

Oct 29 19:41:22 lenovo2 kernel: mce: [Hardware Error]: Machine check events
logged

I'll now attach the wireshark logs as they should be small enough to be
accepted in this ML.
--
mike c
Mike Cloaked
2014-10-29 20:12:25 UTC
Permalink
Here is the text packet dissector file for when xsane was started and hung
at acquire preview. It is gzipped to stay within the size limit.

The packet stream file was too big even if gzipped but if needed I can put
it on a cloud file.
--
mike c
Mike Cloaked
2014-10-29 20:21:53 UTC
Permalink
Post by Mike Cloaked
I have run some more tests this evening - after starting the wireshark
program, I set the systemd journal to log with -f to watch output, and
first simply plugged in the scanner.
ct 29 19:39:51 lenovo2 kernel: usb 3-4: new high-speed USB device number 4
using xhci_hcd
Oct 29 19:39:51 lenovo2 kernel: WARNING! power/level is deprecated; use
power/control instead
The wireshark usbmonitor file ( replayable as input to wireshark), and
text packet dissector files are attached.
At this stage xsane was not started, and only the hardware was plugged in.
kernel: usb 1-2: new high-speed USB device number 8 using xhci_hcd
kernel: WARNING! power/level is deprecated; use power/control instead
The fix is: In the UEFI/BIOS change the setting under USB configuration,
xhci pre-boot mode from enabled to disabled.
This implies that usb3 is problematic and switches off fast usb3 if xhci
pre-boot mode was disabled!
As soon as I started xsane, it appeared to start normally and presented
the gui to "Acquire Preview". As soon as I clicked to acquire preview the
scanner screamed and xsane hung. I will attach the logs fro wireshark for
this second stage in a separate email shortly. However I left the system
to itself and after some 10 seconds or so it stopped screaming and
presented a small popup dialogue box saying that the device was not found.
Oct 29 19:41:22 lenovo2 kernel: mce: [Hardware Error]: Machine check
events logged
I'll now attach the wireshark logs as they should be small enough to be
accepted in this ML.
--
mike c
I looked back at the journal log for the previous tests I ran - in each
case the first time I plugged in the scanner it gave the power level
deprecation warning, but interestingly any subsequent unplugging and
replugging of the scanner before rebooting the machine did not give that
warning - only on the first plug in after boot. Also every time that xsane
hung there was an mce hardware error in the log.

Does this point to a problem with libusb since that involves xhci traffic
on the usb bus?
--
mike c
Mike Cloaked
2014-10-29 21:09:30 UTC
Permalink
I have also been googling for similar issues and there are a number of
similar bug reports in the mailing lists of various linux distributions
where people have found sb2 scanners failing to work when connected to usb3
ports in the past year. One such report is in the kernel bugzilla at
https://bugzilla.kernel.org/show_bug.cgi?id=47421 and the linked linux-usb
thread looks like it had some serious discussion but it did not look like
there was a resolution to the problem.

So this would seem to indicate that linux kernel support for usb3 remains
problematic and it may be that this is the underlying root cause of the
problems I have had?
--
mike c
Mike Cloaked
2014-10-29 21:30:03 UTC
Permalink
I have also been googling for similar issues and there are a number of
similar bug reports in the mailing lists of various linux distributions
where people have found sb2 scanners failing to work when connected to usb3
ports in the past year. One such report is in the kernel bugzilla at
https://bugzilla.kernel.org/show_bug.cgi?id=47421 and the linked
linux-usb thread looks like it had some serious discussion but it did not
look like there was a resolution to the problem.
So this would seem to indicate that linux kernel support for usb3 remains
problematic and it may be that this is the underlying root cause of the
problems I have had?
--
mike c
It looks like there are more recent threads on linux-usb also:
http://thread.gmane.org/gmane.linux.usb.general/110579
--
mike c
Olaf Meeuwissen
2014-10-31 08:58:31 UTC
Permalink
Hi Mike,

First of all, apologies for the somewhat belated reply. I will try to
piece all the bits from your flurry of mails that followed this one
together in this reply.
Post by Olaf Meeuwissen
[...] The only change since the previous time I booted the same
laptop is that I ran a system update - but there was no obvious
package that was updated that would have contributed to the changed
behaviour!
Not obvious to you perhaps but maybe someone else? Would you happen to
have the full list of packages (as well as their old and new versions)?
Maybe someone will spot something.
BTW, did you boot with the same kernel?
[...] I will post the full list of updated packages from the pacman
log. Yes it was booted with the same kernel though the kernel was
updated from 3.16 to 3.17 only a few days ago and is now running with
the new kernel.
If the kernel was updated, it is no longer the same kernel. Going
through the list of updated packages, the kernel update is the only one
that seems to have a possible impact on your issue.
The other thing I had wondered/thought about was that it might be a partial
hardware failure. However the same usb3 port on the laptop where the
scanner was plugged in was used to plug in an external usb hard drive and
that works without any problems. Also the scanner was plugged in to a
different laptop with only usb2 ports and it was fine with xsane on that
laptop. So that suggests that the hardware is not the problem either at the
laptop port or for the scanner.
I also separately have a multifunction printer/scanner (Samsung SCX4500W)
that was working fine as both printer and scanner when connected via usb2
to a previous desktop that only had usb2 ports, but that machine is now
replaced with a new desktop that only has usb3 ports - the MFP works
without any error connected to a usb3 port for the printer functions but
the scanner hangs xsane whilst connected to the same physical port.
However the scanner when connected via its ethernet wired network
connection works fine from xsane using tcp. So the scanner function seems
to work provided it is not connected to a usb3 port. That desktop also runs
arch linux. A few months ago I tested this MFP plugging into the laptop
with usb3 ports and xsane hung when scanning was attempted on the laptop
via usb3 as well.
The combined set of information from these tests seems to indicate that
there is an issue with usb2 printers connected to a machine via usb3 when
using sane, though of course I only have archlinux so I don't know if the
same scanners would work properly when connected via usb3 to a machine
running a different version of linux where the package sets are versioned
differently? If anyone has either of the two scanners that I have, and are
running Ubuntu, Fedora,Mint or another version of linux in a machine with
usb3 ports it would be a very useful comparison?
To summarize your findings, you only have an issue when using scanners
(including an MFP) via USB3 ports. They work fine on USB2 ports or via
the network. Other devices (including the same MFP's printer part) work
fine on USB3 ports. Although we cannot rule out the possibility of a
Arch Linux specific issue, the problem seems to be with SANE's use of
USB.

I've had a quick look at the kernel threads you referred to. It seems
that the kernel's XHCI support may also still need some work. However,
seeing that your other devices work fine (but not knowing anything about
the kernel's USB3 internals really), I think SANE's use of USB could use
some scrutiny as well. Most, if not all, SANE backends use a wrapper
around libusb that might be at fault.

One note about the storage device you attached, that is unlikely to use
libusb. Printer drivers, though, most likely rely on libusb for their
communication. So if printing works without a hitch, that would point
a bigger finger in the direction of SANE's USB wrapper.

I had an admittedly cursory look at your USB captures. What struck me
is the enormous amount of USB control messages in
wireshark-start-xsane-acquire-preview-crash.pcapng, some 4234 packets
out of a total of 4326 captured. That's 97.9% of the packets. While I
find that surprising, I don't know whether it is abnormal. Maybe
someone with more knowledge of USB3 Linux support can chime in here?

That same capture also showed some bulk transfers but I don't know
anything about the protocol for this scanner.

Seeing the power/level warning only once may be due to the kernel
caching things. As for the MCE, you may want to chase your logs for the
events that got logged (apparently). You can probably find them in
kern.log. Reading up on MCEs[1], I got the impression that it could be
related to the large number of USB control messages.

[1] https://en.wikipedia.org/wiki/Machine-check-exception

Please note that I am just thinking out loud (and don't have a lot of
experience in this area).

I'll see if I can find some time to play around with another scanner and
reproduce some of what you're seeing.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-10-31 11:44:58 UTC
Permalink
Post by Jorge Fábregas
Hi Mike,
First of all, apologies for the somewhat belated reply. I will try to
piece all the bits from your flurry of mails that followed this one
together in this reply.
snip
I had an admittedly cursory look at your USB captures. What struck me
is the enormous amount of USB control messages in
wireshark-start-xsane-acquire-preview-crash.pcapng, some 4234 packets
out of a total of 4326 captured. That's 97.9% of the packets. While I
find that surprising, I don't know whether it is abnormal. Maybe
someone with more knowledge of USB3 Linux support can chime in here?
snip
Please note that I am just thinking out loud (and don't have a lot of
experience in this area).
I'll see if I can find some time to play around with another scanner and
reproduce some of what you're seeing.
Hope this helps,
Thank you for your extensive thoughts. No problem with delayed reply - most
of us only have a fraction of our time to work on these things.

It does seem that this is not going to be a simple issue to resolve, with
exploration needed on several different parts of the whole system, so
nailing where the fundamental problem lies could need fixes in the kernel,
the usb libraries or in sane code. Either way it would be useful to have
independent tests and more diagnostics. I did also read up more about mce
errors and it seems that there is a package that can be installed that will
allow getting more detailed logs from mce errors. I am not sure that this
will yield anything definitive though and it may be more of a consequence
of errors elsewhere.

Anyway in due course if this could be explored further and gain traction on
where the fixes are needed, then it might help quite a few people who are
driving usb2 scanners (the vast majority) through usb3 interfaces, which
will become a higher fraction of the usage cases for user machines as time
passes.
--
mike c
m. allan noah
2014-10-31 12:24:48 UTC
Permalink
The key point here, and the reason I asked for these logs initially,
was your ability to scan properly with vuescan, and not with sane. My
hope was that you could make the absolute smallest scan with identical
parameters in both programs, so we could compare. If things are
working better now, that will be difficult.

allan
Post by Mike Cloaked
Post by Jorge Fábregas
Hi Mike,
First of all, apologies for the somewhat belated reply. I will try to
piece all the bits from your flurry of mails that followed this one
together in this reply.
snip
Post by Jorge Fábregas
I had an admittedly cursory look at your USB captures. What struck me
is the enormous amount of USB control messages in
wireshark-start-xsane-acquire-preview-crash.pcapng, some 4234 packets
out of a total of 4326 captured. That's 97.9% of the packets. While I
find that surprising, I don't know whether it is abnormal. Maybe
someone with more knowledge of USB3 Linux support can chime in here?
snip
Post by Jorge Fábregas
Please note that I am just thinking out loud (and don't have a lot of
experience in this area).
I'll see if I can find some time to play around with another scanner and
reproduce some of what you're seeing.
Hope this helps,
Thank you for your extensive thoughts. No problem with delayed reply - most
of us only have a fraction of our time to work on these things.
It does seem that this is not going to be a simple issue to resolve, with
exploration needed on several different parts of the whole system, so
nailing where the fundamental problem lies could need fixes in the kernel,
the usb libraries or in sane code. Either way it would be useful to have
independent tests and more diagnostics. I did also read up more about mce
errors and it seems that there is a package that can be installed that will
allow getting more detailed logs from mce errors. I am not sure that this
will yield anything definitive though and it may be more of a consequence of
errors elsewhere.
Anyway in due course if this could be explored further and gain traction on
where the fixes are needed, then it might help quite a few people who are
driving usb2 scanners (the vast majority) through usb3 interfaces, which
will become a higher fraction of the usage cases for user machines as time
passes.
--
mike c
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Simon Matter
2014-10-31 12:36:27 UTC
Permalink
Post by m. allan noah
The key point here, and the reason I asked for these logs initially,
was your ability to scan properly with vuescan, and not with sane. My
hope was that you could make the absolute smallest scan with identical
parameters in both programs, so we could compare. If things are
working better now, that will be difficult.
Why not revert to the older kernel and see if the problem comes back?
Would be nice to confirm that the kernel makes the difference here.

Simon
Post by m. allan noah
allan
On Fri, Oct 31, 2014 at 8:58 AM, Olaf Meeuwissen
Post by Jorge Fábregas
Hi Mike,
First of all, apologies for the somewhat belated reply. I will try to
piece all the bits from your flurry of mails that followed this one
together in this reply.
snip
Post by Jorge Fábregas
I had an admittedly cursory look at your USB captures. What struck me
is the enormous amount of USB control messages in
wireshark-start-xsane-acquire-preview-crash.pcapng, some 4234 packets
out of a total of 4326 captured. That's 97.9% of the packets. While I
find that surprising, I don't know whether it is abnormal. Maybe
someone with more knowledge of USB3 Linux support can chime in here?
snip
Post by Jorge Fábregas
Please note that I am just thinking out loud (and don't have a lot of
experience in this area).
I'll see if I can find some time to play around with another scanner and
reproduce some of what you're seeing.
Hope this helps,
Thank you for your extensive thoughts. No problem with delayed reply - most
of us only have a fraction of our time to work on these things.
It does seem that this is not going to be a simple issue to resolve, with
exploration needed on several different parts of the whole system, so
nailing where the fundamental problem lies could need fixes in the kernel,
the usb libraries or in sane code. Either way it would be useful to have
independent tests and more diagnostics. I did also read up more about mce
errors and it seems that there is a package that can be installed that will
allow getting more detailed logs from mce errors. I am not sure that this
will yield anything definitive though and it may be more of a
consequence of
errors elsewhere.
Anyway in due course if this could be explored further and gain traction on
where the fixes are needed, then it might help quite a few people who are
driving usb2 scanners (the vast majority) through usb3 interfaces, which
will become a higher fraction of the usage cases for user machines as time
passes.
--
mike c
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Mike Cloaked
2014-10-31 14:21:04 UTC
Permalink
Post by Simon Matter
Post by m. allan noah
The key point here, and the reason I asked for these logs initially,
was your ability to scan properly with vuescan, and not with sane. My
hope was that you could make the absolute smallest scan with identical
parameters in both programs, so we could compare. If things are
working better now, that will be difficult.
Why not revert to the older kernel and see if the problem comes back?
Would be nice to confirm that the kernel makes the difference here.
Simon
The fail logs from the past couple of days were all with the newest kernel.
So the problem remains with the current kernel and it was only on one
occasion that by chance the scanner completed a scan and that just happened
to be with the new kernel soon after it was installed. I suspect that
repeated attempts with the previous kernel would not have made much
difference.
--
mike c
Continue reading on narkive:
Loading...