> The driver is expecting the printer to send a single byte in response
> to a control code (the byte should be 0x00 or 0x01).  It makes an
> appropriate read() call and never comes back.  All other processes on
> the machine stop, the network is unresponsive, etc.  I can still get to
> the kernel debugger with the interrupt switch, and it always seems to
> be in the serial interrupt handler.  (I can copy down the details of
> the stack trace if it will help.)  Since I'm figuring out the control

That'd help. Just send me the trace in private EMail. Also, try it
a few times to see if it's always the same. :-)

> codes for the printer as I go, it may actually be sending anything
> (lots of data, break sequences, etc.), so I'm not sure it's a single
> null byte causing the problem.  I'm pretty sure it's something the
> printer is sending, since I've also seen things go awry during the boot
> sequence if I don't unplug the printer before rebooting.  Also,
> sometimes unplugging the serial cable to the printer will get things to
> start happening again for a couple of seconds, but it usually hangs
> again very shortly thereafter.
> 
> What I'd like to figure out is:  what could the printer possibly be
> doing to the serial port that would bring down the system?  Does 'stty
> -echo' mean that absolutely nothing will be echoed, or could certain
> incoming binary data cause the printer and the serial driver to start
> chatting at full speed?  (I suspect that could cause the symptoms I
> see...)

With stty -echo, the onlything which will get echoed is a new-line.
If you've set raw, then all input & output munging should be off.
So a 0xA will get echoed as an 0xA. Setting -echonl turns this off.
I'm not sure if stty raw sets -echonl or not (I'd expect so).

> This is with a -current kernel supped a couple of weeks ago.
> /etc/printcap sets the serial port to 57600 baud, no flow control,
> 'raw' mode, echo off.  (Yes, the printer requires 57600 with no flow
> control.  It looked wrong to me too, but it's all that works.)

That driver should be quite weaned of spontaneous character generation. :-)

I see no reason why the reception of a single character should wedge
the system (in the driver). Either a character stream, or a state-
change stream (fluctuating signal on CTS or on DTR) could, however,
could tie the system up. A character stream would certainly fill up the
ring buffer, so you'd see zs0b ring overflows when the barrage stoped.

Good luck,

Bill