blob: b84d619bfec158f8fa124c396a21eef39fff9725 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
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...
|