A.P. Lawrence

This article is from a FAQ concerning SCO operating systems. While some of the information may be applicable to any OS, or any Unix or Linux OS, it may be specific to SCO Xenix, Open Desktop or Openserver.

There is lots of Linux, Mac OS X and general Unix info elsewhere on this site: Search this site is the best way to find anything.

Printing FAQ

My printer doesn't work at all!

The first test is whether or not you can print to the raw device (if this is a network printer, see Network Printers). If you aren't sure about how the printer handles line feeds, do this:

 /usr/lib/lponlcr > /dev/lp0
 

(assuming that your printer is /dev/lp0, of course). Type a few lines, and then press enter and CTRL-D. If it gets to the printer, then the port is fine.

The port does show up in "hwconfig", doesn't it? Type "hwconfig | grep parallel" or "grep serial" just to be sure. If it doesn't, you either never defined it (run "mkdev serial" or "mkdev parallel") or the definition is wrong: for example, you said it's a parallel port at 378, but it's actually at 278.

If this is a parallel printer, be sure that your BIOS has it set to "Standard Parallel Port" (sometimes it's "SPP"). If it's EPP or ECP, it will not work with current SCO Unix.

Similarly, there are some "Windows Only" printers that require EPP ports and Windows software- those just are not going to work, period. See Windows Printers for one way around this.

Note : Okidata serial printers require DSR Invalid when using 3 wire xon/xoff flow control. Set this on the printer, using the front panel menus.

If it just hangs, the interrupt is wrong or the card just plain doesn't work (and no, "it works in DOS" doesn't help). It's probably an interrupt problem; the port is never acknowledging receipt of characters so it hangs.

Understand that the "vec=" info in hwconfig for non pnp devices is just a parroting of what YOU told the machine the interrupt is. The lp or serial driver trusts you, but it doesn't really have a clue. It checks the address (378, etc.) by poking certain patterns into certain offsets and then reading the results; if the results are what a parallel or serial port should be sending, then it assumes it has a working port (see /Unixart/driverart.html if you really want to know the gory details). Whether or not the port works otherwise is not the job of the initialization routine, and it definitely is not going to check that interrupts are working or even correct.

Of course, you could have a bad cable, or even a bad printer. I had a customer recently who spend half of a day being very frustrated after an upgrade because he'd done everything right, had double and triple checked everything, but one printer wouldn't print. I suggested putting another printer in, and, yep, that was it: a printer that worked fine the day before had coincidentally died.

Check power, too: I once had a printer that would turn on; the panel lights worked and all that, but it wouldn't print. It turned out that we had only 80 volts at the outlet, and it wasn't enough to drive the motors (this was some years ago).

Comments /SCOFAQ/FAQ_scotec7nogo.html


Add your comments

Why no "Digg this!" etc.?

Forget the expense of flying to New England. Forget hotel and meals costs.
Installation and light training Boston and New England

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Unix and Linux Support

/SCOFAQ/FAQ_scotec7nogo.html copyright 1997-2003 (various) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here