Manual firmware upload required for LaserJet 1020 with HPLIP2.7.10

[Johannes Meixner]

I have a HP LaserJet 1020 and use HPLIP 2.7.10
on openSUSE 10.3 on 32-bit i386 architecture from
http://download.opensuse.org/repositories/home:/jsmeix/openSUSE_10.3/i586/

I set up the printer with hp-setup (as root) which worked well
(plugin download worked well and finally the testpage prints).

But it seems HPLIP doesn't recognize when the printer needs
firmware upload (e.g. after I disconnected it from the power supply).

In this case print-jobs do silently disappear without any
error or warning message in /var/log/cups/error_log
but in /var/log/messages there is:
------------------------------------------------------------
... kernel: usb 3-2: usbfs: USBDEVFS_CONTROL failed
 cmd hp rqt 161 rq 1 len 1 ret -110
... HP_LaserJet_1020?serial=JL50HRE: io/hpmud/musb.c 677:
 invalid device_status: Connection timed out
------------------------------------------------------------

After I used hp-toolbox to upload its firmware again,
it prints well again.

There are three bugs here:

1.
Print-jobs must not get lost in case of a device communication problem.
Instead the backend should report an error and exit with a matching exit code
(CUPS_BACKEND_FAILED or CUPS_BACKEND_STOP see "man backend").

2.
The backend doesn't notice when the device needs a firmware upload.
I assume it doesn't cause harm if the firmware is uploaded more than once.
If yes, the backend could simply try to upload the firmware if there is a device
communication error before any piece of the print-job data was sent
and then submit the print-job data after the firmware was uploaded.

3.
I think there is wrong wording in hp-toolbox regarding firmware upload.
It is called "Download Firmware" and I misunderstood it on the first glance
because usually "download firmware" means to download it from the
manufacturer or whatever web-site on the computer while "upload firmware"
means to upload it into the device - at least this wording is used regarding
firmware issues for scanners, see the SANE project.

[David Suffield (david-suffield)]

Hi Johannes,
The /etc/udev/rules.d/86-hpmu-hp_laserjet_1020.rules file, which is installed by hp-setup, controls the firmware download. The firmware should be downloaded at every lj1020 plug-and-play "add" event.

The attached 86-hpmu-hp_laserjet_1020.rules file should work with Suse 10.3. Does this rule file match what you installed? The plug-in has been updated since we released hplip-2.7.10.

-dave

[Johannes Meixner (jsmeix)]

Thanks for the info!

I found one reason why it fails:

In my /etc/udev/rules.d/86-hpmu-hp_laserjet_1020.rules
the following command is called:
/usr/bin/hp-firmware -y3 -s...
This fails for my installed HPLIP 2.7.10 with
error: option -y not recognized

When I run it with "-y3", my printer is silent
but when I run it without "-y3", my printer seems to get
the firmware because it makes some noise.

After I removed the "-y3" from 86-hpmu-hp_laserjet_1020.rules
the printer makes also some noise after USB re-plug.

The underlying problem is how to provide the plugins
so that they match to the actually installed HPLIP version
of the target system.

In this particular case it doesn't help to let hp-firmware be more
robust against unknown options because this doesn't help
for those users who have already an older HPLIP version installed.

By the way1 :

I am missing an information which files were downloaded
and whereto which file was installed.

For example I was not aware that I got a
/etc/udev/rules.d/86-hpmud-hp_laserjet_1020.rules
installed.

In particular business system admins may get upset
when they are not informed what hp-setup actually does
when they set up a ZJStream printer e.g. on workstations.

By the way 2:

The whole firmware stuff doesn't work reliably for me.

Some "hp-firmware -s..." calls failed with
error: Device busy: hp:/usb/HP_LaserJet_1020?serial=JL50HRE
error: Error opening device (Device not found). Exiting.
(of course there was no print job active)

Now it fails with
error: Invalid USB IDs: 003:012
but "lsusb -s 003:012" shows it:
Bus 003 Device 012: ID 03f0:2b17 Hewlett-Packard

I think it is now time for a reboot...

[Johannes Meixner (jsmeix)]

I thought it is a USB issue, therefore the reboot,
but this didn't help.

I found another issue:

Without the "-y3" in 86-hpmud-hp_laserjet_1020.rules
it causes even more problems than it solves because
now the firmware upload happens while the printer
is in its internal startup procedure.

It seems this stupid peice of cheapest hardware becomes
totally confused if it gets data while it is in startup mode.

When this has happened, no further usage is possible
and one gets any kind of unexpected random useless
error or warning messages from "lpstat" when printing
a normal print job like
"printmode mismatch with pen, tray, etc."
"media jam; will retry in 30 seconds..."

As a quick workaround I simply re-added
the "-y3" to 86-hpmud-hp_laserjet_1020.rules
so that firmware upload fails during printer startup.

Now I watch carefully my printer until its startup
procedure is finished (i.e. when the red LED is off
and the green LED is on) and then I upload the
firmware manually.

Now it prints fine again.

Perhaps it is possible that hp-firmware can query this
crappy devices if they are ready to receive data
and if yes, hp-firmware could simply wait until it
can actually send the firmware.

But I guess this is not possible with such lowest-price stuff
so that a blind delay before upload via "-y3" is the only
possible workaround.

According to what I noticed how long it takes until
the red LED is off and the green LED is on,
I suggest to use "-y10" to be on the safe side.

Of course another mess could happen if there are
pending jobs in the queue and CUPS starts to
send them (with exclusive device access) before
udev would try to upload the firmware.

To make it 100% clear:
My harsh words above are of course not meant
against your software. It is only meant against such
weak hardware crap and I can only try to imagine
what it costs you to make a driver for such crap.

I am so happy that I don't have such a piece of
lowest-level hardware crap at home and that I have
a reasonable PostScript/PCL LaserJet 1220 at work
for real printing (the LaserJet 1020 is only for testing).

[David Suffield (david-suffield)]

Hi Johannes,

Your harsh words about the LJ1020 only make me smile, because I can't make public comments like that. Unfortunately these out-sourced printers have Linux USB issues and are easy to hang.

I found that these printers do not enumerate reliably with the usbfs (ie: "lsusb -v -sbbb:ddd"). Of coarse this means HPLIP would not work either.

Fortunately I made a late hpmud change in HPLIP 2.7.12 to help get around the USB enumeration problem and now these printers seem to work ok.

So, I highly recommend using HPLIP 2.7.12 with these low-end laserjets that require firmware. This would also fix the "-y3" problem.

I will talk to Don about documenting the plugins since they are little black-boxes.

-dave

[Johannes Meixner (jsmeix)]

Wouldn't it be the best possible solution when the backend
and only the backend cares about the firmware stuff?

I mean to have no udev magic at all.

Just let the backend do a firmware upload whenever there are
device communication problems with those low-level devices
at tha beginning of a print job.
Of course preferably if the backend could detect if the device
has already firmware or not.
The backend could re-try to do a firmware upload in an infinite
loop until it is successful.
Only when there are device communication problems after
a successful firmware upload, the backend should abort with
CUPS_BACKEND_FAILED or CUPS_BACKEND_STOP.

This should also avoid the mess when there are pending print jobs
while the device is powered-up because the backend would notice
when it fails to send the first piece of print job data to the device
and then it could do a firmware upload and re-send the print job data.

Furthermore (in contrast to udev) the backend can show
matching INFO:/WARNING:/ERROR: messages to keep
the user informed what is actually going on.

For background information what I have in mind
regarding "infinite retries for a CUPS backend", see
https://bugzilla.novell.com/show_bug.cgi?id=337794#c16
----------------------------------------------------------------------
As long as the backend cannot establish a communication with its
recipient, it cannot cause damage when it loops infinitely and
retries again and again (with a reasonable sleep time between
each retry).

In contrast if a working communication with its recipient crashes,
it should not re-try the same job (which means print it again from
the beginning).
----------------------------------------------------------------------

What do you think?

[David Suffield (david-suffield)]

I understand your suggestion, but I prefer the udev firmware download solution because the solution is cleaner. Udev was designed for this type of functionality and I see no need to convolute a cups "backend" with firmware download functionality. With the udev solution any cups backend will work including the "usb" backend.

Also the udev solution has less processor overhead. A cups backend would have to constantly check these devices to see if the device needs firmware. With udev this extra overhead is not needed because the firmware download is event driven not polled.

-dave

[pauljohn32 (pauljohn)]

