Hi all,
I'm trying to get a USB->serial adapter serving a login prompt via getty.
Here's the converter in question:
---8<---
uftdi0 at uhub3 port 3 configuration 1 interface 0 "FTDI FT232R USB UART" rev
2.00/6.00 addr 2
ucom0 at uftdi0 portno 1
--->8---
The following line in /etc/ttys:
---8<---
ttyU0 "/usr/libexec/getty std.9600" vt220 on
--->8---
Reboot, no login prompt on the client, even after liberally hammering enter.
This is the same as what happened using a prolific cable, but I had assumed
this was a hardware bug, but now I'm not so sure! I know the above procedure
works fine on a Soekris (just using tty00 in place of ttyU0).
Debugging further, manually echoing ASCII down the line using cuaU0 works fine.
I then ran getty under ktrace:
---8<---
ktrace /usr/libexec/getty std.9600 ttyU0
--->8---
It looks to me like opening the device is hanging:
---8<---
...
20220 getty NAMI "/dev"
20220 getty RET unveil 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL kbind(0x7f7fffffa878,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL chown(0x8bbe8e078f0,0<"root">,0<"wheel">)
20220 getty NAMI "/dev/ttyU0"
20220 getty RET chown 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL chmod(0x8bbe8e078f0,0600<S_IRUSR|S_IWUSR>)
20220 getty NAMI "/dev/ttyU0"
20220 getty RET chmod 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL revoke(0x8bbe8e078f0)
20220 getty NAMI "/dev/ttyU0"
20220 getty RET revoke 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL nanosleep(0x7f7fffffb3b8,0x7f7fffffb3a8)
20220 getty STRU struct timespec { 2 }
20220 getty STRU struct timespec { 0 }
20220 getty RET nanosleep 0
20220 getty CALL kbind(0x7f7fffffb318,24,0xb7092ac1c9c0a609)
20220 getty RET kbind 0
20220 getty CALL open(0x8bbe8e078f0,0x2<O_RDWR>)
20220 getty NAMI "/dev/ttyU0"
--->8---
(That's the end of the trace)
That trace snippet corresponds with this chunk of code:
---8<---
if (strcmp(argv[0], "+") != 0) {
chown(ttyn, 0, 0);
chmod(ttyn, 0600);
revoke(ttyn);
/*
* Delay the open so DTR stays down long enough to be
detected.
*/
sleep(2);
while ((i = open(ttyn, O_RDWR)) == -1) {
--->8---
https://cvsweb.openbsd.org/src/libexec/getty/main.c?rev=1.51&content-type=text/x-cvsweb-markup
Nothing else has the serial line open (but it shouldn't matter anyway, as getty
uses revoke(2) on the device).
---8<---
# fstat | grep ttyU0
# fstat | grep cuaU0
#
--->8---
This little C program hangs too (stoppnig getty first obviously):
---8<---
#include <stdio.h>
#include <err.h>
#include <fcntl.h>
int
main(void)
{
printf("opening\n");
if (open("/dev/ttyU0", O_RDWR) == -1)
err(1, "open");
printf("open ok\n");
}
--->8---
When I kill the program with CTRL+C, a newline is sent to the client.
And the behaviour is the same for a:
```
uplcom0 at uhub3 port 3 configuration 1 interface 0 "Prolific Technology PL2303
Serial" rev 1.10/2.02 addr 2
ucom0 at uplcom0
```
The above C program does not hang on Soekris using /dev/tty00.
I can repro on 6.4-stable/amd64 and -current/amd64.
I'm out of ideas, so can anyone think of any reason why open(2) on /dev/ttyU0
might block indefinitely?
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
