diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/graphic/1368 | 68 | ||||
| -rw-r--r-- | results/classifier/118/graphic/1368178 | 99 |
2 files changed, 167 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1368 b/results/classifier/118/graphic/1368 new file mode 100644 index 00000000..421c11ff --- /dev/null +++ b/results/classifier/118/graphic/1368 @@ -0,0 +1,68 @@ +graphic: 0.963 +mistranslation: 0.952 +performance: 0.929 +device: 0.914 +debug: 0.913 +ppc: 0.909 +architecture: 0.820 +x86: 0.788 +vnc: 0.782 +hypervisor: 0.779 +semantic: 0.777 +assembly: 0.774 +boot: 0.755 +i386: 0.742 +KVM: 0.741 +kernel: 0.711 +risc-v: 0.694 +VMM: 0.678 +TCG: 0.664 +PID: 0.661 +user-level: 0.624 +network: 0.578 +socket: 0.537 +arm: 0.533 +peripherals: 0.506 +permissions: 0.503 +files: 0.439 +virtual: 0.389 +register: 0.335 + +unexpect rax value +Description of problem: +- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. +Steps to reproduce: +- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax + 0x2206 <vga_init+16>: movq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8: 0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede +Additional information: + diff --git a/results/classifier/118/graphic/1368178 b/results/classifier/118/graphic/1368178 new file mode 100644 index 00000000..bc402125 --- /dev/null +++ b/results/classifier/118/graphic/1368178 @@ -0,0 +1,99 @@ +graphic: 0.908 +peripherals: 0.881 +register: 0.861 +permissions: 0.857 +debug: 0.847 +assembly: 0.837 +architecture: 0.801 +user-level: 0.769 +mistranslation: 0.763 +device: 0.756 +PID: 0.753 +network: 0.689 +boot: 0.682 +risc-v: 0.679 +kernel: 0.670 +VMM: 0.660 +files: 0.650 +socket: 0.647 +hypervisor: 0.634 +ppc: 0.625 +performance: 0.624 +TCG: 0.617 +semantic: 0.603 +arm: 0.596 +virtual: 0.580 +vnc: 0.550 +KVM: 0.507 +i386: 0.462 +x86: 0.462 + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 + +A fresh installation of Windows Millennium Edition (Windows ME, WinME) as guest OS on qemu interprets qemu's videocards as Number Nine Imagine 128 with the consequence, that + +1. It is impossible to change color depth. +2. WinME uses the i128.drv Driver that is shipped with WinMe. +3. Forcing WinME to use other drivers has no effect. + + +It also doesn't matter what option for -vga was given to QEMU at command line. +cirrus, std, vmware, qxl etc. all have no effect, the videocard detected by Windows Me stays at Number Nine Imagine 128. + +Even selecting another driver in WinME and forcing WinME to use drivers such as the Cirrus Logic 5446 PCI driver has no effect. + +I also want to mention, that the BIOS isn't detected by WinME properly. +The device manager of WinME shows errors with the Plug & Play BIOS driver BIOS.vxd. + + +That is the QEMU Version: + +# qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard + +And this was the complete command line, that was given: +# sudo /usr/bin/qemu-system-i386 -hda WinME_QEMU.img -cdrom drivers.iso -boot c -no-acpi -no-hpet -soundhw sb16 -net nic -cpu pentium3 -m 256 -vga cirrus + + + +Here's a picture of the allowed color depth. +As long as the videocard isn't detected properly, using another driver won't help and without another driver the color depth stays at 16 colors. + + +Here's a screenshot of the driver problem, that WinME shows up. +It says error "code 23", whatever that means. + + +In console mode, info pci gives the following information (see attachted screenshot) + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I am still using Kubuntu 16.04.3 LTS and that is shipped with QEMU 2.5.0 + +# qemu-system-i386 --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16) + +I am not planning to go into the hassle to install QEMU latest on 16.04.3 LTS. + +Could you delay the closing of the ticket until Kubuntu 18.04 LTS is released? +Then i could test it with the QEMU version that will be shipped with Kubuntu 18.04 LTS. + +As an alternative, i could also do the test with QEMU 2.5 instead. + + +Addition to my last comment. + +Ubuntu 17.10 is now shipped with QEMU 2.10. Thus we can expect that 18.04 LTS will be shipped with QEMU 2.10 or later, too. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/108 + + +Oliver, did you ever check this with a newer version of QEMU? + |