APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed all!

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

My printer doesn't work at all (SCO Unix/System V )

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).

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> (SCO Unix) My printer doesn't work at all!

Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

Dump may work fine for you a thousand times. But it _will_ fail under the right circumstances. And there is nothing you can do about it. (Linus Torvalds)



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode