diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
| commit | d0c85e36e4de67af628d54e9ab577cc3fad7796a (patch) | |
| tree | f8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/peripherals | |
| parent | 7f4364274750eb8cb39a3e7493132fca1c01232e (diff) | |
| download | qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip | |
add deepseek and gemma results
Diffstat (limited to 'results/classifier/gemma3:12b/peripherals')
452 files changed, 10536 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/peripherals/1000 b/results/classifier/gemma3:12b/peripherals/1000 new file mode 100644 index 000000000..70c9044c6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1000 @@ -0,0 +1,5 @@ + +Can qemu support different core on one machine? +Description of problem: +I want to build a machine, including three core which is different types, arm Cortex-M3 core, cortex-m33 core, contex-a53 core, communicate through mailbox. I checked the current implementation of QEMU and saw that a machine uses a core, such as mps2.c virt.c . I want to know whether the QEMU strategy supports different types of cores on one machine and can communicate with each other. +Thanks. diff --git a/results/classifier/gemma3:12b/peripherals/1004050 b/results/classifier/gemma3:12b/peripherals/1004050 new file mode 100644 index 000000000..a0e0bb8c7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1004050 @@ -0,0 +1,17 @@ + +qemu-system-ppc64 by default has non-working keyboard + +Compile qemu from git and do: + + ./ppc64-softmmu/qemu-system-ppc64 + +(ie. no parameters). It boots to an OpenBIOS prompt. However the keyboard doesn't work. After ~10 keypresses, qemu just says: + +usb-kbd: warning: key event queue full +usb-kbd: warning: key event queue full +usb-kbd: warning: key event queue full +usb-kbd: warning: key event queue full + +There is no indication inside the guest that OpenBIOS is seeing keyboard events. + +Also there's no indication of what type of keyboard devices are available, nor what we should use. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1014 b/results/classifier/gemma3:12b/peripherals/1014 new file mode 100644 index 000000000..04c0b9ae0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1014 @@ -0,0 +1,4 @@ + +Make -chardev, -serial and others accept stderr like they accept stdio +Additional information: +It's not clear what should happen when the guest tries to read from (instead of write to) the character device. On the other hand, I don't think the specific behavior matters very much. diff --git a/results/classifier/gemma3:12b/peripherals/102 b/results/classifier/gemma3:12b/peripherals/102 new file mode 100644 index 000000000..92fa86c86 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/102 @@ -0,0 +1,2 @@ + +Mouse stops working when connected usb-storage-device diff --git a/results/classifier/gemma3:12b/peripherals/1020309 b/results/classifier/gemma3:12b/peripherals/1020309 new file mode 100644 index 000000000..bdf229ffd --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1020309 @@ -0,0 +1,18 @@ + +qemu-system-ppc: no keyboard after savevm/loadvm + +Here the steps to reproduce: + +1. qemu-img create -f qcow2 test.qcow2 100M +2. qemu-system-ppc -m 1024 -hda test.qcow2 +3. change to the console via Ctrl-Alt-2 and save a snapshot: "savevm test" +4. quit +5. start again and go to the console +6. load the snapshot via "loadvm test" +7. change back to the guest display (Ctrl-Alt-1) +8. try to type something => no keyboard +9. the same via console, e.g. "sendkey 1" has no effect + +I tried the following branches from git: +master, stable-1.0, stable-0.15 +=> all behave the same \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1031955 b/results/classifier/gemma3:12b/peripherals/1031955 new file mode 100644 index 000000000..3b05d4286 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1031955 @@ -0,0 +1,36 @@ + +qemu-system-arm -M lm3s811evb fails + +I am trying out examples from StellarisWare. + +When I try the uart_echo example, that initially tries to talk to the +display, I get this: + + $ .../qemu-1.1.1/bin/qemu-system-arm -M lm3s811evb -kernel uart_echo/gcc/uart_echo.bin + qemu: hardware error: strllaris_i2c_read: Bad offset 0xfc0 + + CPU #0: + R00=00000001 R01=005b8d80 R02=00061a80 R03=007a11ff + R04=40020000 R05=005b8d80 R06=00000002 R07=00000000 + R08=00000000 R09=00000000 R10=00000000 R11=00000000 + R12=00000000 R13=200000d4 R14=00000995 R15=000009cc + PSR=20000173 --C- T svc32 + Aborted + +The example is located in boards/ek-lm3s811/uart_echo in the +StellarisWare distribution. + +With the latest from git: + + $ .../qemu-git/qemu/bin/qemu-system-arm -M lm3s811evb -kernel uart_echo/gcc/uart_echo.bin + qemu-system-arm: hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. + +This however seems to be reported already (Bug #1028260). + +Both versions compiled from sources: + + ./configure --target-list=arm-linux-user,arm-softmmu,armeb-linux-user --enable-sdl --prefix=/path/to/... + +Running Ubunti 10.04 with Linux 2.6.32-40-generic-pae. + +/Lars \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1038136 b/results/classifier/gemma3:12b/peripherals/1038136 new file mode 100644 index 000000000..5b7c2a1fc --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1038136 @@ -0,0 +1,9 @@ + +lack of keycode 89 for br-abnt2 keyboards + +qemu-kvm-1.1.1 +host system: slackware64-13.37 +Bug detailed description: +Independent of Guest OS nothing happens when keycode 89 is pressed. +If you select option "-k pt-br" at qemu commandline you get keycode 89 but there is no more keycode 26 (dead_acute dead_grave) and keycode 51 fails on "less" sign. +If you have a numeric keyboard you can use its "slash" key but there is no means to use the question mark, causing discomfort when you are scripting or programming. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1042654 b/results/classifier/gemma3:12b/peripherals/1042654 new file mode 100644 index 000000000..1a91b2efc --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1042654 @@ -0,0 +1,6 @@ + +Floppy disks and network not working on NT 3.1 on Qemu 1.2 rc1 + +When I try to put Floppy IMG/IMA/VFD images on NT 3.1 when it is running on Qemu 1.2 rc, they are not recognized and the network is not working even though I set it correctly (especially the AMD PCnet adapter) +Here's some screenshot of the floppy error: +http://i49.tinypic.com/j77wcw.png \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1048 b/results/classifier/gemma3:12b/peripherals/1048 new file mode 100644 index 000000000..14a3f81ca --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1048 @@ -0,0 +1,7 @@ + +usb/ohci does not reset HccaPad1 after frame number update. +Description of problem: +When the OHCI controller's framenumber is incremented, HccaPad1 register should be set to zero. Ref OHCI Spec 4.4.1. +Relevant code section: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/hcd-ohci.c#L1201 + +ReactOS uses hccaPad1 to determine if the OHCI hardware is running, consequently it fails this check in current qemu master. diff --git a/results/classifier/gemma3:12b/peripherals/1055090 b/results/classifier/gemma3:12b/peripherals/1055090 new file mode 100644 index 000000000..e5f057db2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1055090 @@ -0,0 +1,22 @@ + +esp error: NetBSD/sparc on qemu-system-sparc + +On qemu-1.2.0's qemu-system-sparc, NetBSD/sparc (32bit) 5.1.2 and 6.0_RC2 generates the following NetBSD's errors. + +esp0: !TC on DATA XFER [intr 18, stat 82, step 4] prevphase 2, resid 0 +esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0 + +On qemu-0.15.1's qemu-system-sparc, NetBSD/sparc 5.1.2 and 6.0_RC2 works fine. + +To reproduce with NetBSD/sparc 6.0_RC2, run + +% qemu-system-sparc -M SS-20 -m 265M -hda NetBSD-sparc-6.0_RC2.qed -nographic -cdrom NetBSD-6.0_RC2-sparc.iso -boot d + +and try to install NetBSD. You can get above errors when newfs command is invoked. +I can reporduce this problem on NetBSD/i386 (32bit) and NetBSD/amd64(64bit; x86_64) host OSes. + +NetBSD-6.0_RC2-sparc.iso is here, +ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0_RC2/images/NetBSD-6.0_RC2-sparc.iso + +NetBSD-sparc-6.0_RC2.qed is created with +% qemu-img create -f qed NetBSD-sparc-6.0_RC2.qed 3G \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1058 b/results/classifier/gemma3:12b/peripherals/1058 new file mode 100644 index 000000000..f8af9acde --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1058 @@ -0,0 +1,9 @@ + +NetBSD Sparc 8.2 OS doesn't seem to accept keyboard input (-nographic) +Description of problem: +The NetBSD appears to boot to the login prompt successfully, but when the login prompt appears, the system doesn't appear to recognize keyboard input and so I cannot login (I can't seem to boot into single user mode for the same reason). I can see the characters being typed on the terminal, but pressing the Enter key to submit input results in nothing. + +I've confirmed that this is an issue with NetBSD because I also attempted to spin up a Solaris 8 VM and a Solaris 2.6 VM with the `-nographic` flag turned on, and I was able to log in and interact with both of those virtual machines. +Steps to reproduce: +1. Use RHEL 8.6 as the base OS (**Update:** I've discovered that this error occurs under a different host OS too (Ubuntu 20.04 LTS in my case) +2. Start the NetBSD VM running the command as specified above diff --git a/results/classifier/gemma3:12b/peripherals/106 b/results/classifier/gemma3:12b/peripherals/106 new file mode 100644 index 000000000..d0be29049 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/106 @@ -0,0 +1,2 @@ + +qemu-git gravis ultrasound not working diff --git a/results/classifier/gemma3:12b/peripherals/1061 b/results/classifier/gemma3:12b/peripherals/1061 new file mode 100644 index 000000000..d1663c5f0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1061 @@ -0,0 +1,247 @@ + +xen/pt: Incorrect register mask for PCI passthrough prevents Linux guest from completing boot process +Description of problem: +In brief, the problem is that PCI/GPU passthrough functions normally with Xen/Qemu if the Xen HVM guest is Windows, but if the guest is Linux, the guest will not complete the booting process and it never reaches the systemd targets that allow the GUI environment to start and login to the desktop environment. The problem is that a bug in the way Qemu initializes the PCI status register of the passed through devices causes the PCI capabilities list bit of the PCI status register to be disabled instead of enabled. This in turn disables the MSI-x interrupt handling capability of the passed through PCI devices. I think the reason only Linux guests are affected is that Linux guests use a different method of delivering interrupts from the passed through PCI devices to the guest from the method used by Windows guests, and the method used by Windows does not require the MSI-x capability of the PCI devices but the method used by Linux does need the MSI-x capability of the passed through devices. I will explain this further in the additional information section with logs and other relevant information. +Steps to reproduce: +1. It might only be reproducible on specific hardware. It is very reproducible on my system, an ASRock B85M-Pro4 with BIOS version P2.50 and a Haswell core i5-4590S CPU. +2. Configure the system to pass through the Intel integrated graphics device (IGD), the on-board USB 3 controller, and the onboard PCI audio device to a Windows Xen HVM guest with Qemu running as the device model for the Windows guest in Dom0 using the Xen xl toolstack, and verify that the Windows guest boots and functions properly. This is not trivial and can probably only be done by persons familiar with Xen and its PCI and VGA/GPU passthrough feature. Here is the xl domain configuration file that the Xen xl toolstack used to create and boot the working Windows HVM domain with passthrough of three PCI devices on my hardware: +``` +builder = 'hvm' +bios = 'seabios' +memory = '3072' +vcpus = '4' +device_model_version = 'qemu-xen' +disk = ['/dev/systems/windows,,xvda,w'] +name = 'bullseye' +vif = [ 'model=e1000,script=vif-route,ip=<redacted>' ] +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'destroy' +boot = 'c' +acpi = '1' +apic = '1' +viridian = '1' +xen_platform_pci = '1' +serial = 'pty' +vga = 'none' +sdl = '0' +vnc = '0' +gfx_passthru = '1' +pci = [ '00:1b.0', '00:14.0,rdm_policy=relaxed', '00:02.0' ] +``` +3. Shut down the working Windows Xen HVM and replace it with a Linux Xen HVM disk image and try to boot that in place of Windows, keeping all other configuration options the same as with the working Windows guest. To create and boot the non-working Linux HVM domain, I used the same xl domain configuration as for Windows with the exception that the disk line was replaced with: +``` +disk = ['/dev/systems/linux,,xvda,w'] +``` +which obviously points to a virtual disk that boots Linux instead of Windows. A Linux guest, such as Debian bullseye or Debian buster or Debian sid will not boot properly and instead exhibit the problem handling IRQs from the passed through PCI devices, as discussed above. +Additional information: +This problem is known by QubesOS and they have been using a patch to fix it since 2017, but they give very few details about the problem in their commit messages: + +https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3/commits/ab2b4c2ad02827a73c52ba561e9a921cc4bb227c + +That same patch to hw/xen/xen_pt_config_init.c also fixes the problem on my system. + +Some logs: + +Without the QubesOS patch, I get error messages indicating problems handling IRQs like this in the Dom0: + +May 10 08:50:03 bullseye kernel: [79077.644346] pciback 0000:00:1b.0: xen_pciback: vpci: assign to virtual slot 0 +May 10 08:50:03 bullseye kernel: [79077.644478] pciback 0000:00:1b.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.644732] pciback 0000:00:14.0: xen_pciback: vpci: assign to virtual slot 1 +May 10 08:50:03 bullseye kernel: [79077.644874] pciback 0000:00:14.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.645024] pciback 0000:00:02.0: xen_pciback: vpci: assign to virtual slot 2 +May 10 08:50:03 bullseye kernel: [79077.645107] pciback 0000:00:02.0: registering for 16 +May 10 08:50:30 bullseye kernel: [79105.273876] vif vif-16-0 vif16.0: Guest Rx ready +May 10 08:50:30 bullseye kernel: [79105.273893] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready +May 10 08:50:30 bullseye kernel: [79105.278023] xen-blkback: backend/vbd/16/51712: using 4 queues, protocol 1 (x86_64-abi) persistent grants +May 10 08:50:44 bullseye kernel: [79119.104937] irq 16: nobody cared (try booting with the "irqpoll" option) +May 10 08:50:44 bullseye kernel: [79119.104973] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1 +May 10 08:50:44 bullseye kernel: [79119.104976] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B85M Pro4, BIOS P2.50 12/11/2015 +May 10 08:50:44 bullseye kernel: [79119.104979] Call Trace: +May 10 08:50:44 bullseye kernel: [79119.104984] <IRQ> +May 10 08:50:44 bullseye kernel: [79119.104998] dump_stack+0x6b/0x83 +May 10 08:50:44 bullseye kernel: [79119.105008] __report_bad_irq+0x35/0xa7 +May 10 08:50:44 bullseye kernel: [79119.105014] note_interrupt.cold+0xb/0x61 +May 10 08:50:44 bullseye kernel: [79119.105024] handle_irq_event+0xa8/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105030] handle_fasteoi_irq+0x78/0x1c0 +May 10 08:50:44 bullseye kernel: [79119.105037] generic_handle_irq+0x47/0x50 +May 10 08:50:44 bullseye kernel: [79119.105044] __evtchn_fifo_handle_events+0x175/0x190 +May 10 08:50:44 bullseye kernel: [79119.105054] __xen_evtchn_do_upcall+0x66/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105063] __xen_pv_evtchn_do_upcall+0x11/0x20 +May 10 08:50:44 bullseye kernel: [79119.105069] asm_call_irq_on_stack+0x12/0x20 +May 10 08:50:44 bullseye kernel: [79119.105072] </IRQ> +May 10 08:50:44 bullseye kernel: [79119.105079] xen_pv_evtchn_do_upcall+0xa2/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105084] exc_xen_hypervisor_callback+0x8/0x10 +May 10 08:50:44 bullseye kernel: [79119.105091] RIP: e030:xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105097] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc +May 10 08:50:44 bullseye kernel: [79119.105100] RSP: e02b:ffffffff82603de8 EFLAGS: 00000246 +May 10 08:50:44 bullseye kernel: [79119.105106] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff810023aa +May 10 08:50:44 bullseye kernel: [79119.105108] RDX: 0000000009d62df2 RSI: 0000000000000000 RDI: 0000000000000001 +May 10 08:50:44 bullseye kernel: [79119.105111] RBP: ffffffff82613940 R08: 00000066a1715350 R09: 000047f57b235dc9 +May 10 08:50:44 bullseye kernel: [79119.105114] R10: 0000000000007ff0 R11: 0000000000000246 R12: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105117] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105124] ? xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105133] ? xen_safe_halt+0xc/0x20 +May 10 08:50:44 bullseye kernel: [79119.105140] ? default_idle+0xa/0x10 +May 10 08:50:44 bullseye kernel: [79119.105145] ? default_idle_call+0x38/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105152] ? do_idle+0x208/0x2b0 +May 10 08:50:44 bullseye kernel: [79119.105158] ? cpu_startup_entry+0x19/0x20 +May 10 08:50:44 bullseye kernel: [79119.105164] ? start_kernel+0x587/0x5a8 +May 10 08:50:44 bullseye kernel: [79119.105170] ? xen_start_kernel+0x625/0x631 +May 10 08:50:44 bullseye kernel: [79119.105180] ? startup_xen+0x3e/0x3e +May 10 08:50:44 bullseye kernel: [79119.105184] handlers: +May 10 08:50:44 bullseye kernel: [79119.105222] [<000000005d228d5f>] usb_hcd_irq [usbcore] +May 10 08:50:44 bullseye kernel: [79119.105245] [<00000000e534b010>] ath_isr [ath9k] +May 10 08:50:44 bullseye kernel: [79119.105257] Disabling IRQ #16 + +Also, without the patch, I get error messages about failure to handle IRQs in the Linux Xen HVM guest: + +Oct 23 18:50:32 domU kernel: irq 36: nobody cared (try booting with the "irqpoll" option) +Oct 23 18:50:32 domU kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-9-amd64 #1 Debian 5.10.70-1 +Oct 23 18:50:32 domU kernel: Hardware name: Xen HVM domU, BIOS 4.14.3 10/22/2021 +Oct 23 18:50:32 domU kernel: Call Trace: +Oct 23 18:50:32 domU kernel: <IRQ> +Oct 23 18:50:32 domU kernel: dump_stack+0x6b/0x83 +Oct 23 18:50:32 domU kernel: __report_bad_irq+0x35/0xa7 +Oct 23 18:50:32 domU kernel: note_interrupt.cold+0xb/0x61 +Oct 23 18:50:32 domU kernel: handle_irq_event+0xa8/0xb0 +Oct 23 18:50:32 domU kernel: handle_fasteoi_irq+0x78/0x1c0 +Oct 23 18:50:32 domU kernel: generic_handle_irq+0x47/0x50 +Oct 23 18:50:32 domU kernel: __evtchn_fifo_handle_events+0x175/0x190 +Oct 23 18:50:32 domU kernel: __xen_evtchn_do_upcall+0x66/0xb0 +Oct 23 18:50:32 domU kernel: __sysvec_xen_hvm_callback+0x22/0x30 +Oct 23 18:50:32 domU kernel: asm_call_irq_on_stack+0x12/0x20 +Oct 23 18:50:32 domU kernel: </IRQ> +Oct 23 18:50:32 domU kernel: sysvec_xen_hvm_callback+0x72/0x80 +Oct 23 18:50:32 domU kernel: asm_sysvec_xen_hvm_callback+0x12/0x20 +Oct 23 18:50:32 domU kernel: RIP: 0010:native_safe_halt+0xe/0x10 +Oct 23 18:50:32 domU kernel: Code: 02 20 48 8b 00 a8 08 75 c4 e9 7b ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d a6 6f 54 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 96 6f 54 00 f4 c3 cc cc 0f 1f 44 00 +Oct 23 18:50:32 domU kernel: RSP: 0018:ffffffff89003e48 EFLAGS: 00000246 +Oct 23 18:50:32 domU kernel: RAX: 0000000000004000 RBX: 0000000000000001 RCX: ffff8dbb7cc2c9c0 +Oct 23 18:50:32 domU kernel: RDX: ffff8dbb7cc00000 RSI: ffff8dbaf55b1400 RDI: ffff8dbaf55b1464 +Oct 23 18:50:32 domU kernel: RBP: ffff8dbaf55b1464 R08: ffffffff891b9120 R09: 0000000000000008 +Oct 23 18:50:32 domU kernel: R10: 000000000000000e R11: 000000000000000d R12: 0000000000000001 +Oct 23 18:50:32 domU kernel: R13: ffffffff891b91a0 R14: 0000000000000001 R15: 0000000000000000 +Oct 23 18:50:32 domU kernel: ? xen_sched_clock+0x11/0x20 +Oct 23 18:50:32 domU kernel: acpi_idle_do_entry+0x46/0x50 +Oct 23 18:50:32 domU kernel: acpi_idle_enter+0x86/0xc0 +Oct 23 18:50:32 domU kernel: cpuidle_enter_state+0x89/0x350 +Oct 23 18:50:32 domU kernel: cpuidle_enter+0x29/0x40 +Oct 23 18:50:32 domU kernel: do_idle+0x1ef/0x2b0 +Oct 23 18:50:32 domU kernel: cpu_startup_entry+0x19/0x20 +Oct 23 18:50:32 domU kernel: start_kernel+0x587/0x5a8 +Oct 23 18:50:32 domU kernel: secondary_startup_64_no_verify+0xb0/0xbb +Oct 23 18:50:32 domU kernel: handlers: +Oct 23 18:50:32 domU kernel: [<000000007d3a0964>] usb_hcd_irq [usbcore] +Oct 23 18:50:32 domU kernel: Disabling IRQ #36 +Oct 23 18:50:32 domU kernel: PM: Image not found (code -22) +Oct 23 18:50:32 domU kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:45:pipe A] flip_done timed out + +To prove the cause of the bug, I compare some logs without the patch +and with the patch that fixes it. + +First, relevant logs generated by Qemu in Dom0, for existing Qemu without the patch. On Debian these logs are located in /var/log/xen in the Dom0: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0280. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0080. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +Next, the same logs, but now using a version of Qemu with the patch that fixes the bug: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0290. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0090. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +To decipher what is happening here, one must refer to the definitions +in the pci/header.h file from PCI Utilities that in Debian is in the +libpci-dev package and is probably in similarly named packages on other +distros. + +The Offset of 0x0006 corresponds to the 16-bit PCI_STATUS register of +the passed through device, and the Emulated value of 0x0010 sets the desired +emulated value of the PCI_STATUS_CAP_LIST bit to 1 in the PCI_STATUS register. +The host values of 0x0290, 0x0090 correspond to the setting of the register in the +physical device for real device 00:14.0 and 00:02.0, respectively. +The syncing to value indicates the value of the register that Qemu +exposes to the guest. Notice that without the patch, the PCI_STATUS_CAP_LIST +bit is turned off for the two PCI devices (register value = 0x0280 and 0x0080 +for real device 00:14.0 and 00:02.0, respectively), but the bit is turned +on (0x0290 and 0x0090) for these devices with the patch. With the capabilities list enabled, the guest can use the MSI-x capability of the device, but with the capabilities +list disabled, the guest cannot use the MSI-x capability of the devices. +That explains why this patch is needed in Qemu to fix this problem and enable the Linux guest to use the MSI-x capability of the passed through PCI devices. + +This is the QubesOS patch thatfixes it: +``` +--- a/hw/xen/xen_pt_config_init.c ++++ b/hw/xen/xen_pt_config_init.c +@@ -1969,7 +1969,7 @@ + /* Mask out host (including past size). */ + new_val = val & host_mask; + /* Merge emulated ones (excluding the non-emulated ones). */ +- new_val |= data & host_mask; ++ new_val |= data & reg->emu_mask; + /* Leave intact host and emulated values past the size - even though + * we do not care as we write per reg->size granularity, but for the + * logging below lets have the proper value. */ +``` +The QubesOS patch that fixes it in Debian's Qemu 7.0.0 build is also attached as a file.[xen-fix-emu-mask.patch](/uploads/3bef189175549cd9854f8dc3d1affc88/xen-fix-emu-mask.patch) + +~~I will not officially submit it as a patch because I am not its author.~~ + +~~I do not know why QubesOS never officially requested that this fix +be committed to Qemu upstream, but I hope after review by the +maintainers of the code touched by this patch it will be recognized +as a necessary fix to a mistake that causes the desired merge of +the host and emulated values to be incorrect.~~ + +For reference, the commit that is fixed by the QubesOS patch is: + +Fixes: 2e87512eccf3c5e40f3142ff5a763f4f850839f4 (xen/pt: Sync up the dev.config and data values.) + +I think perhaps that commit and the patched file might need some other cleanup so I might try my hand at officially submitting a patch to Qemu that fixes this issue on my hardware without breaking something else, because it is possible that the simple QubesOS patch is not suitable as the correct fix. + +But before I do that, I wish to make one more comment. In my logs, the only other register than the PCI_STATUS register that is affected by the QubesOS patch is the PCI_HEADER_TYPE register. Without the patch, the register's value is always exposed to the guest as 0x80, and with the patch, the value is always exposed as 0x00 (PCI_HEADER_TYPE_NORMAL as defined in pci/header.h). That is because Qemu sets the initial emulated value of PCI_HEADER_TYPE register to 0x80, but Qemu also sets the emu_mask to 0x00, so after correcting the merging of the host and emulated values with the QubesOS patch, the value is synced to 0x00 instead of 0x80. What I don't understand is why the register is initialized with 0x80, but the emu_mask is 0x00. Shouldn't the emu_mask be 0x80, to pass through the initial emulated value of 0x80? ~~Also, I don't know why the initial emulated value of PCI_HEADER_TYPE is set to 0x80 but I will assume that is the correct emulated value that should be exposed to the guest.~~ Update: After doing some research, I discovered the bit that is set in the PCI_HEADER_TYPE register (0x80) because of this issue is the bit to define the device as a multifunction device. None of my devices are multifunction, and the fact that the multifunction bit is incorrectly set on my passed through devices because of this issue seems to have no effect on the operation of the device or the guest. Apparently the author of the code to initialize the PCI_HEADER_TYPE register planned to initialize every passed through device as a multifunction device, but is this needed? My testing indicates it is not needed on my system. + +I am referring to this code in hw/xen/xen_pt_config_init.c: + +``` +static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s, + XenPTRegInfo *reg, uint32_t real_offset, + uint32_t *data) +{ + /* read PCI_HEADER_TYPE */ + *data = reg->init_val | 0x80; + return 0; +} + +[...] + + /* Header Type reg */ + { + .offset = PCI_HEADER_TYPE, + .size = 1, + .init_val = 0x00, + .ro_mask = 0xFF, + .emu_mask = 0x00, + .init = xen_pt_header_type_reg_init, + .u.b.read = xen_pt_byte_reg_read, + .u.b.write = xen_pt_byte_reg_write, + }, +``` +I would appreciate any guidance that experienced Qemu or Xen contributors can give me about this question. ~~If no one gives me any guidance here in a timely manner, I plan to propose my own fix officially to Qemu as the QubesOS patch plus changing the emu_mask value of the PCI_HEADER_TYPE register from 0x00 to 0x80. I verified that fixes the problem I am seeing in the PCI_STATUS register without also causing the change that the QubesOS patch makes to the PCI_HEADER_TYPE register.~~ + +I plan to submit a patch to fix this issue, noting the effect the patch has on the PCI_HEADER_TYPE register in the commit message. diff --git a/results/classifier/gemma3:12b/peripherals/1073952 b/results/classifier/gemma3:12b/peripherals/1073952 new file mode 100644 index 000000000..dc633607e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1073952 @@ -0,0 +1,29 @@ + +data sent to serial interface gets truncated after 64kb + +When sending more than 64kb of data to the serial interface in a short timespan, the data seems to disappear. + +I tested it with the latest release (qemu-kvm-1.2.0-rc2.tar.gz) where the bug still occurs. I stumbled upon it when I upraged my qemu version. The bug did not occur in the last version i had (0.12.5). + +You can reproduce it as follows: + +1. Start a dd or cat command in one terminal and pipe the output to a netcat. The testfile has to be larger than 64kb. I used one that had 93kb and did contain only ascii text. + + $ dd if=<TESTFILE> | nc -l 127.0.0.1 65432 + or + $ cat <TESTFILE> | nc -l 127.0.0.1 65432 + +2. Start a qemu and let the first serial port connect to the listening netcat. I suppose that the testsystem can be any system that does not read from the serial port on its own (e.g. during boot process). I used a self compiled minimal linux. + + $ qemu -cdrom <TESTSYSTEM> -serial tcp:127.0.0.1:65432 + +3. When the testsystem is booted, read from the serial device and write it to a file. + + $ dd if=/dev/ttyS0 of=/tmp/testFile + or + $ cat /dev/ttyS0 > /tmp/testFile + + +The result in almost all of my testruns is, that the /tmp/testFile does only has the size of 64kb. The rest of the data vanished. In some cases the file was slightly bigger (65kb or 67kb) but allways under 70kb. The complete file (93kb) was not trasmitted in any of the runs. + +I hope my explanation is exactly enough for you to reproduce it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1086745 b/results/classifier/gemma3:12b/peripherals/1086745 new file mode 100644 index 000000000..57b41177d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1086745 @@ -0,0 +1,12 @@ + +serial port data THRE comes too early + +When using a serial port with a Linux guest (and host) and the application uses hardware handshake, this fails because the handling of TEMT and/or THRE is not operating properly in such cases. + +As long as it takes _time_ for the 'real' port to output the data TEMT may not return true. After writing characters to a real port, the driver should timeout the transmission and after the total time expired, TEMT can be set. + +Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat IOCTL(GET_LSR_INFO), RTS_off, READ_data. +At the moment this fails because very early in the transmission, GET_LSR_INFO returns true and the modem transmitter is switched off. + +I looked in the source (git) and found that 'char_transmit_time' is present. My skills fail to implement it myself. +I build and ran the latest git version and found it to fail as decribed above. I hope someone can solve it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1096713 b/results/classifier/gemma3:12b/peripherals/1096713 new file mode 100644 index 000000000..297d78c4c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1096713 @@ -0,0 +1,9 @@ + +qemu 1.3.0: Windows XP crashes when reconizing the USB keyboard + +I'm trying to use the usb tablet and the usb keyboard as follows: +./qemu-system-i386 -device pci-ohci -device usb-tablet -device usb-kbd +or +./qemu-system-i386 -device ich9-usb-ehci1 -device ich9-usb-uhci1 -device usb-tablet -device ich9-usb-uhci2 -device usb-kbd + +While Windows XP works fine if I only use the tablet but not the keyboard, it crashed with a BSOD when I use both keyboard and tablet. It crashed during the detection of the keyboard. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/110 b/results/classifier/gemma3:12b/peripherals/110 new file mode 100644 index 000000000..f316227be --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/110 @@ -0,0 +1,2 @@ + +KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on diff --git a/results/classifier/gemma3:12b/peripherals/1101210 b/results/classifier/gemma3:12b/peripherals/1101210 new file mode 100644 index 000000000..25d394060 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1101210 @@ -0,0 +1,10 @@ + +qemu 1.4.2: usb keyboard not fully working + +When using the usb keyboard, I can't type the | character. I'm using german keyboard layout (de) on the host and inside the guest. As a guest OS, I use Linux (e.g. a recent KNOPPIX cd). To obtain the | character on a german keyboard, I need to press AltGr + the < or > key, i.e. the key right to the left shift. + +The qemu command line is something like this: +./qemu-system-i386 -device pci-ohci -device usb-kbd +I also tried +./qemu-system-i386 -usb -usbdevice keyboard +with the same effect. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1122 b/results/classifier/gemma3:12b/peripherals/1122 new file mode 100644 index 000000000..eff34afe7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1122 @@ -0,0 +1,129 @@ + +ARMv7M (Cortex M) NVIC does not make number of priority bits a board/SoC-configurable parameter +Description of problem: +In FreeRTOS code for function of `xPortStartScheduler()` in [`main/portable/GCC/ARM_CM4F/port.c`](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4F/port.c#L293) file code sets the value of 0x400 register of NVIC to the maximum bits and expect to read back only maximum priority bits that are supported by the platform. The QEMU code doesn't unset these bits (same 0xff value written is read back): +``` +NVIC: priority [0x400] = 0x00 +NVIC[NS]: [0x400] -> 0x00000000 +NVIC: priority [0x400] = 0xff +NVIC[NS]: [0x400] <- 0x000000ff +nvic_recompute_state NVIC state recomputed: vectpending 0 vectpending_prio 256 exception_prio 256 +NVIC: priority [0x400] = 0x00 +NVIC[NS]: [0x400] -> 0x000000ff +``` +Logging function for reading and writing added in `hw/intc/armv7_nvic.c` like these: +writing: +```c + case 0x400 ... 0x5ef: /* NVIC Priority */ + startvec = (offset - 0x400) + NVIC_FIRST_IRQ; /* vector # */ + + for (i = 0; i < size && startvec + i < s->num_irq; i++) { + if (attrs.secure || s->itns[startvec + i]) { + qemu_log("NVIC: priority [0x%03x] = 0x%02llx\n", offset, (value >> (i * 8)) & 0xff); + set_prio(s, startvec + i, false, (value >> (i * 8)) & 0xff); + } + } + qemu_log("NVIC[%s]: [0x%03x] <- 0x%08llx\n", attrs.secure ? "S" : "NS", offset, value); + + nvic_irq_update(s); + goto exit_ok; +``` +reading: +```c + case 0x400 ... 0x5ef: /* NVIC Priority */ + val = 0; + startvec = offset - 0x400 + NVIC_FIRST_IRQ; /* vector # */ + + // TODO: should return either 0x70 or 0x78 + for (i = 0; i < size && startvec + i < s->num_irq; i++) { + qemu_log("NVIC: priority [0x%03x] = 0x%02x\n", offset, 8 * i); + if (attrs.secure || s->itns[startvec + i]) { + val |= s->vectors[startvec + i].prio << (8 * i); + } + } + qemu_log("NVIC[%s]: [0x%03x] -> 0x%08x\n", attrs.secure ? "S" : "NS", offset, val); + break; +``` +Steps to reproduce: +1. Run FreeRTOS for any ARMv7 Cortex-M platform with NVIC +2. Observe failure to proceed to `prvPortStartFirstTask();` function. +Additional information: +Here is the piece of standard FreeRTOS code that runs that check: +```c + /* configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to 0. + * See https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html */ + configASSERT( configMAX_SYSCALL_INTERRUPT_PRIORITY ); + + /* This port can be used on all revisions of the Cortex-M7 core other than + * the r0p1 parts. r0p1 parts should use the port from the + * /source/portable/GCC/ARM_CM7/r0p1 directory. */ + configASSERT( portCPUID != portCORTEX_M7_r0p1_ID ); + configASSERT( portCPUID != portCORTEX_M7_r0p0_ID ); + + #if ( configASSERT_DEFINED == 1 ) + { + volatile uint32_t ulOriginalPriority; + volatile uint8_t * const pucFirstUserPriorityRegister = ( volatile uint8_t * const ) ( portNVIC_IP_REGISTERS_OFFSET_16 + portFIRST_USER_INTERRUPT_NUMBER ); + volatile uint8_t ucMaxPriorityValue; + + /* Determine the maximum priority from which ISR safe FreeRTOS API + * functions can be called. ISR safe functions are those that end in + * "FromISR". FreeRTOS maintains separate thread and ISR API functions to + * ensure interrupt entry is as fast and simple as possible. + * + * Save the interrupt priority value that is about to be clobbered. */ + ulOriginalPriority = *pucFirstUserPriorityRegister; + + /* Determine the number of priority bits available. First write to all + * possible bits. */ + *pucFirstUserPriorityRegister = portMAX_8_BIT_VALUE; + + /* Read the value back to see how many bits stuck. */ + ucMaxPriorityValue = *pucFirstUserPriorityRegister; + + /* Use the same mask on the maximum system call priority. */ + ucMaxSysCallPriority = configMAX_SYSCALL_INTERRUPT_PRIORITY & ucMaxPriorityValue; + + /* Calculate the maximum acceptable priority group value for the number + * of bits read back. */ + ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS; + + while( ( ucMaxPriorityValue & portTOP_BIT_OF_BYTE ) == portTOP_BIT_OF_BYTE ) + { + ulMaxPRIGROUPValue--; + ucMaxPriorityValue <<= ( uint8_t ) 0x01; + } + + #ifdef __NVIC_PRIO_BITS + { + /* Check the CMSIS configuration that defines the number of + * priority bits matches the number of priority bits actually queried + * from the hardware. */ + configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == __NVIC_PRIO_BITS ); + } + #endif + + #ifdef configPRIO_BITS + { + /* Check the FreeRTOS configuration that defines the number of + * priority bits matches the number of priority bits actually queried + * from the hardware. */ + configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == configPRIO_BITS ); + } + #endif + + /* Shift the priority group value back to its position within the AIRCR + * register. */ + ulMaxPRIGROUPValue <<= portPRIGROUP_SHIFT; + ulMaxPRIGROUPValue &= portPRIORITY_GROUP_MASK; + + /* Restore the clobbered interrupt priority register to its original + * value. */ + *pucFirstUserPriorityRegister = ulOriginalPriority; + } + #endif /* configASSERT_DEFINED */ +``` + +See also these pages: +- https://www.freertos.org/RTOS-Cortex-M3-M4.html +- https://www.freertos.org/freertos-on-qemu-mps2-an385-model.html diff --git a/results/classifier/gemma3:12b/peripherals/1123 b/results/classifier/gemma3:12b/peripherals/1123 new file mode 100644 index 000000000..e44000685 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1123 @@ -0,0 +1,92 @@ + +Xilinx ZynqMP CAN controller logical error - mixed RX and TX channels +Description of problem: +In the code of CAN controller of Xilinx ZynqMP board (`hw/net/can/xlnx-zynqmp-can.c`) in function `update_rx_fifo()` there seems to be a typo or logical error mixing RX and TX buffers: +```c + /* Store the message in fifo if it passed through any of the filters. */ + if (filter_pass && frame->can_dlc <= MAX_DLC) { + + if (fifo32_is_full(&s->rx_fifo)) { + ARRAY_FIELD_DP32(s->regs, INTERRUPT_STATUS_REGISTER, RXOFLW, 1); + } else { + timestamp = CAN_TIMER_MAX - ptimer_get_count(s->can_timer); + + fifo32_push(&s->rx_fifo, frame->can_id); + + fifo32_push(&s->rx_fifo, deposit32(0, R_RXFIFO_DLC_DLC_SHIFT, + R_RXFIFO_DLC_DLC_LENGTH, + frame->can_dlc) | + deposit32(0, R_RXFIFO_DLC_RXT_SHIFT, + R_RXFIFO_DLC_RXT_LENGTH, + timestamp)); + + /* First 32 bit of the data. */ + fifo32_push(&s->rx_fifo, deposit32(0, R_TXFIFO_DATA1_DB3_SHIFT, + R_TXFIFO_DATA1_DB3_LENGTH, + frame->data[0]) | + deposit32(0, R_TXFIFO_DATA1_DB2_SHIFT, + R_TXFIFO_DATA1_DB2_LENGTH, + frame->data[1]) | + deposit32(0, R_TXFIFO_DATA1_DB1_SHIFT, + R_TXFIFO_DATA1_DB1_LENGTH, + frame->data[2]) | + deposit32(0, R_TXFIFO_DATA1_DB0_SHIFT, + R_TXFIFO_DATA1_DB0_LENGTH, + frame->data[3])); +``` +Additional information: +Possible fix: +```diff + git diff 12:29:23 +diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c +index 82ac48cee2..e93e6c5e19 100644 +--- a/hw/net/can/xlnx-zynqmp-can.c ++++ b/hw/net/can/xlnx-zynqmp-can.c +@@ -696,30 +696,30 @@ static void update_rx_fifo(XlnxZynqMPCANState *s, const qemu_can_frame *frame) + timestamp)); + + /* First 32 bit of the data. */ +- fifo32_push(&s->rx_fifo, deposit32(0, R_TXFIFO_DATA1_DB3_SHIFT, +- R_TXFIFO_DATA1_DB3_LENGTH, ++ fifo32_push(&s->rx_fifo, deposit32(0, R_RXFIFO_DATA1_DB3_SHIFT, ++ R_RXFIFO_DATA1_DB3_LENGTH, + frame->data[0]) | +- deposit32(0, R_TXFIFO_DATA1_DB2_SHIFT, +- R_TXFIFO_DATA1_DB2_LENGTH, ++ deposit32(0, R_RXFIFO_DATA1_DB2_SHIFT, ++ R_RXFIFO_DATA1_DB2_LENGTH, + frame->data[1]) | +- deposit32(0, R_TXFIFO_DATA1_DB1_SHIFT, +- R_TXFIFO_DATA1_DB1_LENGTH, ++ deposit32(0, R_RXFIFO_DATA1_DB1_SHIFT, ++ R_RXFIFO_DATA1_DB1_LENGTH, + frame->data[2]) | +- deposit32(0, R_TXFIFO_DATA1_DB0_SHIFT, +- R_TXFIFO_DATA1_DB0_LENGTH, ++ deposit32(0, R_RXFIFO_DATA1_DB0_SHIFT, ++ R_RXFIFO_DATA1_DB0_LENGTH, + frame->data[3])); + /* Last 32 bit of the data. */ +- fifo32_push(&s->rx_fifo, deposit32(0, R_TXFIFO_DATA2_DB7_SHIFT, +- R_TXFIFO_DATA2_DB7_LENGTH, ++ fifo32_push(&s->rx_fifo, deposit32(0, R_RXFIFO_DATA2_DB7_SHIFT, ++ R_RXFIFO_DATA2_DB7_LENGTH, + frame->data[4]) | +- deposit32(0, R_TXFIFO_DATA2_DB6_SHIFT, +- R_TXFIFO_DATA2_DB6_LENGTH, ++ deposit32(0, R_RXFIFO_DATA2_DB6_SHIFT, ++ R_RXFIFO_DATA2_DB6_LENGTH, + frame->data[5]) | +- deposit32(0, R_TXFIFO_DATA2_DB5_SHIFT, +- R_TXFIFO_DATA2_DB5_LENGTH, ++ deposit32(0, R_RXFIFO_DATA2_DB5_SHIFT, ++ R_RXFIFO_DATA2_DB5_LENGTH, + frame->data[6]) | +- deposit32(0, R_TXFIFO_DATA2_DB4_SHIFT, +- R_TXFIFO_DATA2_DB4_LENGTH, ++ deposit32(0, R_RXFIFO_DATA2_DB4_SHIFT, ++ R_RXFIFO_DATA2_DB4_LENGTH, + frame->data[7])); + + ARRAY_FIELD_DP32(s->regs, INTERRUPT_STATUS_REGISTER, RXOK, 1); +``` diff --git a/results/classifier/gemma3:12b/peripherals/1126 b/results/classifier/gemma3:12b/peripherals/1126 new file mode 100644 index 000000000..eae3e9d23 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1126 @@ -0,0 +1,9 @@ + +qemu-system-mipsel freezes for nanoMIPS in the semihosting mode +Description of problem: +In the current git master branch (SHA: 7b17a1a8) there is a problem with qemu-system-mipsel when trying to execute a simple hello.elf program in the semihosting mode for the nanoMIPS architecture. I.e. after executing the following command the terminal freezes: + ``` + $ ./qemu-system-mipsel -cpu I7200 -semihosting -nographic -kernel hello.elf + ``` +hello.elf file is generated using the nanoMIPS GNU Toolchain (https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases). +The program regularly terminates with QEMU emulator version 6.0.1. diff --git a/results/classifier/gemma3:12b/peripherals/1127 b/results/classifier/gemma3:12b/peripherals/1127 new file mode 100644 index 000000000..f205c84c3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1127 @@ -0,0 +1,130 @@ + +Various problems with running SunOS 4.1.4 +Description of problem: +Yes, I know, SunOS 4.1.4 is ancient, but I happened to find an original Solaris 1.1.2/SunOS 4.1.4 installation CD, and nostalgia got the better of me. + +It used to be possible to run SunOS 4.1.4 in QEMU 5.0.0, but starting with 6.0.0, whenever you try to boot, you see the following whenever SunOS tries to access a SCSI disk: + +``` +ok boot disk +Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: +root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0:a fstype 4.2 +Boot: vmunix +Size: 1548288+463688+225704 bytes +SuperSPARC: PAC ENABLED +SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994 +Copyright (c) 1983-1993, Sun Microsystems, Inc. +cpu = SUNW,SPARCstation-20 +mod0 = TI,TMS390Z50 (mid = 8) +mem = 523836K (0x1ff8f000) +avail mem = 510947328 +cpu0 at Mbus 0x8 0x240000 +entering uniprocessor mode +Ethernet address = 52:54:0:12:34:56 +espdma0 at SBus slot f 0x400000 +esp0 at SBus slot f 0x800000 pri 4 (onboard) +esp0: data transfer overrun + State=DATA Last State=DATA_DONE + Latched stat=0x11<XZERO,IO> intr=0x10<BUS> fifo 0x0 + last msg out: EXTENDED; last msg in: COMMAND COMPLETE + DMA csr=0xa4240030<FLSH,INTEN> + addr=fff00034 last=fff00010 last_count=24 + Cmd dump for Target 3 Lun 0: + cdb=[ 0x12 0x0 0x0 0x0 0x24 0x0 ] + pkt_state 0xf<XFER,CMD,SEL,ARB> pkt_flags 0x9 pkt_statistics 0x0 + cmd_flags=0x5 cmd_timeout 0 + Mapped Dma Space: + Base = 0x10 Count = 0x24 + Transfer History: + Base = 0x10 Count = 0x24 + current phase 0x26=DATAIN stat=0x11 0x24 + current phase 0x1=CMD_START stat=0x12 0x12 + current phase 0x60=SELECT_SNDMSG stat=0x7 0x3 0x0 + current phase 0x23=SYNCHOUT stat=0x7 0x19 0xf + current phase 0xb=CMD_CMPLT stat=0x7 0x0 + current phase 0x27=STATUS stat=0x7 0x0 + current phase 0xb=CMD_CMPLT stat=0x13 + current phase 0x80=SEL_NO_ATN stat=0x0 0x3 0x0 + current phase 0x1=CMD_START stat=0x0 0x0 0x80 + current phase 0x1c=RESET stat=0x0 0x1f +``` + +This causes SunOS to ignore the disk, and later it tries to boot via ethernet instead. + +After some digging, I *think* I tracked down the problem. + +This commit seems to be what did it: + +commit 799d90d818ba38997e9f5de2163bbfc96256ac0b +Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> +Date: Thu Mar 4 22:10:58 2021 +0000 + + esp: transition to message out phase after SATN and stop command + + The SCSI bus should remain in the message out phase after the SATN and stop + command rather than transitioning to the command phase. A new ESPState variable + cmdbuf_cdb_offset is added which stores the offset of the CDB from the start + of cmdbuf when accumulating extended message out phase data. + + Currently any extended message out data is discarded in do_cmd() before the CDB + is processed in do_busid_cmd(). + + Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> + Reviewed-by: Laurent Vivier <laurent@vivier.eu> + Message-Id: <20210304221103.6369-38-mark.cave-ayland@ilande.co.uk> + +I determined this by rummaging through the changes to the esp.c driver between 5.0.0 and 6.0.0 until I stumbled across this one. I can make the problem go away with this simple change: + +``` +--- esp.c.orig 2022-04-19 12:10:27.000000000 -0700 ++++ esp.c 2022-07-25 19:57:06.602665000 -0700 +@@ -433,7 +433,7 @@ + trace_esp_handle_satn_stop(fifo8_num_used(&s->cmdfifo)); + s->do_cmd = 1; + s->cmdfifo_cdb_offset = 1; +- s->rregs[ESP_RSTAT] = STAT_MO; ++ s->rregs[ESP_RSTAT] = STAT_TC | STAT_CD /*STAT_MO*/; + s->rregs[ESP_RINTR] |= INTR_BS | INTR_FC; + s->rregs[ESP_RSEQ] = SEQ_MO; + esp_raise_irq(s); +``` + +NOTE: I am not sure if this is a proper fix, as I don't know enough about SCSI or the esp controller. All I know is putting this back the way it was makes SunOS happy again. Unfortunately it may also break something else, so somebody more knowledgeable than I should investigate further. + +If you're worried that reproducing this will be difficult, don't be. I prepared detailed instructions, scripts and all the images you should need to create a virtual SunOS disk and install the OS on it. This includes the OpenProm images and installation ISO. + +You can find everything here (consult readme.txt for details): + +http://people.freebsd.org/~wpaul/sunos-qemu + +The quick install option is very simple. Once you finish writing the OS to the disk and try to boot off it the first time, you should encounter the error above. + +But wait, there's more. + +SunOS 4 has this quirk where it only works with CD-ROM drives that report a block size of 512 bytes, instead of the default of 2048. Now, I realize that just recently, there was a change committed that allows the guest to change the block size with the MODE SELECT command. However this doesn't seem to be good enough for SunOS (I tried it, it still hates the drive). Note that scsi-disk.c hard codes the block size for CD-ROMs to 2058 in scsi_cd_realize(). What would be really nice is if was possible to override this from the command line, and that addresses the problem quite nicely. + +At the same URL above, I also provided a small patch to scsi-disk.c which implements this feature. This allows the user to set the initial block size with logical_block_size=512 when specifying the device parameters. The qemu_sparc5.sh and qemu_sparc20.sh scripts show an example of this. + +One more thing: I wanted to simulate a SPARCstation 20, but I found that SunOS 4 would panic when I tried to boot it with this configuration, even if I used the correct SS20 OpenProm image. The problem here has to do with the SUNW,DBRIe device. QEMU doesn't simulate this device, but it creates dummy resources for it, including a PROM space. The problem is that this space is empty. This causes the OpenProm to create a node with an empty "name" property, which is a condition the SunOS kernel doesn't expect. The result is that the kernel tries to dereference a NULL pointer and panics. (The OpenProm code itself seems to let it slide.) + +To work around this, I patched the sun4m.c code to create the SUNW,DBRIe device such that its PROM space can actually be populated with an FCode image, and I created a simple one with a valid name property so that the kernel doesn't panic. SunOS complains later that it can't find the audio device because it's not actually implemented, but at least it doesn't crash. + +I don't know how this would actually be addressed in QEMU proper since the existing FCode images that QEMU uses come from OpenBios. + +Finally, one thing I haven't figured out is that using the -smp flag with SunOS 4 never seems to work. The OpenProms and the SunOS kernel only ever seem to detect one CPU. I am not that broken up about this though, because SunOS 4 never really did SMP very well to begin with. +Steps to reproduce: +Download all the files at: + +http://people.freebsd.org/~wpaul/sunos-qemu + +You can download just: + +http://people.freebsd.org/~wpaul/sunos-qemu/sunos-qemu.tar.gz + +if you want everything in one shot. + +Read the readme.txt file. This will walk you through trying to create a bootable SunOS system. You should apply the CD-ROM patch to scsi-disk.c and use the qemu_sparc5.sh script initially. This should allow you to install the miniroot from the CD image onto the virtual hard drive, but it will fail booting due to the esp controller problem. The qemu_sparc20.sh script will only boot successfully if you apply the sun4m.c patch and copy QEMU,dbri.bin to the QEMU firmware directory. +Additional information: +I'm not planning to provide a pull request for any of this. As I said, I'm not sure if my fixes are necessarily correct (especially the esp.c one). I'm satisfied that they work for me, but I want to leave it to the appropriate maintainers do decide how to best deal with these things. + +I would be happy to answer questions and test candidate fixes though. diff --git a/results/classifier/gemma3:12b/peripherals/1132 b/results/classifier/gemma3:12b/peripherals/1132 new file mode 100644 index 000000000..345d10c2e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1132 @@ -0,0 +1,116 @@ + +[SPARC/Leon3] Application compiled by RCC 1.2 won't start +Description of problem: +Even simple "hello world" application compiled by Gaisler RCC 1.2 compiler ("space-certified" GCC 4.4.6 with RTEMS OS) for Leon3 CPU won't start on QEMU - QEMU silently exits before getting into `Init`. + +In real hardware it works. + +(I know that the GCC 4.4.6 is quite ancient now, usage of this toolchain is forced) +Steps to reproduce: +Steps provided for Windows system, but I suspect it works exactly the same in Linux system. + +1. Get `sparc-rtems-4.10-gcc-4.4.6-1.2.25-mingw` GCC from here: https://www.gaisler.com/anonftp/rcc/rcc-1.2/1.2.25/ +2. Unpack it to `c:\opt` (it doesn't work from other directories. `/opt` for Linux) +3. Create simple "Hello world" RTEMS application. +4. Run it by `qemu-system-sparc -machine leon3_generic -nographic -monitor null -serial stdio -m 64M -kernel fail.elf` +5. Result is exiting before getting into `Init`. + +Simple example attached (with ELF). It should print `It works. Exiting.` and exit. + +[leon3-rcc-start-fail.zip](/uploads/69d79dcc496e86bb07d5c69212d94ced/leon3-rcc-start-fail.zip) +Additional information: +Log: + +``` +... + +---------------- +IN: ambapp_for_each_dev +0x40005430: clr %o0 ! 0x0 +0x40005434: ret +0x40005438: restore %g0, %o0, %o0 + +---------------- +IN: amba_initialize +0x40003aa8: cmp %o0, 0 +0x40003aac: be 0x40003b4c +0x40003ab0: nop + +---------------- +IN: amba_initialize +0x40003b4c: mov 1, %g1 +0x40003b50: ta 0 + + 1: Trap Instruction (v=80) +pc: 40003b50 npc: 40003b54 +%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000 +%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0 +%l0-7: 40025800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +%i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 43fffec0 40002b78 +psr: f3400fe5 (icc: -Z-- SPE: SPE) wim: 00000002 +fsr: 00000000 y: ffffffff + +---------------- +IN: +0x40003a18: cmp %g1, 3 +0x40003a1c: bne 0x40003a34 +0x40003a20: and %i0, 0xf00, %l4 + +---------------- +IN: +0x40003a34: ta 0 + + 2: Trap Instruction (v=80) +pc: 40003a34 npc: 40003a38 +%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000 +%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470 +%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800 +%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0 +psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002 +fsr: 00000000 y: ffffffff + + 3: Trap Instruction (v=80) +pc: 40003a34 npc: 40003a38 +%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000 +%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470 +%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800 +%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0 +psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002 +fsr: 00000000 y: ffffffff + +// repeating until sudden and quiet exit from QEMU +``` + +After digging it seems that target code requires byte access to GRLIB APB PNP registers that is not implemented in QEMU now. +Adding code supporting byte access seems to help. + +The quick patch is: + +``` +--- a/hw/misc/grlib_ahb_apb_pnp.c ++++ b/hw/misc/grlib_ahb_apb_pnp.c +@@ -249,6 +249,11 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size) + val = apb_pnp->regs[offset >> 2]; + trace_grlib_apb_pnp_read(offset, val); + ++ if (size == 1) { ++ val >>= (24 - (offset & 3) * 8); ++ val &= 0x0ff; ++ } ++ + return val; + } + +@@ -263,7 +268,7 @@ static const MemoryRegionOps grlib_apb_pnp_ops = { + .write = grlib_apb_pnp_write, + .endianness = DEVICE_BIG_ENDIAN, + .impl = { +- .min_access_size = 4, ++ .min_access_size = 1, + .max_access_size = 4, + }, + }; + +``` + +The custom compiled QEMU with this patch is used in project for over half a year and it works fine, but I don't know if it is a proper fix. diff --git a/results/classifier/gemma3:12b/peripherals/1148 b/results/classifier/gemma3:12b/peripherals/1148 new file mode 100644 index 000000000..4b314c3ab --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1148 @@ -0,0 +1,272 @@ + +Support Octal SPI mode and commands for NOR SPI devices +Additional information: +A good example of the Octal SPI (OPI) protocol use is in https://www.st.com/resource/en/application_note/dm00407776-octospi-interface-on-stm32-microcontrollers-stmicroelectronics.pdf + +It is also supported by the concrete drivers in Linux kernel: +- `drivers/mtd/spi-nor/core.c` +- `drivers/mtd/spi-nor/micron-st.c` +- `drivers/mtd/spi-nor/spansion.c` + +I tried to extract the Octal SPI part from that commit and got something like this, though obviously needs more cleaning up/improving: +```patch +--- + hw/block/m25p80.c | 93 ++++++++++++++++++++++++++++++++++------------- + 1 file changed, 68 insertions(+), 25 deletions(-) + +diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c +index 7d3d8b12e0..0aa46bf280 100644 +--- a/hw/block/m25p80.c ++++ b/hw/block/m25p80.c +@@ -361,6 +361,8 @@ typedef enum { + READ4 = 0x13, + FAST_READ = 0x0b, + FAST_READ4 = 0x0c, ++ O_FAST_READ = 0x9d, ++ O_FAST_READ4 = 0xfc, + DOR = 0x3b, + DOR4 = 0x3c, + QOR = 0x6b, +@@ -369,6 +371,11 @@ typedef enum { + DIOR4 = 0xbc, + QIOR = 0xeb, + QIOR4 = 0xec, ++ OOR = 0x8b, ++ OOR4 = 0x8c, ++ OOR4_MT35X = 0x7c, /* according mt35x datasheet */ ++ OIOR = 0xcb, ++ OIOR4 = 0xcc, + + PP = 0x02, + PP4 = 0x12, +@@ -379,6 +386,8 @@ typedef enum { + RDID_90 = 0x90, + RDID_AB = 0xab, + AAI_WP = 0xad, ++ OPP = 0x82, ++ OPP4 = 0x84, + + ERASE_4K = 0x20, + ERASE4_4K = 0x21, +@@ -422,6 +431,7 @@ typedef enum { + STATE_COLLECTING_DATA, + STATE_COLLECTING_VAR_LEN_DATA, + STATE_READING_DATA, ++ DUMMY_CYCLE_WAIT, + } CMDState; + + typedef enum { +@@ -654,12 +664,16 @@ static inline int get_addr_length(Flash *s) + case QPP_4: + case READ4: + case QIOR4: ++ case OIOR4: + case ERASE4_4K: + case ERASE4_32K: + case ERASE4_SECTOR: + case FAST_READ4: ++ case O_FAST_READ4: + case DOR4: + case QOR4: ++ case OOR4: ++ case OOR4_MT35X: + case DIOR4: + return 4; + default: +@@ -670,6 +684,7 @@ static inline int get_addr_length(Flash *s) + static void complete_collecting_data(Flash *s) + { + int i, n; ++ bool dummy_state = false; + + n = get_addr_length(s); + s->cur_addr = (n == 3 ? s->ear : 0); +@@ -689,9 +704,12 @@ static void complete_collecting_data(Flash *s) + case DPP: + case QPP: + case QPP_4: ++ case OPP: + case PP: ++ s->state = STATE_PAGE_PROGRAM; ++ break; ++ case OPP4: + case PP4: +- case PP4_4: + s->state = STATE_PAGE_PROGRAM; + break; + case AAI_WP: +@@ -702,16 +720,27 @@ static void complete_collecting_data(Flash *s) + case READ: + case READ4: + case FAST_READ: +- case FAST_READ4: ++ case O_FAST_READ: + case DOR: +- case DOR4: + case QOR: +- case QOR4: ++ case OOR: + case DIOR: +- case DIOR4: + case QIOR: ++ case OIOR: ++ case FAST_READ4: ++ case O_FAST_READ4: ++ case DOR4: ++ case QOR4: ++ case OOR4: ++ case OOR4_MT35X: ++ case DIOR4: + case QIOR4: +- s->state = STATE_READ; ++ case OIOR4: ++ if (dummy_state == false) { ++ s->state = STATE_READ; ++ } else { ++ s->state = DUMMY_CYCLE_WAIT; ++ } + break; + case ERASE_4K: + case ERASE4_4K: +@@ -744,7 +773,6 @@ static void complete_collecting_data(Flash *s) + s->write_enable = false; + } + break; +- case BRWR: + case EXTEND_ADDR_WRITE: + s->ear = s->data[0]; + break; +@@ -1038,6 +1066,7 @@ static void decode_qio_read_cmd(Flash *s) + s->needed_bytes += 3; + break; + default: ++ s->needed_bytes += 5; + break; + } + s->pos = 0; +@@ -1066,28 +1095,39 @@ static void decode_new_cmd(Flash *s, uint32_t value) + "M25P80: Invalid cmd within AAI programming sequence"); + } + ++ s->needed_bytes = 0; ++ + switch (value) { + ++ case ERASE4_SECTOR: ++ if (s->four_bytes_address_mode == false) { ++ s->needed_bytes += 1; ++ } + case ERASE_4K: +- case ERASE4_4K: + case ERASE_32K: +- case ERASE4_32K: + case ERASE_SECTOR: +- case ERASE4_SECTOR: ++ case OPP: + case PP: +- case PP4: ++ case QOR: ++ case OOR: ++ case FAST_READ: ++ case O_FAST_READ: ++ case DOR: + case DIE_ERASE: + case RDID_90: + case RDID_AB: +- s->needed_bytes = get_addr_length(s); ++ s->needed_bytes += get_addr_length(s); + s->pos = 0; + s->len = 0; + s->state = STATE_COLLECTING_DATA; + break; +- case READ: + case READ4: ++ if (s->four_bytes_address_mode == false) { ++ s->needed_bytes += 1; ++ } ++ case READ: + if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) == MODE_STD) { +- s->needed_bytes = get_addr_length(s); ++ s->needed_bytes += get_addr_length(s); + s->pos = 0; + s->len = 0; + s->state = STATE_COLLECTING_DATA; +@@ -1098,7 +1138,7 @@ static void decode_new_cmd(Flash *s, uint32_t value) + break; + case DPP: + if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_QIO) { +- s->needed_bytes = get_addr_length(s); ++ s->needed_bytes += get_addr_length(s); + s->pos = 0; + s->len = 0; + s->state = STATE_COLLECTING_DATA; +@@ -1110,8 +1150,11 @@ static void decode_new_cmd(Flash *s, uint32_t value) + case QPP: + case QPP_4: + case PP4_4: ++ if (s->four_bytes_address_mode == false) { ++ s->needed_bytes += 1; ++ } + if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_DIO) { +- s->needed_bytes = get_addr_length(s); ++ s->needed_bytes += get_addr_length(s); + s->pos = 0; + s->len = 0; + s->state = STATE_COLLECTING_DATA; +@@ -1121,11 +1164,9 @@ static void decode_new_cmd(Flash *s, uint32_t value) + } + break; + +- case FAST_READ: + case FAST_READ4: + decode_fast_read_cmd(s); + break; +- case DOR: + case DOR4: + if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_QIO) { + decode_fast_read_cmd(s); +@@ -1134,14 +1175,13 @@ static void decode_new_cmd(Flash *s, uint32_t value) + "QIO mode\n", s->cmd_in_progress); + } + break; +- case QOR: + case QOR4: +- if (get_man(s) != MAN_NUMONYX || numonyx_mode(s) != MODE_DIO) { +- decode_fast_read_cmd(s); +- } else { +- qemu_log_mask(LOG_GUEST_ERROR, "M25P80: Cannot execute cmd %x in " +- "DIO mode\n", s->cmd_in_progress); +- } ++ case OOR4: ++ case OOR4_MT35X: ++ s->needed_bytes += 4; ++ s->pos = 0; ++ s->len = 0; ++ s->state = STATE_COLLECTING_DATA; + break; + + case DIOR: +@@ -1265,6 +1305,7 @@ static void decode_new_cmd(Flash *s, uint32_t value) + s->four_bytes_address_mode = false; + break; + case BRRD: ++ s->data_read_loop = false; + case EXTEND_ADDR_READ: + s->data[0] = s->ear; + s->pos = 0; +@@ -1475,6 +1516,8 @@ static uint32_t m25p80_transfer8(SSIPeripheral *ss, uint32_t tx) + } + break; + ++ case DUMMY_CYCLE_WAIT: ++ break; + default: + case STATE_IDLE: + decode_new_cmd(s, (uint8_t)tx); +-- +``` +There is also missing **0xfd** command for the DDR Octal I/O Fast Read for Micron MT35X chips. I am not sure if it's the same as the **0xfc** command in the Xilinx code though. + +Since I am not the author of the original commit, maybe Xilinx folks could take my patch, update/improve it and send to the mailing list. It will reduce the amount of the changes you have to apply in your fork as well :smile: + +cc @alistair23 diff --git a/results/classifier/gemma3:12b/peripherals/1162644 b/results/classifier/gemma3:12b/peripherals/1162644 new file mode 100644 index 000000000..6f611f37b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1162644 @@ -0,0 +1,91 @@ + +qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base() + +Description: +When QEMU tries to boot with a usb 3.0 tablet (xhci) on a Raring ringtail box (QEMU package1.4.0+dfsg-1expubuntu4) it will crash soon afterwards: + +qemu-system-x86_64: /build/buildd/qemu-1.4.0+dfsg/hw/usb/core.c:552: usb_packet_setup: Assertion `p->iov.iov != ((void *)0)' failed. + +Component: +qemu-system -> 1.4.0+dfsg-1expubuntu4 + +Ubuntu Version: + +Description: Ubuntu Raring Ringtail (development branch) +Release: 13.04 + +Steps to reproduce it: + +I met this bug while running the virt-test suite + +https://github.com/autotest/virt-test + +Instructions to install and run it can be seen on the README file + +https://github.com/autotest/virt-test#readme + +After the suite is set, it can be reproduced on a raring (13.04) simply by running: + +./run -t qemu --tests usb.usb_reboot.usb_tablet.xhci + +Command line: + +23:52:42 INFO | Running qemu command (reformatted): +/usr/bin/kvm \ + -S \ + -name 'virt-tests-vm1' \ + -nodefaults \ + -chardev socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130331-233911-ndvUEvrV,server,nowait \ + -mon chardev=hmp_id_hmp1,mode=readline \ + -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-serial,chardev=serial_id_serial1 \ + -chardev socket,id=seabioslog_id_20130331-233911-ndvUEvrV,path=/tmp/seabios-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-debugcon,chardev=seabioslog_id_20130331-233911-ndvUEvrV,iobase=0x402 \ + -device ich9-usb-uhci1,id=usb1 \ + -device nec-usb-xhci,id=usbtest \ + -drive file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0 \ + -device virtio-blk-pci,drive=virtio0,bootindex=1 \ + -device virtio-net-pci,netdev=idumV1TE,mac='9a:c0:c1:c2:c3:c4',id='idmN7iHv' \ + -netdev user,id=idumV1TE,hostfwd=tcp::5000-:22 \ + -m 1024 \ + -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \ + -cpu 'SandyBridge' \ + -M pc \ + -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ + -device usb-tablet,id=usb-testdev,bus=usbtest.0,port=1 \ + -vnc :0 \ + -vga std \ + -rtc base=utc,clock=host,driftfix=none \ + -boot order=cdn,once=c,menu=off \ + -enable-kvm + +ProblemType: Crash +DistroRelease: Ubuntu 13.04 +Package: qemu-system-x86 1.4.0+dfsg-1expubuntu4 +ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 +Uname: Linux 3.8.0-15-generic x86_64 +ApportVersion: 2.9.2-0ubuntu5 +Architecture: amd64 +Date: Sun Mar 31 23:52:46 2013 +EcryptfsInUse: Yes +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-03-31 (0 days ago) +InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) +MarkForUpload: True +ProcEnviron: + TERM=dumb + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +Signal: 6 +SourcePackage: qemu +StacktraceTop: + raise () from /lib/x86_64-linux-gnu/libc.so.6 + abort () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () from /lib/x86_64-linux-gnu/libc.so.6 + __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () +Title: qemu-system-x86_64 crashed with SIGABRT in raise() +UpgradeStatus: Upgraded to raring on 2013-03-31 (0 days ago) +UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1174 b/results/classifier/gemma3:12b/peripherals/1174 new file mode 100644 index 000000000..dc783fac8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1174 @@ -0,0 +1,14 @@ + +aspeed: Fix first byte in I2C old register mode slave receive +Description of problem: +The first byte of data received through the Aspeed I2C slave controller through the old-register mode (specifically byte-buffered, not pool buffered or DMA buffered) is incorrect. It should be the 8-bit I2C slave address for the transfer, which will be the 7-bit I2C slave address of the I2C controller shifted left 1, and 1 or 0 for the lowest bit (is-slave-to-master-transfer, or is-master-to-slave-transfer). +Steps to reproduce: +You could use the simulated I2C slave EEPROM https://docs.kernel.org/i2c/slave-eeprom-backend.html, but you need another I2C model to send data to it. + +Alternatively, you can take this downstream patch and run the qtest in it. It has a test case for slave-mode rx in old-register mode: + +https://github.com/facebook/openbmc/blob/helium/common/recipes-devtools/qemu/qemu/0008-hw-misc-Add-byte-by-byte-i2c-network-device.patch +Additional information: +I already created the fix, it's pretty simple, I submitted it to the mailing list and Klaus (the author of that section of the Aspeed I2C controller) reviewed it. https://lore.kernel.org/qemu-devel/20220820225712.713209-1-peter@pjd.dev/#t + +This is relatively critical fix, but since slave-mode I2C is not widely used at this point, it's probably fine to ship with this bug. My team uses the master branch for everything anyways. diff --git a/results/classifier/gemma3:12b/peripherals/1181796 b/results/classifier/gemma3:12b/peripherals/1181796 new file mode 100644 index 000000000..09e596667 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1181796 @@ -0,0 +1,10 @@ + +Qemu locks up when incoming serial fills up + +I'm using Windows, I'm not sure if this happens on Linux, but for all I know it does. To repro, fire up any image (ideally one that does almost nothing, and doesn't read the serial port), and use the option "-serial pipe:mypipe". Then use Putty or something else to connect to that named pipe so Qemu starts up. Now start typing into Putty. For a VM image that never reads the serial port, upon typing the 16th character Qemu stops executing instructions in the guest (as evidenced either by being unable to step in gdb, seeing that "info registers" in the monitor always reports the same value, or just by observing that the guest is hung). For OS images that do regularly read the serial port, this may require pasting >16 bytes into Putty at once. This occurs with more than just Putty, use anything that can write at a named pipe. + +I would have expected that bytes get dropped, or even more ideally blocked at the sender's side of the named pipe. I would not expect that the entire VM stops. You seem to be able to unwedge the VM by switching to the monitor and running "i /1c 0x3f8" until you've pulled enough out of buffer that it's happy to run again. Interestingly, all bytes seem to come through (more than just the 16) when read from the monitor. + +I haven't been able to get a source environment set up, but I have tried a few of the Windows binaries. This repros in 1.4.1, 1.3.0, 1.2, and 1.0, the most recent build I found that did not have this behavior was 0.15.0. + +Maybe I'm missing something very obvious, and if so, I apologize in advance. I'm also happy to create an OS image that highlights this problem if it would help. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1186303 b/results/classifier/gemma3:12b/peripherals/1186303 new file mode 100644 index 000000000..3f329d01e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1186303 @@ -0,0 +1,23 @@ + +virtual fat do not working in qemu 1.5.0 + +Guest : windows Seven / XP +Qemu version : 1.5.0 +cmd line : +-drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on +generated by libvirt : + +<disk type='dir' device='floppy'> + <driver name='qemu' type='fat'/> + <source dir='/mnt/vdisk/diskconf/TEST003/'/> + <target dev='fda' bus='fdc'/> + <readonly/> + <alias name='fdc0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + +works with qemu <= 1.4.1 + +with qemu 1.5.0 , guest does not see the floppy content. + +Regards \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1188991 b/results/classifier/gemma3:12b/peripherals/1188991 new file mode 100644 index 000000000..7b8c79df7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1188991 @@ -0,0 +1,61 @@ + +Unable to do serial communication using -chardev tty + + + +Im running an Linux Image (kernel 3.2.8) for beagleboard-xm on QEMU's 1.4.0 emulator. + + +What I want to do is to have a communication between guest and host across serial the 4 differents ttyO present on the guest. QEMU offer facilities to redirect the trafic to some device in the host side. + +The command that I use to lauch QEMU is : + + sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -see -device usb-kbd -chardev tty,id=mytty,path=/dev/ttyS0 + +As it says in the QEMU's manual -chardev is suppose to connect to a local tty device at the path given + +My problem goes like this: + +At the guest kernel boot I'm able to see that my UART where enabled + + [ 2.682040] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled + [ 2.777947] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 + [ 2.794967] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 + [ 2.814942] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 + [ 2.966825] console [ttyO2] enabled + [ 2.984777] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3 + +In fact, when I go see in to /proc/tty/driver and I do a cat on OMAP-SERIAL Im able to see this serinfo:1.0 driver revision: + + 0: uart:OMAP UART0 mmio:0x4806A000 irq:72 tx:0 rx:0 CTS|DSR|CD + 1: uart:OMAP UART1 mmio:0x4806C000 irq:73 tx:0 rx:0 CTS|DSR|CD + 2: uart:OMAP UART2 mmio:0x49020000 irq:74 tx:268 rx:37 RTS|CTS|DTR|DSR|CD + 3: uart:OMAP UART3 mmio:0x49042000 irq:80 tx:0 rx:0 CTS|DSR|CD + +I know that ttyO2 is working because my console is been redirected to it. The thing is that doing a set serial on any of the ttyO I get the following message: + + [root@enu driver]# setserial -a /dev/ttyO0 + /dev/ttyO0, Line 0, UART: undefined, Port: 0x0000, IRQ: 72 + Baud_base: 3000000, close_delay: 50, divisor: 0 + closing_wait: 3000 + Flags: spd_normal + +The same goes with ttyO2. I tryed to set some sethings to any of the ttyO with setserial but I always get the same message: + + [root@enu ~]# setserial /dev/ttyO0 uart 8250 + setserial: can't set serial info: Invalid argument + [root@enu ~]# setserial /dev/ttyO0 port 0x4806a000 + setserial: can't set serial info: Invalid argument + +basicly I want to establish a serial communication between a guest and a host, but the serial ports on the guest side aren't well configured. + +When I open ttyS0 with minicom on the host side and do on the guest side + + echo "test" > /dev/ttyO0 + +The host recives nothing. + +Anyone can tell me how I could remove tty modules on the guest side and try to insert it again to see if the setup resets properly or give me any advice on how to solve this problem. Plus if anyone has already tryed doing this kind on serial communication I would like to here from you. + +Thank, +Francisco \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1191 b/results/classifier/gemma3:12b/peripherals/1191 new file mode 100644 index 000000000..c13787afd --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1191 @@ -0,0 +1,10 @@ + +AC97+CoreAudio no audio when out frequency not 44,1KHz & always forces host to use 44,1KHz (or less if frequency not supported) +Description of problem: +AC97+CoreAudio outputs no audio when output frequency not 44,1KHz. Also always forces host to use 44,1KHz (or less if frequency not supported on host output) +Steps to reproduce: +1. Boot any OS with (only) AC97 audio on macOS +2. Attempt to play audio with output frequency in guest set to 48KHz +3. Observe lack of output +Additional information: +I'm using QEMU to test a Custom OS written by me, but this shouldn't be a code issue on our side, rather an issue with QEMU itself, if this is mistaken, please inform us. diff --git a/results/classifier/gemma3:12b/peripherals/1192 b/results/classifier/gemma3:12b/peripherals/1192 new file mode 100644 index 000000000..9e0905207 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1192 @@ -0,0 +1,136 @@ + +Abort in xhci_find_stream() +Description of problem: +I triggered an abort in xhci_find_stream() [1]. This is because the +secondary stream arrays is enabled by setting linear stream array (LSA) bit (in +endpoint context) to 0. We may show warnings and drop this operation. + +``` c +static XHCIStreamContext *xhci_find_stream(XHCIEPContext *epctx, + unsigned int streamid, + uint32_t *cc_error) +{ + // ... + if (epctx->lsa) { + // ... + } else { + FIXME("secondary streams not implemented yet"); // <----------- [1] + } + // ... +``` +Steps to reproduce: +Step 1: download the prepared rootfs and the image. + +https://drive.google.com/file/d/10C2110VH-GrwACiPebC8-Vgcf5_Ny8Sd/view?usp=sharing +https://drive.google.com/file/d/1jAMf8rtTM8p88gamhNk4HC5Z34XtjUHw/view?usp=sharing + +Step 2: run the following script. + +``` bash +QEMU_PATH=../../../qemu/build/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ + -device qemu-xhci,id=xhci -device usb-storage,drive=disk0 \ + -device usb-bot -device usb-tablet,bus=xhci.0 \ + -chardev null,id=cd0 -chardev null,id=cd1 \ + -device usb-braille,chardev=cd0 -device usb-ccid -device usb-ccid \ + -device usb-kbd -device usb-mouse -device usb-serial,chardev=cd1 \ + -device usb-tablet -device usb-wacom-tablet -device usb-audio \ + -nographic +``` + +Step 3: with spawned shell (the user is root and the password is empty), run +`xhci-00`. +Additional information: +``` +root@5b4fda3ee725:~/videzzo/videzzo_qemu/out-san# DEFAULT_INPUT_MAXSIZE=10000000 /root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci -max_len=10000000 -detect_leaks=0 poc-qemu-videzzo-i386-target-videzzo-fuzz-xhci-crash-4a11736abb111efe4b29a6931f403561f9a0f9ec +==71545==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55e05e05e640). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 2668437424 +INFO: Loaded 1 modules (423456 inline 8-bit counters): 423456 [0x55e0606e8000, 0x55e06074f620), +INFO: Loaded 1 PC tables (423456 PCs): 423456 [0x55e060071ae0,0x55e0606e7ce0), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *capabilities*, *operational*, *runtime*, *doorbell*, *usb3 port* +This process will fuzz the following MemoryRegions: + * usb3 port #1[0] (size 10) + * usb3 port #4[0] (size 10) + * capabilities[0] (size 40) + * usb3 port #3[0] (size 10) + * operational[0] (size 400) + * usb3 port #2[0] (size 10) + * runtime[0] (size 220) + * doorbell[0] (size 820) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * capabilities, EVENT_TYPE_MMIO_READ, 0xe0000000 +0x40, 4,4 + * capabilities, EVENT_TYPE_MMIO_WRITE, 0xe0000000 +0x40, 4,4 + * operational, EVENT_TYPE_MMIO_READ, 0xe0000040 +0x400, 4,8 + * operational, EVENT_TYPE_MMIO_WRITE, 0xe0000040 +0x400, 4,8 + * runtime, EVENT_TYPE_MMIO_READ, 0xe0001000 +0x220, 4,8 + * runtime, EVENT_TYPE_MMIO_WRITE, 0xe0001000 +0x220, 4,8 + * doorbell, EVENT_TYPE_MMIO_READ, 0xe0002000 +0x820, 4,4 + * doorbell, EVENT_TYPE_MMIO_WRITE, 0xe0002000 +0x820, 4,4 + * usb3 port #4, EVENT_TYPE_MMIO_READ, 0xe0000470 +0x10, 4,4 + * usb3 port #4, EVENT_TYPE_MMIO_WRITE, 0xe0000470 +0x10, 4,4 + * usb3 port #1, EVENT_TYPE_MMIO_READ, 0xe0000440 +0x10, 4,4 + * usb3 port #1, EVENT_TYPE_MMIO_WRITE, 0xe0000440 +0x10, 4,4 + * usb3 port #2, EVENT_TYPE_MMIO_READ, 0xe0000450 +0x10, 4,4 + * usb3 port #2, EVENT_TYPE_MMIO_WRITE, 0xe0000450 +0x10, 4,4 + * usb3 port #3, EVENT_TYPE_MMIO_READ, 0xe0000460 +0x10, 4,4 + * usb3 port #3, EVENT_TYPE_MMIO_WRITE, 0xe0000460 +0x10, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 197Mb +Running: poc-qemu-videzzo-i386-target-videzzo-fuzz-xhci-crash-4a11736abb111efe4b29a6931f403561f9a0f9ec +../hw/usb/hcd-xhci.c:1099:25: runtime error: shift exponent 156 is too large for 32-bit type 'int' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/hcd-xhci.c:1099:25 in +FIXME xhci_find_stream:998 secondary streams not implemented yet +==71545== ERROR: libFuzzer: deadly signal + #0 0x55e05a7f874e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55e05a7473c1 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55e05a720c06 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:235:18 + #3 0x55e05a720cd2 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:1 + #4 0x55e05a720cd2 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:206:19 + #5 0x7fa0b025c41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fa0b006e00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fa0b006e00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fa0b004d858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x55e05a828c9a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x55e05bd528c3 in xhci_find_stream /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:998:9 + #11 0x55e05bd46ca5 in xhci_kick_epctx /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:1922:17 + #12 0x55e05bd7d7ff in xhci_kick_ep /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:1838:5 + #13 0x55e05bd94ab9 in xhci_doorbell_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:3163:13 + #14 0x55e05cfed443 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #15 0x55e05cfecd81 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #16 0x55e05cfeb68c in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #17 0x55e05d0760be in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #18 0x55e05d06443b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #19 0x55e05d063ef8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #20 0x55e05a83813b in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1072:5 + #21 0x55e05a8365b5 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1197:28 + #22 0x55e05e059fff in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #23 0x55e05e05137b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #24 0x55e05e051250 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #25 0x55e05a83f17c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1472:12 + #26 0x55e05e05e8e2 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #27 0x55e05a72173d in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:589:17 + #28 0x55e05a7044c4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x55e05a70f43e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:882:19 + #30 0x55e05a6fba46 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7fa0b004f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x55e05a6fba9d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci+0x265aa9d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1192344 b/results/classifier/gemma3:12b/peripherals/1192344 new file mode 100644 index 000000000..4ebe936d7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1192344 @@ -0,0 +1,10 @@ + +qemu crashes on unaligned extended disk reads + +When performing a BIOS extended disk read (INT 13H, AH=0x42), if the offset of the buffer destination in the DAP (disk address packet) is not dword-aligned (i.e. a multiple of 4), SeaBIOS attempts to execute code at non-mapped address 0xb4f53, causing QEMU to crash. I imagine it's a bug in the BIOS code, but it does cause QEMU to crash. + +QEMU version: 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) (from Ubuntu repository) +SeaBIOS version: 1.7.2-20130119_170942-roseapple +command line: qemu-system-x86_64 -m 64 -hda hda.img -monitor stdio +CPU: Intel Core i7 CPU M620 on a Dell Latitude E6410 +OS: Ubuntu, GNU/Linux 3.8.0-25-generic, 64-bit \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1194 b/results/classifier/gemma3:12b/peripherals/1194 new file mode 100644 index 000000000..4b5f7136f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1194 @@ -0,0 +1,16 @@ + +Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom" +Description of problem: +After executing the below command inside adb shell +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ + +I am getting the below error +"qemu-system-aarch64: Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom"" +Steps to reproduce: +1. adb Push qemu-system-aarch64 inside system/bin +2. Run +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ +Additional information: +Kindly help me to proceed further diff --git a/results/classifier/gemma3:12b/peripherals/1204 b/results/classifier/gemma3:12b/peripherals/1204 new file mode 100644 index 000000000..ded3f9590 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1204 @@ -0,0 +1,30 @@ + +AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0 +Description of problem: +As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119). +Memory regions marked as Device do not support unaligned access. +Steps to reproduce: +Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault) +``` +.balign 8 +.global first_variable +first_variable: + .word 0x1 +.balign 4 +.global second_variable +second_variable: + .word 0x2 + +no_mmu_sctlr: .dword 0x0000000030C51834 + +.globl reproducer +reproducer: + ldr x1, no_mmu_sctlr // A=0,M=0 + msr sctlr_el3, x1 + dsb sy + isb + + ldr x0, =first_variable + ldr x1, [x0, #0] // Aligned - Success + ldr x1, [x0, #4] // Unaligned - Success??? (Should be failure) +``` diff --git a/results/classifier/gemma3:12b/peripherals/1205 b/results/classifier/gemma3:12b/peripherals/1205 new file mode 100644 index 000000000..5a63bcfaf --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1205 @@ -0,0 +1,8 @@ + +Cannot use `-serial stdio` on macbook pro, apple silicon +Description of problem: +When I run the command above, it will show below: +``` +(qemu) qemu-system-aarch64: -serial stdio: cannot use stdio by multiple character devices +qemu-system-aarch64: -serial stdio: could not connect serial device to character backend 'stdio' +``` diff --git a/results/classifier/gemma3:12b/peripherals/1207228 b/results/classifier/gemma3:12b/peripherals/1207228 new file mode 100644 index 000000000..876f09453 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1207228 @@ -0,0 +1,14 @@ + +Qemu (trunk code) crashes when using --soundhw all option in ioport.c + +After not building qemu (git version) for about 3 weeks, I've done it again this morning. + +With up-to-date trunk code, I got this error on start, when using --soundhw all option + +$ qemu-system-i386 -soundhw all +qemu-system-i386: /home/fred/Téléchargements/logs/qemu-git/src/qemu/ioport.c:240: portio_list_add: Assertion `pio->offset >= off_last' failed. +Abandon (core dumped) + +And if I use only soundhw with one or more options, it doesn't crash. + +Tell me what you'll need to fix this bug. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1213196 b/results/classifier/gemma3:12b/peripherals/1213196 new file mode 100644 index 000000000..63bd64e81 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1213196 @@ -0,0 +1,4 @@ + +-serial tcp should hang up when DTR goes low + +In keeping with the spirit of serial modem control signals, de-asserting DTR should cause the TCP connection to break; asserting DTR should cause QEMU to initiate a new connection or for it to accept another (in server mode; this may involve waiting for one to arrive, too). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1222034 b/results/classifier/gemma3:12b/peripherals/1222034 new file mode 100644 index 000000000..6d84b913f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1222034 @@ -0,0 +1,20 @@ + +QEMU + SPICE + AUDIO = FAILURE + +Hello it's my first time doing this, since the major round of timer/block changes in August I have not been able to have audio working in any guest with the spice protocol. + +64 bit linux , AMD SVM, IOMMUv1 M5A99X EVO R2.0 + + +Example command line: + +qemu-system-x86_64 -m 1024 -cdrom /common/stor8/torrents/Sabayon_Linux_DAILY_x86_Xfce.iso -soundhw hda -vga qxl -spice port=5999,addr=0.0.0.0,disable-ticketing -enable-kvm + + + +Any time the guest tries to access the emulated hardware it will hang for a very long period of time and play no audio through spice. + +This issue does not happen with the 1.6.0 release. + + +If you are unable to replicate this I will go to the trouble of getting the race message that happens in the guest but I am assuming at this point that my configuration is not exotic and it should be very easy to see the issue. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1224444 b/results/classifier/gemma3:12b/peripherals/1224444 new file mode 100644 index 000000000..59730b19c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1224444 @@ -0,0 +1,55 @@ + +virtio-serial loses writes when used over virtio-mmio + +virtio-serial appears to lose writes, but only when used on top of virtio-mmio. The scenario is this: + +/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \ + -global virtio-blk-device.scsi=off \ + -nodefconfig \ + -nodefaults \ + -nographic \ + -M vexpress-a15 \ + -machine accel=kvm:tcg \ + -m 500 \ + -no-reboot \ + -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1001/kernel.27944 \ + -dtb /home/rjones/d/libguestfs/tmp/.guestfs-1001/dtb.27944 \ + -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1001/initrd.27944 \ + -device virtio-scsi-device,id=scsi \ + -drive file=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ + -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1001/root.27944,snapshot=on,id=appliance,cache=unsafe,if=none \ + -device scsi-hd,drive=appliance \ + -device virtio-serial-device \ + -serial stdio \ + -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0 \ + -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ + -append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color' + +After the guest starts up, a daemon writes 4 bytes to a virtio-serial socket. The host side reads these 4 bytes correctly and writes a 64 byte message. The guest never sees this message. + +I enabled virtio-mmio debugging, and this is what is printed (## = my comment): + +## guest opens the socket: +trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0' +virtio_mmio: virtio_mmio_write offset 0x50 value 0x3 +opened the socket, sock = 3 +udevadm settle +## guest writes 4 bytes to the socket: +virtio_mmio: virtio_mmio_write offset 0x50 value 0x5 +virtio_mmio: virtio_mmio setting IRQ 1 +virtio_mmio: virtio_mmio_read offset 0x60 +virtio_mmio: virtio_mmio_write offset 0x64 value 0x1 +virtio_mmio: virtio_mmio setting IRQ 0 +sent magic GUESTFS_LAUNCH_FLAG +## host reads 4 bytes successfully: +main_loop libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG +libguestfs: [14605ms] appliance is up +Guest launched OK. +## host writes 64 bytes to socket: +libguestfs: writing the data to the socket (size = 64) +waiting for next request +libguestfs: data written OK +## hangs here forever with guest in read() call never receiving any data + +I am using qemu from git today (2d1fe1873a984). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1226 b/results/classifier/gemma3:12b/peripherals/1226 new file mode 100644 index 000000000..94e0b3778 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1226 @@ -0,0 +1,26 @@ + +wheel-axis=false does not get applied at hardware init stage +Description of problem: +`-device virtio-tablet,id=touch0,wheel-axis=false` does not get applied at initalization stage, causing android to see it and treat the device as a pointer instead of a tablet. it seems to look for the prop at init stage, I have verified that this is an issue by fixing it with a quick hack below. ~~setting `-device virtio-tablet,id=touch0,wheel-axis=true` will still work fine and cause android to pick it up as a pointer again~~ + + +EDIT: It does not seem to work actually. if set when the default is set to false +Steps to reproduce: +1. Boot android based VM +2. test an app that forces touch only over pointer +Additional information: +``` +diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c +index a7a244a95d..3175f9c7d5 100644 +--- a/hw/input/virtio-input-hid.c ++++ b/hw/input/virtio-input-hid.c +@@ -477,7 +477,7 @@ static struct virtio_input_config virtio_tablet_config_v2[] = { + }; + + static Property virtio_tablet_properties[] = { +- DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true), ++ DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, false), + DEFINE_PROP_END_OF_LIST(), + }; + +``` diff --git a/results/classifier/gemma3:12b/peripherals/1232 b/results/classifier/gemma3:12b/peripherals/1232 new file mode 100644 index 000000000..887b2b5c4 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1232 @@ -0,0 +1,14 @@ + +AArch64 virt can't write to memory related to gicv3 +Description of problem: +According to the info in generated dtb, the memory-mapped registers of gicv3-distributor have a base addr, which is `0x0800_0000`. +And I have checked the validity by reading `gicd_typer`, which means the base addr is right. + +But when I want to configure the gicv3-distributor (like changing `gicd_ctlr`), the value is not changed, keeping the default value. The same thing happens on any register of GICD in my machine. + +**Even I write to this memory by gdb `set` command, the value is also unchangeable.** + +The addr of `gicd_ctlr` should be `0x0800_0000`(offset=0), which should be readable and writable, isn't it? + +I try to modify the value of this addr in assembly as soon as the **machine starts, without enabling MMU**. +This problem should be easier to reproduce. diff --git a/results/classifier/gemma3:12b/peripherals/1241569 b/results/classifier/gemma3:12b/peripherals/1241569 new file mode 100644 index 000000000..920acf0ec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1241569 @@ -0,0 +1,10 @@ + +qemu-system-alpha console unresponsive + +I have created a virtual machine using the QEMU Alpha emulator (very basic, 1 scsi disc, 1 scsi CDROM, 1gb memory). The machine starts, but entering any system commands at the prompt just echs back the command typed. For example + +>>> show device +got: show device +>>> + +Obviously booting any OS from this is not possible. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1242765 b/results/classifier/gemma3:12b/peripherals/1242765 new file mode 100644 index 000000000..2431ee923 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1242765 @@ -0,0 +1,70 @@ + +USB passthrough to Windows 7 guest fails with error -110, hangs + +Description of problem: + +Using a Sandisk Cruzer Fit 16GB USB thumb drive. +Using virt-manager on Fedora 19 host, and Windows 7 32 bit guest. + +I set up a USB2 controller on Windows 7 guest in virt-manager. Windows sees the USB drive and can open the file manager and correctly show the files. I can copy a file from the thumb drive to the Fedora desktop, and then play the file on the desktop. However, any attempt to open a file directly on the thumb drive (example, play an MP3 using Windows Media Player) results in guest hang and host kernel messages: + + +Oct 19 21:15:35 localhost kernel: [187592.977839] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:40 localhost kernel: [187598.065274] usb 1-1.3: device descriptor read/all, error -110 +Oct 19 21:15:40 localhost kernel: [187598.138167] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:15:56 localhost kernel: [187613.218119] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.399275] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:16:11 localhost kernel: [187628.573355] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:16 localhost kernel: [187633.587778] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.702244] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:21 localhost kernel: [187638.876201] usb 1-1.3: reset high-speed USB device number 13 using ehci-pci +Oct 19 21:16:26 localhost kernel: [187643.890642] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.005071] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:16:31 localhost kernel: [187649.106188] usb 1-1.3: USB disconnect, device number 13 +Oct 19 21:16:31 localhost kernel: [187649.178969] usb 1-1.3: new high-speed USB device number 14 using ehci-pci +Oct 19 21:16:47 localhost kernel: [187664.258945] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.440092] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:02 localhost kernel: [187679.614194] usb 1-1.3: new high-speed USB device number 15 using ehci-pci +Oct 19 21:17:17 localhost kernel: [187694.694148] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187709.875297] usb 1-1.3: device descriptor read/64, error -110 +Oct 19 21:17:32 localhost kernel: [187710.049386] usb 1-1.3: new high-speed USB device number 16 using ehci-pci +Oct 19 21:17:37 localhost kernel: [187715.063803] usb 1-1.3: device descriptor read/8, error -110 +Oct 19 21:17:41 localhost kernel: [187719.005453] usb 1-1.3: device descriptor read/8, error -71 + +After that -71 error, the thumb drive completely disappears from the host, as if it is powered down. + +I read that -110 is supposedly a power issue. I can play media files directly from the thumb drive on the host, so the power seems fine on the host. + + +How reproducible: +always + + +Steps to reproduce: +1. use virt-manager, create a Windows 7 32 bit guest +2. in virt-manager, set Controller USB to USB2 +3. on host, insert Sandisk Cruser Fit thumb drive FAT32 format, with an MP3 file on it +4. in virt-manager, add a USB passthrough device and assign it to thumb drive +5. boot Windows 7 guest +6. verify that Windows 7 can see the thumb drive +7. use Windows Media Player to play MP3 + +Actual results: +guest hangs, then host powers off thumb drive + +Expected results: +The MP3 file should play :) + + +Additional info: + +Fedora 19 + +Installed Packages +qemu-common.x86_64 2:1.4.2-11.fc19 @updates +qemu-guest-agent.x86_64 2:1.4.2-11.fc19 @updates +qemu-img.x86_64 2:1.4.2-11.fc19 @updates +qemu-kvm.x86_64 2:1.4.2-11.fc19 @updates +qemu-system-x86.x86_64 2:1.4.2-11.fc19 @updates +virt-manager.noarch 0.10.0-3.fc19 @updates +kernel.x86_64 3.11.1-200.fc19 @updates \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1246890 b/results/classifier/gemma3:12b/peripherals/1246890 new file mode 100644 index 000000000..a8cff8c53 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1246890 @@ -0,0 +1,15 @@ + +AC97 sound card crashes QEMU + +The AC97 sound card does not work. It stops QEMU on startup. The cause appears to be some kind of deadlock. + +Steps to reproduce: +Just add -soundhw ac97 to QEMU's arguments. Example: qemu-system-ppc -soundhw ac97 + +The example above is all it takes to reproduce the problem. + +This problem has been observed on Mac OS X and Debian Linux. + +I question whether the ac97 support ever worked. It is a file that was taken from VirtualBox and added to QEMU. I do know that VirtualBox's support for the ac97 sound card works perfectly. + +The exact line of code that stops QEMU in its tracks is located in the file main-loop.c, in the function os_host_main_loop_wait(), the call made to qemu_mutex_lock_iothread(). The is where QEMU stops under Mac OS X. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1255303 b/results/classifier/gemma3:12b/peripherals/1255303 new file mode 100644 index 000000000..35304b7c0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1255303 @@ -0,0 +1,24 @@ + +ALSA underruns occurr when using QEMU + +I'm running QEMU 1.6.1 on a 64-bit Gentoo Linux system. The guest operating system is Windows 7 32-bit. I get multiple identical warning messages when using the ac97 or hda sound cards: + +> ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.27.2/work/alsa-lib-1.0.27.2/src/pcm/pcm.c:7843:(snd_pcm_recover) underrun occurred + +The difference between ac97 and hda is that the former works well, while the latter causes the sound to be garbled. + +/var/tmp/portage is the directory where Portage, the Gentoo package manager, builds programs. I don't know why it is mentioned in the error message. + +I also don't know if this is an ALSA problem or a QEMU problem. + +The command I use is: + +> qemu-system-i386 -cpu host -m 1G -k it -drive file=~/QEMU/Windows_7_Privato.qcow2,media=disk,index=0 -vga std -net nic -net user -enable-kvm -display sdl -soundhw ac97 -device usb-ehci,id=ehci -usb -rtc base=localtime -usbdevice tablet + +My real sound card is an Intel HD Audio: + +> lspci | grep "Audio device" + +> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) + +Please tell me if you need other informations. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1258 b/results/classifier/gemma3:12b/peripherals/1258 new file mode 100644 index 000000000..a0fd1212d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1258 @@ -0,0 +1,2 @@ + +nios2 system tests are exiting early and not showing an error diff --git a/results/classifier/gemma3:12b/peripherals/1258626 b/results/classifier/gemma3:12b/peripherals/1258626 new file mode 100644 index 000000000..649f87dd7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1258626 @@ -0,0 +1,10 @@ + +Curses Keyboard Broken On OS X + +Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k en-gb'') on OS X 10.9, the keyboard does not work properly. For example, when attempting to switch to the QEMU console with Alt+2, I get: + +``Warning: no scancode found for keysym 226 +Warning: no scancode found for keysym 130 +Warning: no scancode found for keysym 172'' + +I have checked and these scancodes are not mentioned in ``share/qemu/keymaps/''. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1259 b/results/classifier/gemma3:12b/peripherals/1259 new file mode 100644 index 000000000..690f1164b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1259 @@ -0,0 +1,2 @@ + +RISC-V csr diff --git a/results/classifier/gemma3:12b/peripherals/126 b/results/classifier/gemma3:12b/peripherals/126 new file mode 100644 index 000000000..6c3d4ba7c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/126 @@ -0,0 +1,2 @@ + +qemu-input: Mouse stops working in Windows guest diff --git a/results/classifier/gemma3:12b/peripherals/1263 b/results/classifier/gemma3:12b/peripherals/1263 new file mode 100644 index 000000000..e58b2bd8f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1263 @@ -0,0 +1,2 @@ + +arm/imx EPIT timer interrupt does not fire properly on sabrelight diff --git a/results/classifier/gemma3:12b/peripherals/1267520 b/results/classifier/gemma3:12b/peripherals/1267520 new file mode 100644 index 000000000..2ba4176ae --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1267520 @@ -0,0 +1,6 @@ + +Keyboard input not working when the "-k en-us" argument is specified. + +This bug occurs on qemu compiled with i386_softmmu and x86-64_softmmu on linux kernel 3.5.0. +Whenever I run qemu (both i386 and x86_64) to use the en-us language (even though it is the default), I get "Warning: no scancode found for keysym X" (X is an integer). +In the disk image I need qemu to run, I had a shell set up. The shell doesn't register keyboard input when the '-k en-us' command line argument is set when running qemu. I did not have this problem with earlier versions of qemu. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1276879 b/results/classifier/gemma3:12b/peripherals/1276879 new file mode 100644 index 000000000..c8c1dbb94 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1276879 @@ -0,0 +1,17 @@ + +lots of dma command 10, 14 not supported + +Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. +In the terminal that started QEMU, there are a lot of + dma: command 10 not supported +and + dma: command 14 not supported +messages. When the installation of NeXTSTEP gets to +'preparing disk for nextstep installation', there are a lot +of messages that ATA command c5 failed and other info. +The result is a failed installation. + +Is this a bug in QEMU? Is there a workaround, e.g. by +disabling DMA altogether? + +thank you \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1285508 b/results/classifier/gemma3:12b/peripherals/1285508 new file mode 100644 index 000000000..774ba2dec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1285508 @@ -0,0 +1,10 @@ + +[ppa 2.0~git-20140225] mouse cursor invisible with Ubuntu live system + +As requested on u-devel@, I tested QEMU 2.0~git-20140225.aa0d1f4-0ubuntu2 from ppa:ubuntu-virt/candidate. This has a regression with the mouse cursor. + +I downloaded the current Ubuntu Desktop trusty beta-1 amd64 image, and booted it in QEMU: + + $ kvm -m 2048 -cdrom trusty-desktop-amd64.iso + +This boots fine, but in the desktop I don't see any mouse cursor. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1289788 b/results/classifier/gemma3:12b/peripherals/1289788 new file mode 100644 index 000000000..f71eb8516 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1289788 @@ -0,0 +1,4 @@ + +MIDI access (not only adlib) hangs WinNT on QEMU 1.7.x + +Windows NT 4.0 and 2000 (including the latest git release), when enabling adlib (with sb16 already enabled) or the built-in synth of the es1370, hang on QEMU 1.7.x (also with 1.7.50) when they try to play MIDI files (like canyon.mid, etc). I have already tried bisecting but seems that this bug has been introduced sometime in 1.7.0's development time. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1305 b/results/classifier/gemma3:12b/peripherals/1305 new file mode 100644 index 000000000..a25b3daf5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1305 @@ -0,0 +1,15 @@ + +qemu will detach usbredir if backend chardev socket disconnect +Description of problem: +When using the usbredir device in the VM, initiate a hot migration to the VM. +After the migration is completed, the drive letter of the usb in the VM has changed. +Actually the device has been unplugged and re-plugged in the VM. +I think we should keep the plugged state of the device after the migration? +Steps to reproduce: +1. Start a usbredirserver `usbredirserver -p 7000 -v 4 5-2`; +2. Start a VM with a usbredir device attached to it; +3. Mount the usb device in the VM; +4. Migrate the VM, after the migration done, wait a minute，the drive letter of the usb in the VM has changed. +Additional information: +I've found this bug https://bugzilla.redhat.com/show_bug.cgi?id=1254971, this is just to allow the chardev to be reconnected in time when it is disconnected. +Can we make chardev reconnect without unpluging the usbredir device? diff --git a/results/classifier/gemma3:12b/peripherals/1307281 b/results/classifier/gemma3:12b/peripherals/1307281 new file mode 100644 index 000000000..2ba6a7d88 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1307281 @@ -0,0 +1,11 @@ + +qemu crash with assertion in usb_packet_complete_one + +qemu release verison: 1.7.1 +guest os : win7 32bits +qemu cmdline: +/usr/bin/qemu-system-x86_64 -name hch_test -S -machine pc-i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=12,threads=2 -uuid 5ad433c9-e490-42f3-b365-c30d756fbd70 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hch_test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/opt/cvm/hch_test/hch_test.inst,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/data/hugedisk/hch_test/hch_test_share.add,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f2:05:b7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/hch_test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -spice port=5903,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0 + +i use spice to connect to vm and utilize usb redirection. i plug a u-disk into a remote computer and start copy a big file (3G+) to u-disk and qemu was crashed in the middle of the transmission. + +i check the qemu log and found this log: "qemu-system-x86_64: hw/usb/core.c:438: usb_packet_complete_one: Assertion `p->stream || ((&ep->queue)->tqh_first) == p' failed". this crash can be reproduced every time. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1309034 b/results/classifier/gemma3:12b/peripherals/1309034 new file mode 100644 index 000000000..139361ea9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1309034 @@ -0,0 +1,29 @@ + +A way not to grab keyboards or mice + +I set up the window manager to move windows with Alt-Btn1, and to +iconify windows with Shift-Btn1. But since qemu grabs keyboards and +mice, I can't move or iconify the qemu window. + +I tried not to grab anything, by inserting return, just beginnig of +ui/sdl.c:sdl_grab_start() as follows: + +static void sdl_grab_start(void) +{ + return; + /* + +It is comfortable. I'm glad if you make a way not to grab. +Environment variables, options, etc are welcome. + +Current command line is: +QEMU_AUDIO_DRV=pa /usr/local/bin/qemu-system-x86_64 -enable-kvm -hda /dosc/win8_x64.img -soundhw hda -boot c -m 2G -cpu Nehalem,+sep -usb -usbdevice tablet -display sdl -rtc base=localtime + +qemu version is: +luna:linux % qemu-system-x86_64 --version +QEMU emulator version 1.7.93, Copyright (c) 2003-2008 Fabrice Bellard +luna:linux % + +Host: slackware64 14.1 +Host Environment: xfce4 / sawfish +Guest: Windows 8.1 x64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1311 b/results/classifier/gemma3:12b/peripherals/1311 new file mode 100644 index 000000000..eacffe78b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1311 @@ -0,0 +1,2 @@ + +riscv-qemu can't record interrupt diff --git a/results/classifier/gemma3:12b/peripherals/1313816 b/results/classifier/gemma3:12b/peripherals/1313816 new file mode 100644 index 000000000..3bab53a6f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1313816 @@ -0,0 +1,23 @@ + +qemu should close sound device when no more needs. + +I use alsa directly or via pulseaudio on qemu. +And I use xmms2 as well as qemu. + +When I use alsa, one of xmms2 or qemu can play sound. +When I use pulseaudio with qemu and pulseaudio -k, and pulseaudio --start, +qemu can't play sound. + +I think that: +- qemu should open sound device when needs. +- qemu should close sound device when no more needs. + +One of xmms2 or qemu can play sound, but both of them rarely play sound +at the same time. +qemu occurs error on pulseaudio -k, but once close and open the device, +the error will be recovered, I hope. + +Host: slackware64 14.1, linux kernel 3.14.2 +Qemu: 2.0.0 +QEMU_AUDIO_DRV=pa /usr/local/bin/qemu-system-x86_64 -enable-kvm -hda /dosc/win8_x64.img -soundhw hda -boot c -m 2G -cpu host -usb -usbdevice tablet -display sdl -rtc base=localtime +Guest: Windows 8.1 x64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1318474 b/results/classifier/gemma3:12b/peripherals/1318474 new file mode 100644 index 000000000..d0dc8024c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1318474 @@ -0,0 +1,14 @@ + +QEMU update causes Windows reactivation + +After updating QEMU the guest OS's detect new hardware. As a result any Windows OS sees it as a significant change in hardware and require a reactivation. + +Host OS: Ubuntu 14.04 64-bit + +Guest OS's: +Windows Server 2003 R2 Enterprise +Windows Server 2008 R2 Enterprise +Windows Server 2008 R2 Web +Windows Server 2008 R2 Data Center + +QEMU version: 2.0.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1320360 b/results/classifier/gemma3:12b/peripherals/1320360 new file mode 100644 index 000000000..9db58e311 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1320360 @@ -0,0 +1,18 @@ + +usb passthrough not working anymore + +Hi, + +I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but starting with qemu 2.0.0 passthrough stop working. I can still add the usb device but when I start the guest following message appears: + +"unable to execute QEMU command 'device_add': 'usb-host' is not a valid device model name" + +Then the guest will not start. + +I try it with different usb devices (iphone, stick, hdd), always the same error. + +Are there any news / hints about this ? + +Regards + +Martin \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1323 b/results/classifier/gemma3:12b/peripherals/1323 new file mode 100644 index 000000000..fef8368cb --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1323 @@ -0,0 +1,18 @@ + +qemu-system-x86_64: keyboard not available in cd boot menu +Description of problem: +While CD boot menu is shown, no keys input affects the CD boot menu +Steps to reproduce: +1. Execute qemu-system-x86_64 -m 1536 -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +2. Wait for boot menu +3. Try to choose entry +Additional information: +Also occurs with other ISOs + + ``` + qemu-system-x86_64 -m 1536 -cdrom debian-10.8.0-amd64-netinst.iso + ``` + +Does not occur with provided edk2 firmware + +Does not occur with QEMU emulator version 7.1.0 diff --git a/results/classifier/gemma3:12b/peripherals/1323758 b/results/classifier/gemma3:12b/peripherals/1323758 new file mode 100644 index 000000000..a8c834309 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1323758 @@ -0,0 +1,10 @@ + +Mouse stops working when connected usb-storage-device + +I'm running a guest that has Windows 8 Pro (x64) installed. Every time I pass through a usb storage device from the host to the guest, the mouse stops working in the vnc client. When I remove the usb-device the mouse works again. + +The mouse only stops working when I pass through a usb storage device and then make the vlc viewer (client) inactief by clicking on another program on the local computer (where I'm running the vnc viewer (client)). As long as I keep the vnc viewer active, the mouse works without any problems. But as soon as I make the vnc viewer inactief and then active again, the mouse will no longer work. I have to reboot the guest or remove the usb storage device. + +I can't find any related problems on the internet, so it may be just me? + +I hope someone can help me with this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1326 b/results/classifier/gemma3:12b/peripherals/1326 new file mode 100644 index 000000000..9d874fc57 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1326 @@ -0,0 +1,59 @@ + +qemu-system-aarch64: piix3 or ehci usb controller and usb kbd don't work +Description of problem: +the usb device initialization failed in vm, and can not input in vnc console + +message for virtual machine: + +``` +root@localhost ~]# dmesg | grep -i usb +[ 0.925798] ACPI: bus type USB registered +[ 0.927204] usbcore: registered new interface driver usbfs +[ 0.928980] usbcore: registered new interface driver hub +[ 0.930746] usbcore: registered new device driver usb +[ 2.329004] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 2.332659] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 2.336069] uhci_hcd: USB Universal Host Controller Interface driver +[ 2.342659] uhci_hcd 0000:02:02.0: new USB bus registered, assigned bus number 1 +[ 2.348905] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.18 +[ 2.352268] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 2.354598] usb usb1: Product: UHCI Host Controller +[ 2.356194] usb usb1: Manufacturer: Linux 4.18.0-305.3.1.el8.aarch64 uhci_hcd +[ 2.358474] usb usb1: SerialNumber: 0000:02:02.0 +[ 2.360228] hub 1-0:1.0: USB hub found +[ 2.363347] usbcore: registered new interface driver usbserial_generic +[ 2.365456] usbserial: USB Serial support registered for generic +[ 2.384154] usbcore: registered new interface driver usbhid +[ 2.385962] usbhid: USB HID core driver +[ 2.730277] usb 1-1: new full-speed USB device number 2 using uhci_hcd +[ 18.509908] usb 1-1: device descriptor read/64, error -110 +[ 34.509908] usb 1-1: device descriptor read/64, error -110 +[ 34.779906] usb 1-1: new full-speed USB device number 3 using uhci_hcd +[ 50.509910] usb 1-1: device descriptor read/64, error -110 +[ 66.509907] usb 1-1: device descriptor read/64, error -110 +[ 66.629982] usb usb1-port1: attempt power cycle +[ 67.119904] usb 1-1: new full-speed USB device number 4 using uhci_hcd +[ 78.079921] usb 1-1: device not accepting address 4, error -110 +[ 78.229962] usb 1-1: new full-speed USB device number 5 using uhci_hcd +[ 89.079917] usb 1-1: device not accepting address 5, error -110 +[ 89.082006] usb usb1-port1: unable to enumerate USB device +[ 89.229908] usb 1-2: new full-speed USB device number 6 using uhci_hcd +[ 105.009910] usb 1-2: device descriptor read/64, error -110 +[ 121.009910] usb 1-2: device descriptor read/64, error -110 +[ 121.279907] usb 1-2: new full-speed USB device number 7 using uhci_hcd +[ 137.009910] usb 1-2: device descriptor read/64, error -110 +[ 153.009925] usb 1-2: device descriptor read/64, error -110 +[ 153.129984] usb usb1-port2: attempt power cycle +[ 153.619917] usb 1-2: new full-speed USB device number 8 using uhci_hcd +[ 164.579912] usb 1-2: device not accepting address 8, error -110 +[ 164.729913] usb 1-2: new full-speed USB device number 9 using uhci_hcd +[ 175.329921] usb 1-2: device not accepting address 9, error -110 +[ 175.331973] usb usb1-port2: unable to enumerate USB device +``` +Steps to reproduce: +1. ./configure +2. make -j60 +3.virsh create vm.xml +[vm.xml](/uploads/9f946b3637f68c9cd029dfb650f5bd57/vm.xml) +Additional information: +the commit "1c2cb7e0b3" cause the problem, but i don't know the reason diff --git a/results/classifier/gemma3:12b/peripherals/1331 b/results/classifier/gemma3:12b/peripherals/1331 new file mode 100644 index 000000000..b3e9a68d3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1331 @@ -0,0 +1,2 @@ + +risc-v sstatus bug diff --git a/results/classifier/gemma3:12b/peripherals/1332 b/results/classifier/gemma3:12b/peripherals/1332 new file mode 100644 index 000000000..76a130895 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1332 @@ -0,0 +1,2 @@ + +qemu.log missing sstatus register on RISC-V diff --git a/results/classifier/gemma3:12b/peripherals/1334397 b/results/classifier/gemma3:12b/peripherals/1334397 new file mode 100644 index 000000000..349d8fa11 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1334397 @@ -0,0 +1,9 @@ + +cmos RTC alarms no longer wake system from suspend + +Running QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), booting Linux kernels with qemu-system-x86_64 and qemu-system-i386, I no longer see the system resume from suspend when an RTC alarm is set. + +My simple test application can be found here: +https://github.com/johnstultz-work/timetests/blob/master/alarmtimer-suspend.c + +Previously this worked w/ QEMU 1.5 (bascially up until I upgraded from Ubuntu 13.10 to Ubuntu 14.04, which came with 2.0). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1353346 b/results/classifier/gemma3:12b/peripherals/1353346 new file mode 100644 index 000000000..7f575a2d5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1353346 @@ -0,0 +1,12 @@ + +ARMv7-M software-triggered interrupts-- unexpected behaviour + +The handling of the NVIC "Software Triggered Interrupt Register" in qemu-2.1.0/hw/intc/armv7m_nvic.c:375 isn't quite right. As things stand, writing a zero to the STIR ends up transferring control to vector table entry zero, which, on ARMv7-M, holds the reset value of the stack pointer. That's what I see with lm3s811evb emulation, and that's not what happens on my STM NUCLEO-F103RB board (Cortex-M3). + +Seems like an oversight-- the handler probably wants armv7m_nvic_set_pending(), not gic_set_pending_private(), and the IRQ number needs 16 added onto it to get the exception number for the interrupt. + +ARM DUI 0552A (Cortex-M3 Devices: Generic User's Guide), p. 134: + "Interrupt ID of the interrupt to trigger, in the range 0-239. For example, a value of 0x03 specifies interrupt IRQ3." + +Cheers, +Boris \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1366363 b/results/classifier/gemma3:12b/peripherals/1366363 new file mode 100644 index 000000000..3e0e36d6e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1366363 @@ -0,0 +1,12 @@ + +qemu-git gravis ultrasound not working + +Qemu git 2.1.50 with dos622 and windows 3.11. + +Parameter: + +For build: default-configs/sound.mak CONFIG_GUS=y + +Starting parameter: qemu-system-i386 -cpu 486 -m 32M -vga cirrus -hda disk1.img -soundhw gus,pcspk -parallel none -net nic,model=ne2k_isa -net user + +The installer of GUS driver 4.11 does not recognize the card. And conscan tells me that ioport 220-240 and not safe for synth base. It seems that there is a port conflict. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1368204 b/results/classifier/gemma3:12b/peripherals/1368204 new file mode 100644 index 000000000..ff183e09d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1368204 @@ -0,0 +1,16 @@ + +WinME isn't able to detect QEMU's cdrom drive and other hard drives automatically + +On a fresh installation of Windows Millennium (WinME) in qemu, Windows Me isn't able to find the CD-ROM drive or additional hard drives other than -hda at first place. + +Only if i add manually an IDE controller driver in Windows ME's device manager, the CD-ROM inserted in QEMU is found. +Thus an IDE controller isn't found automatically either. + +This shouldn't be the case. On normal real hardware, Windows ME would find at least one IDE or SCSI controller. + +The command line that was used is the following: +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 + +qemu's version is: +qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1373228 b/results/classifier/gemma3:12b/peripherals/1373228 new file mode 100644 index 000000000..8ebce0082 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1373228 @@ -0,0 +1,103 @@ + +Crash upon adding a USB device in Windows 7 (64-bit) + +Command line: + +qemu-system-x86_64 -cpu host -smp cores=2,threads=2 -boot menu=on -m 6144 -soundhw ac97 -drive file=win7.raw,if=virtio -cdrom virtio-win-0.1-81.iso -vga qxl -usb -device nec-usb-xhci,id=xhci -spice port=5924,disable-ticketing -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -monitor stdio -enable-kvm + +QEMU version: + +git master branch (QEMU emulator version 2.1.50, commit hash: 769188d3bbf95ce8d96a335624234dad083f4db6) + +This happens when I plug in the USB flash drive (or any other USB device, just using the flash drive for testing) and run the following command in the QEMU command-line: + +(qemu) device_add usb-host,vendorid=0x12f7,productid=0x1a00,bus=xhci.0 +(qemu) qemu-system-x86_64: /var/tmp/portage/app-emulation/qemu-9999/work/qemu-9999/hw/usb/hcd-xhci.c:897: xhci_events_update: Assertion `intr->er_full' failed. + +Then, QEMU just crashes/dies. + +Meanwhile, dmesg shows this: + +[ 3444.894865] usb 1-2: new high-speed USB device number 8 using xhci_hcd +[ 3445.063285] usb 1-2: New USB device found, idVendor=12f7, idProduct=1a00 +[ 3445.063288] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[ 3445.063290] usb 1-2: Product: Flashdrive 601B +[ 3445.063291] usb 1-2: Manufacturer: Memorex +[ 3445.063292] usb 1-2: SerialNumber: 076A122122DB +[ 3445.063854] usb-storage 1-2:1.0: USB Mass Storage device detected +[ 3445.063923] scsi host3: usb-storage 1-2:1.0 +[ 3446.068031] scsi 3:0:0:0: Direct-Access Memorex Flashdrive 601B PMAP PQ: 0 ANSI: 0 CCS +[ 3446.499830] sd 3:0:0:0: [sdd] 977664 512-byte logical blocks: (500 MB/477 MiB) +[ 3446.500005] sd 3:0:0:0: [sdd] Write Protect is off +[ 3446.500008] sd 3:0:0:0: [sdd] Mode Sense: 23 00 00 00 +[ 3446.500138] sd 3:0:0:0: [sdd] No Caching mode page found +[ 3446.500141] sd 3:0:0:0: [sdd] Assuming drive cache: write through +[ 3446.501591] sdd: sdd1 +[ 3446.502321] sd 3:0:0:0: [sdd] Attached SCSI removable disk +[ 3535.501320] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3535.501348] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3535.501350] usb 1-2: hub failed to enable device, error -22 +[ 3535.654313] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3535.654347] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3535.654349] usb 1-2: hub failed to enable device, error -22 +[ 3535.807428] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3535.820755] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b5569c0 +[ 3535.820757] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b556a08 +[ 3536.016706] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3536.016737] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3536.016739] usb 1-2: hub failed to enable device, error -22 +[ 3536.169702] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3536.169737] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3536.169738] usb 1-2: hub failed to enable device, error -22 +[ 3536.322817] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3536.336160] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b5569c0 +[ 3536.336162] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b556a08 +[ 3536.532116] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3536.532144] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3536.532146] usb 1-2: hub failed to enable device, error -22 +[ 3536.685090] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3536.685125] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3536.685126] usb 1-2: hub failed to enable device, error -22 +[ 3536.838204] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3536.851539] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b5569c0 +[ 3536.851541] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b556a08 +[ 3542.168509] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3542.168531] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3542.168535] usb 1-2: hub failed to enable device, error -22 +[ 3542.321423] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3542.321445] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 9. +[ 3542.321449] usb 1-2: hub failed to enable device, error -22 +[ 3542.474538] usb 1-2: reset high-speed USB device number 8 using xhci_hcd +[ 3542.488160] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b5569c0 +[ 3542.488164] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045b556a08 + +For good measure, here is lspci -nn from the host: + +00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) +00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0a2e] (rev 09) +00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09) +00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) +00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 [8086:9c3a] (rev 04) +00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04) +00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 1 [8086:9c10] (rev e4) +00:1c.1 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 2 [8086:9c12] (rev e4) +00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 [8086:9c14] (rev e4) +00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 5 [8086:9c18] (rev e4) +00:1c.5 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 6 [8086:9c1a] (rev e4) +00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c43] (rev 04) +00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04) +02:00.0 Multimedia controller [0480]: Broadcom Corporation Device [14e4:1570] +03:00.0 Network controller [0280]: Broadcom Corporation BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03) +04:00.0 SATA controller [0106]: Samsung Electronics Co Ltd Apple PCIe SSD [144d:1600] (rev 01) +05:00.0 PCI bridge [0604]: Intel Corporation Device [8086:156d] +06:00.0 PCI bridge [0604]: Intel Corporation Device [8086:156d] +06:03.0 PCI bridge [0604]: Intel Corporation Device [8086:156d] +06:04.0 PCI bridge [0604]: Intel Corporation Device [8086:156d] +06:05.0 PCI bridge [0604]: Intel Corporation Device [8086:156d] +06:06.0 PCI bridge [0604]: Intel Corporation Device [8086:156d] +07:00.0 System peripheral [0880]: Intel Corporation Device [8086:156c] + +Please let me know what other information you need and I'll try to provide it. + +Many thanks, +uriah \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1377095 b/results/classifier/gemma3:12b/peripherals/1377095 new file mode 100644 index 000000000..3b75e4b37 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1377095 @@ -0,0 +1,24 @@ + +KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on + + +Host OS: Gentoo, all packages built 2014-10-01 + +qemu version 2.1.0-r1 + +Linux kernel 3.14.14 x86_64 Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz GenuineIntel GNU/Linux + + +Guest VM: Debian 7 (Wheezy) Linux 3.2.0 686 + + +Start command: +/usr/bin/qemu-system-i386 -enable-kvm -name wheezy -k de -serial null -parallel null -hda /var/kvm/wheezy.kvm-img -daemonize -net nic,macaddr=02:00:00:00:01:31 -net tap,ifname=tap3,script=no,downscript=no -m 512 -pidfile /var/run/kvm/wheezy.pid -usb -usbdevice tablet -runas myuser -vnc 127.0.0.1:3 -usbdevice host:04e8:3242 + +Problem: +USB printer pass-through from KVM host to guest vm only works if I start the qemu kvm when the USB printer (vendor/product ID 04e8:3242) is switched on and therefore shown in lsusb on the host. Then it is available in the started VM. + +But when I switch the usb printer attached to the host off, it disappears in lsusb both on the host and the VM (as expected) but when I switch the USB printer on again, it is shown on the host and also on the QEMU Monitor (Crtl Alt Shift 2 -> info usbhost), but in the VM lsusb does not show it again- so USB pass-through / hot plugging does not work. It worked with a previous Version of qemu (1.0 or something). + +That is very annoying, because every time I want to print something, I need to shutdown the VM, start the printer, and then start the VM (which runs cups as printer server). +But after printing, I do not want the printer to keep running, so I switch it off. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1381846 b/results/classifier/gemma3:12b/peripherals/1381846 new file mode 100644 index 000000000..ff57996b8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1381846 @@ -0,0 +1,9 @@ + +Data sent to parallel port in guest is lost if host buffer fills up + +It appears that qemu will blindly write characters out to the chardev and drop them on the floor if a write fails with EAGAIN, without initiating flow control (via BUSY and ACK) back to the guest. If the host buffer is too small, or is talking to a hardware device that is too slow, data will be lost. + +I notice this problem when I run a DOS program with this on the qemu command line: +-parallel /dev/usb/lp0 + +I can work around this problem by buffering via a pipe, but this looks like a general problem. Is there a way to wire up the readiness of the output chardev to the parallel port ACK and BUSY lines, and signal an ISA interrupt? I don't know the code well enough to tell. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1386197 b/results/classifier/gemma3:12b/peripherals/1386197 new file mode 100644 index 000000000..3e4d90bd0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1386197 @@ -0,0 +1,12 @@ + +keyboard suddenly stops working in VM and problem persists until host reboot. All super-standard setup no funny stuff + +QEMU emulator version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard +Linux HOST 3.16.3-1-ck #1 SMP PREEMPT Sun Sep 21 11:27:46 CEST 2014 x86_64 GNU/Linux + +qemu-system-x86_64 -daemonize -enable-kvm -cpu host -smp 4,maxcpus=4,sockets=1,cores=2,threads=1 -m 4096 -monitor telnet:127.0.0.1:4446,server,nowait -vga qxl -spice port=5556,ipv4,addr=127.0.0.1,disable-ticketing -soundhw all -net tap,script=no,ifname=vm6,vlan=0,vnet_hdr=on -net nic,macaddr=52:54:00:2A:F1:16,vlan=0,model=virtio -drive file=/mnt/2/VM/vm-centos.qcow2,cache=writeback,index=0,media=disk,if=virtio,aio=native -boot c -vnc :6 + + +I already had this with ubanto VM so I installed a centos one but then I type HDD password in VNC suddenly keyboard stops working forever. Kill qemu, stop qemu, start again ... same issue. Very strange. Problem in VNC, problem in vga std problem in spicec problem with options problem without options, SDL no SDL and nothing helps. dmesg only shows unhandled wrmsr like always .. so irrelevant. + +Must be problem with new kernel or nvidia driver mystery magic I suppose? But I had riced CK kernel before and no issue. Hardware didn't change. Nothing works, what is this? Can do sendkey 1 1 in console no issue. So why is all keyboard input dead in mid-operation? You see after reboot I open VM and no matter what VNC or spicec or SDL I input keyboard all normal then this! BAM all keyboard input gone! So in ubuntu I still had mouse so I used onscreen keyboard to enable SSH and then I didn't care. But now I have harddrive password, what can I do? Install different QEMU but I suppose problem with new kernel xorg stuff rather ... Can't change that! Help much appreciated. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1386478 b/results/classifier/gemma3:12b/peripherals/1386478 new file mode 100644 index 000000000..a0ef5c745 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1386478 @@ -0,0 +1,6 @@ + +PS/2 keyboard returns incorrect scan code for F7 to guest + +Using qemu 2.1 as supplied in Debian jessie, the F7 scan code (scan set 2) is being returned by qemu to the guest as 0x02, and not the correct value of 0x83. (I assume 0x83 is correct, given that I cannot locate any scan set 2 charts that use any other value for F7. Including those published by Microsoft.) + +I see the map in hw/input/ps2.c ps2_raw_keycode[] using the correct values, starting at F1: 5, 6, 4, 12 (0x0C). 3. 11 (0x0B), 2, 10 (0x0A), 1, 9, ... but nowhere in that map do I see 131 (0x83). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1390520 b/results/classifier/gemma3:12b/peripherals/1390520 new file mode 100644 index 000000000..de9d0591b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1390520 @@ -0,0 +1,27 @@ + +virtual machine fails to start with connected audio cd + +when connecting a data cd with a virtual machine (IDE CDROM 1), the virtual machine starts up and the data cd is accessable (for example to install software package or drivers), +but connecting an audio cd the following error appears: + +------------------------------------------------------------------------------------------------------------------------------- +cannot read header '/dev/sr0': Input/output error + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/details.py", line 2530, in _change_config_helper + func(*args) + File "/usr/share/virt-manager/virtManager/domain.py", line 850, in hotplug_storage_media + self.attach_device(devobj) + File "/usr/share/virt-manager/virtManager/domain.py", line 798, in attach_device + self._backend.attachDevice(devxml) + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 493, in attachDevice + if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) +libvirtError: cannot read header '/dev/sr0': Input/output error +---------------------------------------------------------------------------------------------------------------------------- + +Description: Ubuntu 14.04.1 LTS +Release: 14.04 + +qemu: + Installiert: 2.0.0+dfsg-2ubuntu1.6 + Installationskandidat: 2.0.0+dfsg-2ubuntu1.6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1399943 b/results/classifier/gemma3:12b/peripherals/1399943 new file mode 100644 index 000000000..1e8cf2c65 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1399943 @@ -0,0 +1,29 @@ + +qemu-system-sparc loses serial console data on EAGAIN + +When running a guest OS with a serial console under +"qemu-system-sparc -nographic", parts of the serial console output +are sometimes lost. + +This happens when a write() to standard output by qemu returns EAGAIN, +as may be the case when the guest is generating console output faster +than the tty (or pty/pipe/socket, etc.) connected to qemu's standard +output accepts it. The bug affects all releases of qemu since 1.5, +which was the first version to set stdout to O_NONBLOCK mode. Version +1.4.2 and earlier work correctly. + +To reproduce the bug, you will need a guest OS configured with a +serial console, and a host with a slow tty. The attached shell script +"sparc-test.sh" does this by using Aboriginal Linux as the serial +console guest, and a pty controlled by a Python script and the +"pexpect" Python module as the slow tty. A "seq" command is sent +to the guest to generate 100,000 lines of output containing sequential +integers, and the output is checked for gaps. The script limits the +tty output rate by occasionally sleeping for 1/10 of a second. + +This bug was originally reported against qemu-system-i386 as +bug #1335444, and has since been fixed in qemu-system-i386, +but remains in qemu-system-sparc as of today's git sources +(d00e6cddc220de993573dfb5fd160ac72ccd49ab). I am opening +this separate bug for the sparc case because I was asked +to do so by Paolo Bonzini in #1335444. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1404610 b/results/classifier/gemma3:12b/peripherals/1404610 new file mode 100644 index 000000000..ff555bbc3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1404610 @@ -0,0 +1,12 @@ + +[feature request] HP300 m68k system? + +QEMU seems to support nothing (specific) that 4.4BSD was targeted to...would be useful to have a complete emulator for a full HP300 to run the binary dist from McKusick's CD set. + +Devices that'd be needed: +* 68020, 68030, or 68040 (How much of these are already present? Not sure if there was a non-standard MMU/FPU...but there was definitely a slightly-uncommon bus used for some peripherals) +* Networking was lance I am pretty sure...at least the onboard one. +* SCSI (Probably a standard chip as used EVERYWHERE ELSE..not sure off hand) +* Framebuffers optional, serial is sufficient for basic booting of 4.4. + +Tape/disk can also be done via HP-IB...but SCSI would probably be easier unless extra peripherals were required (some serial stuff.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1407454 b/results/classifier/gemma3:12b/peripherals/1407454 new file mode 100644 index 000000000..afd5e5346 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1407454 @@ -0,0 +1,31 @@ + +assertion failed when using "-usb" option + +SUMMARY: +---------- +Description: Latest 'master' makes it impossible to use "-usb" command line on any target +Host platform: Linux x86-64 +Guest platform: probably all (at least x86-64, i386, arm and ppc) + +REPRODUCE: +---------- +How to reproduce: +1. Run the following command: +$ qemu-system-x86_64 -usb + +Expected result: +Starting virtual machine with empty configuration + +Actual result: +Qemu crashes with following message: + +qemu-system-x86_64: /home/mplucinski/Developer/Open_Source/qemu/qemu.git/util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion `opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed. +Aborted + +MORE INFORMATION: +---------- +Same happens when trying to run other target, e.g. +$ qemu-system-i386 -usb +$ qemu-system-arm -machine kmz -usb + +First commit where the issue occurs (bisection result): 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1407808 b/results/classifier/gemma3:12b/peripherals/1407808 new file mode 100644 index 000000000..f855ee5e2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1407808 @@ -0,0 +1,10 @@ + +virtual console gives strange response to ANSI DSR + +With "-serial vc" (which is the default), qemu make strange responses to the ANSI DSR escape sequence (\033[6n) which can confuse guests. + +Terminal emulators supporting the ANSI escape sequences usually support the "Device Status Report" escape sequence, \033[6n, to which as a response the terminal injects as input the response \033[n;mR, containing the current cursor position. An application running in the guest can use this escape sequence to, for example, figure out the size of the terminal it is running under, which can be useful as the guest has no other standard way to figure out a "size" for the serial port. + +Unfortunately, it seems that qemu when run with "-serial vc" (which appears to be the default), when qemu gets the \033[6n escape sequence on the serial port, it just responds with a single \033, and that's it! This can confuse an application, could concievably assume that a terminal either supports this escape sequence and injects the correct response (\033[n;mR), or doesn't support it and injects absolutely nothing as input - but not something in between. + +This caused a problem on one shell implementation on OSv that tried to figure out the terminal's size, and had to work around this unexpected behavior (see https://github.com/cloudius-systems/osv/commit/b79223584be40459861d1c12e1cb67e3e49e2a12). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1407813 b/results/classifier/gemma3:12b/peripherals/1407813 new file mode 100644 index 000000000..bf4dea406 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1407813 @@ -0,0 +1,10 @@ + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1408 b/results/classifier/gemma3:12b/peripherals/1408 new file mode 100644 index 000000000..0d3090350 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1408 @@ -0,0 +1,88 @@ + +Out of bounds in imx_usbphy_read() +Description of problem: +The size of the memory region of imx-usb-phy is 0x1000. + +``` +memory_region_init_io(&s->iomem, OBJECT(s), &imx_usbphy_ops, s, + "imx-usbphy", 0x1000); +``` + +A read to s->usbphy[33] will easily overflow. + +``` +static uint64_t imx_usbphy_read(void *opaque, hwaddr offset, unsigned size) +{ + // ... + default: + value = s->usbphy[index]; + break; + } +``` + +Maybe we should drop this read in default branch. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine sabrelite -monitor none -serial none \ +-display none -nodefaults -qtest stdio +readl 0x20c9870 +EOF +``` +Additional information: +``` ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy -max_len=10000000 -detect_leaks=0 ./crash-2f5e9c8ec69dd69f8db69aaa84dde878482b8690.minimized +==14370==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x561837db1240). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1679742864 +INFO: Loaded 1 modules (583356 inline 8-bit counters): 583356 [0x56183b151000, 0x56183b1df6bc), +INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x56183a86a3b0,0x56183b150f70), +./qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *imx-usbphy* +This process will fuzz the following MemoryRegions: + * imx-usbphy[0] (size 1000) + * imx-usbphy[0] (size 1000) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * imx-usbphy, EVENT_TYPE_MMIO_READ, 0x20c9000 +0x1000, 4,4 + * imx-usbphy, EVENT_TYPE_MMIO_WRITE, 0x20c9000 +0x1000, 4,4 + * imx-usbphy, EVENT_TYPE_MMIO_READ, 0x20ca000 +0x1000, 4,4 + * imx-usbphy, EVENT_TYPE_MMIO_WRITE, 0x20ca000 +0x1000, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 222Mb +Running: ./crash-2f5e9c8ec69dd69f8db69aaa84dde878482b8690.minimized +../hw/usb/imx-usb-phy.c:93:17: runtime error: index 540 out of bounds for type 'uint32_t [33]' + #0 0x5618357ddb2a in imx_usbphy_read /root/videzzo/videzzo_qemu/qemu/out-san/../hw/usb/imx-usb-phy.c:93:17 + #1 0x561836f07a0b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:441:11 + #2 0x561836ec6501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #3 0x561836ec38cc in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1425:16 + #4 0x561836ec3008 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1458:9 + #5 0x561836f415ad in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2892:23 + #6 0x561836f42bb8 in flatview_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2934:12 + #7 0x561836f42678 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2947:18 + #8 0x5618337f4b41 in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2873:18 + #9 0x5618337f4b41 in qemu_readl /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1037:5 + #10 0x5618337f2c06 in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1051:35 + #11 0x561837dac6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #12 0x561837da3a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #13 0x561837da37e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #14 0x56183380a07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #15 0x561837db150b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #16 0x5618336ea806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #17 0x5618336cd434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #18 0x5618336d83de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #19 0x5618336c49c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #20 0x7f74d2914082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #21 0x5618336c4a1d in _start (/root/bugs/metadata/imx_usb_phy-00/qemu-videzzo-arm-target-videzzo-fuzz-imx-usb-phy+0x31cea1d) + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/imx-usb-phy.c:93:17 in +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x0,0x8,0x70,0x98,0xc,0x2,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0, +\x00\x08p\x98\x0c\x02\x00\x00\x00\x00\x04\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1423124 b/results/classifier/gemma3:12b/peripherals/1423124 new file mode 100644 index 000000000..fc787b1f7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1423124 @@ -0,0 +1,19 @@ + +QEMU crash after sending data on host serial port + +Good morning, + +I'm using QEMU for Windows last version. +The host system is Windows 7 64bits. +I'm excuting the following statment : + +qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net tap,ifname=TAP32 -soundhw all -serial COM9 + +Qemu starts the emulated Debian and it runs correctly. + +If I try to send data from Windows using COM9 to QEMU (both "real" or emulated by the COM0COM driver), QEMU crashes. Windows dump available if required. +If I try to send data to /dev/ttyS0 (that should be the Linux side of COM9) from Debian, again, the wirtual machine crashes. + +More details if necessary +Best regards +U.Poddine \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1423668 b/results/classifier/gemma3:12b/peripherals/1423668 new file mode 100644 index 000000000..38d493c09 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1423668 @@ -0,0 +1,12 @@ + +Unable to set scsi drive serial if it contains spaces. + +I am virtualzing a physical server for which I need to set the SCSI/SATA drive serial. It is comprised of 12 " " spaces then 8 letter/digits. If I exclude the spaces, the drive serial is not accurate. If I include the spaces I get the following error. + +error: Failed to start domain test1 +error: internal error: driver serial ' ABCD1234' contains unsafe characters + +virsh edit +Centos 7.0 +3.19.0-1.el7.elrepo.x86_64 +QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-60.el7.centos.7), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1425 b/results/classifier/gemma3:12b/peripherals/1425 new file mode 100644 index 000000000..0040dc327 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1425 @@ -0,0 +1,85 @@ + +Assertion failed in transfer_fifo() +Description of problem: +In transfer_fifo(), fifo32_pop() fails since less than 32 bytes are in the fifo. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio -audio none +writel 0xff070000 0x0f73720a +writel 0xff07003c 0x1f37ee63 +EOF +``` +Additional information: +``` +==31717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55871da359f0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1734665286 +INFO: Loaded 1 modules (618606 inline 8-bit counters): 618606 [0x558720b94000, 0x558720c2b06e), +INFO: Loaded 1 PC tables (618606 PCs): 618606 [0x558720222e60,0x558720b93540), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *xlnx.zynqmp-can* +This process will fuzz the following MemoryRegions: + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 491Mb +Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-97ef02583c679111ba6ad823f573f139fac7c72e +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed. +==31717== ERROR: libFuzzer: deadly signal + #0 0x558718e0e10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x558718d5cd81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x558718d35cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x558718d35d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x558718d35d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f3ad4eba41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f3ad4ccc00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f3ad4ccc00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f3ad4cab858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f3ad4cab728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f3ad4cbcfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55871d6eeac9 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:62:5 + #12 0x55871a33f303 in fifo32_pop /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:137:17 + #13 0x55871a334bb5 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:455:23 + #14 0x55871a32d4c0 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:830:9 + #15 0x558719393dcb in register_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:122:9 + #16 0x558719397de8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:203:5 + #17 0x55871c9e9073 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #18 0x55871c9e89b1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #19 0x55871c9e72d6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #20 0x55871ca7548e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #21 0x55871ca635cb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #22 0x55871ca63088 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #23 0x558718e4e0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1081:5 + #24 0x558718e4c544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1222:28 + #25 0x55871da313af in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #26 0x55871da2872b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #27 0x55871da28600 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #28 0x558718e5510c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12 + #29 0x55871da35c92 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #30 0x558718d36826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #31 0x558718d19454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #32 0x558718d243fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #33 0x558718d109e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #34 0x7f3ad4cad082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #35 0x558718d10a3d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3291a3d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1426092 b/results/classifier/gemma3:12b/peripherals/1426092 new file mode 100644 index 000000000..ce2d9e16a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1426092 @@ -0,0 +1,36 @@ + +virtio-balloon-device locks up Guest + +Setting arbitrary balloon target values locks up the guest in some cases crashes it, if the target memory is < used +~5% free. +Found while testing aggressive memory over-commit, scenarios. +You get messages like: + +[ 155.827448] [<c002060c>] (show_stack) from [<c041c518>] (dump_stack+0x6c/0x88) +[ 155.837076] [<c041c518>] (dump_stack) from [<c0091994>] (warn_alloc_failed+0xe0/0x120) +[ 155.847075] [<c0091994>] (warn_alloc_failed) from [<c0094480>] (__alloc_pages_nodemask+0x600/0x91c) +[ 155.859039] [<c0094480>] (__alloc_pages_nodemask) from [<c00da414>] (balloon_page_enqueue+0x20/0xbc) +[ 155.870556] [<c00da414>] (balloon_page_enqueue) from [<c025d794>] (balloon+0x140/0x2cc) +[ 155.881377] [<c025d794>] (balloon) from [<c0043b38>] (kthread+0xd8/0xf4) + +page dumped bacause: nonzero _count +BUG: BAad page state in process Xorg pfn:396e5 + +Test Environment: +x86_64 +Ubuntu 13.10, Guest Linux Kernel 3.19, qemu 2.2.0 with following patches applied - balloon OOM enhancement +commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5 +Author: Raushaniya Maksudova <email address hidden> + +Boot guest with '-balloon virtio', -qmp .... -hmp access +1. sudo info balloon | socat - tcp4-connect:127.0.0.1:4444 + - or over qmp interface +{"execute":"qom-get", "arguments": { "path": "/machine/peripheral-anon/device[1]","property": "guest-stats" }} +{"return": {"stats": {"stat-swap-out": 0, "stat-free-memory": 513454080, "stat-minor-faults": 1261, "stat-major-faults": 0, "stat-total-memory": 526073856, "stat-swap-in": 0}, "last-update": 11109}} + +2. Take memory down check free memory using (1) +3. Issue "sudo echo balloon XXX | socat - tcp4-connect:127.0.0.1:4444" - XXX is value in threshold mentioned above + and you get Guest lockup + +ARM - samething except '-device virtio-balloon-device' used + +Libvirt - virsh setmem causes same issue. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1430 b/results/classifier/gemma3:12b/peripherals/1430 new file mode 100644 index 000000000..1f63d4db1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1430 @@ -0,0 +1,111 @@ + +Underflow in xlnx_dp_aux_push_rx_fifo() +Description of problem: +Pop two times from s->tx_fifo[2] but there is one element left. Since the fifo +is not empty, the check at [1] will fail. + +``` +static void xilinx_spips_flush_txfifo(XilinxSPIPS *s) +{ + // ... + for (;;) { + // ... + if (fifo8_is_empty(&s->tx_fifo)) { // ---------------> [1] + xilinx_spips_update_ixr(s); + return; + } else if (s->snoop_state == SNOOP_STRIPING || + s->snoop_state == SNOOP_NONE) { + for (i = 0; i < num_effective_busses(s); ++i) { + tx_rx[i] = fifo8_pop(&s->tx_fifo); // ---------> [2] + } + stripe8(tx_rx, num_effective_busses(s), false); + } else if (s->snoop_state >= SNOOP_ADDR) { + // ... +``` +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xff0f00a0 0x74b13699 +readl 0xc1af068c +EOF +``` +Additional information: +``` +==64457==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55f8037f3440). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1864808059 +INFO: Loaded 1 modules (600775 inline 8-bit counters): 600775 [0x55f806e06000, 0x55f806e98ac7), +INFO: Loaded 1 PC tables (600775 PCs): 600775 [0x55f8064dab90,0x55f806e05800), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *spi*, *lqspi* +This process will fuzz the following MemoryRegions: + * spi[0] (size 200) + * spi[0] (size 200) + * lqspi[0] (size 2000000) + * spi[0] (size 200) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * spi, EVENT_TYPE_MMIO_READ, 0xff050000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_WRITE, 0xff050000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_READ, 0xff040000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_WRITE, 0xff040000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_READ, 0xff0f0000 +0x200, 1,4 + * spi, EVENT_TYPE_MMIO_WRITE, 0xff0f0000 +0x200, 1,4 + * lqspi, EVENT_TYPE_MMIO_READ, 0xc0000000 +0x2000000, 4,4 + * lqspi, EVENT_TYPE_MMIO_WRITE, 0xc0000000 +0x2000000, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 509Mb +Running: /root/videzzo/videzzo_qemu/out-san/poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips-crash-a2dce6d03fde8dc9cb50fb0c8708f307ca93d7c2.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed. +==64457== ERROR: libFuzzer: deadly signal + #0 0x55f7fecb90fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55f7fec07d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55f7febe0ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55f7febe0d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55f7febe0d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f67ea63a41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f67ea44c00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f67ea44c00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f67ea42b858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f67ea42b728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f67ea43cfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55f803645699 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:62:5 + #12 0x55f8009d1ded in xilinx_spips_flush_txfifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:623:28 + #13 0x55f8009dc092 in lqspi_load_cache /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:1194:9 + #14 0x55f8009da069 in lqspi_read /root/videzzo/videzzo_qemu/qemu/out-san/../hw/ssi/xilinx_spips.c:1231:5 + #15 0x55f80294a61a in memory_region_read_with_attrs_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:464:9 + #16 0x55f802908961 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #17 0x55f8029060d8 in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1431:16 + #18 0x55f802905468 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1458:9 + #19 0x55f802983a6d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2892:23 + #20 0x55f802985078 in flatview_read /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2934:12 + #21 0x55f802984b38 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2947:18 + #22 0x55f7fecebb51 in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2873:18 + #23 0x55f7fecebb51 in qemu_readl /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1037:5 + #24 0x55f7fece9c16 in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1051:35 + #25 0x55f8037ee8bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #26 0x55f8037e5c3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #27 0x55f8037e59e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #28 0x55f7fed0108c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #29 0x55f8037f370b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #30 0x55f7febe1816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #31 0x55f7febc4444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #32 0x55f7febcf3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #33 0x55f7febbb9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #34 0x7f67ea42d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #35 0x55f7febbba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-qspips+0x3454a2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0xd,0xa0,0x0,0xf,0xff,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x99,0x36,0xb1,0x74,0x0,0x0,0x0,0x0,0x0,0xe,0x8c,0x6,0xaf,0xc1,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0, +\x01\x0d\xa0\x00\x0f\xff\x00\x00\x00\x00\x04\x00\x00\x00\x996\xb1t\x00\x00\x00\x00\x00\x0e\x8c\x06\xaf\xc1\x00\x00\x00\x00\x04\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1433 b/results/classifier/gemma3:12b/peripherals/1433 new file mode 100644 index 000000000..36a464354 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1433 @@ -0,0 +1,158 @@ + +Abort in lan9118_16bit_mode_[read|write]() +Description of problem: +[read|write][w|l] are allowed but [read|write]b are not allowed when mode_16bit is enabled. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine smdkc210 -monitor none -serial none \ +-display none -qtest stdio +readb 0x5000070 +EOF +``` +Additional information: +``` +==1940==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5654b8eede90). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3248453476 +INFO: Loaded 1 modules (601357 inline 8-bit counters): 601357 [0x5654bbdd8000, 0x5654bbe6ad0d), +INFO: Loaded 1 PC tables (601357 PCs): 601357 [0x5654bb4aa340,0x5654bbdd7410), +./qemu-videzzo-arm-target-videzzo-fuzz-lan9118: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes +Matching objects by name , *lan9118-mmio* +This process will fuzz the following MemoryRegions: + * lan9118-mmio[0] (size 100) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * lan9118-mmio, EVENT_TYPE_MMIO_READ, 0x5000000 +0x100, 1,4 + * lan9118-mmio, EVENT_TYPE_MMIO_WRITE, 0x5000000 +0x100, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 221Mb +Running: ./crash-663e5408ee573b1e9d073c796ffbaaae9bd583cb +qemu: hardware error: lan9118_read: Bad size 0x1 + +CPU #0: +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +CPU #1: +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +==1940== ERROR: libFuzzer: deadly signal + #0 0x5654b48090fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x5654b4757d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5654b4730ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x5654b4730d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x5654b4730d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7fb6db17941f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fb6daf8b00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fb6daf8b00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fb6daf6a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x5654b483964a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x5654b6a64d84 in hw_error /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/cpus.c:128:5 + #11 0x5654b5ac50c7 in lan9118_16bit_mode_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/lan9118.c:1319:5 + #12 0x5654b7ee045b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11 + #13 0x5654b7ea0761 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #14 0x5654b7e9db2c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16 + #15 0x5654b7e9d268 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9 + #16 0x5654b7f1946d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23 + #17 0x5654b7f1aa78 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12 + #18 0x5654b7f1a538 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18 + #19 0x5654b483a7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18 + #20 0x5654b483a7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1010:5 + #21 0x5654b483997e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1034:35 + #22 0x5654b8ee984f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #23 0x5654b8ee0bcb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #24 0x5654b8ee0aa0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #25 0x5654b48500fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12 + #26 0x5654b8eee132 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #27 0x5654b4731816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x5654b4714444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x5654b471f3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x5654b470b9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7fb6daf6c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x5654b470ba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-lan9118+0x300da2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x4,0x2,0x29,0x92,0xa,0x0,0x0,0x0,0x0,0x0,0x0,0x8,0x70,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0x9,0x48,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x29,0x1f,0x8e,0x23,0x0,0x0,0x0,0x0, +\x04\x02)\x92\x0a\x00\x00\x00\x00\x00\x00\x08p\x00\x00\x05\x00\x00\x00\x00\x01\x00\x00\x00\x01\x09H\x00\x00\x05\x00\x00\x00\x00\x04\x00\x00\x00)\x1f\x8e#\x00\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1435973 b/results/classifier/gemma3:12b/peripherals/1435973 new file mode 100644 index 000000000..3e0a8a27c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1435973 @@ -0,0 +1,61 @@ + +Qemu crash when a guest linux issues specific scsi command via ioctl(SG_IO) with SCSI disk emulation. + +As of git revision 362ca922eea03240916287a8a6267801ab095d12, when guest linux issues specifit scsi command, qemu crashes. + +To reproduce. + +1. launch qemu with scsi emulatoin +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi +2. issues scsi command via ioctl(SG_IO) on guest linux. like below. + +------------------------- +struct request_sense sens; +struct sg_io_hdr sg; +unsigned char cdb[6]; +unsigned char buf[127]; + +memset( &sens, 0, sizeof(sens) ); +memset(&sg, 0, sizeof(sg)); +memset(cdb, 0, sizeof(cdb)); +memset(buf, 0, sizeof(buf)); + +// qemu crash!!! +cdb[0] = 0xff; + +sg.dxferp = buf; +sg.dxfer_len = sizeof(buf); +sg.dxfer_direction = SG_DXFER_FROM_DEV; +sg.flags = 0; +sg.interface_id = 'S'; +sg.cmdp = cdb; +sg.cmd_len = sizeof( cdb ); +sg.sbp = (unsigned char*)&sens; +sg.mx_sb_len = sizeof( sens ); + +ioctl( fd, SG_IO, &sg ); +------------------------- + +I think cause is below code. + +scsi-bus.c L1239 +int scsi_req_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf) +{ + int rc; + + cmd->lba = -1; + cmd->len = scsi_cdb_length(buf); + ... + memcpy(cmd->buf, buf, cmd->len); +} + +scsi_cdb_length(buf) returns -1 when buf[0] is unexpected value. +Then memcpy(cmd->buf, buf, 4294967295); is executed and crash. + +Environment +Qemu: git revision 362ca922eea03240916287a8a6267801ab095d12 +Guest: linux kernel 3.18.4 + buildroot +Host: Windows 7 64bit + +Thanks, +hiroaki \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1437970 b/results/classifier/gemma3:12b/peripherals/1437970 new file mode 100644 index 000000000..da497c220 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1437970 @@ -0,0 +1,45 @@ + +qemu-system-x86_64 - two mouse pointers & fast scrolling problem + +Hello, + +System Specs + +Host: +-------- +Slackware 14.1 x86_64 +Openbox 3.5.2 +tint2 panel (svn version) +Nvidia GTX660M +nvidia-driver-346.35 +Screen: 17" @1920x1080@60Hz + + +Guest +--------- +Slackware 14.1 x86_64 +XFce 4.10 +Screen 17" @1920x1080 +xf86-video-vmware 13.0.1 + +QEMU 2.2.1 + +I start Slackware in QEMU using 'Zoom To Fit' when it first boots up and I log into X, at this point I notice the mouse shows with 2 pointers and when I move the mouse around, shows as trails, but it's actually a second pointer that appears under the first. + +If I use 'Ctrl Alt F' and go into full screen mode the mouse gets corrected and only appears as one pointer and no pointer under the second one when moving around. So this mouse problem only appears the first time I log into X with 'Zoom To Fit'. + +Also if log in instead as 'Full Screen' I do not see the issue, as well as if I log in 'Full Screen' and change back to 'Zoom To Fit' it does not happen. + +I also noticed that if I scroll with the mouse wheel very fast while, as an example, in any application and wanting to move quickly around, the mouse ends up moving me instead to another virtual desktop, XFce by default uses 4. If I just scroll slowly nothing happens, it's only when moving the mouse wheel quickly that the focus gets taken off the application for some reason and put on the desktop and moves you. + +Command line options: +-------------------------------- +qemu-system-x86_64 -rtc base=localtime Slackware\ 14.1\ x64.img -m 4096 --enable-kvm -smp 2 -vga vmware -usbdevice tablet + +I wanted to use -usbdevice tablet to have seamless mouse movement back and forth from Host to Guest without having to Grab... + +If I remove '-usbdevice tablet' and log into X the frst time as 'Zoom To Fit' I see two mouse pointers, but as soon as I click the desktop and the mouse is grabbed the second one goes away and when I move the mouse there is only one pointer. + +Also without the optiion '-usbdevice tablet' and I move the scroll wheel quickly the mouse stays focused on the application and it doesn't move the desktop. + +Please see the attached screen shots, qemu_1.jpg shows 2 mouse pointers when I first log into X and qemu_2.jpg shows when I'm staying in 'Zoom To Fit' mode and moving the mouse around, with a pointer under the pointer. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1438 b/results/classifier/gemma3:12b/peripherals/1438 new file mode 100644 index 000000000..b4c8a5921 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1438 @@ -0,0 +1,8 @@ + +Allow to use QEMU sockets as a CAN bus backend +Additional information: +Good possible example how it can be done is via UDP multicast in `python-can` library: +- https://python-can.readthedocs.io/en/master/interfaces/udp_multicast.html + +Another option, with less features is using a simple serial/character device like in: +- https://python-can.readthedocs.io/en/master/interfaces/serial.html diff --git a/results/classifier/gemma3:12b/peripherals/1438144 b/results/classifier/gemma3:12b/peripherals/1438144 new file mode 100644 index 000000000..348cfd1ef --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1438144 @@ -0,0 +1,9 @@ + +Page sizes are not interpreted correctly for E500/E500MC + +http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf - see 2.12.5.2 MAS Register 1 (MAS1), p. 2-41 +http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf - see 2.16.6.2 MAS Register 1 (MAS1), p. 2-54 + +According to these documents, variable page size for TLB1 is computed as 4K ** TSIZE. + +However, QEMU always treats it as if it was 1K << TSIZE, even if options like "-cpu e500mc" are supplied to qemu. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/144 b/results/classifier/gemma3:12b/peripherals/144 new file mode 100644 index 000000000..21388e8ec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/144 @@ -0,0 +1,2 @@ + +Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up diff --git a/results/classifier/gemma3:12b/peripherals/1453 b/results/classifier/gemma3:12b/peripherals/1453 new file mode 100644 index 000000000..06648ae63 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1453 @@ -0,0 +1,2 @@ + +Tricore: different definitions of pcxi register field diff --git a/results/classifier/gemma3:12b/peripherals/1453025 b/results/classifier/gemma3:12b/peripherals/1453025 new file mode 100644 index 000000000..426d65b02 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1453025 @@ -0,0 +1,16 @@ + +remote usb3.0 redir failed, when guest os has more than one vcpus + +I was testing usb3.0 redirection, it worked fine with one vcpu. +But when I set vcpu to a number greater than one, the redirection failed. + +Host and guest are Fedora 20 and Windows 7. +Client is remote-viwer. + +version: qemu 2.3.0 libvirt 1.2.15 spice 0.12.5 + +libvirt xml: + +<vcpu placement='static'>2</vcpu> +<controller type='usb' index='0' model='nec-xhci'> +</controller> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1476 b/results/classifier/gemma3:12b/peripherals/1476 new file mode 100644 index 000000000..91053aa62 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1476 @@ -0,0 +1,2 @@ + +Support for additional CMOS memory banks diff --git a/results/classifier/gemma3:12b/peripherals/1476183 b/results/classifier/gemma3:12b/peripherals/1476183 new file mode 100644 index 000000000..ee693c080 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1476183 @@ -0,0 +1,18 @@ + +can not create 4 serial port on window (guest os) + +qemu ver: 2.1.2-Latest + +guest os: window 7 64bit with 2 cpu + +problem: when qemu start with 4 serial port, on linux(rhel 7) guest os, /dev/ttyS0-4 is work fine. but on window 7 guest os, only show com1,com2 in device manager, how to get com3 & com4 ? + +qemu cmd: + -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0 + -device isa-serial,chardev=charserial0,id=serial0 + -chardev spiceport,id=charserial1,name=org.qemu.console.serial.1 + -device isa-serial,chardev=charserial1,id=serial1 + -chardev spiceport,id=charserial2,name=org.qemu.console.serial.2 + -device isa-serial,chardev=charserial2,id=serial2 + -chardev spiceport,id=charserial3,name=org.qemu.console.serial.3 + -device isa-serial,chardev=charserial3,id=serial3 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1477683 b/results/classifier/gemma3:12b/peripherals/1477683 new file mode 100644 index 000000000..471f9195b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1477683 @@ -0,0 +1,6 @@ + +FPU in qemu-system-i386 works incorrectly + +FPU bug in qemu-system-i386 makes software which use floating point numbers work incorrectly. For instance, the one included in attachment prints out 0 instead of 2147483648. The same code works ok in qemu-system-x86_64. + +I have this issue in QEMU 2.3.0 on two different x86 guests (Parabola GNU/Linux-libre and libreCMC). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1478376 b/results/classifier/gemma3:12b/peripherals/1478376 new file mode 100644 index 000000000..f4ac41cc3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1478376 @@ -0,0 +1,12 @@ + +PL050 KMIDATA register does not reset + +static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){ + ... + case 2: /* KMIDATA */ + if (s->pending) + s->last = ps2_read_data(s->dev); + return s->last; +} + +When the receive queue is empty (s->pending is false), is the KMIDATA register supposed to be reset to 0x00? In the current implementation, the KMIDATA does not reverse its value after interrupt is lowered. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1479632 b/results/classifier/gemma3:12b/peripherals/1479632 new file mode 100644 index 000000000..73bda8c02 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1479632 @@ -0,0 +1,19 @@ + +dos crashing no sound + +I use this command when I use sound in a program there is no sound and sometimes the program crashes or hangs with no mouse +working. I can though reset with the system with the control menu, but this is further hard to use, because there is no option to scroll through all the commands, I did not visited a wiki page yet. + +This is my command. + +qemu-system-i386 -soundhw all -m 1g -boot menu=on -hda dos622_1.img -boot d + +I have quite freed up some memory, but that didn't help. + +I used qemu because of a bug in dosbox, but that appeared to be the unclutter program and I have now uninstalled it. + +Not to mention that I did not knew that qemu is in such a beta phase. + +Regards, + +BCJ2014 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1480562 b/results/classifier/gemma3:12b/peripherals/1480562 new file mode 100644 index 000000000..4a3dfef2c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1480562 @@ -0,0 +1,16 @@ + +register values in sp804 timer + +In the arm_timer.c, when first reading the load register, I got 0. + +... +case 0: /* TimerLoad */ +... + +According to the specification at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0271d/index.html, +"The minimum valid value for TimerXLoad is 1". Is the initial value supposed to be 0xffffffff? + + +When the 5th and 7th bit in Control Register are set, RIS and MIS remain 0. But should they be enabled (i.e., 0x1 and 0x1) as both interrupt and timer module are set. + +Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1481375 b/results/classifier/gemma3:12b/peripherals/1481375 new file mode 100644 index 000000000..507917add --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1481375 @@ -0,0 +1,26 @@ + +Windows 7 Pro - Sticky Keys + +Qemu KVM v: 1.1.0 +CentOS 7: 3.10.0-229.7.2.el7.x86_64 +Lenovo Thinkpad Yoga + +USB devices: +Bus 001 Device 002: ID 8087:8000 Intel Corp. +Bus 002 Device 068: ID 2109:3431 +Bus 002 Device 012: ID 8087:07dc Intel Corp. +Bus 002 Device 004: ID 04f3:0254 Elan Microelectronics Corp. +Bus 002 Device 005: ID 04f2:b39f Chicony Electronics Co., Ltd +Bus 003 Device 047: ID 2109:0811 +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +Bus 001 Device 003: ID 0483:91d1 STMicroelectronics +Bus 001 Device 004: ID 056a:00ec Wacom Co., Ltd +Bus 002 Device 069: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse +Bus 002 Device 070: ID 04f2:0112 Chicony Electronics Co., Ltd KU-8933 Keyboard with PS/2 Mouse port +Bus 002 Device 071: ID 2109:3431 +Bus 003 Device 048: ID 2109:0811 +Bus 003 Device 049: ID 17e9:4302 DisplayLink + +CentOS (host OS) does not register stuck keys, primarily CTRL, ALT, Windows Key, and escape. Windows 7 Pro VM keeps getting sticky keys registered when I boot into the OS or randomly bring back up the console. The keys getting stuck are CTRL, L_SHIFT, ALT, or Windows key, maybe escape. I have to frantically repress the primary shortcut keys on both the USB keyboard and the laptop keyboard. The USB keyboard is mechanical and clean. The laptop is new. Remember, the host OS does not register stuck keys. If anyone has had this problem, or knows a trick to prevent sticky keys, I'm all ears. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1490 b/results/classifier/gemma3:12b/peripherals/1490 new file mode 100644 index 000000000..a5f4493e2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1490 @@ -0,0 +1,62 @@ + +Keystrokes for F13-24 are not forwarded by an evdev input device +Description of problem: +Currently, keystrokes for F13-F24 are not forwarded by an evdev input device. +Steps to reproduce: +``` +/usr/bin/qemu-system-x86_64 \ +-name guest=win10,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-11-win10/master-key.aes"}' \ +-machine pc-q35-7.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \ +-m 4096 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=4,threads=1 \ +-uuid ca2e9d01-6e02-4aa7-9feb-7846499f7d8a \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.1","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/tmp/win10.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":2}' \ +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' \ +-audiodev '{"id":"audio1","driver":"spice"}' \ +-spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ +-device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.2","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +``` + +This is probably not a minimal example, but I didn't know how to generate one. I think the only relevant lines are these: +``` +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' +``` diff --git a/results/classifier/gemma3:12b/peripherals/1491 b/results/classifier/gemma3:12b/peripherals/1491 new file mode 100644 index 000000000..aebdaac57 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1491 @@ -0,0 +1,2 @@ + +imx_epit will stop unexpectedly when couter rollover diff --git a/results/classifier/gemma3:12b/peripherals/1492649 b/results/classifier/gemma3:12b/peripherals/1492649 new file mode 100644 index 000000000..7dd45a4e4 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1492649 @@ -0,0 +1,12 @@ + +QEMU soundhw HDA huge microphone lag + +I use a Windows 7 x86_64 guest with VGA passthrough and -soundhw hda. The audio plays fine, but the microphone input is delayed by more than 20 seconds. + +-soundhw ac97 does not have this delay but it has choppy sound playback and input. + +System: +Arch linux +Kernel: 4.1.6-1-ARCH +Audio hardware: 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller +Audio system: Pulseaudio 6.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1493 b/results/classifier/gemma3:12b/peripherals/1493 new file mode 100644 index 000000000..9c7019978 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1493 @@ -0,0 +1,86 @@ + +Devision by zero in uart_parameters_setup() +Description of problem: +s->r[R_BRGR] could be zero but there is no check[1]. + +``` +static void uart_parameters_setup(CadenceUARTState *s) +{ + QEMUSerialSetParams ssp; + unsigned int baud_rate, packet_size, input_clk; + input_clk = clock_get_hz(s->refclk); + + baud_rate = (s->r[R_MR] & UART_MR_CLKS) ? input_clk / 8 : input_clk; + baud_rate /= (s->r[R_BRGR] * (s->r[R_BDIV] + 1)); // ----> [1] +``` +Steps to reproduce: +Build with ASan. + +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xff000018 0x12330000 +writew 0xff000004 0xbcc4 +EOF +``` +Additional information: +``` +==23==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55555d6bab70). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 4102190864 +INFO: Loaded 1 modules (603606 inline 8-bit counters): 603606 [0x555560d6e000, 0x555560e015d6), +INFO: Loaded 1 PC tables (603606 PCs): 603606 [0x5555604379b0,0x555560d6d710), +./qemu-videzzo-aarch64-target-videzzo-fuzz-cadence-uart: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *uart* +This process will fuzz the following MemoryRegions: + * uart[0] (size 1000) + * uart[0] (size 1000) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * uart, EVENT_TYPE_MMIO_READ, 0xff000000 +0x1000, 1,4 + * uart, EVENT_TYPE_MMIO_WRITE, 0xff000000 +0x1000, 1,4 + * uart, EVENT_TYPE_MMIO_READ, 0xff010000 +0x1000, 1,4 + * uart, EVENT_TYPE_MMIO_WRITE, 0xff010000 +0x1000, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 512Mb +Running: ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-cadence-uart-crash-cef41ca061384b94899472d8e2e6b5a86b62d259.minimized +../hw/char/cadence_uart.c:181:15: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/char/cadence_uart.c:181:15 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==23==ERROR: AddressSanitizer: FPE on unknown address 0x555558fee913 (pc 0x555558fee913 bp 0x7fffffffb5f0 sp 0x7fffffffb220 T0) + #0 0x555558fee913 in uart_parameters_setup /root/videzzo/videzzo_qemu/qemu/out-san/../hw/char/cadence_uart.c:181:15 + #1 0x555558fe8165 in uart_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/char/cadence_uart.c:471:9 + #2 0x55555c7bee3e in memory_region_write_with_attrs_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:514:12 + #3 0x55555c7be051 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #4 0x55555c7bcd1e in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1522:13 + #5 0x55555c84ce1e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2826:23 + #6 0x55555c83abcb in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2868:12 + #7 0x55555c83a688 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2964:18 + #8 0x555558b3e91e in qemu_writew /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1101:5 + #9 0x555558b3d173 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1253:28 + #10 0x55555d6b5fef in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #11 0x55555d6ad36d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #12 0x55555d6ad114 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #13 0x555558b4646c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1530:12 + #14 0x55555d6bae3b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #15 0x555558a26bf6 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #16 0x555558a09824 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #17 0x555558a147ce in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #18 0x555558a00db6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #19 0x7ffff607a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #20 0x555558a00e0d in _start (/root/bugs/metadata/cadence_uart-00/qemu-videzzo-aarch64-target-videzzo-fuzz-cadence-uart+0x34ace0d) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: FPE /root/videzzo/videzzo_qemu/qemu/out-san/../hw/char/cadence_uart.c:181:15 in uart_parameters_setup +==23==ABORTING +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0x9,0x18,0x0,0x0,0xff,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x0,0x0,0x33,0x12,0x0,0x0,0x0,0x0,0x1,0x9,0x4,0x0,0x0,0xff,0x0,0x0,0x0,0x0,0x2,0x0,0x0,0x0,0xc4,0xbc,0x4e,0x4c,0x0,0x0,0x0,0x0, +\x01\x09\x18\x00\x00\xff\x00\x00\x00\x00\x04\x00\x00\x00\x00\x003\x12\x00\x00\x00\x00\x01\x09\x04\x00\x00\xff\x00\x00\x00\x00\x02\x00\x00\x00\xc4\xbcNL\x00\x00\x00\x00 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1496384 b/results/classifier/gemma3:12b/peripherals/1496384 new file mode 100644 index 000000000..b41604931 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1496384 @@ -0,0 +1,15 @@ + +Error 0x5D in Qemu for Windows + +The reason to use qemu for Windows is that the mouse in emulated Windows works well while it is unusable in qemu at Ubuntu. +Alternative solution/bug is mouse usability in qemu for Linux. +Well-known issue of error 0x5D when booting Win 7 x64 on qemu without kvm, marked as resolved at Linux. + +Used qemu for Windows downloaded from http://qemu.weilnetz.de/ +Tested on qemu 2.3.94 64-bit and qemu 2.4.0 32-bit. + +Options : +qemu-system-x86_64.exe -m 1536 -cpu qemu64,+nx,+pae,+mce,+cx8,+apic,+sep,+mtrr,+pge,+mca,+cmov,+pat,+pse36,+clflush,+acpi,+mmx,+fxsr,+sse,+sse2,+ss,+fxsr,+sse,+sse2,+ss,+de,+mtrr,+mca,+clflush + win_7_work.qcow2 + +On qemu at Ubuntu with kvm Win7 x64 works ,but mouse is unusable as mentioned above. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1498 b/results/classifier/gemma3:12b/peripherals/1498 new file mode 100644 index 000000000..6755270f8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1498 @@ -0,0 +1,6 @@ + +LDC, STC unimplemented in qemu-system-arm +Description of problem: +I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected. + +The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU. diff --git a/results/classifier/gemma3:12b/peripherals/1504 b/results/classifier/gemma3:12b/peripherals/1504 new file mode 100644 index 000000000..62f69d282 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1504 @@ -0,0 +1,2 @@ + +Implement Synopsys DesignWare PCI-I2C adapter model diff --git a/results/classifier/gemma3:12b/peripherals/1505759 b/results/classifier/gemma3:12b/peripherals/1505759 new file mode 100644 index 000000000..6d0fb0d38 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1505759 @@ -0,0 +1,55 @@ + +Usb passthrough of devices plugged to AMD FCH USB OHCI Controller failing on q35. + +I'm trying to setup a q35 vm with windows 7 guest for vga passthrough. The machine works well for this purpose, but the usb devices passed to the vm does not. I receive the following errors on screen: + +qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] +libusb: error [_open_sysfs_attr} open +/sys/bus/usb/devices/3-5/bConfigurationValue failed ret=-1 errno=2 +qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] +libusb: error [_open_sysfs_attr} open +/sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2 +Disabling IRQ #18 +Disabling IRQ #17 + +And from the system log I can see the following: + +Oct 13 20:13:25 koalita kernel: vfio-pci 0000:01:00.1: enabling device (0400 -> 0402) +Oct 13 20:13:29 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:30 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:30 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:31 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:31 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:31 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:31 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:32 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:32 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:32 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:33 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:33 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:34 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:34 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes + +I tried to any combination of usb devices, and even disabling the ICH9 usb devices to make the setup looks close to the 440fx machine that is working for me. + +Version of qemu is 2.2.1(all newer versions fails on usb passthrough, even in 440fx machines), and kernel is 4.1.8. + +The script to launch it is the following: + +qemu-system-x86_64 -enable-kvm -M q35 -vga none -cpu host -smp 3,cores=3,threads=1 -m 6144 \ + -L /usr/x86_64-pc-linux-gnu/usr/share/qemu \ + -nodefaults -nodefconfig \ + -device ioh3420,multifunction=on,id=pcie \ + -device vfio-pci,host=01:00.0,addr=1c.0,x-vga=on,multifunction=on,bus=pcie \ + -device vfio-pci,host=01:00.1,addr=1c.1,bus=pcie \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -device usb-ehci,id=ehci -device nec-usb-xhci,id=xhci \ + -usb -usbdevice host:03f0:134a -usbdevice host:03f0:0024 -usbdevice host:0079:0006 \ + -drive file=q35_win7.img,format=raw,cache=none,aio=native,if=virtio + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1509336 b/results/classifier/gemma3:12b/peripherals/1509336 new file mode 100644 index 000000000..cd1ac79cc --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1509336 @@ -0,0 +1,54 @@ + +USB passthru not work with Mac OS X El Capitan + +QEMU emulator version 2.4.50 with kernel kvm module from linux kernel 3.16.0 or 4.2.3 + +Since upgrading from Yosemite to El Capitan - USB passthru does not work. Note USB passthru worked perfectly with Maverick and Yosemite. I attempt to use different USB hosts. I found a patch for widows xp that had similar problem the patch was applied in 2012. Note NO problems with USB passthru with windows or linux clients. If it matters the devices that I am trying to passthru USB are smartcard reader and webcam. The devices are present in El Capitan but do not function. + +These are the massages from loading the VM (El Capitan). The first two lines are from the clover bootloader. The ehci warnings are generated when loading Mac Os X El Capitan. + +QEMU 2.4.50 monitor - type 'help' for more information +### These messages below started when using the clover bootloader and occur when loading El Capitan, Maverick or Yosemite. +### The bootloader is Clover version 3292 +(qemu) ehci: PERIODIC list base register set while periodic schedule + is enabled and HC is enabled +ehci: ASYNC list address register set while async schedule + is enabled and HC is enabled + +#### Below are errors when the guest host (El Capitan) is loading from qemu monitor. The messages below only occur when loading El Capitan. +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC + +This is the errors from the guest os - Mac Os X - El Capitan +000000.580358 AppleUSBLegacyRoot@: AppleUSBLegacyRoot::init: enabling legacy matching +000001.803455 AppleUSBEHCIPCI@fd000000: AppleUSBEHCI::WaitForAsyncSchedule: USBC +MD (0x00080020) and USBSTS (0x00001000) did not synchronize + +the following qemu command has worked flawlessly with Yosemite and Maverick. +qemu-system-x86_64 -enable-kvm -m 4096 -cpu core2duo -machine q35 \ +-bios /usr/local/share/qemu/bios.bin \ +-name "El Capitan" \ +-mem-path /hugetlbfs \ +-rtc base=utc,clock=vm,driftfix=slew \ +-balloon none \ +-parallel none \ +-smp 4,sockets=1,cores=2,threads=2 \ +-boot menu=on \ +-usb -device usb-kbd -device usb-mouse \ +-device usb-host,vendorid=0x0455,productid=0x0777 \ +-vga std \ +-monitor stdio \ +-device isa-applesmc,osk="youknowwhatitis" \ +-smbios type=2 \ +-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \ +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-device e1000-82545em,netdev=hub0port0,id=mac_vnet0,mac=62:64:44:34:64:54 \ +-netdev bridge,id=hub0port0,br=br0,helper=/usr/local/libexec/qemu-bridge-helper \ +-device ide-drive,bus=ide.0,drive=elcapitan \ +-drive id=elcapitan,format=qcow2,if=none,file=./iElCapitan.qcow2 + +If anything else I can do to debug the problem please let me know. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1519 b/results/classifier/gemma3:12b/peripherals/1519 new file mode 100644 index 000000000..f5a8e2f93 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1519 @@ -0,0 +1,13 @@ + +audio recording not working on qemu +Description of problem: +QEMU fails to record audio from the guest even when the device options hda-duplex and hda-micro options are used. Tried using the other available audio backends (alsa and sdl) but recording on the guest still fails +Steps to reproduce: +1. run the qemu command line above with any of the available audio backends +2. record audio on the guest +3. arecord -vv -d 5 recordng.wav +4. there's an attempt to record but it hangs +5. play recorded audio, there's no output +6. aplay recordng.wav +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1520730 b/results/classifier/gemma3:12b/peripherals/1520730 new file mode 100644 index 000000000..6bde01653 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1520730 @@ -0,0 +1,12 @@ + +32-bit editors vim/rhide broken keyboard handling in freedos 1.1 and ms-dos 6.22 + +This bug is present as of the latest commit: 714487515dbe0c65d5904251e796cd3a5b3579fb + +I also saw it in 2.4.1, but that was a distro package. + +You can see the bug simply using the following line: qemu-system-i386 -hda freedos.disk + +Simply type vim (or rhide) and start entering in some text. You'll notice repeating characters, and also eventually the key mode will change as if you're holding down the shift button. Not capslock. "a" will become "A", but "\" will also become "|". + +I don't think this is a bug in freedos because I get the same behavior with dos 6.22. Not dosbox, though. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1521 b/results/classifier/gemma3:12b/peripherals/1521 new file mode 100644 index 000000000..bb83f38e5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1521 @@ -0,0 +1,2 @@ + +USB HID not using the keycodemapdb and thus lacking new entries diff --git a/results/classifier/gemma3:12b/peripherals/1525 b/results/classifier/gemma3:12b/peripherals/1525 new file mode 100644 index 000000000..dfaad84c0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1525 @@ -0,0 +1,79 @@ + +Wrong initial value of stack pointer on AVR devices +Description of problem: +The initial value of stack pointer of AVR MCUs should be RAMEND (address of the end of their RAM), but QEMU initialize them to 0. + +`qemu-system-avr -machine help` lists 4 flavors of MCUs which are ATmega168, ATmega2560, ATmega1280, ATmega328P. According to their datasheets, the stack pointer should be initialized as follows on reset. + +- [ATmega168](https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=12): RAMEND (which is 0x04FF) +- [ATmega2560 and ATmega1280](https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf#page=15): RAMEND (which is 0x21FF) +- [ATmega328P](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#page=22): RAMEND (which is 0x08FF) +Steps to reproduce: +1. Assemble the assembly code below: `avrasm2 -fI test.asm` + + ```asm + ;; test.asm + .INCLUDE "m328Pdef.inc" + + .EQU F_CPU = 16000000 + .EQU BAUD_RATE = 9600 + .EQU PRESCALE = (F_CPU / (16 * BAUD_RATE)) - 1 + + .CSEG + start: + ;; initialize USART (serial port) + LDI R16, LOW(PRESCALE) + LDI R17, HIGH(PRESCALE) + STS UBRR0L, R16 + STS UBRR0H, R17 + LDI R16, (1 << RXEN0) | (1 << TXEN0) + STS UCSR0B, R16 + + ;; Get stack pointer low byte and print it in ASCII + IN R16, SPL + LDI R17, 0x30 + ADD R16, R17 + print1: + LDS r17, UCSR0A + SBRS r17, UDRE0 + RJMP print1 + STS UDR0, r16 + + ;; Get stack pointer high byte and print it in ASCII + IN R16, SPH + LDI R17, 0x30 + ADD R16, R17 + print2: + LDS r17, UCSR0A + SBRS r17, UDRE0 + RJMP print2 + STS UDR0, r16 + + end: + RJMP end + ``` + +2. Convert it to bin file: `avr-objcopy --input-target=ihex --output-target=binary test.hex test.bin` + +3. Run it with QEMU: `qemu-system-avr -machine uno -bios test.bin -serial stdio` + +This should print 00 which means that the stack pointer is initialized to 0. +Additional information: +I examined the source code and I think that editing the function `avr_cpu_reset_hold` in `/target/avr/cpu.c` might fix this issue. This is my first time seeing QEMU source code, so I might be wrong, though. + +```c +// in /target/avr/cpu.c line 70 +static void avr_cpu_reset_hold(Object *obj) +{ + // ... + + env->rampD = 0; + env->rampX = 0; + env->rampY = 0; + env->rampZ = 0; + env->eind = 0; + env->sp = 0; // <-- change this value in accordance with board type? + + //... +} +``` diff --git a/results/classifier/gemma3:12b/peripherals/1539 b/results/classifier/gemma3:12b/peripherals/1539 new file mode 100644 index 000000000..60f38c1e7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1539 @@ -0,0 +1,4 @@ + +Support for SPC58NH92C5 +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1544524 b/results/classifier/gemma3:12b/peripherals/1544524 new file mode 100644 index 000000000..5166298a6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1544524 @@ -0,0 +1,23 @@ + +"info chardev" not showing the real port in use + +With Qemu 2.1.2 +============== +pharidos@uks2:~/work/tplaf/☸ qemu-system-x86_64 -hda /space/pharidos/Disks/Blank_disk.qcow2 -serial telnet::0,server,nowait -nographic +QEMU 2.1.2 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=telnet:0.0.0.0:44189,server <====<<< serial console is using port 44189 +compat_monitor0: filename=stdio +(qemu) + + +With Qemu 2.5.0 +============== +pharidos@kvm:~/$ qemu-system-x86_64 -hda /space/pharidos/Disks/Blank_disk.qcow2 -serial telnet::0,server,nowait -nographic +QEMU 2.5.0 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=disconnected:telnet::0,server <====<<< serial console port not shown +compat_monitor0: filename=stdio +(qemu) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1549298 b/results/classifier/gemma3:12b/peripherals/1549298 new file mode 100644 index 000000000..53b45fcc1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1549298 @@ -0,0 +1,14 @@ + +Add missing MSRs for powertop + +I reported this same bug on the powertop bugtracker [1] because I think both projects need to change something here. + +When running powertop it crashes and prints: + + unknown op '{' + read_msr cpu0 0xe8 : Input/output error + +It seems that powertop is trying to access model specific registers and because qemu doesn't emulate them it crashes. +Clearly powertop shouldn't crash in such case but I think it would also be better if qemu could add support for these registers. + +1: https://app.devzing.com/powertopbugs/bugzilla/show_bug.cgi?id=4 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1550 b/results/classifier/gemma3:12b/peripherals/1550 new file mode 100644 index 000000000..052a2b13d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1550 @@ -0,0 +1,17 @@ + +Crazy mouse movement when passing `-M pc,vmport=off -accel kvm -vga virtio` at the same time +Description of problem: +The mouse cursor is unusable in an x86 guest (disappears, jumps around like crazy) in a graphical environment when `-M pc,vmport=off -accel kvm -vga virtio` is given at the same time. +Steps to reproduce: +1. Download https://download.manjaro.org/xfce/22.0.5/manjaro-xfce-22.0.5-230316-linux61.iso +2. Start above command +3. Wait until the graphical desktop appears +4. Click inside the window and move the mouse + +-> Mouse cursor disappears or jumps around like crazy +Additional information: +If vmport=off is **not** passed, at some point during startup (before graphical login manager appears) the guest switches to use vmmouse from PS/2 mouse. There it also requests usage of absolute input coordinates (VMMOUSE_REQUEST_ABSOLUTE). This code path works normal. Therefore the culprit might be in the guest. + +Another way to reproduce the issue is to use -accel whpx under Windows host (no need to pass vmport=off there). It can be observed that the same guest doesn't attempt to switch to vmmouse there, just like passing vmport=off under Linux. + +The problem does not exist on Linux host when -accel tcg is used in which case the guest doesn't attempt to switch to vmmouse. diff --git a/results/classifier/gemma3:12b/peripherals/1556 b/results/classifier/gemma3:12b/peripherals/1556 new file mode 100644 index 000000000..0e48bfcaf --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1556 @@ -0,0 +1,36 @@ + +RISCV HGATP CSR writes incorrect +Description of problem: +Issue with CSR writes/reads of SATP and HGATP. +Starting with SATP, in file `qemu/target/riscv/csr.c` the function write_satp has the following code snippet: + +```C + if (riscv_cpu_mxl(env) == MXL_RV32) { + vm = validate_vm(env, get_field(val, SATP32_MODE)); + mask = (val ^ env->satp) & (SATP32_MODE | SATP32_ASID | SATP32_PPN); + } else { + vm = validate_vm(env, get_field(val, SATP64_MODE)); + mask = (val ^ env->satp) & (SATP64_MODE | SATP64_ASID | SATP64_PPN); + } + + if (vm && mask) { + if (env->priv == PRV_S && get_field(env->mstatus, MSTATUS_TVM)) { + return RISCV_EXCP_ILLEGAL_INST; +``` +The potential problem I see in the code is that a CSR write which is either illegal or the same as what was previously in the CSR will not yield an illegal instruction. This potential issue could be simple to fix by simply moving the TVM check outside the vm && mask if-statement. +EDIT: I haven't been able to replicate this. Maybe there is code somewhere else which guards against this situation, I'll leave this comment here anyway just to get an extra pair of eyes on this code. + +For writes to hgatp (in the same source file) the value provided to the function is simply written directly to hgatp. +``` +static RISCVException write_hgatp(CPURISCVState *env, int csrno, + target_ulong val) +{ + env->hgatp = val; + return RISCV_EXCP_NONE; +} +``` +This can not be correct, the specification for example states `"A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of hgatp are WARL in the normal way, when so indicated."` Furthermore, there is also a restriction on the ppn field saying that ppn[1:0] must be 0. Finally when reading hgatp the tvm flag is not taken into consideration at all. +Additional information: +The provided binary should be able to replicate the issue. The error regarding num_unexp_trap can be disregarded in this case, normally I break a test directly on an assertion failure but I didn't this time which is why the counter is increasing. + +[main](/uploads/31ef3bc424d63097177cba3579d9b411/main) diff --git a/results/classifier/gemma3:12b/peripherals/1565395 b/results/classifier/gemma3:12b/peripherals/1565395 new file mode 100644 index 000000000..6a04fa478 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1565395 @@ -0,0 +1,24 @@ + +qemu-2.4.1 fails when compiled against pulseaudio + +If I compile qemu-2.4.1 like this: + +CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe +-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local +--localstatedir=/var --libexecdir=/usr/local/lib/qemu +--interp-prefix=/usr/local/share/qemu --disable-smartcard-nss +--disable-curses --disable-brlapi --audio-drv-list="oss alsa sdl" +--target-list="i386-softmmu i386-linux-user x86_64-softmmu +x86_64-linux-user" --smbd=/usr/local/sbin/smbd + +find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \; + +make + +..it works fine. + +If I add pulseaudio dev files and use --audio-drv-list="oss alsa sdl pa", +then "qemu-system-x86_64 -blah-blah" opens a window, displays the bios +message and stops. Strace shows qemu is not hung, but loops continually. + +The same happens with qemu-2.2.1 and qemu-2.5.0. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1568621 b/results/classifier/gemma3:12b/peripherals/1568621 new file mode 100644 index 000000000..7b96ff35a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1568621 @@ -0,0 +1,19 @@ + +input-linux misdetects Logitech keyboard as a mouse + +The new input-linux.c code misdetects my Logitech K350 keyboard as a mouse. The bug is in the input_linux_complete function. The evdev for this keyboard returns an "evtmap" with the EV_REL bit set. Full evtmap is 0x0012001F. Using a different keyboard everything works as intended, so my configuration and setup are correct otherwise. + + +Suggestion: + +I suggest adding an object property called something like "type" where the user can specify what the device type is manually. This K350 keyboard shows that "evtmap" cannot be used to reliably detect the device type. Since specifying the device type manually is not an undue burden, perhaps it should be a required option and there should be no autodetection? + + +System: + +Arch linux, using qemu-git AUR package installed 20160409. + + +Command line: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/sbin/qemu-system-x86_64 -name win10,debug-threads=on -S -machine pc-i440fx-2.4,accel=kvm,usb=off,vmport=off -cpu host,kvm=off -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 -m 8196 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 58623778-9d9d-4d30-8ec0-b37e12a30fdc -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-17-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/var/lib/libvirt/images/ISOs/Win10_1511_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/ISOs/virtio-win-0.1.112.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sda,format=raw,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:70:8a:db,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=d4:be:d9:56:2e:35,bus=pci.0,addr=0x9 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device vfio-pci,host=04:00.0,id=hostdev0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object input-linux,id=kbd1,evdev=/dev/input/event19,grab_all=on -object input-linux,id=kbb2,evdev=/dev/input/event2 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1574246 b/results/classifier/gemma3:12b/peripherals/1574246 new file mode 100644 index 000000000..6bfa4843b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1574246 @@ -0,0 +1,22 @@ + +Drunken keyboard in go32v2 programs + +QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a while, though. + +Steps to reproduce: + +# Create a VM image, install DOS in it (doesn't matter which) and launch it. +# Launch a "bare DOS" DPMI host (not an operating system) in it; I tested with CWSDPMI and HDPMI32. +# Run a go32v2 program which reads keyboard input (say, the Lua interpreter: <http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/devel/lua.zip>; the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem unaffected). +# Quickly type in something random (e.g. alternate between hitting "p" and "q"), then optionally move the cursor left and right. +# Observe how some keystrokes are missed, and some are caught twice. + +The issue does NOT arise: +* on bare metal DOS, +* in VirtualBox, +* in Bochs with stock Plex86 BIOS, +* in Bochs with SeaBIOS, +* in DOSEMU, +* in DOSBox, +* in QEMU when the DPMI host is Windows 3.11/9x +so at this point I'm reasonably sure that it's the fault of either QEMU or SeaBIOS, and probably the former. The issue arises regardless of whether KVM is enabled. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1575 b/results/classifier/gemma3:12b/peripherals/1575 new file mode 100644 index 000000000..3f8c0b8c2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1575 @@ -0,0 +1,2 @@ + +how to implement a heterogeneous machine(several sysbus/mem map)? diff --git a/results/classifier/gemma3:12b/peripherals/1579645 b/results/classifier/gemma3:12b/peripherals/1579645 new file mode 100644 index 000000000..225cee382 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1579645 @@ -0,0 +1,13 @@ + + [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97" + +Environment: + +when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below: +"audio: Could no init “oss” audio driver.", +then login the guest and try run audio, no sound output. +Reproduce: +1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img] + xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure +2. it will show "audio: Could no init “oss” audio driver". +3. login in guest, it can detect audio device, but actually it is not working. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1580586 b/results/classifier/gemma3:12b/peripherals/1580586 new file mode 100644 index 000000000..9ee90a15f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1580586 @@ -0,0 +1,10 @@ + +Qemu WinXP SP3 second loadvm freezes Guest OS + +Using Qemu-system-i386 to run WinXP SP3 with the following command line: + +qemu-system-i386 -hda qcow2/windowsxp_32bits_dd.qcow2 -m 1024 -net user,smb=/shared -vga std -net nic,model=rtl8139 -rtc base=localtime,clock=vm -s -snapshot + +savevm works fine, and the first loadvm to the snapshot works properly, but the next ones will all freeze the guest OS. + +First I thought it was due to the clock but adding the rtc options did not fix it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1583420 b/results/classifier/gemma3:12b/peripherals/1583420 new file mode 100644 index 000000000..fef6d9358 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1583420 @@ -0,0 +1,6 @@ + +Please support "-soundhw none" + +qemu currently provides a default set of sound hardware. The -soundhw option can change that default set, such as by using "-soundhw pcspkr" to disable most of it, but no "-soundhw none" option exists to disable all of it. As far as I can tell, disabling the default sound hardware requires specifying -nodefaults and then manually specifying all the desired hardware, leaving out sound hardware. + +Please consider adding support for "-soundhw none", to disable all the default sound hardware. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1583421 b/results/classifier/gemma3:12b/peripherals/1583421 new file mode 100644 index 000000000..152ea1689 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1583421 @@ -0,0 +1,8 @@ + +Please provide an option to print the default hardware configuration as command-line options, to make -nodefaults easier to use + +For full customization of the default set of hardware qemu supports, a user can pass -nodefaults and then manually specify each device they want. Many specific options document what they translate to in terms of the full configuration model; however, the defaults for any given platform don't. + +I'd love to have documentation of the default hardware configuration, in terms of qemu command-line options, to make it easy to run qemu -nodefaults, paste in the default command-line, and edit it. + +As this varies by emulated machine, perhaps qemu could have a command-line option to print a specific machine (e.g. pc-i440fx-2.5) in the form of qemu command-line options? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1586 b/results/classifier/gemma3:12b/peripherals/1586 new file mode 100644 index 000000000..e89397764 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1586 @@ -0,0 +1,108 @@ + +qemu-8.0.0-rc3 mock build test stage failures +Description of problem: +https://bugzilla.redhat.com/show_bug.cgi?id=2185288 +Following files have been attached to that report +Attached : +- The rpmuild SPEC file so far (qemu.spec.20230408.v3.txt) +- testlog.20230408.v3.txt +- build.log.20230408.v3.txt +- hw_info.log.20230408.v3.txt +- installed_pkgs.log.20230408.v3.txt +- root.log.20230408.v3.txt +- state.log.20230408.v3.txt + +A number of test failure involving allwinner-i2c and pci_expander_bridge + +``` +Summary of Failures: + + 39/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp ERROR 32.55s killed by signal 6 SIGABRT + 41/817 qemu:qtest+qtest-arm / qtest-arm/test-hmp ERROR 34.48s killed by signal 6 SIGABRT + 1/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test ERROR 210.93s killed by signal 6 SIGABRT + 3/817 qemu:qtest+qtest-arm / qtest-arm/qom-test ERROR 212.50s killed by signal 6 SIGABRT + 45/817 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test ERROR 272.50s killed by signal 6 SIGABRT + 68/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test ERROR 286.06s killed by signal 6 SIGABRT +230/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test ERROR 8.92s killed by signal 6 SIGABRT +270/817 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test ERROR 5.95s killed by signal 6 SIGABRT +337/817 qemu:qtest+qtest-i386 / qtest-i386/cxl-test ERROR 0.90s killed by signal 6 SIGABRT +630/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/cxl-test ERROR 0.84s killed by signal 6 SIGABRT + +Ok: 737 +Expected Fail: 0 +Fail: 10 +Unexpected Pass: 0 +Skipped: 70 +Timeout: 0 + +``` + +The below includes a last line of log snippet for each failure +``` + + 39/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp ERROR 32.55s killed by signal 6 SIGABRT + /builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x7fec734903a0 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + 41/817 qemu:qtest+qtest-arm / qtest-arm/test-hmp ERROR 34.48s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55e683992440 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + 1/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test ERROR 210.93s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x7fbddaf123a0 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + 3/817 qemu:qtest+qtest-arm / qtest-arm/qom-test ERROR 212.50s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55c346ae4440 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + +45/817 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test ERROR 272.50s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5636d9f16fa0 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + +68/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test ERROR 286.06s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x55e0736d8e20 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + +230/817 qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test ERROR 8.92s killed by signal 6 SIGABRT +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x55ab62324420 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + +270/817 qemu:qtest+qtest-arm / qtest-arm/device-introspect-test ERROR 5.95s killed by signal 6 SIGABRT +----------------------------------- stderr ----------------------------------- +/builddir/build/BUILD/qemu-8.0.0/include/hw/i2c/allwinner-i2c.h:35:AW_I2C: Object 0x564fbf62ee90 is not an instance of type allwinner.i2c +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + + + +337/817 qemu:qtest+qtest-i386 / qtest-i386/cxl-test ERROR 0.90s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x55c66482d5f0 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) + +630/817 qemu:qtest+qtest-x86_64 / qtest-x86_64/cxl-test ERROR 0.84s killed by signal 6 SIGABRT +../hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5634e6278170 is not an instance of type pxb +Broken pipe +../tests/qtest/libqtest.c:193: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) +``` +Steps to reproduce: +1. Populate rpmbuild folders with ```rpm -i qemu-7.2.0-7.fc39.srpm``` from https://koji.fedoraproject.org/koji/packageinfo?packageID=3685 +2. Download to ```~/rpmbuild/SOURCES/qemu-8.0.0.tar.xz``` from ```https://download.qemu.org/qemu-8.0.0-rc3.tar.xz``` +3. craft ```~/SPECS/qemu.spec``` for qemu-8.0.0-rc3 (or download attachment of bugzilla bug) +4. recreate new qemu-8.0.0 srpm ```rpmbuild -bs SPECS/qemu.spec``` +5. run ```mock -r /etc/mock/fedora-38-x86_64.cfg --rebuild ~/rpmbuild/SRPMS/qemu-8.0.0-0.fc38.src.rpm``` +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1586611 b/results/classifier/gemma3:12b/peripherals/1586611 new file mode 100644 index 000000000..bad3d5bf9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1586611 @@ -0,0 +1,14 @@ + +usb-hub can not be detached when detach usb device from VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1586613 b/results/classifier/gemma3:12b/peripherals/1586613 new file mode 100644 index 000000000..395e2f0a1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1586613 @@ -0,0 +1,14 @@ + +usb-hub can not be detached when detach usbdevice VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1590322 b/results/classifier/gemma3:12b/peripherals/1590322 new file mode 100644 index 000000000..0aedd624a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1590322 @@ -0,0 +1,11 @@ + +mouse_button 0 takes back to initial position + +i wrote a python script to perform some drag function in the Qemu simulator. +mouse_move x , y +mouse_button 1 +mouse_move new_x,new_y +mouse_move 0 + + +The mouse_move 0 doesn't release the mouse in the position new_x,new_y instead it takes it back to the point x,y and then releases the mouse \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1592336 b/results/classifier/gemma3:12b/peripherals/1592336 new file mode 100644 index 000000000..3620f7456 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1592336 @@ -0,0 +1,28 @@ + +mouse is defunct when grabbed + +I run qemu as follows: +qemu-system-x86_64 -machine accel=kvm -k en-us -smp 4 -m 2371 -usb \ + -device virtio-rng-pci \ + -drive file=/home/new/suse-fact.img,format=raw,discard=unmap,if=none,id=hd + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ + -soundhw hda \ + -net user,tftp=/home/xslaby/tftp,bootfile=/pxelinux.0,hostfwd=tcp::2222-:22,hostfwd=tcp::3632-:3632 -net nic,model=virtio \ + -serial pty -balloon virtio -vga virtio -display gtk,gl=on + +When I run X server with icewm inside the machine, the cursor works until I grab the mous with ctrl-alt-g. Then the cursor dismissed and the mouse is defunct. + +I also tried -usbdevice mouse and -usbdevice tablet with the same result. + +I have these versions of qemu packages: +qemu-2.6.0-470.2.x86_64 +qemu-ipxe-1.0.0-470.2.noarch +qemu-ksm-2.6.0-470.2.x86_64 +qemu-kvm-2.6.0-470.2.x86_64 +qemu-ovmf-x86_64-2015+git1462940744.321151f-2.1.noarch +qemu-ppc-2.6.0-470.2.x86_64 +qemu-seabios-1.9.1-470.2.noarch +qemu-sgabios-8-470.2.noarch +qemu-tools-2.6.0-470.2.x86_64 +qemu-vgabios-1.9.1-470.2.noarch +qemu-x86-2.6.0-470.2.x86_64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1593756 b/results/classifier/gemma3:12b/peripherals/1593756 new file mode 100644 index 000000000..d3299e980 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1593756 @@ -0,0 +1,18 @@ + +qemu-ga won't start on Windows 8.1 guest + +System: Arch Linux, kernel 4.6.2 +VM created with virt-manager 1.3.2 +qemu version 2.6.0 +Windows guest: 8.1, with latest updates (as of now) +Drivers installed from virtio-win iso image (arch package version 0.1.118.2-1) + in particular: vioserial driver version 62.73.104.11800 + +I can start the Guest Agent VSS Provider manually, but the Guest Agent itself doesn't come up. When launched from Console, I get the following: + +<timestamp>: critical: error opening path +<timestamp>: critical: error opening channel +<timestamp>: critical: failed to create guest agent channel +<timestamp>: critical: failed to initialize guest agent channel + +(As possible side effects I have experienced that suspend / resume of the VM only works when I resume, suspend again and resume again. After first resume the VM's screen is frozen and doesn't accept any input. After second resume, all seems to be well.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1596204 b/results/classifier/gemma3:12b/peripherals/1596204 new file mode 100644 index 000000000..dfc1e2c6b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1596204 @@ -0,0 +1,19 @@ + +UART problem in raspi2 + +I was trying to run the raspberry pi uart example at https://github.com/dwelch67/raspberrypi/tree/master/uart01 using qemu 2.6.0, but it didn't work. + +The steps I took were: +* Edit uart01/memmap and change origin to 0x10000 (which is the address qemu starts executing), +* make +* /usr/local/bin/qemu-system-arm -machine raspi2 -m 512M -nographic -gdb tcp::26000 -S -kernel uart01.bin + +Then start arm-none-eabi-gdb and run following commands: + +target remote localhost:26000 +symbol-file ./uart01.elf + + +Then, when I start the program, it seems that the GET32(AUX_MU_LSR_REG)&0x20 condition never becomes true. + +This works on actual hardware, so I am wondering if I'm doing any steps incorrectly or missing. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1605045 b/results/classifier/gemma3:12b/peripherals/1605045 new file mode 100644 index 000000000..dd1702698 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1605045 @@ -0,0 +1,4 @@ + +input-linux enter key stuck and/or broken + +Using new input-linux evdev passthrough feature of qemu (qemu 2.6.0) causes enter key to be stuck down after executing a shell script to launch qemu guest, resulting in repeated new lines in terminal. After a certain point of guest boot, the enter key is no longer pressed. However, at least under Gnome on Wayland, when pressing both left+right Ctrl keys to return keyboard back to the host, the enter key no longer functions. The enter key continues to function when control is under the guest, but never returns to functionality in the host until a reboot is performed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1608802 b/results/classifier/gemma3:12b/peripherals/1608802 new file mode 100644 index 000000000..3fbfeace2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1608802 @@ -0,0 +1,50 @@ + +READ_DMA (0xC8) command does not work correctly + +The QEMU PC emulation of DMA does not behave like real hardware or other virtualization software. + +From the original bug report (Benjamin David Lunt): + + Back to the READ_DMA command, it is my conclusion that the + READ_DMA command, more precisely, the BUS Master part of QEMU is + in error. The tests that people have done to see if it works, is + probably the guest finding out that DMA doesn't work and defaulting + to PIO, but since the read was successful visually to the user, the + user assumed the READ_DMA command works, where the guest actually + defaulted back to PIO transfers without notice. + + My code works on real hardware (numerous machines), Bochs, and Oracle's + Virtual Box. + + ... + + I have a small test suite, zipped and included at: + www.fysnet.net/temp/c8bug.zip + + Within this zip file is a.img. This is a freeDOS bootable + floppy. Emulate it with QEMU and then at the DOS prompt, run + c8bug.exe. + + It will say that the drive is not ready. + "Drive never became ready" + (along with a few other lines of text) + + The source for this test suite is also included. + c8bug.c is the c source code + c8bug.h is the header file + ctype.h is a quick way to get 'bit8u' type defines + timer.h is a delay routine from another project I have + (The base IO addresses are assumed and set at the top of c8bug.c) + (compiled with DJGPP for DPMI) + + q.bat is my command line for QEMU + + On all other machines and VirtualBox, the controller is ready + for me to receive the sector data. + "Drive is ready to transmit data..." + + However, in QEMU, the controller never becomes ready. + "Drive never became ready" + +The bug was reported for QEMU for Windows, but I can confirm that QEMU for Linux also shows that +behaviour, while VirtualBox works. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1618265 b/results/classifier/gemma3:12b/peripherals/1618265 new file mode 100644 index 000000000..30c203892 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1618265 @@ -0,0 +1,4 @@ + +Loading virtio-input-host-pci drivers before boot? To allow using passthrough devices in grub and other preboot menus? + +Currently virtio-input devices cannot be used before the kernel loads. This is not really a full bug but it would be much more useful if you can use the keyboard+mouse this way. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1618301 b/results/classifier/gemma3:12b/peripherals/1618301 new file mode 100644 index 000000000..13b3d0ef5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1618301 @@ -0,0 +1,25 @@ + +qemu-input: Mouse stops working in Windows guest + +ROCCAT Kone XTD mouse will randomly stop working in the guest until it's restarted. Windows Event Viewer shows an error in i8042prt, with the message "Could not set the mouse resolution". The XML log: + +- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> +- <System> + <Provider Name="i8042prt" /> + <EventID Qualifiers="49157">23</EventID> + <Level>2</Level> + <Task>0</Task> + <Keywords>0x80000000000000</Keywords> + <TimeCreated SystemTime="2016-08-30T02:52:00.354536300Z" /> + <EventRecordID>5708</EventRecordID> + <Channel>System</Channel> + <Computer>cronus</Computer> + <Security /> + </System> +- <EventData> + <Data /> + <Binary>000008000100000000000000170005C03205000000000000000000000000000000000000000000000000000000000000</Binary> + </EventData> + </Event> + +Host is running Linux 4.7.2 with QEMU 2.6.1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1623998 b/results/classifier/gemma3:12b/peripherals/1623998 new file mode 100644 index 000000000..b6f578a2b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1623998 @@ -0,0 +1,13 @@ + +pulseaudio Invalid argument error + +When using qemu-system-ppc on Ubuntu Mate 15 with the usb audio card, I see these error messages: + +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument + +No audio plays. When an attempt is made, QEMU seems to freeze for a moment. + +I use "-device usb-audio" to add the usb sound card. This issue is present in both emulation and KVM mode. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1630723 b/results/classifier/gemma3:12b/peripherals/1630723 new file mode 100644 index 000000000..5bcb0bc70 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1630723 @@ -0,0 +1,7 @@ + +UART writes to netduino2/stm32f205-soc disappear + +Writes to UART 2 and 3 disappear. As a sanity check I put printf statements in the function stm32f2xx_usart_write in qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed text sent to UART1 and UART4 are sent to that function while text sent to UART 2 and 3 are not. I assume writes to all 4 need to make it to that function for emulations to operate correctly. + +Example code that writes to all 4 UARTs/USARTs (does not contain the printf statements mention above): +https://github.com/skintigh/baremetal_netduino2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1631773 b/results/classifier/gemma3:12b/peripherals/1631773 new file mode 100644 index 000000000..137d519ad --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1631773 @@ -0,0 +1,12 @@ + +hw/dma/pl080.c:354: possible typo ? + +hw/dma/pl080.c:354:1: warning: V578 An odd bitwise operation detected: s->conf & (0x2 | 0x2). Consider verifying it. + +Source code is + + if (s->conf & (PL080_CONF_M1 | PL080_CONF_M1)) { + +Maybe better code + + if (s->conf & (PL080_CONF_M1 | PL080_CONF_M2)) { \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1634069 b/results/classifier/gemma3:12b/peripherals/1634069 new file mode 100644 index 000000000..a690ea2c6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1634069 @@ -0,0 +1,6 @@ + +Exclude keys from grab + +Feature request: pressing every time a shortcut to release grab for switching windows/desktops is pretty annoying, especially for users of tiling WMs. + +QEMU have to have a way to specify keys or shortcuts (possibly something like "everything with the specified modifier key"), which would not be intercepted. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1636770 b/results/classifier/gemma3:12b/peripherals/1636770 new file mode 100644 index 000000000..80e18a87a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1636770 @@ -0,0 +1,6 @@ + +mouse wheel works only with -usbdevice tablet + +2.7.0 + +tested with windows 10 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1639322 b/results/classifier/gemma3:12b/peripherals/1639322 new file mode 100644 index 000000000..e993a75e1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1639322 @@ -0,0 +1,12 @@ + +pasting into ppc64 serial console kills qemu + +- run qemu-system-ppc64 +- when X window appears press Ctrl+Alt+3 +- paste any text longer than 16 characters + + +qemu-system-ppc64: /home/abuild/rpmbuild/BUILD/qemu-2.6.1/hw/char/spapr_vty.c:40: vty_receive: Assertion `(dev->in - dev->out) < 16' failed. +Aborted (core dumped) + +Broken in SUSE Leap 42.2 and git 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1642011 b/results/classifier/gemma3:12b/peripherals/1642011 new file mode 100644 index 000000000..c36c11384 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1642011 @@ -0,0 +1,16 @@ + +Mouse wheel events not forwarded to guest using GTK display + +Using QEMU 2.7.0 with KVM enabled, when I launch the guest without options (using the default of gtk), the mouse wheel events are not propagated to the guest. + +When I start qemu using -display sdk, mouse wheel events are properly forwarded. + +I can determine that the guest is not receiving mouse wheel events by doing cat /dev/input/by-id/usb-QEMU_QEMU_USB_Mouse_42-event-mouse. When I scroll the wheel, no output is printed to the screen. + +The guest is ChromiumOS. + +The command line is: + +qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -vga cirrus -usbdevice mouse -pidfile /tmp/kvm.pid -chardev pipe,id=control_pipe,path=/tmp/kvm.pipe -serial file:/tmp/kvm.serial -mon chardev=control_pipe -net nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:9222-:22 -drive file=chromiumos/src/build/images/amd64-generic/latest/chromiumos_qemu_image.bin,index=0,media=disk,cache=unsafe + +(Most of that invocation sets up Linux fifos for various and nefarious purposes and can be profitably ignored). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1643342 b/results/classifier/gemma3:12b/peripherals/1643342 new file mode 100644 index 000000000..899cbbccd --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1643342 @@ -0,0 +1,26 @@ + +not able to passthrough mouse / keyboard + +After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error: + +qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227' + +This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error) +I use the following script: + + +qemu-system-x86_64 \ +-enable-kvm \ +-m 16392 \ +-cpu host,kvm=off \ +-smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \ +-usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \ +-vga none \ +-device vfio-pci,host=01:00.0,multifunction=on \ +-device vfio-pci,host=01:00.1 \ +-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \ +-drive if=pflash,format=raw,file=/tmp/my_vars.fd \ +-device virtio-scsi-pci,id=scsi \ +-drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ +-drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \ +-drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1649233 b/results/classifier/gemma3:12b/peripherals/1649233 new file mode 100644 index 000000000..ee3a96947 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1649233 @@ -0,0 +1,6 @@ + +scrolling does not work once mouse is grabbed + +The title pretty much told it all. It occurs in Windows 10 RS1 on qemu 2.7.0. Interestingly, I can scroll in the guest if the mouse is not grabbed. So using usb-tablet sort of works around it, but if I explicitly grab the mouse with Ctrl+Alt+G, scrolling will also stop working. + +The host is Arch Linux so the qemu build uses gtk(3) for GUI by default. I wanted to test with sdl but it seems sdl support in qemu is sort of broken that I can't even start the virtual machine properly with that. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1651167 b/results/classifier/gemma3:12b/peripherals/1651167 new file mode 100644 index 000000000..0a5fed210 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1651167 @@ -0,0 +1,27 @@ + +hw/ipmi/isa_ipmi_bt.c:283: suspect use of macro ? + +I just had a go at compiling qemu trunk with +llvm trunk. It said: + +hw/ipmi/isa_ipmi_bt.c:283:31: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] + +Source code is + + IPMI_BT_SET_HBUSY(ib->control_reg, + !IPMI_BT_GET_HBUSY(ib->control_reg)); + +That use of ! causes trouble. The SET and GET +macros are defined as: + +#define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + (((v & 1) << IPMI_BT_HBUSY_BIT))) + +I can make the compiler shut up by adding extra () in the last +use of v in the SET macro, like this: + +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + +I think this is standard good practice when using macro parameters anyway. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1654826 b/results/classifier/gemma3:12b/peripherals/1654826 new file mode 100644 index 000000000..d297556d5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1654826 @@ -0,0 +1,7 @@ + +Holding key down using input-linux freezes guest + +Qemu release version 2.8.0 +KVM, kernel 4.9.1 + +When using the -object input-linux capability in qemu for passthrough of input/evdev devices, I found that when a key is held for a few seconds or more (such as ctrl key), the guest system freezes until the key is released. In some cases, mouse control is also lost following one of these "freezes". I also noticed that one of the four cpu cores I have the guest pinned to ramps to 100% during these freezes. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1655702 b/results/classifier/gemma3:12b/peripherals/1655702 new file mode 100644 index 000000000..0793520af --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1655702 @@ -0,0 +1,11 @@ + +qemu/hw/char/exynos4210_uart.c: possible pointless local variable ? + +$ fgrep frame_size qemu/hw/char/exynos4210_uart.c + int speed, parity, data_bits, stop_bits, frame_size; + frame_size = 1; /* start bit */ + frame_size++; /* parity bit */ + frame_size += data_bits + stop_bits; +$ + +Suggest either use it or delete it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1656676 b/results/classifier/gemma3:12b/peripherals/1656676 new file mode 100644 index 000000000..2e137e9b3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1656676 @@ -0,0 +1,22 @@ + +nvram/fw_cfg.c ‘read’ may be used uninitialized + +Commit Number: b6af8ea60282df514f87d32e36afd1c9aeee28c8 + +The gcc version version 6.3.1 catches a new uninitialized variable in the master branch of QEMU on the Github. After looking through the function, it is really not properly assigned to a value in a certain path (the else condition of assigning read value in the code). +Here is the snippet of the condition assigning value: + if (dma.control & FW_CFG_DMA_CTL_READ) { + read = 1; + } else if (dma.control & FW_CFG_DMA_CTL_SKIP) { + read = 0; + } else { + dma.length = 0; + } + +Error (Warning) message is as following: +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’: +hw/nvram/fw_cfg.c:372:16: error: ‘read’ may be used uninitialized in this function [-Werror=maybe-uninitialized] + +Solution: +You can fix this by either assign a proper initial value when defining it, or give a proper value in the else condition. +Sorry that I don't have a patch for this. I'm not sure whether to assign 1 or 0 in the else condition. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1658506 b/results/classifier/gemma3:12b/peripherals/1658506 new file mode 100644 index 000000000..a82e95856 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1658506 @@ -0,0 +1,12 @@ + +qemu/hw/intc/arm_gicv3_cpuif.c:2433: bad expression ? + +qemu/hw/intc/arm_gicv3_cpuif.c:2433]: (style) Expression '(X & 0x2000000000000000) == 0x1' is always false. + +Source code is + + ((lr & ICH_LR_EL2_HW) == 1 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Maybe better code + + ((lr & ICH_LR_EL2_HW) != 0 || (lr & ICH_LR_EL2_EOI) == 0)) { \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1660035 b/results/classifier/gemma3:12b/peripherals/1660035 new file mode 100644 index 000000000..818585640 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1660035 @@ -0,0 +1,12 @@ + +hw/timer/altera_timer.c:207: bad size in memset ? + +hw/timer/altera_timer.c:207:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] + +Source code is + + memset(t->regs, 0, ARRAY_SIZE(t->regs)); + +Maybe better code + + memset(t->regs, 0, R_MAX * sizeof( uint32_t)); \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1667613 b/results/classifier/gemma3:12b/peripherals/1667613 new file mode 100644 index 000000000..87740b068 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1667613 @@ -0,0 +1,15 @@ + +Qemu 2.8 on PPC64 issue with input + +Hi devs, +on my PPC64 machine if i start qemu with gtk,gl=on or with sdl,gl=on i have issue with pointer and keyboard. pratically not input at all. +This issue is present in tgc and in kvm + +without gl=on option in kvm with mate as guest i have the input device work in the beginning but after some time the usb goes "unplugged" (i see this message on the serial log of qemu usb unplugged) and the keyboard and mouse dont work. + +On Debian jessie kvm i dont have input working at all. + +my machine is a G5 quad with Fedora 25 PPC64 + +thanks +Luigi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1668103 b/results/classifier/gemma3:12b/peripherals/1668103 new file mode 100644 index 000000000..8211fd1ec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1668103 @@ -0,0 +1,23 @@ + +Possible off-by-one error in priority handling of hw/PL190.c + +I have a problem when reading back VECTADDR in my proprietary OS's interrupt handler. + +Example client code: + + 1) Write INTENCLEAR to clear all interrupt enable bits + 2) Set all 16 vector control registers to zero + 3) Set vector address #2 to value 2 + 4) Set vector control #2 to 0x21 (vector_interrupt_enable(0x20) | vector_interrupt_source(0x1) ) + 5) Enable interrupt 1 by writing 0x2 to INTENABLE + 6) In interrupt handler: read VECTADDR [should read 0x2 (active IRQs vector address as set in step 3), reads 0x0 (active vector address index 3 instead of index 2)] + +Problem: + +So, for me, the block commented with /* Read vector address at the start of an ISR... */ in hw/pl190.c has an off by-one error and does not return the vector address of the pending interrupt, but of the next one in the list of priorities (i.e. vector address 3). + +Solution: + +In pl190_update_vectors(), also set the priority bit for the current priority (1<<i) interrupt (if enabled) in s->prio_mask[i] in addition to those of higher priority enabled interrupts. This will cause the loop in the read handling of VECTADDR to terminate an iteration earlier and will deliver the correct interrupt priority as iteration variable i subsequently used for addressing. + +I'll try to provide a patch for this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1669 b/results/classifier/gemma3:12b/peripherals/1669 new file mode 100644 index 000000000..35f24937a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1669 @@ -0,0 +1,12 @@ + +In the ARM environment, using pci-ohci with specific OS (CentOS-8-aarch64-1905-dvd1.iso) to start a virtual machine, will cause the memory leak +Description of problem: + +Steps to reproduce: +1.Using the pci-ohci as the USB controller to start the VM; + +2.install the OS using the CentOS-8-aarch64-1905-dvd1.iso ; + +3.The QEMU process is taking up more and more memory, which looks like Memory leak +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1674056 b/results/classifier/gemma3:12b/peripherals/1674056 new file mode 100644 index 000000000..96ffe5c8f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1674056 @@ -0,0 +1,36 @@ + +USB keyboard and mouse sucked into qemu-kvm (somewhere) + +i am unable to run a command line qemu that does not "suck in" the keyboard and mouse of the host PC +i tried all that i could from the command line parameters i want to run a headless gui-less kvm host + +if i specify a second set of keyboard and mouse with the -usb the only thing that is diffrent is that i have a keyboard and mouse in the VM if i specify the host keyboard and mouse same thing ... the vm is working fine but the host has no control , no keyboard. i dont see any output of anything +the only recourse i have is ctrl+alt+delete and that resets the host after 2-3 times. + +i tried ctrl+alt, ctrl+alt+x , c , z , 2 , etc... also alt + all those combination and alt with F keys +no luck. + + +my command line looks like this (altough i tried many other variations) + +qemu-system-x86_64 -M q35 -enable-kvm \ +-cpu host,kvm=off -m 4096 -smp cpu=4,sockets=1,cores=4,treads=1 \ +-drive file=xyz.qcow2,if=scsi \ +-device vfio-pci, ... (GPU) \ +-device vfio-pci, .... (GPU audio) \ +-usb -usbdevice host:XXXX:XXXX -usbdevice host:XXXX:XXXX \ <<< same behaviour with and without +-vga none -vnc localhost:1 -daemonize + +i tried with -nographics , -curses, -monitor stdio, pty and none, same result and with -serial as well +tried </dev/null at the end of the command no luck same with & + +my guess is that the keyboard and mouse gets grabbed by the "window" of the qemu regardless if there is graphics or not and i have not foud a "-headless" ,"-nograb" or "-nopussygrab" mode . (yeah had to make the joke :P) + +hardware: +Z97N-wifi +Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz +ram > 8Gb +keyboard is logitech +mouse is logitech + +distro is suse leap 42.1 (made with suseStudio) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1674117 b/results/classifier/gemma3:12b/peripherals/1674117 new file mode 100644 index 000000000..0ce739ba6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1674117 @@ -0,0 +1,76 @@ + +Qemu VM start kills Pulseaudio + +When I start a VM (start command below) in Qemu version >2.5, it kills Pulseaudio (paired with a huge lagspike) in ~4/5 cases. Using version 2.5 build from GIT, it works fine. This also happens when building from the current GIT master (ebedf0f). +Host: + Freshly installed Antergos Arch Linux 4.10.3-1-ARCH + Intel I7-5930K + ASUS X99 Deluxe II latest UEFI + GTX 770 + +Guest: + Windows 10 x64 + AMD RX480 via VFIO + +This also happened on my last install (Ubuntu GNOME 16.10). + +Start command: + QEMU_AUDIO_DRV=pa \ + QEMU_PA_SAMPLES=4096 \ + qemu-system-x86_64 \ + -serial none \ + -parallel none \ + -nodefconfig \ + -nodefaults \ + -name win10 \ + -enable-kvm \ + -cpu host,check,kvm=off \ + -smp 12,sockets=1,cores=6,threads=2 \ + -m 16G \ + -mem-prealloc \ + -device nec-usb-xhci,id=xhci \ + -device usb-host,vendorid=0x05ac,productid=0x0205,bus=xhci.0 \ + -net nic,vlan=0,model=virtio \ + -net bridge,vlan=0,br=bridge0 \ + -object iothread,id=iothread0 \ + -device virtio-blk-pci,iothread=iothread0,drive=drive0 \ + -drive file="$DISK",format=raw,if=none,cache=none,aio=native,id=drive0 \ + -boot order=c,menu=on \ + -rtc base=utc \ + -nographic \ + -k de \ + -monitor stdio \ + -soundhw hda \ + -device vfio-pci,host=02:00.0,addr=09.0,multifunction=on,x-vga=on \ + -device vfio-pci,host=02:00.1,addr=09.1 \ + -device vfio-pci,host=04:00.0,addr=07.0,multifunction=on,id=usbcontroller + +When it kills Pulseaudio, I see these errors in the Qemu console: + pulseaudio: set_sink_input_volume() failed + pulseaudio: Reason: Bad state + pulseaudio: set_sink_input_mute() failed + pulseaudio: Reason: Bad state + pulseaudio: set_source_output_volume() failed + ... many more of these ... + +The journal shows that PulseAudio is killed: + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Main process exited, code=killed, status=9/KILL + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Unit entered failed state. + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Failed with result 'signal'. + Mär 19 13:12:42 hp-desktop systemd[530]: pulseaudio.service: Service hold-off time over, scheduling restart. + Mär 19 13:12:42 hp-desktop systemd[530]: Stopped Sound Service. + Mär 19 13:12:42 hp-desktop systemd[530]: Starting Sound Service... + +I've also captured a PulseAudio debug log when this happens, but it does not contain anything interesting (no warnings or errors), which makes sense in case of SIGKILL. + +In DMESG I get some errors too, but they seem to be just symptoms (but Im just guessing...); 00:14.0 is the USB controller my DAC is connected to: + [ 4372.389051] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4372.509163] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4372.559104] usb 3-9.4: current rate 4500480 is different from the runtime rate 44100 + [ 4373.652557] xhci_hcd 0000:00:14.0: ERROR unknown event type 37 + [ 4373.712382] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 36 + [ 4373.715714] xhci_hcd 0000:00:14.0: Looking for event-dma 0000000745da7f00 trb-start 0000000745da7f10 trb-end 0000000745da7f10 seg-start 0000000745da7000 seg-end 0000000745da7ff0 + [ 4373.719055] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 + [ 4373.722381] xhci_hcd 0000:00:14.0: Looking for event-dma 0000000745da7f00 trb-start 0000000745da7f10 trb-end 0000000745da7f10 seg-start 0000000745da7000 seg-end 0000000745da7ff0 + [ 4373.725753] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 4 comp_code 13 + [ 4373.725759] xhci_hcd 0000:00:14.0: Looking for event-dma 000000073c5a51a0 trb-start 000000073c5a51b0 trb-end 000000073c5a51b0 seg-start 000000073c5a5000 seg-end 000000073c5a5ff0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1679358 b/results/classifier/gemma3:12b/peripherals/1679358 new file mode 100644 index 000000000..7cca475b6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1679358 @@ -0,0 +1,4 @@ + +ARM: RES0/RES1 SCTLR fields not read-only + +There are fields in SCTLR that are RAO/SBOP or WI or in the case of the RR field, accessible only in secure mode. Currently it seems that qemu just propagates any write to SCTLR to the register and this screwed up in a bootloader that I am debugging. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1680679 b/results/classifier/gemma3:12b/peripherals/1680679 new file mode 100644 index 000000000..46640b1fc --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1680679 @@ -0,0 +1,80 @@ + +qemu cannot run twice + +After using qemu with gpu passthrough and then shutting down windows 7 properly I cannot boot windows 7 a second time. +Only a full reboot of linux fixes this issue. +Qemu appears to corrupt something in linux when exiting. +I get no error messages but windows 7 never finishes booting during the 2nd try. +Apparently I do try to run vfiobind each time the script is run. +Wondering if rerunning vfiobind can cause an issue? + + +My specs: +----------------------------------------------------------------------------------------- +System: Host: GT70-2PE Kernel: 4.5.4-040504-generic x86_64 (64 bit gcc: 5.3.1) + Desktop: Cinnamon 3.2.7 (Gtk 3.18.9) Distro: Linux Mint 18.1 Serena +Machine: Mobo: Micro-Star model: MS-1763 v: REV:0.C Bios: American Megatrends v: E1763IMS.51B date: 01/29/2015 +CPU: Quad core Intel Core i7-4810MQ (-HT-MCP-) cache: 6144 KB + flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 22347 + clock speeds: max: 2801 MHz 1: 2801 MHz 2: 2801 MHz 3: 2801 MHz 4: 2801 MHz 5: 2801 MHz 6: 2801 MHz + 7: 2801 MHz 8: 2801 MHz +Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0 + Card-2: NVIDIA GK104M [GeForce GTX 880M] bus-ID: 01:00.0 + Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) + Resolution: 1920x1080@60.02hz, 1920x1080@60.00hz + GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 12.0.6 Direct Rendering: Yes + + +My script: +------------------------------------------------------------------------------------------- +#!/bin/bash + +cd ~/qemu +sudo ./up.sh tap0 + +configfile=~/qemu/vfio-pci1.cfg + +vfiobind() { + dev="$1" + vendor=$(cat /sys/bus/pci/devices/$dev/vendor) + device=$(cat /sys/bus/pci/devices/$dev/device) + if [ -e /sys/bus/pci/devices/$dev/driver ]; then + echo $dev > /sys/bus/pci/devices/$dev/driver/unbind + fi + echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id + +} + +modprobe vfio-pci + +cat $configfile | while read line;do + echo $line | grep ^# >/dev/null 2>&1 && continue + vfiobind $line +done + +sudo qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host,kvm=off \ +-smp 8,sockets=1,cores=4,threads=2 \ +-bios /usr/share/seabios/bios.bin \ +-serial none \ +-parallel none \ +-vga none \ +-m 4G \ +-mem-path /run/hugepages/kvm \ +-mem-prealloc \ +-balloon none \ +-rtc clock=host,base=localtime \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=/home/dad/qemu/windows7.img \ +-drive file=/home/dad/1TB-Backup/Iso/SP1ForWin7.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ +-net nic -net tap,ifname=tap0,script=no,downscript=no \ +-usbdevice host:413c:a503 \ +-usbdevice host:13fe:3100 \ +-usbdevice host:0bc2:ab21 \ +-boot menu=on \ +-boot order=c + +sudo ./down.sh tap0 + +exit 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1680991 b/results/classifier/gemma3:12b/peripherals/1680991 new file mode 100644 index 000000000..c81bd0671 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1680991 @@ -0,0 +1,100 @@ + +raspi2: system timer device not implemented + +In a small hobby kernel for Raspberry Pi 2B, I am using the system timer to control wait durations. This timer is located at 0x3f003000 and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008 (CHI). Reading these memory locations returns 0 for both. + +The basic code for this function is: +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +@@ uint64_t ReadSysTimerCount() -- read the system time running count +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +ReadSysTimerCount: + ldr r0,=ST_CLO @ load the base address of the system timer + ldrd r0,r1,[r0] @ Get the 64-bit timer "count" into r1:r0 + mov pc,lr @ return + +Tracing back the definition of ST_CLO in my code: +#define ST_CLO (ST_BASE+4) // Counter Lower 32 bits +#define ST_BASE (HW_BASE+0x3000) // System Timer base address +#define HW_BASE (0x3f000000) // this is the base address for all hardware I/O addresses + +I have tested a similar program that I know to work on real hardware with qemu-system-arm reading the same mmio register and have the same issue, so I'm pretty sure the issue is not with my code. + +My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): +[adam@os-dev ~]$ uname -a +Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3 (git). + +adam@os-dev ~]$ qemu-system-arm --version +QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +[adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version +QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +A remote debugger for my kernel shows the following: +(gdb) info reg +r0 0x0 0 +r1 0x0 0 +r2 0x96 150 +r3 0x0 0 +r4 0xa000 40960 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0xa000 40960 +r10 0x0 0 +r11 0x7fdc 32732 +r12 0x0 0 +sp 0x7fc8 0x7fc8 +lr 0x8194 33172 +pc 0x80a4 0x80a4 +cpsr 0x800001d3 -2147483181 +(gdb) stepi +0x000080a8 in ?? () +(gdb) info reg +r0 0x3f003004 1056976900 +r1 0x0 0 +r2 0x96 150 +r3 0x0 0 +r4 0xa000 40960 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0xa000 40960 +r10 0x0 0 +r11 0x7fdc 32732 +r12 0x0 0 +sp 0x7fc8 0x7fc8 +lr 0x8194 33172 +pc 0x80a8 0x80a8 +cpsr 0x800001d3 -2147483181 +(gdb) stepi +0x000080ac in ?? () +(gdb) info reg +r0 0x0 0 +r1 0x0 0 +r2 0x96 150 +r3 0x0 0 +r4 0xa000 40960 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0xa000 40960 +r10 0x0 0 +r11 0x7fdc 32732 +r12 0x0 0 +sp 0x7fc8 0x7fc8 +lr 0x8194 33172 +pc 0x80ac 0x80ac +cpsr 0x800001d3 -2147483181 + +Notice r0 is loaded with the address for CLO and then cleared with 0 when read. + +I am writing my code against the documented specifications in "BCM2835 ARM Peripherals" (attached for convenience), section "12 System Timer". + + +Please let me know if you need anything else from me. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1688231 b/results/classifier/gemma3:12b/peripherals/1688231 new file mode 100644 index 000000000..662873c0b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1688231 @@ -0,0 +1,32 @@ + +[Qemu-ppc] sendkey is not working for any of the keystrokes + +sendkey option is not working for any of the keystrokes in ppc64le, + +Qemu version: +# qemu-img --version +qemu-img version 2.9.50 (v2.9.0-303-g81b2d5c-dirty) + +Qemu command line: +# qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 4G,slots=32,maxmem=32G -smp 16,maxcpus=32 -device virtio-blk-pci,drive=rootdisk -drive file=/var/lib/libvirt/images/f25-upstream-ppc64le.qcow2,if=none,cache=none,format=qcow2,id=rootdisk -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -redir tcp:2000::22 + +Guest booted successfully and logged in +Fedora 25 (Twenty Five) +Kernel 4.11.0-rc4 on an ppc64le (hvc0) + +atest-guest login: updatedb (5582) used greatest stack depth: 9568 bytes left +root +Password: +Last login: Mon Mar 27 01:57:51 on hvc0 +[root@atest-guest ~]# + +Qemu monitor: +# telnet 127.0.0.1 1234 +Trying 127.0.0.1... +Connected to 127.0.0.1. +Escape character is '^]'. +QEMU 2.9.50 monitor - type 'help' for more information +(qemu) sendkey a +(qemu) sendkey ret + +But from the console, I couldn't observe the keystroke a or return. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1692 b/results/classifier/gemma3:12b/peripherals/1692 new file mode 100644 index 000000000..7cc9bb4f6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1692 @@ -0,0 +1,103 @@ + +Got "Assertion `bus->irq_count[i] == 0` failed" when running fuzzing +Description of problem: +When running the fuzzer on ac97, it always stops with "Assertion `bus->irq_count[i] == 0` failed". +Steps to reproduce: +Run `./qemu-fuzz-x86_64 --fuzz-target=generic-fuzz-ac97` +Additional information: +The logs triggered by the crash report are: +``` +==2330108==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000000] OPENED +INFO: libFuzzer ignores flags that start with '--' +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1879893091 +INFO: Loaded 1 modules (358762 inline 8-bit counters): 358762 [0x55bec313a1a0, 0x55bec3191b0a), +INFO: Loaded 1 PC tables (358762 PCs): 358762 [0x55bec3191b10,0x55bec370b1b0), +./qemu-fuzz-x86_64: Running 1 inputs 1 time(s) each. +Running: ./crash-55e7a160b7c66d5b41718e22c7620a29e9f568f1 +Starting x86_64 with Arguments: -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -device ac97,audiodev=snd0 -audiodev none,id=snd0 -nodefaults -qtest /dev/null +Matching objects by name ac97* +This process will try to fuzz the following MemoryRegions: + * bus master[0] (size 0xffffffffffffffff) + * ac97-nabm[0] (size 0x100) + * bus master container[0] (size 0xffffffffffffffff) + * ac97-nam[0] (size 0x400) +[R +0.033680] outl 0xcf8 0x80000800 +[S +0.033714] [R +0.033729] inw 0xcfc +[S +0.033750] [R +0.033766] outl 0xcf8 0x80000810 +[S +0.033781] [R +0.033792] outl 0xcfc 0xffffffff +[S +0.033816] [R +0.033827] outl 0xcf8 0x80000810 +[S +0.033841] [R +0.033852] inl 0xcfc +[S +0.033866] [R +0.033879] outl 0xcf8 0x80000810 +[S +0.033894] [R +0.033904] outl 0xcfc 0xc001 +[S +0.033920] [R +0.033935] outl 0xcf8 0x80000814 +[S +0.033952] [R +0.033967] outl 0xcfc 0xffffffff +[S +0.033984] [R +0.033994] outl 0xcf8 0x80000814 +[S +0.034008] [R +0.034017] inl 0xcfc +[S +0.034031] [R +0.034043] outl 0xcf8 0x80000814 +[S +0.034057] [R +0.034067] outl 0xcfc 0xc401 +[S +0.034085] [R +0.034096] outl 0xcf8 0x80000804 +[S +0.034110] [R +0.034120] inw 0xcfc +[S +0.034133] [R +0.034145] outl 0xcf8 0x80000804 +[S +0.034159] [R +0.034170] outw 0xcfc 0x7 +[S +0.035259] [R +0.035272] outl 0xcf8 0x80000804 +[S +0.035285] [R +0.035291] inw 0xcfc +[S +0.035300] [I +0.035389] CLOSED +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x80000805 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcfc 0x5050505 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc40b 0x6f0d +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x0 0x8 0x2a256c5a2c008425 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x80000805 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcfc 0x8468920 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +qemu-fuzz-x86_64: ../../../../hw/pci/pci.c:435: void pcibus_reset(BusState *): Assertion `bus->irq_count[i] == 0' failed. +==2330108== ERROR: libFuzzer: deadly signal + #0 0x55bebf2624de in __sanitizer_print_stack_trace ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55bebf1a4b31 in fuzzer::PrintStackTrace() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55bebf17f406 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18 + #3 0x55bebf17f4cd in fuzzer::Fuzzer::CrashCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1 + #4 0x55bebf17f4cd in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19 + #5 0x7fae9f8a441f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466) + #6 0x7fae9f69800a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fae9f69800a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fae9f677858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7fae9f677728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7fae9f688fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55bebfab33a7 in pcibus_reset ../hw/pci/pci.c:435:9 + #12 0x55bec0c75ae3 in resettable_phase_hold ../hw/core/resettable.c + #13 0x55bec0c6e543 in device_reset_child_foreach ../hw/core/qdev.c:276:9 + #14 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #15 0x55bec0c5c421 in bus_reset_child_foreach ../hw/core/bus.c:97:13 + #16 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #17 0x55bec0c73729 in resettable_assert_reset ../hw/core/resettable.c:60:5 + #18 0x55bec0c7336a in resettable_reset ../hw/core/resettable.c:45:5 + #19 0x55bec0c7309a in qemu_devices_reset ../hw/core/reset.c:84:9 + #20 0x55bec02d95bb in pc_machine_reset ../hw/i386/pc.c:1901:5 + #21 0x55bebff4ede6 in qemu_system_reset ../softmmu/runstate.c:451:9 + #22 0x55bec0c49684 in fuzz_reset ../tests/qtest/fuzz/fuzz.c:56:5 + #23 0x55bec0c55641 in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:676:5 + #24 0x55bec0c4a0f7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5 + #25 0x55bebf17fc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) .. /../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15 + #26 0x55bebf1630a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21 + #27 0x55bebf16fa8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19 + #28 0x55bebf15a856 in main ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #29 0x7fae9f679082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #30 0x55bebf15a8dd in _start (../qemu-fuzz-x86_64+0x1e938dd) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal + +``` + +After some manual checks, I find out that the instruction `outl 0xcf8 0x80000805` and `outl 0xcfc 0x8468920` will set irq_count[5] to -1 while the pcibus_reset() doesn't set it back to 0 so it will fail the assertion. diff --git a/results/classifier/gemma3:12b/peripherals/1694808 b/results/classifier/gemma3:12b/peripherals/1694808 new file mode 100644 index 000000000..4686906ba --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1694808 @@ -0,0 +1,12 @@ + +Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up + +Using qemu-kvm as shipped with Ubuntu 16.04, I cannot get a passed-through USB Host Keyboard to work at boot-up using the Q35 platform. + +My minimal example to verify this bug is the following: + + qemu-system-x86_64 -M q35 -m 128 -cdrom mini.iso -usb -usbdevice host:04ca:005a -vnc :1 -display none + +Using a noname USB Keyboard with ID 04ca:005a and the Ubuntu 16.04 NetBoot mini.iso, I can see the boot screen of the Ubuntu ISO through VNC, but pressing the arrow keys doesn't do anything. + +By taking out the "-M q35" parameter, QEMU switches to the traditional i440FX system. The passed-through USB Host Keyboard works there, but the old platform is no option for me. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1707587 b/results/classifier/gemma3:12b/peripherals/1707587 new file mode 100644 index 000000000..62a9e7d06 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1707587 @@ -0,0 +1,9 @@ + +Read certificate from USB key failed + +QEMU release version: qemu-2.9.0 +VM operation system: win7 32bit + +I have an usb key which can be redirected and recognized in VM. However, it is failed to get the certificate when using the official application for this usb key. What's more, the whole app is stalled untill this usb key detached from VM. + +As I researched, this usb key uses interrupt transfers when application trying to read certificate from it. Problem is that some certificate data abandoned by "usbredir_stop_interrupt_receiving" and "usbredir_stop_ep". The two functions use "usbredir_free_bufpq" to clear the buffered usb packets, even the certificate remain in the bufpq. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1712 b/results/classifier/gemma3:12b/peripherals/1712 new file mode 100644 index 000000000..905cf09d8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1712 @@ -0,0 +1,10 @@ + +Arabic keyboard layout wrong. +Description of problem: +After a while the compilation process starts, xkb gives an error about symbols/ar not found. According to my research, linux distros using "ara" for arabic layout. But qemu pc-bios/keymaps/ folder contains "ar" for arabic layout. +Steps to reproduce: +1.Configure +2.Build +3.Wait until error appears. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1713 b/results/classifier/gemma3:12b/peripherals/1713 new file mode 100644 index 000000000..67c25a0e9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1713 @@ -0,0 +1,41 @@ + +hw/input/hid.c - Add Support for More Than Five Mouse Buttons in QEMU for evdev? +Additional information: +Sure enough, there appear to only be five buttons defined. + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/input/hid.c#L113 + +```c +[INPUT_BUTTON_LEFT] = 0x01, +[INPUT_BUTTON_RIGHT] = 0x02, +[INPUT_BUTTON_MIDDLE] = 0x04, +[INPUT_BUTTON_SIDE] = 0x08, +[INPUT_BUTTON_EXTRA] = 0x10, +``` + + +At this point, the existing naming schema cannot be continued... might I suggest: + +```c +[INPUT_BUTTON_SIX] = 0x??, +[INPUT_BUTTON_SEVEN] = 0x??, +[INPUT_BUTTON_EIGHT] = 0x??, +[INPUT_BUTTON_NINE] = 0x??, +[INPUT_BUTTON_TEN] = 0x??, +[INPUT_BUTTON_ELEVEN] = 0x??, +[INPUT_BUTTON_TWELVE] = 0x??, +``` +Although, I'm not sure if 12 buttons is future-proofed enough. + +I should also note that I found this post which states that there's no more space left in PS2 emulation, so I don't know if that would cause a conflict. +"ps/2 emulation looks like there are no unused bits for more buttons. Possibly we have to extend the usb mouse emulation for that." +https://listman.redhat.com/archives/vfio-users/2016-January/001596.html + +Unfortunately, I have never written a patch. I'm not even sure how I would apply a patch in Unraid, other than overwriting the bin file. So if this is ever fixed, I would simply hope that one day a new version of QEMU would get up-streamed into a new version of Unraid. + +So, here I am humbly asking for support. I don't know if it's as simple as just adding new definitions... and I have no idea what hex value to assign them. + +*edit* I also failed to get a temporary workaround to work by remapping the mouse buttons in the host VM using xmodmap using this command: + +`xmodmap -e "pointer = 1 12 3 4 5 6 7 8 9 10 11 2" &` +I tried saving `pointer = 1 12 3 4 5 6 7 8 9 10 11 2` in the host VM's root folder in .Xmodmap, but it did not propogate to guest VMs. The buttons were still their original mapping and running the xmod command had no effect. diff --git a/results/classifier/gemma3:12b/peripherals/1714538 b/results/classifier/gemma3:12b/peripherals/1714538 new file mode 100644 index 000000000..ae24fdf69 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1714538 @@ -0,0 +1,4 @@ + +Support for Raspberry Pi 3 Model B + +The raspberry pi 3 B uses a 64-bit instruction set. It would be useful if qemu could emulate the boardn \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1715296 b/results/classifier/gemma3:12b/peripherals/1715296 new file mode 100644 index 000000000..82deb6625 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1715296 @@ -0,0 +1,17 @@ + +qemu: invalid serial port configuration + +The tty_serial_init() function sets the port c_oflags as follows: +tty.c_oflag |= OPOST not clearing ONLCR, ONLRET and others. +The result is that the postprocess output is enabled and host translates 0xa (LF) to 0xd 0xa (CR LF) which breaks the binary transmissions on serial port even if you set the port to raw mode (no matters if on host and/or guest). +The issue has been reported 11 years ago on qemu-devel mailing list: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +There was also a FreeBSD patch including the fix: +https://lists.freebsd.org/pipermail/freebsd-ports/2006-October/036390.html + +I think the correct port configuration is: +tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL); +tty.c_oflag &= ~OPOST; + +In such case the host will perform no output processing and will pass the data as is. +And the guest will be able to configure input/output processing exactly as it wants. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1718719 b/results/classifier/gemma3:12b/peripherals/1718719 new file mode 100644 index 000000000..6bee704a9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1718719 @@ -0,0 +1,12 @@ + +qemu can't capture keys properly under wayland + +This appears to be different than the previous similar bugs; patches do look to be applied to use libinput in the wayland case. Still: + +unknown keycodes `(unnamed)', please report to <email address hidden> + +I am using qemu-system-x86 1:2.10+dfsg-0ubuntu1 + +Many key inputs work correctly, but at boot the system will not properly catch the arrow keys, the above error shows up immediately after hitting Esc (for instance) to get to the boot menu. Booting from CD onto a daily Ubuntu desktop image, I can't navigate the splash menu. + +The same works correctly through virt-manager (which uses spice AFAICT, but wayland tends to crash when running virt-manager), and things work if I switch my session to Xorg rather than wayland. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1719339 b/results/classifier/gemma3:12b/peripherals/1719339 new file mode 100644 index 000000000..a70ddfca5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1719339 @@ -0,0 +1,14 @@ + +serial8250: too much work for irq3 + +It's know issue and sometimes mentioned since 2007. But it seems not fixed. + +http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00140.html +https://bugzilla.redhat.com/show_bug.cgi?id=986761 +http://old-list-archives.xenproject.org/archives/html/xen-devel/2009-02/msg00696.html + +I don't think fixes like increases PASS_LIMIT (/drivers/tty/serial/8250.c) or remove this annoying message (https://patchwork.kernel.org/patch/3920801/) is real fix. Some fix was proposed by H. Peter Anvin https://lkml.org/lkml/2008/2/7/485. + +Can reproduce on Debian Strech host (Qemu 1:2.8+dfsg-6+deb9u2), Ubuntu 16.04.2 LTS (Qemu 1:2.5+dfsg-5ubuntu10.15) also tried to use master branch (QEMU emulator version 2.10.50 (v2.10.0-766-ga43415ebfd-dirty)) if we write a lot of message into console (dmesg or dd if=/dev/zero of=/dev/ttyS1). + +/usr/local/bin/qemu-system-x86_64 -name guest=ultra1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-ultra1/master-key.aes -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Client,ds=on,acpi=on,ss=on,ht=on,tm=on,pbe=on,dtes64=on,monitor=on,ds_cpl=on,vmx=on,smx=on,est=on,tm2=on,xtpr=on,pdcm=on,osxsave=on,tsc_adjust=on,clflushopt=on,pdpe1gb=on -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 4537ca29-73b2-40c3-9b43-666de182ba5f -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-27-ultra1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8.0x7 -drive file=/home/dzagorui/csr/csr_disk.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:a9:4c:86,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4000,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4001,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 -msg timestamp=on \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1721187 b/results/classifier/gemma3:12b/peripherals/1721187 new file mode 100644 index 000000000..19f3dc716 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1721187 @@ -0,0 +1,18 @@ + +install Centos7 or fedora27 on qemu on windows8.1 + +Hello, +I have tried to install CentOs or Fedora27 on my Windows8 using QEMU. I work on notepad with 4GB. +Unfortunatly, my touchpad nor my usb-mouse are not recognise on the graphical installation of CentOs and Fedora installation. So, I cannot install them. +Here are the commands I use for installation : + +qemu-img create -f qcow2 fedora27b2_hd.qcow2 80G + +qemu-system-x86_64 -k fr -hda fedora27b2_hd.qcow2 -cdrom Fedora-Workstation-Live-x86_64-27_Beta-1.5.iso -m 512 -boot d + +I have tried to add the option : -device usb-mouse but, I got the error message that no 'usb-bus' found for the usb-mouse device. + +What is wrong ? QEMU or my installation command ? + +Thank, BRgds, +Laurent \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1722884 b/results/classifier/gemma3:12b/peripherals/1722884 new file mode 100644 index 000000000..15c1db05f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1722884 @@ -0,0 +1,18 @@ + +keyboard input while mouse moving triggers mouse failure + +When QEMU is getting a ton of mouse input events if keys are pressed on the keyboard the scan code will be corrupted causing erroneous behavior. I have confirmed this problem in the latest version in git (530049bc1dcc24c1178a29d99ca08b6dd08413e0). + +After the erroneous behavior the operating system issues a keyboard reset which prevents the mouse from functioning until the operating system is restarted. + +This seems to only occur if the PS2 mouse is being used as the input, the tablet input device doesn't exhibit this behavior. + +The same problem was reported here also: https://openxt.atlassian.net/browse/OXT-562 + +Host : Debian 9 +CPU : Ryzen 1700X +RAM : 16GB +Kernel: 4.12.0-0.bpo.2-amd64 + +Guest : Windows 10 (KVM) +RAM : 8GB (1GB Huge pages) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1723984 b/results/classifier/gemma3:12b/peripherals/1723984 new file mode 100644 index 000000000..c9c6656ec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1723984 @@ -0,0 +1,18 @@ + +ID_MMFR0 has an invalid value on aarch64 cpu (A57, A53) + +The ID_MMFR0 register, accessed from aarch64 state as an invalid value: +- ARM ARM v8 documentation (D7.2 General system control registers) described bits AuxReg[23:20] to be + "In ARMv8-A the only permitted value is 0010" +- Cortex A53 and Cortex A57 TRM describe the value to be 0x10201105, so AuxReg[23:20] is 0010 too +- in QEMU target/arm/cpu64.c, the relevant value is + cpu->id_mmfr0 = 0x10101105; + +The 1 should be changed to 2. + +Spotted & Tested on the following qemu revision: + +commit 48ae1f60d8c9a770e6da64407984d84e25253c69 +Merge: 78b62d3 b867eaa +Author: Peter Maydell <email address hidden> +Date: Mon Oct 16 14:28:13 2017 +0100 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1726910 b/results/classifier/gemma3:12b/peripherals/1726910 new file mode 100644 index 000000000..f377dc04e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1726910 @@ -0,0 +1,12 @@ + +UI request: add a function key toolbar (f1-f12) + +I run old DOS programs under FreeDOS using QEMU. + +It's common when running/testing DOS applications to use the function keys. Some of these (such as F10) are intercepted by the window system. For example, some DOS program installers use F10 to install the software, but F10 is intecepted by the window system. + +The standard solution is to jump to the QEMU console and use sendkey to send a specific function key to the QEMU guest (often needed for 'sendkey f10'). But this does not seem to be very user friendly for new users. Nor is it very fast if you need to this often. + +I propose QEMU add a toolbar with the function keys. + +I've attached a mockup of one possible design, with a simple toolbar for F1-F12. A possible modification would be to add "modifier" buttons for Ctrl and Shift and Alt to make it easier for users to enter combinations like Ctrl-F12 or Alt-F10 or Shift-F1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1731588 b/results/classifier/gemma3:12b/peripherals/1731588 new file mode 100644 index 000000000..0c9cf616d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1731588 @@ -0,0 +1,14 @@ + +qemu-system-arm black screen and keyboard not detected + +Hi guys, + +I try to emulate FreeRTOS with this guide : http://wiki.csie.ncku.edu.tw/embedded/Lab32 +But, the keys on my keyboard are not taken into account. + - Command line : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -semihosting +If I try to add usb flag with : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -usb -device usb-host,hostbus=1,hostaddr=1 -show-curso +I obtain this message "qemu-system-arm: -device usb-host,hostbus=1,hostaddr=1: 'usb-host' is not a valid device model name" + +My second option is try with the latest version of qemu with this command line : "qemu-system-arm -M lm3s6965evb -monitor stdio -kernel build/main.bin -semihosting" but I obtain a black screen. + +Could someone guide me on this problem ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1733 b/results/classifier/gemma3:12b/peripherals/1733 new file mode 100644 index 000000000..c4b9d8444 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1733 @@ -0,0 +1,4 @@ + +[riscv-pmp]: PMP_is_locked function has redundant top pmp check +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/174 b/results/classifier/gemma3:12b/peripherals/174 new file mode 100644 index 000000000..febb79096 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/174 @@ -0,0 +1,2 @@ + +European keyboard PC-105 deadkey diff --git a/results/classifier/gemma3:12b/peripherals/1745354 b/results/classifier/gemma3:12b/peripherals/1745354 new file mode 100644 index 000000000..0277c7e46 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1745354 @@ -0,0 +1,13 @@ + +CDOS ps/2 mouse problem + +Qemu v2.10.2 (also tested with 2.11.0) +Host OS : CentOS 7 x86_64 (1708) +Guest OS : Concurrent DOS 386 3.0 (with GEM) + +There is my launch command : +/usr/local/bin/qemu-system-i386 -m 4m -cpu 486 -hda /home/my_user/HDD.img -vga std + +When I'm launching the guest, it is not responding after focusing in the viewer. I think this is due to the ps/2 emulation because when I add "-usb -device usb-mouse" in my command I don't have this issue (but in this case, mouse is not supported by CDOS). + +I tested with an older version of Qemu (0.11) which uses the Bochs bios (instead of SeaBios in newer versions), and I don't have this issue either. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1748434 b/results/classifier/gemma3:12b/peripherals/1748434 new file mode 100644 index 000000000..b24760c72 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1748434 @@ -0,0 +1,8 @@ + +Possibly wrong GICv3 behavior when secure enabled + +I an tried arm-aarch64 interrupt routing to EL3, by SCR_EL3.FIQ=1. First I am started QEMU with secure=on and GICv3 support. +I programmed secure and non-secure timers and set-up appropriate interrupts.Secure timer to be GRP1_Secure and non-secure timer to be GRP1_NonSecure. ICC_PMR = 0xff. Then I switched CPU to EL1. +With that setup no interrupt was delivered to PE. GIC interface showed that non secure IRQ is pending. ICC_PMR read at EL1 returns 0 (shall return value ((PMR_(el3) << 1) & 0xff) according to GIC specification. +Than I tried to increase interrupt priority mask - so I set ICC_PMR = 0x7f (at EL3). Then I read at EL1 ICC_PMR=0xfe - (is shall be 0). With this setup IRQ of secure timer was taken at EL3, non secure timer didn't rise IRQ (as it is masked by PMR). +I dig to qemu code and see wrong condition in file arm_gicv3_cpuif.c in function icc_pmr_read(). This behavior is opposite of ARM specification. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1749223 b/results/classifier/gemma3:12b/peripherals/1749223 new file mode 100644 index 000000000..d852bc28a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1749223 @@ -0,0 +1,17 @@ + +mouse offset or invisible wall 2.11.0-3 + +(There was another post, I'm not sure if it is related though. Also not sure if it's Arch related, I wouldn't be surprised as I normally use Gentoo and have less problems with Gentoo.) + + +qemu-system-x86_64 -enable-kvm -M q35 -cpu host -m 8192 -vga vmware -smp 4,sockets=1,cores=4,threads=1 -drive file=/path/to/my.img,if=virtio -soundhw ac97 -usb -monitor unix:/tmp/qemu-mon,server,nowait -usb --usbdevice host:0000:ffff -device vfio-pci,host=00:00.0 -alt-grab & + + + +When I grab the mouse in/out of the VM I tend to get an "invisible wall" half of the time. +I can push past if I fling the mouse through it but not if I slowly keep moving down. + +The direction always seems to be down when I hit a wall (so a Y offset? maybe?) +This has been happening since at least version 2.10. + +Not sure if "-alt-grab" has anything to do with it, that'd be my first guess. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1750899 b/results/classifier/gemma3:12b/peripherals/1750899 new file mode 100644 index 000000000..1ca30c3f8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1750899 @@ -0,0 +1,25 @@ + +Mouse cursor sometimes can't pass the invisible border on the right side of the screen + +I'm using qemu 2.11 on Gentoo Linux, with configured GPU passthrough (Radeon RX580) to the guest Windows 10. +This configuration is alive for last 4 years, this time I changed a lot qemu, linux kernel and windows versions, changed GPU and always all was working as expected. I always used standard PS/2 mouse emulation and that was enough for me. + +Now, I bought two new monitors, instead of old one, and setup them as one logical monitor, using technology called Eyefinity - it's a part of standard Radeon software. Now Windows thinks, that I have one monitor with resolution 2160x1920 (I bought Dell monitors with a thin borders and use them in portrait mode). + +Windows uses it without any problems, but mouse become crazy - sometimes (~3 times from each 5) I can't move cursor to the right border of the screen, it looks like the invisible vertical border. I spent really huge amount of time to understand, which component is the root of problem and found, that it's really a mouse. I tried all possible variants (standard, tablet, virtio-mouse-pci, virtio-tablet-pci), and found, that in both mouse variants bug is reproducing, and in both tablet variants - cursor stuck near all real borders and corners, so it's not a variant too. +The only working variant becomes passing real USB port to my VM and insert second mouse to this port. So, now it's working, but I have two mice on my working place, which doesn't seems very useful. + +Here is my command line: + +QEMU_AUDIO_DRV=pa QEMU_PA_SAMPLES=4096 qemu-system-x86_64 -enable-kvm -M q35 -m 12168 -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ +-bios /usr/share/qemu/bios.bin -rtc base=localtime -vga none -device secondary-vga \ +-drive id=virtiocd,if=none,format=raw,file=/home/akushsky/virtio-win-0.1.141.iso \ +-device driver=ide-cd,bus=ide.1,drive=virtiocd \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=05:00.0,bus=root.1,addr=00.0,multifunction=on,romfile=/opt/kvm/images/Sapphire.RX580.8192.170320_1.bin,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive file=/dev/sdb,id=disk,format=raw,if=none,discard=on,cache=none,aio=native,detect-zeroes=unmap -device scsi-hd,drive=disk,id=scsi0 \ +-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-usb -usbdevice host:046d:c52b + +All in all, I checked on Windows 7 and Windows 10, and on qemu 2.10 and 2.11 - bug is always reproducible. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1751674 b/results/classifier/gemma3:12b/peripherals/1751674 new file mode 100644 index 000000000..12636ab7a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1751674 @@ -0,0 +1,16 @@ + +qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers + +Qemu segfaults trying to generate a VM memory dump: + +$ QEMU_AUDIO_DRV=none qemu-git-src/arm-softmmu/qemu-system-arm -M vexpress-a9 -smp 4 -m 1024 -machine secure=off,dump-guest-core=on -kernel linux-4.9.75/arch/arm/boot/zImage -append "root=/dev/mmcblk0 rw rootfstype=ext4 mem=1024M net.ifnames=0 console=ttyAMA0" -dtb vexpress-v2p-ca9.dtb -sd armv7-hd.qcow2 -netdev tap,ifname=tap_armv7,script=no,downscript=no,id=net0 -device virtio-net-device,mac=00:DE:AD:BE:FF:02,netdev=net0 -monitor stdio -serial vc -loadvm SS0 +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) pmemsave 0 0x3FFFFFFF memory.dmp +Segmentation fault (core dumped) + +$ git rev-parse HEAD +b384cd95eb9c6f73ad84ed1bb0717a26e29cc78f + +It's the second time I try to submit this bug, I think last time it failed because the attached core dump size (400M compressed). Have a look if you can get that file, otherwise I will try to update this ticket once it's created: + +(Error ID: OOPS-65553b72bc14be693eb1e37814ff9267) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1752 b/results/classifier/gemma3:12b/peripherals/1752 new file mode 100644 index 000000000..88c465b5d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1752 @@ -0,0 +1,23 @@ + +QEMU bug: csrw `MIE_MEIE | MIE_MSIE | MIE_MTIE` to sie changes mie +Description of problem: +QEMU bug: csrw `MIE_MEIE | MIE_MSIE | MIE_MTIE` to sie changes mie. + +**Only csrw causes this bug. csrs/csrc have no effect.** +Steps to reproduce: +output from my test program: +``` +[firmware_main] Clear mie +[firmware_main] mie is 0x0 +[firmware_main] sie is 0x0 +[firmware_main] Set MIE_SEIE | MIE_STIE | MIE_SSIE | MIE_MEIE for mie +[firmware_main] mie is 0xa22 +[firmware_main] sie is 0x0 +[firmware_main] mideleg is 0x0 +[firmware_main] Set MIE_SEIE | MIE_STIE | MIE_SSIE for mideleg +[firmware_main] mie is 0xa22 +[firmware_main] sie is 0x222 +[firmware_main] Set MIE_SSIE for sie +[firmware_main] mie is 0x800 +[firmware_main] sie is 0x0 +``` diff --git a/results/classifier/gemma3:12b/peripherals/1753314 b/results/classifier/gemma3:12b/peripherals/1753314 new file mode 100644 index 000000000..e596ef8ce --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1753314 @@ -0,0 +1,14 @@ + +UART in sabrelite machine simulation doesn't work with VxWorks 7 + +The imx_serial.c driver currently implements only partial support for the i.MX6 UART hardware. In particular, it does not implement support for the Transmit Complete Interrupt Enable bit in the UCR4 register. The VxWorks 7 i.MX6 serial driver depends on the behavior of this bit in actual hardware in order to send characters through the UART correctly. The result is that with the current machine model, VxWorks will boot and run in QEMU but it's unable to print any characters to the console serial port. + +I have produced a small patch for the imx_serial.c module to make it nominally functional with VxWorks 7. It works well enough to allow the boot banner to appear and for the user to interact with the target shell. + +I'm not submitting this as a patch to the development list as I'm not fully certain it complies with the hardware spec and doesn't break any other functionality. I would prefer if the maintainer (or someone) reviewed it for any issues/refinements first. + +I'm attaching the patch to this bug report. A copy can also be obtained from: + +http://people.freebsd.org/~wpaul/qemu/imx_serial.zip + +This patch was generated against QEMU 2.11.0 but also works with QEMU 2.11.1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1754 b/results/classifier/gemma3:12b/peripherals/1754 new file mode 100644 index 000000000..4e6bf0e17 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1754 @@ -0,0 +1,17 @@ + +QEMU wrongly requires SD card sizes to be a power of two +Description of problem: +QEMU arbitrarily requires SD card sizes to be a power of 2. However, this behavior does not match the real world, and I am unable to pass a *physical* SD card into the guest operating system. +``` +$ sudo qemu-system-aarch64 -M raspi2b -drive file=/dev/mmcblk0,if=sd,format=raw +qemu-system-aarch64: Invalid SD card size: 29.7 GiB +SD card size has to be a power of 2, e.g. 32 GiB. +You can resize disk images with 'qemu-img resize <imagefile> <new-size>' +(note that this will lose data if you make the image smaller than it currently is). +``` +Steps to reproduce: +1. Insert a physical SD card into your host system and make a note of its device name. It will be something like `/dev/mmcblk0` +2. Attempt to start a guest OS with the SD card attached. See the command above. +3. You will get an error saying that the card size is not a power of two. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1754038 b/results/classifier/gemma3:12b/peripherals/1754038 new file mode 100644 index 000000000..9f12fbb6c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1754038 @@ -0,0 +1,113 @@ + +ARM M: Systick first wrap delayed (qemu-timers/icount prb?) + +When running this kind of code with qemu: + +static void SysTickISR(void) +{ + printf("SysTick\n"); +} + +void main() +{ + volatile int i, j; + printf("setup timer\n"); + *(uint32_t*) 0xE000E014 = 0x8FFFFF; //reload value + *(uint32_t*) 0xE000E018 = 0; //force reload + *(uint32_t*) 0xE000E010 = 7; //cpu clk + ISR + enable + + for (j = 0; j < 0x100; j++) { + for (i = 0; i < 0x100000; i++) + ; + printf("cnt %08x -- %8x\n", *(uint32_t*) 0xE000E018, *(uint32_t*)0xE000E010); + } +} + +I get the following output (comments added after '#'): + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +cnt 00000000 -- 7 <--- problem here, systick should wrap and raise isr +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +SysTick <--- delayed isr occuring here +cnt 000986e0 -- 10007 +SysTick +cnt 00865290 -- 10007 <---- then running fine as long as regs not modified +cnt 00731e51 -- 7 +cnt 005fea27 -- 7 +cnt 004cb5ff -- 7 +cnt 003981d6 -- 7 +cnt 00264dad -- 7 +cnt 00131984 -- 7 +SysTick +cnt 008fe545 -- 10007 +cnt 007cb106 -- 7 +cnt 00697cdd -- 7 +cnt 005648b4 -- 7 +cnt 0043148b -- 7 +cnt 002fe061 -- 7 +cnt 001cac38 -- 7 +cnt 00097810 -- 7 +SysTick +cnt 008643d6 -- 10007 +cnt 00730f97 -- 7 +cnt 005fdb6d -- 7 +cnt 004ca745 -- 7 +cnt 0039731c -- 7 +cnt 00263ef3 -- 7 +cnt 00130aca -- 7 +SysTick +cnt 008fd68b -- 10007 +cnt 007ca24c -- 7 +cnt 00696e23 -- 7 +cnt 005639fa -- 7 +cnt 004305d1 -- 7 +cnt 002fd1a8 -- 7 +cnt 001c9d7f -- 7 +cnt 00096956 -- 7 +SysTick +cnt 0086351d -- 10007 +cnt 007300dd -- 7 +cnt 005fccb4 -- 7 +cnt 004c988c -- 7 +cnt 00396463 -- 7 +cnt 00263039 -- 7 +cnt 0012fc10 -- 7 +[...] + +Command line and version: +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -monitor stdio -serial file:/dev/pts/6 -icount 4 -cpu cortex-m4 +QEMU 2.11.50 + +I am compiling from git repo, head is: +commit f32408f3b472a088467474ab152be3b6285b2d7b +Author: Daniel P. Berrangé <email address hidden> +Date: Tue Mar 6 13:43:17 2018 +0000 + +Config options: +./configure --target-list=arm-softmmu --enable-debug --disable-slirp --enable-tcg-interpreter --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native + + +Not working with git tag 2.10.0 (almost same config) + +Working with stock qemu-arm 2.5.0 from Ubuntu 16.04. + +I started investigating, though I am not familiar with qemu code and I could see that the execution is not geting out of qemu_tcg_rr_cpu_thread_fn() 'while' loop and timers are not triggered because the values in cpu->icount_extra or cpu->icount_budget are not to modified accordingly after the timer is set (host side) when the systick register is written (target side). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1759492 b/results/classifier/gemma3:12b/peripherals/1759492 new file mode 100644 index 000000000..f5c0e7348 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1759492 @@ -0,0 +1,15 @@ + +suspend/resume is not supported for vm with tpm device + +I have used libvirt with qemu to create a vm with tpm device, when I suspend the vm and resume it, libvirt will +raise error: +libvirtError: internal error: process exited while connecting to monitor: Enter char_pty_open +I find some materials: +https://wiki.qemu.org/Features/TPM +https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg05355.html +They present qemu haven't supported tpm suspend/resume, Does someone have any advice on how to resolve the problem? + +qemu version: 2.10.2 +vm image version: centos 7.2 + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1760176 b/results/classifier/gemma3:12b/peripherals/1760176 new file mode 100644 index 000000000..2655675a9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1760176 @@ -0,0 +1,6 @@ + +optical drive doesn't open in Lubuntu 18.04 on '12 MacPro + +Running an install to HD of Lubuntu 18.04 and after running update/upgrade this morning now the optical drive door doesn't respond to keyboard "eject" key on a Mac keyboard for '12 MacPro . . . . I tried to use "xfburn" to get the door to open, nothing seems to get it to work that I know of. Yesterday there was no issue . . . . Tried to run "apt -f install" and it showed some old kernels to "autoremove" . . . which I did; didn't try to reboot into old kernel to test, perhaps now old kernel is gone? + +F \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1760262 b/results/classifier/gemma3:12b/peripherals/1760262 new file mode 100644 index 000000000..5a5bd43cc --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1760262 @@ -0,0 +1,32 @@ + +cmsdk-apb-uart doesn't appear to clear interrupt flags + +I have been writing a small operating system and using QEMU emulating the mps2-an385 board for some of my testing. + +During development of the uart driver I observed some odd behaviour with the TX interrupt -- writing a '1' to bit 0 of the INTCLEAR register doesn't clear the TX interrupt flag, and the interrupt fires continuously. + +It's possible that I have an error somewhere in my code, but after inspecting the QEMU source it does appear to be a QEMU bug. I applied the following patch and it solved my issue: + +From 9875839c144fa60a3772f16ae44d32685f9328aa Mon Sep 17 00:00:00 2001 +From: Patrick Oppenlander <email address hidden> +Date: Sat, 31 Mar 2018 15:10:28 +1100 +Subject: [PATCH] hw/char/cmsdk-apb-uart: fix clearing of interrupt flags + +--- + hw/char/cmsdk-apb-uart.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c +index 1ad1e14295..64991bd9d7 100644 +--- a/hw/char/cmsdk-apb-uart.c ++++ b/hw/char/cmsdk-apb-uart.c +@@ -274,6 +274,7 @@ static void uart_write(void *opaque, hwaddr offset, uint64_t value, + * is then reflected into the intstatus value by the update function). + */ + s->state &= ~(value & (R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); ++ s->intstatus &= ~(value & ~(R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); + cmsdk_apb_uart_update(s); + break; + case A_BAUDDIV: +-- +2.16.2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1761401 b/results/classifier/gemma3:12b/peripherals/1761401 new file mode 100644 index 000000000..1fd3a60ab --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1761401 @@ -0,0 +1,11 @@ + +ARM/Neon: vcvt rounding error + +Hello, + +While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. + +The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t. +The expected result is 125, but we get 126 instead. + +Maybe it's just a matter of default rounding mode? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1769189 b/results/classifier/gemma3:12b/peripherals/1769189 new file mode 100644 index 000000000..4e4dfc5e6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1769189 @@ -0,0 +1,11 @@ + +Issue with qemu 2.12.0 + SATA + +(first reported here: https://bugzilla.tianocore.org/show_bug.cgi?id=949 ) + +I had a Windows 10 VM running perfectly fine with OVMF UEFI, since I upgraded to qemu 2.12, the guests hangs for a couple of minutes, works for a few seconds, and hangs again, etc. By "hang" I mean it doesn't freeze, but it looks like it's waiting on IO or something, I can move the mouse but everything needing disk access is unresponsive. + +What doesn't work: qemu 2.12 with OVMF +What works: using BIOS or downgrading qemu to 2.11.1. + +Platform is arch linux 4.16.7 on skylake, I have attached the vm xml file. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1771948 b/results/classifier/gemma3:12b/peripherals/1771948 new file mode 100644 index 000000000..362fd3a8a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1771948 @@ -0,0 +1,20 @@ + +aarch64 msr CNTFRQ_EL0 + +Hello, + +I'm running qemu 2.12 on a raspberry pi 3 with the command: + +qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin + +On my start file (right in the beginning with the highest EL), the following instructions: + +ldr x0 , =19200000 +msr CNTFRQ_EL0, x0 + + +and qemu halts on the "msr CNTFRQ_EL0, x0" instruction. + +I believe this is not a normal behavior. + +Thank you \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1772086 b/results/classifier/gemma3:12b/peripherals/1772086 new file mode 100644 index 000000000..1ad95bc05 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1772086 @@ -0,0 +1,4 @@ + +malformed serial data being sent from guest + +When sending data through serial from guest each time 0x0A byte is sent 0x0D is sent before it. For example, when sending {0x29, 0x0A} on the other end I receive {0x29, 0x0D, 0x0A}. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1772165 b/results/classifier/gemma3:12b/peripherals/1772165 new file mode 100644 index 000000000..06179c62c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1772165 @@ -0,0 +1,23 @@ + +arm raspi2/raspi3 emulation has no USB support + +Using Qemu 2.12.0 on ArchLinux. + +Trying to emulate arm device with `qemu-system-arm` and attach usb device for unput using + +` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 ` + +# lsusb returns + +Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub +Bus 001 Device 014: ID 13d3:3487 IMC Networks +Bus 001 Device 004: ID 0457:11af Silicon Integrated Systems Corp. +Bus 001 Device 003: ID 0bda:57e6 Realtek Semiconductor Corp. +Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + +# qemu returns +qemu-system-arm: -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002: Bus '001' not found + + +Tried with connecting external usb keyboard but that didn't seem to work either. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1772262 b/results/classifier/gemma3:12b/peripherals/1772262 new file mode 100644 index 000000000..48b48debb --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1772262 @@ -0,0 +1,42 @@ + +Adding -spice doesn't respect environment variable QEMU_AUDIO_DRV + +When -spice is added to the commandline, QEMU_AUDIO_DRV=alsa is not respected and I receive no audio from the guest using the alsa driver. When -spice options are omitted, audio works as usual. + +I want to channel mouse and keyboard events to the guest using spice (with looking-glass) instead of a third-party product over a network interface (with synergy), but audio ends up over the spice protocol as well instead of using alsa despite asking otherwise. For example, one will only hear audio when a program like spicy is running. Naturally it would be nice if this were not needed, since spice audio is gappier than regular audio on my machine. + +Perhaps if -spice added an option similar to agent-mouse=off but for audio, (say audio-pipe=off or so for example,) this might mitigate the issue in a more naive fashion UX-wise, without having to force the issue with environment variables that unfortunately for me don't seem to work. :( + +QEMU emulator version 2.12.0 + +Commandline + + qemu-system-x86_64 \ + -ctrl-grab \ + -enable-kvm \ + -cpu host,hv-time,kvm=off \ + -smp cores=4 \ + -m 8G \ + -M q35 \ + -vga none \ + -netdev tap,id=hostnet,ifname=tap1,script=no,downscript=no \ + -net nic,model=virtio,macaddr=52:54:FD:BF:F7:9A,netdev=hostnet \ + -netdev user,id=usernet,smb=/media/DRIVE-C/tux/vms/share \ + -net nic,model=virtio,macaddr=52:54:2E:40:4F:C8,netdev=usernet \ + -usb \ + -device usb-ehci,id=ehci \ + -device ioh3420,bus=pcie.0,addr=1c,multifunction=on,port=1,chassis=1,id=root.1 \ + -device vfio-pci,host=07:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ + -device ich9-intel-hda \ + -device hda-micro \ + -drive if=virtio,file=vm/win10/disk.img,media=disk \ + -boot menu=on,splash=splash/boot.jpg,splash-time=5000 \ + -name win10 \ + -device ivshmem-plain,memdev=ivshmem \ + -object memory-backend-file,id=ivshmem,share=on,mem-path=/dev/shm/looking-glass,size=32M \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent \ + -spice addr=127.0.0.1,port=5900,disable-ticketing + +When the last four options are not present, audio works as expected. This is with both a windows 10 guest and a windows 7 guest. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1773 b/results/classifier/gemma3:12b/peripherals/1773 new file mode 100644 index 000000000..fccbe2182 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1773 @@ -0,0 +1,10 @@ + +qemu does not use the mic of the webcam dedicated to the VM +Description of problem: + +Steps to reproduce: +1. plug two webcams to the desktop, one for the host and one for the VM +2. launch QEMU VM +3. QEMU VM take the desktop webcam mic instead of the webcam mic dedicated to the VM. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1776224 b/results/classifier/gemma3:12b/peripherals/1776224 new file mode 100644 index 000000000..84f30fac4 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1776224 @@ -0,0 +1,41 @@ + +QEMU's SPICE server not getting leds callback when sending capslock + +I'm having troubles using the QEMU's SPICE server for remote views. When +trying to sync leds from my SPICE client to QEMU, I can see that the +caps lock keycodes are sent but the server state never gets updated +(which leads in funny behaviours like caps lock "blinking" in the guest +if the clients resyncs its state often). + +That behaviour doesn't happen at all with the numlock led which does the +same thing but with different keycodes. + +Here is an example of what's happening when the client tries to resync +with a capslock difference: + +> Spice received: 58 +> ps2_put_keycode: 88 +> +> Spice received: 186 +> ps2_put_keycode: 240 +> ps2_put_keycode: 88 +> ps2_queue: 186 + +And with numlock: + +> Spice received: 69 +> ps2_put_keycode: 119 +> +> Spice received: 197 +> ps2_put_keycode: 240 +> ps2_put_keycode: 119 +> ps2_queue: 197 +> ps2_set_ledstate: 0 +> Spice new ledstate: 0 + + +This behaviour is consistent across SPICE clients and only appears in a linux TTY (it works fine if I start an X server and on windows). It still happens on QEMU latest commit at the time (0d2fa03dae4fbe185a082f361342b1e30aed4582) + +Spice registers a callback for leds via qemu_add_led_event_handler but +it's never called for capslock. Is that a normal behaviour ? Is there +any reasons for the capslock led not to be updated ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1777777 b/results/classifier/gemma3:12b/peripherals/1777777 new file mode 100644 index 000000000..46c891baa --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1777777 @@ -0,0 +1,12 @@ + +arm9 clock pending (SP804) + +Hello all, + +I'm using the versatilepb board and the timer Interrupt Mask Status register (offset 0x14 of the SP804) does not seem to be working properly on the latest qemu-2.12. I tried on the 2.5 (i believe this is the mainstream version that comes with Linux) and it works perfectly. + +What happens is that the pending bit does not seem to be set in some scenarios. In my case, I see the timer value decreasing to 0 and then being reset to the reload value and neither does the interrupt is triggered nor the pending bit is set. + +I believe this is a matter of timing since in the "long" run the system eventually catches up (after a few microseconds). + +Thank you \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1778 b/results/classifier/gemma3:12b/peripherals/1778 new file mode 100644 index 000000000..c7ae0319b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1778 @@ -0,0 +1,2 @@ + +Spice audio play at wrong speed and frequency after qemu-7.2.0 diff --git a/results/classifier/gemma3:12b/peripherals/1785485 b/results/classifier/gemma3:12b/peripherals/1785485 new file mode 100644 index 000000000..4b8bd08f6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1785485 @@ -0,0 +1,11 @@ + +Mouse moves erratically when using scroll wheel on Windows NT 4, Windows 95, and Windows 3.1 guests + +QEMU version: 3.0.0 RC3 +Guests: Windows NT 4.0, Windows 95, Windows 3.1 + +Program: When the user uses the scroll wheel, the mouse's movement becomes erratic. + +This is noticed immediately when the scroll wheel is used. Sometimes the problem can be fixed by moving the scroll wheel some more. + +My theory is this problem is because of the lack of support for the Microsoft Intellimouse in these guest operating systems. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1790975 b/results/classifier/gemma3:12b/peripherals/1790975 new file mode 100644 index 000000000..38214d2d7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1790975 @@ -0,0 +1,18 @@ + +Default arm virt machine broken + +This occurs on qemu_v3.0.0 but not on qemu_v2.12.2 (built from qemu_v3.0.0 tag on github) + +Symptom: You'll see something like this in the kernel output: + +[ 1.285210] OF: PCI: host bridge /pcie@10000000 ranges: +[ 1.286246] OF: PCI: IO 0x3eff0000..0x3effffff -> 0x00000000 +[ 1.287061] OF: PCI: MEM 0x10000000..0x3efeffff -> 0x10000000 +[ 1.287820] OF: PCI: MEM 0x8000000000..0xffffffffff -> 0x8000000000 +[ 1.289312] pci-host-generic 4010000000.pcie: can't claim ECAM area [mem 0x10000000-0x1fffffff]: address conflict with /pcie@10000000 [mem 0x10000000-0x3efeffff] +[ 1.290984] pci-host-generic: probe of 4010000000.pcie failed with error -16 + + +Qemu Command Line: qemu-system-arm -machine virt -m 1024M -kernel zImage -serial stdio + +I can post my zImage if anyone has problems reproducing with their own zImage. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1791947 b/results/classifier/gemma3:12b/peripherals/1791947 new file mode 100644 index 000000000..0623dc004 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1791947 @@ -0,0 +1,15 @@ + +isochronous usb device forwarding with windows 10 and xhci freezes + +When I try to forward isochronous usb devices (webcam, HID-Audio) into the VM the devices work for a few minutes then the device stops working and stays that way until a VM reboot or a windows driver reload. +It does not matter if I use qemu-xhci or nec-xhci. +I can gather more information, if its helpful! + +Windows build: +windows 10 pro 1803 jun 2018 + +Qemu command line: +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-win10/master-key.aes -machine pc-q35-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Skylake-Client-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,ssbd=on,xsaves=on,pdpe1gb=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 38b1258e-fea4-41fe-9e21-07c426c5b2b2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win10/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device qemu-xhci,id=usb,bus=pci.3,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 -drive file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/en_windows_10_multiple_editions_version_1803_jun_2018.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:33:11,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -msg timestamp=on + +Cheers, +Florian \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1792523 b/results/classifier/gemma3:12b/peripherals/1792523 new file mode 100644 index 000000000..dc0d0fd93 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1792523 @@ -0,0 +1,51 @@ + +usb passthrough not resetting on host after vm shutdown if started with -daemonize + +Below is the full Qemu command used to launch the VM. Have been using this same setup since Qemu 2.12, plus a couple of cherry picked patch commits fixing ide-hd and e1000e in Windows guests. Both sets of patches have now been merged to 3.0, so decided to update to 3.0. + +The VM launches and runs fine, but after shutting down, the usb devices that are passed through from the host (keyboard, mouse) do not work until unplugged and plugged in again. Have narrowed this down to the -daemonize -pidfile arguments.. if those lines are removed, usb devices work in the host again right away after VM shutdown. + +CPU: Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz +OS: Linux dev 4.18.6-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 5 11:54:09 UTC 2018 x86_64 GNU/Linux + +Thank you for looking into this! + + +#!/usr/bin/env bash + +echo vfio-pci > /sys/bus/pci/devices/0000:04:00.0/driver_override +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers/vfio-pci/bind +echo > /sys/bus/pci/devices/0000:04:00.0/driver_override + +/usr/bin/qemu-system-x86_64 \ +-name winnt \ +-daemonize \ +-pidfile /run/vms/qemu/winnt.pid \ +-boot menu=on \ +-drive if=pflash,format=raw,readonly,file=/opt/vms/qemu/machines/ovmf_code_patched.fd \ +-drive if=pflash,format=raw,file=/opt/vms/qemu/machines/winnt/ovmf_vars_patched.fd \ +-machine pc-q35-3.0,accel=kvm \ +-nodefaults \ +-cpu host,kvm=off,hv_vendor_id=RedHat,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff \ +-accel kvm \ +-smp 4,sockets=1,cores=4,threads=1 \ +-m 16G \ +-nic bridge,br=br0,mac=52:54:00:12:34:77,model=e1000e \ +-device vfio-pci,host=01:00.0,multifunction=on \ +-device vfio-pci,host=01:00.1 \ +-vga none \ +-display none \ +-monitor none \ +-blockdev raw,node-name=ide-hd.0,cache.direct=on,discard=unmap,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_181265803048 \ +-device ide-hd,drive=ide-hd.0,bus=ide.0,rotation_rate=1 \ +-blockdev raw,node-name=ide-hd.1,cache.direct=on,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-TOSHIBA_HDWE160_X746K8ZTF56D-part1 \ +-device ide-hd,drive=ide-hd.1,bus=ide.1 \ +-device vfio-pci,host=04:00.0 \ +-device qemu-xhci \ +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers_probe \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1796816 b/results/classifier/gemma3:12b/peripherals/1796816 new file mode 100644 index 000000000..cb3dd912d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1796816 @@ -0,0 +1,21 @@ + +Wrong keyboard in QEMU Windows for OpenSUSE PowerPC + +I am trying to run an OpenSUSE PowerPC Little Endian system under Microsoft Windows. I have an English UK keyboard. The keyboard is basically correct (I get a 'pound' sign when I press shift-3) but some of the keys are rendered incorrectly. The wrong keys are +\ renders as # (just right of left hand shift key) +| renders as ~ (shift-\) +' renders as ` (2 keys right of l) +@ renders as ¬ (shift-') +# renders as ' (3 keys right of l) +~ renders as @ (shift-#) + +QEMU command line was +>"\Program Files\qemu\qemu-system-ppc64.exe" -hda opensuse.qcow2 + +OpenSUSE was installed from download.opensuse.org/ports/ppc/tumbleweed/iso/openSUSE-Tumbleweed-DVD-ppc64le-Current.iso . + +I am running OpenSUSE in runlevel 3 (no X11). + +I don't really know whether the problem is with QEMU, the Windows port of QEMU, or with OpenSUSE Tumbleweed. + +This is with QEMU for Windows 3.0.0 from https://qemu.weilnetz.de/w64/ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1797033 b/results/classifier/gemma3:12b/peripherals/1797033 new file mode 100644 index 000000000..5463cf347 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1797033 @@ -0,0 +1,10 @@ + +Running with -rtc clock=vm,base=<datetime> introduces arbitrary base shift at guest startup + +When specifying 'base' for RTC to start with, it has incorrect implementation in combination with clock=vm. + +I inspected source code. This is because it uses host clock (qemu_time() function return value) as reference with 'rtc_date_offset' operations across several places in code before guest execution starts, which has no relevance with clock=vm. + +It works in vast majority of cases only thanks to combination of some luck and fast execution of qemu initialization phase relative to host real time (i.e. multiple calls of qemu_time() returns same value). But if qemu execution is being slow down by high CPU load on host or started just before value of second changes, it may accumulate at least 1 second (and in hard circumstances even 2+ seconds) of delay from specified base datetime before guest becomes ready to start. + +This behavior breaks determinism of guest execution in icount mode. (Even if guest doesn't cares about precise time, just one second shift may trigger such chain of changes which accumulates significant difference in guest state at the moment when guest OS finishes booting.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/180 b/results/classifier/gemma3:12b/peripherals/180 new file mode 100644 index 000000000..f896f8103 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/180 @@ -0,0 +1,2 @@ + +hardware-based time keeping diff --git a/results/classifier/gemma3:12b/peripherals/1802 b/results/classifier/gemma3:12b/peripherals/1802 new file mode 100644 index 000000000..d5f766dd9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1802 @@ -0,0 +1,10 @@ + +windows serial COM PollingFunc don't sleep if guest uart can't write +Description of problem: +If two or more characters are sent from the host to the guest via Windows Com/Serial, everything freezes. +Steps to reproduce: +1. +2. +3. +Additional information: +I fix it in qemu/chardev/char-win.c see attached file diff --git a/results/classifier/gemma3:12b/peripherals/1804 b/results/classifier/gemma3:12b/peripherals/1804 new file mode 100644 index 000000000..9d080cddb --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1804 @@ -0,0 +1,12 @@ + +Virtual Machines Do Not Recognize Mouse 5 and 6 +Description of problem: +Trying to click the mouse buttons 5 and 6 to go forwards and backwards in Firefox does not work. It seems that those buttons are not recognized by the virtual machine. Tested with both `libvirt` and `aqemu`. Though `libvirt` testing was done on a Fedora host a few months prior. + +Running Fedora 38 VM in virtualbox does not have this problem, the guest recognizes button 5 and 6, going forwards and backwards in Firefox. +Steps to reproduce: +1. Install aqemu or libvirt on Debian 12 +2. Create a Fedora 38 Guest machine +3. Open Firefox and navigate to a few pages, then try to go backwards and forwards in history using the mouse buttons. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1806114 b/results/classifier/gemma3:12b/peripherals/1806114 new file mode 100644 index 000000000..f111b7c20 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1806114 @@ -0,0 +1,30 @@ + +Reading sectors from floppy with BIOS INT 13h is broken + +I'm developing a game bootable from a floppy disk, written in i386 assembly. I found out it doesn't work on newer QEMU versions. I managed to isolate the issue and it seems that there's a problem with handling of BIOS interrupt 13h when it comes to reading disk sectors (AH=02). + +I've written a simple test in assembly. It simply accesses four different floppy disk sectors and prints out the strings they contain. The problem is, the two latter strings don't show up at all nor the BIOS interrupt returns an error (CF set). I've attached the code to this bug report. I use following commands to compile it and run: + +$ nasm disk-test.asm -o disk-test.bin +$ qemu-system-i386 -boot a -fda disk-test.bin + +After running, the expected output is: + + I am a test string from boot sector + C:H:S 0:0:2 - Hello + C:H:S 0:0:3 - there! + C:H:S 0:1:4 - In QEMU you can't + C:H:S 1:0:5 - see these two lines! :( + +while the actual output is: + + I am a test string from boot sector + C:H:S 0:0:2 - Hello + C:H:S 0:0:3 - there! + + +So far, I found this problem in the current QEMU version for Ubuntu 18.04 (Debian 1:2.11+dfsg-1ubuntu7.8), as well as in the 3.1.0-rc3 and 2.12.1 versions, available on the www.qemu.org website. Thus, the issue doesn't seem to be very recent. + +To be sure, I ran the program on my other machine with older QEMU version (Debian 2.0.0+dfsg-2ubuntu1.43) and on my RaspberryPi 2 (Debian 1.1.2+dfsg-6+deb7u25) and everything works as expected there. It also works well in VirtualBox. + +I hope these information are useful to you, however, I feel like this bug may be more related to Seabios. If so, please let me know and I will report it somewhere else. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1806824 b/results/classifier/gemma3:12b/peripherals/1806824 new file mode 100644 index 000000000..36e699547 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1806824 @@ -0,0 +1,10 @@ + +SIE-200 (TrustZone) MPC: BLK_MAX returns an incorrect value + +Version: +$ qemu-system-arm --version +QEMU emulator version 3.0.92 (v3.1.0-rc2-31-gd522fba244) + +Arm SIE-200 Technical Reference Manual describes that BLK_MAX indicates the maximum value of "block based index register" (BLK_IDX). For example, the value 1 would indicate that BLK_IDX can be 0 or 1. According to my experiments, the AN505 FPGA image apparently follows this behavior. + +In the current implementation of QEMU, it appears to indicate the number of possible values for BLK_IDX, i.e., one plus the value it's supposed to return. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1810000 b/results/classifier/gemma3:12b/peripherals/1810000 new file mode 100644 index 000000000..c3ac7d737 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1810000 @@ -0,0 +1,16 @@ + +qemu system emulator crashed when using xhci usb controller + +I am testing usb-bt-dongle device on xchi host controller, and found +that the qemu crashed directly with an assertion failer. + +Here is the information to reproduce the crash: + +Qemu git revision: 9b2e891ec5ccdb4a7d583b77988848282606fdea +System emulator: qemu-x86_64 +VM image: https://people.debian.org/~aurel32/qemu/amd64/debian_squeeze_amd64_desktop.qcow2 +CommandLine: qemu-system-x86_64 -M q35 -device qemu-xhci,id=xhci -enable-kvm -device usb-bt-dongle -hda ./debian_wheezy_amd64_standard.qcow2 + +Error message: + +qemu-system-x86_64: /build/qemu-Eap4uc/qemu-2.11+dfsg/hw/usb/core.c:592: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1811916 b/results/classifier/gemma3:12b/peripherals/1811916 new file mode 100644 index 000000000..e520aaa00 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1811916 @@ -0,0 +1,4 @@ + +SDL2 interface didn't follow the current X11 keyboard layout for hotkeys + +My X11 was configured to use Dvorak keyboard layout, with setxkbmap(1). Despite the window title said 'Press Ctrl-Alt-G to exit grab' after it grabbed the mouse, pressing this hotkey don't have any effects, and I has to switch to a virtual terminal to kill(1) that qemu process. By debugging the program I found it is using the raw key code to handle the key events, so I must use CTRL-ALT-I to exit the grab, in my keyboard. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1815009 b/results/classifier/gemma3:12b/peripherals/1815009 new file mode 100644 index 000000000..6eec684fc --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1815009 @@ -0,0 +1,8 @@ + +Qemu evdev multiple guests/host switch + +Hello, + +Qemu up to version 3.1 + +it would be nice if passed through evdev can be switched (using lctrl + rctrl) through all running guests configured for evdev and the host. Currently, only the last started guest and host can be switched only so the previously started guests can't be controlled. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1815078 b/results/classifier/gemma3:12b/peripherals/1815078 new file mode 100644 index 000000000..039f9d784 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1815078 @@ -0,0 +1,22 @@ + +Qemu 3.1.0 risc-v mie.MEIE + +Hello all, + +There is a bug in qemu for Risc-v, related to the mie register: when we try to set the MEIE bit (11) nothing is done, even when we are running at machine mode. + +Li a0 , 1 << 11 +Csrs mie , a0 + +And when we read mie it is as though nothing was done. + +Going through the qemu source code I was able to correct it: on file op_helper.c, line 94, the variable all_ints should be initialized with: + +uint64_t all_ints = delegable_ints | MIP_MSIP | MIP_MTIP | MIP_MEIP; + +That is, the MIP_MEIP was missing. + +I've successfully triggered uart interrupts with this patch (virt machine). + +All the best, +Pharos team \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1815721 b/results/classifier/gemma3:12b/peripherals/1815721 new file mode 100644 index 000000000..fb90cd58a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1815721 @@ -0,0 +1,15 @@ + +RISC-V PLIC enable interrupt for multicore + +Hello all, + +There is a bug in Qemu related to the enabling of external interrupts for multicores (Virt machine). + +After correcting Qemu as described in #1815078 (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable interrupts for core 1 at address 0x0C00_2080 we don't seem to be able to trigger an external interrupt (e.g. UART0). + +This works perfectly for core 0, but fore core 1 it does not work at all. I assume that given bug #1815078 does not enable any external interrupt then this feature has not been tested. I tried to look at the qemu source code but with no luck so far. + +I guess the problem is related to function parse_hart_config (in sfive_plic.c) that initializes incorrectly the plic->addr_config[addrid].hartid, which is later on read in sifive_plic_update. But this is a guess. + +Best regards, +Pharos team \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1816614 b/results/classifier/gemma3:12b/peripherals/1816614 new file mode 100644 index 000000000..a3c871371 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1816614 @@ -0,0 +1,24 @@ + +error: static assertion failed: "arm generic timer needs __Int128 defined" + +Hi, + +Accordingly to the instruction from https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842060/QEMU we have downloaded the Xilinx QEMU and tried to build it on Ubuntu 16.04.5 32Bit OS. We have done all the following steps from the instruction: +$ git clone git://github.com/Xilinx/qemu.git +$ cd qemu +$ git submodule update --init dtc +$ ./configure --target-list="aarch64-softmmu,microblazeel-softmmu" --enable-fdt --disable-kvm --disable-xen +$ make +and we have got the error during the compilation: +/home/qemu/include/qemu/int128.h:168:1: error: static assertion failed: "arm generic timer needs __Int128 defined" + _Static_assert(0, "arm generic timer needs __Int128 defined"); + ^ +/home/qemu/rules.mak:66: recipe for target 'stubs/qmp_pc_dimm.o' failed + +Could you please help to solve this issue. + +Last commit: commit 0b2f6a40631acd7e0cf789ea86b188d76c11149d + +Thanks, +Best Regards, +Piotr \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1818398 b/results/classifier/gemma3:12b/peripherals/1818398 new file mode 100644 index 000000000..5fd871e63 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1818398 @@ -0,0 +1,17 @@ + +No evdev mouse passthrough with virtio-vga or kvm + +Hi, + +Using qemu version 3.1.0-1 on a host with the latest Archlinux 64-bit distribution, and running the same OS as guest, the mouse doesn't work when using both evdev passthrough and virtio-vga, or when using both evdev passthrough and kvm. + +The following command line runs a machine that does not receive any mouse event: +qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host -accel kvm -boot order=dc,menu=on -m size=2048 -net nic -device virtio-vga -device intel-hda -name Linux -drive file=/mnt/data/nobody/linux/arch.img,if=virtio -display sdl,gl=on -full-screen -net user -D /dev/null -rtc base=utc,clock=host,driftfix=slew -nodefaults -object input-linux,id=kbd1,evdev=/dev/input/event6,grab_all=on,repeat=on -object input-linux,id=mouse1,evdev=/dev/input/event7 + +But with this command line, removing virtio-vga and kvm, the mouse works as expected: +qemu-system-x86_64 -machine type=q35 -boot order=dc,menu=on -m size=2048 -net nic -device cirrus-vga -device intel-hda -name Linux -drive file=/mnt/data/nobody/linux/arch.img,if=virtio -display sdl,gl=on -full-screen -net user -D /dev/null -rtc base=utc,clock=host,driftfix=slew -nodefaults -object input-linux,id=kbd1,evdev=/dev/input/event6,grab_all=on,repeat=on -object input-linux,id=mouse1,evdev=/dev/input/event7 + +Note: Passing a keyboard by evdev in the same way always works, the problem is mouse specific. + +Thanks in advance for the analysis, +gatestallman \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1819649 b/results/classifier/gemma3:12b/peripherals/1819649 new file mode 100644 index 000000000..2d78c2e98 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1819649 @@ -0,0 +1,6 @@ + +Win10 Preview Build 18351 - no input + +The issue exists in both 2.12.1 and current master (built 8.3.2019). Neither keyboard nor mouse input seems to work and there's no cursor available (VNC, SPICE, SDL tested). If all the 'hv_*' flags are removed input works again. + +In the attachments you can find a simple script to reproduce it (requires the ISO path to be changed). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1824704 b/results/classifier/gemma3:12b/peripherals/1824704 new file mode 100644 index 000000000..1428e91e8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1824704 @@ -0,0 +1,24 @@ + +-k tr not working after v20171217! turkish keyboard dont working + +hi qemu + +-k tr not working after v20171217! turkish keyboard dont working + +last working without proplem at v20171217! + + +after this version tr keyboard prople. +freedos , winpe , linux images all dont working tr turkish keyboard. + +example press key " ç " show " , " +example 2 press key " . " show " ç " + +tr keyboard work always "en-us" kbd. +:(((((((( + + + +please fix this critical bug. + +Sincerely \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1831362 b/results/classifier/gemma3:12b/peripherals/1831362 new file mode 100644 index 000000000..272dc45d1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1831362 @@ -0,0 +1,28 @@ + +European keyboard PC-105 deadkey + +With a freshly compiled version of qemu 4.0.50 on Windows 10 (host) + +I am using 3 different Belgian keyboards and I have the same behaviour +- 2 USB keyboards (Logitech and HP) and +- the keyboard of my laptop (HP) + +3 characters on the same key cannot be used (the key seams to be dead): +< (less than), +> (greater than) used with the combination of LShift or RShift +\ (backslash) used with the combination of AltGr + +Using grub command mode from an archlinux installation (5.1.4) +The keyboard seams to be a mix of azerty and qwerty keyboard +all letters are correctly mapped but all numbers and special +characters are not + +Using sendkey in monitor +"sendkey <" results in : \ +"sendkey shift-<" results in : | +"sendkey ctrl-alt-<" results in : nothing + +REM: VirtualBox can handle this key and with the showkey command + from the archlinux kbd package, it shows : + keycode 86 press + keycode 86 release \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1832535 b/results/classifier/gemma3:12b/peripherals/1832535 new file mode 100644 index 000000000..1d9040654 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1832535 @@ -0,0 +1,13 @@ + +[riscv/regression] Missing tlb flush introduced in refactoring + +Hello, + +In qemu-system-riscv64, following a QEMU update, I get all sort of weird and not easily reproducible crashes in my risc-v guest. + +I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b. +Some TLB flushes were removed in the following places: +target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice) +target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice) + +Adding TLB flushes in all 4 places fixes the issues for me. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1834113 b/results/classifier/gemma3:12b/peripherals/1834113 new file mode 100644 index 000000000..eaa61252b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1834113 @@ -0,0 +1,48 @@ + +QEMU touchpad input erratic after wakeup from sleep + +Using Ubuntu host and guest. Normally the touchpad works great. Within the last few days, suddenly, apparently after a wake from sleep, the touchpad will behave erratically. For example, it will take two clicks to select something, and when moving the cursor it will act as though it is dragging even with the button not clicked. + +A reboot fixes the issue temporarily. + +ProblemType: Bug +DistroRelease: Ubuntu 19.04 +Package: qemu 1:3.1+dfsg-2ubuntu3.1 +Uname: Linux 5.1.14-050114-generic x86_64 +ApportVersion: 2.20.10-0ubuntu27 +Architecture: amd64 +CurrentDesktop: ubuntu:GNOME +Date: Mon Jun 24 20:55:44 2019 +Dependencies: + +EcryptfsInUse: Yes +InstallationDate: Installed on 2019-02-20 (124 days ago) +InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 +Lsusb: + Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 001 Device 002: ID 8087:0025 Intel Corp. + Bus 001 Device 003: ID 0c45:671d Microdia + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +MachineType: Dell Inc. Precision 5530 +ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.1.14-050114-generic root=UUID=18e8777c-1764-41e4-a19f-62476055de23 ro mem_sleep_default=deep mem_sleep_default=deep acpi_rev_override=1 scsi_mod.use_blk_mq=1 nouveau.modeset=0 nouveau.runpm=0 nouveau.blacklist=1 acpi_backlight=none acpi_osi=Linux acpi_osi=! +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 04/26/2019 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: 1.10.1 +dmi.board.name: 0FP2W2 +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 10 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvr1.10.1:bd04/26/2019:svnDellInc.:pnPrecision5530:pvr:rvnDellInc.:rn0FP2W2:rvrA00:cvnDellInc.:ct10:cvr: +dmi.product.family: Precision +dmi.product.name: Precision 5530 +dmi.product.sku: 087D +dmi.sys.vendor: Dell Inc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1835827 b/results/classifier/gemma3:12b/peripherals/1835827 new file mode 100644 index 000000000..aa433bb41 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1835827 @@ -0,0 +1,6 @@ + +HTIF symbols no longer recognized by RISC-V spike board + +Tested commit: f34edbc760b0f689deddd175fc08732ecb46665f + +I belive this was introduced in 0ac24d56c5e7d32423ea78ac58a06b444d1df04d when the spike's load_kernel() was moved to riscv_load_kernel() which no longer included htif_symbol_callback(). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1842774 b/results/classifier/gemma3:12b/peripherals/1842774 new file mode 100644 index 000000000..e5c8627bb --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1842774 @@ -0,0 +1,4 @@ + +Enhanced Hardware Support - Finalize Naming + +This feature request will provide the final naming of the next machine \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1845 b/results/classifier/gemma3:12b/peripherals/1845 new file mode 100644 index 000000000..b4b2522b4 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1845 @@ -0,0 +1,10 @@ + +qemu-xhci not working on aarch64 +Description of problem: +Once the VM is loaded I run lsusb from the cli and I get no devices listed. +Steps to reproduce: +1. Build qemu from source with libusb support +2. Launch vm using the above configuration +3. Run lsusb from the command line in the VM instance +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1848231 b/results/classifier/gemma3:12b/peripherals/1848231 new file mode 100644 index 000000000..75086ee56 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1848231 @@ -0,0 +1,18 @@ + +serial/parallel character devices created for the none-machine + +The none-machine can not be started unless using "-serial null": + +qemu-system-x86_64 -machine none -nographic -monitor stdio +QEMU 3.1.1 monitor - type 'help' for more information +(qemu) qemu-system-x86_64: cannot use stdio by multiple character devices +qemu-system-x86_64: could not connect serial device to character backend 'stdio' +$ + +$ qemu-system-mips -machine none -nographic -serial null -monitor stdio +QEMU 4.1.50 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +compat_monitor0: filename=stdio +serial0: filename=null +(qemu) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1856549 b/results/classifier/gemma3:12b/peripherals/1856549 new file mode 100644 index 000000000..0f27e96b5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1856549 @@ -0,0 +1,16 @@ + +qemu-4.2.0/hw/misc/mac_via.c: 2 * bad test ? + +1. + +qemu-4.2.0/hw/misc/mac_via.c:417:27: style: Expression is always false because 'else if' condition matches previous condition at line 412. [multiCondition] + + } else if ((m->data_out & 0xf3) == 0xa1) { +... + } else if ((m->data_out & 0xf3) == 0xa1) { + +2. + +qemu-4.2.0/hw/misc/mac_via.c:467:27: style: Expression is always false because 'else if' condition matches previous condition at line 463. [multiCondition] + +Duplicate. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1857269 b/results/classifier/gemma3:12b/peripherals/1857269 new file mode 100644 index 000000000..281acb3aa --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1857269 @@ -0,0 +1,16 @@ + +Keyboard not fully working on Windows version + +Hello, + +I am working with windows qemu version: + +qemu-w64-setup-20190815 + +I have installed a msdos virtual machine on qemu with sp keyboard layout (Spain at Europe). I have found that some keys do not work in the way they should. I believe that the problem is that es qemu spanish keyboard layout is the latin one, la in msdos sysytem. + +I ask you to create the Spain layout. + + + +Thanks in advance. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1858488 b/results/classifier/gemma3:12b/peripherals/1858488 new file mode 100644 index 000000000..58826b9e0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1858488 @@ -0,0 +1,30 @@ + +qemu git && 4.2: timed audio issues with sb16, gus not working? + + +I have built [both] current git, and 4.2.0, there are issues with audio/soundhw for both. + +Specifics: + +Linux nullrig 5.3.0-24-generic #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux + +Out of source build, successful for both: + +../configure --prefix=/opt/qemu --target-list=i386-softmmu,mips64el-softmmu ---enable-sdl --enable-sdl-image --enable-lzo --enable-bzip2 --enable-avx2 --enable-kvm --enable-membarrier --enable-plugin + +Call: + +./qemu -machine pc,accel=kvm,usb=off -cpu pentium -m 64 -rtc base=localtime -parallel none -soundhw sb16,adlib,pcspk -device cirrus-vga,bus=pci.0 -drive id=disk1,file=doom.cow,format=qcow2,if=virtio -audiodev pa,id=pa + +Audio for sb16 sounds ok, however if i switch to a timer based audio: -audiodev wav + +The output is wrong.. I had assumed it was all timer based audio, however it seems to be limited to sb16. + +So I then tried the next popular/compatible audio device for dos games: gravis ultrasound [gus]. + +I get no output at all for it. +I have tried more than one piece of software, DOOM shareware is any easy example. + +I realize there are better solutions for playing DOS games, however I am interested in snapshot support which many of them lack. + +I am willing to put the work into fixing it myself if need be, however i'm not very familiar with the audio backend. Specifically, it is already mixed into a single buffer, if 'adlib' driver is already working: (audio_pcm_ops.write() output is correct on timer based output) I failed to see how it affects emulation of the sound blaster. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1859081 b/results/classifier/gemma3:12b/peripherals/1859081 new file mode 100644 index 000000000..8aa0bf148 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1859081 @@ -0,0 +1,9 @@ + +Mouse way too fast when Qemu is on a Windows VM with a OS 9 Guest + +On a server, I have a Windows 10 VM with Qemu 4.1.0 (latest) from https://qemu.weilnetz.de/w64/ installed. +There I have a Mac OS 9.2.2 machine. +Now if I connect to the Windows VM with VNC or RDP or even VMWare console, the Mouse in the Mac OS Guest inside Qemu is waaaay to fast. Even when lowering the mouse speed in the Mac OS mouse setting, one pixel in the Host (Windows 10 VM) still moves the mouse by 10 pixels inside the Qemu machine. +I tried different resolutions but that does not help. +Is there any way to fix this or any way how I can provide more information? +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1859378 b/results/classifier/gemma3:12b/peripherals/1859378 new file mode 100644 index 000000000..785a3093a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1859378 @@ -0,0 +1,21 @@ + +xhci Control Transfer requiring a Status TRB before starting transfer + +This may not necessarily be a bug, but more of a change. + +A little background may need to be in order. + +With all USB Control transfers, there is a SETUP transfer, zero or more DATA transfers, and if successful, a STATUS transfer. This STATUS transfer is used to indicate to the recipient that the previous transfers were successful. For example, in a CONTROL IN transfer, the host sends a SETUP packet to the device, receives zero or more DATA packets, and then on successful transfer, the HOST sends the STATUS packet indicating to the device that all was received. + +If no DATA packets are received, the HOST is not to send a STATUS packet. This could be due to a STALL or other error. + +With this in mind, the STATUS transfer, in this case an xHCI STATUS TRB, may not even be on the transfer ring yet. The HOST software may be waiting for a successful transfer before it submits the STATUS transfer. + +However, if you look at the test at line 1701 (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c#l1701), the current code will not start the CONTROL transfer at all if it doesn't see that STATUS TRB on the ring. + +In my opinion, this is in error. It is not required that a STATUS TRB be on the ring to start the CONTROL transfer. This STATUS TRB can be placed on the ring after a successful SETUP and zero or more DATA transfers followed by a ring to the door bell. Then after a successful transfer to this point, placing this STATUS TRB on the ring and another ring to the door bell. + +In my opinion, the check at line 1701 should be removed. + +Thank you, +Ben \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1859384 b/results/classifier/gemma3:12b/peripherals/1859384 new file mode 100644 index 000000000..d42cd04e5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1859384 @@ -0,0 +1,40 @@ + +arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N") + +For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM, only one CPU can acknowledge the IRQ until it becomes inactive. + +The TRM also mandates that SGIs and PPIs follow the N-N model and that SPIs follow the 1-N model. + +However this is not currently the case with QEMU. I have locally (no minimal test case) seen e.g. uart interrupts being acknowledged twice before having been deactivated (expected: irqId on one CPU and 1023 on the other instead). + +I have narrowed the issue down to the following: + +1) arm_gic_common_reset resets all irq_state[id] fields to 0. This means all IRQ will use the N-N model, and if s->revision != REV_11MPCORE, then there's no way to set any interrupt to 1-N. + +**If fixed locally** with a hackjob, I still have the following trace: + +pl011_irq_state 534130.800 pid=2424 level=0x1 +gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff +gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1 +gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1 +gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21 +gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1 +gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21 +gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21 +gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21 +pl011_write 1594.700 pid=2424 addr=0x44 value=0x50 +pl011_irq_state 2.000 pid=2424 level=0x0 +gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff +pl011_write 30.700 pid=2424 addr=0x38 value=0x0 +pl011_irq_state 1.200 pid=2424 level=0x0 +gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21 +gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21 +pl011_irq_state 1169.500 pid=2424 level=0x0 + +This is because: + +2) gic_acknowledge_irq calls gic_clear_pending which uses GIC_DIST_CLEAR_PENDING but this usually has no effect on level-sensitive interrupts. + +With this often being a no-op (ie. assuming ispendr was not written to), any 1-n level-sensitive interrupt is still improperly pending on all the other cores. + +(Also, I don't really know how the qemu thread model works, there might be race conditions in the acknowledgment logic if gic_acknowledge_irq is called by multiple threads, too.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1859916 b/results/classifier/gemma3:12b/peripherals/1859916 new file mode 100644 index 000000000..f3e28f48e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1859916 @@ -0,0 +1,53 @@ + +coreaudio not working on MacOS + +OS: MacOS Catalina 10.15.2 + +qemu-system-x86_64 -version +QEMU emulator version 4.2.50 (v4.2.0-13-g084a398bf8-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Qemu install via brew: brew install qemu + +--- + +I use following to install Ubuntu 18.04 desktop successfully:- + +IMG_CD=$HOME/Downloads/iso/ubuntu-18.04.3-desktop-amd64.iso +IMG_FILE=$HOME/code/vm/qemu/u64d01.qcow2 +MAC_ADDR=xx:xx:xx:xx:xx:xx + +qemu-system-x86_64 \ +-no-user-config -nodefaults \ +-show-cursor \ +-name u64d01 \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host -smp 4 -m 2048 \ +-overcommit mem-lock=off \ +-overcommit cpu-pm=off \ +-rtc base=utc,clock=host \ +\ +-device virtio-tablet-pci \ +-device virtio-vga \ +\ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=$IMG_FILE,if=none,format=qcow2 \ +\ +-device virtio-net-pci,netdev=nic1,mac=$MAC_ADDR \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +\ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0,out.buffer-count=10000 \ +\ +-cdrom $IMG_CD + +Removing the last -cdrom line Ubuntu desktop boot up and everything work perfectly except the audio. + +I test with wav audio driver by replacing the -audiodev line as follow, which save the client audio to a wave file, like below and it work perfectly: + +-audiodev wav,id=snd0,path=$HOME/qemu.wav + +I start the vm, open firefox and play a few video, then shutdown the vm. Then I can play the qemu.wav file and all the audio was recorded there. + +However, I can't get audio directly with coreaudio. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1861677 b/results/classifier/gemma3:12b/peripherals/1861677 new file mode 100644 index 000000000..c0ac1b04d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1861677 @@ -0,0 +1,49 @@ + +wavcapture crash with pulseaudio + +As of commit 28db64fce55, +using demo from QEMU advent calendar 2018 day 1: +https://www.qemu-advent-calendar.org/2018/download/day01.tar.xz + +$ qemu-system-x86_64 -M pc \ + -net none -soundhw pcspk \ + -drive file=day01/fbird.img,format=raw,if=floppy \ + -monitor stdio -S +(qemu) info qtree +bus: main-system-bus + type System + dev: i440FX-pcihost, id "" + bus: pci.0 + dev: PIIX3, id "" + bus: isa.0 + dev: isa-pcspk, id "" + audiodev = "pa" + iobase = 97 (0x61) + migrate = true +(qemu) wavcapture out.wav pa +(qemu) cont +(qemu) # Press 'up' key in demo +Segmentation fault (core dumped) + +(gdb) bt +#0 0x0000555bfef0dc51 in audio_pcm_sw_write (sw=0x555c01333930, buf=0x0, size=14728) at audio/audio.c:725 +#1 0x0000555bfef10a49 in audio_capture_mix_and_clear (hw=0x555c012379b0, rpos=0, samples=3682) at audio/audio.c:1054 +#2 0x0000555bfef11059 in audio_run_out (s=0x555c01235550) at audio/audio.c:1186 +#3 0x0000555bfef11894 in audio_run (s=0x555c01235550, msg=0x555bff3e37e8 "timer") at audio/audio.c:1355 +#4 0x0000555bfef10334 in audio_timer (opaque=0x555c01235550) at audio/audio.c:831 +#5 0x0000555bff33f041 in timerlist_run_timers (timer_list=0x555c00377b50) at util/qemu-timer.c:588 +#6 0x0000555bff33f0eb in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at util/qemu-timer.c:602 +#7 0x0000555bff33f3b6 in qemu_clock_run_all_timers () at util/qemu-timer.c:688 +#8 0x0000555bff33fb60 in main_loop_wait (nonblocking=0) at util/main-loop.c:525 +#9 0x0000555bfef0187c in main_loop () at vl.c:1683 +#10 0x0000555bfef090ab in main (argc=12, argv=0x7ffec49184c8, envp=0x7ffec4918530) at vl.c:4438 +(gdb) p *sw +$1 = {card = 0x0, s = 0x0, info = {bits = 16, sign = 1, freq = 44100, nchannels = 2, bytes_per_frame = 4, bytes_per_second = 176400, swap_endianness = 0}, conv = 0x555bfef0ced1 <noop_conv>, ratio = 4294967296, buf = 0x555c0123f6f0, + rate = 0x555c007c0ec0, total_hw_samples_mixed = 0, active = 1, empty = 1, hw = 0x555c014b12a0, name = 0x0, vol = {mute = 0, r = 4294967296, l = 4294967296}, callback = {opaque = 0x0, fn = 0x0}, entries = {le_next = 0x0, + le_prev = 0x555c014b1310}} +(gdb) p *sw->hw +$2 = {s = 0x555c01235550, enabled = 1, poll_mode = 0, pending_disable = 0, info = {bits = 16, sign = 1, freq = 44100, nchannels = 2, bytes_per_frame = 4, bytes_per_second = 176400, swap_endianness = 0}, + clip = 0x555bfef16376 <clip_natural_int16_t_from_stereo>, ts_helper = 0, mix_buf = 0x555c0059d680, buf_emul = 0x0, pos_emul = 0, pending_emul = 0, size_emul = 0, samples = 16384, sw_head = {lh_first = 0x555c01333930}, cap_head = { + lh_first = 0x0}, pcm_ops = 0x0, entries = {le_next = 0x0, le_prev = 0x0}} + +sw->hw->pcm_ops is NULL. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1861692 b/results/classifier/gemma3:12b/peripherals/1861692 new file mode 100644 index 000000000..f97aefbc2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1861692 @@ -0,0 +1,4 @@ + +wavcapture does not record silence + +Using setup described in https://bugs.launchpad.net/qemu/+bug/1861677 a wav file is generated with all the silences stripped out. IOW silence frames are not recorded. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1862887 b/results/classifier/gemma3:12b/peripherals/1862887 new file mode 100644 index 000000000..82fdbca27 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1862887 @@ -0,0 +1,70 @@ + +qemu does not load pulseaudio modules properly + +Hello, + +This is on Arch-linux(latest) and the qemu 4.2.0 version made from git clone https://github.com/spheenik/qemu.git +with: + ./configure --prefix=/opt/qemu-test --python=/usr/bin/python2 --target-list=x86_64-softmmu +--audio-drv-list=pa --disable-werror +added to the build. + +I've been workin on a passthrough Windows 10 vm this month and have been steadily seeing some promising progress. My block/issue at the moment is integrating the audio now that the GPU has been succesfully passed through. +I've been going back and forth between the audio options for Pulseaudio and cannot change the following issue: +pulseaudio: pa_context_connect() failed +pulseaudio: Reason: Connection refused +pulseaudio: Failed to initialize PA contextlibusb: error [udev_hotplug_event] ignoring udev action bind +I leave my current operable build followed by some of the options that I have tried using to correct this despite the following errors not changing + +This is my current operable build: + +#!/bin/bash + +vmname="windows10vm" + +if ps -ef | grep /opt/qemu-test/bin/qemu-system-x86_64 | grep -q multifunction=on; then +echo "A passthrough VM is already running." & +exit 1 + +else + +/opt/qemu-test/bin/qemu-system-x86_64 \ +-m 12G \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=.../win2.img \ +-drive file=.../Win10_1909_English_x64.iso,index=1,media=cdrom \ +-drive file=.../virtio-win-0.1.171.iso,index=2,media=cdrom \ +-boot order=dc \ +-bios /usr/share/ovmf/x64/OVMF_CODE.fd \ +-name $vmname,process=$vmname \ +-machine type=q35,accel=kvm,vmport=off \ +-cpu host,kvm=off \ +-smp 3,sockets=1,cores=3,threads=1 \ +-device virtio-balloon \ +-rtc clock=host,base=localtime \ +-vga none \ +-nographic \ +-serial none \ +-parallel none \ +-soundhw hda \ +-usb \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device vfio-pci,host=...,multifunction=on \ +-device vfio-pci,host=... \ +-device e1000,netdev=net0 \ +-netdev user,id=net0,hostfwd=tcp::...-:22 \ + +Here's a list of setting combinations I had tried to resolve this: + +#export QEMU_AUDIO_DRV=pa +#QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 +#export QEMU_PA_SAMPLES=8192 +#export QEMU_AUDIO_TIMER_PERIOD=99 +#export QEMU_PA_SERVER=/run/user/1000/pulse/native +#export QEMU_PA_SINK=alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo +#export QEMU_PA_SOURCE=input + +-audiodev pa,id=pa1,server=server=/run/user/1000/pulse/native + +At best I have removed an XDG_RUNTIME_DIR error but other than that this build has no audio compatability. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1865188 b/results/classifier/gemma3:12b/peripherals/1865188 new file mode 100644 index 000000000..bfa375453 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1865188 @@ -0,0 +1,12 @@ + +Switching from the monitor to the emulated machine with a French keyboard (AZERTY) + +Hi, +I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french AZERTY. + +sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr -boot d -drive if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom ../../distri/11iv1/'HP-UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS _Install&Recovery_B6821-10046.iso' -net nic,model=tulip -net tap + +When I want to use the monitor (to change cdrom during the hp-ux installation process), the characters I type are misinterpreted. For example, I enter "2" at hp-ux prompt, I see : "412691;82;22". Impossible to switch from monitor to hp-ux with Ctrl+Alt+1 and Ctrl+Alt+2. + +I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options -alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal than hp-ux. Nothing works. +Best regards. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1868617 b/results/classifier/gemma3:12b/peripherals/1868617 new file mode 100644 index 000000000..a6251231a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1868617 @@ -0,0 +1,16 @@ + +multiseat: route different spice tablet events to distinct vdagents + +docs/multiseat.txt says: + +> Note on spice: Spice handles multihead just fine. But it can't do +> multiseat. For tablet events the event source is sent to the spice +> agent. But qemu can't figure it, so it can't do input routing. +> Fixing this needs a new or extended input interface between +> libspice-server and qemu. For keyboard events it is even worse: The +> event source isn't included in the spice protocol, so the wire +> protocol must be extended to support this. + +I'm not sure exactly what "can't figure it" means, but it looks to me like qemu can't route incoming tablet events from a spice client to distinct vdagent channels. + +I think this part of the process can be fixed within qemu. I've reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to address the issues with the keyboard interface at the protocol level. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1872237 b/results/classifier/gemma3:12b/peripherals/1872237 new file mode 100644 index 000000000..d4d66b123 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1872237 @@ -0,0 +1,241 @@ + +SysTick reload behavior emulated incorrectly + +QEMU's emuation of SysTick on ARM is incorrect with respect to reload +behavior. This issue is described here, and also in a repository +dedicated to the issue: + + https://github.com/oxidecomputer/qemu-systick-bug + + +(What follows is in Markdown, which I understand that Launchpad does +not support; see the repository linked above for a rendering of it.) + +Take this Rust program: + +```rust +#![no_std] +#![no_main] + +extern crate panic_semihosting; + +use cortex_m_rt::entry; +use cortex_m_semihosting::hprintln; +use cortex_m::peripheral::syst::SystClkSource; +use cortex_m::peripheral::SYST; + +fn delay(syst: &mut cortex_m::peripheral::SYST, ms: u32) +{ + /* + * Configured for the LM3S6965, which has a default CPU clock of 12 Mhz + */ + let reload = 12_000 * ms; + + syst.set_reload(reload); + syst.clear_current(); + syst.enable_counter(); + + hprintln!("waiting for {} ms (SYST_CVR={}) ...", + ms, SYST::get_current() + ).unwrap(); + + while !syst.has_wrapped() {} + + hprintln!(" ... done (SYST_CVR={})\n", SYST::get_current()).unwrap(); + + syst.disable_counter(); +} + +#[entry] +fn main() -> ! { + let p = cortex_m::Peripherals::take().unwrap(); + let mut syst = p.SYST; + + syst.set_clock_source(SystClkSource::Core); + + loop { + delay(&mut syst, 1000); + delay(&mut syst, 100); + } +} +``` + +This program should oscillate between waiting for one second and waiting +for 100 milliseconds. Under hardware, this is more or less what it does +(depending on core clock frequency); e.g., from an STM32F4107 (connected via +OCD and with semi-hosting enabled): + +``` +waiting for 1000 ms (SYST_CVR=11999949) ... + ... done (SYST_CVR=11999902) + +waiting for 100 ms (SYST_CVR=1199949) ... + ... done (SYST_CVR=1199897) + +waiting for 1000 ms (SYST_CVR=11999949) ... + ... done (SYST_CVR=11999885) + +waiting for 100 ms (SYST_CVR=1199949) ... + ... done (SYST_CVR=1199897) + +waiting for 1000 ms (SYST_CVR=11999949) ... + ... done (SYST_CVR=11999885) + +``` + +Under QEMU, however, its behavior is quite different: + +``` +$ cargo run + Finished dev [unoptimized + debuginfo] target(s) in 0.03s + Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel target/thumbv7m-none-eabi/debug/qemu-systick-bug` +waiting for 1000 ms (SYST_CVR=11999658) ... + ... done (SYST_CVR=11986226) + +waiting for 100 ms (SYST_CVR=0) ... + ... done (SYST_CVR=1186560) + +waiting for 1000 ms (SYST_CVR=1185996) ... + ... done (SYST_CVR=11997350) + +waiting for 100 ms (SYST_CVR=0) ... + ... done (SYST_CVR=1186581) +``` + +In addition to the values being strangely wrong, the behavior is wrong: +the first wait correctly waits for 1000 ms -- but the subsequent wait +(which should be for 100 ms) is in fact 1000 ms, and the next wait (which +should be for 1000 ms) is in fact 100 ms. (That is, it appears as if +the periods of the two delays have been switched.) + +The problems is that the QEMU ARM emulation code does not reload SYST_CVR from +SYST_RVR if SYST_CSR.ENABLE is not set -- and moreover, that SYST_CVR is +not reloaded from SYST_RVR even when SYST_CSR.ENABLE becomes set. This is +very explicit; from +<a +href="https://github.com/qemu/qemu/blob/8bac3ba57eecc466b7e73dabf7d19328a59f684e/hw/timer/armv7m_systick.c#L42-L60">hw/timer/armv7m_systick.c</a>: + +```c +static void systick_reload(SysTickState *s, int reset) +{ + /* The Cortex-M3 Devices Generic User Guide says that "When the + * ENABLE bit is set to 1, the counter loads the RELOAD value from the + * SYST RVR register and then counts down". So, we need to check the + * ENABLE bit before reloading the value. + */ + trace_systick_reload(); + + if ((s->control & SYSTICK_ENABLE) == 0) { + return; + } + + if (reset) { + s->tick = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); + } + s->tick += (s->reload + 1) * systick_scale(s); + timer_mod(s->timer, s->tick); +} +``` + +The statement in the code is stronger than the statement in the +<a href="https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf">ARMv7-M Architecture Reference Manual</a> (sec B3.3.1): + +> Writing to SYST_CVR clears both the register and the COUNTFLAG status +> bit to zero. This causes the SysTick logic to reload SYST_CVR from SYST_RVR +> on the next timer clock. A write to SYST_CVR does not trigger the +> SysTick exception logic. + +Note that this does not mention the behavior on a write to SYST_CVR when +SYST_CSR.ENABLE is not set -- and in particular, does *not* say that writes to +SYST_CVR will be ignored if SYST_CSR.ENABLE is not set. + +Section 3.3.1 does go on to say: + +> The SYST_CVR value is UNKNOWN on reset. Before enabling the SysTick counter,u +> software must write the required counter value to SYST_RVR, and then write +> to SYST_CVR. This clears SYST_CVR to zero. When enabled, the counter +> reloads the value from SYST_RVR, and counts down from that value, rather] +> than from an arbitrary value. + +(This is more or less what has been quoted in the implementation of +`systick_reload`, above.) This note does **not** say, however, that writes +to SYST_CVR will be discarded when not enabled, but rather that the counting +will only begin (and the value in SYST_RVR loaded or reloaded) when +SYST_CSR.ENABLE becomes set. + +While QEMU's behavior does not match that of the hardware (and is therefore +at some level malfunctioning), there is additional behavior that is very +clearly incorrect: once SYST_CSR.ENABLE is set, not only will SYST_CVR +continue to return 0 (that is, the counter will not be enabled), +SYST_CSR.COUNTFLAG will become set when the *old* value of SYST_RVR ticks +have elapsed! This is wrong in both regards: if SYST_CVR is not counting +down, SYST_CSR.COUNTFLAG should never become set -- and it certainly +shouldn't match a value of SYST_RVR that has been overwritten in the +interim! + +In terms of fixing this, it's helpful to understand the +<a +href="https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg01217.html">context +around this change</a>: + +> Consider the following pseudo code to configure SYSTICK (The +> recommended programming sequence from "the definitive guide to the +> arm cortex-m3"): +> SYSTICK Reload Value Register = 0xffff +> SYSTICK Current Value Register = 0 +> SYSTICK Control and Status Register = 0x7 +> +> The pseudo code "SYSTICK Current Value Register = 0" leads to invoking +> systick_reload(). As a consequence, the systick.tick member is updated +> and the systick timer starts to count down when the ENABLE bit of +> SYSTICK Control and Status Register is cleared. +> +> The worst case is that: during the system initialization, the reset +> value of the SYSTICK Control and Status Register is 0x00000000. +> When the code "SYSTICK Current Value Register = 0" is executed, the +> systick.tick member is accumulated with "(s->systick.reload + 1) * +> systick_scale(s)". The systick_scale() gets the external_ref_clock +> scale because the CLKSOURCE bit of the SYSTICK Control and Status +> Register is cleared. This is the incorrect behavior because of the +> code "SYSTICK Control and Status Register = 0x7". Actually, we want +> the processor clock instead of the external reference clock. +> +> This incorrect behavior defers the generation of the first interrupt. +> +> The patch fixes the above-mentioned issue by setting the systick.tick +> member and modifying the systick timer only if the ENABLE bit of +> the SYSTICK Control and Status Register is set. +> +> In addition, the Cortex-M3 Devices Generic User Guide mentioned that +> "When ENABLE is set to 1, the counter loads the RELOAD value from the +> SYST RVR register and then counts down". This patch adheres to the +> statement of the user guide. + +This fix is simply incorrect -- or at the least, incomplete: +a write to SYST_CVR must clear any cached state +such that a subsequent write to SYST_CSR.ENABLE will correctly cause +a reload. Here is a diff that solves the problem without re-introducing +the behavior that the original fix was trying to correct: + +```diff +diff --git a/hw/timer/armv7m_systick.c b/hw/timer/armv7m_systick.c +index 74c58bcf24..3f7b267c2d 100644 +--- a/hw/timer/armv7m_systick.c ++++ b/hw/timer/armv7m_systick.c +@@ -181,6 +181,15 @@ static MemTxResult systick_write(void *opaque, hwaddr addr, + break; + case 0x8: /* SysTick Current Value. Writes reload the timer. */ + systick_reload(s, 1); ++ ++ if ((s->control & SYSTICK_ENABLE) == 0) { ++ /* ++ * If we're not enabled, explicitly clear our tick value to ++ * assure that when we do become enabled, we correctly reload. ++ */ ++ s->tick = 0; ++ } ++ + s->control &= ~SYSTICK_COUNTFLAG; + break; + default: +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1873335 b/results/classifier/gemma3:12b/peripherals/1873335 new file mode 100644 index 000000000..2ea98c38c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1873335 @@ -0,0 +1,6 @@ + +Dos Keypad is not working for numbers - numlock is not working + +Hello, +i tried to use Qemu 4.2 for Dos, but there is problem what in Dos is not possible turn on Numlock for input numbers, so games need it.. Numlock only working as arrow keys. + I tested bough Windows and Linux builds. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1873337 b/results/classifier/gemma3:12b/peripherals/1873337 new file mode 100644 index 000000000..b8063141b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1873337 @@ -0,0 +1,12 @@ + +Arrow keys press is double in some programs in Dos + +Hello, +im trying to use Qemu for Dos machines. + + But there is problem with some programs that arrow key press is double in some problems. As advanced Filemanagers - Dos Navigator or File Wizard, same Scandisk. + +There is gif: +https://www.vogons.org/download/file.php?id=77141&mode=view + + Its blocking to use such problem, unless you use Numlock key for it, but im used 25+ years to arrow keys and its bug.. I guess that it would mess with some games too. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1873344 b/results/classifier/gemma3:12b/peripherals/1873344 new file mode 100644 index 000000000..a183ff2e2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1873344 @@ -0,0 +1,13 @@ + +KVM Windows 98 sound card passthrough is not working for DOS programs.. + +Hello, +im trying to passthrough PCI soundcards into Qemu Windows 98 machine - i tried Yamaha 724/744 and Aunreal Vortex 1, for Windows 98 its working fine, but for Windows 98 dosbox mode its at the best half - working - FM (music) only or nothing with detected by games sound setups. + All there cards are using SB emulation devices. + + When i try to boot to pure DOS, without Windows 98, even music is not working with pass through, only sound which i was able to heard its form Yamaha Setup utility test - Native 16bit sound, aby other test, games setup etc.. are able to dettect sound cards at all. + Im pretty sure that drivers are setup correctly, because im using same setup on other physical machine, when its working. My suspect is missing or broken Qemu MB DMA channels emulation.. Because its is need to make DOS sound working. + + Im using pass through because, SB16 emulation in Qemu is incomplete and for Windows 98 dos box, problem is same as with physical cards. Same with AC97 emulation and its Win95 drivers, which have SB emulation device fallback.. + +Qemu 2.11 + 4.2 Linux Mint 19.3. MB Gigabyte Z170. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1873769 b/results/classifier/gemma3:12b/peripherals/1873769 new file mode 100644 index 000000000..60b8c2119 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1873769 @@ -0,0 +1,12 @@ + +SB16 audio playback freezes emulation in Windows 95 guest + +- QEMU 4.2.93 (v5.0.0-rc3) built from latest git master 20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and launched on same Windows 10 + +- Launched using "qemu-system-i386.exe -drive format=raw,file=hdd-2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom Windows_95.iso -boot c" + +- I have attached video screen capture of the issue + +--- + +I decided to make my first ever QEMU build after encountering the dsound issues using the latest 4.2.0 binary from https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound playback is working correctly, however the whole Windows 95 UI freezes while sound is playing. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1874073 b/results/classifier/gemma3:12b/peripherals/1874073 new file mode 100644 index 000000000..b7561d029 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1874073 @@ -0,0 +1,15 @@ + +openrisc_sim.c:87:42: error: 'cpu_irqs[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized] + +I see the warning since gcc10: + +static void openrisc_sim_init(MachineState *machine): +... + qemu_irq *cpu_irqs[2]; +... + + + serial_mm_init(get_system_memory(), 0x90000000, 0, serial_irq, + 115200, serial_hd(0), DEVICE_NATIVE_ENDIAN); + +I would initialize cpu_irqs[2] with {}. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1874904 b/results/classifier/gemma3:12b/peripherals/1874904 new file mode 100644 index 000000000..95d87c83a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1874904 @@ -0,0 +1,12 @@ + +qemu windows with gtk and french keypad not working as expected + +When I use qemu on Windows 10 with a French AZERTY keypad with the correct options the emulated system keypad still QWERTY. If we use sdl it works fine the emulated keypad is AZERTY. + +Example of command with ubuntu live cd: +-> qemu-system-x86_64.exe -m 4G ubuntu-18.04.4-desktop-amd64.iso -display gtk -k fr + +NOTES: + - Using the same command on Linux works fine. The emulated keypad is AZERTY. + +Qemu version : 4.2.0 on Windows 10 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1875 b/results/classifier/gemma3:12b/peripherals/1875 new file mode 100644 index 000000000..cec7d8bf1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1875 @@ -0,0 +1,10 @@ + +qemu-system-x86_64: warning: no scancode found for keysym 65483 +Description of problem: +qemu-system-x86_64: warning: no scancode found for keysym 65483 + +I'm hoping this is something that could easily be added to qemu, rather than a limitation of windows: + +I want to bind F14 to an arbitrary key, in this case `keycode 148 = XF86Calculator`, but it's not happening, and qemu is giving the error: `qemu-system-x86_64: warning: no scancode found for keysym 65483` + +`xmodmap -e "keycode 148 = F14 F14 F14 F14 F14"` Executes with no error, and xev correctly shows as F14 pressed/released, but a windows 10 VM started afterwards cannot recognise this bind. diff --git a/results/classifier/gemma3:12b/peripherals/1876187 b/results/classifier/gemma3:12b/peripherals/1876187 new file mode 100644 index 000000000..66748ae31 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1876187 @@ -0,0 +1,8 @@ + +qemu-system-arm freezes when using SystickTimer on netduinoplus2 + +git commit 27c94566379069fb8930bb1433dcffbf7df3203d + +The global variable system_clock_scale used in hw/timer/armv7m_systick.c is never set on the netduinoplus2 platform, it stays initialized as zero. Using the timer with the clock source as cpu clock leads to an infinit loop because systick_timer->tick always stays the same. + +To reproduce use to CMSIS function SysTick_Config(uint32_t ticks) to setup the timer. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1878054 b/results/classifier/gemma3:12b/peripherals/1878054 new file mode 100644 index 000000000..80b2b8fa6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1878054 @@ -0,0 +1,40 @@ + +Hang with high CPU usage in sdhci_data_transfer + +Hello, +While fuzzing, I found an input that causes QEMU to hang with 100% CPU usage. +I have waited several minutes, and QEMU is still unresponsive. Using gdb, It +appears that it is stuck in an sdhci_data_transfer: + +#0 memory_region_access_valid (mr=<optimized out>, addr=0x10284920, size=<optimized out>, is_write=0xff, attrs=...) at /home/alxndr/Development/qemu/memory.c:1378 +#1 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1463 +#2 flatview_write_continue (fv=<optimized out>, addr=0x10284920, attrs=..., ptr=<optimized out>, len=0xb7, addr1=0x5555582798e0, l=<optimized out>, mr=0x5555582798e0 <io_mem_unassigned>) at /home/alxndr/Development/qemu/exec.c:3137 +#3 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +#4 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#5 address_space_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, attrs=..., attrs@entry=..., buf=0xaaaab04f325, len=0x4, is_write=0xb8, is_write@entry=0x1) at +/home/alxndr/Development/qemu/exec.c:3278 +#6 dma_memory_rw_relaxed (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:87 +#7 dma_memory_rw (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:110 +#8 dma_memory_write (as=0x5555572509ac <unassigned_mem_ops+44>, addr=0x5555582798e0, buf=0xaaaab04f325, len=0x4) at /home/alxndr/Development/qemu/include/sysemu/dma.h:122 +#9 sdhci_sdma_transfer_multi_blocks (s=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:618 +#10 sdhci_data_transfer (opaque=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:891 +#11 sdhci_send_command (s=0x61e000021080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:364 +#12 sdhci_write (opaque=<optimized out>, offset=0xc, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:1158 +#13 memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at +/home/alxndr/Development/qemu/memory.c:483 +#14 access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x61e0000219f0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#15 memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x1ffe0ff, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#16 flatview_write_continue (fv=<optimized out>, addr=0xe106800c, attrs=..., ptr=<optimized out>, len=0xff3, addr1=0x5555582798e0, l=<optimized out>, mr=0x61e0000219f0) at /home/alxndr/Development/qemu/exec.c:3137 +#17 flatview_write (fv=0x606000045da0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /home/alxndr/Development/qemu/exec.c:3177 +#18 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=0xaaaab04f325, buf@entry=0x62100008ad00, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#19 qtest_process_command (chr=<optimized out>, chr@entry=0x55555827c040 <qtest_chr>, words=<optimized out>) at /home/alxndr/Development/qemu/qtest.c:567 +#20 qtest_process_inbuf (chr=0x55555827c040 <qtest_chr>, inbuf=0x61900000f640) at /home/alxndr/Development/qemu/qtest.c:710 + + +I am attaching the qtest commands for reproducing it. +I can reproduce it in a qemu 5.0 build using: + +qemu-system-i386 -M pc-q35-5.0 -qtest stdio -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic -serial none -monitor none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1878323 b/results/classifier/gemma3:12b/peripherals/1878323 new file mode 100644 index 000000000..32d5bfd81 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1878323 @@ -0,0 +1,61 @@ + +Assertion-failure in usb_detach + +Hello, +While fuzzing, I found an input that triggers an assertion-failure in usb_detach + +/home/alxndr/Development/qemu/hw/usb/core.c:69: void usb_detach(USBPort *): Assertion `dev->state != USB_STATE_NOTATTACHED' failed. +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557fd2040 <str> "dev->state != USB_STATE_NOTATTACHED", file=0x555557fd1ec0 <str> "/home/alxndr/Development/qemu/hw/usb/core.c", line=0x45, function=0x555557fd2000 <__PRETTY_FUNCTION__.usb_detach> "void usb_detach(USBPort *)") at assert.c:101 +#4 0x000055555723f0ce in usb_detach (port=0x62100002df30) at /home/alxndr/Development/qemu/hw/usb/core.c:69 +#5 0x00005555572a05a4 in ehci_reset (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:863 +#6 0x00005555572bf941 in ehci_opreg_write (ptr=0x62100002d9f0, addr=0x0, val=0xbebebebe, size=0x4) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1032 +#7 0x00005555564938b5 in memory_region_write_accessor (mr=0x62100002dcb0, addr=0x0, value=0x7fffffffaad0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#8 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffffaad0, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62100002dcb0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#9 0x0000555556491df6 in memory_region_dispatch_write (mr=0x62100002dcb0, addr=0x0, data=0xbebebebe, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#10 0x00005555562cbbf4 in flatview_write_continue (fv=0x60600003e600, addr=0xe0000020, attrs=..., ptr=0x625000260000, len=0xfe0, addr1=0x0, l=0x4, mr=0x62100002dcb0) at /home/alxndr/Development/qemu/exec.c:3137 +#11 0x00005555562bbad9 in flatview_write (fv=0x60600003e600, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3177 +#12 0x00005555562bb609 in address_space_write (as=0x62100002d328, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3268 +#13 0x00005555562c06a6 in address_space_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, is_write=0x1, access_len=0x1000) at /home/alxndr/Development/qemu/exec.c:3592 +#14 0x0000555557257d73 in dma_memory_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, dir=DMA_DIRECTION_FROM_DEVICE, access_len=0x1000) at /home/alxndr/Development/qemu/include/sysemu/dma.h:145 +#15 0x0000555557257c57 in usb_packet_unmap (p=0x6110000484c0, sgl=0x611000048548) at /home/alxndr/Development/qemu/hw/usb/libhw.c:65 +#16 0x00005555572a5953 in ehci_free_packet (p=0x611000048480) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:536 +#17 0x00005555572a4ed4 in ehci_cancel_queue (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:584 +#18 0x00005555572a49ab in ehci_free_queue (q=0x60d000004f10, warn=0x0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:611 +#19 0x00005555572b102d in ehci_queues_rip_device (ehci=0x62100002d9f0, dev=0x623000001d00, async=0x1) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:674 +#20 0x00005555572af7a3 in ehci_detach (port=0x62100002df78) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:733 +#21 0x000055555723f15c in usb_detach (port=0x62100002df78) at /home/alxndr/Development/qemu/hw/usb/core.c:70 +#22 0x00005555572a05a4 in ehci_reset (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:863 +#23 0x00005555572bf941 in ehci_opreg_write (ptr=0x62100002d9f0, addr=0x0, val=0xbebebebe, size=0x4) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1032 +#24 0x00005555564938b5 in memory_region_write_accessor (mr=0x62100002dcb0, addr=0x0, value=0x7fffffffc410, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#25 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffffc410, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62100002dcb0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#26 0x0000555556491df6 in memory_region_dispatch_write (mr=0x62100002dcb0, addr=0x0, data=0xbebebebe, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#27 0x00005555562cbbf4 in flatview_write_continue (fv=0x60600003e600, addr=0xe0000020, attrs=..., ptr=0x625000260000, len=0xfe0, addr1=0x0, l=0x4, mr=0x62100002dcb0) at /home/alxndr/Development/qemu/exec.c:3137 +#28 0x00005555562bbad9 in flatview_write (fv=0x60600003e600, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3177 +#29 0x00005555562bb609 in address_space_write (as=0x62100002d328, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3268 +#30 0x00005555562c06a6 in address_space_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, is_write=0x1, access_len=0x1000) at /home/alxndr/Development/qemu/exec.c:3592 +#31 0x0000555557257d73 in dma_memory_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, dir=DMA_DIRECTION_FROM_DEVICE, access_len=0x1000) at /home/alxndr/Development/qemu/include/sysemu/dma.h:145 +#32 0x0000555557257c57 in usb_packet_unmap (p=0x6110000484c0, sgl=0x611000048548) at /home/alxndr/Development/qemu/hw/usb/libhw.c:65 +#33 0x00005555572aa87e in ehci_execute_complete (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1324 +#34 0x00005555572a7b8c in ehci_state_executing (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1973 +#35 0x00005555572b3685 in ehci_advance_state (ehci=0x62100002d9f0, async=0x1) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2094 +#36 0x00005555572b2db9 in ehci_advance_async_state (ehci=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2152 +#37 0x00005555572a29c3 in ehci_work_bh (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2320 +#38 0x0000555557bfba60 in aio_bh_call (bh=0x60400001cd90) at /home/alxndr/Development/qemu/util/async.c:136 + + +I can reproduce it in qemu 5.0 using the commands in the attachment: + +qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \ +-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,multifunction=on,masterbus=ich9-ehci-1.0,firstport=0 \ +-device ich9-usb-uhci2,bus=pcie.0,addr=1d.1,multifunction=on,masterbus=ich9-ehci-1.0,firstport=2 \ +-device ich9-usb-uhci3,bus=pcie.0,addr=1d.2,multifunction=on,masterbus=ich9-ehci-1.0,firstport=4 \ +-drive if=none,id=usbcdrom,media=cdrom \ +-device usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 \ +-device usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom \ +-display none -nodefaults -nographic < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1878641 b/results/classifier/gemma3:12b/peripherals/1878641 new file mode 100644 index 000000000..03acab8ed --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1878641 @@ -0,0 +1,46 @@ + +Abort() in mch_update_pciexbar + +Hello, +I found an input which triggers an abort() in mch_update_pciexbar: + +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x000055555705c7ae in mch_update_pciexbar (mch=0x629000005920) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:324 +#3 0x000055555705bb6a in mch_write_config (d=0x629000005920, address=0x60, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci-host/q35.c:480 +#4 0x00005555570954fb in pci_host_config_write_common (pci_dev=0x629000005920, addr=0x60, limit=0x100, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:81 +#5 0x000055555709606e in pci_data_write (s=0x61d000096080, addr=0xf2000060, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:118 +#6 0x00005555570967d0 in pci_host_data_write (opaque=0x629000005200, addr=0x0, val=0x8400056e, len=0x4) at /home/alxndr/Development/qemu/hw/pci/pci_host.c:165 +#7 0x00005555564938b5 in memory_region_write_accessor (mr=0x629000005610, addr=0x0, value=0x7fffffff9c70, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#8 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffff9c70, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x629000005610, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#9 0x0000555556491df6 in memory_region_dispatch_write (mr=0x629000005610, addr=0x0, data=0x8400056e, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#10 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033b00, addr=0xcfc, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x0, l=0x4, mr=0x629000005610) at /home/alxndr/Development/qemu/exec.c:3137 +#11 0x00005555562bbad9 in flatview_write (fv=0x606000033b00, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#12 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0xcfc, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#13 0x0000555556478c0a in cpu_outl (addr=0xcfc, val=0x8400056e) at /home/alxndr/Development/qemu/ioport.c:80 +#14 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ebf0) at /home/alxndr/Development/qemu/qtest.c:396 +#15 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#16 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", size=0xd2) at /home/alxndr/Development/qemu/qtest.c:722 +#17 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:183 +#18 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0xf2000060\noutl 0xcfc 0x8400056e\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n\377\377\377\177", len=0xd2) at /home/alxndr/Development/qemu/chardev/char.c:195 +#19 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#20 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#21 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#22 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#23 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#24 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#25 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#26 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + + +I can reproduce this in qemu 5.0 built using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0xf2000060 +outl 0xcfc 0x8400056e +EOF + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1878642 b/results/classifier/gemma3:12b/peripherals/1878642 new file mode 100644 index 000000000..81eb1697d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1878642 @@ -0,0 +1,52 @@ + +Assertion failure in pci_bus_get_irq_level + +Hello, +I found an input which triggers an assertion failure in pci_bus_get_irq_level: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/pci/pci.c:268: int pci_bus_get_irq_level(PCIBus *, int): Assertion `irq_num < bus->nirq' failed. +Aborted +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff685742f in __assert_fail_base (fmt=0x7ffff69bdb48 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x555557f9bca0 <str> "irq_num < bus->nirq", file=0x555557f9bbe0 <str> "/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=<optimized out>) at assert.c:92 +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557f9bca0 <str> "irq_num < bus->nirq", file=0x555557f9bbe0 <str> "/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=0x555557f9bc40 <__PRETTY_FUNCTION__.pci_bus_get_irq_level> "int pci_bus_get_irq_level(PCIBus *, int)") at assert.c:101 +#4 0x0000555557060c34 in pci_bus_get_irq_level (bus=0x61d000096080, irq_num=0xef) at /home/alxndr/Development/qemu/hw/pci/pci.c:268 +#5 0x0000555556657391 in ich9_lpc_update_apic (lpc=0x62a000006200, gsi=0xff) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:249 +#6 0x0000555556658ea7 in ich9_set_sci (opaque=0x62a000006200, irq_num=0x0, level=0x1) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:354 +#7 0x0000555556ccefc6 in qemu_set_irq (irq=0x60600002af80, level=0x1) at /home/alxndr/Development/qemu/hw/core/irq.c:44 +#8 0x0000555556bc06fd in acpi_update_sci (regs=0x62a000006c80, irq=0x60600002af80) at /home/alxndr/Development/qemu/hw/acpi/core.c:723 +#9 0x0000555556bccb08 in ich9_pm_update_sci_fn (regs=0x62a000006c80) at /home/alxndr/Development/qemu/hw/acpi/ich9.c:56 +#10 0x0000555556bc10ee in acpi_pm_evt_write (opaque=0x62a000006c80, addr=0x2, val=0x2049, width=0x2) at /home/alxndr/Development/qemu/hw/acpi/core.c:456 +#11 0x00005555564938b5 in memory_region_write_accessor (mr=0x62a000006db0, addr=0x2, value=0x7fffffff9c70, size=0x2, shift=0x0, mask=0xffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#12 0x000055555649328a in access_with_adjusted_size (addr=0x2, value=0x7fffffff9c70, size=0x2, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62a000006db0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#13 0x0000555556491df6 in memory_region_dispatch_write (mr=0x62a000006db0, addr=0x2, data=0x2049, op=MO_16, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#14 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033fe0, addr=0x5d02, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x2, l=0x2, mr=0x62a000006db0) at /home/alxndr/Development/qemu/exec.c:3137 +#15 0x00005555562bbad9 in flatview_write (fv=0x606000033fe0, addr=0x5d02, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#16 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0x5d02, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#17 0x0000555556478c0a in cpu_outl (addr=0x5d02, val=0xedf82049) at /home/alxndr/Development/qemu/ioport.c:80 +#18 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ef20) at /home/alxndr/Development/qemu/qtest.c:396 +#19 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#20 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", size=0xe9) at /home/alxndr/Development/qemu/qtest.c:722 +#21 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at /home/alxndr/Development/qemu/chardev/char.c:183 +#22 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at /home/alxndr/Development/qemu/chardev/char.c:195 +#23 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#24 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#25 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#26 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#27 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#28 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#29 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#30 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x8400f841 +outl 0xcfc 0xebed205d +outl 0x5d02 0xedf82049 +EOF + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1878645 b/results/classifier/gemma3:12b/peripherals/1878645 new file mode 100644 index 000000000..6197d581e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1878645 @@ -0,0 +1,52 @@ + +null-ptr dereference in ich9_apm_ctrl_changed + +Hello, +While fuzzing, I found an input which triggers a NULL pointer dereference in +tcg_handle_interrupt. It seems the culprint is a "cpu" pointer - maybe this bug +is specific to QTest? + +==23862==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000b4 (pc 0x55b9dc7c9dce bp 0x7ffc346a0900 sp 0x7ffc346a0880 T0) +==23862==The signal is caused by a READ memory access. +==23862==Hint: address points to the zero page. + #0 0x55b9dc7c9dce in tcg_handle_interrupt /home/alxndr/Development/qemu/accel/tcg/tcg-all.c:57:21 + #1 0x55b9dc904799 in cpu_interrupt /home/alxndr/Development/qemu/include/hw/core/cpu.h:872:5 + #2 0x55b9dc9085e8 in ich9_apm_ctrl_changed /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:442:13 + #3 0x55b9dd19cdc8 in apm_ioport_writeb /home/alxndr/Development/qemu/hw/isa/apm.c:50:13 + #4 0x55b9dc73f8b4 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 + #5 0x55b9dc73f289 in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 + #6 0x55b9dc73ddf5 in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + #7 0x55b9dc577bf3 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 + #8 0x55b9dc567ad8 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 + #9 0x55b9dc567608 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 + #10 0x55b9dc723fe7 in cpu_outb /home/alxndr/Development/qemu/ioport.c:60:5 + #11 0x55b9dc72d3c0 in qtest_process_command /home/alxndr/Development/qemu/qtest.c:392:13 + #12 0x55b9dc72b186 in qtest_process_inbuf /home/alxndr/Development/qemu/qtest.c:710:9 + #13 0x55b9dc72a8b3 in qtest_read /home/alxndr/Development/qemu/qtest.c:722:5 + #14 0x55b9ddc6e60b in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:183:9 + #15 0x55b9ddc6e75a in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:195:9 + #16 0x55b9ddc77979 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9 + #17 0x55b9ddcff0e9 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12 + #18 0x7f7161eac897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #19 0x55b9ddebcb84 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #20 0x55b9ddebb57d in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #21 0x55b9ddebb176 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #22 0x55b9dcb4bd1d in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #23 0x55b9ddd1629c in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #24 0x7f7160a5ce0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #25 0x55b9dc49c819 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xc9c819) + + +I can reproduce this in qemu 5.0 built with AddressSanitizer using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x8400f841 +outl 0xcfc 0xaa215d6d +outl 0x6d30 0x2ef8ffbe +outb 0xb2 0x20 +EOF + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1878651 b/results/classifier/gemma3:12b/peripherals/1878651 new file mode 100644 index 000000000..2758f3495 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1878651 @@ -0,0 +1,68 @@ + +Assertion failure in e1000e_write_to_rx_buffers + +Hello, +While fuzzing, I found an input which triggers an assertion failure in e1000e_write_to_rx_buffers: +/home/alxndr/Development/qemu/hw/net/e1000e_core.c:1424: void e1000e_write_to_rx_buffers(E1000ECore *, hwaddr (*)[4], e1000e_ba_state *, const char *, dma_addr_t): Assertion `bastate->cur_idx < MAX_PS_BUFFERS' failed. +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff685742f in __assert_fail_base (fmt=0x7ffff69bdb48 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x555557f691e0 <str> "bastate->cur_idx < MAX_PS_BUFFERS", file=0x555557f5a080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x590, function=<optimized out>) at assert.c:92 +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557f691e0 <str> "bastate->cur_idx < MAX_PS_BUFFERS", file=0x555557f5a080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x590, function=0x555557f69240 <__PRETTY_FUNCTION__.e1000e_write_to_rx_buffers> "void e1000e_write_to_rx_buffers(E1000ECore *, hwaddr (*)[4], e1000e_ba_state *, const char *, dma_addr_t)") at assert.c:101 +#4 0x0000555556f8fbcd in e1000e_write_to_rx_buffers (core=0x7fffee07c4e0, ba=0x7fffffff8860, bastate=0x7fffffff88a0, data=0x7fffe61b8021 "", data_len=0x2000) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1424 +#5 0x0000555556f82f14 in e1000e_write_packet_to_guest (core=0x7fffee07c4e0, pkt=0x61100004b900, rxr=0x7fffffff8d10, rss_info=0x7fffffff8d30) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582 +#6 0x0000555556f80960 in e1000e_receive_iov (core=0x7fffee07c4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#7 0x0000555556f7d457 in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#8 0x0000555556f64738 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#9 0x0000555556f63f0e in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#10 0x0000555556f650e5 in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#11 0x0000555556fb026a in e1000e_tx_pkt_send (core=0x7fffee07c4e0, tx=0x7fffee09c748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#12 0x0000555556faebf6 in e1000e_process_tx_desc (core=0x7fffee07c4e0, tx=0x7fffee09c748, dp=0x7fffffff9520, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#13 0x0000555556fadfa8 in e1000e_start_xmit (core=0x7fffee07c4e0, txr=0x7fffffff9720) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#14 0x0000555556fa308b in e1000e_set_tdt (core=0x7fffee07c4e0, index=0xe06, val=0x563) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#15 0x0000555556f84d7e in e1000e_core_write (core=0x7fffee07c4e0, addr=0x438, val=0x563, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#16 0x0000555556f79497 in e1000e_mmio_write (opaque=0x7fffee079800, addr=0x438, val=0x563, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#17 0x00005555564938b5 in memory_region_write_accessor (mr=0x7fffee07c110, addr=0x438, value=0x7fffffff9d90, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#18 0x000055555649328a in access_with_adjusted_size (addr=0x438, value=0x7fffffff9d90, size=0x2, access_size_min=0x4, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x7fffee07c110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#19 0x0000555556491df6 in memory_region_dispatch_write (mr=0x7fffee07c110, addr=0x438, data=0x563, op=MO_16, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#20 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000037820, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x2, addr1=0x438, l=0x2, mr=0x7fffee07c110) at /home/alxndr/Development/qemu/exec.c:3137 +#21 0x00005555562bbad9 in flatview_write (fv=0x606000037820, addr=0xe1020023, attrs=..., buf=0x61900009ba80, len=0x417) at /home/alxndr/Development/qemu/exec.c:3177 +#22 0x00005555562bb609 in address_space_write (as=0x6080000027a0, addr=0xe1020023, attrs=..., buf=0x61900009ba80, len=0x417) at /home/alxndr/Development/qemu/exec.c:3268 +#23 0x0000555556488c07 in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60400001e210) at /home/alxndr/Development/qemu/qtest.c:567 +#24 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#25 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffc9e0 "e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305\n-M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic\n002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055\360U", size=0x1f2) at /home/alxndr/Development/qemu/qtest.c:722 +#26 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001d50, buf=0x7fffffffc9e0 "e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305\n-M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic\n002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055\360U", len=0x1f2) at /home/alxndr/Development/qemu/chardev/char.c:183 +#27 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001d50, buf=0x7fffffffc9e0 "e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305\n-M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic\n002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055\360U", len=0x1f2) at /home/alxndr/Development/qemu/chardev/char.c:195 +#28 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001d50) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#29 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002b780, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001d50) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#30 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#31 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#32 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x39c63cc8) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#33 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#34 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#35 0x0000555557a6a29d in main (argc=0x13, argv=0x7fffffffe0e8, envp=0x7fffffffe188) at /home/alxndr/Development/qemu/softmmu/main.c:49 + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1020618 0x14 0x0000d0ff2d05575f215e1b0000000000d0ff2d05 +write 0x27 0x800c 0x08004500feffffff00007b06f +write 0x1b8006 0x8001 0x2f0 +write 0xe1020023 0x417 0x0002e10000000006ffcf055e2d1b0002e10000000006ffd1055e2d1b0002e10000000006ffd3055e2d1b0002e10000000006ffd5055e2d1b0002e10000000006ffd7055e2d1b0002e10000000006ffd9055e2d1b0002e10000000006ffdb055e2d1b0002e10000000006ffdd055e2d1b0002e10000000006ffdf055e2d1b0002e10000000006ffe1055e2d1b0002e10000000006ffe3055e2d1b0002e10000000006ffe5055e2d1b0002e10000000006ffe7055e2d1b0002e10000000006ffe9055e2d1b0002e10000000006ffeb055e2d1b0002e10000000006ffed055e2d1b0002e10000000006ffef055e2d1b0002e10000000006fff1055e2d1b0002e10000000006fff3055e2d1b0002e10000000006fff5055e2d1b0002e10000000006fff7055e2d1b0002e10000000006fff9055e2d1b0002e10000000006fffb055e2d1b0002e10000000006fffd055e2d1b0002e10000000006ffff055e2d1b0002e10000000006ff01055e2d1b0002e10000000006ff03055e2d1b0002e10000000006ff05055e2d1b0002e10000000006ff07055e2d1b0002e10000000006ff09055e2d1b0002e10000000006ff0b055e2d1b0002e10000000006ff0d055e2d1b0002e10000000006ff0f055e2d1b0002e10000000006ff11055e2d1b0002e10000000006ff13055e2d1b0002e10000000006ff15055e2d1b0002e10000000006ff17055e2d1b0002e10000000006ff19055e2d1b0002e10000000006ff1b055e2d1b0002e10000000006ff1d055e2d1b0002e10000000006ff1f055e2d1b0002e10000000006ff21055e2d1b0002e10000000006ff23055e2d1b0002e10000000006ff25055e2d1b0002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305 +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1880066 b/results/classifier/gemma3:12b/peripherals/1880066 new file mode 100644 index 000000000..9eeef9c31 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1880066 @@ -0,0 +1,70 @@ + +Microphone input dies in guest when switching evdev input + +justin@justin-3900x:~$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal + + + +justin@justin-3900x:~$ apt list --installed | egrep '*qemu*|*kvm*' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +ipxe-qemu-256k-compat-efi-roms/focal,focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/focal,focal,now 1.0.0+git-20190109.133f4c4-0ubuntu3 all [installed,automatic] +libvirt-daemon-driver-qemu/focal,now 6.0.0-0ubuntu8 amd64 [installed,automatic] +qemu-block-extra/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-kvm/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +qemu-system-common/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-system-data/focal-updates,focal-updates,focal-security,focal-security,now 1:4.2-3ubuntu6.1 all [installed,automatic] +qemu-system-gui/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu-system-x86/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +qemu-utils/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed,automatic] +qemu/focal-updates,focal-security,now 1:4.2-3ubuntu6.1 amd64 [installed] +justin@justin-3900x:~$ + +This did not happen in Eoan (qemu 4.0.0). I was able to switch in/out of a VM with my audio coming through fine. I enabled Eoan in my sources.list, downgraded all my qemu packages, and the issue was resolved. + +This happens on the latest Windows 10 guest when a sound device is listening for the microphone. + +/var/log/libvirt/qemu/<vmname>.log spews this error out when I switch with evdev (which is just the keyboard and mouse, the audio is passed through I assume spice): + + +audio: live=228193 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=228675 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=228675 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=229156 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=229156 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=229638 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=229638 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=230119 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=230119 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=230600 sw->hw->conv_buf->size=1920 +A bug was just triggered in audio_pcm_hw_get_live_in +Context: +audio: live=230600 hw->conv_buf->size=1920 +A bug was just triggered in audio_get_avail +Context: +audio: live=231081 sw->hw->conv_buf->size=1920 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1880424 b/results/classifier/gemma3:12b/peripherals/1880424 new file mode 100644 index 000000000..7aa5c317f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1880424 @@ -0,0 +1,41 @@ + +I/O write make imx_epit_reset() crash + +libFuzzer found: + +qemu-fuzz-arm: hw/core/ptimer.c:377: void ptimer_transaction_begin(ptimer_state *): Assertion `!s->in_transaction' failed. +==6041== ERROR: libFuzzer: deadly signal + #8 0x7fcaba320565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x563b46f91637 in ptimer_transaction_begin (qemu-fuzz-arm+0x1af1637) + #10 0x563b476cc4c6 in imx_epit_reset (qemu-fuzz-arm+0x222c4c6) + #11 0x563b476cd004 in imx_epit_write (qemu-fuzz-arm+0x222d004) + #12 0x563b46582377 in memory_region_write_accessor (qemu-fuzz-arm+0x10e2377) + #13 0x563b46581ee3 in access_with_adjusted_size (qemu-fuzz-arm+0x10e1ee3) + #14 0x563b46580a83 in memory_region_dispatch_write (qemu-fuzz-arm+0x10e0a83) + #15 0x563b463c5022 in flatview_write_continue (qemu-fuzz-arm+0xf25022) + #16 0x563b463b4ea2 in flatview_write (qemu-fuzz-arm+0xf14ea2) + #17 0x563b463b49d4 in address_space_write (qemu-fuzz-arm+0xf149d4) + +Reproducer: + +qemu-system-arm -M kzm -display none -S -qtest stdio << 'EOF' +writel 0x53f94000 0x110000 +EOF + +qemu-system-arm: hw/core/ptimer.c:377: ptimer_transaction_begin: Assertion `!s->in_transaction' failed. +Aborted (core dumped) + +(gdb) bt +#1 0x00007f4aa4daa895 in abort () at /lib64/libc.so.6 +#2 0x00007f4aa4daa769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f4aa4db8566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x000055ee85400164 in ptimer_transaction_begin (s=0x55ee873bc4c0) at hw/core/ptimer.c:377 +#5 0x000055ee855c7936 in imx_epit_reset (dev=0x55ee871725c0) at hw/timer/imx_epit.c:111 +#6 0x000055ee855c7d1b in imx_epit_write (opaque=0x55ee871725c0, offset=0, value=1114112, size=4) at hw/timer/imx_epit.c:209 +#7 0x000055ee8513db85 in memory_region_write_accessor (mr=0x55ee871728f0, addr=0, value=0x7fff3012d6f8, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:483 +#8 0x000055ee8513dd96 in access_with_adjusted_size (addr=0, value=0x7fff3012d6f8, size=4, access_size_min=1, access_size_max=4, access_fn= + 0x55ee8513daa2 <memory_region_write_accessor>, mr=0x55ee871728f0, attrs=...) at memory.c:545 +#9 0x000055ee85140cbd in memory_region_dispatch_write (mr=0x55ee871728f0, addr=0, data=1114112, op=MO_32, attrs=...) at memory.c:1477 +#10 0x000055ee850deba5 in flatview_write_continue (fv=0x55ee87181bd0, addr=1408843776, attrs=..., ptr=0x7fff3012d900, len=4, addr1=0, l=4, mr=0x55ee871728f0) at exec.c:3147 +#11 0x000055ee850decf3 in flatview_write (fv=0x55ee87181bd0, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3190 +#12 0x000055ee850df05d in address_space_write (as=0x55ee8730a560, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3289 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1880763 b/results/classifier/gemma3:12b/peripherals/1880763 new file mode 100644 index 000000000..396941dae --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1880763 @@ -0,0 +1,7 @@ + +Missing page crossing check in use_goto_tb() for rx target + +Currently the rx target doesn't have the page crossing check in its +use_goto_tb() function. +This is a required feature for stable system mode emulations that all +other targets implement. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1883739 b/results/classifier/gemma3:12b/peripherals/1883739 new file mode 100644 index 000000000..11f1cbc3a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1883739 @@ -0,0 +1,21 @@ + +ide_dma_cb: Assertion `prep_size >= 0 && prep_size <= n * 512' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -drive id=disk,file=hda.img,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + +To create disk image run: +``` +dd if=/dev/zero of=hda.img bs=1024 count=1024 +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1884017 b/results/classifier/gemma3:12b/peripherals/1884017 new file mode 100644 index 000000000..6bdf41260 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1884017 @@ -0,0 +1,16 @@ + +Intermittently erratic mouse under Windows 95 + +The mouse works fine maybe 75-80% of the time, but intermittently (every 20-30 seconds or so), moving the mouse will cause the pointer to fly around the screen at high speed, usually colliding with the edges, and much more problematically, click all the mouse buttons at random, even if you are not clicking. This causes random objects on the screen to be clicked and dragged around, rendering the system generally unusable. + +I don't know if this is related to #1785485 - it happens even if you never use the scroll wheel. + +qemu version: 5.0.0 (openSUSE Tumbleweed) + +Launch command line: qemu-system-i386 -hda win95.qcow2 -cpu pentium2 -m 16 -vga cirrus -soundhw sb16 -nic user,model=pcnet -rtc base=localtime + +OS version: Windows 95 4.00.950 C + +I have made the disk image available here: https://home.gloveraoki.me/share/win95.qcow2.lz + +Setup notes: In order to make Windows 95 detect the system devices correctly, after first install you must change the driver for "Plug and Play BIOS" to "PCI bus". I have already done this in the above image. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1884507 b/results/classifier/gemma3:12b/peripherals/1884507 new file mode 100644 index 000000000..20acca682 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1884507 @@ -0,0 +1,7 @@ + +'none' machine should use 'none' display option + +As the 'none' machine doesn't have any peripheral (except CPU cores) +it is pointless to start a display. + +'-M none' should imply '-display none'. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1884684 b/results/classifier/gemma3:12b/peripherals/1884684 new file mode 100644 index 000000000..f46c1eb87 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1884684 @@ -0,0 +1,40 @@ + +QEMU 5.0: Guest VM hangs/freeze when unplugging USB device + +Setup: + +Host: Debian/SID, Kernel 5.6, QEMU 5.0 +Guest: Windows 10 VM with PCI and USB device passthrough. + +Problem: Guest VM suddenly hangs when pulling USB device out from the Host. + +Observations: + - Issue appears to be related to QEMU 5.0 + - It started after an upgrade to QEMU 5.0. + - Downgrading only QEMU on multiple systems fixes the issue. + + - Issue is very reproducible. + - Most of the time within a few attempts of pulling/reconnecting the device. + - Issue happens with multiple devices (I did try standard HID devices, a webcam and an x-ray sensor). + + - Guest just hangs. + - Display output remains on last frame shown. + - Ping to Guest immediately stops working. + - Logs in the Guest stop logging immediately. + + - Host is fine and thinks the Guest is fine. + - Guest continues to show as running in "virsh list". + - No suspicious entries in the QEMU logs. + - No suspicious entries in Host syslogs/messages. + - Host can can kill guest "virsh destroy" and respawn fine. + + - Issue seems widespread. + - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 for both Windows and Linux guests (First version that uses QEMU 5.0) + +https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/ +https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/ +https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/ + +I'd be more than happy any debugs that might be helpful. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1886076 b/results/classifier/gemma3:12b/peripherals/1886076 new file mode 100644 index 000000000..86f016b0f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1886076 @@ -0,0 +1,37 @@ + +risc-v pmp implementation error + +QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab + + +RISC-V PMP implementation is not correct on QEMU. + +When an access is granted there is no more PMP check on the 4KB memory range of the accessed location. +A cache flush is needed in order to force a PMP check on next access to this 4KB memory range. +A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range. + +For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF: +1st case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Then a read access is done @0x80003400 --> access OK while it must be blocked! +2nd case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");) + 3) A read access is done @0x80003400 --> access blocked as expected + +Analysis: + After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry. + Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed. +What should be done: + Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry. + +The 4KB range is the default size of a TLB page on QEMU for RISCV. +The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes. + +I tested a quick fix and PMP is working as expected. +The quick fix consist in replacing this line: +tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE); +By this one in target/riscv/cpu_helper.c: +tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size); + +This quick fix has to be optimized in order to consume less HW resources, as explained at the beginning. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1887641 b/results/classifier/gemma3:12b/peripherals/1887641 new file mode 100644 index 000000000..4d5b7c7db --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1887641 @@ -0,0 +1,8 @@ + +PCI bus not available for hda + +I'm trying to boot Mac OS 9.2.2 image in order to install it on a qcow disk image. I'm using Linux Mint MATE 20 and QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.3). When I boot, I've got this error message and boot fails : + +$ /usr/bin/qemu-system-ppc -monitor stdio -soundhw hda -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -drive file="/home/david/.aqemu/iMacG3_hard_disk_HDA.img",if=ide,index=0 -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 +QEMU 4.2.0 monitor - type 'help' for more information +(qemu) qemu-system-ppc: PCI bus not available for hda \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1888663 b/results/classifier/gemma3:12b/peripherals/1888663 new file mode 100644 index 000000000..76ac36475 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1888663 @@ -0,0 +1,14 @@ + +msmouse not recognized in guest + +The msmouse option for emulating a serial mouse does not seem to work in a DOS guest. + +I'm on Windows 10 X64, I have tried launching qemu (commit d0cc248164961a7ba9d43806feffd76f9f6d7f41 but also way older) with: +./qemu-system-i386 -serial msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse -fda mousetest.img +./qemu-system-i386 -chardev msmouse,id=msmouse -device pci-serial,chardev=msmouse -chardev msmouse,id=msmouse -fda mousetest.img + +Then I boot FreeDOS (but regular DOS shows same behavior), start the CuteMouse driver and force the scan of a serial mouse with CTM /S. +The mouse is never found. With other drivers (in the attachment), the mouse is probably not found but the driver is installed anyway, but it does not work (there's a MOUSETST in the same floppy; it works iwth CTM and PS/2 mouse emulation). + +Using a serial port sniffer inside the guest, it would seem that data is indeed transmitted. Setting a few printf in msmouse.c also confirms that the mouse gets initilized and starts transmitting data. However, it does not work... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1890208 b/results/classifier/gemma3:12b/peripherals/1890208 new file mode 100644 index 000000000..1ec9c5f7a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1890208 @@ -0,0 +1,12 @@ + +Mouse pointer disappears when it is over console window + +The host mouse pointer disappears when it is over a console window. + +I am emulating quite simple hardware: just text console and no mouse. I don't expect the mouse to have any effect on the emulated computers, but I need to know where the mouse pointer is. That is important because I need to use the mouse to switch between applications and to switch between virtual machines (QEMU grabs Alt+Tab events). Also, it is quite tricky to work with multiple screens when we don't know where the mouse pointer is. + +I am using: +* Virtual Machine Manager 2.2.1 +* QEMU 4.2.0 +* Fedora 32 +* KDE Plasma 5.18.5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1891354 b/results/classifier/gemma3:12b/peripherals/1891354 new file mode 100644 index 000000000..91dd014d1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1891354 @@ -0,0 +1,115 @@ + +Heap-use-after-free in usb_packet_unmap + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \ +-trace usb\* -device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc0202 +outl 0xcf8 0x80001004 +outl 0xcfc 0x1c77695e +writel 0xc0040 0xffffd855 +writeq 0xc2000 0xff05140100000000 +write 0x1d 0x1 0x27 +write 0x2d 0x1 0x2e +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x05 +write 0x17276 0x1 0x72 +write 0x17278 0x1 0x02 +write 0x3d 0x1 0x27 +write 0x40 0x1 0x2e +write 0x41 0x1 0x72 +write 0x42 0x1 0x01 +write 0x4d 0x1 0x2e +write 0x4f 0x1 0x01 +write 0x2007c 0x1 0xc7 +writeq 0xc2000 0x5c05140100000000 +write 0x20070 0x1 0x80 +write 0x20078 0x1 0x08 +write 0x2007c 0x1 0xfe +write 0x2007d 0x1 0x08 +write 0x20081 0x1 0xff +write 0x20082 0x1 0x0b +write 0x20089 0x1 0x8c +write 0x2008d 0x1 0x04 +write 0x2009d 0x1 0x10 +writeq 0xc2000 0x2505ef019e092f00 +EOF + +20091==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000045030 at pc 0x55db79edeef2 bp 0x7ffc4020b2b0 sp 0x7ffc4020b2a8 +READ of size 4 at 0x611000045030 thread T0 + #0 0x55db79edeef1 in usb_packet_unmap hw/usb/libhw.c:64:28 + #1 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 + #2 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #3 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #4 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #5 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #10 0x55db78cfee6b in flatview_write exec.c:3216:14 + #11 0x55db78cfee6b in address_space_write exec.c:3308:18 + #12 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 + #13 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #14 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 + #15 0x7fc5d7f1a897 in g_main_context_dispatch + #16 0x55db7aa571b3 in glib_pollfds_poll util/main-loop.c:217:9 + #17 0x55db7aa571b3 in os_host_main_loop_wait util/main-loop.c:240:5 + #18 0x55db7aa571b3 in main_loop_wait util/main-loop.c:516:11 + #19 0x55db79315008 in qemu_main_loop softmmu/vl.c:1676:9 + #20 0x55db7a8860fd in main softmmu/main.c:49:5 + +0x611000045030 is located 48 bytes inside of 256-byte region [0x611000045000,0x611000045100) +freed by thread T0 here: + #0 0x55db78cac16d in free (build/i386-softmmu/qemu-system-i386+0x250e16d) + #1 0x55db79f7c0e8 in xhci_ep_nuke_xfers hw/usb/hcd-xhci.c:1252:9 + #2 0x55db79f7b454 in xhci_disable_ep hw/usb/hcd-xhci.c:1279:5 + #3 0x55db79f79af7 in xhci_disable_slot hw/usb/hcd-xhci.c:2048:13 + #4 0x55db79f5aea3 in xhci_reset hw/usb/hcd-xhci.c:2706:9 + #5 0x55db79f82f49 in xhci_oper_write hw/usb/hcd-xhci.c:2966:13 + #6 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #7 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #8 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #9 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #10 0x55db78cfee6b in flatview_write exec.c:3216:14 + #11 0x55db78cfee6b in address_space_write exec.c:3308:18 + #12 0x55db78d01fe7 in address_space_unmap exec.c:3634:9 + #13 0x55db79edebbb in dma_memory_unmap include/sysemu/dma.h:145:5 + #14 0x55db79edebbb in usb_packet_unmap hw/usb/libhw.c:65:9 + #15 0x55db79ede66f in usb_packet_map hw/usb/libhw.c:54:5 + #16 0x55db79f6d5f1 in xhci_setup_packet hw/usb/hcd-xhci.c:1618:5 + #17 0x55db79f67143 in xhci_fire_ctl_transfer hw/usb/hcd-xhci.c:1722:9 + #18 0x55db79f67143 in xhci_kick_epctx hw/usb/hcd-xhci.c:1991:13 + #19 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #20 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #21 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #22 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #23 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #24 0x55db78cfee6b in flatview_write exec.c:3216:14 + #25 0x55db78cfee6b in address_space_write exec.c:3308:18 + #26 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 + #27 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #28 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 + #29 0x7fc5d7f1a897 in g_main_context_dispatch + +previously allocated by thread T0 here: + #0 0x55db78cac562 in calloc (build/i386-softmmu/qemu-system-i386+0x250e562) + #1 0x7fc5d7f20548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) + #2 0x55db79f8837d in xhci_doorbell_write hw/usb/hcd-xhci.c:3162:13 + #3 0x55db792c6b8e in memory_region_write_accessor softmmu/memory.c:483:5 + #4 0x55db792c658b in access_with_adjusted_size softmmu/memory.c:544:18 + #5 0x55db792c5d9b in memory_region_dispatch_write softmmu/memory.c + #6 0x55db78d094d2 in flatview_write_continue exec.c:3176:23 + #7 0x55db78cfee6b in flatview_write exec.c:3216:14 + #8 0x55db78cfee6b in address_space_write exec.c:3308:18 + #9 0x55db793072a9 in qtest_process_command softmmu/qtest.c:452:13 + #10 0x55db79304087 in qtest_process_inbuf softmmu/qtest.c:710:9 + #11 0x55db7a7d7293 in fd_chr_read chardev/char-fd.c:68:9 + #12 0x7fc5d7f1a897 in g_main_context_dispatch + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1891829 b/results/classifier/gemma3:12b/peripherals/1891829 new file mode 100644 index 000000000..935d54c17 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1891829 @@ -0,0 +1,12 @@ + +High bit(s) sometimes set high on rcvd serial bytes when char size < 8 bits + +I *believe* (not confirmed) that the old standard PC serial ports, when configured with a character size of 7 bits or less, should set non-data bits to 0 when the CPU reads received chars from the read register. qemu doesn't do this. + +Windows 1.01 will not make use of a serial mouse when bit 7 is 1. The ID byte that the mouse sends on reset is ignored. I added a temporary hack to set bit 7 to 0 on all incoming bytes, and this convinced windows 1.01 to use the mouse. + +note 1: This was using a real serial mouse through a passed-through serial port. The emulated msmouse doesn't work for other reasons. + +note 2: The USB serial port I am passing through to the guest sets non-data bits to 1. Not sure if this is the USB hardware or linux. + +note 3: I also needed to add an -icount line to slow down the guest CPU, so that certain cpu-sensitive timing code in the guest didn't give up too quickly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1891830 b/results/classifier/gemma3:12b/peripherals/1891830 new file mode 100644 index 000000000..0c8f6e68a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1891830 @@ -0,0 +1,35 @@ + +msmouse serial mouse emulation broken? No id byte sent on reset + +I took a shot at getting Windows 1.01 working. It doesn't support a PS/2 mouse out-of-the-box but does support MS serial mice. It doesn't seem to detect qemu's emulated msmouse. + +When I run this command: + +> qemu-system-i386 -nodefaults -hda my_windows1_hd.qcow2 -vga std -serial msmouse -trace enable='serial*' -icount shift=10,align=on + +I get this output (edited): + +251908@1597626456.800452:serial_ioport_write write addr 0x04 val 0x01 +251908@1597626456.800460:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.800462:serial_ioport_read read addr 0x00 val 0x00 + +[snip] + +251908@1597626456.961641:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961642:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961644:serial_ioport_read read addr 0x00 val 0x00 +251908@1597626456.961647:serial_ioport_write write addr 0x04 val 0x0b +251908@1597626456.961648:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961684:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626456.961685:serial_ioport_read read addr 0x05 val 0x60 + +[snip] + +251908@1597626457.045894:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045895:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045897:serial_ioport_read read addr 0x05 val 0x60 +251908@1597626457.045932:serial_ioport_read read addr 0x00 val 0x00 + +The write of 0x01 and then 0x0b to reg 0x04 is the guest turning the RTS line off then on. A real mouse will respond to this by sending 0x4d, which is how the guest detects the mouse. + +Reproducible in current stable-4.2 and 5.0 (debian's build). I am able to get the guest to use a real passed-through serial mouse (with a minor hack, separate bug filed for this) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1892604 b/results/classifier/gemma3:12b/peripherals/1892604 new file mode 100644 index 000000000..c8fd9a628 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1892604 @@ -0,0 +1,27 @@ + +qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion `addr <= GINTSTS2' failed. + +When trying to run the 2016-05-27 Raspbian image on the emulated raspi2 platform, the system boots but shortly after the login prompt QEMU (master; commit ID ca489cd037e4d50dc6c40570a167504ad7e5a521) dies with: + +qemu-system-arm: ../hw/usb/hcd-dwc2.c:666: dwc2_glbreg_read: Assertion `addr <= GINTSTS2' failed. + +Steps to reproduce: + +1. Get the image: wget http://downloads.raspberrypi.org/raspbian/images/raspbian-2016-05-31/2016-05-27-raspbian-jessie.zip + +2. Extract the kernel image and DTB: + +sudo losetup -f --show -P 2016-05-27-raspbian-jessie.img +sudo mkdir /mnt/rpi +sudo mount /dev/loop11p1 /mnt/rpi/ +cp /mnt/rpi/kernel7.img . +cp /mnt/rpi/bcm2709-rpi-2-b.dtb . +sudo umount /mnt/rpi +sudo losetup -d /dev/loop11 + +3. Run QEMU: +qemu-system-arm -M raspi2 -m 1G -dtb bcm2709-rpi-2-b.dtb -kernel kernel7.img -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -sd 2016-05-27-raspbian-jessie.img -smp 4 -serial stdio -display none + +A few seconds after the login prompt is displayed, QEMU will exit with the assertion failure. + +I also tried changing all of the asserts to if statements that (for MMIO reads) returned 0 and (for writes) just returned, but this resulted in a non-responsive system. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1892962 b/results/classifier/gemma3:12b/peripherals/1892962 new file mode 100644 index 000000000..61c1496ec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1892962 @@ -0,0 +1,130 @@ + +Segfault in usb_bus_from_device + +Hello, +Reproducer: + +cat << EOF | ./qemu-system-i386 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,\ +multifunction=on,id=ich9-ehci-1 \ +-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,\ +multifunction=on,masterbus=ich9-ehci-1.0,firstport=0 \ +-device usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 \ +-display none -nodefaults -qtest stdio -accel qtest +outl 0xcf8 0x8000e803 +outl 0xcfc 0xff00ff00 +outl 0xcf8 0x8000e821 +outb 0xcfc 0xff +outl 0xff10 0x8500057e +clock_step +clock_step +outb 0xff00 0x49 +write 0x2 0x1 0x40 +write 0x400006 0x1 0xfb +write 0x400008 0x1 0x2d +write 0x40000a 0x1 0xe0 +write 0x40000c 0x1 0x16 +write 0x40000e 0x1 0xfa +write 0xfa001c 0x1 0x04 +clock_step +write 0x400006 0x1 0xfb +write 0xfa001d 0x1 0xff +clock_step +write 0x8 0x1 0xe0 +write 0xa 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x1600e8 0x1 0xe1 +write 0x1600eb 0x1 0x30 +clock_step +clock_step +write 0x10 0x1 0xe0 +write 0x12 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +write 0x8 0x1 0xe1 +write 0xa 0x1 0x40 +write 0xb 0x1 0x30 +clock_step +write 0x14 0x1 0xe0 +write 0x16 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +write 0x18 0x1 0xe0 +write 0x1a 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +write 0x1c 0x1 0xe0 +write 0x1e 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +write 0x20 0x1 0xe0 +write 0x22 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +EOF + +The trace: + +... +[S +0.087589] OK +[R +0.087596] write 0x1600e6 0x1 0x9c +OK +[S +0.087603] OK +[R +0.087655] write 0x6 0x1 0x9c +OK +[S +0.087667] OK +[R +0.087675] clock_step +784168@1598406646.189133:usb_uhci_frame_start nr 8 +784168@1598406646.189141:usb_uhci_td_load qh 0x0, td 0x1600e0, ctrl 0x9c0180, token 0x300000e1 +784168@1598406646.189147:usb_uhci_packet_add token 0x0, td 0x1600e0 +784168@1598406646.189151:usb_packet_state_change bus 0, port 1, ep 0, packet 0x611000043c00, state undef -> setup +784168@1598406646.189161:usb_packet_state_change bus 0, port 1, ep 0, packet 0x611000043c00, state setup -> complete +784168@1598406646.189165:usb_uhci_packet_complete_success token 0x0, td 0x1600e0 +784168@1598406646.189168:usb_uhci_packet_del token 0x0, td 0x1600e0 +784168@1598406646.189174:usb_uhci_td_complete qh 0x0, td 0x1600e0 +784168@1598406646.189179:usb_uhci_td_load qh 0x0, td 0x0, ctrl 0x9c0182, token 0x304000e1 +784168@1598406646.189183:usb_uhci_packet_add token 0x0, td 0x0 +784168@1598406646.189187:usb_packet_state_change bus 0, port 1, ep 0, packet 0x611000043d40, state undef -> setup +/home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12: runtime error: member access within null pointer of type 'USBDevice' (aka 'struct USBDevice') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 in +/home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12: runtime error: member access within null pointer of type 'DeviceState' (aka 'struct DeviceState') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==784168==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x5599c43df445 bp 0x7ffec2833e50 sp 0x7ffec2833dc0 T0) +==784168==The signal is caused by a READ memory access. +==784168==Hint: address points to the zero page. + #0 0x5599c43df445 in usb_bus_from_device /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 + #1 0x5599c43ea95c in usb_packet_set_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:549:23 + #2 0x5599c43e8abd in usb_handle_packet /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:438:17 + #3 0x5599c4b02497 in uhci_handle_td /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-uhci.c:892:9 + #4 0x5599c4afbd26 in uhci_process_frame /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-uhci.c:1075:15 + #5 0x5599c4aed2e3 in uhci_frame_timer /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-uhci.c:1174:9 + #6 0x5599c7620917 in timerlist_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:572:9 + #7 0x5599c7620e51 in qemu_clock_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:586:12 + #8 0x5599c5f35a13 in qtest_clock_warp /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/cpus.c:507:9 + #9 0x5599c61225d8 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:665:9 + #10 0x5599c611063e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #11 0x5599c610f3e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #12 0x5599c7215762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #13 0x5599c72158aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #14 0x5599c723b514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #15 0x5599c7127736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #16 0x7f62623914cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #17 0x5599c76b2c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #18 0x5599c76b0567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #19 0x5599c76aff47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #20 0x5599c5e8e08d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #21 0x5599c382051c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #22 0x7f6261b9acc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #23 0x5599c3775cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 in usb_bus_from_device +==784168==ABORTING + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1894 b/results/classifier/gemma3:12b/peripherals/1894 new file mode 100644 index 000000000..7e3313dff --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1894 @@ -0,0 +1,12 @@ + +Can't emulate audio with OpenCore Mac OS X 10.7 +Description of problem: +OpenCore wants me to use `AppleALC`, but to use _that_, I need the layout ID of the motherboard or something and I'm not sure how I'd do that since it's a QEMU VM. All I want to do is have some audio :( + +So, how can I emulate audio with AppleALC + OpenCore/how can I get a layout ID that'll give me audio on a QEMU VM? Do note that I am using UTM (https://getutm.app/) (UTM uses QEMU and is basically a QEMU frontend). +Steps to reproduce: +1. Set up OpenCore and install Mac OS X 10.7 +2. Copy across a .mp3 file +3. iTunes fails to play it due to no audio drivers/audio outputs +Additional information: +N/A diff --git a/results/classifier/gemma3:12b/peripherals/1895363 b/results/classifier/gemma3:12b/peripherals/1895363 new file mode 100644 index 000000000..c75ecad88 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1895363 @@ -0,0 +1,8 @@ + +borland IDEs double up cursor key presses (need timing on PS2 port input) + +Most DOS-era IDEs from Borland (I have tried Borland C++ 2.0, Borland C++ 3.1 and Turbo Pascal 7.1) exhibit strange responses to the keyboard. Cursor keys are registered twice, so each press of a cursor key causes the cursor to move twice. Also the other keys occasionally are missed or duplicated. + +From an internet search, the problem appears to be this. These programs read the PS2 input register multiple times per incoming byte, on the assumption that the byte will remain there for at least a few hundred microseconds, before the next byte (if any) appears there. qemu treats a read of the register by the guest as an acknowledgement of the incoming byte and puts the next byte into the register immediately, thus breaking the programs that expect each successive byte to stay in place for a while. + +The obvious solution is to use a timer to advance through the queued bytes. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1895895 b/results/classifier/gemma3:12b/peripherals/1895895 new file mode 100644 index 000000000..36db7a607 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1895895 @@ -0,0 +1,30 @@ + +Attaching SD-Card to specific SD-Bus Sabrelite (ARM) + +Currently, I am looking for a method of attaching an sd-card to a specific bus as opposed to defaulting to the first. + +QEMU Version: 5.0.0 +Specifically trying to use qemu-system-arm binary + + +Running an "info qtree" shows the output seen in the attached image. I have attempted multiple different combinations of arguments to attempt to get the sd-card to appear on the FOURTH sd-bus but no luck. The machine type being used is Sabrelite. It should be noted that I was able to PATCH QEMU to achieve the result I expected but I had hoped this functionality was already available and did not require modification to QEMU itself. + + +For reference, this is the patch that was made to source to allow the card to attach to a specific bus. After the change was made, an sd-card could be attached to a bus with the following flags: + +-drive file=sdcard.img,format=raw,id=mycard -device sd-card,drive=mycard,bus=sd-bus.0 + + +diff qemu-5.1.0.orig/hw/sd/sdhci.c qemu-5.1.0/hw/sd/sdhci.c +1311a1312,1314 +> static int index=0; +> char name[64]; +> sprintf(name, "sd-bus.%d", index++); +1313c1316 +< TYPE_SDHCI_BUS, DEVICE(s), "sd-bus"); +--- +> TYPE_SDHCI_BUS, DEVICE(s), name); + + + +If there is a way to attach an sd-card to the specific bus that does NOT require this change, I'd appreciate it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1896317 b/results/classifier/gemma3:12b/peripherals/1896317 new file mode 100644 index 000000000..f6105c560 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1896317 @@ -0,0 +1,58 @@ + +ioapic: UndefinedBehaviorSanitizer starting qemu-system-i386 + +As of commit 053a4177817: + +$ ./configure --enable-sanitizers --disable-kvm + +$ make qemu-system-i386 + +$ ./build/i386-softmmu/qemu-system-i386 +include/exec/memory.h:688:12: runtime error: member access within null pointer of type 'AddressSpace' (aka 'struct AddressSpace') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/exec/memory.h:688:12 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==249513==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x55955d7f8c4f bp 0x7fff10f3cff0 sp 0x7fff10f3cf20 T0) +==249513==The signal is caused by a READ memory access. +==249513==Hint: address points to the zero page. + #0 0x55955d7f8c4f in address_space_to_flatview include/exec/memory.h:688:12 + #1 0x55955d8003d2 in address_space_translate include/exec/memory.h:2286:31 + #2 0x55955d8315f3 in address_space_stl_internal memory_ldst.c.inc:312:10 + #3 0x55955d831cd1 in address_space_stl_le memory_ldst.c.inc:353:5 + #4 0x55955d7ef2e1 in stl_le_phys include/exec/memory_ldst_phys.h.inc:103:5 + #5 0x55955d7ed299 in ioapic_service hw/intc/ioapic.c:138:17 + #6 0x55955d7f0e30 in ioapic_set_irq hw/intc/ioapic.c:186:17 + #7 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #8 0x55955d0409e6 in gsi_handler hw/i386/x86.c:583:5 + #9 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #10 0x55955ca539c9 in hpet_handle_legacy_irq hw/timer/hpet.c:724:13 + #11 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #12 0x55955ce7a695 in pit_irq_timer_update hw/timer/i8254.c:264:5 + #13 0x55955ce7a1d8 in pit_irq_control hw/timer/i8254.c:306:9 + #14 0x55955e34b825 in qemu_set_irq hw/core/irq.c:45:5 + #15 0x55955ca52276 in hpet_reset hw/timer/hpet.c:707:5 + #16 0x55955e342e91 in device_transitional_reset hw/core/qdev.c:1114:9 + #17 0x55955e345cfc in resettable_phase_hold hw/core/resettable.c:182:13 + #18 0x55955e31c1e5 in bus_reset_child_foreach hw/core/bus.c:94:9 + #19 0x55955e348a58 in resettable_child_foreach hw/core/resettable.c:96:9 + #20 0x55955e34596f in resettable_phase_hold hw/core/resettable.c:173:5 + #21 0x55955e344a72 in resettable_assert_reset hw/core/resettable.c:60:5 + #22 0x55955e344919 in resettable_reset hw/core/resettable.c:45:5 + #23 0x55955e3473e9 in resettable_cold_reset_fn hw/core/resettable.c:269:5 + #24 0x55955e344898 in qemu_devices_reset hw/core/reset.c:69:9 + #25 0x55955d05c5b0 in pc_machine_reset hw/i386/pc.c:1632:5 + #26 0x55955d55ab84 in qemu_system_reset softmmu/vl.c:1403:9 + #27 0x55955d56816d in qemu_init softmmu/vl.c:4458:5 + #28 0x55955bc13609 in main softmmu/main.c:49:5 + #29 0x7f3baad20041 in __libc_start_main (/lib64/libc.so.6+0x27041) + #30 0x55955bb398ed in _start (build-sanitizer/qemu-system-i386+0x1b3d8ed) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV include/exec/memory.h:688:12 in address_space_to_flatview + +Comment and stl_le_phys() added in commit cb135f59b80: + /* No matter whether IR is enabled, we translate + * the IOAPIC message into a MSI one, and its + * address space will decide whether we need a + * translation. */ + stl_le_phys(ioapic_as, info.addr, info.data); \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1897 b/results/classifier/gemma3:12b/peripherals/1897 new file mode 100644 index 000000000..df39c5fc8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1897 @@ -0,0 +1,22 @@ + +npcm7xx_timer-test.c is unreliable +Description of problem: +Sometimes npcm7xx_timer-test fails intermittently: +https://gitlab.com/qemu-project/qemu/-/jobs/5121787250 + +``` +38/96 qemu:qtest+qtest-arm / qtest-arm/npcm7xx_timer-test ERROR 0.95s exit status 1 +>>> QTEST_QEMU_BINARY=./qemu-system-arm QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=103 /builds/qemu-project/qemu/build/tests/qtest/npcm7xx_timer-test --tap -k +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +** +ERROR:../tests/qtest/npcm7xx_timer-test.c:475:test_periodic_interrupt: assertion failed (tim_read(td, TISR) == tim_timer_bit(td)): (0x00000000 == 0x00000004) +** +ERROR:../tests/qtest/npcm7xx_timer-test.c:476:test_periodic_interrupt: 'qtest_get_irq(global_qtest, tim_timer_irq(td))' should be TRUE +(test program exited with status code 1) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +When I reran the CI job, it passed. + +Please investigate why this test is unreliable and fix it. Thanks! diff --git a/results/classifier/gemma3:12b/peripherals/1897568 b/results/classifier/gemma3:12b/peripherals/1897568 new file mode 100644 index 000000000..1e3385333 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1897568 @@ -0,0 +1,11 @@ + +Strange keyboard behaviour in Vim editor + + +I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a problem with the keyboard in the Vim editor. The arrow keys jump over a line, as if you had typed the key twice. PgUp and PgDn are likewise affected. Other applications are not affected, unless you shell out from Vim. + +The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've tried without it and it doesn't make a difference. + +I don't get this keyboard behaviour in the exact same VM under VMware Player or Bochs. + +-Albert. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1899539 b/results/classifier/gemma3:12b/peripherals/1899539 new file mode 100644 index 000000000..0f4d91d2f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1899539 @@ -0,0 +1,10 @@ + +keyboard errors in DOS, found links to similar errors for reference + +OS: slackware 14.2, updated. qemu version: 4.1.0 (from slackbuild script) + +command line: qemu-system-i386 -hda msdos.vhd + +Description of problem: MSDOS 6.22 disk image running gwbasic 3.23. Cursor keys and sometimes letter keys are repeated. Cursor keys seemingly always, letter keys seem to happen when typing too fast. Numpad arrows are not affected. Also insert key doesnt seem to work at all. + +Have found one similar current bug, Bug #1574246 Drunken keyboard in go32v2 programs https://bugs.launchpad.net/qemu/+bug/1574246?comments=all and a much older vbox bug report that seems very similar, https://www.virtualbox.org/ticket/58 , and for some reason mentions a qemu patch. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1901532 b/results/classifier/gemma3:12b/peripherals/1901532 new file mode 100644 index 000000000..0f6017176 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1901532 @@ -0,0 +1,20 @@ + +Assertion failure `mr != NULL' failed through usb-ehci + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ehci. + +This was found in version 5.0.1 (stable-5.0). + +-------- + +qemu-system-i386: src/qemu-repro/exec.c:3581: address_space_unmap: Assertion `mr != NULL' failed. +[1] 14721 abort src/qemu-repro/build/i386-softmmu/qemu-system-i386 + + +To reproduce the assertion failure, please run the QEMU with following command line. + +``` +$ qemu-system-i386 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -m 512 -drive if=none,id=stick,file=./usbdisk.img -device usb-ehci,id=ehci -device usb-storage,bus=ehci.0,drive=stick +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1904331 b/results/classifier/gemma3:12b/peripherals/1904331 new file mode 100644 index 000000000..e52ce50c1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1904331 @@ -0,0 +1,27 @@ + +Coding bug in the function serial_ioport_write in serial.c + +Branch hash: b50ea0d (pulled from github). + +I was reviewing the code and noticed the following in the function serial_ioport_write: + + assert(size == 1 && addr < 8); + . + . + . + switch(addr) { + default: + case 0: + if (s->lcf & UART_LCR_DLAB) { + if (size == 1) { + s->divider = (s->divider & 0xff00) | val; + } else { + s->divider = val; + } + } + +The assert will trigger if the size is > 1, so the else of the if (size == 1) will never be executed and an attempt to specify a size > 1 will trigger an assert. + +The documentation for the UART indicates that the 16-bit divisor is broken up amongst 2 8-bit registers (DLL and DLM). There already is code to handle the DLL and DLM portions of the divider register (as coded). + +This is not exactly going to cause a bug, as there is no code that calls this function with a value for size other than 1. It is just unnecessary code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1906155 b/results/classifier/gemma3:12b/peripherals/1906155 new file mode 100644 index 000000000..25623b617 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1906155 @@ -0,0 +1,14 @@ + +USB Passthrough Fails on Start, Needs domain Reset + +Hi, + +I am seeing (consistently = always), USB Passthrough for my Logitech Keyboard and Mouse ... they don't work / no response on domain (VM) startup. After a reset of the VM they then work - but why are they "dead" on initial startup of the VM? Is this a known issue? + +Running, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +And if it makes a difference, this is a macOS guest (on a Linux host). + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1906180 b/results/classifier/gemma3:12b/peripherals/1906180 new file mode 100644 index 000000000..46ce8e2a2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1906180 @@ -0,0 +1,14 @@ + +Keyboard keys get stuck + +Keyboard keys get "stuck" quite often, on certain Linux guests at least, and start repeating themselves until another key is pressed. This is especially noticeable with key combinations like Ctrl+V for pasting. When it happens, you get the pasted text and vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv... + +This bug has been present for quite some time but I don't remember any specific version that had it first. + + +QEMU version: 5.1.0 +Guest: Debian stable 64-bit (live), with Gnome desktop (may occur with other Linux guests too) +Host: Arch Linux with KDE desktop (X11, wayland not tested); both default and hardened kernel tested + +QEMU start command: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom debian.iso -boot d -vga std \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1906181 b/results/classifier/gemma3:12b/peripherals/1906181 new file mode 100644 index 000000000..2c93a49fe --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1906181 @@ -0,0 +1,14 @@ + +Mouse starts jumping wildly on guest desktop + +Sometimes mouse goes completely crazy and starts jumping around the guest desktop by itself and becomes completely unusable. + +This does not happen on every boot, only sometimes. It may be caused by some input combination but I haven't yet found any specific cause. It happens soon after the desktop has been loaded and rebooting seems to be the only way to resolve the situation. + + +Guest: Kubuntu 20.04 64-bit (live), with KDE desktop +Host: Arch Linux, with KDE desktop +QEMU version: 5.1.0 + +QEMU start command: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1906608 b/results/classifier/gemma3:12b/peripherals/1906608 new file mode 100644 index 000000000..6f93d6b70 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1906608 @@ -0,0 +1,18 @@ + + [Feature request]For some ehci controller, qemu should implement using portsc[26-27] to detect the speed of device. + +for some ehci controller ,for example ehci controller on fsl_imx6,it using portsc[26-27] to decide a full speed device or high speed device was connected, hub-ehci.c should set the portsc[26-27] to return the right speed. + +line:1001 in hub-ehci.c + if (dev && dev->attached && (dev->speedmask & USB_SPEED_MASK_HIGH)) { + val |= PORTSC_PED; + } + +below is the spec for fsl_imx6 USB PART. +PORTSC:27–26 :PSPD +Port Speed - Read Only. +This register field indicates the speed at which the port is operating. +00 Full Speed +01 Low Speed +10 High Speed +11 Undefined \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1907042 b/results/classifier/gemma3:12b/peripherals/1907042 new file mode 100644 index 000000000..2b75b21d9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1907042 @@ -0,0 +1,37 @@ + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed + +Hello, + +An assertion failure was found in hw/usb/core.c:727 in latest version 5.2.0. + +Reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 -trace usb\* + +Backtrace is as follows: +#0 0x00007f13fff14438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f13fff1603a in __GI_abort () at abort.c:89 +#2 0x00007f13fff0cbe7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=file@entry=0x55f97745f6c0 "../hw/usb/core.c", line=line@entry=727, function=function@entry=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:92 +#3 0x00007f13fff0cc92 in __GI___assert_fail (assertion=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x55f97745f6c0 "../hw/usb/core.c", line=727, function=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:101 +#4 0x000055f975bfc9b2 in usb_ep_get (dev=0x62300000c500, pid=45, ep=1) at ../hw/usb/core.c:727 +#5 0x000055f975f945db in ohci_service_td (ohci=0x6270000191f0, ed=0x7ffcd9308410) at ../hw/usb/hcd-ohci.c:1044 +#6 0x000055f975f95d5e in ohci_service_ed_list (ohci=0x6270000191f0, head=857580576, completion=0) at ../hw/usb/hcd-ohci.c:1200 +#7 0x000055f975f9656d in ohci_process_lists (ohci=0x6270000191f0, completion=0) at ../hw/usb/hcd-ohci.c:1238 +#8 0x000055f975f9725c in ohci_frame_boundary (opaque=0x6270000191f0) at ../hw/usb/hcd-ohci.c:1281 +#9 0x000055f977212494 in timerlist_run_timers (timer_list=0x60b00005b060) at ../util/qemu-timer.c:574 +#10 0x000055f9772126db in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#11 0x000055f977212fde in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#12 0x000055f9772d5717 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531 +#13 0x000055f97695100c in qemu_main_loop () at ../softmmu/vl.c:1677 +#14 0x000055f9758f7601 in main (argc=16, argv=0x7ffcd9308888, envp=0x7ffcd9308910) at ../softmmu/main.c:50 +#15 0x00007f13ffeff840 in __libc_start_main (main=0x55f9758f75b0 <main>, argc=16, argv=0x7ffcd9308888, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd9308878) at ../csu/libc-start.c:291 +#16 0x000055f9758f74a9 in _start () + + +The poc is attached. + +Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1908832 b/results/classifier/gemma3:12b/peripherals/1908832 new file mode 100644 index 000000000..a12cabfdb --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1908832 @@ -0,0 +1,63 @@ + +jack audio dev produces no sound + +Hi, + +I'm testing the new jack audiodev backend in my +laptop. The host system is gentoo, using the +ebuild for qemu 5.1.0-r2, and I'm using jack +use flag globally in the system so any ebuild +that have support for jack should be build with +it. The jack setup reportedly works as I use it +with firefox, and mumble with no trouble. When +I launch the following script, I see the vm +connects to jack: + +/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 -vga virtio -display gtk,gl=on \ + -cpu host -smp 2,cores=2,threads=1 \ + -m 4G -L /usr/share/qemu \ + -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \ + -drive file=/usr/share/edk2-ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=debian_VARS.fd,if=pflash,format=raw,unit=1 \ + -audiodev id=jack,driver=jack -device ich9-intel-hda -device hda-duplex,audiodev=jack \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent \ + -device nec-usb-xhci,id=usb \ + -device usb-host,vendorid=0x04ca,productid=0x708e \ + -device usb-host,vendorid=0x1050,productid=0x0407 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev1 \ + -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev2 \ + -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 \ + -chardev spicevmc,name=usbredir,id=usbredirchardev3 \ + -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -drive file=debian.qcow2,cache=none,aio=io_uring,if=virtio + +Output of vm initialization: + +jack: JACK output configured for 48000Hz (1024 samples) +jack: JACK input configured for 48000Hz (1024 samples) +gl_version 46 - core profile enabled +GLSL feature level 430 + +Though executing any application that uses sound, +for instance, any youtube video through browser, +I listen nothing. By executing pkill jackd, and +launching the same script replacing the audiodev +line for the following: + + -audiodev id=alsa,driver=alsa -device ich9-intel-hda -device hda-duplex,audiodev=alsa \ + +The audio works, and I can listen to music, or +any other kind of application, though I cannot +listen anything else in the host. + +The guest is a simple debian testing(bullseye) +system with plasma desktop, using pulseaudio, +nothing fancy. + +Thanks! + +José \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1909261 b/results/classifier/gemma3:12b/peripherals/1909261 new file mode 100644 index 000000000..3ef357cf9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1909261 @@ -0,0 +1,36 @@ + +[OSS-Fuzz] Issue 28929 xhci: ASSERT: xfer->packet.status != USB_RET_NAK + +=== Reproducer === + +./qemu-system-i386 -m 512M -machine q35,accel=qtest \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-bot -device usb-storage,drive=disk0 \ +-chardev null,id=cd0 -chardev null,id=cd1 \ +-device usb-braille,chardev=cd0 -device usb-ccid \ +-device usb-ccid -device usb-kbd -device usb-mouse \ +-device usb-serial,chardev=cd1 -device usb-tablet \ +-device usb-wacom-tablet -device usb-audio \ +-qtest stdio -nographic -nodefaults < attachment + +=== Stack Trace === +#0 raise +#1 abort +#2 libc.so.6 +#3 __assert_fail +#4 xhci_kick_epctx /src/qemu/hw/usb/hcd-xhci.c:1865:13 +#5 xhci_ep_kick_timer /src/qemu/hw/usb/hcd-xhci.c:1034:5 +#6 timerlist_run_timers /src/qemu/util/qemu-timer.c:574:9 +#7 qemu_clock_run_timers /src/qemu/util/qemu-timer.c:588:12 +#8 qtest_clock_warp /src/qemu/softmmu/qtest.c:356:9 +#9 qtest_process_command /src/qemu/softmmu/qtest.c:752:9 +#10 qtest_process_inbuf /src/qemu/softmmu/qtest.c:797:9 +#11 qtest_server_inproc_recv /src/qemu/softmmu/qtest.c:904:9 +#12 send_wrapper /src/qemu/tests/qtest/libqtest.c:1390:5 +#13 qtest_sendf /src/qemu/tests/qtest/libqtest.c:438:5 +#14 qtest_clock_step_next /src/qemu/tests/qtest/libqtest.c:912:5 +#15 op_clock_step /src/qemu/tests/qtest/fuzz/generic_fuzz.c:574:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28929 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1911188 b/results/classifier/gemma3:12b/peripherals/1911188 new file mode 100644 index 000000000..72a2ddb57 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1911188 @@ -0,0 +1,15 @@ + +qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument + +QEMU emulator version 4.2.1 (qemu-4.2.1-1.fc32) on Fedora 32. + +When writing a script to start qemu automatically, I ran into a very confusing error message due to a bug in my script and had trouble understanding it. I isolated the problem to the following: + +$ qemu-system-x86_64 "" +qemu-system-x86_64: Initialization of device ide-hd failed: Device needs media, but drive is empty + +As you can see, running qemu with an empty argument prints a seemingly random and unrelated error message about an ide-hd device, and the program immediately exits with code 1. This happens when an empty argument appears anywhere in the arguments list, always causing the program to immediately die with this error. + +This is a simply baffling message to be encountering when the problem is really an empty argument. + +Expected behaviour: Either flatly ignore the empty argument, or at most trigger a warning (eg, "warning: saw empty argument"). It should not at all prevent the program from running. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1911216 b/results/classifier/gemma3:12b/peripherals/1911216 new file mode 100644 index 000000000..cd1acb6a9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1911216 @@ -0,0 +1,32 @@ + +abort issue locates in hw/usb/hcd-ohci.c:1297:ohci_frame_boundary + +Hello, + +I found an assertion failure in hw/usb/hcd-ohci.c:1297 + +This was found in latest version 5.2.0. + +my reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 + + +backtrace is as follows +pwndbg> bt +#0 0x00007fdf392aa438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007fdf392ac03a in __GI_abort () at abort.c:89 +#2 0x000055c613721118 in ohci_frame_boundary (opaque=0x6270000191f0) at hw/usb/hcd-ohci.c:1297 +#3 0x000055c6140bdf0e in timerlist_run_timers (timer_list=0x60b00005bcc0) at util/qemu-timer.c:572 +#4 0x000055c6140be15a in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at util/qemu-timer.c:586 +#5 0x000055c6140beac7 in qemu_clock_run_all_timers () at util/qemu-timer.c:672 +#6 0x000055c6140a1938 in main_loop_wait (nonblocking=0) at util/main-loop.c:523 +#7 0x000055c6125d87e9 in qemu_main_loop () at /home/dell/qemu5-hypervisor/vm/fuzz-seedpool/hcd-ohci/qemu-5.1.0/softmmu/vl.c:1676 +#8 0x000055c613f216ea in main (argc=7, argv=0x7fff174cdd28, envp=0x7fff174cdd68) at /home/dell/qemu5-hypervisor/vm/fuzz-seedpool/hcd-ohci/qemu-5.1.0/softmmu/main.c:49 +#9 0x00007fdf39295840 in __libc_start_main (main=0x55c613f21699 <main>, argc=7, argv=0x7fff174cdd28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff174cdd18) at ../csu/libc-start.c:291 +#10 0x000055c6120a4349 in _start () + +The poc is attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1913344 b/results/classifier/gemma3:12b/peripherals/1913344 new file mode 100644 index 000000000..34335f88b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1913344 @@ -0,0 +1,10 @@ + + Exynos4210 UART peripheral data loss + +Currently the Exynos4210 UART (hw/char/exynos4210_uart.c) incorrectly reports however many empty bytes are available in the FIFO when queried for receive capacity. However this peripheral supports a polled mode where only a single byte can be submitted at a time and the FIFO is unused, meaning that in polled mode data is lost since it's written into the FIFO and the polling code in FIFO disabled mode only returns the value in the RX data register. + +Even worse, potentially enabling the FIFO without a FIFO reset will create a weird situation where data is already in the FIFO whenever data came in faster than the polling could pick it up (which is basically always). + +This change obscured the issue in https://bugs.launchpad.net/qemu/+bug/1913341, which instead presented as strange data loss until I locally resolved this issue. + +I have a patch ready for the bug and will submit it later today, I'm just filing for clarity. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1913669 b/results/classifier/gemma3:12b/peripherals/1913669 new file mode 100644 index 000000000..498d4eb21 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1913669 @@ -0,0 +1,34 @@ + +FPE in npcm7xx_adc_convert + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf000c000 0x4 0x02400200 +clock_step +EOF + +Trace: +../hw/adc/npcm7xx_adc.c:60:51: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/adc/npcm7xx_adc.c:60:51 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717962==ERROR: AddressSanitizer: FPE on unknown address 0x55901aa6e67a (pc 0x55901aa6e67a bp 0x7fff0ac087e0 sp 0x7fff0ac087a0 T0) +#0 0x55901aa6e67a in npcm7xx_adc_convert /hw/adc/npcm7xx_adc.c:60:51 +#1 0x55901aa6e67a in npcm7xx_adc_convert_done /hw/adc/npcm7xx_adc.c:106:15 +#2 0x55901ceb847e in timerlist_run_timers /util/qemu-timer.c:574:9 +#3 0x55901c05d804 in qtest_clock_warp /softmmu/qtest.c:356:9 +#4 0x55901c059781 in qtest_process_command /softmmu/qtest.c:752:9 +#5 0x55901c051b97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#6 0x55901c8a2286 in fd_chr_read /chardev/char-fd.c:68:9 +#7 0x7fa5c43f1aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#8 0x55901cefd363 in glib_pollfds_poll /util/main-loop.c:232:9 +#9 0x55901cefd363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#10 0x55901cefd363 in main_loop_wait /util/main-loop.c:531:11 +#11 0x55901bfb8599 in qemu_main_loop /softmmu/runstate.c:721:9 +#12 0x55901a2451fd in main /softmmu/main.c:50:5 +#13 0x7fa5c3e96cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#14 0x55901a198bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: FPE /hw/adc/npcm7xx_adc.c:60:51 in npcm7xx_adc_convert \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1916775 b/results/classifier/gemma3:12b/peripherals/1916775 new file mode 100644 index 000000000..979b4ab0c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1916775 @@ -0,0 +1,26 @@ + +Guest freezes until there is a keyboard input on Windows version + +Windows guests are freezing and waiting for keyboard input and it continues to function after I press a key. I am using Windows10 Home and below is the command I use to run the guest. I have suspected if this is caused by random entropy but even with mouse moving it gives same random locks and it continues to work as soon as I press a key so maybe its not about entropy at all, + +startwinguest.bat: +qemu-system-x86_64 ^ + -name "win" ^ + -machine type=q35,accel=whpx ^ + -cpu EPYC,hv_relaxed,hv_time,topoext ^ + -nodefaults ^ + -usb ^ + -rtc base=localtime,driftfix=slew ^ + -smp 6,sockets=1,cores=3,threads=2 ^ + -m 8192 -mem-prealloc ^ + -soundhw hda ^ + -usbdevice tablet ^ + -netdev user,id=mynet0,hostfwd=tcp::3390-:3389 -device virtio-net,netdev=mynet0 ^ + -vga std ^ + -display gtk ^ + -boot d ^ + -device virtio-scsi-pci,id=scsi0 ^ + -drive "file=%~dp0win10.qcow2,if=none,format=qcow2,discard=unmap,aio=threads,cache=writethrough,id=someid" ^ + -device scsi-hd,drive=someid,bus=scsi0.0 ^ + -drive "file=D:\Setups\OS\Windows\en_windows_server_2019_updated_dec_2020_x64_dvd_36e0f791.iso,media=cdrom,index=1" ^ + -drive "file=%~dp0virtio-win-0.1.185.iso,media=cdrom,index=2" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1920752 b/results/classifier/gemma3:12b/peripherals/1920752 new file mode 100644 index 000000000..6b099d7d1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1920752 @@ -0,0 +1,53 @@ + +USB SoundCard Passthrough not working on arm64 + +Hello, + +I am virtualizing a armhf guest on a aarch64 host and was to use my Sound Blaster USB Soundcard as passthrough. + +armhf Guest is: Debian Buster +aarch64 host is a jetson nano. KVM is enabled. + +Latest qemu is built from sources. +The command I use for running is as follows: + +../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm \ +-kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' \ +-device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,hostbus=1,hostport=2.3 -serial stdio \ +-device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \ +-drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd \ +-netdev user,id=mynet -device virtio-net-device,netdev=mynet \ +-bios edk2-arm-code.fd -no-reboot + + +Where are my lsusb -t shows: + +rreddy78@jetson-nano:~/Downloads$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M + |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M + |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + +Within the VM I can see the usb as follows + +rreddy78@debian:~$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M + |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M + + +Its looks like some passthrough as but it seems like only for + + _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + +I am not sure if passthrough even works because this post I saw + +https://community.arm.com/developer/ip-products/system/f/embedded-forum/48031/usb-pass-through-in-qemu-command-line-for-arm-machines/168764#168764 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1921061 b/results/classifier/gemma3:12b/peripherals/1921061 new file mode 100644 index 000000000..f5458463f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1921061 @@ -0,0 +1,8 @@ + +Corsair iCUE Install Fails, qemu VM Reboots + +Hi, + +I had this working before, but in the latest version of QEMU (built from master), when I try to install Corsair iCUE, and it gets to the driver install point => my Windows 10 VM just reboots! I would be happy to capture logs, but ... what logs exist for an uncontrolled reboot? Thinking they are lost in the reboot :-(. + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1921635 b/results/classifier/gemma3:12b/peripherals/1921635 new file mode 100644 index 000000000..081b4a051 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1921635 @@ -0,0 +1,35 @@ + +ESP SCSI adapter not working with DOS ASPI drivers + +I have been trying to install the DOS ASPI drivers for the ESP scsi card. Both in am53c974 and dc390 modes. Neither works but they don't work in different ways. + +The following things appear to be problematic: + +* The am53c974 should work with the PcSCSI drivers (AMSIDA.SYS) but the ASPI driver never manages to get past initializing the card. The VM never continues. +* The dc390 ASPI driver fares a little better. The ASPI driver loads and is semi-functional but the drivers for the peripherals don't work. + - ASPI.SYS (creative name) loads + - TRMDISK.SYS fails to load when a cd-drive is attached and will crashs scanning the scsi-id where the cd drive is attached + - TRMDISK.SYS loads without a CD drive attached but fails to read any scsi-hd devices attached. The TFDISK.EXE formatter crashes. + - TRMCD.SYS loads, but can not detect any CD drives. + +The various permutations: +am53c974 hang on ASPI driver load: (CD only attached) + +~/src/qemu/build/qemu-system-i386 -m 64 -device am53c974,id=scsi0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda am53c974_aspi.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 crash because of CDROM attachment and loading TRMDISK.SYS (Only CD attached) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, but TRMDISK.SYS not working (TFDISK.EXE will crash) +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0,logical_block_size=512 -drive file=small.qcow2,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +dc390 successful boot, TRMDISK.SYS not loaded, only TRMCD.SYS. CDROM not detected +~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_cd.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log + +All of these tests were done on 7b9a3c9f94bcac23c534bc9f42a9e914b433b299 as well as the 'esp-next' branch found here: https://github.com/mcayland/qemu/tree/esp-next + +The bios file is a seabios master with all int13 support disabled. With it enabled even less works but I figured this would be a seabios bug and not a qemu one. + +The actual iso and qcow2 files used don't appear the matter. the 'small.qcow2' is an empty drive of 100MB. I have also tried other ISOs in the CD drives, or even not put any cd in the drives with the same results. + +I will attach all of the above images. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1923663 b/results/classifier/gemma3:12b/peripherals/1923663 new file mode 100644 index 000000000..4cdc78d45 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1923663 @@ -0,0 +1,20 @@ + +Can't(?) disable default floppy drive any more in qemu 6.0 + +There's a documented change in qemu 6.0: + +https://qemu-project.gitlab.io/qemu/system/removed-features.html#floppy-controllers-drive-properties-removed-in-6-0 + +where you can't configure floppy controller device properties with -global any more. However, there's a thing you could do with the old parameter which I can't figure out a way to do with the documented replacement. openQA passed exactly this argument: + +-global isa-fdc.driveA= + +and that has the effect of removing/disabling the default floppy drive/controller. If you just run `qemu-system-i686` (no other args) you'll see the VM briefly try to boot from a floppy drive; if you run `qemu-system-i686 -global isa-fdc.driveA=` (with an earlier version of qemu, obviously) you'll see it does not do so. + +I can't see a way to do this with `-device floppy`. Going by the docs, the equivalent should be: + +-device floppy,unit=0,drive= + +but that does not seem to have the same effect. If you run `qemu-system-i686 -device floppy,unit=0,drive=`, it still tries to boot from a floppy drive. + +I see there's a -nodefaults option that disables *all* default devices, but I don't think that's what we want here either. We might want the other default devices, we just don't want the floppy drive. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1926174 b/results/classifier/gemma3:12b/peripherals/1926174 new file mode 100644 index 000000000..41ddb8bde --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1926174 @@ -0,0 +1,16 @@ + +Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM + +This weekend I tried to get a CloudReady (Chrome OS) VM running on qemu 5.2. This seems to wok quite well, performance seems to be great in fact. Only problem is mouse input. + +Using SDL display, there is no visible mouse unless I set "show-cursor=on". After that the mouse pointer flickers a bit and most of the time is displaced so I need to press below a button in order to hit it. After switching to fullscreen and back using ctrl-alt-f this effect seems to be fixed for a while but the mouse pointer does not reach all parts of the emulated screen anymore. + +Using SPICE instead the mouse pointer is drawn, but it is *very* laggy. In fact it is only drawn every few seconds so it is unusable but placement seems to be correct. Text input is instant, so general emulation speed is not an issue here. + +To reproduce, download the free image from https://www.neverware.com/freedownload#home-edition-install + +Then run one of the following commands: + +qemu-system-x86_64 -drive driver=raw,file=cloudready-free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-vga,virgl=on -display sdl,gl=on,show-cursor=on -usb -device usb-mouse -device intel-hda -device hda-duplex + +qemu-system-x86_64 -drive driver=raw,file=cloudready-free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-vga,virgl=on -display spice-app,gl=on -usb -device usb-mouse -device intel-hda -device hda-duplex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/1947933 b/results/classifier/gemma3:12b/peripherals/1947933 new file mode 100644 index 000000000..598a3ed22 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1947933 @@ -0,0 +1,15 @@ + +xHCI Port Status Change Event at port powered + +Per section 4.19.3 of the xHCI version 1.0 specification, when the Port Power bit transitions from 0 to 1, if there is a connection on that port, a Port Status Change Event should be issued. + +Currently, when the port is powered, this event is not being issued. + +I don't know the QEMU code base well enough to submit a patch, but I believe that when the port is powered, check to see if there is a connection (hence, setting the CCS and CSC bits), and then a call to: + +xhci_port_notify(port, PORTSC_PLC); + +will suffice. + +Thank you, +Ben \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/195 b/results/classifier/gemma3:12b/peripherals/195 new file mode 100644 index 000000000..db2f89169 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/195 @@ -0,0 +1,2 @@ + +wavcapture does not record silence diff --git a/results/classifier/gemma3:12b/peripherals/1965 b/results/classifier/gemma3:12b/peripherals/1965 new file mode 100644 index 000000000..716572f29 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1965 @@ -0,0 +1,2 @@ + +riscv64 semihosting not working diff --git a/results/classifier/gemma3:12b/peripherals/1978 b/results/classifier/gemma3:12b/peripherals/1978 new file mode 100644 index 000000000..7d314a0ab --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1978 @@ -0,0 +1,6 @@ + +sifive_e : erroneous CLINT frequency +Description of problem: +CLINT's `mtime` updates at a clock frequency of [10 MHz](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/riscv/sifive_e.c?ref_type=heads#L228), whereas [SiFive documentation](https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf?_gl=1*w2ieef*_ga*MTcyNDI2MjM0Ny4xNjk2ODcwNTM3*_ga_T369JS7J9N*MTY5Njg3MDUzNy4xLjAuMTY5Njg3MDUzNy42MC4wLjA.) shows that its clock frequency is 32.768 kHz (i.e., the RTC clock). + +This difference leads to unexpected timing behavior. Due to the difference, it can even trigger multiple nested interrupts as the IRQ routine is not able to return before a new timer interrupt is triggered. diff --git a/results/classifier/gemma3:12b/peripherals/1980 b/results/classifier/gemma3:12b/peripherals/1980 new file mode 100644 index 000000000..343d0134d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1980 @@ -0,0 +1,14 @@ + +pipewire backend, bad mic sound +Description of problem: +Qemu VM and openSUSE share the webcam mic. +Pipewire is used by openSUSE. + +If using qemu with pa backend, there is no sound problem when mic is used by Skype in openSUSE. +If using qemu with pipewire backend and Skype used the mic then my contact says he does not recognize my voice and there are cracks. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/1981 b/results/classifier/gemma3:12b/peripherals/1981 new file mode 100644 index 000000000..7e1ba90c6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1981 @@ -0,0 +1,11 @@ + +wrong address of pmpaddr13 and pmpaddr14 CSRs +Description of problem: +In qemu\disas\riscv.c lines 2119 & 2120 it seems that there is a confusion about the correct address of the pmpaddr13 and pmpaddr14 CSRs +``` +line 2117 case 0x03bb: return "pmpaddr11"; +line 2118 case 0x03bc: return "pmpaddr12"; +**line 2119 case 0x03bd: return "pmpaddr14"; <--- pmpaddr13 should be here +line 2120 case 0x03be: return "pmpaddr13"; <--- pmpaddr14 should be here** +line 2121 case 0x03bf: return "pmpaddr15"; +``` diff --git a/results/classifier/gemma3:12b/peripherals/1982 b/results/classifier/gemma3:12b/peripherals/1982 new file mode 100644 index 000000000..fae16127c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/1982 @@ -0,0 +1,10 @@ + +PS/2 mouse and keyboard not disabled when adding USB devices +Description of problem: +Documentation (such as https://www.qemu.org/docs/master/system/qemu-manpage.html or https://www.qemu.org/docs/master/system/devices/usb.html) says that enabling a USB keyboard or mouse (or tablet) will disable the PS/2 equivalent, but it seems both are present instead. +Steps to reproduce: +1. Pass a `-usbdevice` or `-device` option to QEMU. +2. Boot Haiku. +3. Find two identical devices in Preferences > Input, both `Extended PS/2 Mouse 1` and `USB Tablet 1`, as well as `AT Keyboard 1` and `USB Keyboard 1`. +Additional information: +The content of /var/log/syslog, which shows discovery of PS/2 devices: [syslog.zst](/uploads/7ed067538c94edfdbaf35ec92a422c68/syslog.zst) diff --git a/results/classifier/gemma3:12b/peripherals/2020 b/results/classifier/gemma3:12b/peripherals/2020 new file mode 100644 index 000000000..3edb41c88 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2020 @@ -0,0 +1,12 @@ + +qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed. +Description of problem: +VM just crashed, likely because of a time / NTP change +``` +qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed. +2023-12-04 15:51:40.571+0000: shutting down, reason=crashed +``` +Steps to reproduce: +1. N/A + +/label ~"kind::Bug" diff --git a/results/classifier/gemma3:12b/peripherals/2021 b/results/classifier/gemma3:12b/peripherals/2021 new file mode 100644 index 000000000..308119e74 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2021 @@ -0,0 +1,2 @@ + +crashing when trying to read data from sensor though usb diff --git a/results/classifier/gemma3:12b/peripherals/2025 b/results/classifier/gemma3:12b/peripherals/2025 new file mode 100644 index 000000000..7e98dbaac --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2025 @@ -0,0 +1,27 @@ + +Can't make the touchscreen work in Windows VM, device virtio-multitouch-pci not starting +Description of problem: +I tried the multitouch on qemu 8, by adding "-device virtio-multitouch-pci" to the qemu cmd line +I could make the multitouch work for an Ubuntu VM, but not for a Windows VM +Last version of Virtio drivers are installed in Windows. + +Here are the issues i can see in windows : + + +Windows Events of virtio input driver device : + +``` +Device PCI\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\3&2411e6fe&0&18 had a problem starting. +Driver Name: oem7.inf +Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da} +Service: VirtioInput +Lower Filters: +Upper Filters: +Problem: 0xA +Problem Status: 0xC000009A +``` +Qemu didnt produce any logs regarding this PCI + +Do I miss something ? + +Thanks for your help diff --git a/results/classifier/gemma3:12b/peripherals/204 b/results/classifier/gemma3:12b/peripherals/204 new file mode 100644 index 000000000..95de6a039 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/204 @@ -0,0 +1,2 @@ + +Dos Keypad is not working for numbers - numlock is not working diff --git a/results/classifier/gemma3:12b/peripherals/205 b/results/classifier/gemma3:12b/peripherals/205 new file mode 100644 index 000000000..ce46130b2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/205 @@ -0,0 +1,2 @@ + +Arrow keys press is double in some programs in Dos diff --git a/results/classifier/gemma3:12b/peripherals/2055 b/results/classifier/gemma3:12b/peripherals/2055 new file mode 100644 index 000000000..1e65ac565 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2055 @@ -0,0 +1,8 @@ + +Unable to set the PBMTE bit in the menvcfg register for RISCV 64 bit +Description of problem: +We are unable to program the PBMTE bit in the menvcfg register of a RV64 machine. The following is the command that was used to do this. + +write_csr(menvcfg,PTE_PBMT); +Steps to reproduce: +1. A simple test program with the above command should be able to reproduce this issue. diff --git a/results/classifier/gemma3:12b/peripherals/2066 b/results/classifier/gemma3:12b/peripherals/2066 new file mode 100644 index 000000000..a7fb9267d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2066 @@ -0,0 +1,2 @@ + +Feature Request: UART 8250 Support in QEMU Virt Machine for aarch64 diff --git a/results/classifier/gemma3:12b/peripherals/2073 b/results/classifier/gemma3:12b/peripherals/2073 new file mode 100644 index 000000000..f2053bb6c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2073 @@ -0,0 +1,17 @@ + +Audio: missing ability to disable microphone input from host? +Description of problem: +**It appears there is no way to disable the microphone / input to the audio backend device(s).** + + +There are at least two cases where this matters: +1. The host has no microphone input (e.g. only HDMI audio output with video). +2. The host has a microphone input, but the user doesn't want the guest VM to have access to the microphone/input. + +I tried the option in.channels=0, as that seemed the most obvious way, though that doesn't work. + +For -audio dsound, it appears that CLSID_DirectSoundCapture is unconditionally acquired. + +There will also be later periodic warning/text outputs from QEMU "Could not create a backend for voice virtio.in", if you're running on a host system with no audio input device. + +Adding a couple backend checks for channels > 0 may work well. Not sure if it matters that audio front end device in the VM still thinks there is an audio input. diff --git a/results/classifier/gemma3:12b/peripherals/2084 b/results/classifier/gemma3:12b/peripherals/2084 new file mode 100644 index 000000000..137c61d30 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2084 @@ -0,0 +1,2 @@ + +"qemu-system-arm -machine virt -cpu cortex-a9" error message includes a lot of "(null)"s diff --git a/results/classifier/gemma3:12b/peripherals/2093 b/results/classifier/gemma3:12b/peripherals/2093 new file mode 100644 index 000000000..666e2ff53 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2093 @@ -0,0 +1,4 @@ + +m68k: virt: Add command to virt-ctrl device to pause cpu until an interrupt happens +Additional information: +I'm working on how to implement this myself. Any hints would be great. diff --git a/results/classifier/gemma3:12b/peripherals/2114 b/results/classifier/gemma3:12b/peripherals/2114 new file mode 100644 index 000000000..0b8dbc9ea --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2114 @@ -0,0 +1,2 @@ + +hw/char/riscv_htif.c and hw/char/sifive_uart call qemu_chr_fe_write() and ignore return value diff --git a/results/classifier/gemma3:12b/peripherals/2139 b/results/classifier/gemma3:12b/peripherals/2139 new file mode 100644 index 000000000..79a405e9e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2139 @@ -0,0 +1,10 @@ + +Super/Win key seems to release immediately on sdl+windows +Description of problem: +Currently on windows when trying SerenityOS the super key releases immediately so you can't use the shortcuts, with the GTK gui (gl off) it works though. but GTK has other problems with mouse which sometimes doesn't work at all, SDL seems to work well besides from this one issue. +Steps to reproduce: +1. Boot with default settings on wsl2 which launches qemu on windows if it's installed +2. Try to use any of the superkey shortcuts like superkey+space for a search popup https://github.com/SerenityOS/serenity/blob/dc47d01fdc62a1ee319310e2b11c26b8ebe8899d/Base/usr/share/man/man7/KeyboardShortcuts.md#L4 +3. Fail because it immediately opens the menu blocking the shortcuts. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2147 b/results/classifier/gemma3:12b/peripherals/2147 new file mode 100644 index 000000000..61420dfee --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2147 @@ -0,0 +1,10 @@ + +The Windows version of QEMU runs the semihost project without printing +Description of problem: +In Linux, running this command to execute the Semihost project will print `Hello World` in the console, but running in Windows will not print anything. + +I'd like to know if it's the windows version of qemu that doesn't have perfect support for semihost, or if I need to adjust the input parameters. +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2167 b/results/classifier/gemma3:12b/peripherals/2167 new file mode 100644 index 000000000..91b9e505a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2167 @@ -0,0 +1,41 @@ + +The GPIO controllers connected to the emulated PCIe bus via vhost-user can't generate interrupts. +Description of problem: +The problem is related to emulation of GPIO controllers using the vhost-user protocol for GPIO. The problem was detected when using the [vhost-device-gpio](https://github.com/rust-vmm/vhost-device) software. I have described the whole issue in https://github.com/rust-vmm/vhost-device/issues/613 , but it is QEMU related, and therefore I describe it here as well. +The broader context is described in https://stackoverflow.com/questions/75906208/how-to-connect-via-virtio-gui-running-on-host-with-gpio-in-a-qemu-emulated-virtu . +Steps to reproduce: +1. For Debian/testing you need to compile a libgpiod-2.1.1 (I assume that the following is done in the home directory directory of the `dev` user: `/home/dev`): + + ``` + wget https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/snapshot/libgpiod-2.1.tar.gz ; \ + tar -xzf libgpiod-2.1.tar.gz ; \ + cd libgpiod-2.1 ; \ + autoupdate ; \ + ./autogen.sh ; \ + make + ``` + 2. Download the vhost-device-gpio (`git clone https://github.com/rust-vmm/vhost-device.git`) + 3. Build the vhost-device-gpio (in the `vhost-device-gpio` subdirectory) + + ``` + export PATH_TO_LIBGPIOD=/home/dev/libgpiod-2.1 + export SYSTEM_DEPS_LIBGPIOD_NO_PKG_CONFIG=1 + export SYSTEM_DEPS_LIBGPIOD_SEARCH_NATIVE="${PATH_TO_LIBGPIOD}/lib/.libs/" + export SYSTEM_DEPS_LIBGPIOD_LIB=gpiod + export SYSTEM_DEPS_LIBGPIOD_INCLUDE="${PATH_TO_LIBGPIOD}/include/" + cargo build --features "mock_gpio" + ``` + 4. Start vhost-device-gpio: (`LD_LIBRARY_PATH=/home/emb/libgpiod-2.1/lib/.libs/ ./vhost-device-gpio -s /tmp/gpio.sock -l s4`) + 5. Download the Buildroot 2023.11.1 (`wget https://buildroot.org/downloads/buildroot-2023.11.1.tar.xz` in another directory) and unpack it. Buildroot and the main directory of Buildroot tree are denoted by BR if the following description. + 6. Configure BR (run `make qemu_aarch64_virt_defconfig` in the main BR directory, run `make menuconfig` and select external toolchain, `BR2_PACKAGE_LIBGPIOD=y`, `BR2_PACKAGE_LIBGPIOD_TOOLS=y`, run `make linux-menuconfig` and select `CONFIG_GPIO_VIRTIO=m` in the kernel configuration) + 7. Build the Linux and QEMU (run `make` in the BR directory). + 8. Run the emulation in BR/output/images, using the command line given above. + 9. After the virtual machine starts, log in as root and load the driver: `modprobe gpio-virtio` +10. Try to monitor changes of one of the emulated pins: `gpiomon 0 0` +11. You'll get the error message: + + ``` + gpiomon: error waiting for events: No such device + ``` +Additional information: +[0009-enable-F-IRQ-in-virtio-pci.patch](/uploads/39bc04b2d94063ccd539c5cfbc9cd105/0009-enable-F-IRQ-in-virtio-pci.patch) diff --git a/results/classifier/gemma3:12b/peripherals/2178 b/results/classifier/gemma3:12b/peripherals/2178 new file mode 100644 index 000000000..568a98fc0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2178 @@ -0,0 +1,18 @@ + +USB passthrough on Apple Silicon is unusable +Description of problem: +I can't get USB passthrough to work sufficiently well with wifi modems such as the RTL8187L or Atheros AR 9271. + +I only use the VM as a router since the host OS doesn't have drivers for any external wifi modems. This is a setup I've used flawlessly many times in the past with other VMs on x86 platforms for many years, but with ARM it's been one fail after another. Parallels does work with the exact same host and guest, but fails in the networking area (plus it's expensive and overkill for something this simple). I mention this because I know the guest drivers work 100% with a different VM. +Steps to reproduce: +1. Run any Linux on QEMU on any Apple Silicon mac +2. Attempt to use a Atheros AR 9271 USB device +3. Various fails including + a) USB device not showing up (lsusb) + b) device shows up and Linux attempts to attach driver, but fails (lsmod shows driver loaded but no interface listed on iwconfig) + c) interface shows up (never got the Atheros this far, but RealTek does) but the interface is slow, corrupts data, etc. + d) after re-attaching several times it will eventually stop attaching at all requiring a MacOS system reboot, which is really annoying for my workflow. + +It's basically non-functional for me. Atheros is 100% non-functional and RealTek 10% works (well enough to *sometimes* connect to the AP, but usually craps the bed if you try to do anything as simple as run a dhcp client to fetch the IP). + +If anyone knows of any other Linux ARM on Mac ARM vm solutions that allow USB passthrough please let me know. Unfortunately, VirtualBox os currently not one of them. diff --git a/results/classifier/gemma3:12b/peripherals/220 b/results/classifier/gemma3:12b/peripherals/220 new file mode 100644 index 000000000..8166dc499 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/220 @@ -0,0 +1,2 @@ + +Broken mouse movement inside MS-DOS for at least one program diff --git a/results/classifier/gemma3:12b/peripherals/2243 b/results/classifier/gemma3:12b/peripherals/2243 new file mode 100644 index 000000000..134f6f82d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2243 @@ -0,0 +1,10 @@ + +ES1370 sound card can crash the Windows 2000 and Windows XP guest. +Description of problem: +If using ES1370 sound card with Windows 2000 and Windows XP guest, it will crash the Windows 2000 and Windows XP guest. Windows 2000 and Windows XP have built in ES1370 driver. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2245 b/results/classifier/gemma3:12b/peripherals/2245 new file mode 100644 index 000000000..dc90dd981 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2245 @@ -0,0 +1,2 @@ + +RISC-V Extensions query for QEMU System diff --git a/results/classifier/gemma3:12b/peripherals/2269 b/results/classifier/gemma3:12b/peripherals/2269 new file mode 100644 index 000000000..067b118e8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2269 @@ -0,0 +1,42 @@ + +RISC-V exit via sifive_test does not work in scripts with -serial stdio +Description of problem: + +Steps to reproduce: +1. Create assembly file `hello.s`: +```as +.section .text +.globl _start +_start: csrr t0, mhartid + bnez t0, _start + li t0, 0x100000 + li t1, 0x5555 + sw t1, 0(t0) +halt: j halt +``` +2. Create linker script `link.ld`: +```ld +OUTPUT_ARCH( "riscv" ) +ENTRY(_start) +SECTIONS +{ + . = 0x80000000; +} +``` +3. Create runner script `./run.sh` (don't forget to `chmod +x`) +```sh +#!/usr/bin/env bash +timeout 10 qemu-system-riscv64 -M virt -display none -serial stdio -bios none -kernel hello +``` +4. Compile into executable: +```sh +riscv64-unknown-elf-gcc -c -mcmodel=medany -fvisibility=hidden -nostartfiles -march=rv64g -mabi=lp64 -o hello.o hello.s +riscv64-unknown-elf-ld hello.o -nostdlib -T link.ld -o hello +``` +5. Dot-source the script - it will immediately exit cleanly +6. Execute the script - it will timeout with exit code 124 +7. Execute the script with redirected stdin, e.g. `./run.sh < ./run.sh` or `echo | ./run.sh` - it will immediately exit cleanly +Additional information: +This issue happens only with `-serial stdio`. Using `chardev:file` or `chardev:null` does not reproduce the issue. Process substitution like `<(echo 'test')` does not seem to work. `cat | ./run.sh` will wait until any line is send, then exit cleanly. This is mainly an issue when using helper test scripts which want to interact with user, as proper CI/UT would redirect serial anyways. + +I have noticed similar behavior with other RISC-V UART device - when running from scripts, there is no output, as if QEMU was waiting for something, even if there is only UART TX, not RX. It does not matter if I actually type in anything or not. diff --git a/results/classifier/gemma3:12b/peripherals/2306 b/results/classifier/gemma3:12b/peripherals/2306 new file mode 100644 index 000000000..b02392b72 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2306 @@ -0,0 +1,2 @@ + +A bug of ptimer that the freq can't set more than 1000M diff --git a/results/classifier/gemma3:12b/peripherals/2308 b/results/classifier/gemma3:12b/peripherals/2308 new file mode 100644 index 000000000..f576dccb3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2308 @@ -0,0 +1,80 @@ + +QEMU Windows COM port setup dialog always invoked and fails if none is available (USB or virtual serial port hardware) +Description of problem: +The Windows backend serial port in `chardev/char-win.c` always calls `CommConfigDialog()`. This should display a COM port configuration dialog which does (and can) not persist the COM port settings. If the COM port does not support this action (see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-commconfigdialoga) then the function fails. +Steps to reproduce: +1. Currently not possible with QEMU releases as QEMU does not recognize extended COM port specifications like `\\.\COM19` or `\\.\CNCA0` +Additional information: +See https://support.microsoft.com/en-gb/topic/howto-specify-serial-ports-larger-than-com9-db9078a5-b7b6-bf00-240f-f749ebfd913e for details on COM port filenames. + +I have a patch which 'fixes' this problem by setting the nominated COM port to defaults of `115200,8,N,0` which seems perfectly sensible in 2024. Please contact me for more details. A git diff shown below (with extensive error reporting) + +N.B. Markodown will destroy formatting! + +``` +diff --git a/chardev/char-win.c b/chardev/char-win.c +index d4fb44c4dc..a05896ffe9 100644 +--- a/chardev/char-win.c ++++ b/chardev/char-win.c +@@ -96,12 +96,24 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp) + s->file = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0, NULL, + OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0); + if (s->file == INVALID_HANDLE_VALUE) { ++ { ++ char buffer[1024] = { 0 }; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename); ++ OutputDebugString(buffer); ++ } + error_setg_win32(errp, GetLastError(), "Failed CreateFile"); + s->file = NULL; + goto fail; + } + + if (!SetupComm(s->file, NRECVBUF, NSENDBUF)) { ++ { ++ char buffer[1024] = { 0 }; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename); ++ OutputDebugString(buffer); ++ } + error_setg(errp, "Failed SetupComm"); + goto fail; + } +@@ -110,9 +122,31 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp) + size = sizeof(COMMCONFIG); + GetDefaultCommConfig(filename, &comcfg, &size); + comcfg.dcb.DCBlength = sizeof(DCB); +- CommConfigDialog(filename, NULL, &comcfg); +- ++#if 1 ++ // JME hardwire. There seems to be no mechanism to simply specify serial port options ++ comcfg.dcb.BaudRate = 115200; ++ comcfg.dcb.Parity = NOPARITY; ++ comcfg.dcb.StopBits = ONESTOPBIT; ++ comcfg.dcb.ByteSize = 8; ++#else ++ { ++ BOOL ret = CommConfigDialog(filename, NULL, &comcfg); ++ if (!ret) ++ { ++ char buffer[1024] = { 0 }; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename); ++ OutputDebugString(buffer); ++ } ++ } ++#endif + if (!SetCommState(s->file, &comcfg.dcb)) { ++ { ++ char buffer[1024]={0}; ++ DWORD dw = GetLastError(); ++ sprintf_s(buffer,1024,"%s(%d) Error: %d 0x%x %s\r\n",__FILE__,__LINE__,dw,dw, filename); ++ OutputDebugString(buffer); ++ } + error_setg(errp, "Failed SetCommState"); + goto fail; + } +``` + +/label ~"kind::Bug" diff --git a/results/classifier/gemma3:12b/peripherals/2312 b/results/classifier/gemma3:12b/peripherals/2312 new file mode 100644 index 000000000..a27ce9c73 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2312 @@ -0,0 +1,45 @@ + +hvf_vcpu_exec isv assert with qemu-xhci device +Description of problem: +Using the qemu-xhci device with HVF on darwin-aarch64 causes [this assert](https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1920) to fire. + +``` +travis@gmachine vms % cat launch.sh +#!/usr/bin/env bash + +~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 \ + -nographic \ + -machine virt \ + -accel hvf \ + -cpu host \ + -m 16M \ + -device qemu-xhci \ + -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin +travis@gmachine vms % ./launch.sh + + +U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000) + +DRAM: 16 MiB (effective 16 EiB) +Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1920. +./launch.sh: line 10: 22295 Abort trap: 6 ~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin +``` + +This is NixOS' build of u-boot 2024.04. This is also Nixpkgs' build of qemu-9.0.0; by default it contains some patches, but if I remove those and build with the unmodified release tarball there's no change in behavior. Naturally this doesn't happen with TCG and I haven't found any other (non-USB) device to cause this issue. +Steps to reproduce: +On a darwin-aarch64 machine with git and nix setup (8.2.2 is latest in Nixpkgs head, the same problem occurs with 9.0.0): + +``` +% git clone https://github.com/nixos/nixpkgs +% cd ./nixpkgs +% $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios $(nix-build -E 'with import ./default.nix {system = "aarch64-linux";}; ubootQemuAarch64')/u-boot.bin + + +U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000) + +DRAM: 16 MiB (effective 16 EiB) +Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1915. +zsh: abort $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel +``` +Additional information: +I have not yet tried other u-boot binaries. I suppose it could be u-boots fault? Eyeballing hvf.c this seems to be an unhandled case in the MMIO callback? I'm far out of my element so that could be total nonsense. diff --git a/results/classifier/gemma3:12b/peripherals/2323 b/results/classifier/gemma3:12b/peripherals/2323 new file mode 100644 index 000000000..bb1e0c4b3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2323 @@ -0,0 +1,27 @@ + +Win/Super key not working correctly under Windows hosts +Description of problem: +I accidentally noticed `Win` key (VK_LWIN) not working correctly on Windows hosts, more specifically: + +1. It is impossible to "hold" `Win`. If one presses and holds `Win`, the guest is spammed with `Win` keypresses, instead of receiving a single `Win` keypress at the point of releasing the button (VK_LWIN button up). +2. It is impossible to make key combinations (shortcuts, hotkeys etc.) that involve the `Win/Super` key. Maybe implicitly solved by fixing #1. + +This behavior is present starting from bc8e883065f36581e4f2352c31a1dfa5f65a82f2 (ui/sdl2: disable SDL_HINT_GRAB_KEYBOARD on Windows). Before it, on the SDL2 keyboard hook `Win/Super` key worked correctly. I demonstrate the problem on Fedora/WinXP, but it affects all guests. +Steps to reproduce: +1. (see additional information) +2. +3. +Additional information: +Short video demonstration on a WinXP guest and a Fedora 39 guest. The qemus used are (qemu-8.0.2 e0968d21e27ef9c406f709180a39a076e786efbe; working correctly) and (qemu-9.0.0 from the release tarball qemu-9.0.0.tar.xz; buggy) + +1. In the WinXP video, I'm pressing and holding the `Win` key for about 3 seconds. In the correct version, the start menu is opened only at the point of release. In the buggy version, the start menu is opened repeatedly tens of times (flickering). You can see the point of release in Nirsoft's KeyboardStateView, when VK_LWIN loses the "pressed" asterisk. + + At the end of the video I'm trying to use the `Win+e` shortcut for WinExplorer. In the buggy version, Outlook is opened instead. This is because the keypresses are processed individually, first `Win` opens the start menu and then `e` opens email application (in this case outlook). In the correct version WinExplorer is opened. + +  +  + +2. In the Fedora video, I'm trying to set up a simple shortcut, I'm pressing on my keyboard `LCTRL+LALT+Super+E`. In the buggy version, the `Super` key is not picked up. All the shortcut combinations involving `Super` are therefore not working. + +  +  diff --git a/results/classifier/gemma3:12b/peripherals/2343 b/results/classifier/gemma3:12b/peripherals/2343 new file mode 100644 index 000000000..44da65d48 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2343 @@ -0,0 +1,32 @@ + +pflash write timeout u-boot@qemu-system-aarch64 +Description of problem: +Emulating the write into flash of environment variables within U-boot is not possible anymore. This works natively in Fedora 39 which has the 8.1.3 qemu version. Stopped working after transitioning to Fedora 40 which currently comes with 8.2.2, also doesn't work with Debian 12 which has 7.2.9. + +The write fails with the following message: + +``` +=> saveenv +Saving Environment to Flash... Un-Protected 2 sectors +Erasing Flash... +.. done +Erased 2 sectors +Writing to Flash... pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +Flash buffer write timeout at address 4000000 data ffffffffb64f6361 +Timeout writing to Flash +Protected 2 sectors +Failed (1) +``` +Steps to reproduce: +1. Download or build u-boot for aarch64 qemu. You can extract from u-boot-qemu debian package https://packages.debian.org/unstable/u-boot-qemu . +2. `truncate -s 64m varstore.img` +3. `qemu-system-aarch64 -machine virt -cpu cortex-a35 -nographic -smp 2 -m 1G -bios u-boot.bin -drive if=pflash,format=raw,file=varstore.img,readonly=off,index=1 -d guest_errors,unimp` +Additional information: +After building versions 8.1.3 and 8.1.4 I found both were working fine regartheless the host OS, the issue was introduced in 8.1.5. +After inspecting commits history I drop the following commit [hw/pflash: implement update buffer for block writes (hash:fcc79f2e09550b0461792491965fe202ed2219ae)](https://gitlab.com/qemu-project/qemu/-/commit/fcc79f2e09550b0461792491965fe202ed2219ae) rebuilt and the issue was gone. +I then recheck all non working versions and both versions 8.2.2 and 7.2.9 also have this commit, this explains why it also doesn't work. +I attached a trace running with v8.1.5 and v8.1.5 with drop commit. +[v8.1.5.log](/uploads/04aa0e24e1e16f6bdf29a6e6be587ba1/v8.1.5.log) +[v8.1.5-drop-fcc79f2e.log](/uploads/206fe958ab78c12542fda3764df978da/v8.1.5-drop-fcc79f2e.log) diff --git a/results/classifier/gemma3:12b/peripherals/2347 b/results/classifier/gemma3:12b/peripherals/2347 new file mode 100644 index 000000000..72d44864c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2347 @@ -0,0 +1,10 @@ + +Grab Input not working only for Windows key +Description of problem: +When Input Grabbing is enabled (as seen in the menu and the Qemu window title itself), a press on the Windows key will also send that press to the host system (Arch / KDE). + +I expected all inputs to be grabbed and stay within the VM. +Steps to reproduce: +1. Open a QEMU instance in a Arch / KDE host (not fullscreen) +2. Focus the instance and enable Input Grabbing (Ctrl + Alt + G) +3. Press the Windows key diff --git a/results/classifier/gemma3:12b/peripherals/2349 b/results/classifier/gemma3:12b/peripherals/2349 new file mode 100644 index 000000000..101f8336c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2349 @@ -0,0 +1,13 @@ + +keyboard (and mouse) not working in macOS guest +Description of problem: +keyboard not working after exiting EFI environment. it works in the OpenCore boot picker, but not in the recovery system. The mouse can work by forcing the PS2 controller and pause/resume the VM. See here for more details: +https://github.com/utmapp/UTM/issues/5240#issuecomment-2112477131 +Tried adding ps2 kexts, but qemu USB keyboard, mouse and tablet do not attach to the AppleUSBEHCI bus. It works fine in Snow Leopard only as evident in the picture on the Github issue. +Steps to reproduce: +1.Install macOS guest Mavericks through Sierra using https://github.com/royalgraphx/LegacyOSXKVM/blob/main/info/CONVERSIONS.md +2.https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot-macOS.sh +3. +Additional information: +[command.txt](/uploads/3af8e5476833a1f869debc4fbfe97e84/command.txt) +[EFI.zip](/uploads/3f49054b496b19244ebb111cf07ed05a/EFI.zip) diff --git a/results/classifier/gemma3:12b/peripherals/2355 b/results/classifier/gemma3:12b/peripherals/2355 new file mode 100644 index 000000000..46b2c31af --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2355 @@ -0,0 +1,80 @@ + +buffer overflow in aspeed gpio +Description of problem: +The following log reveals it: + +``` +==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88 +READ of size 2 at 0x55a5da29e128 thread T0 + #0 0x55a5d700dc61 in aspeed_gpio_read /home/joey/repo/qemu/build/../hw/gpio/aspeed_gpio.c:564:14 + #1 0x55a5d933f3ab in memory_region_read_accessor /home/joey/repo/qemu/build/../system/memory.c:445:11 + #2 0x55a5d92fba40 in access_with_adjusted_size /home/joey/repo/qemu/build/../system/memory.c:573:18 + #3 0x55a5d92f842c in memory_region_dispatch_read1 /home/joey/repo/qemu/build/../system/memory.c:1426:16 + #4 0x55a5d92f7b68 in memory_region_dispatch_read /home/joey/repo/qemu/build/../system/memory.c:1459:9 + #5 0x55a5d9376ad1 in flatview_read_continue_step /home/joey/repo/qemu/build/../system/physmem.c:2836:18 + #6 0x55a5d9376399 in flatview_read_continue /home/joey/repo/qemu/build/../system/physmem.c:2877:19 + #7 0x55a5d93775b8 in flatview_read /home/joey/repo/qemu/build/../system/physmem.c:2907:12 + #8 0x55a5d9377078 in address_space_read_full /home/joey/repo/qemu/build/../system/physmem.c:2920:18 + #9 0x55a5d8189aa2 in address_space_read /home/joey/repo/qemu/include/exec/memory.h:3100:18 + #10 0x55a5d8189aa2 in qtest_process_command /home/joey/repo/qemu/build/../system/qtest.c:597:13 + #11 0x55a5d818231d in qtest_process_inbuf /home/joey/repo/qemu/build/../system/qtest.c:811:9 + #12 0x55a5d81915ae in qtest_read /home/joey/repo/qemu/build/../system/qtest.c:823:5 + #13 0x55a5d9bc115d in qemu_chr_be_write_impl /home/joey/repo/qemu/build/../chardev/char.c:214:9 + #14 0x55a5d9bc1219 in qemu_chr_be_write /home/joey/repo/qemu/build/../chardev/char.c:226:9 + #15 0x55a5d9bccd25 in fd_chr_read /home/joey/repo/qemu/build/../chardev/char-fd.c:72:9 + #16 0x55a5d95d958c in qio_channel_fd_source_dispatch /home/joey/repo/qemu/build/../io/channel-watch.c:84:12 + #17 0x7f8909babc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) + #18 0x55a5d9f62319 in glib_pollfds_poll /home/joey/repo/qemu/build/../util/main-loop.c:287:9 + #19 0x55a5d9f60c53 in os_host_main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:310:5 + #20 0x55a5d9f6081c in main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:589:11 + #21 0x55a5d8198807 in qemu_main_loop /home/joey/repo/qemu/build/../system/runstate.c:796:9 + #22 0x55a5d9544c6c in qemu_default_main /home/joey/repo/qemu/build/../system/main.c:37:14 + #23 0x55a5d9544cb7 in main /home/joey/repo/qemu/build/../system/main.c:48:12 + #24 0x7f8909229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #25 0x7f8909229e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + #26 0x55a5d671ed34 in _start (/home/joey/repo/qemu/build/qemu-system-aarch64+0x2773d34) + +0x55a5da29e128 is located 24 bytes to the left of global variable '<string literal>' defined in '../hw/gpio/aspeed_gpio.c:1180:23' (0x55a5da29e140) of size 20 + '<string literal>' is ascii string 'aspeed.gpio-ast2500' +0x55a5da29e128 is located 22 bytes to the right of global variable '<string literal>' defined in '/home/joey/repo/qemu/include/hw/gpio/aspeed_gpio.h:17:1' (0x55a5da29e100) of size 18 + '<string literal>' is ascii string 'ASPEED_GPIO_CLASS' +SUMMARY: AddressSanitizer: global-buffer-overflow /home/joey/repo/qemu/build/../hw/gpio/aspeed_gpio.c:564:14 in aspeed_gpio_read +Shadow bytes around the buggy address: + 0x0ab53b44bbd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0ab53b44bbe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0ab53b44bbf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0ab53b44bc00: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 + 0x0ab53b44bc10: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 +=>0x0ab53b44bc20: 00 00 02 f9 f9[f9]f9 f9 00 00 04 f9 f9 f9 f9 f9 + 0x0ab53b44bc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0ab53b44bc40: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 04 f9 + 0x0ab53b44bc50: f9 f9 f9 f9 00 00 00 01 f9 f9 f9 f9 00 00 00 00 + 0x0ab53b44bc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0ab53b44bc70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-aarch64 -display \ +none -machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio +readq 0x7e780272 +EOF +``` diff --git a/results/classifier/gemma3:12b/peripherals/2356 b/results/classifier/gemma3:12b/peripherals/2356 new file mode 100644 index 000000000..163bb9e48 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2356 @@ -0,0 +1,16 @@ + +assert in stm32l4x5_rcc +Description of problem: +The following log reveals it: + +``` +qemu-system-aarch64: ../hw/misc/stm32l4x5_rcc.c:546: void rcc_update_cfgr_register(Stm32l4x5RccState *): Assertion `val <= 0b100' failed. +Aborted +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-aarch64 -display \ +none -machine accel=qtest, -m 512M -machine b-l475e-iot01a -qtest stdio +writeq 0x40021008 0xffffffff +EOF +``` diff --git a/results/classifier/gemma3:12b/peripherals/2358 b/results/classifier/gemma3:12b/peripherals/2358 new file mode 100644 index 000000000..2fb591668 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2358 @@ -0,0 +1,51 @@ + +null-pointer-dereference in a9gtimer +Description of problem: +The following log reveals it: + +``` +../hw/timer/a9gtimer.c:51:22: runtime error: member access within null pointer of type 'CPUState' (aka 'struct CPUState') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/timer/a9gtimer.c:51:22 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==2624453==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000002d0 (pc 0x55df9673422f bp 0x7fff7310e930 sp 0x7fff7310e8a0 T0) +==2624453==The signal is caused by a READ memory access. +==2624453==Hint: address points to the zero page. + #0 0x55df9673422f in a9_gtimer_get_current_cpu /home/joey/repo/qemu/build/../hw/timer/a9gtimer.c:51:22 + #1 0x55df9673408c in a9_gtimer_this_write /home/joey/repo/qemu/build/../hw/timer/a9gtimer.c:246:14 + #2 0x55df97e00353 in memory_region_write_accessor /home/joey/repo/qemu/build/../system/memory.c:497:5 + #3 0x55df97dffa40 in access_with_adjusted_size /home/joey/repo/qemu/build/../system/memory.c:573:18 + #4 0x55df97dfd986 in memory_region_dispatch_write /home/joey/repo/qemu/build/../system/memory.c:1521:16 + #5 0x55df97ea8973 in flatview_write_continue_step /home/joey/repo/qemu/build/../system/physmem.c:2755:18 + #6 0x55df97ea81df in flatview_write_continue /home/joey/repo/qemu/build/../system/physmem.c:2785:19 + #7 0x55df97e7be4b in flatview_write /home/joey/repo/qemu/build/../system/physmem.c:2816:12 + #8 0x55df97e7b908 in address_space_write /home/joey/repo/qemu/build/../system/physmem.c:2936:18 + #9 0x55df96c8b041 in qtest_process_command /home/joey/repo/qemu/build/../system/qtest.c:559:13 + #10 0x55df96c8631d in qtest_process_inbuf /home/joey/repo/qemu/build/../system/qtest.c:811:9 + #11 0x55df96c955ae in qtest_read /home/joey/repo/qemu/build/../system/qtest.c:823:5 + #12 0x55df986c515d in qemu_chr_be_write_impl /home/joey/repo/qemu/build/../chardev/char.c:214:9 + #13 0x55df986c5219 in qemu_chr_be_write /home/joey/repo/qemu/build/../chardev/char.c:226:9 + #14 0x55df986d0d25 in fd_chr_read /home/joey/repo/qemu/build/../chardev/char-fd.c:72:9 + #15 0x55df980dd58c in qio_channel_fd_source_dispatch /home/joey/repo/qemu/build/../io/channel-watch.c:84:12 + #16 0x7f76346edc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) + #17 0x55df98a66319 in glib_pollfds_poll /home/joey/repo/qemu/build/../util/main-loop.c:287:9 + #18 0x55df98a64c53 in os_host_main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:310:5 + #19 0x55df98a6481c in main_loop_wait /home/joey/repo/qemu/build/../util/main-loop.c:589:11 + #20 0x55df96c9c807 in qemu_main_loop /home/joey/repo/qemu/build/../system/runstate.c:796:9 + #21 0x55df98048c6c in qemu_default_main /home/joey/repo/qemu/build/../system/main.c:37:14 + #22 0x55df98048cb7 in main /home/joey/repo/qemu/build/../system/main.c:48:12 + #23 0x7f7633e29d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #24 0x7f7633e29e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + #25 0x55df95222d34 in _start (/home/joey/repo/qemu/build/qemu-system-aarch64+0x2773d34) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/joey/repo/qemu/build/../hw/timer/a9gtimer.c:51:22 in a9_gtimer_get_current_cpu +==2624453==ABORTING +``` +Steps to reproduce: +``` +cat << EOF | /home/joey/repo/qemu/build/qemu-system-aarch64 -display \ +none -machine accel=qtest, -m 512M -machine npcm750-evb -qtest stdio +writel 0xf03fe20c 0x26d7468c +EOF +``` diff --git a/results/classifier/gemma3:12b/peripherals/242 b/results/classifier/gemma3:12b/peripherals/242 new file mode 100644 index 000000000..61edb260f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/242 @@ -0,0 +1,2 @@ + +Implementation of Virtual Battery for Battery Status diff --git a/results/classifier/gemma3:12b/peripherals/2432 b/results/classifier/gemma3:12b/peripherals/2432 new file mode 100644 index 000000000..d0d8c135f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2432 @@ -0,0 +1,71 @@ + +Bug in bcm2835_thermal interface +Description of problem: +Stack traces, crash detail: +``` +#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:44 +#1 __pthread_kill_internal (signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:78 +#2 __GI___pthread_kill (threadid=140737230841344, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 +#3 0x00007ffff5042476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#4 0x00007ffff50287f3 in __GI_abort () at ./stdlib/abort.c:79 +#5 0x00007ffff6f0eb57 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#6 0x00007ffff6f6870f in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x0000555555d642a6 in bcm2835_thermal_write (opaque=0x7ffff0a475b0, addr=2, value=0, size=2) + at ../hw/misc/bcm2835_thermal.c:76 +#8 0x0000555556c4a119 in memory_region_write_accessor + (mr=0x7ffff0a478e0, addr=2, value=0x7fffffffd250, size=2, shift=0, mask=65535, attrs=...) + at ../system/memory.c:497 +#9 0x0000555556c49da6 in access_with_adjusted_size + (addr=2, value=0x7fffffffd250, size=2, access_size_min=1, access_size_max=4, access_fn=0x555556c49ef0 <memory_region_write_accessor>, mr=0x7ffff0a478e0, attrs=...) at ../system/memory.c:573 +#10 0x0000555556c49395 in memory_region_dispatch_write (mr=0x7ffff0a478e0, addr=2, data=0, op=MO_16, attrs=...) + at ../system/memory.c:1521 +#11 0x0000555556c84e88 in flatview_write_continue_step + (attrs=..., buf=0x7fffffffd470 "", len=512, mr_addr=2, l=0x7fffffffd360, mr=0x7ffff0a478e0) + at ../system/physmem.c:2757 +#12 0x0000555556c84c42 in flatview_write_continue + (fv=0x555559717490, addr=1059135490, attrs=..., ptr=0x7fffffffd470, len=512, mr_addr=2, l=2, mr=0x7ffff0a478e0) at ../system/physmem.c:2787 +#13 0x0000555556c73305 in flatview_write + (fv=0x555559717490, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2818 +#14 0x0000555556c73179 in address_space_write +--Type <RET> for more, q to quit, c to continue without paging--c + (as=0x5555598056f0, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2938 +#15 0x0000555556c735df in address_space_set (as=0x5555598056f0, addr=1059135490, c=0 '\000', len=2025625, attrs=...) at ../system/physmem.c:2965 +#16 0x0000555555a95b66 in rom_reset (unused=0x0) at ../hw/core/loader.c:1284 +#17 0x0000555555ab872d in legacy_reset_hold (obj=0x5555598069b0, type=RESET_TYPE_COLD) at ../hw/core/reset.c:76 +#18 0x0000555556d7dbf4 in resettable_phase_hold (obj=0x5555598069b0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:180 +#19 0x0000555556d7d19f in resettable_container_child_foreach (obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resetcontainer.c:54 +#20 0x0000555556d7f4a4 in resettable_child_foreach (rc=0x555558b02f50, obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:92 +#21 0x0000555556d7da92 in resettable_phase_hold (obj=0x5555595573d0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:169 +#22 0x0000555556d7d47a in resettable_assert_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:58 +#23 0x0000555556d7d2f7 in resettable_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:45 +#24 0x0000555555ab842e in qemu_devices_reset (reason=SHUTDOWN_CAUSE_NONE) at ../hw/core/reset.c:179 +#25 0x000055555633227d in qemu_system_reset (reason=SHUTDOWN_CAUSE_NONE) at ../system/runstate.c:493 +#26 0x0000555555aa6bd2 in qdev_machine_creation_done () at ../hw/core/machine.c:1643 +#27 0x000055555633679f in qemu_machine_creation_done (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2685 +#28 0x0000555556335ffd in qmp_x_exit_preconfig (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2715 +#29 0x000055555633bfe4 in qemu_init (argc=9, argv=0x7fffffffdc68) at ../system/vl.c:3759 +#30 0x0000555556d6eea2 in main (argc=9, argv=0x7fffffffdc68) at ../system/main.c:47 +``` +Description: +I encountered a part of the code during QEMU execution that shouldn't have been reached, which led to an error. + +Crash detail: +``` +ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached +Bail out! ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached +Aborted +``` + +Malicious inputs: +Malicious input is attached as tar.gz archive to this file, it contains file name id:000017,sig:06,src:000428,time:48261741,execs:1725363,op:havoc,rep:8 +[malicious_input.tar.gz](/uploads/fcf47faafb59308cfdb04b3e81e788f3/malicious_input.tar.gz) + +Affected code area/snippet: + +qemu/hw/misc/bcm2835_thermal.c:bcm2835_thermal_write + + +Acknowledge for reporting this issue: +Alisher Darmenov (darmenovalisher@gmail.com), +Mohamadreza Rostami (mohamadreza.rostami@trust.tu-darmstadt.de), +Ahmad-Reza Sadeghi (ahmad.sadeghi@trust.tu-darmstadt.de) diff --git a/results/classifier/gemma3:12b/peripherals/2462 b/results/classifier/gemma3:12b/peripherals/2462 new file mode 100644 index 000000000..69d791d3b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2462 @@ -0,0 +1,40 @@ + +QEMU SIFIVE reading from stdin hangs +Description of problem: +I have a simple test program (C and ASM) that reads from stdin. When i was using the qemu provided by Ubuntu, QEMU emulator version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.5), my test was working, and was able to read bytes from stdin. + +Using the latest Qemu from git, breaks my test. I can still print, but now reading hangs, like its always waiting for input but never getting it. + +My guess is that this commit breaks my code: +https://github.com/qemu/qemu/commit/6ee7ba1b8a10bd8eb1d3b918eaaf9f832a51adb4 + +Before the above commit, `qemu_chr_fe_set_handlers` was being called, and that is what allowed the default behavior of reading from stdin is on by default? + +from sifive_uart.c +``` + qemu_chr_fe_set_handlers(&s->chr, sifive_uart_can_rx, sifive_uart_rx, + sifive_uart_event, sifive_uart_be_change, s, + NULL, true); +``` +Steps to reproduce: +1. compile simple C program that calls `read` reading a single byte from stdin +2. do not initialize UART options +3. run in QEMU, send input, hangs. +Additional information: +Other examples online, like riscv-probe, use a uart init function like below: +``` +static void sifive_uart_init() +{ + uart = (int *)(void *)getauxval(SIFIVE_UART0_CTRL_ADDR); + uint32_t uart_freq = getauxval(UART0_CLOCK_FREQ); + uint32_t baud_rate = getauxval(UART0_BAUD_RATE); + uint32_t divisor = uart_freq / baud_rate - 1; + uart[UART_REG_DIV] = divisor; + uart[UART_REG_TXCTRL] = UART_TXEN; + uart[UART_REG_RXCTRL] = UART_RXEN; + uart[UART_REG_IE] = 0; +} +``` + +However, when I was using QEMU 8.0.4, i did not have to write a function like above to init UART, because stdin and stdout were working out of the box. +Below is my C and ASM: diff --git a/results/classifier/gemma3:12b/peripherals/2468 b/results/classifier/gemma3:12b/peripherals/2468 new file mode 100644 index 000000000..6c8d6ba0a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2468 @@ -0,0 +1,34 @@ + +m68k: movec to/from CAAR not emulated? +Description of problem: + +Steps to reproduce: +1. Start adding a machine for the Motorola MVME147 VME module +2. Step through the standard ROM for this board (147BUG) +3. Step until `ff823bf0 4e 7b 18 02 movec D1,CAAR` +4. Watch QEMU show a fatal error for an unimplemented control register: + +``` +QEMU 9.0.50 monitor - type 'help' for more information +(qemu) qemu: fatal: Unimplemented control register write 0x802 = 0xffffffff + +D0 = ffffffff A0 = fffe0000 F0 = 7fff ffffffffffffffff ( nan) +D1 = ffffffff A1 = 00000000 F1 = 7fff ffffffffffffffff ( nan) +D2 = ffff271f A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = ffffffff A3 = 00000000 F3 = 7fff ffffffffffffffff ( nan) +D4 = ffffffff A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan) +D5 = ffffffff A5 = 00000400 F5 = 7fff ffffffffffffffff ( nan) +D6 = ffffffff A6 = 00000000 F6 = 7fff ffffffffffffffff ( nan) +D7 = ffffffff A7 = 000037dc F7 = 7fff ffffffffffffffff ( nan) +PC = ff823bf0 SR = 2714 T:0 I:7 SI X-Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN + A7(MSP) = 00000000 A7(USP) = ffffffff ->A7(ISP) = 000037dc +VBR = 0xffffffff +SFC = 0 DFC 0 +SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000 +DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000 +MMUSR 00000000, fault at 00000000 +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/247 b/results/classifier/gemma3:12b/peripherals/247 new file mode 100644 index 000000000..50abb4672 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/247 @@ -0,0 +1,2 @@ + +qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers diff --git a/results/classifier/gemma3:12b/peripherals/2497 b/results/classifier/gemma3:12b/peripherals/2497 new file mode 100644 index 000000000..84d5e3eec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2497 @@ -0,0 +1,4 @@ + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/gemma3:12b/peripherals/2503 b/results/classifier/gemma3:12b/peripherals/2503 new file mode 100644 index 000000000..345063fb2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2503 @@ -0,0 +1,10 @@ + +how to install cmake scipt in QEMU with riscv +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2521 b/results/classifier/gemma3:12b/peripherals/2521 new file mode 100644 index 000000000..cabb294d3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2521 @@ -0,0 +1,17 @@ + +USB Passthrough Improper Remote Wakeup +Description of problem: +I am doing research with Linux Power Management interactions with USB devices. Which is why I would like to be able to wake a qemu vm from suspend with a passed through USB device. The first issue is that remote wakeup from usb devices do not wake the vm at all when running in -nographic mode (issuing system_wakeup from a qemu monitor shell will wake it though). When running with a GUI it is possible to wake the vm from a usb device as well as the qemu monitor shell but both will result in the GUI screen being black afterwards. It is still possible to use the vm though. Finally, waking the vm with a usb device is only possible when a valid usb device is passed through in the qemu launch command line. But interestingly the usb device specified to be passed through will only wakeup the vm if it is unplugged and plugged back in during the suspend. All other usb devices can wakeup the vm normally even though they are not passed through. It is not clear to me what is going on here and why other devices not being passed through to qemu can wake the vm. Note I have also enabled the /sys/bus/usb/devices/usb#/power/wakeup file and have manually unsuppressed the remote_wakeup flag in the source code to enable the /sys/bus/usb/devices/#-#/power/wakeup files to be generated but it has not affected anything. +Steps to reproduce: +I have tested this issue with multiple kernel versions (6.10, 6.10-rc4, 6.6.43) as well as custom and generic kernel configs and different debian images so these do not seem to be the problem. But here is a detailed description of the exact setup I am currently using: + +1. Download linux-6.10-rc4 source and configure with syzkaller fuzzing config https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-usb.config +2. Set CONFIG_KCOV_INSTRUMENT_ALL to off (breaks suspend/resume in vm) and create bzImage +2. Create a debian bookworm image with syzkaller script https://github.com/google/syzkaller/blob/master/tools/create-image.sh +3. Download and build Qemu from source (see attached for detailed configuration and dependencies) +4. Attach a usb keyboard and mouse +5. Choose one device to pass through via command line +6. Try waking the vm with nographic and graphic mode using the usb devices +Additional information: +[configuration_output.txt](/uploads/f7d3487dab65deef40bd0e110b64a573/configuration_output.txt) +[gui_wakeup_log.txt](/uploads/72b192a88d587eced4bb4032307307e5/gui_wakeup_log.txt) diff --git a/results/classifier/gemma3:12b/peripherals/2550 b/results/classifier/gemma3:12b/peripherals/2550 new file mode 100644 index 000000000..e15506a01 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2550 @@ -0,0 +1,26 @@ + +GICv3 vGIC system registers not initialized on ARM Cortex-A15 +Description of problem: +For Cortex-A15, the GICv3 vGIC registers are not initialized like for AArch64 CPUs, for example Cotex-A35, Cortex-A55, etc +Steps to reproduce: +The setup is not trivial. I can provide a boot image on request. But I hope the problem is straight-forward. +Additional information: +Suggested fix: +```diff +index 20c2737f17..136b513bda 100644 +--- a/target/arm/tcg/cpu32.c ++++ b/target/arm/tcg/cpu32.c +@@ -569,6 +569,12 @@ static void cortex_a15_initfn(Object *obj) + cpu->ccsidr[1] = 0x201fe00a; /* 32K L1 icache */ + cpu->ccsidr[2] = 0x711fe07a; /* 4096K L2 unified cache */ + cpu->isar.reset_pmcr_el0 = 0x410F3000; ++ ++ /* From B3.5 VGIC Type register */ ++ cpu->gic_num_lrs = 4; ++ cpu->gic_vpribits = 5; ++ cpu->gic_vprebits = 5; ++ + define_arm_cp_regs(cpu, cortexa15_cp_reginfo); + } + +``` diff --git a/results/classifier/gemma3:12b/peripherals/2551 b/results/classifier/gemma3:12b/peripherals/2551 new file mode 100644 index 000000000..0847254f6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2551 @@ -0,0 +1,14 @@ + +RTC time could run slow 3s than host time when clock=vm & base=UTC +Description of problem: +When start qemu with `-rtc base=utc,clock=vm`, sometime guest time can slower 3s than host. There's no problem (also didn't be noticed) as we often start ntp service, who will adjust our system time. But let's talk about if we havn't enable NTP service(for example system just booted) + +After inspect into the code, i found that there are two problem we should think about: +# +Steps to reproduce: +1. start vm with `-rtc base=utc,clock=vm` +2. disable NTP (OS specific)`systemctl disable --now ntpd;systemctl disable --now ntpdate` +3. reboot in the guest +4. after guest started, compare guest time with host time(at the same time) `date +'%F %T.%3N'` +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2561 b/results/classifier/gemma3:12b/peripherals/2561 new file mode 100644 index 000000000..e0d6a19b1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2561 @@ -0,0 +1,40 @@ + +Sound doesnt work on debian guest + debian host using Pipewire +Description of problem: +There is no sound on Debian Stable VM. Im using SPICE for audio redirection. +Steps to reproduce: +1. Download debian stable ISO (12 atm) +2. Install it on your KVM +3. Make sure your host and your guest are using pipewire (check https://wiki.debian.org/PipeWire#Installation) +4. No sound is transmitted to the host. +Additional information: +- I have tried switching SPICE to something else like ALSA, but it will result in hanging of the video page similar to this video: + +https://github.com/QubesOS/qubes-issues/issues/1698#issuecomment-1031376517 + +- Tried to use direct pipewire, but resulted into error: + +``` +Error starting domain: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package? + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + ^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup + self._backend.create() + File "/usr/lib/python3/dist-packages/libvirt.py", line 1379, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package? +``` + +Yes i have installed "qemu-system-gui" but still got the same message. + + +Debian XML with SPICE: + +[Debian-XML.txt](/uploads/66e09b37f672b49f8f0a0a01d3c6a6b2/Debian-XML.txt) diff --git a/results/classifier/gemma3:12b/peripherals/2619 b/results/classifier/gemma3:12b/peripherals/2619 new file mode 100644 index 000000000..d508623ec --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2619 @@ -0,0 +1,2 @@ + +INTEGER_OVERFLOW in nios2.c diff --git a/results/classifier/gemma3:12b/peripherals/2625 b/results/classifier/gemma3:12b/peripherals/2625 new file mode 100644 index 000000000..0bda855a9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2625 @@ -0,0 +1,84 @@ + +Adding TPM support for ARM SBSA-Ref machine +Additional information: +Here is a proposed change where a new memory region is added to the machine initialization routine: + +```diff +diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c +index e3195d5449..84bc7d9adb 100644 +--- a/hw/arm/sbsa-ref.c ++++ b/hw/arm/sbsa-ref.c +@@ -28,6 +28,8 @@ + #include "sysemu/numa.h" + #include "sysemu/runstate.h" + #include "sysemu/sysemu.h" ++#include "sysemu/tpm.h" ++#include "sysemu/tpm_backend.h" + #include "exec/hwaddr.h" + #include "kvm_arm.h" + #include "hw/arm/boot.h" +@@ -94,6 +96,7 @@ enum { + SBSA_SECURE_MEM, + SBSA_AHCI, + SBSA_XHCI, ++ SBSA_TPM, + }; + + struct SBSAMachineState { +@@ -132,6 +135,7 @@ static const MemMapEntry sbsa_ref_memmap[] = { + /* Space here reserved for more SMMUs */ + [SBSA_AHCI] = { 0x60100000, 0x00010000 }, + [SBSA_XHCI] = { 0x60110000, 0x00010000 }, ++ [SBSA_TPM] = { 0x60120000, 0x00010000 }, + /* Space here reserved for other devices */ + [SBSA_PCIE_PIO] = { 0x7fff0000, 0x00010000 }, + /* 32-bit address PCIE MMIO space */ +@@ -629,6 +633,24 @@ static void create_smmu(const SBSAMachineState *sms, PCIBus *bus) + } + } + ++static void create_tpm(SBSAMachineState *sbsa, PCIBus *bus) ++{ ++ Error *errp = NULL; ++ DeviceState *dev; ++ ++ TPMBackend *be = qemu_find_tpm_be("tpm0"); ++ if (be == NULL) { ++ error_report("Couldn't find tmp0 backend"); ++ return; ++ } ++ ++ dev = qdev_new(TYPE_TPM_TIS_SYSBUS); ++ object_property_set_link(OBJECT(dev), "tpmdev", OBJECT(be), &errp); ++ object_property_set_str(OBJECT(dev), "tpmdev", be->id, &errp); ++ sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal); ++ sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, sbsa_ref_memmap[SBSA_TPM].base); ++} ++ + static void create_pcie(SBSAMachineState *sms) + { + hwaddr base_ecam = sbsa_ref_memmap[SBSA_PCIE_ECAM].base; +@@ -686,6 +708,8 @@ static void create_pcie(SBSAMachineState *sms) + pci_create_simple(pci->bus, -1, "bochs-display"); + + create_smmu(sms, pci->bus); ++ ++ create_tpm(sms, pci->bus); + } + + static void *sbsa_ref_dtb(const struct arm_boot_info *binfo, int *fdt_size) +``` + +With such, the tpm can get used when setting the TPM base address to be 0x60120000 with the following launching command: + +```bash +qemu-system-aarch64 -machine sbsa-ref,gic-version=3,acpi=off \ + -cpu host -m 4G \ + -nographic -accel kvm \ + -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ + -tpmdev emulator,id=tpm0,chardev=chrtpm \ + -device virtio-blk-pci,drive=drv0 \ + -drive format=qcow2,file=hda.qcow2,if=none,id=drv0 \ + -drive if=pflash,format=raw,file=flash0.img,readonly=on \ + -drive if=pflash,format=raw,file=flash1.img +``` diff --git a/results/classifier/gemma3:12b/peripherals/2645 b/results/classifier/gemma3:12b/peripherals/2645 new file mode 100644 index 000000000..39e8896e2 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2645 @@ -0,0 +1,24 @@ + +Failed shutdown during record with `ide-hd` disk. +Description of problem: +Running `shutdown -h now` on the guest with an `ide-hd` disk during a recording results in a long wait, followed by a BMDMA error. +Steps to reproduce: +1. Install Ubuntu Server guest OS and create disk snapshot +1. Reboot and log in: `qemu-system-x86_64 -hda ubuntu_snapshot.qcow2 -m 2g -net none -monitor stdio` +2. Take a snapshot: `savevm loggedin` +3. Start recording from VM snapshot: `./qemu/build/qemu-system-x86_64 -icount shift=auto,rr=record,rrfile=ubuntu_shutdown.bin -drive file=ubuntu_snapshot.qcow2,if=none,id=img-direct -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device ide-hd,drive=img-blkreplay -loadvm loggedin -net none -m 2g` +4. Run `shutdown -h now` in guest +5. Wait (~5-10 mins) +6. Observe BMDMA error (see below) +Additional information: +``` +ata1.00: exeption Emask 0x0 SAct 0.0 SErr 0.0 action 0x6 +ata1.00: BMDMA stat 0x5 +ata1.00: failed command: READ DMA +ata1.00: cmd c8/xx:xx:xx:xx:xx/xx:xx:xx:xx:xx/xx tag - dma 4096 in + res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) +ata1.00: revalidation failed (errno=-2) +... +``` + +Note: Running the same command on a guest with a `virtio` disk results in further progress, but still does not shut down (stuck on `[ OK ] Stopped Create final runtime dir for shutdown pivot root.`) diff --git a/results/classifier/gemma3:12b/peripherals/2651 b/results/classifier/gemma3:12b/peripherals/2651 new file mode 100644 index 000000000..cf847b634 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2651 @@ -0,0 +1,9 @@ + +MPC5553/MPC5554 Emulation (information request) +Additional information: +If it is not planned, I'll most likely start educating myself on this project to try and patch it in as it's a need that is quite important for me. +I'll try not to waste your time and read as much as I can about your guidelines. +Would you advise me against trying to do this? +I'd like to know how hard you think this will be. + +DISCLAIMER : I am still very much a newbie in embedded systems, I'm only in the first year of my master's degree in embedded systems. diff --git a/results/classifier/gemma3:12b/peripherals/2663 b/results/classifier/gemma3:12b/peripherals/2663 new file mode 100644 index 000000000..f2bcd7d2a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2663 @@ -0,0 +1,8 @@ + +powerpc: for 6xx,7xx,74xx msr and srr1 are not set correctly on exception +Description of problem: +When an exception is raised, qemu does not set bits in SRR1 and MSR correctly. + +This causes some operating systems to not work, in particular early little endian ones like Windows NT. +Additional information: +The following patch changes the MSR and SRR1 bit settings on exception to what is mentioned in the various user manuals for the 6xx, 7xx and 74xx series (6xx and 7xx are effectively identical, 74xx has some additional changes): [exception_msr.patch](/uploads/aae17dd35f0f0e72b831243fcfd0c416/exception_msr.patch) diff --git a/results/classifier/gemma3:12b/peripherals/2691 b/results/classifier/gemma3:12b/peripherals/2691 new file mode 100644 index 000000000..1e7a39b6d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2691 @@ -0,0 +1,28 @@ + +Renesas: test_rx_gdbsim.py test sometime timeouts +Description of problem: +```make check-functional``` runs sometime fail with : + +``` +160/164 qemu:func-thorough+func-rx-thorough+thorough / func-rx-rx_gdbsim TIMEOUT 90.03s killed by signal 15 SIGTERM +``` +Steps to reproduce: +1. ./configure --target-list=rx-softmmu +2. make -j 20 +3. while [ 1 ]; do PYTHONPATH=python:tests/functional QEMU_TEST_QEMU_BINARY=build/qemu-system-rx build/pyvenv/bin/python3 tests/functional/test_rx_gdbsim.py ; done + +It hangs after a few iterations. +Additional information: +The test console log file contains: + ``` +... +2024-11-19 11:03:04,123: Run /bin/sh as init process +2024-11-19 11:03:04,136: +2024-11-19 11:03:04,137: Sash command shell (version 1.1.1) +2024-11-19 11:03:04,137: +2024-11-19 11:03:04,145: />sh-sci 88240.serial: overrun error +2024-11-19 11:03:04,150: sh-sci 88240.serial: frame error +2024-11-19 11:03:04,156: sh-sci 88240.serial: parity error + ``` + +These errors appear to reflect some problems in the renesas_sci model. diff --git a/results/classifier/gemma3:12b/peripherals/2703 b/results/classifier/gemma3:12b/peripherals/2703 new file mode 100644 index 000000000..8e28cf7b0 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2703 @@ -0,0 +1,41 @@ + +ptimer period sporadically too long +Description of problem: +A ptimer in a custom device with a frequency of 10kHz is sporadically called after more than 100,000ns in virtual time have elapsed. + +With a icount shift of 4 or 5 this happens almost everytime before the linux guest can even finish booting. + +With a shift of 0 this happens very rarely, but it does occur from time to time. +Steps to reproduce: +1. setup a ptimer with a frequency of 10kHz and assert that the time passed between callbacks is exactly 100,000ns +2. run +3. wait for boom +Additional information: +``` +// Timer setup +ptimer_transaction_begin(state->timer); + +ptimer_set_freq(state->timer, 10000); +ptimer_run(state->timer, 0); + +ptimer_transaction_commit(state->timer); +``` +``` +// timer callback +int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); +static int64_t last = 0; +if (last > 0) +{ + if (now - last != 100000) + { + fprintf(stderr, "error tick %ld after %ld is incorrect: %ld\n", now, last, now - last); + assert(0); + } +} +last = now; +``` + +``` +error tick 47867503135 after 47867400000 is incorrect: 103135 +qemu-system-x86_64: ../...file.c:119: timer_callback: Assertion `0' failed. +``` diff --git a/results/classifier/gemma3:12b/peripherals/2705 b/results/classifier/gemma3:12b/peripherals/2705 new file mode 100644 index 000000000..5a0cf932e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2705 @@ -0,0 +1,18 @@ + +USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X) +Steps to reproduce: +1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above. +2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off` +3. Boot macOS. + +USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable. + + +While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection: + + * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.) + * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2. + * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped. + * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references. + +It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup. diff --git a/results/classifier/gemma3:12b/peripherals/2707 b/results/classifier/gemma3:12b/peripherals/2707 new file mode 100644 index 000000000..fd9950041 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2707 @@ -0,0 +1,11 @@ + +virtio-balloon crashes in a object assert when querying stats +Description of problem: +Fetch virtio-balloon stats will crash a QEMU crash with assert failures +Steps to reproduce: +1. ./qemu-system-x86_64 -device virtio-balloon,id=balloon -qmp qmp.sock +2. Connect to qmp.sock +3. Issue 'qom-get path=/machine/peripheral/balloon property=guest-stats' +4. QEMU go boom! +Additional information: +This is a regression caused by commit 0d2eeef77a33315187df8519491a900bde4a3d83, which failed to update `balloon_stat_names` with the new stats names, causing code to try to add a QDict entry with a NULL key. diff --git a/results/classifier/gemma3:12b/peripherals/2708 b/results/classifier/gemma3:12b/peripherals/2708 new file mode 100644 index 000000000..896526cf7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2708 @@ -0,0 +1,2 @@ + +aarch64 register MDCCINT_EL1 exhibits bizzare behavior diff --git a/results/classifier/gemma3:12b/peripherals/2744 b/results/classifier/gemma3:12b/peripherals/2744 new file mode 100644 index 000000000..c7bed2048 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2744 @@ -0,0 +1,6 @@ + +Avoid defining custom machine-definition macros for each new machine type +Additional information: +There are already some semi-generic implementations of this macro, such as [`DEFINE_PC_VER_MACHINE()`](https://gitlab.com/qemu-project/qemu/-/blob/aa3a285b5bc56a4208b3b57d4a55291e9c260107/include/hw/i386/pc.h#L326), which is used for the 'q35', 'pc' and 'isapc' machine types. + +There does appear to be some deviation from the template macro in some cases. We would have to enumerate what the nature of these deviations is, why only some machine types need them, and how they would fit into the proposed generic macro. Still, if we could have a generic macro that simplifies 80% of machine types' version definitions, then that seems like a win. diff --git a/results/classifier/gemma3:12b/peripherals/2756 b/results/classifier/gemma3:12b/peripherals/2756 new file mode 100644 index 000000000..621f09645 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2756 @@ -0,0 +1,43 @@ + +Unexpected port id 2909357808 for device virtio-serial0.0 +Description of problem: +when the VM runs for a period of time.qemu log always print the error：“Unexpected port id 2909357808 for device virtio-serial0.0”.And the spice connet display black screen.Restart the vm,it recovery. my channel is 16,Normally it will always output port less than 16,but when error it report a lage port. why it get a lage port "2909357808",Is there a data overflow? +Steps to reproduce: +1.The VM runs for a period of time + +2.report the error: "Unexpected port id 2909357808 for device virtio-serial0.0". + +3.restart to recovery. +Additional information: +qemu log: + +when vm is ok: +``` +virtio serial port 16 send control message event = 1, value = 1 +virtio serial port 0 send control message event = 1, value = 1 +virtio serial port '1' handle control message event = 3, value = 1 +virtio serial port '2' handle control message event = 3, value = 1 +virtio serial port 2 send control message event = 6, value = 1 +virtio serial port '3' handle control message event = 3, value = 1 +virtio serial port 3 send control message event = 6, value = 1 +virtio serial port '4' handle control message event = 3, value = 1 +virtio serial port 4 send control message event = 6, value = 1 +``` + + +when error: + +``` +2024-11-07T07:19:50.969383Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:19:50.969706Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +2024-11-07T07:20:00.944495Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:20:00.950544Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +2024-11-07T07:20:47.923564Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:20:47.924422Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +``` diff --git a/results/classifier/gemma3:12b/peripherals/2763 b/results/classifier/gemma3:12b/peripherals/2763 new file mode 100644 index 000000000..251dcc107 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2763 @@ -0,0 +1,25 @@ + +RISC-V APLIC emulation: interrupt pending state of direct-delivery level-triggered interrupts is wrong after masking +Description of problem: +According to the APLIC specification, the interrupt pending state of a level-triggered interrupt in direct delivery mode should always match the (rectified) input signal: + +> When an interrupt domain is in direct delivery mode, the pending bit for a level-sensitive source is always just a copy of the rectified input value. + +(From Section 4.7 "Precise effects on interrupt-pending bits" of the specification. See also the more detailed paragraph starting with "If the + source mode is Level1 or Level0 and the interrupt domain is configured in direct delivery mode [...]".) + +However, **this is not true in Qemu's emulation**. In particular, in some situations, **a level-triggered interrupt in direct delivery mode can be raised even though the rectified input signal is off**. +Steps to reproduce: +1. Set `-machine virt,acpi=off,aia=aplic` to use AIA without IMSIC. +2. Program APLIC to direct delivery. Program some level triggered interrupt (e.g., an interrupt of a PCIe ECAM controller). +4. Wait until the IRQ is raised by a device (i.e., `claimi` returns the IRQ). +5. Mask the interrupt by writing to `clrie`. +6. Clear the interrupt at the device level. +7. The state of Qemu's APLIC registers is now: + ``` + Rectified input = 0 (correct) + Pending = 1 (incorrect) + topi = 0 (correct) + ``` + +Furthermore, if `setie` is written to unmask the IRQ in this situation, the IRQ is raised (in `topi` / `claimi`) despite the signal being off. diff --git a/results/classifier/gemma3:12b/peripherals/2783 b/results/classifier/gemma3:12b/peripherals/2783 new file mode 100644 index 000000000..ddb807a5a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2783 @@ -0,0 +1,18 @@ + +Cannot install a fresh Windows 7 32-bit guest with Q35 machine type (mouse and keyboard do not function, so cannot continue install) +Description of problem: +When trying to install Windows 7 32-bit via the official SP1 installation ISO, the machine boots the installer, but both keyboard and mouse do not function, so the installation cannot proceed. +Steps to reproduce: +1. Using virt-manager, create a new VM using the x86 version of the Windows 7 SP1 install ISO found here: https://archive.org/details/windows-7-professional-with-sp1-x64-dvd-iso +2. Select `Microsoft Windows 7` as the Operating System type, which uses Q35 as the machine type +3. Click Begin Installation +4. See the Windows 7 installer screen show up +5. Keyboard and mouse inputs don't work at all, mouse cursor also doesn't appear +Additional information: +I've tried using `Microsoft Windows XP` as the Operating System in virt-manager, which switches to i440FX as the machine type, and the issue doesn't appear: keyboard and mouse both work perfectly. But of course, it would be nice to use Q35 instead to get USB 3.0, PCI-E, etc. + + +Notice the lack of cursor in the screenshot above on Q35. + +When using a i440FX machine, the white Windows cursor will appear: + diff --git a/results/classifier/gemma3:12b/peripherals/2787 b/results/classifier/gemma3:12b/peripherals/2787 new file mode 100644 index 000000000..e151e5e4e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2787 @@ -0,0 +1,14 @@ + +Opentitan timer layout incorrect +Description of problem: +It looks as if some of the timer register offsets here are incorrect: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L37 + +Compare with: + +https://opentitan.org/book/hw/ip/rv_timer/doc/registers.html + +I suspect they're out of date. The documentation link on line 7 is not working anymore - the current documentation URL for Opentitan is the one just given. + +It might also make sense to rename this file `opentitan_timer.c`, instead of `ibex_timer.c`. The timer is an Opentitan hardware IP block, rather than a feature of the Ibex CPU. diff --git a/results/classifier/gemma3:12b/peripherals/2788 b/results/classifier/gemma3:12b/peripherals/2788 new file mode 100644 index 000000000..1c8883c42 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2788 @@ -0,0 +1,14 @@ + +[solved] input mouse and keyboard not working on a distro +Description of problem: +The distro work but does not take input from either keyboard or mouse. +At the boot menu (syslinux) where I have to choose the boot mode the keyboard works, but it stops working when the desktop has booted. +The distro is not blocked I can tell by observing that the clock in the panel keeps running and if I click in the qemu menubar on machine > power down, the distro correctly performs the shutdown procedure. +I have tried other distributions (porteus and tinycore) and both do not have this problem. +I also tried using as -display vnc and sdl but I have the same problem. +I am using a [portable version of qemu](https://gitlab.com/qemu-project/qemu/-/issues/new) but I also tried with the repository version having the same problem. +Steps to reproduce: +Simply boot the virtual machine with the distro, in my case with the portable qemu version: +./QEMU-git-x86_64.AppImage qemu-system-x86_64 -m 512 -enable-kvm -boot d -cdrom ./Nemesis-v25.01-XFCE-x86_64.iso +Additional information: +I am not expert in qemu, if you need some more data I can try to produce it diff --git a/results/classifier/gemma3:12b/peripherals/2796 b/results/classifier/gemma3:12b/peripherals/2796 new file mode 100644 index 000000000..d3933b161 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2796 @@ -0,0 +1,8 @@ + +Opentitan Timer ignores COMPARE_UPPER0/COMPARE_LOWER0 +Description of problem: +In a bare metal application, running on an emulated Opentitan board, if you set a timer interrupt threshold by writing to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before writing to `rv_timer.CTRL` to start the timer, then the interrupt does not fire. If you write to the `COMPARE_*` registers *after* starting the timer by writing to `CTRL`, then the interrupt fires correctly. + +I think the explanation is that [ibex_timer_update_irqs](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L61) has an early return if `rv_timer.CTRL` is not set. As a result, although writes to `COMPARE_*` always call `ibex_timer_update_irqs`, they don't have their intended side-effects before `CTRL` is unset. +Steps to reproduce: +Write to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before you have set `rv_timer.CTRL`. Observe that no timer interrupt occurs. diff --git a/results/classifier/gemma3:12b/peripherals/2828 b/results/classifier/gemma3:12b/peripherals/2828 new file mode 100644 index 000000000..c221e8a06 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2828 @@ -0,0 +1,4 @@ + +Potential issues at Interrupt filtering and virtual interrupts for supervisor level (RISC-V AIA) +Description of problem: +I am working on RISC-V Advanced Interrupt Architecture (AIA) compliance tests for our RISC-V core. These tests pass on our hardware implementation but fail when running on QEMU. There are several points where the tests fail while running in QEMU: diff --git a/results/classifier/gemma3:12b/peripherals/2833 b/results/classifier/gemma3:12b/peripherals/2833 new file mode 100644 index 000000000..738c7f84f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2833 @@ -0,0 +1,20 @@ + +Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET +Description of problem: +In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says: +> Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field. +> +> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0. + + +> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values. + +In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows. + +The HPET should show that it works with more than just IRQ 2. +Steps to reproduce: +1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859 +2. `nix develop` +3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int` +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2860 b/results/classifier/gemma3:12b/peripherals/2860 new file mode 100644 index 000000000..3509bf8e7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2860 @@ -0,0 +1,34 @@ + +ps2 keyboard not work after boot and use libspice to connect it +Description of problem: +When I start almost 10 qemu virtual machines, there will always be one or two that have the ps2 keyboard not work well after booted.But I use mstsc to connect to the desktop, the keyboard works fine. But when reboot or migrate it well recovery. +Steps to reproduce: +1.Asynchronously start 40 qemu virtual machines, each with 4 cores and 4 threads + +2.there will always be one or two that have the ps2 keyboard not work well. + +4.And when i gdb debug it, i found i hang at the func "prepare_mmio_access" + +5.reboot or migrate it well recovery +Additional information: +the gdb debug as fllow: + +gdb attach $pid + +gdb>b kbd_push_key //spice input + +gdb>b kbd_read_data + +gdb>b ps2_keyboard_event + +gdb>c + +After continue, the code run on ps2_keyboard_event,but no work to "kbd_read_data".This Proves that the keyboard input has been added to the queue, but has not been read from the queue. + +gdb> thread 4 //switch to thread "CPU 0/KVM" + +gdb> bt + + + +I guess there is no event to notify the device to read after writing to the queue, or is it deadlocked? I'm not sure diff --git a/results/classifier/gemma3:12b/peripherals/2864 b/results/classifier/gemma3:12b/peripherals/2864 new file mode 100644 index 000000000..b98f8f7b8 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2864 @@ -0,0 +1,10 @@ + +qemu-system-ppc -M g3beige mouse/keyboard behave erraticaly at least since 9.0 +Description of problem: +Mouse behaves very erraticaly, seemingly clicks on its own, moves auto-opened terminal window to the left +Steps to reproduce: +1. Get helenOS from https://www.helenos.org/wiki/Download +2. Boot it (need 256 Mb) +3. Try to move mouse or type anything in Terminal +Additional information: +Seemingly same issue present on netBSD (booted on qemu 9.0.4 due to regression in qemu), and macos X/9 when booted on this machine or -M mac99,via=cuda diff --git a/results/classifier/gemma3:12b/peripherals/2886 b/results/classifier/gemma3:12b/peripherals/2886 new file mode 100644 index 000000000..23a8c39db --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2886 @@ -0,0 +1,16 @@ + +ACPI MADT advertises GITS even when disabled +Description of problem: +As per the command line given above, QEMU shall emulate a GICv4 without GIC Interrupt Translation Service (GITS). + +The following happens: +- ACPI **incorrectly** lists a GITS (type 0xf) structure in the MADT with GITS MMIO Base = 0x8080000 +- The OS reads that structure and interprets it to mean a GITS is present at the given MMIO address +- Subsequent access to GITS MMIO causes a data abort (0x25) because QEMU doesn't emulate a GITS (as requested) + +The bug is thus that QEMU wrongly advertises GITS as present (via the MADT) when it is in fact absent. +Steps to reproduce: +1. Disable GITS emulation by passing `its=off` on the QEMU command line +2. Check if a GITS structure is listed in the ACPI MADT (must be present in ACPI MADT only if GITS is enabled and absent otherwise) +Additional information: +When booting with `its=on` (default), everything works as expected. diff --git a/results/classifier/gemma3:12b/peripherals/2888 b/results/classifier/gemma3:12b/peripherals/2888 new file mode 100644 index 000000000..a481b3b9c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2888 @@ -0,0 +1,15 @@ + +mouse pointer does not move in USB pass in. +Description of problem: +I have this script to start qemu that passes in my mouse, keyboard and xbox controller. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move. +Steps to reproduce: +1. use the script above with the right USB IDs for you mouse and keyboard (and controller if you want) +2. When the VM boots it will not move the cursor. The mouse will work but the pointer stays still. +Additional information: +I am using thees patches in qemu but it does not work in vanilla ether: +https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/ + +and this in the kernel (6.14.0): +https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83 + +I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0. diff --git a/results/classifier/gemma3:12b/peripherals/2889 b/results/classifier/gemma3:12b/peripherals/2889 new file mode 100644 index 000000000..8c3425d51 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2889 @@ -0,0 +1,23 @@ + +mouse does not work in pass in +Description of problem: +I have this script to start qemu that passes in my mouse, keyboard and xbox controler. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do work. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move. Here is the script: +Steps to reproduce: +1. run the script above with the right variables. +2. Move your mouse in the screen. It will not move the pointer. +Additional information: +I am using thees patches in qemu but it does not work in vanilla ether: +https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/ + +and this in the kernel (6.14.0): +https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83 + +I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0. + +I am runing mint on my host and arch on my guest. on my host I have virglrenderer on and on my guest I installed the pacman package lib32-vulkan-virtio and vulkan-virtio. + +If it helps I can remove the pass throws and insted use: + +-usbdevice tablet -usbdevice mouse -usbdevice keyboard +or +-device virtio-mouse -device virtio-keyboard -device virtio-tablet diff --git a/results/classifier/gemma3:12b/peripherals/2896 b/results/classifier/gemma3:12b/peripherals/2896 new file mode 100644 index 000000000..7df21fd8b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2896 @@ -0,0 +1,2 @@ + +How to enable MPU support on Cortex-R5F? diff --git a/results/classifier/gemma3:12b/peripherals/2923 b/results/classifier/gemma3:12b/peripherals/2923 new file mode 100644 index 000000000..7fb7bda21 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2923 @@ -0,0 +1,14 @@ + +Audio crackling issue when USB headset is pass thru via usb-host,hostbus=bus,hostaddr=addr +Description of problem: +When we pass thru USB headset via usb port pass-thru, and if the headset supports only 44100 Hz sampling rate, we hear the crackling sound. + +The headsets which support 48000Hz works fine. +Steps to reproduce: +1. Pass the usb device using hostbus,port. +2. Connect a usb headset like Logitech H340 which supports only 44100Hz sampling rate. +3. Play any audio file or youtube video, there is constant crackling sound. + +This issue is observed irrespective of the guest OS. Both ubuntu and windows guest, exhibit similar problem. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/2937 b/results/classifier/gemma3:12b/peripherals/2937 new file mode 100644 index 000000000..72696765e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2937 @@ -0,0 +1,2 @@ + +Request for Assistance: Properly Emulating USB Devices in QEMU for Custom USB Driver Testing diff --git a/results/classifier/gemma3:12b/peripherals/294 b/results/classifier/gemma3:12b/peripherals/294 new file mode 100644 index 000000000..f354afa10 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/294 @@ -0,0 +1,2 @@ + +Keyboard keys get stuck diff --git a/results/classifier/gemma3:12b/peripherals/2947 b/results/classifier/gemma3:12b/peripherals/2947 new file mode 100644 index 000000000..272da182b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2947 @@ -0,0 +1,11 @@ + +Tablet-like mouse under Linux guest even if no -device usb-tablet is specified +Description of problem: +Arch Linux guest has absolute mouse tracking even when there is `-nodefaults` and no -device usb-tablet is provided. The guest does not have qemu guest agent installed. This is the unwanted behavior. The expected behavior is that it has a separate mouse pointer under guest, like with Windows guest. +Steps to reproduce: +1. Install guest operating system +2. Install gnome metapackage and enable GDM +3. Reboot +4. GDM has absolute mouse tracking and the mouse gets captured automatically, without having to click on the window or pressing Ctrl+Alt+G +Additional information: +[journalctl](/uploads/356952b8e2454c98e76ad82b700c518e/journalctl) diff --git a/results/classifier/gemma3:12b/peripherals/2960 b/results/classifier/gemma3:12b/peripherals/2960 new file mode 100644 index 000000000..efaa4ad77 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/2960 @@ -0,0 +1,11 @@ + +Mouse doesn't work correctly with SDL display backend +Description of problem: +The mouse starts moving like crazy, up and down or left and right. +I tested it with -accel on and off, I make some test and seems to be the SDL display backed(GTK just crash before start execution of the vm). +Steps to reproduce: +1.Install Linux Mint 22.1 +2.Execute the command above. +3.Log in and the problems start. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/316 b/results/classifier/gemma3:12b/peripherals/316 new file mode 100644 index 000000000..5504a846b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/316 @@ -0,0 +1,2 @@ + +[feature request] webcam support diff --git a/results/classifier/gemma3:12b/peripherals/317 b/results/classifier/gemma3:12b/peripherals/317 new file mode 100644 index 000000000..de35fc7ba --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/317 @@ -0,0 +1,2 @@ + +synchronous abort on accessing unused I/O ports on aarch64 diff --git a/results/classifier/gemma3:12b/peripherals/328 b/results/classifier/gemma3:12b/peripherals/328 new file mode 100644 index 000000000..773e7bf27 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/328 @@ -0,0 +1,2 @@ + +numerical keypad disabled by default in the guest diff --git a/results/classifier/gemma3:12b/peripherals/346 b/results/classifier/gemma3:12b/peripherals/346 new file mode 100644 index 000000000..1a80dcbd5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/346 @@ -0,0 +1,2 @@ + +Guest refuses to accept keyboard input when accelerated with WHPX diff --git a/results/classifier/gemma3:12b/peripherals/352 b/results/classifier/gemma3:12b/peripherals/352 new file mode 100644 index 000000000..0f918822a --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/352 @@ -0,0 +1,2 @@ + +audio input crack diff --git a/results/classifier/gemma3:12b/peripherals/357 b/results/classifier/gemma3:12b/peripherals/357 new file mode 100644 index 000000000..f2e0d9500 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/357 @@ -0,0 +1,2 @@ + +race condition in hw/input/pckbd.c causes wrong data to be read on interrupts diff --git a/results/classifier/gemma3:12b/peripherals/362 b/results/classifier/gemma3:12b/peripherals/362 new file mode 100644 index 000000000..6175022b5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/362 @@ -0,0 +1,2 @@ + +check of PMR capability is missing for PMRCTL register write diff --git a/results/classifier/gemma3:12b/peripherals/373 b/results/classifier/gemma3:12b/peripherals/373 new file mode 100644 index 000000000..834726639 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/373 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the ARM subsystem diff --git a/results/classifier/gemma3:12b/peripherals/375 b/results/classifier/gemma3:12b/peripherals/375 new file mode 100644 index 000000000..b77ed1923 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/375 @@ -0,0 +1,2 @@ + +MacOS 11.4 (x86_64) Host - USB passthrough appears to be broken diff --git a/results/classifier/gemma3:12b/peripherals/445 b/results/classifier/gemma3:12b/peripherals/445 new file mode 100644 index 000000000..e6bec8f69 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/445 @@ -0,0 +1,2 @@ + +QEMU + DOS keyboard behavior diff --git a/results/classifier/gemma3:12b/peripherals/455 b/results/classifier/gemma3:12b/peripherals/455 new file mode 100644 index 000000000..8ae320c4e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/455 @@ -0,0 +1,35 @@ + +Pressing special keys (specially ctrl) sticks the key or makes it repeat the next key until ESC or Ctrl is pressed. +Description of problem: +Well, I'm using it in a daily basis, since it is my VM to isolate the environment for work. + +It was compiled from source for _jack_ support, the only thing that I cared about. I'll be honest : I don't remember the special parameters, nothing unusual though. I'm not in the need for _rt_ kernels. + +When I press `Ctrl` and sometimes when I press other special keys, one of the three options occur : +1. It repeats all the keys pressed next, like if I was pressing it for a long time. + - Example : `a` turns into `aaaaaaaaaaaaaaa...`(continues) + - It repeats until I press `Esc` or `Ctrl` again. +1. `Ctrl` continues as pressed and everything I type occurs with `Ctrl`. + - Example : `a` turns into `Ctrl-A` + - Probably caused by the previous option. +1. It does what is expected, like `Ctrl-C` +Steps to reproduce: +1. Run the specified config. +1. Test `Ctrl-C` + `Ctrl-V` using text editors. + - I think that using a graphical one is faster to see it happening. + - Examples + - Atom + - Eclipse + - Kate + - VsCode + - It also occurred using a _pty_ but since I generally use the _middle-mouse-button_ with _ptys_. + - I'm not aware of the frequency that it happens. + - It also occurs with the mouse (`Ctrl-mouseclick`). + - For example: instead of going to a _Firefox_'s tab, it selects it. + +I don't know any other step here, the use case is trivial coding. +Additional information: +- I have already tried to disable "keyboard repeat" in config. + - At first it seems to work but the `Ctrl` key can get stuck like in the description and then I'm unable to get out of it (everything is sent as if it was with `Ctrl`) without pressing `Ctrl`+`ESC`. I have no idea of why. + - The problem seems to occur less frequently. +- It also happened before setting up `qemu-guest-agent`. diff --git a/results/classifier/gemma3:12b/peripherals/459 b/results/classifier/gemma3:12b/peripherals/459 new file mode 100644 index 000000000..075351b94 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/459 @@ -0,0 +1,36 @@ + +bcm2835_aux (raspi3) fails when the receive FIFO fills up +Description of problem: +When a bare-metal application on the `raspi3` board reads the `AUX_MU_STAT_REG` MMIO register while the device's buffer is at full receive FIFO capacity (i.e. `s->read_count == BCM2835_AUX_RX_FIFO_LEN`) the assertion `assert(s->read_count < BCM2835_AUX_RX_FIFO_LEN)` fails. + +The assertion in question is currently in line 141 of `hw/char/bcm2835_aux.c`: https://gitlab.com/qemu-project/qemu/-/blob/9c2647f75004c4f7d64c9c0ec55f8c6f0739a8b1/hw/char/bcm2835_aux.c#L141 +but in my current QEMU version, it seems that it was in line 140, but I don't think that has any implication on this error. If the below steps to reproduce are followed, the full output of a normal QEMU (no debugging output or anything) is simply: + +```text +$ echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio +qemu-system-aarch64: /build/qemu-71DV4m/qemu-4.2/hw/char/bcm2835_aux.c:140: bcm2835_aux_read: Assertion `s->read_count < BCM2835_AUX_RX_FIFO_LEN' failed. +Aborted (core dumped) +``` + +Notice, that there is nothing really wrong with the implementation, if for instance an application that uses the `AUX_MU_LSR_REG` instead to check whether input is available, everything works as expected. It really seems that just this assertion is wrong. Also notice that the [BCM2835 manual](https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf) (page 18) explicitly allows values inclusive 8. +Steps to reproduce: +1. write a minimal bare-metal application for aarch64 using below main file +2. compile it with a decent aarch64 compiler, linker script and entry assembly as `kernel8.elf` +3. `echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio` +4. QEMU crashes with the above state assertion error +Additional information: +Minimal bare-metal application (`main.c`): + +```c +#define MMIO_BASE 0x3F000000 +#define AUX_MU_STAT ((volatile unsigned int*)(MMIO_BASE+0x00215064)) + +void main() { + while (1) { + // Just read STAT register to trigger the assertion error + *AUX_MU_STAT; + } +} +``` + +Also see [kernel8.elf.zip](/uploads/b12ae2750d2df1bb8db2701f3145f653/kernel8.elf.zip) for a precompiled version of the above application. diff --git a/results/classifier/gemma3:12b/peripherals/481 b/results/classifier/gemma3:12b/peripherals/481 new file mode 100644 index 000000000..6e7b42992 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/481 @@ -0,0 +1,2 @@ + +Implement I2C for BCM2835 (raspi) diff --git a/results/classifier/gemma3:12b/peripherals/486 b/results/classifier/gemma3:12b/peripherals/486 new file mode 100644 index 000000000..91698c087 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/486 @@ -0,0 +1,2 @@ + +/dev/input/mouse0: is not an evdev device diff --git a/results/classifier/gemma3:12b/peripherals/49 b/results/classifier/gemma3:12b/peripherals/49 new file mode 100644 index 000000000..3ae52408f --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/49 @@ -0,0 +1,2 @@ + +[Feature request] MDIO bus diff --git a/results/classifier/gemma3:12b/peripherals/493 b/results/classifier/gemma3:12b/peripherals/493 new file mode 100644 index 000000000..3d15113cb --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/493 @@ -0,0 +1,8 @@ + +RISC-V: Setting mtimecmp to -1 immediately triggers an interrupt +Description of problem: +When setting mtimecmp to -1, which should set a timer infinitely far in the future, a timer interrupt is triggered immediately. This happens for most values over 2^61. It is the same for both 32-bit and 64-bit, and for M-mode writing to mtimecmp directly and S-mode using OpenSBI. + +I have looked through the source code, and the problem is in the function `sifive_clint_write_mtimecmp`, in the file `/hw/intc/sifive_clint.c`. First, the muldiv64 multiplies diff with 100, causing an overflow (at least for -M virt, other machines might use a different timebase_freq). Then, the unsigned `next` is passed to `timer_mod`, which takes a signed integer. In `timer_mod_ns_locked` the value is set to `MAX(next, 0)`, which means that if the MSB of `next` was set, the interrupt happens immediately. This means that it is impossible to set timers more than 2^63 nanoseconds in the future. + +This problem basically only affects programs which disable timer interrupts by setting the next one infinitely far in the future. However, the SBI doc specifically says that this is a valid approach, so it should be supported. Using the MSB doesn't work without changing code functionality in QEMU, but it should be sufficient to cap `next` at the maximum signed value. diff --git a/results/classifier/gemma3:12b/peripherals/502 b/results/classifier/gemma3:12b/peripherals/502 new file mode 100644 index 000000000..57c28122b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/502 @@ -0,0 +1,2 @@ + +6.1.0-rc0 Regression: No mouse input possible diff --git a/results/classifier/gemma3:12b/peripherals/511 b/results/classifier/gemma3:12b/peripherals/511 new file mode 100644 index 000000000..28a2b44c3 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/511 @@ -0,0 +1,2 @@ + +usbredirparser: bulk transfer length exceeds limits (can't use any USB storage) diff --git a/results/classifier/gemma3:12b/peripherals/521994 b/results/classifier/gemma3:12b/peripherals/521994 new file mode 100644 index 000000000..b768a2581 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/521994 @@ -0,0 +1,71 @@ + +Windows 98 doesn't detect mouse on qemu and SeaBIOS. + +A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the result is + +fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit +commit fd646122418ecefcde228d43821d07da79dd99bb +Author: Anthony Liguori <email address hidden> +Date: Fri Oct 30 09:06:09 2009 -0500 + + Switch pc bios from pc-bios to seabios + + SeaBIOS is a port of pc-bios to GCC. Besides using a more modern tool chain, + SeaBIOS introduces a number of new features including PMM support, better + BEV and BCV support, and better PnP support. + + Signed-off-by: Anthony Liguori <email address hidden> + +I got following messages with DEBUG_BIOS + +Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) +Ram Size=0x08000000 (0x0000000000000000 high) +CPU Mhz=2271 +Found 1 cpu(s) max supported 1 cpu(s) +PIIX3/PIIX4 init: elcr=00 0c +PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 +PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 +PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 +region 4: 0x0000c000 +PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 +PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 +region 0: 0xe0000000 +region 1: 0xe2000000 +region 6: 0xe2010000 +MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224 +SMBIOS ptr=0x000f8990 table=0x07fffef0 +ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30 +Scan for VGA option rom +Running option rom at c000:0003 +VGABios $Id$ +Turning on vga console +Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) + +Found 0 lpt ports +Found 0 serial ports +ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9) +ATA controller 1 at 170/374/c008 (irq 15 dev 9) +ps2 irq but no data. +ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63 +ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56 +ps2_recvbyte timeout +keyboard initialized +Scan for option roms +Returned 53248 bytes of ZoneHigh +e820 map has 6 items: + 0: 0000000000000000 - 000000000009f400 = 1 + 1: 000000000009f400 - 00000000000a0000 = 2 + 2: 00000000000f0000 - 0000000000100000 = 2 + 3: 0000000000100000 - 0000000007ffd000 = 1 + 4: 0000000007ffd000 - 0000000008000000 = 2 + 5: 00000000fffc0000 - 0000000100000000 = 2 +enter handle_19: + NULL +Booting from Hard Disk... +Booting from 0000:7c00 +pnp call arg1=5 +pnp call arg1=0 +ps2_recvbyte timeout +ps2_recvbyte timeout +ps2_recvbyte timeout +ps2_recvbyte timeout \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/526 b/results/classifier/gemma3:12b/peripherals/526 new file mode 100644 index 000000000..2ddfc4998 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/526 @@ -0,0 +1,16 @@ + +MacBook German Keyboard <> and ^° Key not working +Description of problem: +Using a German keyboard on my 2018 MacBook Pro I can't type the <> Key or the ^ Key. +When pressing the <> Key it gets interpreted as the ^ Key, the ^ Key is dead. + +Problem is not caused by the guest system, Ubuntu VMs also can't type <>. (Ubuntu VMs ran inside UTM, which internally uses QEMU. https://mac.getutm.app/ ) + +VirtualBox maps the <> Key and ^ Key correctly. +Steps to reproduce: +0. Use a MacBook with a German Keyboard +1. Install TempleOS +2. Install German Keyboard Layout from https://github.com/Rion96/GKey (mount the ISO as a CD Drive) +3. Every key works except for <> and ^. +Additional information: +Doing the same steps in VirtualBox results in <> and ^ working, so it must be a QEMU error. diff --git a/results/classifier/gemma3:12b/peripherals/529 b/results/classifier/gemma3:12b/peripherals/529 new file mode 100644 index 000000000..8dd11faae --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/529 @@ -0,0 +1,5 @@ + +qemu-system-riscv64 hard lockup on non-stdio serial output +Additional information: +u-boot pre-compiled firmware: (directory contains all git revisions, build flags, etc) +https://github.com/haiku/firmware/tree/master/u-boot/riscv64/qemu diff --git a/results/classifier/gemma3:12b/peripherals/533613 b/results/classifier/gemma3:12b/peripherals/533613 new file mode 100644 index 000000000..a526b6c67 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/533613 @@ -0,0 +1,5 @@ + +fr-ca keymap is wrong + +The fr-ca keymap has tons of wrong keys in it, it affects other projects using Qemu/KVM like Xen. +Documentation about how to make a keymap is too vague to allow me to make something useful to send a patch, I was however able to make something which at least allows me to use important keys like dot and slash, I will attach it for reference. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/538 b/results/classifier/gemma3:12b/peripherals/538 new file mode 100644 index 000000000..3bd01de67 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/538 @@ -0,0 +1,2 @@ + +Memory Leak in hpet_timer results in unusable machine diff --git a/results/classifier/gemma3:12b/peripherals/54 b/results/classifier/gemma3:12b/peripherals/54 new file mode 100644 index 000000000..981a91342 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/54 @@ -0,0 +1,2 @@ + +Attaching SD-Card to specific SD-Bus Sabrelite (ARM) diff --git a/results/classifier/gemma3:12b/peripherals/549 b/results/classifier/gemma3:12b/peripherals/549 new file mode 100644 index 000000000..490d5576c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/549 @@ -0,0 +1,2 @@ + +FPE in npcm7xx_clk_update_pll diff --git a/results/classifier/gemma3:12b/peripherals/584 b/results/classifier/gemma3:12b/peripherals/584 new file mode 100644 index 000000000..3ce2250a5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/584 @@ -0,0 +1,44 @@ + +qemu-system-ppc: extra IPI interrupt on core0 +Description of problem: +When I try to emit an IPI interrupt from core0 to another core via the MPIC controller(IPIDR1—Interprocessor interrupt dispatch register 1), core0 itself generates an unwanted IPI interrupt. +Steps to reproduce: +1. Prepare ISR routine, something like: + + void ipi_handler (void) + { + int core_id = CORE_ID_GET(); + myprintf("\n IPI interrupt triggered on core:%d\n",core_id); + } +2. Create a task and bind it to core0. This task is mainly to write the MPIC controller to emit IPI interrupts to other cores. + MPIC_REG_WRITE(MPIC_BASE + IPIDR1, **0xe**); + +3. run the test task +Additional information: +/* Below test was tested on Qemu6.1 */ + +IPI interrupts are emitted by core:0 + +**IPI interrupt triggered on core:0** /* it's a bug, it should not trigger on core 0. */ + +IPI interrupt triggered on core:1 + +IPI interrupt triggered on core:2 + +IPI interrupt triggered on core:3 + + +This bug only occurs when "emitting an IPIDR1 interrupt from **core0**". + +------------ + + +/* Below test was tested on real board(fsl_p4080ds) */ + +IPI interrupts are emitted by core:0 + +IPI interrupt triggered on core:1 + +IPI interrupt triggered on core:2 + +IPI interrupt triggered on core:3 diff --git a/results/classifier/gemma3:12b/peripherals/584155 b/results/classifier/gemma3:12b/peripherals/584155 new file mode 100644 index 000000000..12ee17d8c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/584155 @@ -0,0 +1,5 @@ + +support horisontal mouse wheel + +Brad Jorsch provided a series of patches to support horisontal mouse scrolling in qemu-emulated mouse. +See Debian bug#579968 -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579968 and submission to qemu-devel list at http://<email address hidden>/msg30991.html . \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/608107 b/results/classifier/gemma3:12b/peripherals/608107 new file mode 100644 index 000000000..ffd415e94 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/608107 @@ -0,0 +1,7 @@ + +ppc fails to clear MSR_POW when incurring exception + +QEMU VERSION: 0.12.4 + +According to FreeScale's 'Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005], section 6.5, table 6-7, an interrupt resets MSR_POW to zero but qemu-0.12.4 fails to do so. +Resetting the bit is necessary in order to bring the processor out of power-management since otherwise it goes to sleep right away in the exception handler, i.e., it is impossible to leave PM-mode. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/612297 b/results/classifier/gemma3:12b/peripherals/612297 new file mode 100644 index 000000000..af1f793da --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/612297 @@ -0,0 +1,14 @@ + +qemu-kvm fails to detect mouse while Windows 95 setup + +CPU: AMD Phenom II X4 945 +KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package) +Kernel: linux-2.6.26.8-rt16 +arch: x86_64 +Guest: Windows 95 B + +I'm trying to install Windows 95 B on qemu-kvm with this options: + +kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M -rtc base=localtime -k de -soundhw sb16 -vga cirrus -net user,hostname=w95vm -net nic,model=ne2k_pci -boot a -fda /var/mmn/vm/floppy/win95B_Drive-D-boot.img -cdrom /var/mmn/vm/CD/win95-setup.iso -no-acpi -no-kvm -usb + +I've also tried some other option, but always the same: no ps/2 mouse detection. And usb mouse is not supported by Windows 95 B while setup process. This is only possible later by installing the extension usbsupp.exe after the system setup. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/612452 b/results/classifier/gemma3:12b/peripherals/612452 new file mode 100644 index 000000000..e258652de --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/612452 @@ -0,0 +1,16 @@ + +Problems with the number of serial ports for more than two + +qemu --version +QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard + +Command line: + +qemu -serial null -serial null -serial file:test1 hd.img + +Error: + +isa irq 4 already assigned + +echo $? +1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/615 b/results/classifier/gemma3:12b/peripherals/615 new file mode 100644 index 000000000..7af4d4fa1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/615 @@ -0,0 +1,11 @@ + +Not sure if this is a qemu issue but SD card is not correctly read. blk_update_request: I/O error on Manjaro libvirt OS. +Description of problem: + +Steps to reproduce: +1. Run vagrant command line +2. Start console in virt-manager +3. Add USB SD card reader device with SD card. +4. Go back to console +Additional information: +I've bought a new SD card reader and SD card, tried it on other ports and the problem persists. diff --git a/results/classifier/gemma3:12b/peripherals/627982 b/results/classifier/gemma3:12b/peripherals/627982 new file mode 100644 index 000000000..76a969b82 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/627982 @@ -0,0 +1,8 @@ + +linux 2.6.35 hangs with -no-acpi + +Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance the Debian kernel: + +qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 + +There is no output except just "Booting the kernel" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/638 b/results/classifier/gemma3:12b/peripherals/638 new file mode 100644 index 000000000..f7428ac50 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/638 @@ -0,0 +1,14 @@ + +exynos4210_uart.c: SIGSEGV when loadvm +Description of problem: +Line 619 of hw/char/exynos4210_uart.c cast the object incorrectly. + +The function will be called with Exynos4210UartFIFO as opaque because it is set as `vmstate_exynos4210_uart_fifo.post_load` + +# +Steps to reproduce: +1. Create a VM with exynos4210_uart +2. savevm +3. loadvm +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/639651 b/results/classifier/gemma3:12b/peripherals/639651 new file mode 100644 index 000000000..3a8d539de --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/639651 @@ -0,0 +1,22 @@ + +DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver installed + +Positng the issue here since I did not get any reply on the ML. + +I was trying to update some windows XP (SP3) images in kvm. + +It worked fine several times but last time I added mass storage +drivers to sysprep and now on the second boot after reseal (the first +is mini-setup) I get a BSOD with message +DRIVER_IRQL_NOT_LESS_OR_EQUAL. I can post the screenshot if somebody +thinks it is interesting enough. + +The same image works on hardware (which has controllers different from +the qemu PIIX3) and in VirtualBox (with the default PIIX4 as well as +PIIX3) so long as IO apic is enabled). + +I am not sure if this is an error with the MS drivers or how they are +used in sysprep in this particular case or if his is some strange +error in qemu emulation in the PIIX3 controller or elsewhere. + +The image is originally created on hardware with MP acpi (not virtualization). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/656 b/results/classifier/gemma3:12b/peripherals/656 new file mode 100644 index 000000000..e9b415999 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/656 @@ -0,0 +1,8 @@ + +qemu-system-arm sabrelite does not use sd card +Description of problem: +I have build qemu from source. Furthermore I build Uboot from source following [this Link](https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html). With the provided command lines I am able to create and image and start the sabrelite board and see Uboot console Output. The problem I am facing is, that I am not able to interact with the provided tmp.img. + +I was also using the -driver option instead of the -blockdev option, but did not get any different results with that. +Additional information: +I provide the console output in the attached file. [console.out](/uploads/996b8c07310ec3b008477e3e70a2e629/console.out) diff --git a/results/classifier/gemma3:12b/peripherals/657329 b/results/classifier/gemma3:12b/peripherals/657329 new file mode 100644 index 000000000..c03853abf --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/657329 @@ -0,0 +1,48 @@ + +APIC unusable on QEMU + +The APIC is unusable with QEMU using x86-64 system emulation. Problem exists in the latest stable QEMU 0.12.5 as well as the latest git head. I am using Mac OS X 10.6, 64-bit version of QEMU. + +The QEMU binary was configured with: + + ./configure --target-list=i386-softmmu,x86_64-softmmubck-i-search: conf_ + +Problem is that the hw/apic.c file (as well as a few other naughty files) rely on the cpu_single_env global - which is set to NULL in cpu-exec.c. + +Below is a test reading the local APIC version register: + +Before taking it out: + +(qemu) xp 0xfee00030 +00000000fee00030: 0x00000000 +(qemu) + +After: + +(qemu) xp 0xfee00030 +00000000fee00030: 0x00050011 +(qemu) + +Quick fix below. I don't know if there are any side effects with this, if this is OK maybe we can fix it like this for the stable versions and fix the HEAD to not rely on the cpu_single_env global. + +diff --git a/cpu-exec.c b/cpu-exec.c +index dbdfdcc..3e966d7 100644 +--- a/cpu-exec.c ++++ b/cpu-exec.c +@@ -674,7 +674,17 @@ int cpu_exec(CPUState *env1) + env = (void *) saved_env_reg; + + /* fail safe : never use cpu_single_env outside cpu_exec() */ ++#warning fixup devices which rely on this ++#if 0 ++ /* ++ * Hello. This is wrapped around an #if 0 ... #endif because that's ++ * what should happen. However, certain naughty devices (like the APIC ++ * for instance, and a few others), access this global variable. ++ * ++ * So this is here for now ... until we fix up those devices. ++ */ + cpu_single_env = NULL; ++#endif + return ret; + } \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/658152 b/results/classifier/gemma3:12b/peripherals/658152 new file mode 100644 index 000000000..483161849 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/658152 @@ -0,0 +1,16 @@ + +jp106 keyboard cannot input "_" key + +My environment are +cpu model = AMD Phenom II X2 545 +kvm version = Virtual Machine Manager 0.8.5 +host kernel version = vmlinuz-2.6.34.7-56.fc13.x86_64 +host kernel arch = x86_64 +guest you are using = CentOS-5.5, slackware-13.1 +qemu command = not use +I do not use -no-kvm-irqchip or -no-kvm-pit switch or -no-kvm switch. + +Report +I use jp106 keybord on host OS( Fedora Core 13), it work fine. +but I could not keyin "_" key on GestOS( CentOS-5.5, Slackware-13.1). +I change keybord but same result, so I reported a bug. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/668 b/results/classifier/gemma3:12b/peripherals/668 new file mode 100644 index 000000000..7bfedab27 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/668 @@ -0,0 +1,22 @@ + +No trace verbs +Description of problem: +I am trying to follow [this tutorial](https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver) to get my sound working again, but I am stuck at the step where I have to analyse the verbs, because I get none. They say I should get things similar to this: +``` +CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0) +CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2) +CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4) +RIRBWP advance to 3, last WP 0 +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x10ec0245 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100001 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0) +``` +in the `qemu-output.txt` file, but instead I am getting [this](https://github.com/ryanprescott/realtek-verb-tools/files/7331986/qemu-output.txt) in the console. + +How do I get verbs in the first format ? + +I tried compiling qemu from source with this: `./configure --enable-trace-backends=log --target-list=x86_64-softmmu`, but that produced the same result as using the `qemu-system-x86_64` command that I got by installing qemu with my package manager. +Steps to reproduce: +https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver +Additional information: +I don't know, as me if I am missing something diff --git a/results/classifier/gemma3:12b/peripherals/678 b/results/classifier/gemma3:12b/peripherals/678 new file mode 100644 index 000000000..814dbd185 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/678 @@ -0,0 +1,48 @@ + +eject (monitor command) not work for blockdev cdrom +Description of problem: +cdrom1 device work fine, all files reads, but when i whant to eject CD-ROM disk from device by telnet monitor, it not work. +Steps to reproduce: +1. Connect to monitor with +``` +telnet 127.0.0.1 9100 +(QEMU 5.2.0 monitor - type 'help' for more information) +``` + +2. Show block devices +``` +info block +cdrom1-format: /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only) + Attached to: cdrom1 + Removable device: not locked, tray closed + Cache mode: writeback +``` + +3. Send eject commands +``` +eject cdrom1 +Error: Device 'cdrom1' not found +eject cdrom1-format +Error: Device 'cdrom1-format' not found +eject cdrom1-storage +Error: Device 'cdrom1-storage' not found +``` +Additional information: +When i run qemu with next lines (replace -blockdev to -drive): +``` +-device ide-cd,bus=ide.1,drive=cdrom1,id=idecd1,bootindex=2 +-drive if=none,id=cdrom1,media=cdrom,readonly=on,file="/mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso" +``` + +eject cdrom1 command work fine + +``` +info block +cdrom1 (#block133): /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only) + Attached to: idecd1 + Removable device: not locked, tray closed + Cache mode: writeback +eject cdrom1 +``` + +Also i found a similar bug description on this link https://bugs.launchpad.net/qemu/+bug/1799766 diff --git a/results/classifier/gemma3:12b/peripherals/678363 b/results/classifier/gemma3:12b/peripherals/678363 new file mode 100644 index 000000000..41c95999c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/678363 @@ -0,0 +1,12 @@ + +Swapping caps lock and control causes qemu confusion + +Running Fedora14 [host], I have caps-lock and control swapped over in my keyboard preferences. + +Qemu doesn't cope very well with this; running an OS inside Qemu (again fedora, suspect that it doesn't matter): + +The physical caps-lock key [which the host uses as control] toggles caps-lock on both press and release. + +The physical control key [which the host uses as caps-lock], acts as both a caps-lock and control key. + +Qemu should either respect my keyboard layout or else ignore it completely. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/685096 b/results/classifier/gemma3:12b/peripherals/685096 new file mode 100644 index 000000000..a1898a500 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/685096 @@ -0,0 +1,16 @@ + +USB Passthrough not working for Windows 7 guest + +USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. + +The device appears in the device manager of Windows 7, but with "Error code 10: device cannot start". I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. + +I am trying this with the latest git-pull of QEMU-KVM. + +The command line to launch qemu-kvm for win7 is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 + +The command line to launch qemu-kvm for winxp is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 + +Any help is appreciated. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/688052 b/results/classifier/gemma3:12b/peripherals/688052 new file mode 100644 index 000000000..39d9eeeb1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/688052 @@ -0,0 +1,29 @@ + +usb does not work 0.13.0 + +Hi all, I'm using both, debian lenny and debian squeeze. +I installed qemu-kvm (0.12.5) form debian repository but I got problem trying to pass a host usb device to the guest. + +I compiled so the latest stable version (0.13.0) hoping that the problem was fixed. +It didn't help, the error I get is always: + +usb_create: no bus specified, using "usb.0" for "usb-host" + +The command I use is + +qemu-system-x86_64 -hda lenny_amd64_vergine.qcow2 -usbdevice host:002.007 -boot order=c + +On internet I found this, it might help: +http://<email address hidden>/msg38795.html + +The guest is a simple debian lenny with 2.6.26 kernel. + + +I tried also to download the qemu development version but the download get interruped + +git clone http://git.qemu.org/qemu.git +Cloning into qemu... +error: Failed connect to git.qemu.org:80; No such file or directory (curl_result = 7, http_code = 0, sha1 = 62d76a25fe741bdaf1157f0edaf50a7772541db6) +error: Unable to find 62d76a25fe741bdaf1157f0edaf50a7772541db6 under http://git.qemu.org/qemu.git + +I attach more info about the host machine I'm testing on. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/696530 b/results/classifier/gemma3:12b/peripherals/696530 new file mode 100644 index 000000000..9f3d14e02 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/696530 @@ -0,0 +1,8 @@ + +qemu-0.13.0-r2 special keys different when using -alt-grab + +I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f for full screen did not work for me with a windows guest. They work normally when omitting the -alt-grab startup parameter. + +After quite a long time, I found out that I have to add the shift key to the keys from the documentation when I use the -alt-grab option. + +Probably -ctrl-grab behaves similarly. It would be really nice to have this documented in the default documentation in the man page as has not been documented there yet. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/72 b/results/classifier/gemma3:12b/peripherals/72 new file mode 100644 index 000000000..b57ef8c09 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/72 @@ -0,0 +1,2 @@ + +mouse offset or invisible wall 2.11.0-3 diff --git a/results/classifier/gemma3:12b/peripherals/721659 b/results/classifier/gemma3:12b/peripherals/721659 new file mode 100644 index 000000000..56f229c24 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/721659 @@ -0,0 +1,17 @@ + +qemu-kvm-0.13.0 doesn't pass USB devices to the VM + +I have the bug, similar to this one: +https://bugzilla.redhat.com/show_bug.cgi?id=583108 +but under gentoo + +When I add parameters -usb -usbdevice host:4348:5584, I see the following lines in console: + +husb: config #1 need -1 +USBDEVFS_DISCONNECT: No route to host +husb: open device 2.11 +(...many repetitions of three above lines...) + +All parameters (2.11) are verified with lsusb at host computer - parameters are correct + +Error description is very confusing - I don't know what to check, what "config #1" mean, which route should be checked and how to check it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/725 b/results/classifier/gemma3:12b/peripherals/725 new file mode 100644 index 000000000..7d7e98ac5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/725 @@ -0,0 +1,15 @@ + +GICv3 ITS CTLR[Enabled] bit can not be cleared +Description of problem: +ITS CTLR[Enabled] can not be cleared, + + `s->ctlr |= (value & ~(s->ctlr));` + +Link: +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/intc/arm_gicv3_its.c#L899 +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/73 b/results/classifier/gemma3:12b/peripherals/73 new file mode 100644 index 000000000..14204272b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/73 @@ -0,0 +1,2 @@ + +KVM Windows 98 sound card passthrough is not working for DOS programs.. diff --git a/results/classifier/gemma3:12b/peripherals/752476 b/results/classifier/gemma3:12b/peripherals/752476 new file mode 100644 index 000000000..d9c777a45 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/752476 @@ -0,0 +1,9 @@ + +monitor command mouse_button 1 moves mouse + +via the qemu -monitor interface, it is possible to move and click the mouse using +mouse_move 20000 10000 +mouse_button 1 +but the mouse_button command always moves the mouse to (0,0) making it rather unusable to (auto-)trigger any widgets in the VM from the outside. + +Would be nice to have this available for my qemu/kvm based os-autoinst testing framework. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/77 b/results/classifier/gemma3:12b/peripherals/77 new file mode 100644 index 000000000..d4d9ecfa5 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/77 @@ -0,0 +1,2 @@ + +msmouse not recognized in guest diff --git a/results/classifier/gemma3:12b/peripherals/771 b/results/classifier/gemma3:12b/peripherals/771 new file mode 100644 index 000000000..580332286 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/771 @@ -0,0 +1,15 @@ + +No interrupts are delivered to the guest after rebooting Windows 98 +Description of problem: +After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts. The guest performs fine before the reboot. + +Closer examination reveals that no hardware interrupts are delivered to the guest. BIOS Data Area variables like the keyboard buffer and the system clock are not updated. Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor. + +The only remedy seems to be to exit the QEMU process entirely and launch it again. +Steps to reproduce: +0. Install Windows 98 into the guest. (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.) +1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load. (I managed sometimes to reproduce the bug without the system having loaded fully.) +2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent) +3. Observe the system freeze. +Additional information: +None diff --git a/results/classifier/gemma3:12b/peripherals/778032 b/results/classifier/gemma3:12b/peripherals/778032 new file mode 100644 index 000000000..93fe2783d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/778032 @@ -0,0 +1,71 @@ + +qemu spinning on serial port writes + +As originally found at http://<email address hidden>/msg08745.html from 3 years ago! + +Basically qemu seizes up in the event that the file descriptor for its emulated serial port has a full buffer, i.e. write() returns EAGAIN. For me, this happened when the serial port was being directed through a UNIX socket, with a default-sized 4KB buffer. Just the normal output from a Linux kernel boot caused it to seize up, and stop the main emulation / select loop. + +My suggestion is to remove the detection of EAGAIN in qemu-char.c:521, so that if the buffer is full, KVM discards the byte(s) it was trying to write. This is a surely better outcome than the process spinning forever. + +I will submit a separate patch to control the buffer sizes when creating UNIX sockets, which will help allow slow-reading processes to tune things so that they don't miss any output. + +Additionally, in the context of a hosted environment, if the -serial option is used, this could be a small security issue. An untrusted user of a guest system, knowing their serial output is going via a small buffer, could spew output to their /dev/ttyS0 at a rate fast enough to trigger this bug and eat a CPU core on the host. + +To quote David S. Ahern's original bug report (mine was the same, only with the latest version from git, so line numbers may have changed - my suggested fix above is accurate though): + +I am trying to redirect a guest's boot output through the host's serial +port. Shortly after launching qemu, the main thread is spinning on: + +write(9, "0", 1) = -1 EAGAIN (Resource temporarily unavailable) + +fd 9 is the serial port, ttyS0. + + +The backtrace for the thread is: + +#0 0x00002ac3433f8c0b in write () from /lib64/libpthread.so.0 +#1 0x0000000000475df9 in send_all (fd=9, buf=<value optimized out>, +len1=1) at qemu-char.c:477 +#2 0x000000000043a102 in serial_xmit (opaque=<value optimized out>) at +/root/kvm-81/qemu/hw/serial.c:311 +#3 0x000000000043a591 in serial_ioport_write (opaque=0x14971790, +addr=<value optimized out>, val=48) + at /root/kvm-81/qemu/hw/serial.c:366 +#4 0x00000000410eeedc in ?? () +#5 0x0000000000129000 in ?? () +#6 0x0000000014821fa0 in ?? () +#7 0x0000000000000007 in ?? () +#8 0x00000000004a54c5 in tlb_set_page_exec (env=0x10ab4, +vaddr=46912496956816, paddr=1, prot=-1, mmu_idx=0, is_softmmu=1) + at /root/kvm-81/qemu/exec.c:388 +#9 0x0000000000512f3b in tlb_fill (addr=345446292, is_write=1, +mmu_idx=-1, retaddr=0x0) + at /root/kvm-81/qemu/target-i386/op_helper.c:4690 +#10 0x00000000004a6bd2 in __ldb_cmmu (addr=9, mmu_idx=0) at +/root/kvm-81/qemu/softmmu_template.h:135 +#11 0x00000000004a879b in cpu_x86_exec (env1=<value optimized out>) at +/root/kvm-81/qemu/cpu-exec.c:628 +#12 0x000000000040ba29 in main (argc=12, argv=0x7fff67f7a398) at +/root/kvm-81/qemu/vl.c:3816 + +send_all() invokes unix_write() which by design is not breaking out on +EAGAIN. + +The following command is enough to show the problem: + +qemu-system-x86_64 -m 256 -smp 1 -no-kvm \ + -drivefile=/dev/cciss/c0d0,if=scsi,cache=off,boot=on \ + -vnc :1 -serial /dev/ttyS0 + + +The guest is running RHEL3 with the parameter 'console=ttyS0' added to +grub.conf; the problem appears to be with qemu, so I would expect it to +show with any linux guest. This particular host is running RHEL5.2 with +kvm-81, but I have also seen the problem with Fedora-9 as the host OS. + +Yes, the serial port of the server is connected to another system via a +null modem. If I change the serial argument to '-serial udp::4555' and +use 'nc -u -l localhost 4555 > /dev/ttyS0' I see the guest's boot +output show up on the second system as expected. I'd prefer to be able +to use the serial port connection directly without nc as a proxy. +Suggestions? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/783 b/results/classifier/gemma3:12b/peripherals/783 new file mode 100644 index 000000000..7a0113c9e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/783 @@ -0,0 +1,4 @@ + +risc-v: provide CPU without MMU +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/785 b/results/classifier/gemma3:12b/peripherals/785 new file mode 100644 index 000000000..d041cd323 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/785 @@ -0,0 +1,2 @@ + +Build failure on macOS with jack diff --git a/results/classifier/gemma3:12b/peripherals/786211 b/results/classifier/gemma3:12b/peripherals/786211 new file mode 100644 index 000000000..d078b9ad9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/786211 @@ -0,0 +1,4 @@ + +Missing checks for valid, writable, firmware in fw_cfg_write + +The `fw_cfg_write` function in the firmware emulation is missing checks to ensure that the firmware being written is (a) a valid index, and (b) writable. This can lead to a segmentation fault and potentially (in the case of writing to FW_CFG_INVALID), memory corruption, although the attacker has fairly limited control over whether and what corruption is possible. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/79 b/results/classifier/gemma3:12b/peripherals/79 new file mode 100644 index 000000000..57eef989e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/79 @@ -0,0 +1,2 @@ + +support horisontal mouse wheel diff --git a/results/classifier/gemma3:12b/peripherals/804517 b/results/classifier/gemma3:12b/peripherals/804517 new file mode 100644 index 000000000..1aac5d252 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/804517 @@ -0,0 +1,45 @@ + +qemu crashes on Darwin in qemu_iohandler_poll + +I have an issue when I try to run qemu-system-arm on Mac OS X. +Sometime between 1 and 15 secs after qemu is started it crashes +as shown bellow. + +Same thing on linux host works fine. + +Is anybody else experiencing this? +Any Hints? + +Thanks, + +Damjan + + + +(gdb) run +Starting program: /opt/arm-qemu/bin/qemu-system-arm -M verdex -pflash flash.img -nographic -monitor null -m 289 +Reading symbols for shared libraries .++++++++++++++........................................................................................ done +pxa2xx_clkpwr_write: CPU frequency change attempt + + +U-Boot 1.2.0 (May 10 2008 - 21:17:19) - PXA270@400 MHz - 1604 + +*** Welcome to Gumstix *** + +DRAM: 256 MB +Flash: 32 MB +Using default environment + +Hit any key to stop autoboot: 1 +Program received signal EXC_BAD_ACCESS, Could not access memory. +Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5fbfed30 +0x00007fff5fbfed30 in ?? () +(gdb) +(gdb) bt +#0 0x00007fff5fbfed30 in ?? () +#1 0x00000001000c26f4 in qemu_iohandler_poll () +#2 0x00000001001975ae in main_loop_wait () +#3 0x00000001001976e2 in main_loop () +#4 0x000000010019bfbc in qemu_main () +#5 0x00000001000d63a5 in main () +(gdb) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/810588 b/results/classifier/gemma3:12b/peripherals/810588 new file mode 100644 index 000000000..ed515774b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/810588 @@ -0,0 +1,6 @@ + +Unexpected crash of qemu-kvm with SCSI disk emulation. + +Virual machine with MS windows 2003 installed on the virtual scsi disk (-drive file=/my/path/myimage.qcow2.img,boot=on,if=scsi,media=disk,bus=0,unit=1) unexpectedly crashes without core dump. When the image is connected as an ide disk (-hda ) vm flies normally. +Qemu-kvm version: 0.12.5 +Os/distr.: Debian squeeze, x86_64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/812398 b/results/classifier/gemma3:12b/peripherals/812398 new file mode 100644 index 000000000..03b5cb4e7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/812398 @@ -0,0 +1,12 @@ + +powerpc 7450 MMU initialization broken + +The 7540 family of PPCs' MMU can update TLBs using hardware search (like a 604 or 7400) but also using a software algorithm. The mechanism used is defined by HID0[STEN]. + +By default (CPU reset) HID0 is set to 0x80000000 (BTW; another small bug, qemu doesn't set the hardwired MSB), hence +the software-table lookup feature is *disabled*. However, the default (and immutable) 'mmu_model' for this CPU family is POWERC_MMU_SOFT_74XX which choses the soft TLB replacement scheme. + +To fix this: + +1) the initial mmu_model for the 7450 family (includes 7441, 7445, 7451, 7455, 7457, 7447, 7448) should be: POWERPC_MMU_32B +2) when HID0[STEN] is written then the mmu_model should be changed accordingly (I'm not familiar enough with the qemu internal state to judge if any cached state would have to be updated). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/813546 b/results/classifier/gemma3:12b/peripherals/813546 new file mode 100644 index 000000000..21a251f90 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/813546 @@ -0,0 +1,6 @@ + +option to disable PS/2 mouse + +Adds an option to disable the PS/2 mouse. + +This is useful to work around bugs in PS/2 drivers in some system or testing system without a PS/2 mouse present. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/821078 b/results/classifier/gemma3:12b/peripherals/821078 new file mode 100644 index 000000000..8e1b857c7 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/821078 @@ -0,0 +1,14 @@ + +virtio-serial-bus: Unexpected port id + +With qemu-kvm-0.15.0-rc1 virtio-serial-bus reports an error, and windows vdagent can not start. qemu-0.15.0-rc1 behaves as expected, ie vdagent runs in the guest, mouse passes seamlessly between spicec and host and copy/paste works between guest and host. +qemu-kvm has been configured with +./configure --target-list=x86_64-softmmu --disable-curses --disable-curl --audio-drv-list=alsa --audio-card-list=sb16,ac97,hda --enable-vnc-thread --disable-bluez --enable-vhost-net --enable-spice +and is started with +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,aio=native -m 1536 -name WinXP -net nic,model -net user -localtime -usb -vga qxl -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio + +I've also tried start qemu like +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio +and observed the same results. + +the host runs 2.6.39.4 vanilla kernel. the guest uses the most recent virtio-serial, vga-qxl and vdagent from spice-space.org \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/835 b/results/classifier/gemma3:12b/peripherals/835 new file mode 100644 index 000000000..224263369 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/835 @@ -0,0 +1,10 @@ + +SDL display does not handle ps2 relative packets +Description of problem: +The main problem: while tracing relative events input_event_rel all mouse events are positive and seems to be the absolute x and y mouse position. When that happens ps2 sends a +x -y of a full 127 count. +Steps to reproduce: +1. Trace input_event_rel +2. Observe that when moving the mouse the trace always shows positive values, that doesn't depend on what direction you move the mouse +3. Observe that the xrel and yrel is more like absolute positions +Additional information: +I noticed searching on sdl2 docs and some issues related to SDL2 mouse events that when you do not specify SDL_HINT_MOUSE_RELATIVE_MODE_WARP weird things happens, i tried adding SDL_SetHint(SDL_HINT_MOUSE_RELATIVE_MODE_WARP, "1"); at the end of the sdl2 init function and the mouse events started to show normal values. I'm not sure if that's the correct way to solve the bug, but it seems to be. diff --git a/results/classifier/gemma3:12b/peripherals/839790 b/results/classifier/gemma3:12b/peripherals/839790 new file mode 100644 index 000000000..22da71472 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/839790 @@ -0,0 +1,18 @@ + +-usbdevice tablet broken on win XP client + +I'm using the qemu-kvm package from arch (not the qemu package), and on prior versions of qemu-kvm I was able to use -usbdevide tablet without problems. The absolute mouse position is great... With current version of qemu-kvm, when I use -usbdevice tablet, I got no mouse at all. As my client is windows XP, it's not good to try do anything without mouse, :-) + +I searched in current bugs, and didn't find any bug which subject included "tablet", so I'm submitting this bug... + +Current qemu-kvm package in arch I'm using is: + +% pacman -Ss qemu-kvm +extra/qemu-kvm 0.15.0-2 [installed] + Latest KVM QEMU is a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation. + +Please notice I do not get any error, just the mouse broken... + +thanks, + +Javier. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/849 b/results/classifier/gemma3:12b/peripherals/849 new file mode 100644 index 000000000..6b698990d --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/849 @@ -0,0 +1,23 @@ + +High mouse polling rate stutters some applications +Description of problem: +There are couple of instances where moving the mouse would slow down some applications, especially for games + +https://www.reddit.com/r/VFIO/comments/ect3sd/having_an_issue_with_my_vm_where_games_stutter/ + +https://www.reddit.com/r/VFIO/comments/n9hwtg/game_fps_drop_on_mouse_input/ + +https://www.reddit.com/r/VFIO/comments/ln1uwb/evdev_mouse_passthrough_with_1000hz_mouse_causes/ + +https://www.reddit.com/r/VFIO/comments/se92rq/looking_for_advice_on_poor_gpu_passthrough/ + +I myself included, is impacted by this mysterious issue, I'm not pretty sure whether this is related to VFIO or QEMU or both, but I'm definitely sure this is a kind of regression in between since I had no such issue before. +Steps to reproduce: +1. Do a GPU passthrough +2. Get a mouse capable of outputting high polling rate like 1000Hz, usually they are categorized as gaming mouses +3. Start any 3D applications, including stuff like Unreal Engine 4 Editor or any games +4. See mysterious stuttering +Additional information: +I'm using an AMD Ryzen 7 3700X CPU as the host, but I have made scripts that pins CPU to the VM to get better performance speculatively by putting the threads on the same CCX to minimize memory latency as much as possible. This alleviated some terrible lag, but not by much. (like 11 FPS to 20 FPS if you move your mouse which is still crappy compared to 90+ FPS when static) + +I suspect there is something wrong with the USB subsystem. diff --git a/results/classifier/gemma3:12b/peripherals/873460 b/results/classifier/gemma3:12b/peripherals/873460 new file mode 100644 index 000000000..170e9b2c4 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/873460 @@ -0,0 +1,9 @@ + +Likewise no sound + +Hi, +using fresh Ubuntu 11.10 with Likewise 6 in a MS Domain. +Domain users log with no sound. +Local users are OK. + +Thx \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/879 b/results/classifier/gemma3:12b/peripherals/879 new file mode 100644 index 000000000..80de015d6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/879 @@ -0,0 +1,4 @@ + +Microphone support for Macbooks +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/893068 b/results/classifier/gemma3:12b/peripherals/893068 new file mode 100644 index 000000000..3e9bd2b27 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/893068 @@ -0,0 +1,12 @@ + +Spanish keys { and [ did not work + +The keys { and [ did not work inside the virtualized enviorment (widnows 7). The problems happens ussing aqemu as a front end as well as invoking qemu-kvm from command line: + +qemu-kvm -m 8096 eclipse.img -smp cores=4,threads=2 -hdb ander.img -k es + +We have also notices this warning in the console: + +Warning: no scancode found for keysym 314 + +The host system is gentoo stable with some exceptions (mainly qemu-kvm-0.15.1-r1, gcc-4.6.2 and kernel-3.2_rc2) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/894 b/results/classifier/gemma3:12b/peripherals/894 new file mode 100644 index 000000000..2c85e9d3b --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/894 @@ -0,0 +1,32 @@ + +target/riscv64 qemu-iotests 040 failed +Description of problem: +I cross-compiled a riscv64 QEMU flavor based on the most updated code, then make check. Some qemu-iotests failed, 040 041 127 256 267. I mainly focused on test 040 and tried to find out what happened. +Steps to reproduce: +1. change directory to QEMU source tree root +2. ./configure --prefix=~/temp --target-list=riscv64-softmmu +3. make +4. cd build/tests/qemu-iotests/ +5. ./check -qcow2 040 + +Then a lot of error messages(please see attachment). The following log might hint the root cause I thought: +``` ++ Command: /home/qemu/qemu/build/tests/qemu-iotests/../../qemu-system-riscv64 -display none -vga none -chardev socket,id=mon,path=/tmp/tmpwhnx3jq0/qemu-28363-monitor.sock -mon chardev=mon,mode=control -qtest unix:path=/tmp/tmpwhnx3jq0/qemu-28363-qtest.sock -accel qtest -nodefaults -display none -accel qtest -drive if=none,id=drive0,file=/home/qemu/qemu/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=mid,backing.backing.node-name=base -device virtio-scsi -device scsi-hd,id=scsi0,drive=drive0 ++ Output: [I 1646574338.669217] OPENED ++qemu-system-riscv64: -device virtio-scsi: No 'PCI' bus found for device 'virtio-scsi-pci' +``` +The command had no '-machine' argument. For riscv64 target, 'spike' will be the default machine. Maybe 'spike' have no PCI bus? Then I tried to change it to 'virt' machine but failed, nothing new happen. +``` +QEMU_DEFAULT_MACHINE=virt ./check -qcow2 040 +``` +``` +QEMU_OPTIONS="-machine virt" ./check -qcow2 040 +``` +Last, I modified [testenv.py](https://gitlab.com/qemu-project/qemu/-/blob/master/tests/qemu-iotests/testenv.py#L239) and added one line in machine-map, all tests passed! +``` +('riscv64', 'virt'), +``` + +Is there any way to easy the issue or do I miss something? Thank you! +Additional information: +[zlog.riscv.xz](/uploads/cbbad7c5c256d2b49d220aa6425e2b17/zlog.riscv.xz) diff --git a/results/classifier/gemma3:12b/peripherals/900 b/results/classifier/gemma3:12b/peripherals/900 new file mode 100644 index 000000000..f99694228 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/900 @@ -0,0 +1,2 @@ + +how to install gemu guest agent without configure script ? diff --git a/results/classifier/gemma3:12b/peripherals/904617 b/results/classifier/gemma3:12b/peripherals/904617 new file mode 100644 index 000000000..a29b87c4c --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/904617 @@ -0,0 +1,16 @@ + +device_add usb-hub causes segfault in qemu-1.0 + +When calling the command + +(qemu) device_add usb-hub,bus=usb.0,port=4 + +qemu replies + +Error: usb port 4 (bus usb.0) not found (in use?) + +Then qemu crashes with a segfault: + +[ 1546.177627] qemu-system-x86[1710]: segfault at 0 ip b75d3f8b sp bfddb0b0 error 6 in qemu-system-x86_64[b7488000+2e2000] + +Maybe it might be related to the docs/usb2.txt where UHCI has only 2 ports. But a mistake in the port number should not cause qemu to crash \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/924943 b/results/classifier/gemma3:12b/peripherals/924943 new file mode 100644 index 000000000..569b9cf6e --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/924943 @@ -0,0 +1,15 @@ + +usb-host devices given by command line are routed incomplete to the guest + +affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches (older versions not tested) +affected guests: linux, windows +test hardware: standard usb key (or any other piece of USB hardware) that works perfectly when plugged in after guest bootup + +Several Sequences have been tested: +- start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -device usb-host,bus=ehci.0 +- start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S (to not start up the guest directly) + at the console prompt: "device_add usb-host" then "c" to start the guest. + +For the linux guest, I get a usb device listed and detected as /dev/sdb when plugging it in at runtime. At startup linux does NOT detect it. +For the windows guest, I get a usb device listed and detected as "removable media" when plugging it in at runtime. At startup Windows does detect "something" that is listed in the device manager as Generic Mass Storage device, but with a yellow exclamation mark and there is no removable media listed in Explorer + +If you need further testings, just let me know. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/925 b/results/classifier/gemma3:12b/peripherals/925 new file mode 100644 index 000000000..e242effc4 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/925 @@ -0,0 +1,19 @@ + +AArch64 SVE2 LD/ST instructions segfault on MMIO addresses +Description of problem: +During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state: +``` +(gdb) p $x17 +$1 = 0xffffffe2 +(gdb) p $z26.s.u +$2 = {0x0 <repeats 16 times>} +(gdb) p $p2 +$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0} +``` +QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device. +Additional information: +A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices. + +<details><summary>Reproducer seed for my future self</summary> +S6008340160849309262|Q|cd4t|pq|w5|lK124 +</details> diff --git a/results/classifier/gemma3:12b/peripherals/93 b/results/classifier/gemma3:12b/peripherals/93 new file mode 100644 index 000000000..b6694f663 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/93 @@ -0,0 +1,2 @@ + +qemu 1.4.2: usb keyboard not fully working diff --git a/results/classifier/gemma3:12b/peripherals/932490 b/results/classifier/gemma3:12b/peripherals/932490 new file mode 100644 index 000000000..3df3958b1 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/932490 @@ -0,0 +1,10 @@ + +Qemu fails on -fda /dev/fd0 when no medium is present + +# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +# qemu-system-x86_64 -fda /dev/fd0 +qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No such device or address + +Starting with a medium (floppy disk) inserted, then removing or changing the medium works fine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/936 b/results/classifier/gemma3:12b/peripherals/936 new file mode 100644 index 000000000..e6bb4a7b6 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/936 @@ -0,0 +1,17 @@ + +Serial output mangled in terminal +Description of problem: +My hobby OS uses the serial port at `0x3f8` to log messages to QEMU's stdout. This used to work fine, I can even emit ANSI escape codes to get color output and it renders in my terminal as expected. I left this project for about a year and just returned to it with the latest version of QEMU. Now, all of the QEMU serial output from my OS in the terminal seems to be missing carriage returns and buffering strangely. It's as if every log line ends up on the same line in the stdout buffer, but with newlines (without returning to the start of the line) between them. For example (these aren't my real logs but demonstrate the issue): +``` +[KERNEL] startup + [KERNEL] initializing heap + [KERNEL] initializing drivers + [KERNEL] ready! +``` +Also, when QEMU exits, I notice that my shell indicates that the last command's output didn't end in a newline which is strange. + +I tried debugging this myself by piping the output to a file and inspecting it in a hex editor, but it looks like just normal newlines in the output. I tried piping the output to `tr '\n' '\r\n'` to add carriage returns, but that ends up rendering all the output on a single line which resets to the first column every line. I tried sending the output to a file and watching the file, but it seems to get buffered and the data only shows up once QEMU exits. My best guess is that the output hasn't changed, but this new version of QEMU is changing some kind of buffering setting on its output which is causing this, but I'm really not sure what's going on. +Steps to reproduce: +I can provide the boot image if that would be helpful to reproduce. +Additional information: + diff --git a/results/classifier/gemma3:12b/peripherals/938552 b/results/classifier/gemma3:12b/peripherals/938552 new file mode 100644 index 000000000..e5f732438 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/938552 @@ -0,0 +1,24 @@ + +ENH: Inherit ptys, useful output from -serial pty + +When controlling a qemu instance from another program, it'd be very useful to be able to have qemu inherit pseudo-tty file descriptors so they could just be specified on the command line. + +It's possible to allocate a pty pair in the master program before forking and exec'ing qemu and have qemu use that pty, but it's a bit painful. The master program must call ptsname(...) on the fd of the slave side and insert the path to the pty device node into qemu's command line. This doesn't work well in many scripting languages which lack a ptsname() call; a Linux-specific hack like readlink() of /proc/self/fd/[slave-fd] is necessary. + +If qemu accepted file descriptors for serial I/O this would all be a lot more flexible, and it wouldn't be limited to ptys either. Just accept a new format for "-serial" like "-serial fd:7" and have the parent program not set that FD to close-on-exec. + +None of this would be as necessary if qemu's "-serial pty" option was fully functional. Unfortunately, it doesn't provide any information to associate the created PTY(s) with their qemu devices, so it's hard to know which serial port is which, which the monitor device is, etc. See, eg: + +$ qemu -serial pty -serial pty -monitor pty +char device redirected to /dev/pts/6 +char device redirected to /dev/pts/7 +char device redirected to /dev/pts/8 + +... which is which? Are they allocated in the order they're specified on the command line? Nope, because /dev/pts/6 is the monitor in this case. With more than one device using "pty" a lot of guesswork is involved. + +If you're using "-monitor stdio" you can issue an "info chardev" and parse that to find out what everything else is connected to, but this shouldn't really be necessary. Ideally the device names would be printed when a port is redirected to a pty, eg: + +$ qemu -serial pty -serial pty -monitor pty +char device compat_monitor0 redirected to /dev/pts/6 +char device serial0 redirected to /dev/pts/7 +char device serial1 redirected to /dev/pts/8 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/peripherals/955 b/results/classifier/gemma3:12b/peripherals/955 new file mode 100644 index 000000000..37db0d955 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/955 @@ -0,0 +1,2 @@ + +support multiple UARTs in qemu-riscv-virt by default diff --git a/results/classifier/gemma3:12b/peripherals/958 b/results/classifier/gemma3:12b/peripherals/958 new file mode 100644 index 000000000..4942c0597 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/958 @@ -0,0 +1,14 @@ + +qemu-system-sparc crashes on floppy access +Description of problem: +qemu-system-sparc crashes when accessing the emulated floppy drive of the guest system. +Steps to reproduce: +1. wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/sparc/installation/bootfs/boot.fs.gz +2. gunzip boot.fs.gz +3. qemu-system-sparc -nographic boot.fs +4. Select option "3) floppy" +5. qemu-systems-sparc crashes with the messages: +``` + Ejecting floppy disk + Segmentation fault (core dumped) +``` diff --git a/results/classifier/gemma3:12b/peripherals/98 b/results/classifier/gemma3:12b/peripherals/98 new file mode 100644 index 000000000..ac4293ce9 --- /dev/null +++ b/results/classifier/gemma3:12b/peripherals/98 @@ -0,0 +1,2 @@ + +Curses Keyboard Broken On OS X |