* Peter Crosthwaite ([email protected]) wrote:
> On Tue, Feb 4, 2014 at 4:45 AM, Dr. David Alan Gilbert
> <[email protected]> wrote:
> > (cc'ing in Peter Crosthwaite and Michael Tokarev due to a serial fifo change
> > - see below!)
> >
> > * Martin Kletzander ([email protected]) wrote:
> >> Hello,
> >
> > Hi Martin,
> > I don't know about your spice warnings that triggered this but looking
> > down the backtrace I can see something odd:
> >
> >> current HEAD (2f61120c10da9128357510debc8e66880cd2bfdc) segfaults when
> >> I'm trying to do the following:
> >>
> >> I add this to qemu's command-line:
> >>
> >> -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0 \
> >> -device isa-serial,chardev=charserial0,id=serial0
<snip>
> Hi Dave,
>
> Yes that does looks suss. My bad. Can you confirm your theory by
> making the proposed change? does it fix the bug?
>
> --- a/hw/char/serial.c
> +++ b/hw/char/serial.c
> @@ -225,7 +225,7 @@ static gboolean serial_xmit(GIOChannel *chan,
> GIOCondition cond, void
>
> if (s->tsr_retry <= 0) {
> if (s->fcr & UART_FCR_FE) {
> - s->tsr = fifo8_is_full(&s->xmit_fifo) ?
> + s->tsr = fifo8_is_empty(&s->xmit_fifo) ?
> 0 : fifo8_pop(&s->xmit_fifo);
> if (!s->xmit_fifo.num) {
> s->lsr |= UART_LSR_THRE;
Yep, seems reasonable; and Martin says it stops the seg;
I wonder if there are any serial tests out there - The other
failure mode this could have caused is the replacing of chunks
of outbound data by \0's if the fifo was full.
Dave
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
