HP Color LaserJet Enterprise MFP M578 issues

[fabled]

Seems that the new HP M578 has few issues that would need improvements / additional quirks:

• The replies from printer sometime take long time (due to various reasons), and I had to adjust DevInitTimeout to 10 seconds
• One reason for the above is that the IPP GET /ipp/print request sometimes takes long time, partly due to random delays on printer side, but partly because the response is fairly large and compression is not supported. Perhaps ippGetPrinterAttributes could be updated to request only the attributes really needed, instead of the all which is slow to construct and generates more data than wanted.
• Another related firmware issue is that GET /ipp/faxout when the fax unit is not installed is broken. It will return 503 Service Unavailable, headers and the empty line to indicate end of headers. However, it never sends the empty line to indicate end of body. This triggers ippGetPrinterAttributes to exit early (from HTTP status check), and that triggers the client has gone; draining response from USB logic in background. However, that logic never finishes since the final newline is not received. While everything works still, this causes issues because one channel is kept allocated, and that also prevents clean shutdown of ipp-usb when the printer is attached.

Suggestions:

• Adjust DevInitTimeout slightly higher
• Add timeout handling to func (wrap *usbResponseBodyWrapper) Close()
• Perhaps add a quirk to disable fax support
• Make ippGetPrinterAttributes request only named attributes instead of all

I will also try to reach out to the HP support on the mentioned firmware issues. And perhaps request if they could support Content-Encoding: gzip because that would likely speed up things over the slow USB2.0.

[alexpevzner]

Hi Timo,

I've probably fixed /ipp/faxout issue, please retest. And please test on some fax-capable devices too, I never tried this method of fax presence detection before (based in IPP-over-USB class-specific device capabilities instead of probing), so who knows how will it work on various firmwares.

Regarding DevInitTimeout, I can add device-specific quirk to selectiverly increase this timeout on devices that require it, but I don't want to increase it for all devices, because if initialization stuck, it prevents ipp-usb from normal shutdown, and long timeout here is really annying.

Regarding timeout in func (wrap *usbResponseBodyWrapper) Close(), what should I do, if this timeout expires? I can't leave device in this state, because synchronization is lost in this case, and IPP-over-USB doesn't provide me a method to selectively reset a single interface. It's a real headache :-(

Regarding requestion only the needed attributes, I prefer all attributes to be listed in the log, because it helps solving other issues without need to ask users to do something special to obtain more info. How large is response for this device, in bytes?

[alexpevzner]

P.S. The price of this device is very impressive! I see, the more expensive device is, the more likely it will have some noticeable bugs in firmware...

[fabled]

I've probably fixed /ipp/faxout issue, please retest. And please test on some fax-capable devices too, I never tried this method of fax presence detection before (based in IPP-over-USB class-specific device capabilities instead of probing), so who knows how will it work on various firmwares.

Will test when I get back to the device again. Though, the device does support faxing, it just needs an optional add-on module for that. So I am not sure how the USB descriptor bit is set when the module is not present. The unit I have, does not have this module, so that's why the http GET response is likely 503 (URI recognized, support not present). Anyhow, I remember seeing this with all the "Enterprise" series devices in HP lab. So "Server: HP_Compact_Server" would be fairly good way to recognize the broken device.

Regarding DevInitTimeout, I can add device-specific quirk to selectiverly increase this timeout on devices that require it, but I don't want to increase it for all devices, because if initialization stuck, it prevents ipp-usb from normal shutdown, and long timeout here is really annying.

Right. Then again, if the attributes requested is reduces, this does not need increasing. The maximum time I've seen is just around 5 seconds. But this device also gives the zero-size USB reads, and given how the backoff strategy works there, it also adds little likelyness for the DevInitTimeout to happen.

Regarding timeout in func (wrap *usbResponseBodyWrapper) Close(), what should I do, if this timeout expires? I can't leave device in this state, because synchronization is lost in this case, and IPP-over-USB doesn't provide me a method to selectively reset a single interface. It's a real headache :-(

Yeah. I have no good ideas. I was thinking to assume the channel is reset after a long timeout. The main issue is that clean exit is not possible when device is attached with stuck channel. After receiving quit signal, it waits indefinitely for the channel to enter clean state. Perhaps the quit process should at least have some hard timeout for this? It can then USB reset the whole device because the daemon is exiting.

Regarding requestion only the needed attributes, I prefer all attributes to be listed in the log, because it helps solving other issues without need to ask users to do something special to obtain more info. How large is response for this device, in bytes?

It was around 30 kB or so. Other HP devices gave even more (as in seveal 100kBs). It seems the "Pro" series devices support Content-Encoding: gzip, but the more expensive "Enterprise" ones do not :/

More importantly, it seems that requesting the whole set also increases the device's processing time of the request considerably (up to several seconds 3-5 seconds). Much of the bulk data comes from the printer dumping all the support paper format sizes/margins, paper types, etc. When just requesting few needed attributes the request is usually sub-second. So this would be one important place for me to reduce latency from USB cable connect to the device being usable by user.

[alexpevzner]

So I am not sure how the USB descriptor bit is set when the module is not present

This is a special kind of USB descriptor; it exists only in the IPP-USB devices and indicates what device can expose via the IPP-USB interface (print/scan/web console). So I think, firmware may set it correctly, according to the actual hardware capabilities.

We should test. I'm worry if some devices that actually have fax support don't set "fax" bit in the USB descriptor.

Then again, if the attributes requested is reduces, this does not need increasing.

OK. I've changed ipp-usb to request only attributes that it actually need (though the list includes document-format-supported and media-size-supported which may return a long list). Lets see, how does it help.

The main issue is that clean exit is not possible when device is attached with stuck channel. After receiving quit signal, it waits indefinitely for the channel to enter clean state. Perhaps the quit process should at least have some hard timeout for this? It can then USB reset the whole device because the daemon is exiting.

This logic actually exists in the shutdown path. If device could not be shut down within a reasonable time, USB reset is issued. I will review this code to understand why doesn't it work in your case.

[fabled]

I can confirm that the IPP-USB descriptor fax bit is off in my device which does not have the module installed. Likely the commit fixes the issues mentioned, and speeds up things by avoiding a round trip.

I can also confirm that the requesting only needed attributes for the printer query improves things:

• before: 15147 bytes response, usually 3 second latency
• after: 3244 bytes, split second latency
  Improving considerably user experience. Thanks!