Description of problem: Since updating to hplip 3.22.6, if I boot with a usb-connected printer powered up, that printer shows a "device communication error" in the HP device manager. If, however, I boot with the printer(s) powered down, then power them up later, That communication error does not occur. If I boot with the printer powered up, then power it down and back up, I still get the communication error. I have three HP printers. The newest is a Envy Photo 7858 all-in-one. Next-newest is a Color Laserjet CP1215. The oldest is a Deskjet 5650. It's no hardship for me to boot with the first two powered down, and in fact I do that when not using them. The Deskjet isn't so easy. The printer switch puts it into standby mode, rather than powering it off. I have put a switch into the line, so that I can power it off, again, not exactly a hardship, for me. But, I can imagine situations where a user would not want to power off his printer. In those situations, this issue can be very annoying.
In addition, I have determined that booting with the Deskjet printer powered up and on standby greatly increases boot time over when booting with power to the printer switched off. My system uses an SSD boot drive, and normally boots in a few seconds. But, if the Deskjet is powered before the boot, boot time goes to what seems like well over a minute. It did not do this before the update to hplip 3.22.6. I will attach two text files. Bootfast.txt is a normal boot, while bootslow.txt is a slow one. Watching the display as it boots, the delay is occurring before control is handed off to sddm.
Created attachment 13330 [details] Journal of a normal, fast boot
Created attachment 13331 [details] Journal of a slow boot with Deskjet powered up
Please try "rpm -e --nodeps xsane xsane-gimp" and see if that fixes the problem. I'm suggesting this as the slow boot has a 58 second delay right before the line python3[707]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=0, index=1 A search for "io/hpmud/musb.c 427" indicates it part of saned. If that fixes the issue then it may be an xsane problem rather then an hplip problem, even if the update to hplip is what triggered it's showing up now.
CC: (none) => davidwhodgins
Another suggestion no related to this bug, to speed up the boot. Add a line with HARDDRAKE_ONBOOT=no to /etc/sysconfig/system, and manually run harddrake2 any time you add hardware.
Regarding Comment 4, this is my production install and I am reluctant to remove xsane and/or xsane-gimp, as I use them semi-regularly with the all-in-one printer from Comment 0. It also seems odd that applying or removing power to the Deskjet would make a difference with xsane, as that is a printer-only, with no scanning capability. I'm not on that computer right now, but last night I did do a boot with "splash quiet" removed from the boot options, and with the Deskjet receiving power. There was a delay at one point, something about waiting for udev, that had a limit of over two minutes possible. It didn't last that long, and the boot as a whole was not as long as it has been, but not as short as was normal before the hplip update. I didn't see any other delays during the boot. https://bugs.mageia.org/show_bug.cgi?id=10072#c68 indicates that fixing that bug involved a change in udev rules. Perhaps that is the cause. When I get back to that computer again I will try booting that way again, and report back here.
OK, another boot on the machine with the issue, and again there was a delay at the same point. I paid better attention this time, and it was a "start job" for udev to initialize hardware, with a potential limit of 2 minutes 59 seconds. (Why not 3 minutes? A conundrum.) I watched, and at around 58 or 59 seconds, it completed and the boot proceeded normally.
Another boot, this time with power removed from the Deskjet, and the other printers shut down. This time I did see the "start job" message, but it came and went too quickly to read anything more than that.
I should have made it clear. Remove xsane to see if it is the cause or not. Re-install it once that's been determined.
Since the update my HP Deskjet 930c powers up when the PC boots and cannot be powered down until the PC shuts down.
CC: (none) => I027614
(In reply to Dave Hodgins from comment #9) > I should have made it clear. Remove xsane to see if it is the cause or not. > Re-install it once that's been determined. It doesn't look like it, but the issue has become more cloudy than ever. Before removing xsane, I booted a 2-3 times, watching for the delay. It was there twice, and once was not. Then I removed xsane, and tried again. No delay on the first boot, and when I checked the Device Manager(DM) the Deskjet had the communication error. Another boot after a short pause, and the delay was there - and no communication error in the DM for the deskjet. I repeated this several times, with the same result. Sometimes there was a udev delay, sometimes not. When there was, the DM communicated with the Deskjet, and when there was no delay it didn't. Re-installing xsane now...
Trying to clarify; is this right (printer on at boot)? - If you get the long delay on booting, there is no "device communication error" in the HP device manager. - If you do not get the long booting delay, you do get the preceding error.
CC: (none) => lewyssmith
@Lewis: That's what I have observed so far with the Deskjet 5650. I have not tried my other printers individually yet.
Hello For information, I have exactly the same problem on a friend's PC with an HP printer. To get around the abnormally long boot time, the easiest way is to turn off the printer. Note that the printer is well recognized once the boot is done. It works correctly.
CC: (none) => jeanmichel.varvou
Created attachment 13337 [details] Result of journalctl -b -p err > /tmp/tracejlb.txt
Thank you both for your similar evidence. Assigning this to Nicolas S who put up version 3.22.6 (& earlier ones). Please re-assign it if you see the need.
Assignee: bugsquad => nicolas.salgueroCC: lewyssmith => (none)Source RPM: (none) => hplip-3.22.6-1.mga8.src.rpm
I tried booting with my Envy Photo 7858 powered up and in standby. Long delay, and once booted no error in the DM. Speculation follows. Please feel free to correct any misconceptions I have there. My gut feeling is the long delay is being caused by udev repeatedly trying to upload firmware to printers that don't require it, eventually moving on. I can see, possibly, where a delay for a printer that needs the firmware might be necessary, but for those printers that don't there ought to be a way to shorten it. Some older, slower printers like my Deskjet 5650 (usb 1.1, I believe) may take longer sometimes to "wake up" than others, don't respond to udev quickly enough, so udev believes they are offline. That may be why sometimes it works one way, sometimes another.
Keywords: (none) => FOR_ERRATA9
CC: (none) => epp
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=31007
Hi, Does the problem still occur with hplip-3.22.10-1.mga9? Best regards, Nico.
(In reply to Nicolas Salguero from comment #18) > Hi, > > Does the problem still occur with hplip-3.22.10-1.mga9? > > Best regards, > > Nico. Yes. (Sorry to take so long to answer.)
Hi, With hplip-3.22.10-2.mga9, I reverted back to the previous behaviour, which was the cause of bug 10072. Does it works better? Best regards, Nico.
With regard to the Deskjet 5650 and the Color Laserjet CP1215, the status in the HP Device Manager has returned to what it was before. If you boot with the devices turned on, they show up in the Device Manager as "idle." If you boot with them powered down, they both show a "communication error" which will switch to "idle" when the devices are powered on. With regard to the Envy Photo 7858, results are mixed. In the real hardware install used for the test, somewhere along the line I had installed HP FAX, and that device shows in the device manager with the others. That device behaves as do the two above printers. The printer part of the 7858 is different. If you boot with the device powered up but in sleep mode, the DM status is "busy, powered down, or unplugged." Waking the device up does not change the status, and the DM cannot communicate with it for other functions. If you boot with the device powered down, DM reports a communication error. Powering it up changes that to "idle" but when the printer drops into sleep mode it changes to busy, etc and will not change regardless of the actual status of the device. When it shows as "idle" the DM can get information with regard to ink levels, etc. If you boot with the device powered up and awake, The DM shows the "busy, etc." status. This is all with already-installed printers. I didn't think until just now to try removing the 7858 and re-installing it.
I've been doing a lot of printing with M8 lately, and have forgotten a few times to switch off the printer when done with it that session. I am still using hplip-3.22.10-2. Somewhere along the way, the system has reverted to reporting a device communication error for the printer if you boot with it powered up, but not if you boot with the printer powered down and power it up once the boot is finished. However, the occasional long boot is still gone, and the behavior is now consistent.
Still valid? What to write in errata?
CC: (none) => fri
Mageia 9 is currently using hplip 3.22.10-4. I'm not seeing this issue any more with my two usb-only printers, a Deskjet 5650 and a Color Laserjet CP1215. My third HP printer, a Envy Photo 7858, is now connected to my network through wifi. Going by information from Bug 31623, if this printer were connected through usb, it might still show the issue unless the recommended-but-not-required ipp-usb package were removed, due to conflicts between hplip and ipp-usb for Airprint-capable printers. If necessary, changing my hardware setup to test that speculation would be difficult, but not impossible.
OK thanks Entered https://wiki.mageia.org/en/Mageia_9_Errata#Printing IF we find it not an issue anymore we can delete it later
Keywords: FOR_ERRATA9 => IN_ERRATA9
Assignee: nicolas.salguero => pkg-bugs
We stopped supporting Mageia 8 almost 8 months ago https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/ That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not. If this particular bug did not get fixed for Mageia 8, then we do regret that. If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field. If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing Mageia is a community project, meaning that we, the users, make Mageia together. The more active contributors we have, the more bug reports will get fixed. Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D
Status: NEW => RESOLVEDResolution: (none) => OLD