Jeff "Tiny" Warren
2004-09-10 01:14:06 UTC
Hello All,
I am asking this here even though this may technically be a busybox
question to see if anyone has run into this problem before and fixed it.
I am using the AT91RM9200dk dev board successfully with a
uClibc 0.9.26 toolchain (gcc 3.3.4) and the 2.4.25 with the vrs-1 and
the low latency patch. I can log in and it works great except I get this
warning when I boot up(can't access tty; job control turned off).
I am currently not calling a login process, so when it boots up I am at
the command prompt and don't have to supply a password.
The code in busybox that shows this message is in ash.c,line 6480:
void
setjobctl(int on)
{
int fd;
int pgrp;
if (on == jobctl || rootshell == 0)
return;
if (on) {
int ofd;
ofd = fd = open(_PATH_TTY, O_RDWR);
if (fd < 0) {
fd += 3;
while (!isatty(fd) && --fd >= 0)
;
}
fd = fcntl(fd, F_DUPFD, 10);
close(ofd);
if (fd < 0)
goto out;
fcntl(fd, F_SETFD, FD_CLOEXEC);
do { /* while we are in the background */
if ((pgrp = tcgetpgrp(fd)) < 0) {
out:
sh_warnx("pgrp:%d ,expected:%d, fd:%d",pgrp,getpgrp(),fd);
sh_warnx("can't access tty; job control turned off");
mflag = on = 0;
goto close;
}
if (pgrp == getpgrp())
break;
killpg(0, SIGTTIN);
} while (1);
initialpgrp = pgrp;
...
I added the sh_warnx("pgrp:%d ,expected:%d, fd:%d",pgrp,getpgrp(),fd);
to see if I could see if there is anything grossly wrong and what I see
on the command line is:
-ash: pgrp:-1 ,expected:34, fd:10
-ash: can't access tty; job control turned off
The function tcgetpgrp in uClibc(0.9.26) is small, but I don't know too
much about ioctl stuff yet, so I am not absolutely sure what it is doing
except that it is asking for the process group id.
termios.c line 102
/* Return the foreground process group ID of FD. */
pid_t tcgetpgrp ( int fd)
{
int pgrp;
if (ioctl (fd, TIOCGPGRP, &pgrp) < 0)
return (pid_t) -1;
return (pid_t) pgrp;
}
Obviously the ioctl call is failing, but I don't know why.
Just to be complete, here is my inittab file, with a few things I have
tried (without success) commented out. One of those lines was added
from the BusyBox mail archives, but it did not help.
# /etc/inittab: for BusyBox 1.0rc3
# $Id: inittab,v 1.6 1997/01/30 15:03:55 miquels Exp $
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
#::wait:/etc/init.d/syslog
::sysinit:/etc/init.d/rcS
#::wait:/etc/init.d/tty
#::wait:/etc/init.d/rtc
#::respawn:/sbin/getty ttyS0 115200 vt100
#vc/1::askfirst:/sbin/getty 115200 /dev/vc/1
::askfirst:-/bin/ash
::respawn:/usr/sbin/inetd -i
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
the rcS file doesn't do anything with the tty's.
I believe all of the tty permissions and groups are set correctly in the
dev folder. I just followed the Ramdisk for the AT91RM9200DK and how
that was setup.
If I run tty on the command, it returns /dev/ttyS0, which is what I
expect
I can communicate and the board works fine. Maybe I just leave it as is
and not worry about it?
If it has an unintended effect, I would like to fix it if anyone knows
how.
Thanks,
Jeff Warren
-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ/Etiquette: http://www.arm.linux.org.uk/armlinux/mailinglists.php
I am asking this here even though this may technically be a busybox
question to see if anyone has run into this problem before and fixed it.
I am using the AT91RM9200dk dev board successfully with a
uClibc 0.9.26 toolchain (gcc 3.3.4) and the 2.4.25 with the vrs-1 and
the low latency patch. I can log in and it works great except I get this
warning when I boot up(can't access tty; job control turned off).
I am currently not calling a login process, so when it boots up I am at
the command prompt and don't have to supply a password.
The code in busybox that shows this message is in ash.c,line 6480:
void
setjobctl(int on)
{
int fd;
int pgrp;
if (on == jobctl || rootshell == 0)
return;
if (on) {
int ofd;
ofd = fd = open(_PATH_TTY, O_RDWR);
if (fd < 0) {
fd += 3;
while (!isatty(fd) && --fd >= 0)
;
}
fd = fcntl(fd, F_DUPFD, 10);
close(ofd);
if (fd < 0)
goto out;
fcntl(fd, F_SETFD, FD_CLOEXEC);
do { /* while we are in the background */
if ((pgrp = tcgetpgrp(fd)) < 0) {
out:
sh_warnx("pgrp:%d ,expected:%d, fd:%d",pgrp,getpgrp(),fd);
sh_warnx("can't access tty; job control turned off");
mflag = on = 0;
goto close;
}
if (pgrp == getpgrp())
break;
killpg(0, SIGTTIN);
} while (1);
initialpgrp = pgrp;
...
I added the sh_warnx("pgrp:%d ,expected:%d, fd:%d",pgrp,getpgrp(),fd);
to see if I could see if there is anything grossly wrong and what I see
on the command line is:
-ash: pgrp:-1 ,expected:34, fd:10
-ash: can't access tty; job control turned off
The function tcgetpgrp in uClibc(0.9.26) is small, but I don't know too
much about ioctl stuff yet, so I am not absolutely sure what it is doing
except that it is asking for the process group id.
termios.c line 102
/* Return the foreground process group ID of FD. */
pid_t tcgetpgrp ( int fd)
{
int pgrp;
if (ioctl (fd, TIOCGPGRP, &pgrp) < 0)
return (pid_t) -1;
return (pid_t) pgrp;
}
Obviously the ioctl call is failing, but I don't know why.
Just to be complete, here is my inittab file, with a few things I have
tried (without success) commented out. One of those lines was added
from the BusyBox mail archives, but it did not help.
# /etc/inittab: for BusyBox 1.0rc3
# $Id: inittab,v 1.6 1997/01/30 15:03:55 miquels Exp $
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
#::wait:/etc/init.d/syslog
::sysinit:/etc/init.d/rcS
#::wait:/etc/init.d/tty
#::wait:/etc/init.d/rtc
#::respawn:/sbin/getty ttyS0 115200 vt100
#vc/1::askfirst:/sbin/getty 115200 /dev/vc/1
::askfirst:-/bin/ash
::respawn:/usr/sbin/inetd -i
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
the rcS file doesn't do anything with the tty's.
I believe all of the tty permissions and groups are set correctly in the
dev folder. I just followed the Ramdisk for the AT91RM9200DK and how
that was setup.
If I run tty on the command, it returns /dev/ttyS0, which is what I
expect
I can communicate and the board works fine. Maybe I just leave it as is
and not worry about it?
If it has an unintended effect, I would like to fix it if anyone knows
how.
Thanks,
Jeff Warren
-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ/Etiquette: http://www.arm.linux.org.uk/armlinux/mailinglists.php