blob: 60eebde7b43d8e9757522083c4391103a525c43c (
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
|
id = 2198
title = "Unable to run OS/2 Warp4.52"
state = "closed"
created_at = "2024-02-28T09:01:27.043Z"
closed_at = "2024-06-08T20:18:43.735Z"
labels = ["accel: TCG", "guest::os2", "target: i386", "workflow::Patch available"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/2198"
host-os = "OS/2 Warp4.52 (or Warp4 + fixpack15)"
host-arch = "x86 (Linux Debian) and ARM (Android)"
qemu-version = "8.0.2 (Android/Termux) and 5.0.2 (Debian 1:5.2+dfsg-11+deb11u3)"
guest-os = "OS/2 Warp4.52 (or Warp4 + fixpack15)"
guest-arch = "x86"
description = """Operating system crashes upon boot."""
reproduce = """1. Install OS/2 Warp4
2. Apply Fixpack15
3. Try to boot the system"""
additional = """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."""
|