(Mostly taken from Brad Fritz's tips to the LEAF mailing list)

First, work your way up the stack, starting with the hardware. Did boot complete successfully with no error messages and with the required hardware and modules being found? If not, the missing or failed element is likely to give you your strongest lead to the problem. A typical example might be signs of an IRQ conflict or that the parport modules report a different IRQ to the one you had previously configured hardware to use.

Nicholas Fong reports that some motherboards will prevent LPT1 from working if there is no monitor attached. He recommends:

Boot up with a monitor attached, after boot up, type ps ax and you should see:

/usr/sbin/p9100d 

Boot up again without attaching the monitor, after boot up, attach a monitor and type ps ax if the /usr/sbin/p9100d disappears, if it does, you have one of those strange motherboards.

There is no cure. You need to change motherboard or add an ISA add-on multi-function IO card with a parallel port.

If you don't see any hardware or boot errors, continue to work up through the stack. Get to the command line and check that the modules are properly loaded by issuing:

lsmod | grep parport
lsmod | grep lp

You should see that the two parallel port modules and the lp module have been loaded.

If they don't, try manually loading them and examining the resources available with and without the modules loaded. Eg:

  # stop printing, remove drivers, and show irq/io state
  svi p910nd stop
  rmmod lp parport_pc parport
  cat /proc/interrupts
  cat /proc/ioports

  # insert drivers specifying irq/io, show irq/io state, start
  # print service, and test printing
  insmod parport
  insmod parport_pc io=0x378 irq=7
  insmod lp
  cat /proc/interrupts
  cat /proc/ioports
  svi p910nd start

Next, check to see if you have parport entries in the /proc filesystem (in other words, the system correctly created the nodes you configured in root.dev.mk and root.dev.mod). Issue:

find /proc/ -name 'parport*'

Verify you have a /dev/lp0 device by issuing:

ls -l /dev/lp*

On a single printer system, the output should look something like:

crw-rw----    1 root     lp         6,   0 Jun 13  2001 /dev/lp0

On a two-printer system, the output should look something like:

crw-rw----    1 root     lp         6,   0 Jun 13  2001 /dev/lp0
crw-rw----    1 root     lp         6,   1 Jun 13  2001 /dev/lp1

Check that the p9100 package did load. The messages you see from issuing:

svi p910nd stop
and
svi p910nd start

should confirm that the package did load.

Check that the p9100.lrp package found all the devices that you expect by issuing:

cat /var/log/syslog | less

and look for signs that the p9100 package found printer devices that you expected and - more likely - failed to find devices that it expected but which are not present. Eg, LPT3 is unlikely On a single printer server you will typically see a message here showing that /dev/lp1 was not configured.

Verify that the daemon is started by issuing:

svi p910nd stop; svi p910nd start
and
ps -ef | grep p910

Verify the daemon is bound to port 9100 (0x238C in hex - not to be confused with the io ports used by the parallel port)

cat /proc/net/tcp | grep -i 238C

The response on a working server looks something like this:

   0: 00000000:238C 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        
0 5791 1 c3d8aa60 300 0 0 2 -1                              

Verify you can connect to that port from a remote client by issuing:

nc 192.168.1.254 9100

or use the printer test files from Nicholas Fong's p9100test.zip file as shown below:

nc 192.168.1.254 9100  <  pcl.prn  (if you have a PCL language printer)
nc 192.168.1.254 9100  < epson.prn  (if you have an Epson printer that uses the ESC/P2
language)
nc  192.168.1.254 9100 < testing.ps  (if you have a postscript printer)

The Windows version of "nc" requires the user to type Ctrl-C when the file is "sent".

If you have a full version of nc (e.g. Linux), replace above by:

nc -q2 192.168.1.254 9100 <  pcl.prn  (if you have a PCL language printer)
nc -q2 192.168.1.254 9100  < epson.prn  (if you have an Epson printer that uses the ESC/P2
language)
nc -q2 192.168.1.254 9100 < testing.ps  (if you have a postscript printer)

ToDo: find out how to interpret the result of this command.

I get no response on my working server - does this mean that no response should mean that everything is OK. What would a "connection refused" message mean?

Run "tail -f /var/log/syslog" on the print server and then verify you can connect to port 9100 from the printing client with:

telnet 192.168.1.254 9100

If there is a problem, expect to see a "connection refused" message. If so, check that the port exists, that Shorewall's rules are letting it through and that the appropriate parallel port exists.

You should see syslog show a message like:

Apr 12 01:50:53 firewall p9100d: Connection from 192.168.2.1 port 1067

This is the p9100 package reporting a connection on its port 9100.

If you see this message, then while you are running tail on /var/log/syslog, try to print to the device from the remote client as you normally would. You should see the same message appear again.

Client-side

Check that your client Standard TCP/IP printing port is connecting to the correct IP address and port number.

9100 prints to /dev/lp0
9101 prints to /dev/lp1
9102 prints to /dev/lp2

Troubleshooting tips that don't seem work

Although it would be handy to test the print server by printing from its own command line, this will likely not work:

Try this from the print server:

echo -en "Hello\f" >/dev/lp0

If you see activity on the printer then that's good. But if you don't seen any activity then that is not necessarily bad. The only effective way to test the print server is to print to it from a remote client.