Hi, there are two lines, which should be inserted into ip22zilog.c, to make the serial-console work on IP2[82] as expected: --- snip --------------------------------------------------------------- --- ip22zilog.c Fri Dec 3 06:07:38 2004 +++ ip22zilog.c Mon Dec 20 02:07:42 2004 @@ -881,6 +881,7 @@ up->cflag = termios->c_cflag; ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port)); + uart_update_timeout(port, termios->c_cflag, baud); spin_unlock_irqrestore(&up->port.lock, flags); } @@ -1047,6 +1048,8 @@ } con->cflag = cflag | CS8; /* 8N1 */ + + uart_update_timeout(&ip22zilog_port_table[con->index].port, cflag, baud); } static int __init ip22zilog_console_setup(struct console *con, char *options) --- snap --------------------------------------------------------------- The reason for this can be found in drivers/serial/serial_core.c and drivers/char/tty_ioctl.c (at least up to 2.6.10-rc2 / Rev. 1.13 and 1.20 respective): 1) serial_core.c: If port->timeout is less than HZ/50, a huge per character timeout 'char_time' will be calculated in uart_wait_until_sent(struct tty_struct*, int timeout). 2) (64bit only) tty_ioctl.c: tty_wait_until_sent(struct tty_struct*, long timeout) will call tty->driver->wait_until_sent() (->uart_wait_until_sent()) with a long timeout argument. So far, this is not critical, as long as all other relevant variables in uart_wait_until_sent() are unsigned... Whenever port->ops->tx_empty() (ip22zilog_tx_empty()) doesn't succeed in the first attempt, a msleep_interruptible(jiffies_to_msecs(char_time)) will be done (yes, this case isn't negligibly rare) ... Two consequences could be observed: 1) 'timeout' is in the positive int range (here 30000) and will override the huge 'char_time' value. This leads to (e.g.) some nice 30sec delays in init. 2) ioctl(0,TCSETSF,...) makes tty_wait_until_sent() call tty->driver->wait_until_sent(tty,MAX_SCHEDULE_TIMEOUT), i.e. uart_wait_until_sent(tty,-1). Now the huge 'char_time' takes effect, sending login to sleep, until it receives a SIGALRM, thus making a console-login impossible. Since the majority of the serial drivers do not uart_update_timeout(), it might be preferable to make uart_wait_until_sent() fool-proof (only a couple of additional statements), instead of changing ip22zilog.c (alone), but i'm in doubt, whether these changes would find their way. with kind regards pf PS: in general, 2.6.10-rc2 + current linux-mips.org/arch/mips seems to be far less hostile to IP28, than 2.6-version(s), i toiled with before :-)
