When I was young, my family had a subscription to Consumer Reports, and I grew up expecting it to be trustworthy. But I became an expert in a few things and discovered that on those topics, they were often uninformed and frequently misleading. A few years after I was married, my wife and I dropped our subscription because I no longer trusted them. Also, we had subscribed with a unique name, and as a result we got the impression that that they sold their subscriber list to anyone with a wooden nickel. The vast majority of our junk mail for the next fifteen years or more was addressed to the name that we had provided only to CR. This further eroded remaining trust in their intentions.

In the early Red Hat days, as Linux was entering more mainstream consciousness, I was among many interviewed for some news reports. I got to see both sides of the news business, and discovered that even the non-profit NPR appeared to be looking for a hook; to find hidden conflict regardless of whether it exists sometimes appears to be the essence of journalism. My skepticism deepened and broadened. I’m still happy that we have investigative journalists, and decry the current political sentiment regarding news media, but now I read news stories from any source wondering how much to trust this particular story, and what biases the author and editor might have. A good lesson.

I am glad that Wikipedia exists, and I do read it. I know that on average, a sampling was found to be similarly factual to a curated encyclopedia. But… I still have my favorite Wikipedia page: lp0 on fire. I have enjoyed reading the speculation about where the “lp0 on fire” message originated. I don’t know that there’s anything actually specifically wrong there, but it also doesn’t mention the source of the actual error message that titles the page.

What really happened

Linux was young, I was young, and while I did have experience tending a few mainframes and their associated line printer which they shared, I had no experience or even oral history of flaming printers. I had never seen a “printer on fire” message.

Linus Torvalds had written barely enough of a parallel port driver to function, because he mostly didn’t care about printers anyway. The single CPU spent all of its time waiting for the slow printer to become ready, and the system became unresponsive the whole time it was feeding data to the printer. The workaround was dd if=file.to.print of=/dev/lp0 bs=1 which made the printer even slower, so in practice no one used it. I was looking for a first kernel driver to cut my teeth on, and I cared about printing.

OS/2 “solved” the problem of making a parallel port work on a multitasking system by requiring a relatively expensive (at the time) interrupt-driven parallel port, but it still wasn’t fast. (Rumors were that it transmitted only one character on each interrupt, but I never heard whether they were true.) In my hubris, I thought that I could do better than IBM’s finest.

I ordered the datasheet for the parallel port driver chip from the manufacturer (remember getting information in the days before the web?) and when it arrived in the mail (USPS), I got to work.

I realized that most printers had at least a single print line worth of buffer memory, and that I could push data at the printer until it signaled that the buffer was full, then yield the CPU for a while without slowing down the printer, because the printer would be busy for a while processing data. As long as I usually had an opportunity to check again in a jiffy (0.01 seconds) whether there was room in the buffer, the printer would work at approximately full speed. I made it possible to use interrupts if they were set up, but at that time most of the parallel ports weren’t connected to interrupt lines because DOS didn’t need that.

I was beside myself when I got the Linux driver to print faster without interrupts, and with lower CPU utilization, than the OS/2 driver. I reduced typical CPU utilization from 99.9% to 0.01% while increasing throughput. Winning my imaginary race with IBM’s OS/2 driver writers gave me unwarranted confidence in my own abilities, and I never looked back.

(Incidentally, I also wrote and published the tunelp program that people could use to make the driver even faster with their computer and printer. This was my first experience making the dubious ioctl mess worse than I found it.)

But while I was making it go fast, I also noticed that the data sheet explained the responses from the printer. Not just busy, but also error codes. I decided that reporting the actual error codes from the printer would be helpful, so I dutifully added error reporting. One of the error codes signified “unknown error”. At the time, it seemed funny to me to report “unknown error” as "lp%d on fire" (where %d was replaced by a number based on the I/O address for your particular printer; typically 0 on older hardware and 1 on newer hardware at the time) and I vaguely thought that Linus would ask me to change that—or just change it himself—when I sent him the patch to make printing fast and efficient.

It was many years, and many panicked people to whom I apologize for my youthful indiscretions, before someone changed the error message to indicate that it was a joke. (reported invalid error status (on fire, eh?))

I was overjoyed to discover, through the Wikipedia article, that I wasn’t the only one to think it would be funny (or, perhaps even helpful?) to report an unknown error as a fire. But the specific error message from the title of the article, lp0 on fire, was my sorry invention.

Mea culpa, mea culpa, mea maxima culpa.

Update: Mitch Franklin found my post from 1996 when my memory of the event was fresher. I had by now totally forgotten that I was transcribing a comment into an error message. It was certainly a joke, and I still turned it into a scary error message, but the joke wasn’t mine, it seems.