Suse 13.2 - scanner no longer working on 64-bit version

English Hardware
1

Hello,

I recently changed my old 32-bit machine (which was running suse 13.2) for a new x86_64 machine on which I installed 13.2, and ever since I can’t get my old Brother DCP-135C scanner to work. (It’s a multi-purpose device, the printer part is working). I used the described procedure in the Brother pages, as well as my notes on what I did on the 32-bit version to get everything working correctly in 13.2.

I’ve done all the pre-requisites including udev rules etc. and scanimage is recognizing the scanner (scanimage -L), but trying to actually use the scanner (scanimage -T) doesn’t work “Invalid argument”. I have the output of strace etc. available, if I figure out how to attach it to this post.

Turn scanner off, wait 30sec, turn back on = 1st initialization

root# export SANE_DEBUG_DLL=4
root# scanimage -T
[sanei_debug] Setting debug level of dll to 4.
[dll] sane_init: SANE dll backend version 1.0.13 from sane-backends 1.0.24
[dll] sane_init/read_dlld: attempting to open directory ./dll.d' [dll] sane_init/read_dlld: attempting to open directory /etc/sane.d/dll.d’
[dll] sane_init/read_dlld: opendir failed: No such file or directory
[dll] add_backend: adding backend brother2' [dll] sane_get_devices [dll] load: searching backend brother2’ in /usr/lib64/sane' [dll] load: trying to load /usr/lib64/sane/libsane-brother2.so.1’
[dll] load: dlopen()ing /usr/lib64/sane/libsane-brother2.so.1' [dll] init: initializing backend brother2’
[dll] init: backend brother2' is version 1.0.1 [dll] sane_get_devices: found 1 devices [dll] sane_open: trying to open brother2:bus4;dev1’
[dll] sane_open: open successful
[dll] sane_get_option_descriptor(handle=0xff19e0,option=0)
[dll] sane_control_option(handle=0xff19e0,option=0,action=0,value=0x7fff38c3eefc,info=(nil))
[dll] sane_get_option_descriptor(handle=0xff19e0,option=0)
[dll] sane_control_option(handle=0xff19e0,option=0,action=0,value=0x7fff38c3ee38,info=(nil))
[dll] sane_get_option_descriptor(handle=0xff19e0,option=1)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=2)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=3)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=4)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=5)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=6)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=7)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=8)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=9)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=10)
[dll] sane_get_option_descriptor(handle=0xff19e0,option=11)
[dll] sane_control_option(handle=0xff19e0,option=10,action=0,value=0x60b584,info=(nil))
[dll] sane_control_option(handle=0xff19e0,option=8,action=0,value=0x7fff38c3ee3c,info=(nil))
[dll] sane_control_option(handle=0xff19e0,option=11,action=0,value=0x60b588,info=(nil))
[dll] sane_control_option(handle=0xff19e0,option=9,action=0,value=0x7fff38c3ee3c,info=(nil))
[dll] sane_control_option(handle=0xff19e0,option=8,action=0,value=0x7fff38c3ef10,info=(nil))
[dll] sane_get_option_descriptor(handle=0xff19e0,option=10)
[dll] sane_control_option(handle=0xff19e0,option=10,action=1,value=0x7fff38c3ef30,info=0x7fff38c3ee3c)
scanimage: rounded value of br-x from 215.9 to 215.88
[dll] sane_control_option(handle=0xff19e0,option=9,action=0,value=0x7fff38c3ef10,info=(nil))
[dll] sane_get_option_descriptor(handle=0xff19e0,option=11)
[dll] sane_control_option(handle=0xff19e0,option=11,action=1,value=0x7fff38c3ef30,info=0x7fff38c3ee3c)
scanimage: rounded value of br-y from 355.6 to 355.567
[dll] sane_start(handle=0xff19e0)
scanimage: sane_start: Invalid argument
[dll] sane_cancel(handle=0xff19e0)
[dll] sane_close(handle=0xff19e0)
[dll] sane_exit: exiting
[dll] sane_exit: calling backend `brother2’s exit function
[dll] sane_exit: finished

Is this something to do with 32/64 bit, is it to do with Sane, with Suse, with brother drivers? I’m stuck here, any help is appreciated.

2

Starting from the top. Did you install the 64-bit RPM that is available for this model?

http://support.brother.com/g/b/downloadlist.aspx?c=gb&lang=en&prod=dcp135c_eu_as&os=127

3

Yes, I did install the 64-bit packages. Here’s the list of installed packages, the brscan packages are from brother:

root# rpm -qa | grep -i -e sane -e brscan | sort

brscan-skey-0.2.4-1.x86_64
brscan2-0.2.5-1.x86_64
hplip-sane-3.14.6-2.2.4.x86_64
libksane0-14.12.3-16.1.x86_64
sane-backends-1.0.24-2.1.10.x86_64
sane-backends-32bit-1.0.24-2.1.10.x86_64
sane-backends-autoconfig-1.0.24-2.1.10.x86_64
xsane-0.998-22.1.5.x86_64

4

Is the scanner connected to a USB 3.0 or USB 2.0 port? (Just in case this is affecting the behaviour somehow)

This is definitely concerning and it may require a bug report to help resolve

[dll] sane_start(handle=0xff19e0)
scanimage: sane_start: Invalid argument'
5

Looking at the back of the PC it appears to be USB 2.0 (the symbol doesn’t mention SS as the USB ports on the front do). I don’t think the USB version is directly related. However, since checking the back of the PC is rather difficult, I first checked with lsusb. It did make me notice something else (bold stuff): scanimage and lsusb don’t report the same bus:device descriptor!

lsusb -v output for version numbers:


... stuf omitted ...

**Bus 003 Device 015**: ID 04f9:01ce Brother Industries, Ltd DCP-135C
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x04f9 Brother Industries, Ltd
  idProduct          0x01ce DCP-135C
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 3 BROJ8F733644
  bNumConfigurations      1

... stuf omitted ...

whereas scanimage -L


[sanei_debug] Setting debug level of dll to 4.
[dll] sane_init: SANE dll backend version 1.0.13 from sane-backends 1.0.24
[dll] sane_init/read_dlld: attempting to open directory `./dll.d'
[dll] sane_init/read_dlld: attempting to open directory `/etc/sane.d/dll.d'
[dll] sane_init/read_dlld: opendir failed: No such file or directory
[dll] add_backend: adding backend `brother2'
[dll] sane_get_devices
[dll] load: searching backend `brother2' in `/usr/lib64/sane'
[dll] load: trying to load `/usr/lib64/sane/libsane-brother2.so.1'
[dll] load: dlopen()ing `/usr/lib64/sane/libsane-brother2.so.1'
[dll] init: initializing backend `brother2'
[dll] init: backend `brother2' is version 1.0.1
[dll] sane_get_devices: found 1 devices
device `brother2:**bus4;dev1**' is a Brother DCP-135C USB scanner
[dll] sane_exit: exiting
[dll] sane_exit: calling backend `brother2's exit function
[dll] sane_exit: finished

