Samsung ML-1640 working on Leap, not on Tumbleweed

Hi all

Re. this printer, I downloaded the UnifiedLinuxdriver from Samsung, followed instructions and the printer was added, visible in YaST’s printer module and all was working well on TW as well as on Leap 42.2 and 42.3 during all upgrades the latter got. It simply worked. Now, and I don’t know when this started because I hadn’t used the printer for months, it doesn’t.
As you can see, the system knows the device is existiing

@knurphtlaptop:~> lsusb**Bus 002 Device 004: ID 04e8:3292 Samsung Electronics Co., Ltd ML-1640 Series Laser Printer**
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 13d3:5710 IMC Networks UVC VGA Webcam
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

No matter what I try ( even tried copying the /etc/cups/ folder from the ( working ) Leao install, but to no avail ), I can’t get the thing recognized and configurable as a printer. Any thoughts ?

Hi Gertjan

Can you clarify a little further? Are you having problems even getting the printer detected and configured?

When the printer is turned on and connected what is reported by the following?

lpstat -t

…and is the CUPS USB backend detecting the printer ok?

/usr/lib/cups/backend/usb

Also run

sudo /usr/sbin/lpinfo -v

and see what is reported.

Cheers Dean, this is from the TW install, which doesn’t work

# lpstat -tscheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
# /usr/lib/cups/backend/usbDEBUG: Loading USB quirks from "/usr/share/cups/usb"
DEBUG: Loaded 132 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=6
DEBUG: Failed to open device, code: -1
# lpinfo -vnetwork beh
network ipps
network socket
network ipp
network http
network https
network lpd
direct hp
network smb
direct hpfax

Can you run the usb backend as regular user?

/usr/lib/cups/backend/usb

Also, the following

getfacl /dev/bus/usb/002/004

The libusb error you got when running the CUPS usb backend manually is apparently I/O related

DEBUG: Failed to open device, code: -1

Not sure about the underlying cause, but it might be useful to look at the udev info associated with the printer device node…assuming the printer is connected as you reported in your opening post

Bus 002 Device 004: ID 04e8:3292 Samsung Electronics Co., Ltd ML-1640 Series Laser Printer

then run the following…

udevadm info -x /dev/bus/usb/002/004

Here they are:


@knurphtlaptop:~> /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 132 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=6
DEBUG: Failed to open device, code: -1

The other one gives a ‘file not found’ error. But …

# file: dev/bus/usb/002/**019**# owner: root
# group: lp
user::rw-
group::rw-
other::r--

???

And …

# udevadm info -x /dev/bus/usb/002/019P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4
N: bus/usb/002/019
E: BUSNUM=002
E: DEVNAME=/dev/bus/usb/002/019
E: DEVNUM=019
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4
E: DEVTYPE=usb_device
E: DRIVER=usb
E: ID_BUS=usb
E: ID_MODEL=ML-1640_Series
E: ID_MODEL_ENC=ML-1640\x20Series
E: ID_MODEL_FROM_DATABASE=ML-1640 Series Laser Printer
E: ID_MODEL_ID=3292
E: ID_REVISION=0100
E: ID_SERIAL=Samsung_Electronics_Co.__Ltd._ML-1640_Series_144QBAHS602380E.
E: ID_SERIAL_SHORT=144QBAHS602380E.
E: ID_USB_INTERFACES=:070102:
E: ID_VENDOR=Samsung_Electronics_Co.__Ltd.
E: ID_VENDOR_ENC=Samsung\x20Electronics\x20Co.\x2c\x20Ltd.
E: ID_VENDOR_FROM_DATABASE=Samsung Electronics Co., Ltd
E: ID_VENDOR_ID=04e8
E: MAJOR=189
E: MINOR=146
E: PRODUCT=4e8/3292/100
E: SUBSYSTEM=usb
E: SYSTEMD_WANTS=configure-printer@usb-002-019.service printer.target
E: TAGS=:systemd:
E: TYPE=0/0/0
E: USEC_INITIALIZED=21346709711

The udev info seems to check out ok, and the device node permissions appear to be as expected as well. I’m not sure why ‘lpinfo -v’ doesn’t communicate properly with the device. A regression requiring a bug report IMHO.

If possible can you also check the printer’s operation using another machine (if available), perhaps running Leap, or other OS? No red light up on printer? (I’ve read some anecdotal information that indicates page count can cause issues for some users, but there are ways to correct that if necessary.)

I’ll check and send all the info from Leap 42.3, where the printer works fine.

On Leap 42.3, with working printer

# lpinfo -v
network beh
network http
network lpd
network https
network ipps
direct usb://Samsung/ML-1640%20Series?serial=144QBAHS602380E.
network socket
network ipp
direct hp
network smb

A regression then…time to submit a bug report.

Nope, no red lights. Tha printer works fine on Leap 42.2 and 42.3. And it used to work on TW as well. Just don’t know when it stopped doing so, last time I printed something on it is at least two months ago.

Yes, based on all the diagnostic info derived so far ----> bug report.

Nope, no bug report … After a lot of reading and searching I found out that USB autosuspend was the culprit. Adding

USB_BLACKLIST="04e8:3292"

to /etc/default/tlp solved it. After a reboot the printer was autodetected, ditto configured and works as it should.

EDIT: this was where I found the solution : Printer pauses randomly after upgrade to 16.04 - #52 by mrprobot - Hardware - Ubuntu MATE Community

Good find. I didn’t suspect power management at play. :slight_smile:

Is tlp included by default in openSUSE Tumbleweed? (I don’t have it installed in Leap 42.3)

I wonder if the udev approach is still valid here? For example…

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATR{idProduct}=="3292", ATTR{Power/Control}="on"

References
https://wiki.archlinux.org/index.php…SB_autosuspend
https://www.kernel.org/doc/Documenta…management.txt

Leap doesn’t know /etc/default/tlp .

I had already made some attempts to use a udev rule, though not the one you posted. Will comment the addition in /etc/default/tlp and try yours to see if the result is the same. Probably changes in udev / libusb ??

Nope doesn’t work.