Bug 701368

*** Bug 697694 has been marked as a duplicate of this bug. ***

Today I retested this with the current factory versions, that should be openSUSE 12.1 Milestone 4.

sane: sane-backends-1.0.22-13.6.i586
kernel: Linux lthendrik.site 3.0.0-2-desktop #1 SMP PREEMPT Fri Jul 22 08:28:15 UTC 2011 (50c05d7) i686 i686 i386 GNU/Linux

The issue with the mouse still exists.
I tested with two other USB devices, an external hard disk and a DVB-T-stick. Both devices keep working, when the mouse gets blocked.

hwinfo --mouse shows this about that USB mouse:

lthendrik:/home/hendrik # hwinfo --mouse
39: USB 00.0: 10503 USB Mouse                                   
  [Created at usb.122]
  Unique ID: FKGF.IvHLBRRchEC
  Parent ID: pBe4.v+N+B0xY+P6
  SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
  SysFS BusID: 2-1:1.0
  Hardware Class: mouse
  Model: "STMicroelectronics Imaging Division (VLSI Vision) 5 button optical mouse with scroll wheel"
  Hotplug: USB
  Vendor: usb 0x0553 "STMicroelectronics Imaging Division (VLSI Vision)"
  Device: usb 0x0a02 "5 button optical mouse with scroll wheel"
  Revision: "1.00"
  Compatible to: int 0x0210 0x0015
  Driver: "usbhid"
  Driver Modules: "usbhid"
  Device File: /dev/input/mice (/dev/input/mouse0)
  Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event1, /dev/input/by-id/usb-5_button_optical_mouse_with_scroll_wheel_5_button_optical_mouse_with_scroll_wheel-event-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1:1.0-event-mouse, /dev/input/by-id/usb-5_button_optical_mouse_with_scroll_wheel_5_button_optical_mouse_with_scroll_wheel-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1:1.0-mouse
  Device Number: char 13:63 (char 13:32)
  Speed: 1.5 Mbps
  Module Alias: "usb:v0553p0A02d0100dc00dsc00dp00ic03isc01ip02"
  Driver Info #0:
    Buttons: 5
    Wheels: 1
    XFree86 Protocol: explorerps/2
    GPM Protocol: exps2
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #35 (Hub)

More versions, more tests:

openSUSE 12.1 Final : bug still there
openSUSE 12.1 Final with Tumbleweed (kernel 3.2): bug still there

openSUSE 12.2 Milestone 1: bug is gone

Please attach dmesg of the failure case. The log attached in the description begins too late.

Created attachment 480136 [details]
new system logs from sane-find-scanner runs

I reinstalled OS 12.1 at the test machine, and let sane-find-scanner run until the mouse got blocked. Another run of  sane-find-scanner unblocked the mouse.
After that I copied /var/log/messages und the output of dmesg.

There's simply nothing unusual in the log. Odd. Can you please run "lsusb -v" after the scanner has blocked and attach the reslt?

Created attachment 480498 [details]
lsusb output

I attached the output of lsusb -v before and after the mouse got blocked by sane-find-scanner.

Also nothing wrong. Can you please provide the output of "lsusb -t" before and after blockage?

Created attachment 480769 [details]
lsusb -t output

Created attachment 480771 [details]
lsusb -D output

One more try with: lsusb -D /dev/bus/usb/003/002
There is a difference.

