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 17:11:49
>
> Bill wrote in reference to hangs in the boot sequence with some Apple
> printers:
>
> >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.
>
> I don't think you'd want the serial port to echo everything back if the
> terminal was set for "local echo". That would cause every character
> typed to appear on the terminal twice. On modems this is usually called
> "Command Echo" and can be enabled/disabled via one of the
> Hayes-compatible modem commands. On my Supra it's the "E" command.
True. But the "UNIX Way" is that the terminal isn't supposed to
local echo. If it does, stty -echo fixes all. At least that's the
dogma. That's not to say I'm against such heretical ideas like
making the port defaults NOT include echo, but I'm trying to keep
being a heretic as a side line, don't you know. :-)
Actually, for a dial-in serviced by getty, you're supposed to change
the power-on defaults of the modem so that the no-command-echo mode
is the power-up default.
> If it's just this character re-echo that is confusing the printer because
> it doesn't expect to see the Command/Status/Character it sends echoed
> back, how do I set the "noecho" attribute for the line so that it's setup
> *before* the call to "settyflags" in the boot process? Should I define
> /dev/tty01 as a unique terminal type in /etc/ttys with a corresponding
> entry for that terminal type in the termcaps file?
Setting the terminal type won't help AFAIK. My printer (a DeskWriter)
has the same I-don't-expect-my-data-back problem, though it actually
prints its status bytes. They come out as white-on-black blobs. :-(
For now, keep the thing off during boot, and put a line in rc.local like:
(/usr/sbin?)/stty -f /dev/tty01 raw
and all will be well from that point on.
This problem, in a varried form, is exactly why the next version of the
driver will be able to set "raw" as the defaults for a tty. These defaults
will be set VERY early in the tty's life; in zsopen. :-)
> >I'll try & hurry this beast up. Though we'll also need some changes in the
> >booter to support this stuff.
>
> Don't hurry on my account. It's not that difficult to turn off the
> printer before I boot, although it'd be nice to see Booter V1.9
> officially "released" as it's use is mandatory for booting NetBSD on some
> Macs like my Performa-550.
Well, I'd like to put some more stuff in it, so let's wait a bit. :-)
> Here is the traceback from a Kernel built from sources SUPed last
> weekend. The printer in question is an Apple Personal 300 Laserwriter
> with the Energy Saving feature.
>
> -Debugger...
> _nmi(2404,5,47,5a00,2104) + 26
> _lev7intr(?)
> _zshard(0) + 12
> _lev4intr(?)
> _serstop(7000a00,7000a82,5,c,c01) + e
> _seropen(c01,5,2000,7051a00) + b0
> _spec_open(886e20) + 14c
> _vn_open(886ee8,5,0) + 320
> _sys_open(7051a00,886f88,886f80) + 72
> _syscall(5) + 13c
> _trap0() + e
>
> Hope this helps, if not let me know what Debug options you'd like me to
> enable in the Serial Module. Since you're already working on a new
> Serial Module it doesn't make much sense to fix the current one. But if
> it can be used to gain a better understanding of what's going on in hopes
> of avoiding the same problems in your current effort, then I think it
> might be time well spent.
I definitely agree debugging this problem is good now as the next version
behaves basically the same here.
Try removing the "static" in front of the definition of zsparam. It's
the routine just after zsstop (aka serstop by a #define). "static"
keeps its name out of the symbol table, so the debugger thinks a call
to it is a call to the routine which preceeds it. zsparam IS called by
the open routines, and it is the routine which actually enables
interrupts on the chip. Just the thing to start an interrupt storm. :-)
Also, it might be interresting to sprinkle printf's through zshard,
the routine which services interrupts. Something like printf('t')
for transmit interrupts, printf('T') for transmitter done,
printf('r%c ',rr0) for received bytes (after the character has
been read into rr0!), and printf('s') for status changes. Note:
You'll probably fill the screen and want to turn the pritner
off fairly quickly, and reboot with a kernel w/o these printf's.
Good luck!
Bill