Phil Wilshire wrote: > minicom -o > will stop the AT commands being issued.
Thanks for the tip, Phil. But I am more concerned about the actual bug. > I would fix the linux driver to stop the race. Since there's no hope that NXP will fix the problem, this is the only way to go. The primary questions are: - Is this problem limited to NXP or are other chips affected and nobody noticed? In other words: should this fix be specific to NXP or more general? - How to fix it properly? Currently, I tend to call receive-chars() not only when UART_LSR_DR is set, but also when UART_IIR_RDI is set. After all, the receive interrupt signals that data is available. Please check attached patch. It works fine with the lpc2214 chip. And it should (IMHO) not break anything because an asserted RDI actually signals that data is available. - Finally the most important question: should the patch be integrated in the official sources? I think it should be safe to integrate it. diff -urw linux-2.4.32.orig/drivers/char/serial.c linux-2.4.32/drivers/char/serial.c --- linux-2.4.32.orig/drivers/char/serial.c 2007-10-17 14:43:41.000000000 +0200 +++ linux-2.4.32/drivers/char/serial.c 2007-10-17 15:19:39.000000000 +0200 @@ -1118,7 +1118,7 @@ #ifdef SERIAL_DEBUG_INTR printk("status = %x...", status); #endif - if (status & UART_LSR_DR) + if ((status & UART_LSR_DR) || (iir & UART_IIR_RDI)) receive_chars(info, &status, regs); check_modem_status(info); #ifdef CONFIG_MELAN @@ -1131,7 +1131,7 @@ transmit_chars(info, 0); #endif if (pass_counter++ > RS_ISR_PASS_LIMIT) { -#if SERIAL_DEBUG_INTR +#ifdef SERIAL_DEBUG_INTR printk("rs_single loop break.\n"); #endif break; _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev