[ale] Kernel assistance required

[Michael B. Trausch]

On Sat, 2011-02-05 at 13:29 -0500, Michael H. Warfield wrote:
> How did you test it?

First, I tried setting it up in CUPS, as I had with my last system that
had a built-in parallel port.  Submitted print jobs would disspear from
the queue immediately.

That led me to test more directly:

$ sudo -s
# cat /etc/passwd > /dev/lp0

The cat command returned immediately (it did not block) and no output
reached the printer.  So, I tried something else:

# while true; do cat /etc/passwd; done > /dev/lp0

This did the same thing; no output to the printer at all.  No dmesg or
syslog status or error output.  Just... nothing.

> Did the printer subsystem configure the printer for you?

More or less.  The setup is pretty much automatic in Ubuntu, save for
selecting the actual driver itself.  This printer follows the standard
for Epson 9 pin printers, though I only use it for plain-text printing;
things like source code or unified diffs, mostly, when I have to go
through some legacy system and try to figure out what's going on.  I
prefer to do that on paper with a pen to try to mark things up.

> Do the /dev/lp[01] devices show up?

Yes.  Both devices appear as expected, and as shown, the kernel even
sees the name of the printer.

> Did you try cat'ing a file to the raw device (cat /etc/inittab
> > /dev/lp0)?

Yep.

> > The kernel detects it (and the printer attached to it) alright:
> > 
> > 2011-02-05 12:17:18 EST (Linux 2.6.35-26-generic)
> > <mbt at aloe> ~ $ dmesg|egrep '(parport|lp)'
> > [   10.931931] lp: driver loaded but no devices found
> > [   11.201761] parport_pc 0000:03:06.0: PCI INT A -> GSI 21 (level, low)
> > -> IRQ 21
> > [   11.201807] parport0: PC-style at 0xd800 (0xd400), irq 21, using FIFO
> > [PCSPP,TRISTATE,COMPAT,ECP]
> > [   11.242729] parport0: Printer, CITIZEN 500
> > [   11.242800] lp0: using parport0 (interrupt-driven).
> > [   11.242857] parport1: PC-style at 0xd000 (0xc800), irq 21, using FIFO
> > [PCSPP,TRISTATE,COMPAT,ECP]
> > [   11.330295] lp1: using parport1 (interrupt-driven).
> 
> > But sending anything to it is as good as sending it to /dev/null: it
> > does nothing.
> 
> Define "sending".  Are you using cups and the high level print drivers?
> Does the job show up then go away?

As stated above, yes, yes, and also plaintext dumped to the printer
fails.  Sending infinitely has no effect, either.

> > The card itself works, as the Windows operating system can print to it.
> > I'm not sure what the problem is: there is no status information, nor
> > any errors, output to dmesg or the system logs when I attempt to use the
> > printer.  Just, nothing happens.  At all.
> > 
> > I don't really know where to begin looking at this.  I don't have any
> > idea if any Linux kernel actually works with this hardware, nor do I
> > know really how to go about figuring out whether any of them do other
> > than by brute force.
> > 
> > The last time I had a problem with anything in the parallel subsystem,
> > the kernel people were less helpful than not helpful at all, which is
> > why I am asking here.  Nobody there was willing to offer me any
> > guidance, and I wound up throwing away the hardware because I had no
> > time to fuss with it.
> 
> I haven't used the parallel ports in ages.  Most everything has either
> USB or network.  The few ancient dot-matrix printers I have in operation
> any more, I slapped parallel to USB adapters on them and disabled the lp
> ports on the motherboards (recovered an interrupt I needed for the sound
> system).

The last USB port -> centronics adapter I used failed to function
correctly.  However, it failed differently.

Say I would do this:

# cat /etc/resolv.conf
# Generated by NetworkManager
domain trausch.us
search trausch.us
nameserver 4.2.2.1
nameserver 4.2.2.2

Then:

# cat /etc/resolv.conf > /dev/to/device

The command would block, and no output would appear on the printer.  I
quite by accident discovered that the printer would print the file (sans
the very first character) if I pressed the ON LINE button twice (once to
take the printer offline and once to bring it back).  However, the first
character would be omitted.  So if I wanted to preserve the print job
perfectly, I would have to send an extra octet at the beginning of the
print job, so that when I pressed ON LINE twice, the print job would
come out without corruption.

In that case, however, it wasn't the driver's fault (I don't think).
The same behavior was exhibited in Windows.  I wound up throwing the
stupid thing away in that case, too.  Biggest waste of $10 I can think
of in recent history.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110205/9d6a003d/attachment-0001.bin