Subject: Re: Problem Apple printers
To: Bob Nestor <rnestor@metronet.com>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 04/22/1996 09:23:44
> 
> Ken wrote:
> 
> >I'm not sure of the relevancy of this here, but I've been seeing boot
> >"hang" when setting tty flags, too.  I don't know why the kernel does
> >this, but I know why it appears to hang.  When setting tty flags, the
> >serial driver somehow asserts the DTR line, and it tells my modem to
> 
> Yes, this is the same thing I've always seen with the Personal 300 
> LaserWriter.  I once turned on all the debugging options in the Serial 
> code and noticed this same chatter between the CPU and the printer.  
> Powering down the printer allows the boot to proceed, but in the case of 
> the LaserWriter when the power comes back up it goes back into the same 
> chatter mode. Also, it seems that the printer state change in this case 
> is being handled as an "Output Complete" interrupt rather than a "Change 
> of Status" interrupt.  It might be possible to fix the problem by 
> reclassifying the cause of the interrupt.  I had intended to try this and 
> got side-tracked by other things.

Well, Ken's problem (modem saying "NO CARRIER" when DTR goes up, which
sets up an echo loop) is kinda "the way it's supposed to work."
Serial ports are "supposed" to echo everything back out, since there's
supposed to be a terminal on the other end. Modems aren't supposed to
speak unless spoken to.

One of the features of the new serial port driver will be to define a
port as a "raw" port. Right now the settings for a tty the first time
it's opened are correct for a terminal; echo, opost, onlcr, icanon,
etc. Sounds like your printer (and Ken's modem as long as it's not
a dial-in for a tty) need this RAW mode too.

I'll try & hurry this beast up. Though we'll also need some changes in the
booter to support this stuff.

> Bill, I tried commenting out the references to DCD in lines 262, 1471, 
> and 1472 but got the same results.  On boot I hang in set ttyflags.   A 
> traceback shows the code to be "serstop" called from "seropen", etc.

Weird. Could you check closely on the trace? seropen isn't supposed
to call serclose directly. ??


Take care,

Bill