SULDR Forums Supported Printers Printing Questions Scanning Questions General Questions Samsung Installer

CLX-3185 scanner on USB not recognized by Debian Wheezy

Started by JMM, January 20, 2013, 11:07:00

Previous topic - Next topic

JMM

I recently installed Debian Wheezy (beta-4 installer), and still have Debian Squeeze working.
SULDR perfectly worked with Squeeze.

With Wheezy, printing is perfect (better quality then before I guess, halftones are great !). The scanner seems to be recognized but an input/output error occurs (in French : smfp:SAMSUNG CLS-3180 Series on USB:0': Erreur d'entrée/sortie sur le périphérique). Installing the fix "samsungmfp-scanner-usblp-fix" did not help. According to recommendations, I removed it.

Then I tried to install the Samsung UnifiedLinuxDriver 1.13. The installer is clearly unappropriate, it could not recognized that sane API where already installed and also that Qt was fully installed. The scanner was not recognised at all (not listed in the configurator), and the installer recognized a additional printer that did not exist.

So I uninstalled the Samsung UnifiedLinuxDriver 1.13 and went back to SULDR.

"sane-find-scanner -v" answers :
found USB scanner (vendor=0x04e8 [Samsung Electronics Co., Ltd.], product=0x343d [CLX-3180 Series]) at libusb:001:002

"scanimage -L" answers :
device `smfp:SAMSUNG CLX-3180 Series on USB:0' is a SAMSUNG CLX-3180 Series on USB:0 Scanner

This all the information I can provide. Of course I am ok to make more tests if somebody has ideas.

Regards,
JMM

JMM

Some more information : here is what I get from /var/log/syslog after running "xsane" or "scanimage -T"

Jan 27 17:01:35 island04 scanimage: io/hpmud/pp.c 627: unable to read device-id ret=-1
Jan 27 17:01:35 island04 kernel: [80955.297042] usb 1-1: usbfs: process 13371 (scanimage) did not claim interface 0 before use
Jan 27 17:01:39 island04 kernel: [80959.358290] usb 1-1: usbfs: process 13371 (scanimage) did not claim interface 0 before use

bchemnet

I'm not sure what to make of this.  I can find scattered reports of similar behavior from libusb-1.0-0, but nothing that is particularly useful for troubleshooting this (and it's not even clear whether the syslog messages are meaningful).  Perhaps try installing the version of libusb-1.0-0 from sid?  It is a more recent release and might solve the issue.  You might also try installing usbview to see if it reports anything odd, but I wouldn't be too optimistic about that.

There's also the possibility that simply moving which USB port it is plugged into will help.  Although that shouldn't matter, it occasionally does.

JMM

Hi, thanks for advice,

usbview fails. It says :
Can not open the file /proc/bus/usb/devices.
Indeed this file does not exist.

usbview suggested to check the modules regarding usb in the kernel :
lsmod | grep usb says :
usblp                  17343  0
usbhid                 36418  0
hid                    81328  1 usbhid
usb_storage            43870  1
scsi_mod              162269  5 libata,usb_storage,sd_mod,sr_mod,sg
usbcore               128681  6 ehci_hcd,ohci_hcd,usb_storage,usbhid,usblp
usb_common             12354  1 usbcore

usbview also suggested to mount the "usbdevfs" file system. the mount command failed. I had to use "usbfs", seems to be the name of the filesystem in Debian Wheezy.

I did : mount -t usbfs none /proc/bus/usb

Now usbview works, it  can read /proc/bus/usb/devices and recognizes the devices. The only point is that the CLX-3180 Series is wirtten red, so may be something is odd...
Below is what usbview says about the device, it seems that interface 0 is not properly recognized, it has no name, all other devices listed by usbview have names. Is there a usb scanner module missing in the kernel ?

CLX-3180 Series
Manufacturer: Samsung Electronics Co., Ltd.
Serial Number: Z4OQBAABB00965H
Speed: 480Mb/s (high)
USB Version:  2.00
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 04e8
Product Id: 343d
Revision Number:  1.00

Config Number: 1
   Number of Interfaces: 2
   Attributes: c0
   MaxPower Needed:   2mA

   Interface Number: 0
      Name: (none)
      Alternate Number: 0
      Class: ff(vend.)
      Sub Class: ff
      Protocol: ff
      Number of Endpoints: 2

         Endpoint Address: 03
         Direction: out
         Attribute: 2
         Type: Bulk
         Max Packet Size: 512
         Interval: 1250us

         Endpoint Address: 84
         Direction: in
         Attribute: 2
         Type: Bulk
         Max Packet Size: 512
         Interval: 0ms

   Interface Number: 1
      Name: usblp
      Alternate Number: 0
      Class: 07(print)
      Sub Class: 01
      Protocol: 02
      Number of Endpoints: 2

         Endpoint Address: 01
         Direction: out
         Attribute: 2
         Type: Bulk
         Max Packet Size: 512
         Interval: 1250us

         Endpoint Address: 82
         Direction: in
         Attribute: 2
         Type: Bulk
         Max Packet Size: 512
         Interval: 0ms

And the scanner still fails, unfortunaltey,

Regards,
JMM

JMM

Additional comment.
I just checked usbview on Squeeze. The result is the same, the device CLX-3180 is marked red and interface 0 has no name.... but this does not prevent the sanner to work...
Regards,
JMM

bchemnet

I would assume a bug in the usb library based on this information.  Activating the sid respository and just updating the libusb system should be "safe" (I routinely pull packages from experimental and/or sid into testing when I need an update that is blocked by the freeze), and is the most likely single thing I can think of that might help.

JMM

Hi,
Since I am not a specialist of package management (by far) I feared intractable dependency problems introducing a central package such as libsub from another distribution, and decided did not do it (for now).

However I also could also note in the log file another problem with the usb mouse (Logitech, idVendor=046d, idProduct=c016). USB manager seemed to loose access to the mouse and frequently renew it. See example from kern.log, where 52 was previously attributed to the mouse (and it was 51 before being 52 aso...) :
[55723.829651] usb 2-4: USB disconnect, device number 52
[55724.164021] usb 2-4: new low-speed USB device number 53 using ohci_hcd
[55724.376042] usb 2-4: New USB device found, idVendor=046d, idProduct=c016

I bought a new mouse ! And no more changes in device numbers...

The result is that I a can access the scanner now but I still have the warning in the system.log file :

[  775.220813] usb 1-1: usbfs: process 4424 (xsane) did not claim interface 0 before use

My feeling is that since the connexion to the scanner seems not be not properly secured by the driver, unexpected changes in another USB device was the cause of the bad access to the scanner (kind of mismatch in device numbers).

So from my side the problem is partly solved (the system is workable), but still not perfectly behaving.

I sent a message to Samsung, which answered they did not support Debian (I new it, but I wanted to read their answer, at least, they quickly answered!). I will also send a bug report to libusb developers. It might be interesting to see if the (now harmless) message in system.log regarding interface claim also appears in other systems (I will try with my Ubuntu laptop -which should be supported by Samsung-). This would confirm the occurrence of some problems between libusb and the Samsung driver.

Thank you for your help and consideration.

JMM

Hi,

Just an additional comment :
In fact I still have "sometimes" the problem (input/output error occurs on scnanner and xsan fails), but not too often (:))

Regards,

Repository Information Legal Contact Alternative Drivers