Hi Nicholas, songguozhi1234,
Seems that you guys have similar problem, and it happens
specifically on mips for both of you.
Please, read each other's mails quoted below,
and cooperate to find out what's going on.
> >On Friday 18 July 2008 11:05, [EMAIL PROTECTED] wrote:
> >> now, [cross-compiling HOWTO] working well under x86 processor.
> >>
> >> I modified it and rebuilt it for mips, however,it did not run well.
>
> OK, now I tell you with more details as following:
> I modified it and rebuilt it for mips.
> When the computer(processor is mips) run the kernel completely and then go to
> run the filesystem's INIT program, it does not print the message on terminal
> if I does not press any key. And later, it aways display the last times
> message on the terminal, but not the current message. for example:
> I input "ls", it outputs "l", and then I press the enter key, it outputs
> "ls", and I press enter key again, it execute the "ls command"...
> another instance is:
> I input "ping 127.0.0.1" and then press enter key two times, it outputs only
> several lines and stops, and then I press any key, it outputs another several
> lines and stops again. The amount of ouputed lines is related to the time of
> pressing key.
> Now, I consider that uclibc and busybox does not support mips.
> Thst's all!
> My thanks!
On Thursday 05 June 2008 11:07, Nicolas Dichtel wrote:
> Le 05.06.2008 02:46, Denys Vlasenko a écrit :
> > On Wednesday 04 June 2008 18:51, Nicolas Dichtel wrote:
> >> Hi all,
> >>
> >> I was using busybox-1.01 for a long time and recently I've switched to
> >> busybox-1.10.2. On x86, there is no problem, but on MIPS architecture,
> >> the console does not work properly: need to type second character to make
> >> the first appear.
> >
> > Please give more details. You need to type every char twice or what?
> No, when I type a char, the previous one is displayed (and not the current).
> Here is an example:
> #
> I type '1':
> #
> I type '2':
> #1
> I type '3':
> #12
> I type return:
> #123
>
> This problem appears before the login and after the login.
>
> > What program is receiving your keypresses? getty? shell? How exactly
> Before the login, it's getty and after it's bash (version 2.05.0).
> Started with /etc/inittab (sh is a link to bash):
> [EMAIL PROTECTED]:~# cat /etc/inittab
> ::sysinit:/bin/sh /etc/rc
> ::respawn:/sbin/getty -L 38400 ttyS0 vt100
> ::shutdown:/bin/sh /etc/rc.shutdown
>
> > do you start it (command line, etc)? Can you show ls -l /proc/$PID/fd
> > of this program and also ls -l /proc/1/fd?
> With the old busybox (after login on console):
> [EMAIL PROTECTED]:~# ls -l /proc/318/fd/
> lrwx------ 1 root root 64 Jan 1 00:00 0 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:08 1 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:00 2 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:08 255 -> /dev/ttyS0
> [EMAIL PROTECTED]:~# ls -l /proc/1/fd/
> [EMAIL PROTECTED]:~#
>
> With the new busybox:
>
> - getty (before login on console):
>
> root 325 0.0 0.0 3584 644 ttyS0 Ss+ 00:00 0:00 /sbin/getty
> -L
> 38400 ttyS0 vt100
>
> [EMAIL PROTECTED]:~# ls -l /proc/325/fd/
> lrwx------ 1 root root 64 Jan 1 00:02 0 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:02 1 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:01 2 -> /dev/ttyS0
>
> - bash (after login on console):
>
> root 325 0.0 0.0 4596 1356 ttyS0 Ss+ 00:00 0:00 -sh
>
> [EMAIL PROTECTED]:~# ls -l /proc/325/fd
> lrwx------ 1 root root 64 Jan 1 00:02 0 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:02 1 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:01 2 -> /dev/ttyS0
> lrwx------ 1 root root 64 Jan 1 00:06 255 -> /dev/ttyS0
>
> - init:
> [EMAIL PROTECTED]:~# ls -l /proc/1/fd/
> lrwx------ 1 root root 64 Jan 1 00:07 0 -> /dev/console
> lrwx------ 1 root root 64 Jan 1 00:07 1 -> /dev/console
> lrwx------ 1 root root 64 Jan 1 00:07 2 -> /dev/console
>
> >
> > Do you have any console=XXX or CONSOLE=XXX params on kernel command line?
> Kernel command line: console=ttyS0,38400 rdinit=/sbin/init
>
> >
> >> If I apply this patch:
> >>
> >> --- busybox/init/init.c 2008-04-17 11:13:25.000000000 +0200
> >> +++ busybox-new/init/init.c 2008-05-20 16:47:00.000000000 +0200
> >> @@ -873,6 +873,9 @@ int init_main(int argc ATTRIBUTE_UNUSED,
> >>
> >> /* Figure out where the default console should be */
> >> console_init();
> >> + close(0);
> >> + close(1);
> >> + close(2);
> >> set_sane_term();
> >> chdir("/");
> >> setsid();
> >>
> >> the problem is solved. Of course, some log messages are hidden with this
> >> patch.
> >> I didn't find a better way to fix that problem. Any ideas ?
> >
> > Sorry, but I don't like it. Not only you deprive all future children
> > from knowing what console is, you risk starting them with
> > stdio CLOSED - which is very bad, a lot of programs have bugs
> > where they overwrite random files if they are run with stdio closed.
> Sure that this patch is only a temporary work around ...
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
