On Sun, May 23, 2010 at 5:30 AM, Denys Vlasenko
<[email protected]> wrote:
> On Friday 21 May 2010 04:28, John Williams wrote:
>> Hi,
>>
>> I'm running a pure BusyBox v1.14.3 rootfs on a PPC440 environment, and
>> am seeing some strange behaviour at the initial login prompt. Console
>> device is a Xilinx uartlite (mainline driver 2.6.31-stable) on
>> /dev/ttyUL0
>>
>> Here's inittab:
>>
>> ~ # cat /etc/inittab
>> ::sysinit:/etc/rc.sysinit
>> ::shutdown:/etc/rc.reboot
>> ::ctrlaltdel:/sbin/reboot
>> ttyUL0::respawn:/bin/getty -L 115200 ttyUL0 vt100
>> ::respawn:/bin/syslogd -n
>> ::respawn:/bin/flatfsd
>> ::sysinit:/bin/inetd /etc/inetd.conf
>
> Try experimenting with adding string "null" as tty
> for last three lines, anstead of leaving it empty.
Success! This resolves the local echo of the username and need to ^D
the getty/login prompts. I gave each inittab entry null tty (except
rc.sysinit) just to be sure.
However, I still see the race between 'cat /etc/motd' with the getty
login - see below
>> Here's the last bit of my boot log
>>
>> Sending select for 192.168.0.6...
>> Lease of 192.168.0.6 obtained, lease time 259200
>> adding dns 192.168.0.1
>> Starting portmap:
>>
>> Xilinx-ML507-PPC-lite login: root
>> root
>> Password:
>> <looooong pause>
>> <hit ^D>
>> ~ # whoami
>> root
>>
>> Note how when getty gets the login name, it's being echoed to the
>> console. And, after I enter the password, it just sits until I hit
>> ^D, then I'm logged in successfully.
>>
>> Job control or termio issues maybe?
>
> Looks like termio problem - something messed with console's termio.
>
>
>> Some other observations -
>> * if I hit ^D immediately at the login: prompt, it pauses a few
>> seconds (I think for init to respawn getty), then I see this:
>>
>> Xilinx-ML507-PPC-lite login: <Ctrl-D>
>> getty: ttyUL0: read: No such file or directory
>
> likely caused by:
>
> /* Do not report trivial EINTR/EIO errors. */
> if (read(STDIN_FILENO, &c, 1) < 1) {
> if (errno == EINTR || errno == EIO)
> exit(EXIT_SUCCESS);
> bb_perror_msg_and_die("%s: read", op->tty);
> }
>
> Need to account for the possibility of read of 0 bytes!
> (I just fixed it in git)
OK, thanks.
>> <wait a few seconds>
>> Xilinx-ML507-PPC-lite login:
>>
>> This re-spawned getty works fine - no local echo of the username, no
>> strange hangups etc.
>
> Because it properly resets termio, overwriting broked setting.
>
>
>> * If I 'cat /etc/motd' at the end of my rc.sysinit script, the MOTD
>> output gets truncated (last line incomplete or missing), instead it is
>> interrupted by the login: prompt. It's like there's some kind of race
>> between the init scripts and getty.
>
> Yes. Check your /etc/rc.sysinit that it does not start
> something in background so that this "something" runs even
> after /etc/rc.sysinit exits (and then init proceeds to start
> respawn services); or all backgrounded processes are properly
> isolated. Instead of simple:
>
> command args &
>
> do something like:
>
> setsid command args </dev/null >/dev/null 2>&1 &
>
> bacause bare "command args &" retains stdin/out/err of the parent
> (which is /dev/console == /dev/ttyUL0 in your case)
> and if it, or one of its children, plays with termio settings
> of stdin/out/err, it affects it _globally_.
OK - thanks for the info.
The last line of /etc/rc.sysinit is
cat /etc/motd
The last 30 or so chars of the motd are not displayed - getty races and wins.
If rc.sysinit has a short sleep after cat /etc/motd (like sleep 0.1)
it all comes out fine.
Maybe getty is starting, and resetting the tty before the serial
driver has drained the buffer?
Is there a more robust startup sequence that can make sure that
rc.sysinit completes before getty starts up?
BTW I rebuilt this system with a uart16550 serial port instead, and
the same issue occurs.
Thanks for your help,
John
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
