2.4.19: drivers/usb/printer.c usblpX on fire

2.4.19: drivers/usb/printer.c usblpX on fire

[Pete de Zwart]

Is there a reason that in 2.4.19's drivers/usb/printer.c if the printer status
code from is greater than 2 it states that it is on fire instead of printing
the unknown error code?

	Pete de Zwart.

-- 
The real reason your computer crashed, thanx to the BOFH:
"HTTPD Error 4004 : very old Intel cpu - insufficient processing power"

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Mikael Pettersson]

Pete de Zwart writes:
 > Is there a reason that in 2.4.19's drivers/usb/printer.c if the printer status
 > code from is greater than 2 it states that it is on fire instead of printing
 > the unknown error code?

Dunno, but the parport lp.c also goes into "printer on fire" mode, in my case
whenever the black ink cartridge becomes empty :-(

/Mikael

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Samuel Flory]

On Fri, 2002-08-09 at 01:20, Mikael Pettersson wrote:
> Pete de Zwart writes:
>  > Is there a reason that in 2.4.19's drivers/usb/printer.c if the printer status
>  > code from is greater than 2 it states that it is on fire instead of printing
>  > the unknown error code?
> 
> Dunno, but the parport lp.c also goes into "printer on fire" mode, in my case
> whenever the black ink cartridge becomes empty :-(
> 


  The printer on fire message is the traditional Un*x error message for
unknown error on a printer.

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Pete de Zwart]

Around about 1010h 09/08/2002, Samuel Flory emitted the following wisdom:
>   The printer on fire message is the traditional Un*x error message for
> unknown error on a printer.

	What I don't understand is why the misleading message is sent
instead of the printer driver stating that it has received an unknown printer
error code and printing the code number.

	Out of curiosity, does there exist an error code that a printer can
assert that specifies that it is "on fire"?

	Pete de Zwart.

-- 
The real reason your computer crashed, thanx to the BOFH:
"Repeated reboots of the system failed to solve problem"

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Bill Davidsen]

On Sat, 10 Aug 2002, Pete de Zwart wrote:

> Around about 1010h 09/08/2002, Samuel Flory emitted the following wisdom:
> >   The printer on fire message is the traditional Un*x error message for
> > unknown error on a printer.
> 
> 	What I don't understand is why the misleading message is sent
> instead of the printer driver stating that it has received an unknown printer
> error code and printing the code number.

See the paragraph you quoted.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Alan Cox]

On Fri, 2002-08-09 at 18:10, Samuel Flory wrote:
>   The printer on fire message is the traditional Un*x error message for
> unknown error on a printer.

Linux maybe - unix no

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Jesse Pollard]

Pete de Zwart <dezwart@froob.net>:
> 
> Around about 1010h 09/08/2002, Samuel Flory emitted the following wisdom:
> >   The printer on fire message is the traditional Un*x error message for
> > unknown error on a printer.
> 
> 	What I don't understand is why the misleading message is sent
> instead of the printer driver stating that it has received an unknown printer
> error code and printing the code number.
> 
> 	Out of curiosity, does there exist an error code that a printer can
> assert that specifies that it is "on fire"?

Ummm no.

As I understand it, this message is related to a parallel port (input only
style) status code - ready, online, check.

The "check" signal might have had a slightly different name, but it was
a "unknown error".

The fire message came from the old drum printers. These had the alphabet
on a 3 inch diameter steel drum, one ring of the alphabet for each colum.

Over this would run a ribbon, about 24 inches in width, and 10 feet long.
This assembly was all mounted on a door to give access to the paper, and
the print hammers.

The print hammers are all mounted on a fixed base of the printer body, with
the fanfold paper running over it.

The drum rotated about 1200 to 2400 RPM. Faster for higher speed printers.

What happens is that the ribbon gets worn and tends to slide toward the
side of the printer that is printed on the most (ribbon shrinks, and it
is the right side of the printer). When working normally, the ribbon moves
at about 1/4 the speed of the drum. Whenever the ribbon reached the end,
it would hit a switch that would reverse the direction of the ribbon feed.

When the ribbon started shrinking on the right, the entire roll would
start bunching up on the right, leaving the left side of the drum
rotating at high speed, directly against the paper.

This condition generates quite a bit of paper dust.

It also tends to cause the paper to jam. If the jam isn't detected soon
enough, the accumulated paper dust, ink dust, real paper, AND the rapidly
rotating drum would generate enough heat-by-friction contact to start
a fire.

This condition is made worse by the printer cleaning solution, which was
usually denatured alcohol, whose fumes tended to collect in the ribbon.
(had that start a fire once - somebody turned the printer on before the
 drum had dried; something sparked and there was a brief flash of flame)

