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
SCO Unix/System V Printing FAQ
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
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
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).
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic