Package: lprng
Version 3.8.28-1
I submitted this bug over a month ago. It was rejected as not being a
lprng bug. But new information I just obtained indicates that it may be
in part a lprng bug.
On Mon, Dec 27, 2004 at 02:57:28PM -0800, David Lawyer wrote:
> Once I type lpr (or pr) to print something, it hangs if I try to print
> something more (use lpr or pr again). Also cat test-file > /dev/ttyS1
> will not work either. It just hangs and nothing gets printed. I'm
> using kernel 2.6.8-1 but the old kernel 2.4.26 prints fine and doesn't
> have this problem.
By using lpc and typing lpq I read: Status: cannot open /dev/ttyS1
'Interrupted system call", attempt 1, sleeping 10. So the problem is
that the serial port can't be opened. But the minicom program can open
this port and then I can type to the printer from the PC keyboard (like
an old typewriter). Also, the modemstat program can open ttyS1. So why
can't lprng open it?
I think this problem has to do with the modem control lines in the
printer cable. When I turn on the printer (25 years old, but of the
highest quality --all metal and heavy) CTS and DSR at the PC are
asserted (from the printer). Note that CD is not asserted. If I
disconnect the printer cable and assert CD with a jumper cable, then the
serial port opens when I try to print (second try) per lsof. But
nothing gets printed of course since the cable to the printer is
disconnected. Thus I suspect the problem with opening the serial port
is due to no CD on the port.
Here's the code modemstat uses to open the serial port where
device="/dev/ttyS1":
void open_my_device()
{
fh = open (device,O_RDONLY);
if (fh == -1)
{
printf ("\nCannot open %s\n",device);
exit (1);
}
}
This works. But actually there may be CD on the port when it opens.
That's because my printer asserts CD to the PC as soon as the PC asserts
DTR->DSR to the printer. DTR->DSR means the PC send out DTR which
asserts the DSR pin on the printer (crossover cable). When lpr tries to
open the port, I see DTR (and CD) get asserted at the PC for several
seconds. Then both of these are negated and it seems that the open
fails. All this may have to do with race conditions. Perhaps if the
test for CD is made before asserting DTR, then open() fails. But if DTR
is asserted in time for CD to be asserted before the test for CD, then
all is OK. This is just a hypothesis that may be wrong.
If I set stty clocal (disable modem control signals) and put stty=clocal
in /etc/printcap then the problem is fixed. But I didn't have to do
this previously and didn't discover until just now that this will still
permit CTS/RTS hardware flow control which I need due to a printer
buffer size of 256 bytes.
> I'm printing via the serial port to an old serial printer. If I don't
> use lpr/pr, but first use cat test-file > /dev/ttyS1, all is OK and I
> can repeat sending files to the printer. But if I use the lpr or pr
> print commands, then I can't print anymore. Before using the cat
> command to send data to the printer, I of course have to use stty to set
> the baud rate to that of the printer, etc.
>
> I think something may be different in the serial driver for the 2.6
> kernel that's causing this problem
>
> David Lawyer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
