hey there, I've got a HP LaserJet P1102 printer and am running it with hplip via hpcups, plus the binary plugin. emerge -pv hplip [ebuild R ] net-print/hplip-3.20.6-r1::gentoo USE="X hpcups libnotify policykit qt5 snmp -doc -fax -hpijs -kde -libressl -libusb0 -minimal -parport -scanner -static-ppds" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8" 0 KiB with the update from hplip-3.19.12-r1 to 3.20.6-r1 I got an abundance of python3.7 /usr/bin/hp-firmware -y3 -s001:030 in my taskmanager, it causes short cpu spikes and it seems to try all my usb ports and restarts when it got to the end. The processes are owned by root I have no idea where this is coming from, and how to stop it from annoying everyone, but to disconnect the device. It doesn't matter if the device is in standby or on. Where can I start to debug this further?
What is "reinterate"?
that's a typo and it should mean to reiterate these processes keep on spawning out of nowhere, until the device/printer is disconnected python3.7 /usr/bin/hp-firmware -y3 -s001:030 means to use python3.7 to execute hp-firmware, to wait 3 seconds (-y3) and to use usb port 001:030 (-s001:030) and it keeps on trying lots of usb ports, two or three at the same time, causing the cpu spikes every other second I believe this is some kind of unwanted automatic behavior, to possibly upload the firmware to the device
the unstable hplip-3.20.3 is also affected by this behavior
Created attachment 658754 [details] output from emerge --info
the old hplip-3.19.12-r1 didn't show this behavior where can I start to debug this further? I'm not very familiar with how the package works, and also have no idea where their upstream repo lives to be able to check if it already has been fixed in the latest code.
Created attachment 661164 [details] log from dmesg I recently discovered these log spam in dmesg log, can you make any use of it?
I guess you also have the complementary hplip-plugin-3.20.6-r1 installed and not an older version. From looking at the code this command is only executed when a firmware (meaning the plugin) download is required. Adding the maintainer of hplip-plugin as it is affected.
I reverted back to =hplip-3.19.12-r1 with plugins in sync, and still have this problem, though only occasionally and I can't find the trigger for this.
Are you using systemd?
no, I don't use systemd. This is a pure openrc system, as emerge --info tells you :)
(In reply to tt_1 from comment #10) > no, I don't use systemd. This is a pure openrc system, as emerge --info > tells you :) I am just asking because "python3.7 /usr/bin/hp-firmware -y3 -s001:030" is executed by /usr/bin/hp-config_usb_printer. If you don't execute it manually it is only executed by udev rules which I patched out. I just forgot to remove the systemd service which is also running it. Thus the question.
I haven't had a chance to look into this, though I doubt the plugin package is to blame. It basically only installs a bunch of .so libs and firmware blobs. I just wanted to mention that I have another HP LaserJet and I've never seen this problem.
(In reply to Daniel Pielmeier from comment #11) > (In reply to tt_1 from comment #10) > > no, I don't use systemd. This is a pure openrc system, as emerge --info > > tells you :) > > I am just asking because "python3.7 /usr/bin/hp-firmware -y3 -s001:030" is > executed by /usr/bin/hp-config_usb_printer. If you don't execute it manually > it is only executed by udev rules which I patched out. I just forgot to > remove the systemd service which is also running it. Thus the question. I'm using these packages on stable amd64: dev-libs/libgudev sys-fs/udev sys-fs/udev-init-scripts virtual/libudev virtual/udev and openrc ofc but hey, maybe there's some sort of hidden dependency where udev catches the systemd stuff or whatever? I can test any patch you suggest.
Looking at this some more, I can't even figure out how this could possibly be executed automatically if you're not using systemd. Perhaps it's triggered by the GUI stuff? I don't have that enabled here. Just for the avoidance of doubt, could you paste /lib/udev/rules.d/56-hpmud.rules? Maybe you could check the parent process of these processes to see where it is coming from? Also with hp-firmware being written in Python, maybe you could play about with it and determine why it's hanging?
(In reply to James Le Cuirot from comment #14) > Looking at this some more, I can't even figure out how this could possibly > be executed automatically if you're not using systemd. Perhaps it's > triggered by the GUI stuff? I don't have that enabled here. Just for the > avoidance of doubt, could you paste /lib/udev/rules.d/56-hpmud.rules? Maybe > you could check the parent process of these processes to see where it is > coming from? Also with hp-firmware being written in Python, maybe you could > play about with it and determine why it's hanging? I was also thinking in that direction. Could it be that for some weird reason the hplip patches are not installed for you. Given the other bug #740578 you reported were it also seems as if a patch is missing. Can you post the output of one of the following commands to check? With app-portage/gentoolkit: equery f --filter=obj hplip | xargs grep hp-config_usb_printer With app-portage/portage-utils: qlist -C hplip | xargs grep hp-config_usb_printer
Created attachment 662554 [details] output from greping for hp-config_usb_printer (In reply to Daniel Pielmeier from comment #15) > (In reply to James Le Cuirot from comment #14) > > Looking at this some more, I can't even figure out how this could possibly > > be executed automatically if you're not using systemd. Perhaps it's > > triggered by the GUI stuff? I don't have that enabled here. Just for the > > avoidance of doubt, could you paste /lib/udev/rules.d/56-hpmud.rules? Maybe > > you could check the parent process of these processes to see where it is > > coming from? Also with hp-firmware being written in Python, maybe you could > > play about with it and determine why it's hanging? > > I was also thinking in that direction. Could it be that for some weird > reason the hplip patches are not installed for you. Given the other bug > #740578 you reported were it also seems as if a patch is missing. > > Can you post the output of one of the following commands to check? > > With app-portage/gentoolkit: > equery f --filter=obj hplip | xargs grep hp-config_usb_printer > With app-portage/portage-utils: > qlist -C hplip | xargs grep hp-config_usb_printer sorry for the delay, I had to find out how to turn the output into english :o I can't find that much usefull in there, will add the udev rule as well
Created attachment 662557 [details] hpmud udev rules these are my udev rules but aren't these the same for every install out there? Or are they generated individually?
(In reply to tt_1 from comment #16) > Created attachment 662554 [details] > output from greping for hp-config_usb_printer > > (In reply to Daniel Pielmeier from comment #15) > > (In reply to James Le Cuirot from comment #14) > > > Looking at this some more, I can't even figure out how this could possibly > > > be executed automatically if you're not using systemd. Perhaps it's > > > triggered by the GUI stuff? I don't have that enabled here. Just for the > > > avoidance of doubt, could you paste /lib/udev/rules.d/56-hpmud.rules? Maybe > > > you could check the parent process of these processes to see where it is > > > coming from? Also with hp-firmware being written in Python, maybe you could > > > play about with it and determine why it's hanging? > > > > I was also thinking in that direction. Could it be that for some weird > > reason the hplip patches are not installed for you. Given the other bug > > #740578 you reported were it also seems as if a patch is missing. > > > > Can you post the output of one of the following commands to check? > > > > With app-portage/gentoolkit: > > equery f --filter=obj hplip | xargs grep hp-config_usb_printer > > With app-portage/portage-utils: > > qlist -C hplip | xargs grep hp-config_usb_printer > > > sorry for the delay, I had to find out how to turn the output into english :o > > I can't find that much usefull in there, will add the udev rule as well Nothing wrong with your output. Looks like mine. I am lost here! Another thing to check. Did you at one point in time manually install hplip from it's homepage. Eventually there are some leftovers which are causing problems.
I'm kind of optimistic this is fixed in hplip-3.20.9-r3, I only need more time for testing to beef up my confidence in the hplip+plugin combination. I believe it's been either an undetectable bug in the hplip-plugin, or it's caused by the plugin requirement turned off for my printer, and that confused all the hplip-* stuff. This is reverted with the latest patchset. /me marks bug as 'in progress' if he was able to
this is fixed with hplip-3.20.9-r3, I've tested with gui and without gui, also with both python3_7 and python3_8 you think this is worth a seperate stable bug?
(In reply to tt_1 from comment #20) > this is fixed with hplip-3.20.9-r3, I've tested with gui and without gui, > also with both python3_7 and python3_8 > > you think this is worth a seperate stable bug? Are you really sure it it also still does not work with the old version. I am not sure if anything changed in that regard! Just curious! Will open a stable request soon!
> Are you really sure it it also still does not work with the old version. I > am not sure if anything changed in that regard! Just curious! > > Will open a stable request soon! yeah, I think it's worth a new bug because other users with the same inital problem can't find this bug anymore, if it has been renamed. can you please rephrase your statement above? I don't understand! :-/
(In reply to tt_1 from comment #22) > > yeah, I think it's worth a new bug because other users with the same inital > problem can't find this bug anymore, if it has been renamed. Of course renaming was never an option! > can you please rephrase your statement above? I don't understand! :-/ What I meant is, maybe now it also works with the old version for no reason!
FYI stabilisation is tracked in bug #754072.
