serial ports on the Ultra 5
gurney_j at resnet.uoregon.edu
Mon Dec 5 20:45:45 GMT 2005
Aaron Glenn wrote this message on Mon, Dec 05, 2005 at 11:28 -0800:
> On 12/5/05, John Baldwin <jhb at freebsd.org> wrote:
> > You don't use sab(4) anymore, but uart(4).
> I had a suspicion that was the case, but couldn't confirm it.
> > Here are your SAB ports. /dev/ttyu0 and /dev/ttyu1
> Then something more sinister is at work here. A 'cu -l /dev/ttyu0'
> will "connect" me, however I get no prompt, and not input or output
> seems to be passed to the console port. All input gets dumped to the
> shell I executed the cu command from, *after* I kill the first (lowest
> pid) cu process.
> yang# ps -ax | grep ttyu
> 687 ?? I 0:00.01 /usr/libexec/getty std.9600 ttyu1
> 688 u0 Is+ 0:00.01 /usr/libexec/getty std.9600 ttyu0
> 741 p0 R+ 0:00.01 grep ttyu
> yang# cu -l /dev/ttyu1 -s 9600
> *hit enter a few times, type hello john, then kill the first cu
> process from another shell*
> yang# hello john
> hello: Command not found.
> Reading the handbook section on serial communications again, I don't
> see anything wrong. I'll be the first to admit this type of stuff is
> uncharted territory for me. If I skipped some required reading on the
> subject, please don't hesitate to point me to it.
You won't get a login prompt from the getty running on the local
machine... as soon as you open up ttyu1 the getty will "get" out
of the way and stop doing work... The above usually happens when
the otherside doesn't have CD raised and you haven't set the clocal
flag on the port... if you use the cuau1 port, that usually ignores
CD, and you can start typing...
what do you have on the other side? are they back to back? or? Also,
I usually disable getty's when I'm debugging as it can usually cause
other issues, and then once I have the serial ports mostly working, then
I enable getty and see what breaks...
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-sparc64