>diff -r 041be3f6b38e tools/ioemu/hw/serial.c
>--- a/tools/ioemu/hw/serial.c Tue Sep 19 13:26:47 2006
>+++ b/tools/ioemu/hw/serial.c Tue Sep 19 15:47:11 2006
>@@ -160,7 +160,8 @@
> s->lsr &= ~UART_LSR_THRE;
> serial_update_irq(s);
> ch = val;
>- qemu_chr_write(s->chr, &ch, 1);
>+ if (qemu_chr_write(s->chr, &ch, 1) == -1)
>+ fprintf(logfile, "serial write error\n");
> s->thr_ipending = 1;
> s->lsr |= UART_LSR_THRE;
> s->lsr |= UART_LSR_TEMT;
>
>Doesn't the above mean we still drop the character? Shouldn't we be
>storing the character somewhere and retrying it later? We should
>probably also clear the tx ready bit (bit 5) in the UART's Line Status
>Register. We should then retry the write in ~100ms, and set the tx
ready
>bit again.
>
After timeout mechanism added, there isn't any character lost. In fact,
we don't see any character lost with timeout=50ms. So 100ms should be a
very safe value IMO. Print here is just for debug purpose, to indicate
system abnormity.
>
>diff -r 041be3f6b38e tools/ioemu/vl.c
>--- a/tools/ioemu/vl.c Tue Sep 19 13:26:47 2006
>+++ b/tools/ioemu/vl.c Tue Sep 19 15:47:11 2006
>@@ -1191,7 +1191,7 @@
> FD_ZERO(&writefds);
> FD_SET(fd, &writefds);
> timeout.tv_sec = 0;
>- timeout.tv_usec = 0;
>+ timeout.tv_usec = 100000;
> sel_ret = select(max_fd + 1, NULL, &writefds, 0, &timeout);
> if (sel_ret <= 0) {
> /* Timeout or select error */
>@@ -1674,7 +1674,8 @@
>
> tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
> |INLCR|IGNCR|ICRNL|IXON);
>- tty.c_oflag |= OPOST;
>+ tty.c_oflag &= ~OPOST;
>+
> tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
> tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS);
> switch(data_bits) {
>
>What does this part of the patch do? I don't know my tcsetattrs very
>well.
>
~OPOST disables output processing (e.g.: map NL to CR-NL on output).
With output and input processing both disabled, windbg host and target
can receive the raw data of the other end separately, and interpret them
in their own way.
Thanks,
Xiaowei
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|