serial over /dev/ttyu0 does not work.
stefan.lambrev at sun-fish.com
Sat May 19 13:53:47 UTC 2007
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
>> 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
>> 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
Well it is not uart because, if I start minicom on both ends, the first
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) ?
More information about the freebsd-stable