The paper jam usually set off the "check" signal and the host
would stop sending data to the printer, and report some message to the
operator. Sometimes, the offline switch would also be triggered, which
(at least in the printer) would stop the drum from spinning. The offline
switch was actually triggered by a different condition. I think it was
when the paper was no longer in contact with an "out of paper" sensor.
If the offline switch wasn't triggered, the drum would continue spinning,
and continue adding more heat.

The old lpd on UNIX v 6/7 used the check signal to report a "printer on fire"
if the offline signal was NOT present. I believe it was the combination of
offline and check signal that was used to generate the "out of paper"
message.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Pete de Zwart]

Cool, thanx Jesse, I always wondered what the history was behind it and
how to achieve it.

Here is another query:

If each printer had their own set of error codes, what would be the way to
implement their display from the kernel?

Would each printer have to have their own module if they had a non-standard
list of error codes or would we simply ignore them and state that the
ill conforming printer is on fire?

	Pete de Zwart.

-- 
The real reason your computer crashed, thanx to the BOFH:
"Your processor does not develop enough heat."

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 11 Aug 2002 10:03, Pete de Zwart wrote:
> Cool, thanx Jesse, I always wondered what the history was behind it and
> how to achieve it.
>
> Here is another query:
>
> If each printer had their own set of error codes, what would be the way to
> implement their display from the kernel?
>
> Would each printer have to have their own module if they had a non-standard
> list of error codes or would we simply ignore them and state that the
> ill conforming printer is on fire?
There is more than one way of getting information over the printer connection.

If you think about old-style centronics type parallel connections, there are 
data pins that can provide 8-bit parallel transfers. There are also some 
status pins (no paper, busy, on-fire, whatever). Clearly there will never be 
enough pins on a real system to indicate every combination that might be 
possible ("cyan toner nearly empty", "jam in duplexer unit", "C5 envelope 
tray at 42%"). So you need another way. One option is to make the parallel 
transfer mechanism bi-directional, and do both data and status transfers over 
the same 8-bit parallel pins. Then you can establish a protocol for this (eg 
IEEE-1284 variants).

When you want to map this type of usage to USB, you can indicate some things 
over a "get_status" query at the USB level (which is basically mapping the 
old status pins), and you can just pass the data up to a normal printer 
system (which doesn't care whether it is talking to the printer over the 
traditional /dev/lpX device or a USB emulation.

So the kernel doesn't care about most of the error codes (since it isn't 
interpreting the data stream), but there are some things that are noted for 
historical reasons. Those things (like "out of paper" turn out to be widely 
supported (or if not, are at least set to benign values). All the "unique" 
error codes are a problem for userspace.

Does this make sense?

Brad
- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9VbVJW6pHgIdAuOMRAmvXAJ9lWcnGN24F6tyJEOUoID/1fl4oUQCgovse
oPsfs1E7GHh1jbUjCYUiiTg=
=qENi
-----END PGP SIGNATURE-----

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Pete de Zwart]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Yeah, that makes sense, it's not the kernel's job to take care of the
printers status beyond the basics.

Make the printer drivers like a pseudo-micro-kernel, have the basic printer
operations done in the kernel and have the rest of the functionality farmed
out to individual printer modules.

Ignoring the above, where should the functionality for the extended printer
operations reside?

In the print spooler? A separate process that deals with a bunch of printers?

If this is going off-topic for LKML where would be a better place to discuss
this?

	Pete de Zwart.

Around about 1052h 11/08/2002, Brad Hards emitted the following wisdom:
> So the kernel doesn't care about most of the error codes (since it isn't 
> interpreting the data stream), but there are some things that are noted for 
> historical reasons. Those things (like "out of paper" turn out to be widely 
> supported (or if not, are at least set to benign values). All the "unique" 
> error codes are a problem for userspace.
> 
> Does this make sense?

-- 
The real reason your computer crashed, thanx to the BOFH:
"Mailer-daemon is busy burning your message in hell."

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.19: drivers/usb/printer.c usblpX on fire

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 11 Aug 2002 11:36, Pete de Zwart wrote:
> Yeah, that makes sense, it's not the kernel's job to take care of the
> printers status beyond the basics.
>
> Make the printer drivers like a pseudo-micro-kernel, have the basic printer
> operations done in the kernel and have the rest of the functionality farmed
> out to individual printer modules.
WTF?

> Ignoring the above, where should the functionality for the extended printer
> operations reside?
Depends on printer service. Irrelevant to kernel.

> In the print spooler? A separate process that deals with a bunch of
> printers?
Depends on printer service.

> If this is going off-topic for LKML where would be a better place to
> discuss this?
ML for whatever printer service you want to use.


- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9VdpGW6pHgIdAuOMRAjivAJ48K4aWrOrUo9MqOxbFAAlPvOBqAQCfSMAS
ifgR+wFLwQIjH7SZNPS1Nqc=
=s5IL
-----END PGP SIGNATURE-----