From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BxkpF-0004lR-JN for qemu-devel@nongnu.org; Thu, 19 Aug 2004 07:11:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BxkpE-0004l4-00 for qemu-devel@nongnu.org; Thu, 19 Aug 2004 07:11:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BxkpD-0004l1-Ox for qemu-devel@nongnu.org; Thu, 19 Aug 2004 07:11:19 -0400 Received: from [203.9.177.36] (helo=mailhost.chh.co.nz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bxkkv-0007jQ-HQ for qemu-devel@nongnu.org; Thu, 19 Aug 2004 07:06:54 -0400 From: Darryl Dixon Content-Type: multipart/alternative; boundary="=-snQPSLu+kWo8kLWg3bWO" Message-Id: <1092913600.6010.13.camel@localhost.localdomain> Mime-Version: 1.0 Date: Thu, 19 Aug 2004 23:06:40 +1200 Subject: [Qemu-devel] Serial port UART emulation apparently buggy Reply-To: esrever_otua@pythonhacker.is-a-geek.net, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --=-snQPSLu+kWo8kLWg3bWO Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi All, Rather than continue one of the many previous threads I thought I'd start again, as I have actually made some minor progress in the effort to make the serial port emulation work correctly in qemu. I am as certain as I can be that the UART emulation coded in serial_ioport_write() and (maybe) serial_ioport_read() contains some bugs or flaws in its logic regarding which registers and which bitmasks get applied at any given time. After extensive debugging via the magic of fprintf and my own new function to dump the state of the SerialState object at various appropriate times, here's what I see: serial_ioport_read() appears to be work correctly(?) serial_ioport_write() appears to not set some of its bitmasks in *at least* the ier register correctly after the first attempt to write some data. This borks it for the remainder of any terminal session in the guest, until it is reinitialised. Specifically, I noticed that it seems to leave the THRI bit set in ier after having written data. When I add this line: ----------------8<------------------- s->thr_ipending = 1; s->lsr |= UART_LSR_THRE; s->lsr |= UART_LSR_TEMT; + s->ier &= ~UART_IER_THRI; serial_update_irq(s); ----------------8<------------------- to serial_ioport_write things start looking much more promising. A guest terminal session now works (I am able to get the modem on my host, which is connected to /dev/ttySL0 to dial another phone successfully from a terminal session inside the guest), but only in 'no flow control' mode. I assume that means that there are other registers not being flipped at the right time too, but I haven't found them yet. I will poke the code some more, and probably send a proper patch containing this fix(?) and some of my debug stuff ifdef'ed out once I've cleaned my test area up a bit. Anyhow, just thought I'd share :) Cheers, -- Darryl Dixon --=-snQPSLu+kWo8kLWg3bWO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi All,

Rather than continue one of the many previous threads I thought I'd start again, as I have actually made some minor progress in the effort to make the serial port emulation work correctly in qemu. I am as certain as I can be that the UART emulation coded in serial_ioport_write() and (maybe) serial_ioport_read() contains some bugs or flaws in its logic regarding which registers and which bitmasks get applied at any given time. After extensive debugging via the magic of fprintf and my own new function to dump the state of the SerialState object at various appropriate times, here's what I see:
serial_ioport_read() appears to be work correctly(?)
serial_ioport_write() appears to not set some of its bitmasks in *at least* the ier register correctly after the first attempt to write some data. This borks it for the remainder of any terminal session in the guest, until it is reinitialised. Specifically, I noticed that it seems to leave the THRI bit set in ier after having written data. When I add this line:
----------------8<-------------------
s->thr_ipending = 1; s->lsr |= UART_LSR_THRE; s->lsr |= UART_LSR_TEMT; + s->ier &= ~UART_IER_THRI; serial_update_irq(s);
----------------8<-------------------
to serial_ioport_write things start looking much more promising. A guest terminal session now works (I am able to get the modem on my host, which is connected to /dev/ttySL0 to dial another phone successfully from a terminal session inside the guest), but only in 'no flow control' mode. I assume that means that there are other registers not being flipped at the right time too, but I haven't found them yet. I will poke the code some more, and probably send a proper patch containing this fix(?) and some of my debug stuff ifdef'ed out once I've cleaned my test area up a bit. Anyhow, just thought I'd share :)

Cheers,

--
Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>

--=-snQPSLu+kWo8kLWg3bWO--