qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Serial port UART emulation apparently buggy
Date: Thu, 19 Aug 2004 23:06:40 +1200	[thread overview]
Message-ID: <1092913600.6010.13.camel@localhost.localdomain> (raw)

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

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>

[-- Attachment #2: Type: text/html, Size: 2821 bytes --]

             reply	other threads:[~2004-08-19 11:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-19 11:06 Darryl Dixon [this message]
2004-08-19 14:06 ` [Qemu-devel] Serial port UART emulation apparently buggy Darryl Dixon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1092913600.6010.13.camel@localhost.localdomain \
    --to=esrever_otua@pythonhacker.is-a-geek.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).