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?
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.
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.
--
Marcel Moolenaar
[EMAIL PROTECTED]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
