printer randomly stops working

Bug #113640 reported by Ramon de Ruiter
8
Affects Status Importance Assigned to Milestone
linux-source-2.6.22 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: cupsys

My printer, a USB Brother HL-1430 (HL-1450 driver) refuses to print documents (Open Office) after it has successfully printed 1 or 2 documents a few hours before. Afaik the printer worked fine before Feisty.
Then the Gnome printing manager displays the error:
Printing: Printer not connected; will retry in 30 seconds...

Yesterday I also had this bug. I "fixed" it like this:
-Delete the printer
-Pull USB plug, wait a sec and reinsert
-Detect new printer (nothing was detected, but that's another bug i guess)
-Reboot
-Printer can now be detected by the wizard and after installing it worked perfectly again (testpage and OOo Writer)

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Brother printer on USB are known to have communication problems. This is probably the same as the problem reported as bug #35638.

The best is probably to use the printer's ethernet connector (if it has one) to get a network add-on for this printer or connect it to the USB printer port of a router ort a network print box.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

can you post the output of "uname -a"? Thanks.

Revision history for this message
Ramon de Ruiter (won) wrote :

I've looked for an UTP interface for the printer before to eliminate the need of a running PC to print. That interface costs about as much as a new printer so that's not an option. More importantly I can't recall this weirdness before dist-upgrading to Feisty.

Current kernel:
Linux pc-desktop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

I'm quite sure this didn't occur when running vmlinuz-2.6.17-10-generic/vmlinuz-2.6.17-11-generic on Edgy.
Do you suspect regression in the kernel?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Which distro did you use before Feisty on which the problem did not occur? Edgy? Dapper? Older?

Changed in cupsys:
status: Unconfirmed → Needs Info
Revision history for this message
Stanley Sokolow (overbyte) wrote : Re: [Bug 113640] Re: printer randomly stops working

Till,

I don't remember. I'll try the 5.10 live CD and 6.06 live CD.

Stan

Till Kamppeter wrote:
> *** This bug is a duplicate of bug 35638 ***
> https://bugs.launchpad.net/bugs/35638
>
> Which distro did you use before Feisty on which the problem did not
> occur? Edgy? Dapper? Older?
>
> ** Changed in: cupsys (Ubuntu)
> Status: Unconfirmed => Needs Info
>
>

Revision history for this message
Ramon de Ruiter (won) wrote :

That'd be Edgy. I always upgrade within a few weeks to the latest version.

Revision history for this message
Stanley Sokolow (overbyte) wrote :
Download full text (4.2 KiB)

I have some more information and a solution to the problem; well, at least a work-around and a hypothesis about the underlying bug. My Brother HL-1440 works perfectly (so far) when connected with the parallel port instead of USB. That's a cheap alternative compared with buying a different printer. I checked the Brother-USA web site regarding the models that have been reported in bug 113640 and the related (duplicate) bug 35638. These models all come with both USB and parallel connections. The printer senses which cable is plugged in. Until the USB problem is solved, these models and perhaps all the Brother HL series of printers should be connected by parallel port or ethernet interface if available in that model, rather than USB.

I tried some other experiments to help tunnel in on the nature of the USB "invisibility" problem I've described. I don't think its a bug in the kernel, but rather a bug in the way that the printer driver or CUPS interprets the printer status data it receives from the printer when probed on the USB port. As data supporting this hunch, consider this. I plugged in a different USB printer to the same USB cable instead of the Brother printer. This test printer was a printer/scanner Lexmark (model X2250). I did not install a driver yet. I just plugged it in, turned it on, and booted into Ubuntu 7.04. When I was logged in, I executed the "watch 'lpinfo -v'" command and watched. The printer was seen as a local usb printer with the correct model name. It was solidly visible, never going invisible from the lpinfo output. So what's different about the Brother printer? The Brother is a laser printer and the Lexmark X2250 is inkjet. Lasers have a fuser roller, which is heated by a heating element inside the roller so that the roller can melt the dry ink powder into the paper (fusing it to the paper), but inkjet printers do not. The heating element is temperature regulated by the printer so it maintains the correct fusing temperature. To do this, it turns the heater on and off as needed. I have a strong suspicion that the status data reported on the USB port includes some indication whether the fuser is at the correct temperature or not, or perhaps whether current is flowing in the heater element or not. This would be useful information for a diagnostic program that figures out whether the printer is functioning correctly, so it's possible that Brother provided this status data in the USB status dialog, for diagnostic purposes. If that's true, perhaps the Linux printer driver developers have mis-interpreted the status data coming in on the USB port, using the fuser status information as a printer presence indication (or perhaps as a printer ready or not ready indication). There probably is a different bit of data in the status message that is the correct indicator of the printer-ready state, one which corresponds to the "ready" LED on the printer itself. If I am correct about this, the behavior of cycling between visible and invisible would be explained -- when the fuser cools down and needs to be heated, the fuser status bit would be interpreted by the driver as printer not present or ...

Read more...

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Stanley Sokolow, to your last paragraph, this problem I have fixed now, at least for USB. You need to install the hal-cups-utils package. Then as soon as you unplug the printer or turn it off, the queue gets disabled, and as soon as you plug/turn on the printer again, the queue gets re-enabled again.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you also test this with Gutsy (live CD if you do not want to install)?

Can you also test in single-user mode?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I have now packaged CUPS with an alternative USB backend which does not use the usblp kernel module. You can download it here:

http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/cupsys/

Install all packages in the binary/ subdirectory using "sudo dpkg -i ...". Then do

sudo rmmod usblp

Does CUPS/system-config-printer/gnome-cups-manager see your Brother printer reliably now?

Note that the binary packages are for Ubuntu Gutsy.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux-source-2.6.22 (Ubuntu) because there has been no activity for 60 days.]

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.