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

Bug#745411: marked as done (hplip: hplip_config_usb_printer producing kernel "Call Trace")



Your message dated Mon, 30 Jul 2018 19:28:51 +0100
with message-id <30072018192402.2a6ab50ca412@desktop.copernicus.org.uk>
and subject line Re: Bug#745411: hplip: hplip_config_usb_printer producing kernel Call Trace
has caused the Debian Bug report #745411,
regarding hplip: hplip_config_usb_printer producing kernel "Call Trace"
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.)


-- 
745411: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745411
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: hplip
Version: 3.14.1-1
Severity: normal

And this is what is logged:

Apr 20 13:04:22 debian kernel: [162198.348002] INFO: task hp-config_usb_p:6065 blocked for more than 120 seconds.
Apr 20 13:04:22 debian kernel: [162198.348005]       Tainted: P           O 3.13-1-amd64 #1
Apr 20 13:04:22 debian kernel: [162198.348006] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 20 13:04:22 debian kernel: [162198.348008] hp-config_usb_p D ffff88040b54cb40     0  6065      1 0x00000080
Apr 20 13:04:22 debian kernel: [162198.348011]  ffff88040b54c800 0000000000000086 0000000000014280 0000000000014280
Apr 20 13:04:22 debian kernel: [162198.348014]  ffff880036b4bfd8 ffff88040b54c800 ffffffffa03a6040 ffff880036b4be78
Apr 20 13:04:22 debian kernel: [162198.348016]  ffffffffa03a6044 ffff88040b54c800 00000000ffffffff ffffffffa03a6048
Apr 20 13:04:22 debian kernel: [162198.348018] Call Trace:
Apr 20 13:04:22 debian kernel: [162198.348033]  [<ffffffff814a45d0>] ? schedule_preempt_disabled+0x20/0x70
Apr 20 13:04:22 debian kernel: [162198.348036]  [<ffffffff814a6043>] ? __mutex_lock_slowpath+0x133/0x1b0
Apr 20 13:04:22 debian kernel: [162198.348040]  [<ffffffff814a60d6>] ? mutex_lock+0x16/0x25
Apr 20 13:04:22 debian kernel: [162198.348043]  [<ffffffffa03a42d0>] ? pp_ioctl+0x20/0x870 [ppdev]
Apr 20 13:04:22 debian kernel: [162198.348047]  [<ffffffff8118b94f>] ? do_vfs_ioctl+0x2cf/0x4a0
Apr 20 13:04:22 debian kernel: [162198.348048]  [<ffffffff8118bba0>] ? SyS_ioctl+0x80/0xa0
Apr 20 13:04:22 debian kernel: [162198.348052]  [<ffffffff814aeb79>] ? system_call_fastpath+0x16/0x1b

All this started to show up while testing a udev-rule to mount a
filesystem on a USB-stick connected to an usb-port in a hub built into
"HP Compaq LA2405x" monitors.  I used:

	# udevadm trigger --action=add /dev/sdg

which activates the rules in:

	/lib/udev/rules.d/56-hpmud.rules

That rules run /usr/bin/hp-config_usb_printer on usb devices which
seem to be scanners (Device: ID 03f0:2512):

	Bus 004 Device 004: ID 03f0:2512 Hewlett-Packard OfficeJet Pro L7300
	Bus 003 Device 005: ID 03f0:2512 Hewlett-Packard OfficeJet Pro L7300

but they are not.  They are usb-hubs that built into "HP Compaq
LA2405x" monitors.  Seen the forked processes:

	root      6065  0.0  0.0 126856 15076 ?        D    12:53   0:00 /usr/bin/python /usr/bin/hp-config_usb_printer 003:005
	root      6074  0.0  0.0 126856 15072 ?        S    12:53   0:00 /usr/bin/python /usr/bin/hp-config_usb_printer 004:004

Took a look at:

	# ls -al /proc/6074/fd
	total 0
	dr-x------ 2 root root  0 Apr 20 13:17 .
	dr-xr-xr-x 9 root root  0 Apr 20 12:53 ..
	lrwx------ 1 root root 64 Apr 20 13:17 0 -> /dev/null
	lrwx------ 1 root root 64 Apr 20 13:17 1 -> /dev/null
	lrwx------ 1 root root 64 Apr 20 13:17 13 -> socket:[3215190]
	lrwx------ 1 root root 64 Apr 20 13:17 2 -> /dev/null
	l-wx------ 1 root root 64 Apr 20 13:17 3 -> /root/.hplip/hplip_config_usb_printer.log
	lr-x------ 1 root root 64 Apr 20 13:17 4 -> /dev/parport0

and:

	# ls -al /root/.hplip/hplip_config_usb_printer.log
	-rw-r----- 1 root root 0 Apr 20 12:53 /root/.hplip/hplip_config_usb_printer.log

Killing the processes:

	# kill -9 6074 6065

silences the kernel.