I thus moved the scanner to a different port on the back, resulting in:


Bus 002 Device 002: ID 8087:8001 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
**Bus 003 Device 016**: ID 04f9:01ce Brother Industries, Ltd DCP-135C
Bus 003 Device 002: ID 04f2:0420 Chicony Electronics Co., Ltd 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

scanimage -L continues to report


device `brother2:bus4;dev1' is a Brother DCP-135C USB scanner

similar for all other ports a I tried on the back. The two ports on the front are USB 3.0, I tried both, but they too are on Bus3 at device 18 and 19 respectively.

6

As it turns out all the USB ports on my computer are on Bus 3 and the lowest device ID = 15 and going up in the 20s.

But whatever I do scanimage -L always lists it as “bus4:dev1”

A bug somewhere?

7

small correction, the device IDs seem to be allocated dynamically, hence physically putting a device on another USB port will always increase the device ID number on Bus 3. By rebooting I did manage to get:


Bus 003 Device 003: ID 04f9:01ce Brother Industries, Ltd DCP-135C

no different though. Scanimage -L reports


device `brother2:bus4;dev1' is a Brother DCP-135C USB scanner

Looking in the output of strace (result of strace -o strace.out scanimage -T), the whole scanimage false reports may be just a display bug, because the open call does use 003/003


*... stuff omitted ...*
open("/dev/**bus/usb/003/003**", O_RDWR)    = 189
ioctl(189, SNDRV_CTL_IOCTL_TLV_READ or USBDEVFS_GET_CAPABILITIES, 0x12b9ba0) = 0
write(7, "\1", 1)                       = 1
read(6, "\1", 1)                        = 1
ioctl(189, USBDEVFS_SETCONFIGURATION, 0x7fff3c862bbc) = -1 EBUSY (Device or resource busy)
ioctl(189, SNDRV_CTL_IOCTL_ELEM_UNLOCK or USBDEVFS_CLEAR_HALT, 0x7fff3c862bbc) = 0
*... stuff omitted ...*

if I


grep 189 strace.out

I get


open("/dev/bus/usb/003/003", O_RDWR)    = 189
ioctl(189, SNDRV_CTL_IOCTL_TLV_READ or USBDEVFS_GET_CAPABILITIES, 0x12b9ba0) = 0
ioctl(189, USBDEVFS_SETCONFIGURATION, 0x7fff3c862bbc) = -1 EBUSY (Device or resource busy)
ioctl(189, SNDRV_CTL_IOCTL_ELEM_UNLOCK or USBDEVFS_CLEAR_HALT, 0x7fff3c862bbc) = 0
ioctl(189, USBDEVFS_CLAIMINTERFACE, 0x7fff3c862aec) = 0
ioctl(189, USBDEVFS_SUBMITURB, 0x12b9e10) = 0
poll({fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=189, events=POLLOUT}], 4, 60000) = 1 ({fd=189, revents=POLLOUT}])
**ioctl(189, USBDEVFS_REAPURBNDELAY, 0x7fff3c862998) = 0
ioctl(189, USBDEVFS_REAPURBNDELAY, 0x7fff3c862998) = -1 EAGAIN (Resource temporarily unavailable)
ioctl(189, USBDEVFS_SUBMITURB, 0x12b9e10) = 0
poll({fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=189, events=POLLOUT}], 4, 60000) = 1 ({fd=189, revents=POLLOUT}])**
*... pattern in bold repeats another 312 times to end with ...*
ioctl(189, USBDEVFS_REAPURBNDELAY, 0x7fff3c862aa8) = -1 EAGAIN (Resource temporarily unavailable)
ioctl(189, SNDRV_CTL_IOCTL_ELEM_LIST or USBDEVFS_RELEASEINTERFACE, 0x7fff3c862bdc) = 0
close(189)                              = 0
8

I think a bug report with the scanimage debug and strace output will be required to help resolve this. It would be interesting to see whether the 32-bit drivers can work. (I think ‘sane-backends-32bit’ is required for this.)

9

…and I still wonder about whether this is perhaps related to USB 3.0 (XHCI) communication failure?

10

The device number is immaterial. We are speaking about the USB protocol used. The error report indicate you were using a USB3 protocol but you need to try a USB2 protocol. Most machines will still have both. Sometimes the USB 3’s are coloured different. There have been some problems reported with some hardware USB3 ports

11

I just checked: the motherboard is an ASUS H97M-E which has both

  • 6 USB3.0/2.0 ports (4 blue ports at back-panel, and 2 at mid-board)
  • 8 USB 2.0/1.1 ports (6 ports at midboard, 2 ports at back-panel) (presumably other colours; not mentioned in the manual).

However, the only ports that are accessible from the outside of the casing are 6 blue ports at the back (and thus USB 3.0/2.0 I presume) and 2 USB-SS labeled ports on the front. Since the PC assembler, for warranty purposes, sealed the casing of my computer (opening it will void the warranty), there is no easy way for me to force hardware-wise a USB 2.0 port.

Is there a way to accomplish such thing through kernel parameters or so?

Happy to upload full strace output, but I don’t have permission to upload attachments.

I tried another port, and here’s the lsusb output for that port


Bus 003 Device 006: ID 04f9:01ce Brother Industries, Ltd DCP-135C
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x04f9 Brother Industries, Ltd
  idProduct          0x01ce DCP-135C
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                0 
  iSerial                 3 BROJ8F733644
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           85
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      2 Bidirectional
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             100
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
12

There might be a BIOS (or UEFI) setting for enabling/disabling XHCI mode. Worth a shot.

13

Sorry for the delay in posting an answer. Thanks to all of you for pointing me in the direction of a USB2 vs. USB3 problem, this turned out to be the problem, but the solution wasn’t as straight forward.

On reading about USB protocols and controllers it turns out that xHCI refers to a USB3 controller and eHCI to a USB2 controller. There seem to be many problems with older devices, and most BIOSes apparently have a setting to disable xHCI, as did mine, so this was the first thing I tried:

The BIOS has in the advanced settings a place to specify one of 4 values for XHCI:


        XHCI = disables -> all USB ports are USB 2.0 ports
        XHCI = enabled -> all USB ports are USB 3.0 ports
        XHCI = auto -> 2.0 until the OS detects 3.0, detection upon reboot
        XHCI = Smart Auto -> 2.0 until the OS detects 3.0, no subsequent detections upon reboot

I set it to “disabled” and yes, the scanner was working perfectly.

I didn’t actually think disabling USB3.0 would be a wise long-term decision for my new PC, so I looked around for possible software solutions. It is then that I stumbled on this interesting post (scroll down to where it says “setpci”):
http://superuser.com/questions/812022/force-a-single-usb-3-0-port-to-work-as-usb-2-0

However, looking into the specifications of the motherboard, my PC has the 9-series chipset of Intel, for which the documentation can be found here
http://www.intel.com/content/www/us/en/chipsets/9-series-chipset-pch-datasheet.html

WARNING: all the below is chipset specific for the Intel 9 series

The relevant chapter is chapter 16 where there is an overview table at the start, and more in particular 16.1.36 and 16.1.38

There is a more convenient way to specify the device in setpci, that is by using lspci:


root# lspci
...
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller
...

thus from now on I can use:


root# setpci -H1 -s 00:14.0 d8.L=0      # set ALL USB ports to 2.0, USB3_PSSEN attribute
                            ^^ ^
                             | |
                             | - see man page of setpci .L forces 4 bytes to be written
                             - see 9-series pdf in chapter 16 address offset D8 for attribute USB3_PSSEN, values

As it turns out this doesn’t help me, but the other setting is about controlling which USB port gets routed over which controller: the xHCI or the eHCI controller. As specified in 16.1.36

We read the value:


root# setpci -H1 -s 00:14.0 d0.L
00003fff

3fff is the hex value for 14 bits (0…13) set to 1 meaning all 14 usb ports the controller can handle are routed over the xHCI controller. Setting a bit to 0 means the port will be handled by the eHCI (USB 2.0) controller.


        13 12 11 10  9  8  7  6  5  4  3  2  1  0
         1  1  1  1  1  1  1  1  1  1  1  1  1  1 = 3FFF

I couldn’t find an easy way to figure out which USB port of these 14 my scanner was on, so I did a binary search. Remeber to plug out / plug in your USB device, because that is the moment where the routing to the controller gets determined. Also note: on doing a binary search I set half of the ports to 0 in the first step, this required mouse and keyboard to reinitialize and took a few seconds; but everything recovered fine.

In my case the USB port turned out to be port 8, bit 7, and it is this port I set to 0:


        13 12 11 10  9  8  7  6  5  4  3  2  1  0
         1  1  1  1  1  1  0  1  1  1  1  1  1  1 = 3F7F

And yes EVERYTHING WORKING correctly!!!

Now make this permanent in the boot:


root# systemctl status rc-local.service

implies the script /etc/init.d/boot.local is executed at startup, I added the line:


setpci -H1 -s 00:14.0 d0.L=3F7F

It worked for me. And since the Intel 9-series is not uncommon, I hope this explanation helps others.

14

Yes, it impacts on a lot of users without realising that it is the cause.

I didn’t actually think disabling USB3.0 would be a wise long-term decision for my new PC, so I looked around for possible software solutions. It is then that I stumbled on this interesting post (scroll down to where it says “setpci”):
windows 7 - Force a single USB 3.0 port to work as USB 2.0 - Super User

Well done with pursuing this. I’ve only ever seen recommendations to disable in the BIOS when there are problems. This appears to be a more sophisticated approach. Thanks for sharing the additional information.