serial over /dev/ttyu0 does not work.
Hello list. There is a weird situation where my serial connection stoped working. 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. 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! 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 ?? :) 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) Any useful ideas where to look for ? Also switching back from uart to sio may sound OK, but it needs another restart :( both machines are using: uname -srm FreeBSD 6.2-STABLE amd64 P.S. I'm 100% sure it is not a cable problem as the serial console was working with device sio 5minutes ago :( The problem is that with sio the second com port that not work due I/O range conflicts and uart saved me once so I try same solution and here. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serial over /dev/ttyu0 does not work.
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] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serial over /dev/ttyu0 does not work.
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