It shows up this is a problem reported here too:

	https://bugs.launchpad.net/hplip/+bug/1266704

that even has a partial solution (This fix is released in HPLIP-3.14.3):

	https://bugs.launchpad.net/hplip/+bug/1266704/comments/5

since 2014-03-13.  Debian might consider a package upgrade.  Still...

That bug report states "Usb device 003:004 is HP Smart Card Terminal
keyboard and Usb device 003:005 is HP mouse".

It seems the matching rule:

	ATTR{idVendor}=="03f0", ATTR{idProduct}=="????",

in 56-hpmud.rules is _far_ too generous.  I made a few attempts to
find ways to blacklist the 03f0:2512 devices.  Came up with this one:

,----[ /etc/udev/rules.d/10-hpmud-blacklist.rules ]
| ACTION!="add|change", GOTO="hpmud_blacklist_rules_end"
| SUBSYSTEM!="usb", GOTO="hpmud_blacklist_rules_end"
| ENV{DEVTYPE}!="usb_device", GOTO="hpmud_blacklist_rules_end"
|
| ATTR{idVendor}=="03f0", ATTR{idProduct}=="2512", ENV{ID_MM_DEVICE_IGNORE}:="1", RUN:="/usr/bin/logger -p info -t 10-hpmud-blacklist.rules -- ignore %N, /sys%p"
|
| LABEL="hpmud_blacklist_rules_end"
`----

But that doesn't stop /lib/udev/rules.d/56-hpmud.rules from doing it's
thing :(, when:

	# udevadm trigger --action=add /dev/sdg

The only way I found in to avoid that is to modify 56-hpmud.rules:

	 LABEL="hpmud_usb_rules"

	+# "03f0:2512 Hewlett-Packard OfficeJet Pro L7300" is an USB hub
	+# integrated into an HP Compaq LA2405x monitor, on my system
	+ATTR{idVendor}=="03f0", ATTR{idProduct}=="2512", PROGRAM="/bin/sh -c 'logger -p info -t 56-hpmud.rules -- skipping HP Device $env{BUSNUM} $env{DEVNUM}'", GOTO="hpmud_rules_end"

which works, but is obviously not ideal (as editing distributed conf-files
is unsustainable).

Is there _any_ standard procedure I could use instead, to avoid
mangling 56-hpmud.rules?


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

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages hplip depends on:
ii  adduser                3.113+nmu3
ii  coreutils              8.21-1.2
ii  cups                   1.7.2-1
ii  hplip-data             3.14.1-1
ii  libc6                  2.18-4
ii  libcups2               1.7.2-1
ii  libdbus-1-3            1.8.0-3
ii  libhpmud0              3.14.1-1
ii  libsane                1.0.24-1.1+b1
ii  libsane-hpaio          3.14.1-1
ii  libsnmp30              5.7.2.1~dfsg-3
ii  libssl1.0.0            1.0.1g-3
ii  libusb-1.0-0           2:1.0.18-2
ii  lsb-base               4.1+Debian12
ii  policykit-1            0.105-4
ii  printer-driver-hpcups  3.14.1-1
ii  python                 2.7.5-5
ii  python-dbus            1.2.0-2+b2
ii  python-gobject-2       2.28.6-12+b1
ii  python-imaging         2.3.0-2
ii  python-pexpect         3.1-1
ii  python-reportlab       3.0-1
ii  wget                   1.15-1

Versions of packages hplip recommends:
ii  avahi-daemon                  0.6.31-4
pn  printer-driver-postscript-hp  <none>
ii  sane-utils                    1.0.24-1.1+b1

Versions of packages hplip suggests:
pn  hplip-doc              <none>
ii  hplip-gui              3.14.1-1
ii  python-notify          0.1.1-3
ii  system-config-printer  1.4.3-4

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/udev/rules.d/56-hpmud.rules (from hplip package)


Cheers,

-- 
Cristian

--- End Message ---
--- Begin Message ---
tags 745411 - moreinfo
thanks


On Mon 30 Jul 2018 at 18:28:28 +0200, Cristian Ionescu-Idbohrn wrote:

> On Mon, 30 Jul 2018, Brian Potkin wrote:
> > 
> > tags 745411 moreinfo
> > thanks
> > 
> > On Mon 21 Apr 2014 at 14:50:36 +0200, Cristian Ionescu-Idbohrn wrote:
> > > 
> > > Is there _any_ standard procedure I could use instead, to avoid
> > > mangling 56-hpmud.rules?
> > 
> > It doesn' appear so; at least, no one has come up with anything. Does
> > the changed behaviour in hplip 3.14.3 and later (a test with unstable)
> > address your issue in any significant way?
> 
> I have not seen this bug in more than 4 years.  What fixed it?  I 
> don't know, though 56-hpmud.rules looks significantly different now.
> 
> Please close this bug.  No longer an issue for me.

Thank you for the timely and informative response. Closing.

Cheers,

Brian.

--- End Message ---

Reply to: