Marcel Moolenaar wrote:
On May 19, 2007, at 8:26 AM, Stefan Lambrev wrote:
I have disabled device sio in kernel and replaced it with device uart.
And so dmesg |grep uart is :
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0
I was expecting to see uart1 too .. but it is not here.
It's likely that the port doesn't exist or you disabled it
in the BIOS. With ACPI you can be sure we won't try to
create a device for hardware that isn't described by ACPI.
I have: /dev/ttyu0 & /dev/cuau0, also in /etc/ttys I have the
following line:
ttyu0 "/usr/libexec/getty std.9600" vt100 on secure
I have this configuration on other servers too and it works without
problems,
but the main difference that I found is when I use minicom.
I think if I try to open /dev/cuau0 I should see "Device busy" - and
on all other servers where I checked
it does respond with "Device busy" as it is already used, but on this
server I do not!
Are you sure your minicom configuration is correct? Could it
be that it still tries to open ttyd0?
Yes I'm sure :)
Also I notice that where the serial is NOT working I have this line
in ps xa:
1653 ?? I 0:00.00 /usr/libexec/getty std.9600 ttyu0
In first moment I thought it is OK to have getty on ttyu0, but what
is this "??" :)
It means that there's no terminal associated with the getty process.
It's perfectly normal.
so I checked on the other server and I saw that there is NO getty on
ttyu0 running at all (it is started
when I start minicom from the other side of the serial but then it
shows:
99615 u0 Ss+ 0:00.00 /usr/libexec/getty std.9600 ttyu0
and it is stopped when I stop minicom)
Interesting. How is getty started exactly?
BTW: In this case getty is associated with ttyu0 itself. That's not
uncommon and happens when you manually start and/or stop getty.
No, I do not start it manually.
The parent process is 1 - /sbin/init
May be someone more familiar with rc.scripts, init and ttys can explain.
Any useful ideas where to look for ? Also switching back from uart to
sio may sound OK, but it needs another restart :(
The problem doesn't seem to be with uart(4). I see getty(8) and
minicom(1) behaviour that's different on this box from other
boxes (as per your description). It looks to me to be a config
problem.
Well it is not uart because, if I start minicom on both ends, the first
minicom
receive : AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0.
So the serial is working, but for some reason getty cannot start on it
(or/and lock it) ?
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
