[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: how to setup serial console on my mac?
I have a fix for you.
>--- On Wed, 12/3/08, Donald Lee <MacPPC2%caution.icompute.com@localhost> wrote:
>> Sorry. That question is beyond my meager expertise. I
>> think it's a "wscons"
>> question. (?)
>I checked some info on wscons, IMHO don't think it's that. Getty on the other
>hand IMHO looks like it:
> getty, uugetty -- set terminal modes for system access
> The getty program is called by init(8) to open and initialize the tty
> line, read a login name, and invoke login(1). The devices on which to
> run getty are normally determined by ttys(5).
>and TTYS(5) states;
> The file ttys contains information that is used by various routines to
> initialize and control the use of terminal special files. This informa-
> tion is read with the getttyent(3) library routines.
> # root login on console at 1200 baud
> console "/usr/libexec/getty std.1200" vt100 on secure
> # dialup at 1200 baud, no root logins
> ttyd0 "/usr/libexec/getty d1200" dialup on # 555-1234
> # Mike's terminal: hp2621
> ttyh0 "/usr/libexec/getty std.9600" hp2621-nl on # 457
> # John's terminal: vt100
> ttyh1 "/usr/libexec/getty std.9600" vt100 on # 459
> # terminal emulate/window system
> ttyv0 "/usr/new/xterm -L :0" vs100 on
> # Network pseudo ttys -- don't enable getty
> ttyp0 none network
> ttyp1 none network off
>It looks like my config is OK
>wally# cat /etc/ttys
>console "/usr/libexec/getty std.38400" vt100 off secure
>ttyE0 "/usr/libexec/getty std.9600" vt100 on secure
>ttyZ0 "/usr/libexec/getty std.38400" vt100 on secure
>ttyZ1 "/usr/libexec/getty std.38400" vt200 on secure
>Why I'm not able to logon via ttyZ0 or ttyZ1? :-(
I looked into this and I think I found a solution.
If you add "local" to the end of the /etc/ttys entry:
ttyZ1 "/usr/libexec/getty std.38400" vt200 on secure local
seems to work (mine is still "unknown" vs. "vt200", but I digress)
Note that if you change this "on the fly" you have to run ttyflags(8)
to update the flags.
"local" tells the serial driver to ignore the "modem control" serial pins -
like the "carrier detect" and such like.
If you try to do this after the machine is booted, and you have
already typed some chars and/or have a non-working getty already running,
you will have some trouble.
There is some funny business in the startup/flow control. I had to
fire up my "terminal emulator" program to "free up" the serial port, but
once that was done, it worked. ( think there was data "stuck" behind
some sort of flow control status that was not cleared by the "local"
A reboot seems to clear it reliably, after adding "local" to the ttys line.
Also, I am pumping data through the port now, and I note that it is much
more robust than the "old" serial ports. I think the interrupt fixes/changes
in the kernel about the 2.1 timeframe fixed some underlying problems.
It seems to work!
Main Index |
Thread Index |