[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#982742: marked as done (cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!))



Your message dated Tue, 16 Feb 2021 11:47:51 +0000
with message-id <16022021114620.5425ee44e45e@desktop.copernicus.org.uk>
and subject line Re: Bug#982742: solved
has caused the Debian Bug report #982742,
regarding cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
982742: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982742
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: cups
Version: 2.3.3op2-3
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I tried to install an USB printer (oki B432).

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
localhost:631/administration -> new printer

   * What was the outcome of this action?

The printer is not listed anymore and thus I cannot select the neccesary ppd-
file, which used to work this way years ago (2017-2019/20). It still works
*reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
installation it does not work anymore:

Investigating this on my computer I found the following:

 # uname -r
5.10.0-3-amd64

printer switched off:

# lsmod | grep usb
usbhid                 65536  0
hid                   147456  2 usbhid,hid_generic
usbcore               323584  6
ehci_pci,usbhid,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common             16384  3 usbcore,ehci_hcd,uhci_hcd

# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 98 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=8


printer switched on:

# lsmod | grep usb
usblp                  28672  0
usbhid                 65536  0
hid                   147456  2 usbhid,hid_generic
usbcore               323584  8
ehci_pci,usbhid,usblp,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common             16384  3 usbcore,ehci_hcd,uhci_hcd

# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 98 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=9
DEBUG: Failed to detach "usblp" module from 06bc:0357

or

# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 95 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=9
DEBUG: Switching USB device configuration: 0 -> 1
DEBUG: Failed to set configuration 1 for 06bc:0357
DEBUG: Failed to set alternate interface 0 for 06bc:0357: Connection timed out


The difference I can't explain except for the following facts:

Today I downgraded cups and relatives to the version (cups_2.3.3-1_amd64.deb)
of the above Live_ISO. I added a missing package (libusbredirparser1).
Initially it worked, i.e. the printer was visible and installable in the web
admin panel after reloading the page some times. In the printing menue (for
example libreoffice) the printer showed up once. After rebooting and updating
the printer showed up with two slightly different names in the menues, and did
not show up in the administration anymore. I updated, used different kernels,
downgraded again. No more printer in the admin panel list. ***This is a
longstanding problem, not just today!***

I still reliably can install and use the printer using the above mentioned
live-ISO, but with my real installation, the few times I get it installed, it
does not work, as cups is "waiting for the printer becomming available"
(according to the cups job list), whereas the printer shows "ready to print" in
its LED panel.

To it seams usblp and libusb are blocking each other and/or there are timing
issues.

Any help or fix is very appreciated. If needed I could test. But my "skills"
are rather limited.


   * What outcome did you expect instead?

Obviously I would like to install and configure my printer to then be able to
print

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client            2.3.3op2-3
ii  cups-common            2.3.3op2-3
ii  cups-core-drivers      2.3.3op2-3
ii  cups-daemon            2.3.3op2-3
ii  cups-filters           1.28.7-1
ii  cups-ppdc              2.3.3op2-3
ii  cups-server-common     2.3.3op2-3
ii  debconf [debconf-2.0]  1.5.74
ii  ghostscript            9.53.3~dfsg-7
ii  libavahi-client3       0.8-5
ii  libavahi-common3       0.8-5
ii  libc6                  2.31-9
ii  libcups2               2.3.3op2-3
ii  libgcc-s1              10.2.1-6
ii  libstdc++6             10.2.1-6
ii  libusb-1.0-0           2:1.0.24-2
ii  poppler-utils          20.09.0-3.1
ii  procps                 2:3.3.17-2

Versions of packages cups recommends:
ii  avahi-daemon  0.8-5
ii  colord        1.4.5-3

Versions of packages cups suggests:
pn  cups-bsd     <none>
pn  cups-pdf     <none>
ii  foomatic-db  20200820-1
ii  smbclient    2:4.13.4+dfsg-1
ii  udev         247.3-1

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd

--- End Message ---
--- Begin Message ---
On Tue 16 Feb 2021 at 09:37:03 +0300, Alexander Pevzner wrote:

> On 2/16/21 4:31 AM, mh wrote:
> > comparing avahi settings was much less pain then I expected.
> 
> Congratulations!
> 
> > had an active (non commented out) line:
> > 
> > allow-interfaces=eth9
> 
> Which effectively protected Avahi from being working on all another
> interfaces, including the loopback interface.
> 
> Nice that this problem has been finally solved.
> 
> -- 
> 
> 	Wishes, Alexander Pevzner (pzz@apevzner.com)

--- End Message ---

Reply to: