Can this bug report remain unresolved, pending resolution of HDD issue? I just ran GSmartControl and found this in the log:

SMART Extended Comprehensive Error Log Version: 1 (6 sectors)
Device Error Count: 87 (device log contains only the most recent 24 errors)
	CR     = Command Register
	FEATR  = Features Register
	COUNT  = Count (was: Sector Count) Register
	LBA_48 = Upper bytes of LBA High/Mid/Low Registers ]  ATA-8
	LH     = LBA High (was: Cylinder High) Register    ]   LBA
	LM     = LBA Mid (was: Cylinder Low) Register      ] Register
	LL     = LBA Low (was: Sector Number) Register     ]
	DV     = Device (was: Device/Head) Register
	DC     = Device Control Register
	ER     = Error register
	ST     = Status register
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 87 [14] occurred at disk power-on lifetime: 1472 hours (61 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 00 00 00 00 00 18 08 e0 00  Error: UNC at LBA = 0x00001808 = 6152

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  c8 00 00 00 20 00 00 00 00 18 00 e0 0a     00:01:58.545  READ DMA
  ea 00 00 00 00 00 00 25 42 ea af e0 0a     00:01:58.545  FLUSH CACHE EXT
  27 00 00 00 00 00 00 00 00 00 00 e0 0a     00:01:58.544  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 00 00 00 00 00 a0 0a     00:01:58.542  IDENTIFY DEVICE
  ef 00 03 00 46 00 00 00 00 00 00 a0 0a     00:01:58.540  SET FEATURES [Set transfer mode]

Thanks for the report.
> Here is the output from hp-doctor
(This very long report would have been better as an attachment).

> Can this bug report remain unresolved, pending resolution of HDD issue?
Done.

Using Gsmartcontrol on a suspect disc recently, after ruuning the *long* smartctl self test, it immediately said the disc was on its way out, panick!

Ever confirmed: 1 => 0
CC: (none) => lewyssmith
Status: NEW => UNCONFIRMED

(In reply to Lewis Smith from comment #2)
> Thanks for the report.
> > Here is the output from hp-doctor
> (This very long report would have been better as an attachment).
> 
> > Can this bug report remain unresolved, pending resolution of HDD issue?
> Done.
> 
> Using Gsmartcontrol on a suspect disc recently, after ruuning the *long*
> smartctl self test, it immediately said the disc was on its way out, panick!

The HDD was indeed failing. Bought my first, ever, solid state drive today. Installed Mageia 8 on it then converted it to Cauldron.

The base install (before online updates) took all of nine minutes. Rebooted after the online update and the boot took 17 seconds from Grub2 to the login screen.

And this is on a 13-year old desktop...  :)

HPLIP is still displaying the "communication error". One minute it displays that, then the next minute it's fine. I've done everything I can think of, from deleting the printers in the CUPS interface then adding them back in with HPLIP, to factory-resetting the 3830 (the D1660 cannot be factory reset), to replacing the USB cables.

What I do know, is when HPLIP displays "communication error", running "lsusb -v" displays both printers, Mageia *is* recognizing them, so it's not a USB problem. This is leading me to believe that there is likely a bad file in the HPLIP package somewhere.

Lewis,

I *may* have found a workaround to this, but want to test it for a few days, before deciding whether to close this bug report.

Working with my HP OfficeJet 3830 (all-in-one), I deleted everything via the CUPS web interface. Then added the 3830 back via CUPS. But this time, rather than selecting the HP PPD file for the printer, I selected "IPP Everywhere"  (https://www.pwg.org/ipp/everywhere.html), which allows computers and mobile devices to find and print to networked and USB printers, without the need for vendor-specific software.

So far, it's working. The HP Device Manager is showing no HP printers connected, test prints from Thunderbird and the web browsers print successfully and Document Scanner (simple-scan) is seeing the device and is able to scan.

Going into MCC/Hardware/Printers, the printer entry icon is a network printer, instead of a local printer.

Thank you for all the work you have put into this (which, however, no-one else could have done). You seem to have got very bogged down in HPLIP. Congratulations on your hopeful solution.

What you say above about "IPP Everywhere" looks important. I have no experience of using CUPS to configure a printer, rather always via our MCC and Manage Printer applications. It seems that your printers are USB. Can you say whether you could have achieved the same result using Mageia's "Add printer"?
(I did not get anywhere trying to add my USB printer as a network one: fell at the first fence over a URI).

CC'ing TJ to see what he thinks about this. He has, I think, HP experience.

CC: (none) => andrewsfarm

This sounds like the same issue as Bug 30626. 

With that bug, if I boot with my HP printers powered up, more often than not I will get the "communication error" message. Sometimes, there will be a long delay in the boot, and then there will be no error. If I power them up after the boot, there is no problem.

This issue remains unresolved. My workaround is to power down my printers when not using them. One printer, an almost ancient Deskjet 5650, does not power down with the switch - it only goes to sleep. With that one, I installed an inline switch before the power supply. I actually have no problem with this, as I use my printers irregularly, and removing power from them when not using them saves me a few pennies on my electric bill.

Your solution of forcing the printer to be a network printer is interesting, as I had determined that what I saw only affected usb-connected printers.

(In reply to Lewis Smith from comment #5)
> Thank you for all the work you have put into this (which, however, no-one
> else could have done). You seem to have got very bogged down in HPLIP.
> Congratulations on your hopeful solution.
> 
> What you say above about "IPP Everywhere" looks important. I have no
> experience of using CUPS to configure a printer, rather always via our MCC
> and Manage Printer applications. It seems that your printers are USB. Can
> you say whether you could have achieved the same result using Mageia's "Add
> printer"?
> (I did not get anywhere trying to add my USB printer as a network one: fell
> at the first fence over a URI).
> 
> CC'ing TJ to see what he thinks about this. He has, I think, HP experience.

Most likely, the IPP Everywhere option would not be available using MCC to configure the printer as it appears to communicate in sone way with HPLIP, as I found the printer listed in HPLIP after using the MCC.

I also have an older Deskjet D1600 and although it can be added via CUPS, MCC and HPLIP, the IPP Everywhere option was not available for this model in CUPS, so I ended up disconnecting it, since there is no way to access the printer maintenance (align cartridges, clean, etc.) outside of HPLIP with this model.

Apparently, when CUPS configured the OfficeJet 3830 with IPP Everywhere, it showed up as a networked printer in MCC, even though it's USB-connected.

(In reply to Thomas Andrews from comment #6)
> This sounds like the same issue as Bug 30626. 

What I had been seeing was when HPLIP installed the printer and I selected to send aprint test page, that was fine. The second I opened the HPLIP GUI (Device Manager), it immediately threw up the communication error.

The printer was powered on during all this.

According to HP's support page, your Officejet has wireless connectivity, so that is what's being used to make it a network printer, even though the usb cable is connected. That is why the "IPP Everywhere" trick worked. One of my printers can be used like that, but the others cannot.

Please try this with the Deskjet: Boot with the printer connected, but powered down. Once booted, power up the printer and use MCC to install it. You can print a test page from MCC if you want, but don't try the HP Gui just yet. Reboot with the power removed from the printer. (It's possible that your Deskjet may be like mine, and is never really powered down unless the power supply is disconnected from the power source.) Once booted, power up the printer, and try the HP GUI again. (With my printers, the device communication error will be gone. I'm hoping the same will be true for you.)

The printer is successfully connected and working, so I would prefer to leave it as it is.

Wireless is turned off at the printer and I use MAC Filtering on my Internet gateway. As the printer's MAC address is not in the filter, there is no way for it to connect via wireless.

I meant to perform the test with the older D1600. The way I was reading it, you did not have that one working. I would not ask you to mess around with one that is working.

My HP Envy Photo 7858 allows the computer to communicate directly with the printer's wireless, bypassing the router and Internet. I had thought that's what happened with you, but it shouldn't if the printer's wireless is turned off. I think. My only experience with wireless printers is with the one HP Envy.

The D1600 installed successfully via the MCC, selecting USB for the connection, instead of HPLIP. Removed power from the printer and rebooted. Restored power to printer.

Launched HP GUI, it crashed.

From terminal:

~]$ hp-toolbox

HP Linux Imaging and Printing System (ver. 3.22.6)
HP Device Manager ver. 15.0

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

\Segmentation fault (core dumped)
[epp@downstairs ~]$ coredumpctl
No coredumps found.

Well, it would seem that your issue is not the same, though the symptoms are somewhat similar.

That exhausts any help I can give. All of my printers, when I used MCC, have been installed with the "hplip" option. I don't remember ever trying the "usb" option, because all my printers are HP. And I'm not a developer by any definition of the term, so getting into the guts of hplip is beyond me.

I am sorry I couldn't be of more assistance.

You were very helpful!

@Edward
> The D1600 installed successfully via the MCC, selecting USB for the
> connection, instead of HPLIP. Removed power from the printer and rebooted.
> Restored power to printer.
You did not say whether it worked before the HPLIP crash...

In particular, does TJ's simple suggestion that troublesome HP printers are powered off for boot, then powered on, whence they work OK, work for you?
If so, this will be 'for errata'.

Likewise your suggestion about "IPP Everywhere".

I find this mixture of MCC, CUPS, HPLIP for installing HP printers a worms' nest. I have never had affair with HPLIP over many years (but no HP printer).

The printer, installed using HPLIP, worked before the hplip segfaults, as long as I left the GUI alone. As soon as I launched the GUI, pre-segfault, it threw up the 'communication error'. As long as the 'communication error' was there, the printer would not print.

IPP Everywhere is apparently not compatible with every printer. Occasionally, I would see a message in the CUPS interface that printer drivers and one other item would be deprecated in a future version of CUPS. I do not know what that would mean for printers like the D1600.

The D1600 otherwise works if installed independently of HPLIP, using USB as the connection from within MCC.

I do not believe the current HPLIP version is incompatible with Mageia Cauldron/9. My other desktop (Mageia 8 host, Cauldron VBox guests) has a different HP printer, but is Ethernet-connected. 'hp-setup -a <IP address>' successfully set it up in all three of the Cauldron VBoxes and I have had zero issues.

I still believe this is at least related to the issue I saw in Bug 30626. Unfortunately, I also believe it is an upstream bug, and we will probably have to wait for a new version of hplip before it might be fixed.

As for older printers like your D1600, and all of mine, while they don't usually drop the printers from the list of support, once the hplip developers have decided that there is "full" support for them they rarely revisit the ppds to fix any bug that might be there. However, this doesn't act like a ppd issue, because it seems to involve many printers, so there is still a chance they will look into it.

Over the years, I reported a grand total of two bugs to HPLIP, the oldest was in 2016. As of today, neither bug has been acknowledged or commented on by anyone from HP. I don't report bugs to them anymore.

> The D1600 otherwise works if installed independently of HPLIP,
> using USB as the connection from within MCC.
Thank you for this encouraging news!
This bug looks very much an HPLIP problem; if the dropping printers are added via MCC or CUPS; or only powered on after booting; they work. Please correct if this is wrong.

Flagging for ERRATA.

Assigning to NicolasS. although HPLIP is not your baby, you are its main maintainer.

Ever confirmed: 0 => 1
Keywords: (none) => FOR_ERRATA9
Status: UNCONFIRMED => NEW
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=30626
Assignee: bugsquad => nicolas.salguero

Hi,

Does the problem still occur with hplip-3.22.10-1.mga9?

Best regards,

Nico.

Ping Edward. When you have time.

I finally got the time to make a real hardware install of Cauldron, with printers attached, and I am seeing the same problem with my printers and hplip 3.22.10 that Edward saw with his printers.

I have three HP printers, a venerable Deskjet 5650, a Color Laserjet CP1215, and an Envy Photo 7858 all-in-one. 

The Deskjet is capable of usb or parallel; I'm using usb. The Laserjet is usb-only. Both were installed using system-config-printer from MCC, choosing hplip. Both of these are working as they do in Mageia 8. If I boot with them powered down, then power up after, the HP gui seems to communicate with them OK. If I boot with them powered up, The HP gui shows a "communication error" until I power them down, refresh the devices, power them up again, and refresh again.

They will print OK, whether the HP gui can communicate with them or not.

As with Edward's Officejet, my Envy can be used with usb or wireless.(wifi) It is connected to my router, but I installed the Envy in MCC using the usb connection and hplip. When I went to look at it in the hp gui, I was told the status was "busy, (BLAST! I forgot this one), or unplugged." If I tried to print with it, and I was presented with a number of options, the one that included "IPP Anywhere" was the only one that worked. 

And if I tried the scanner, the only device out of three choices that would work is the "airscan" option. That includes an IP address, so one would think it is directly accessing the printer's wireless connection - except that the IP address is not the one my router gave the printer, AND this desktop does not have wifi hardware at the moment. 

I have not yet tried to configure the Envy as a network printer in MCC on this desktop, so I don't know how that might work.

I'm going to remove the "ERRATA" flag, at lest for now. Yes, I can get the printer and scanner to work, but it's far too complicated for many of our less experienced users. It should be better than this.

Keywords: FOR_ERRATA9 => (none)

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.

It's looking more now that what Edward and I have seen are the symptoms of two issues at the same time. At least, that's what I'm seeing. 

The issue of Bug 30626 changed, reverting behavior in the HP Device manager. The issue of Bug 31222, concerning the scanner part of the printer only working with the "Airscan" driver, did not change. 

I have reported any changes I observed in the respective bugs.

There is definitely something wrong with the device handling via USB  connection in M8.
Explanation:
My HP Envy 6022 is connected:
via USB to my desktop PC
via wifi (not via sharing) to my Acer laptop.

Started this morning  the desktop. As the printer is behind the same powerswitch as the desktop's monitor, the printer starts up as well and it works OK.
Nothing done further to printer, after 1 hour start HP Device Manager and get status "device communication error".
Thereafter, start the laptop, start HP Device Manager and get status "Power save mode". Initiate a print job from the laptop and it prints OK.
Check thereafter the status on the desktop refreshing the HP Device Manager device and it remains at "device communication error" and does not do any printing.

CC: (none) => herman.viaene