(In reply to comment #10)
> Created an attachment (id=480771) [details]
> lsusb -D output
> 
> One more try with: lsusb -D /dev/bus/usb/003/002
> There is a difference.

I am afraid I am too stupid to see it. Could you clarify?

before:
  iManufacturer           1 5 button optical mouse with scroll wheel
  iProduct                3 5 button optical mouse with scroll wheel
after:
  iManufacturer           1 
  iProduct                3 

Not much of a difference and probably not helpful:(

(In reply to comment #3)
> More versions, more tests:
> 
> openSUSE 12.1 Final : bug still there
> openSUSE 12.1 Final with Tumbleweed (kernel 3.2): bug still there
> 
> openSUSE 12.2 Milestone 1: bug is gone

Very well. Could you try the kernel of the working version on your system?

I tested 12.1 + Tumbleweed (kernel 3.3.0-16-desktop) against 12.2 Milestone 2 (kernel 3.3.0-rc6-1-default). Again in 12.1 the problem was still there and in 12.2 not. But then I checked the output of "sane-find-scanner -v" of both versions and found in the 12.2-version an error message:
"libusb not available"
So I think, that the 12.2-version does not even read/write _any_ USB device and is therefore not able to cause any problems. 
This might by worth a bug report of its own. But my scanner is not attached by USB and I cannot check, if sane-find-scanner is able to detect USB devices.

(In reply to comment #14)

> versions and found in the 12.2-version an error message:
> "libusb not available"

This is odd due to a kernel change. Please check for the availability of libusb
with the rpm tool.

I am sure, that libusb was there. But in the meantime I installed openSUSE 12.2 Milestone 3. In this version the error message about missing libusb is gone, but now the problem (mouse freezes) is back. 
I also tested different mouse models from another vendor (Logitech). With these mice I don't have this problem.

Johannes, this suggests strongly that this is a problem with the firmware of the mouse in question. Can we teach sane-find-scanner to leave such devices alone? Is there a scanner that pretends to be an HID device?

I am afraid, I do not know if there are plain USB scanner devices
or USB all-in-one devices (with a built-in scanner unit)
which use USB device classes other than
- 255 "Vendor Specific Class" (usually for plain scanners) or
- 7 "Printer" (usually for all-in-one devices).

I think as long as sane-find-scanner only reads libusb information
it cannot cause the USB mouse device to become disconnected.

I think it is that sane-find-scanner also tries to find out the
type of USB chip used in the device which causes the trouble
with this particular USB mouse, see "man sane-find-scanner".

Hendrik Woltersdorf,
in https://bugzilla.novell.com/show_bug.cgi?id=697694#c10
I wrote "sane-find-scanner -vv" which was unfortunately a typo
because "sane-find-scanner -vv" is the same as "sane-find-scanner -v".

To get the USB device descriptor information please run as root

# sane-find-scanner -v -v

and attach its output as MIME type "text/plain".

E.g. on my workstation "sane-find-scanner -v -v" results:
---------------------------------------------------------------------------
This is sane-find-scanner ...
...
searching for SCSI scanners:
...
searching for USB scanners:
...
trying libusb:
...
<device descriptor of 0x04a9/0x220e at 008:002 (Canon CanoScan)>
...
<trying to find out which USB chip is used>
  checking for GT-6801 ...
  this is not a GT-6801 (bDeviceSubClass = 0x0)
  checking for GT-6816 ...
  this is not a GT-6816 (bDeviceClass = 255, bInterfaceClass = 255)
  checking for GT-8911 ...
  this is not a GT-8911 (check 1, bDeviceClass = 255, bInterfaceClass = 255)
  checking for MA-1017 ...
  this is not a MA-1017 (bDeviceClass = 255, bInterfaceClass = 255)
  checking for MA-1015 ...
  this is not a MA-1015 (bcdUSB = 0x110)
  checking for MA-1509 ...
  this is not a MA-1509 (bDeviceSubClass = 0x0)
  checking for LM983[1,2,3] ...
<This USB chip looks like a LM9832/3

found USB scanner (vendor=0x04a9 [Canon], product=0x220e [CanoScan],
 chip=LM9832/3) at libusb:008:002
...
done
---------------------------------------------------------------------------

My assumption is that for Hendrik Woltersdorf's USB mouse device
sane-find-scanner is "trying to find out which USB chip is used"
and that causes the trouble.

Created attachment 486731 [details]
output of sane-findscanner -v -v

Hendrik Woltersdorf,
Was your "5 button optical mouse with scroll wheel" again
disconnected when you did run "sane-find-scanner -v -v"?

Your attachment #486731 [details]
does not show any "trying to find out which USB chip is used"
in particular not for your "5 button optical mouse with scroll wheel"
so that it seems my above assumption is wrong.

I need to ckeck in detail what the check_libusb_device function
which is called by sane-find-scanner actually does - but I am
not at all an USB expert so that this may take a while...

I set needinfo to myself while I ckeck check_libusb_device.

There are two check_libusb_device functions in tools/sane-find-scanner.c
in the SANE sources, one "#ifdef HAVE_LIBUSB" and
one "#ifdef HAVE_LIBUSB_1_0".

As far as I see the check_libusb_device functions only test
libusb values and does not communicate with the USB device
(long lines shown wrapped here):
------------------------------------------------------------------------------
#ifdef HAVE_LIBUSB
...
  for (interface_nr = 0; interface_nr < dev->config[0].bNumInterfaces && is_scanner <= 0; interface_nr++)
    {
      switch (dev->descriptor.bDeviceClass)
        {
        case USB_CLASS_VENDOR_SPEC:
          ++is_scanner;
          break;
        case USB_CLASS_PER_INTERFACE:
          if (dev->config[0].interface[interface_nr].num_altsetting == 0 ||
              !dev->config[0].interface[interface_nr].altsetting)
            break;
          switch (dev->config[0].interface[interface_nr].altsetting[0].bInterfaceClass)
            {
            case USB_CLASS_VENDOR_SPEC:
            case USB_CLASS_PER_INTERFACE:
            case 16:                /* data? */
              ++is_scanner;
              break;
            }
          break;
        }
    }

  if (is_scanner > 0)
    {
      char * chipset = check_usb_chip (dev, verbose, from_file);

      printf ("found USB scanner (vendor=0x%04x", dev->descriptor.idVendor);
...
#ifdef HAVE_LIBUSB_1_0
...
  for (intf = 0; (intf < config0->bNumInterfaces) && (is_scanner <= 0); intf++)
    {
      switch (desc.bDeviceClass)
        {
          case USB_CLASS_VENDOR_SPEC:
            ++is_scanner;
            break;
          case USB_CLASS_PER_INTERFACE:
            if ((config0->interface[intf].num_altsetting == 0)
                || config0->interface[intf].altsetting)
              break;
            switch (config0->interface[intf].altsetting[0].bInterfaceClass)
              {
                case USB_CLASS_VENDOR_SPEC:
                case USB_CLASS_PER_INTERFACE:
                case 16:                /* data? */
                  ++is_scanner;
                  break;
              }
            break;
        }
    }
...
  if (is_scanner > 0)
    {
#if 0
      char *chipset = check_usb_chip (dev, verbose, from_file);
#endif

      printf ("found USB scanner (vendor=0x%04x", vid);
------------------------------------------------------------------------------
where include/sane/sanei_usb.h lists
------------------------------------------------------------------------
#define USB_CLASS_VENDOR_SPEC           0xff
#define USB_CLASS_PER_INTERFACE         0x00
------------------------------------------------------------------------

As far as I see sane-find-scanner only does check_usb_chip
when the USB device class is 255 "Vendor Specific Class"
and then it would print "found USB scanner" which is
not the case in attachment #486731 [details]

Therefore - from my point of view - there is no code in sane-find-scanner
which can trigger that the "5 button optical mouse with scroll wheel"
gets disconnected.

But I am not at all an USB expert so that my analysis could be wrong.

(In reply to comment #21)

> As far as I see the check_libusb_device functions only test
> libusb values and does not communicate with the USB device
> (long lines shown wrapped here):

The descriptors which libusb evaluates are first retrieved from the device. According to the USB spec devices must always be able to deliver the device descriptors. This particular mouse seems to have a buggy firmware that expects a request for device descriptors only at the times a certain other OS requests them.

I am afraid SANE needs to have a blacklist entry for this device based on a VID:PID pair.
Is there a facility for that in SANE?

As far as I see in the SANE sources for the sanei_usb_init function
in sanei/sanei_usb.c it calls the libusb functions
usb_init(); usb_find_busses(); usb_find_devices ();
before it loops through all of the busess and all of the devices
to find USB devices with "USB_CLASS_VENDOR_SPEC":
-----------------------------------------------------------------------
sanei_usb_init
...
  DBG (4, "sanei_usb_init: Looking for libusb devices\n");
  usb_init ();
#ifdef DBG_LEVEL
  if (DBG_LEVEL > 4)
    usb_set_debug (255);
#endif /* DBG_LEVEL */

  usb_find_busses ();
  usb_find_devices ();

  /* Check for the matching device */
  for (bus = usb_get_busses (); bus; bus = bus->next)
    {
      for (dev = bus->devices; dev; dev = dev->next)
        {
-----------------------------------------------------------------------

Hendrik Woltersdorf,
you could run
------------------------------------------------
# export SANE_DEBUG_SANEI_USB=128
# sane-find-scanner -v -v 2>&1 | less
------------------------------------------------
to get additionally SANE USB debug messages.
Check for "Looking for libusb devices" and subsequent messages.

I.e. SANE works - as far as I see - as described in
http://libusb.sourceforge.net/doc/examples-code.html

I assume this particular "5 button optical mouse with scroll wheel"
USB devices would get disconnected when any program calls the
libusb functions usb_init(); usb_find_busses(); usb_find_devices();

I do not understand how blacklisting in SANE could help at all
when a device get disconnected when the libusb functions
usb_init(); usb_find_busses(); usb_find_devices();
are called because those functions are not device specific.

Therefore I think a blacklist for broken USB devices
which get disconnected when those libusb functions
are called as described in the libusb Developers Guide
might work if it happens in libusb to avoid such issues
for any program and not only for SANE programs.

On the other hand:
If a broken USB device would be blacklisted in libusb
(so that libusb ignores it), how could it be used at all?

In the end I think blacklisting would not really help
(at least not in SANE).

As far as I see all what Hendrik Woltersdorf could do
with his "5 button optical mouse with scroll wheel"
is to re-plug it whenever it got disconnected.

I will ask on the sane-devel@lists.alioth.debian.org
mailing list what SANE upstream thinks about
blacklisting USB devices in SANE because in
other exceptional cases it might make sense.

I close the issue as WONTFIX for openSUSE which means
that we (i.e. openSUSE) will not (and probably cannot)
implement something to work around such broken USB devices.

Created attachment 487029 [details]
2. output of sane-find-scanner -v -v

Not every run of sane-find-scanner disables this mouse and I do not run sane-find-scanner all day long. So this is a minor problem and WONTFIX is fine with me.
I attached 2 outputs of sane-find-scanner with "SANE_DEBUG_SANEI_USB=128". 
sf_128.log   : run without disabling the mouse
sf_128_2.log : run with disabling the mouse

Whether or not the issue is closed as WONTFIX (at least for now)
does not hinder us to continue (but it is no longer seen as an
open bug in openSUSE which is the main reason to have it closed).

"diff -u1 sf_128.log sf_128_2.log" shows (long lines wrapped here):
--------------------------------------------------------------------------
--- sf_128.log  2012-04-19 20:27:59.000000000 +0200
+++ sf_128_2.log        2012-04-19 20:28:11.000000000 +0200
@@ -262,3 +262,3 @@
 
-<device descriptor of 0x0553/0x0a02 at 002:002 (5 button optical
 mouse with scroll wheel 5 button optical mouse with scroll wheel)>
+<device descriptor of 0x0553/0x0a02 at 002:002 (5 button optical
 mouse with scroll wheel 5 button optica)>
 bLength               18
@@ -274,3 +274,3 @@
 iManufacturer         1 (5 button optical mouse with scroll wheel)
-iProduct              3 (5 button optical mouse with scroll wheel)
+iProduct              3 (5 button optica)
 iSerialNumber         0 ()
--------------------------------------------------------------------------

In sf_128_2.log (with disabling the mouse) the iProduct string is
truncated (the device descriptor shows the iManufacturer and iProduct
strings which are identical in this case).

The truncated iProduct string indicates - from my non-expert point
of view - that the communication with the USB device got somehow
corrupted.

In particular the diff shows that there is nothing different
regarding what SANE does in both cases which indicates - from
my non-expert point of view - that the root cause is not
in SANE.


But perhaps it might make a difference whether or not the
old libusb0 is used or the newer libusb1 to communicate
with USB devices.

Currently the sane-backends packages uses the old libusb0
but not directly as in the beginning but since some time
via the compatibility layer libusb-compat and this
compatibility layer had already caused some issues
in particular bnc#559697 and bnc#596411 - see
https://bugzilla.novell.com/show_bug.cgi?id=559697#c7
for the libusb naming and versioning numbering.

Because newer sane-backends versions support libusb1 directly
I updated our sane-backends package right now in its OBS
development project "graphics" to use libusb1 directly.

Hendrik Woltersdorf,
if you like you may try out for testing if our newest
sane-backends package from the "graphics" project
works better for you.

It is available as ready-made RPMs for openSUSE 11.4 and 12.1
via the "graphics" development project in the openSUSE build
service for 32-bit i586 and 64-bit x86_64 architecture.

E.g. for openSUSE 12.1 32-bit architecture from this direct URL
http://download.opensuse.org/repositories/graphics/openSUSE_12.1/i586/

The newest sane-backends package contains this RPM changelog entry:
----------------------------------------------------------------------
# rpm -q --changelog sane-backends | head -n3
* Fri Apr 20 2012 jsmeix@suse.de
- Configure --enable-libusb_1_0 plus BuildRequires libusb-1_0-devel
  to use libusb1 (instead of using libusb0 via libusb-compat),
----------------------------------------------------------------------

Do not use "Factory" if your system is not "Factory".
Use the matching packages for your particular system.
The packages in the "graphics" development project are
only for testing, without any guarantee or warranty,
and without any support. As an extreme example, this means
if your complete computer center crashes because of those
packages, it is only your problem. On the other hand
this does not mean that those packages are known to be
terrible broken but they are not thoroughly tested
so that any unexpected issue can happen.

I appreciate any feedback whether or not sane-backends
from the "graphics" project works for you.

Many Thanks in advance for testing it!

I tested the sane-backends from the "graphics" repository. Now things got worse. When the mouse got disabled, that disabled state survived a reboot. I needed to plug in a different mouse (Logitech M90), which worked. After that the "problem-mouse" did work again. See the corresponding dmesg output:
...
[   91.682054] usb 2-1: new low-speed USB device number 6 using uhci_hcd
[   91.847053] usb 2-1: device descriptor read/64, error -71
[   92.061064] usb 2-1: device descriptor read/64, error -71
[   92.264067] usb 2-1: new low-speed USB device number 7 using uhci_hcd
[   92.429069] usb 2-1: device descriptor read/64, error -71
[   92.643024] usb 2-1: device descriptor read/64, error -71
[   92.846082] usb 2-1: new low-speed USB device number 8 using uhci_hcd
[   93.254079] usb 2-1: device not accepting address 8, error -71
[   93.356085] usb 2-1: new low-speed USB device number 9 using uhci_hcd
[   93.764078] usb 2-1: device not accepting address 9, error -71
[   93.764097] hub 2-0:1.0: unable to enumerate USB device on port 1
[  109.126051] usb 3-2: new low-speed USB device number 2 using uhci_hcd
[  109.291047] usb 3-2: device descriptor read/64, error -71
[  109.505052] usb 3-2: device descriptor read/64, error -71
[  109.708062] usb 3-2: new low-speed USB device number 3 using uhci_hcd
[  109.822062] usb 3-2: device descriptor read/64, error -71
[  110.087075] usb 3-2: device descriptor read/64, error -71
[  110.290104] usb 3-2: new low-speed USB device number 4 using uhci_hcd
[  110.699045] usb 3-2: device not accepting address 4, error -71
[  110.801084] usb 3-2: new low-speed USB device number 5 using uhci_hcd
[  111.209079] usb 3-2: device not accepting address 5, error -71
[  111.209099] hub 3-0:1.0: unable to enumerate USB device on port 2
[  204.306086] usb 2-1: new low-speed USB device number 10 using uhci_hcd
[  204.520139] usb 2-1: New USB device found, idVendor=046d, idProduct=c05a
[  204.520149] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  204.520156] usb 2-1: Product: USB Optical Mouse
[  204.520162] usb 2-1: Manufacturer: Logitech
[  204.538700] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input10
[  204.539000] generic-usb 0003:046D:C05A.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.0-1/input0
[  221.454121] usb 2-1: USB disconnect, device number 10
[  231.156087] usb 2-1: new low-speed USB device number 11 using uhci_hcd
[  231.384142] usb 2-1: New USB device found, idVendor=0553, idProduct=0a02
[  231.384151] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
[  231.384159] usb 2-1: Product: 5 button optical mouse with scroll wheel
[  231.384166] usb 2-1: Manufacturer: 5 button optical mouse with scroll wheel
[  231.403083] input: 5 button optical mouse with scroll wheel 5 button optical mouse with scroll wheel as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input11
[  231.403626] generic-usb 0003:0553:0A02.0002: input,hidraw0: USB HID v1.10 Mouse [5 button optical mouse with scroll wheel 5 button optical mouse with scroll wheel] on usb-0000:00:1d.0-1/input0

--------------------------------------------
I tried two times in different ports the problem-mouse before using the Logitech model.

--------------------------------------------
lthendrik:/home/hendrik # rpm -qa sane-backends
sane-backends-1.0.22-72.1.i586

Precision: That odd behavior happened after I upgraded only the sane-backends package. Later I did a "zypper dup" (the recommended update method for OS 12.1+Tumbleweed) and beside a lot of other packages, including a new kernel, the package sane-backends-autoconfig got updated too.
After these updates the behavior returned to "normal". That means, it is no longer necessary to plug in a different mouse model to revive the "problem-mouse".