I have an HP1018 on Fedora Core 7 Linux and I get this same flaky behavior. The hp-check-t output seems to say everything is OK with device communication, but sometimes I send through print jobs and they just "disappear". No error message, just vanish from the queue. I think part of the setup trouble is in deciding which of the USB device options is the correct one in the CUPS configuration tool. That was before I learned of hp-setup and hp-toolbox, which don't seem to be so confused by the number of different devices.

Here's the bit from hp-check -t that makes me think everything is ifne.

hp1018_bl309
------------
Type: Printer
Installed in HPLIP?: Yes, using the hp: CUPS backend.
Device URI: hp:/usb/HP_LaserJet_1018?serial=KP2PZKA
PPD: /etc/cups/ppd/hp1018_bl309.ppd
PPD Description: HP LaserJet 1018 Foomatic/hpijs-ZJS (recommended)
Printer status: printer hp1018_bl309 is idle. enabled since Thu 31 Jan 2008 03:38:02 PM CST
Required plug-in status: Installed
Communication status: Good

It looks like that whether the jobs are coming out of the printer or not.

After upgrading to hplip-2.7.12, I noticed a little improvement, actually. Instead of disapearing in the queue, jobs seemed to just sit. In the toolbox, I can see an indication that a job is "printing." When they fail, the hp-toolbox status says "printer idle" alternating with "device communication error" every few seconds.

I gave up working on it late last night and the user emailed me this morning while I was sleeping off the frustration. He said "Thanks a lot, prints great now."

I have no idea why it started working. The system was not restarted, as far as I know. I am pretty sure I was in hp-toolbox and I did hit a bunch of buttons out of frustration, maybe even the download firmware button.

All I can say is, this printer is not making a good statement on behalf of the HP company. I had an HP Laser Jet Series II in 1988 and it lasted about 8 years. It costed $1600 back then, but it worked dependably. Since then, I've had an HP LaserJet 6 that constantly jammed because the paper was vertically stacked, an HP 1300 that worked OK, except that postscript print jobs regularly overran memory, and now this HP1018. Except for the Series II, I've not picked these things, they assign them to us at work. HP had a company name that represented quality and the people that buy things used to insist on HP printers.

Maybe you do get what you pay for.

[Johannes Meixner (jsmeix)]

Regarding comment #6
https://bugs.launchpad.net/hplip/+bug/187049/comments/6
'With the udev solution any cups backend will work including the "usb" backend.'

Thanks to mention it!
This is THE reason to do firmware upload via udev.

Nevertheless:
The backend must still be fixed so that print jobs cannot get lost
if there is no firmware in the device and/or that there cannot happen
any mess when there are pending print jobs in the queue
while the device is power-cycled and additionally also that the job
is not lost when communication crashes while the job is sent
(e.g. because of power-cycle while the job is sent).

Imagine what normal users usually do if a particular printout is not
as expected (and when there are subsequent jobs in the queue
or if it is a longer job which is not yet sent completely to the device).
What else could they do except to power-cycle the device
when the only button/switch at the device is the power switch?
Many users don't know or do the CUPS "cancel".

[Johannes Meixner (jsmeix)]

Only a side note regarding
https://bugs.launchpad.net/hplip/+bug/187049/comments/7
'I had an HP Laser Jet Series II in 1988 and it lasted about 8 years.
It costed $1600 back then, but it worked dependably.'

Just buy a HP printer which costs $1600 now
and you will very likely be happy with a nice
PostScript/PCL device which is reasonable robust.
Perhaps not as robust as the LaserJet series II,
but then just buy one which costs now the
current real equivalent of $1600 from 1988 ;-)

Again:
I never had a real problem with my LaserJet 1220
which is a LaserJet 1200 plus scanner unit and
a LaserJet 1200 was much cheaper than $1600.

[Aaron Albright (albrigha-deactivatedaccount)]

Johannes,

Did Dave answer all your questions?

I'm wondering how I should classify this bug, or if he worked out the explanation for what's going on I'll set it to invalid?

Thanks for your time,

Aaron

[Johannes Meixner (jsmeix)]

As far as I see there was no answer regarding
item 1. "Print-jobs must not get lost..."
in my initial comment, see also my
"Nevertheless: The backend must still be fixed..."
In comment #8:
https://bugs.launchpad.net/hplip/+bug/187049/comments/8

Or is it perhaps already fixed in newest HPLIP?

[Aaron Albright (albrigha-deactivatedaccount)]

I think this is fixed...if not please reopen.

A