diff options
Diffstat (limited to 'results/classifier/118/debug/588748')
| -rw-r--r-- | results/classifier/118/debug/588748 | 91 |
1 files changed, 91 insertions, 0 deletions
diff --git a/results/classifier/118/debug/588748 b/results/classifier/118/debug/588748 new file mode 100644 index 00000000..b84d619b --- /dev/null +++ b/results/classifier/118/debug/588748 @@ -0,0 +1,91 @@ +debug: 0.841 +device: 0.833 +socket: 0.830 +kernel: 0.830 +hypervisor: 0.794 +ppc: 0.794 +network: 0.787 +boot: 0.785 +PID: 0.751 +performance: 0.726 +arm: 0.698 +peripherals: 0.691 +graphic: 0.685 +architecture: 0.680 +permissions: 0.675 +register: 0.665 +user-level: 0.640 +semantic: 0.634 +vnc: 0.618 +TCG: 0.615 +files: 0.605 +mistranslation: 0.602 +risc-v: 0.602 +VMM: 0.583 +x86: 0.560 +assembly: 0.519 +virtual: 0.512 +i386: 0.501 +KVM: 0.471 + +QEMU fails to boot DR DOS Plus since 0.6.1 + +The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting Digital Research DOS Plus. + + + +This patch doesn't seem correct as the spec is pretty clear that THRE interrupt enable is set to high, then an interrupt is rased if LSR.THRE=1. Does the following also make DOSPlus boot again: + + +diff --git a/hw/serial.c b/hw/serial.c +index 9102edb..b0ac52f 100644 +--- a/hw/serial.c ++++ b/hw/serial.c +@@ -401,7 +401,8 @@ static void serial_ioport_write(void *opaque, uint32_t addr, + s->poll_msl = 0; + } + } +- if (s->lsr & UART_LSR_THRE) { ++ if (s->ier & UART_IER_THRI && ++ s->lsr & UART_LSR_THRE) { + s->thr_ipending = 1; + serial_update_irq(s); + } + + +> This patch doesn't seem correct as the spec is pretty clear that THRE interrupt enable is set to high, then an interrupt is rased if LSR.THRE=1. Does the following also make DOSPlus boot again: + +No it doesn't. Same as unpatched. + +Can you add some debugging to see what IER is being set to? + +Do you have any insight into why DR DOS Plus is failing? + +> Can you add some debugging to see what IER is being set to? + +With DEBUG_SERIAL defined, serial logs: +serial: event 2 +serial: write addr=0x01 val=0x02 +serial: read addr=0x01 val=0x02 +serial: read addr=0x02 val=0x02 +serial: write addr=0x01 val=0x00 +serial: write addr=0x03 val=0x80 +serial: write addr=0x00 val=0x0c +serial: write addr=0x01 val=0x00 +serial: write addr=0x03 val=0x03 +serial: write addr=0x04 val=0x0b +serial: read addr=0x05 val=0x60 +serial: read addr=0x06 val=0xb0 +serial: read addr=0x00 val=0x00 +serial: write addr=0x01 val=0x0f +serial: read addr=0x02 val=0x02 +serial: read addr=0x02 val=0x01 +(stalls here) + +I think the interrupt should be raised only on the rising edge of THRE. + +Has this bug been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1645b8eee558ffe2389 +? +If so, I think we could now close this bug ticket... + |