blob: 15ab24141466ee85c7771aed59729a691eb4d184 (
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
|
graphic: 0.859
permissions: 0.842
boot: 0.817
device: 0.801
network: 0.799
architecture: 0.788
semantic: 0.762
ppc: 0.662
performance: 0.655
mistranslation: 0.644
register: 0.618
socket: 0.613
i386: 0.540
vnc: 0.516
debug: 0.487
peripherals: 0.465
kernel: 0.461
KVM: 0.461
PID: 0.450
files: 0.418
user-level: 0.394
virtual: 0.387
arm: 0.380
hypervisor: 0.373
risc-v: 0.372
VMM: 0.286
x86: 0.279
TCG: 0.277
assembly: 0.181
Unable to run OS/2 Warp4.52
Description of problem:
Operating system crashes upon boot.
Steps to reproduce:
1. Install OS/2 Warp4
2. Apply Fixpack15
3. Try to boot the system
Additional information:
This is a very old bug that seems to render a whole family of Operating Systems (OS/2 Warp4 and eComStation) unusable under Qemu.
Warp4 works, in the sense that it does install and run, but just until it is updated to 4.52 (which is necessary to get a useable guest)
I found traces of its existence as far as:
https://bugs.launchpad.net/qemu/+bug/1743441
https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg02337.html
And i found the issue brieffly commented at https://www.os2world.com/forum/index.php?topic=2346.0
I quote:
'Regarding QEMU/KVM, OS/2 runs in QEMU mostly fine. Except the trap in os2lvm.dmd and non-working netbeui.os2 and
tcpbeui.os2. The problem with os2lvm.dmd is because QEMU closely follows the intel spec, which is incorrect. The spec says
that 16-bit SGDT instruction behaves the same like in i286 processor. But it's not true, it behaves like i386 instruction. So, QEMU
emulates SGDT 16-bit instruction incorrectly. OS2LVM.DMD uses 16-bit SGDT instruction and it hits the problem.'
After a brief discussion on the Warp4 group at groups.io where I was told that this is indeed a Qemu bug, I thought someone has
to report on that.
|