[Qemu-devel] PATCH: serial.c
Hi, According to the documentation, reading IIR does not reset any pending interrupt. This issue caused VxWorks to freeze. Tristan. *** hw/serial.c 31 Mar 2007 16:54:14 - 1.15 --- hw/serial.c 4 May 2007 12:49:34 - *** *** 233,242 break; case 2: ret = s-iir; - /* reset THR pending bit */ - if ((ret 0x7) == UART_IIR_THRI) - s-thr_ipending = 0; - serial_update_irq(s); break; case 3: ret = s-lcr; --- 233,238
RE: [Qemu-devel] PATCH: serial.c
Tristan, I do not believe that is actually the problem, and arguably QEMU is correct with timing accuracy set aside. The root of the issue is a more of a timing problem because the clear/set can happen atomically in QEMU with respect to the cpu clock vs the real hardware which takes multiple clock cycles for this to happen. Even Linux can fall victim to this with heavy printk (if you have ever seen the message too much work for interrupt). You should instead consider fixing the BSP i8250Sio.c, because it clears reads the iir and jumps out of the main serial loop if there is if it has done enough work, vs checking if it has done enough work and jumping out of the loop before reading the iir. As an FYI for VxWorks 6.4 and up it is fixed there and you can request a patch through the normal channels (not the QEMU developer list). Also the fix you suggested would certainly allow you to run a VxWorks image, but the BSP will never take a break (power save), because the interrupt service routine for the rs232 will be called over and over until the work limit expires and the BSP is permitted to so something else. Cheers, Jason. -Original Message- From: On Behalf Of Tristan Gingold Sent: Friday, May 04, 2007 7:52 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] PATCH: serial.c Hi, According to the documentation, reading IIR does not reset any pending interrupt. This issue caused VxWorks to freeze. Tristan.
Re: [Qemu-devel] PATCH: serial.c
On May 4, 2007, at 3:34 PM, Wessel, Jason wrote: Tristan, I do not believe that is actually the problem, and arguably QEMU is correct with timing accuracy set aside. The root of the issue is a more of a timing problem because the clear/set can happen atomically in QEMU with respect to the cpu clock vs the real hardware which takes multiple clock cycles for this to happen. Even Linux can fall victim to this with heavy printk (if you have ever seen the message too much work for interrupt). I think this is a different issue: QEMU serial baudrate is almost infinite and linux interrupt handler detects IRQ storm IIRC. You should instead consider fixing the BSP i8250Sio.c, because it clears reads the iir and jumps out of the main serial loop if there is if it has done enough work, vs checking if it has done enough work and jumping out of the loop before reading the iir. I don't agree because IIR is not cleared when read. Yes the handler first reads IIR and then jump out of the loop if it has done enough work but the interrupt is not cleared (because the xmit register is still empty) and cpu should enter into the interrupt function as soon as the interrupts are still enabled. IMHO changing the code (ie inverting the tests) is a (valuable) work- around. Tristan.
