summary refs log tree commit diff stats
path: root/results/classifier/deepseek-2-tmp/output/peripherals
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/peripherals')
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1022
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/102030918
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/10426546
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1062
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/108008625
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/108674512
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/109060212
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/109456420
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/114910
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/121021213
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/123214
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/124156910
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/12432
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/124747825
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/125227016
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/125456
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/125530324
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/127279620
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/12824
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/128550810
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/12897884
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/130515
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/131381623
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/132375810
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/133223411
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/135334612
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/136636312
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/136934719
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/137709524
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/13771638
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/13818469
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/138619712
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/139715712
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/14062
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/142312419
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1462
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/146346313
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/147010
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/147837612
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/147963219
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/148137526
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/149264912
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/149638415
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/152073012
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/152381128
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/152512339
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/154816630
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/157424622
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/15834206
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/16037348
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/160378512
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/16050454
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1612
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/16119794
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/161338
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/161582333
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/161830125
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/16367706
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/165338460
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/16548267
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/165570211
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/166810323
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/167167723
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/167424
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/167405636
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1680991100
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/16855264
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/168698030
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/169480812
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/17152038
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/171933914
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/172127527
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/172288418
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1742
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/174717
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/17487564
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/177216523
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/177310
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/17782
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/178548511
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/179681621
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/179703310
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18000888
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18088248
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/180929113
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1812
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/181000016
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18119164
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/181839817
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/182452819
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/182470424
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/182545226
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/183847519
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/184510
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/185487833
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/185726916
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18590819
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/185937821
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/185938440
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/186145815
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/186352622
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18636014
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187126710
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18733356
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187333712
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187490412
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187510
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18761878
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187813446
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187864552
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/187891540
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/188006670
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/188373921
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/188401716
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/189182912
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/189260427
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/18953638
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/189560212
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/189953910
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190015559
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/19003526
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190198120
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190211244
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190446418
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190618014
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190660818
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/190924730
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191121632
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191334124
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191366836
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191366934
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191435351
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191744277
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/191832184
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/192617416
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/1952
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/198014
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/20212
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/2052
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/20558
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/207317
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/2132
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/213910
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/215810
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/21602
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/216741
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/2202
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/224310
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/229336
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/230740
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/234710
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/234913
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/2422
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/26602
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/27744
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/278814
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/288815
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/2922
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/292314
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/292637
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/2942
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/3162
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/3382
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/3492
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/3572
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/4312
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/44167213
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/4452
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/4462
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/4952
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5002
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5012
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/52199471
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5322
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5336135
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5442
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5512
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/55858
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/5692
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/61229714
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/61727
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/64619
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/65700645
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/65815216
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/6672
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/6866136
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/6872
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/68805229
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/692
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/69609439
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/7042
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/71792924
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/722
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/73215595
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/75765416
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/792
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/8272
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/8734609
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/89403716
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/90686416
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/932
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/95985230
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/9852884
-rw-r--r--results/classifier/deepseek-2-tmp/output/peripherals/98950424
204 files changed, 3562 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/102 b/results/classifier/deepseek-2-tmp/output/peripherals/102
new file mode 100644
index 000000000..92fa86c86
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/102
@@ -0,0 +1,2 @@
+
+Mouse stops working when connected usb-storage-device
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1020309 b/results/classifier/deepseek-2-tmp/output/peripherals/1020309
new file mode 100644
index 000000000..bdf229ffd
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1042654 b/results/classifier/deepseek-2-tmp/output/peripherals/1042654
new file mode 100644
index 000000000..1a91b2efc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/106 b/results/classifier/deepseek-2-tmp/output/peripherals/106
new file mode 100644
index 000000000..d0be29049
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/106
@@ -0,0 +1,2 @@
+
+qemu-git gravis ultrasound not working
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1080086 b/results/classifier/deepseek-2-tmp/output/peripherals/1080086
new file mode 100644
index 000000000..6a8ab7831
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1080086
@@ -0,0 +1,25 @@
+
+MC146818 RTC breaks when SET bit in Register B is on.
+
+This bug occurs when the SET flag of Register B is enabled. When an RTC
+data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set,
+the data is (as expected) correctly stored in the cmos_data array. However,
+since the SET flag is enabled, the function rtc_set_time is not invoked.
+As a result, the field base_rtc in RTCState remains uninitialized. This appears to
+cause a problem on subsequent writes which can end up overwriting data.
+
+To see this, consider writing data to Register A after having written
+data to any of the RTC data registers; the following figure illustrates
+the call stack for the Register A write operation:
+
+ +- cmos_io_port_write
+ +-- check_update_timer
+ +---- get_next_alarm
+ +------ rtc_update_time
+
+In rtc_update_time, get_guest_rtc calculates the wrong time and
+overwrites the previously written RTC data register values.
+
+I have created a standalone test case which exposes this bug:
+
+   https://github.com/ahorn/benchmarks/commit/fff1ca40694bbef6f7f9de323bb0bed63419ef99
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1086745 b/results/classifier/deepseek-2-tmp/output/peripherals/1086745
new file mode 100644
index 000000000..57b41177d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1090602 b/results/classifier/deepseek-2-tmp/output/peripherals/1090602
new file mode 100644
index 000000000..ada18d388
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1090602
@@ -0,0 +1,12 @@
+
+RFE: Allow specifying usb-host device by serial number
+
+Currently you can pass through a host USB device to the guest like
+
+  -device usb-host,vendorid=0x1234,productid=0x5678
+
+Which is all well and good, but has problems if you are trying to assign to identical USB devices to the same guest.
+
+It would be useful if there was an additional option that allow matching against the device's serial number, which should allow differentiating between two devices with the same product+vendor.
+
+This was originally filed at https://bugzilla.redhat.com/show_bug.cgi?id=640332
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1094564 b/results/classifier/deepseek-2-tmp/output/peripherals/1094564
new file mode 100644
index 000000000..f4b4ea39c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1094564
@@ -0,0 +1,20 @@
+
+images used as scsi disks not readable (qemu-system-arm, macos 10.8)
+
+Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my disk, I get as far as mounting root and then get SCSI errors with 1.3.0 and the current origin/master. git bisect says the issue is
+
+commit f563a5d7a820424756f358e747238f03e866838a
+Merge: a273652 aee0bf7
+Author: Paolo Bonzini <email address hidden>
+Date:   Wed Oct 31 10:42:51 2012 +0100
+
+    Merge remote-tracking branch 'origin/master' into threadpool
+    
+    Signed-off-by: Paolo Bonzini <email address hidden>
+
+
+I am using:
+qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22
+
+Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus:
+CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang"  ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1149 b/results/classifier/deepseek-2-tmp/output/peripherals/1149
new file mode 100644
index 000000000..3d36243d4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1149
@@ -0,0 +1,10 @@
+
+Micron Xccela (MT35x) NOR Flash wrong implementation in `hw/block/m25p80.c`
+Additional information:
+I see that in the fork they introduced a new entry - `MAN_MICRON_OCTAL`: - https://github.com/Xilinx/qemu/blob/master/hw/block/m25p80.c
+
+Would be nice to make it more generic, probably to call just `MAN_MICRON` and set octal mode like quad mode in other flash implementations - via the configuration register flags, especially since they could be enabled and disabled on the fly.
+
+Also the 256 configuration registers: https://github.com/Xilinx/qemu/commit/9b2fe1e36bfd8849bb3538161279cdff6efea325
+
+cc @alistair23
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1210212 b/results/classifier/deepseek-2-tmp/output/peripherals/1210212
new file mode 100644
index 000000000..c7873d41a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1210212
@@ -0,0 +1,13 @@
+
+qemu core dumps with -serial mon:vc
+
+qemu 1.5.2-1 dumps core when asked to put the monitor on a virtual console.  For example, suppose you want to monitor the second serial port, you might try something like:
+
+qemu-system-x86_64 -serial null -serial mon:vc
+
+But that creates a core dump.  In fact, even re-creating what should be the default dumps core:
+
+$ qemu-system-x86_64 -serial mon:vc:80Cx25C
+Segmentation fault (core dumped)
+
+I'm not including a backtrace because the bug is so easy to reproduce, but I can provide more info if necessary.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1232 b/results/classifier/deepseek-2-tmp/output/peripherals/1232
new file mode 100644
index 000000000..887b2b5c4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1241569 b/results/classifier/deepseek-2-tmp/output/peripherals/1241569
new file mode 100644
index 000000000..920acf0ec
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1243 b/results/classifier/deepseek-2-tmp/output/peripherals/1243
new file mode 100644
index 000000000..4b2710310
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1243
@@ -0,0 +1,2 @@
+
+Floating-point-exception in ide_set_sector
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1247478 b/results/classifier/deepseek-2-tmp/output/peripherals/1247478
new file mode 100644
index 000000000..9ef07281d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1247478
@@ -0,0 +1,25 @@
+
+usb passthrough mass storage write data corruption
+
+the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb
+in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and
+except for the last packet for odd-sized files). The pattern is:
+3 times bulk out 20480
+1 time bulk out 4096
+
+and that repeats for files longer than 65536 bytes.
+
+the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each
+20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and
+57344-61440.
+and so on. and because the 4096 sized  bulk out is always error free, the next corrupt span is from
+81920-86016.
+
+the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same
+transfer.
+
+to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file.
+(possibly check the bulk transfer sizes with usbmon).
+note that attaching usb disks with hw/usb/dev-storage does work just fine.
+cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are
+always ok even with usb passthrough.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1252270 b/results/classifier/deepseek-2-tmp/output/peripherals/1252270
new file mode 100644
index 000000000..422e5624b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1252270
@@ -0,0 +1,16 @@
+
+installing NT4 on MIPS Magnum/Jazz asserts
+
+While installing NT4 on MIPS Magnum (Jazz), when the NT Installer tries to format the harddisk, QEmu 1.6.1 crashes with an assertion:
+
+qemu-system-mips64el: g364: invalid read at [0000000000102000]
+qemu-system-mips64el: hw/scsi/scsi-bus.c:1577: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed.
+./nt4mips.sh: line 3: 20336 Aborted                 (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384
+
+This assertion also occurred with the stock Ubuntu version of QEmu (1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)) which I tried before.
+
+Note that to even get this far, you need the patch mentioned in BUG1245924, otherwise QEmu 1.6.1 won't even start/boot at all
+
+NT4 installation guide I'm following:
+http://gunkies.org/wiki/Installing_Windows_NT_4.0_on_Qemu(MIPS)
+http://virtuallyfun.superglobalmegacorp.com/?p=2255
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1254 b/results/classifier/deepseek-2-tmp/output/peripherals/1254
new file mode 100644
index 000000000..0722c8b3a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1254
@@ -0,0 +1,56 @@
+
+hw: misc: edu: two off-by-one errors
+Description of problem:
+In `hw/misc/edu.c`, `edu_check_range()` fails for boundary conditions where `size2 == 0` and `size2 == size1`.
+Steps to reproduce:
+Two ways to reproduce (attached test program, [foo.c](/uploads/9cbef4f72d175b8336b58f607e262d7b/foo.c))
+
+error:
+1. `gcc -o foo foo.c`
+2. `./foo`
+
+fix:
+1. `gcc -DFIXED -o foo foo.c`
+2. `./foo`
+
+Using `qtest`: (see "QEMU command line" above).
+Additional information:
+(output of `foo` without fix):
+```
+EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000000000-0xffffffffffffffff)!
+EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000000000-0x0000000000000fff)!
+```
+
+Output of `qtest` without the fix:
+```
+qemu: hardware error: EDU: DMA range 0x0000000000000000-0x0000000000000fff out of bounds (0x0000000000040000-0x0000000000040fff)!
+CPU #0:
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000663
+ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
+EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
+DR6=ffff0ff0 DR7=00000400
+EFER=0000000000000000
+FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
+FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
+FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
+FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
+FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
+XMM00=0000000000000000 0000000000000000 XMM01=0000000000000000 0000000000000000
+XMM02=0000000000000000 0000000000000000 XMM03=0000000000000000 0000000000000000
+XMM04=0000000000000000 0000000000000000 XMM05=0000000000000000 0000000000000000
+XMM06=0000000000000000 0000000000000000 XMM07=0000000000000000 0000000000000000
+```
+
+Patch has been submitted to `qemu-devel`
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1255303 b/results/classifier/deepseek-2-tmp/output/peripherals/1255303
new file mode 100644
index 000000000..35304b7c0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1272796 b/results/classifier/deepseek-2-tmp/output/peripherals/1272796
new file mode 100644
index 000000000..4546ef38a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1272796
@@ -0,0 +1,20 @@
+
+Windows 98 First Edition emulation problems
+
+System: Debian SID x86 with latest updates
+
+1) QEMU compiled from latest main GIT branch (and 1.7 stable version)
+./configure options: ./configure --enable-sdl --target-list=i386-softmmu --cpu=i686 --audio-drv-list=alsa
+
+When you try to boot Windows 98 First Edition (Italian), it does not simply boot. It stays on booting screen. 
+If you try to install, the installation goes flawless, but when it boots it freeze.
+
+I am launching VM with this: qemu-system-i386 -hda main.img -cpu pentium -m 256 -fda floppy1.img -boot c -soundhw gus -vga cirrus
+
+I have tried with -M option "pc-i440fx-1.6" since 1.6 have no problems with the booting of Win98, but nothing. No fix found.
+
+2) QEMU 1.6.2 (same compile and launching options)
+gus soundboard seems not recognized even with real dos drivers (tried to install theme into real dos mode).
+with SoundBlaster 16 i have following error: WARNING: I/O thread spun for 1000 iterations, making the emulation impossible (too slow, and sound is stuttering) . Tried to compile with oss and sdl option on audio-drv-list but no fix found.
+
+Any ideas? thank you
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1282 b/results/classifier/deepseek-2-tmp/output/peripherals/1282
new file mode 100644
index 000000000..621cc549e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1282
@@ -0,0 +1,4 @@
+
+sdhci: DMA reentrancy issue leads to an infinite loop
+Description of problem:
+When sdhci transfers multiple blocks, it doesnot check if the dma-write buffer pointer overlaps with its MMIO region, crafted content can cause DoS because of infinite loop and CPU consumption.
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1285508 b/results/classifier/deepseek-2-tmp/output/peripherals/1285508
new file mode 100644
index 000000000..774ba2dec
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1289788 b/results/classifier/deepseek-2-tmp/output/peripherals/1289788
new file mode 100644
index 000000000..f71eb8516
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1305 b/results/classifier/deepseek-2-tmp/output/peripherals/1305
new file mode 100644
index 000000000..a25b3daf5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1313816 b/results/classifier/deepseek-2-tmp/output/peripherals/1313816
new file mode 100644
index 000000000..3bab53a6f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1323758 b/results/classifier/deepseek-2-tmp/output/peripherals/1323758
new file mode 100644
index 000000000..a8c834309
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1332234 b/results/classifier/deepseek-2-tmp/output/peripherals/1332234
new file mode 100644
index 000000000..2ceda31bc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1332234
@@ -0,0 +1,11 @@
+
+qemu-system-ppc no longer able to read real cdrom
+
+When I use to send the -cdrom /dev/cdrom option to QEMU, I would be able to use a real cdrom. With QEMU v2.0.0, real cdroms don't work. A quick look at the output from the "info block" command shows this:
+
+ide1-cd0: /dev/cdrom (raw, read-only)
+      Removable device: not locked, tray closed
+
+This indicates that the cdrom is set to /dev/cdrom. I remember versions of QEMU prior to 1.5 were able to use a real cdrom. 
+
+qemu-system-ppc is being run on Mac OS 10.6.8.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1353346 b/results/classifier/deepseek-2-tmp/output/peripherals/1353346
new file mode 100644
index 000000000..7f575a2d5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1366363 b/results/classifier/deepseek-2-tmp/output/peripherals/1366363
new file mode 100644
index 000000000..3e0e36d6e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1369347 b/results/classifier/deepseek-2-tmp/output/peripherals/1369347
new file mode 100644
index 000000000..a856d51c1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1369347
@@ -0,0 +1,19 @@
+
+Mac OS X cannot passthrough USB device to guest
+
+I'm using Mac OS 10.9.4 with qemu-system-arm installed from brew (version 1.7.1) and verified with qemu-system-x86_64. I'm trying to pass a Ralink 5370 WiFi USB dongle to my guest system, it appears in my system profiler as:
+
+802.11 n WLAN:
+
+  Product ID:	0x5370
+  Vendor ID:	0x148f
+  Version:	 1.01
+  Serial Number:	1.0
+  Speed:	Up to 480 Mb/sec
+  Manufacturer:	Ralink
+  Location ID:	0x1d110000 / 6
+  Current Available (mA):	500
+  Current Required (mA):	450
+
+Using the docs, I'm passing "-usb -device usb-host,vendorid=0x148f,productid=0x5370" and getting this error back:
+"qemu-system-arm: -device usb-host,vendorid=0x148f,productid=0x5370: Parameter 'driver' expects device type"
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1377095 b/results/classifier/deepseek-2-tmp/output/peripherals/1377095
new file mode 100644
index 000000000..3b75e4b37
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1377163 b/results/classifier/deepseek-2-tmp/output/peripherals/1377163
new file mode 100644
index 000000000..134f783be
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1377163
@@ -0,0 +1,8 @@
+
+Does not add usb-host devices as they are hotplugged
+
+A commandline such as
+
+qemu-kvm -device usb-ehci,id=USBCtrl -device host-usb,bus=USBCtrl.0,hostbus=3
+
+should automatically add all devices on the given bus (here: 3) not only initially, but also when new devices appear on that bus while Qemu runs. Currently, all devices on the bus are added initially, but new devices which are added to the (host) usb while Qemu runs have to be added manually.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1381846 b/results/classifier/deepseek-2-tmp/output/peripherals/1381846
new file mode 100644
index 000000000..ff57996b8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1386197 b/results/classifier/deepseek-2-tmp/output/peripherals/1386197
new file mode 100644
index 000000000..3e4d90bd0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1397157 b/results/classifier/deepseek-2-tmp/output/peripherals/1397157
new file mode 100644
index 000000000..2cd355a19
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1397157
@@ -0,0 +1,12 @@
+
+cpu high with ps2 keyboard on multi-core win7 guest os
+
+
+qemu ver: 1.5.3-Latest 
+
+guest os: window 7 64bit with 2 cpu and ps2 keybord.
+
+problem: Use virt-viwer as client to connect, When input quickly, the guest and host cpu will high and the input-char will display later.  but when only 1 cpu on the vm, the problem will not display or When qemu ver is 0.12.1, the problem will not display.
+
+qemu cmd:
+/usr/libexec/qemu-kvm -name xx_win7 -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu qemu64,+sse4.2,+sse4.1,+ssse3,-svm,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid 0860a434-6560-591b-f92f-c13c5caaf52d -rtc base=localtime -no-shutdown -boot strict=on -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 ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/lfs/xx_win7/xx_win7.vda,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=2 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -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 -spice port=5900,addr=::,disable-ticketing,plaintext-channel=main,plaintext-channel=display,plaintext-channel=inputs,plaintext-channel=cursor,plaintext-channel=playback,plaintext-channel=record,plaintext-channel=usbredir,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,playback-compression=on,disable-copy-paste,seamless-migration=on -vga qxl -global qxl-vga.ram_size=268435456 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1406 b/results/classifier/deepseek-2-tmp/output/peripherals/1406
new file mode 100644
index 000000000..a8b9cfd58
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1406
@@ -0,0 +1,2 @@
+
+WANTED: Schematics, Service, Tech Notes, .pdf  IBM Power4 970MP/FX Apple PowerMac G5 Early/Late 2005
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1423124 b/results/classifier/deepseek-2-tmp/output/peripherals/1423124
new file mode 100644
index 000000000..fc787b1f7
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/146 b/results/classifier/deepseek-2-tmp/output/peripherals/146
new file mode 100644
index 000000000..822fd275d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/146
@@ -0,0 +1,2 @@
+
+macOS Guest Reading USB 3.0 Bus as USB 2.0
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1463463 b/results/classifier/deepseek-2-tmp/output/peripherals/1463463
new file mode 100644
index 000000000..9b7536fd3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1463463
@@ -0,0 +1,13 @@
+
+PCI devices on PCI to PCI bridges stopped being accessable from Xen with QEMU 2.3.0
+
+The change set:
+
+commit 3996e85c1822e05c50250f8d2d1e57b6bea1229d
+Author: Paul Durrant <email address hidden>
+Date:   Tue Jan 20 11:06:19 2015 +0000
+
+    Xen: Use the ioreq-server API when available
+...
+
+Added calls to xen_map_pcidev()  when available.  However these call are only done at startup, not when the guest configures the PCI to PCI bridge.  So Xen 4.5.0 (which has these) using a QEMU 2.3.0 or later can no longer access PCI devices that are not on a root bridge.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1470 b/results/classifier/deepseek-2-tmp/output/peripherals/1470
new file mode 100644
index 000000000..1fd8c6c87
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1470
@@ -0,0 +1,10 @@
+
+Mouse cursor disappeared for WfW 3.11
+Description of problem:
+I've been using the "GD5434 v1.25f, 1280x1024x64K Smlfnt" driver (from sp2904.exe, https://archive.org/download/Windows-3.1-WING-doom inside cirrus.zip) with Fedora's qemu build for years, which is the best version of that driver that I could find, and which works quite nicely apart from a font problem right after startup, and is a lot faster than the standard (patched) SVGA driver. Opening and closing File Manager will get rid of the font corruption. After an upgrade to Fedora 37, I noticed that the mouse cursor was not displayed anymore, which I bisected to this git commit: cb8962c146
+Steps to reproduce:
+1. Run the image (boots right into Windows)
+2. Note the missing cursor
+3.
+Additional information:
+Image for easy testing (IBM DOS 5, 1024x768) is here: https://drive.google.com/file/d/1_5-gGXEahPOPvgG436WbKM9dnOr7Z8zo/view?usp=sharing (4.4 MB)
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1478376 b/results/classifier/deepseek-2-tmp/output/peripherals/1478376
new file mode 100644
index 000000000..f4ac41cc3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1479632 b/results/classifier/deepseek-2-tmp/output/peripherals/1479632
new file mode 100644
index 000000000..73bda8c02
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1481375 b/results/classifier/deepseek-2-tmp/output/peripherals/1481375
new file mode 100644
index 000000000..507917add
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1492649 b/results/classifier/deepseek-2-tmp/output/peripherals/1492649
new file mode 100644
index 000000000..7dd45a4e4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1496384 b/results/classifier/deepseek-2-tmp/output/peripherals/1496384
new file mode 100644
index 000000000..b41604931
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1520730 b/results/classifier/deepseek-2-tmp/output/peripherals/1520730
new file mode 100644
index 000000000..6bde01653
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1523811 b/results/classifier/deepseek-2-tmp/output/peripherals/1523811
new file mode 100644
index 000000000..20366aaa5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1523811
@@ -0,0 +1,28 @@
+
+USB assert failure on dev-storage.c
+
+On executing the attached python script in the guest OS, QEMU dies with assert failure:
+
+[run python script in guest root shell]
+# python a.py
+
+[host message]
+qemu-system-x86_64: hw/usb/dev-storage.c:445: usb_msd_handle_data: Assertion `le32_to_cpu(s->csw.residue) == 0' failed.
+Aborted (core dumped)
+
+
+When I detach the kernel driver and send CBW and reattach it again, without conforming to the command/data/status protocol, QEMU dies.
+I think this is due to misimplementation of Command/Data/Status protocol in Bulk-only transfer.
+This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines.
+Before running python script, make sure to change a.py that it should points to usb mass storage's vid and pid.
+
+QEMU was running on these environment : 
+[CPU model]    Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
+[qemu version] QEMU 2.5.0-rc2 (compiled from source, gcc 4.8.4)
+[host info]    Ubuntu 14.04.3, x86_64, 3.19.0-32-generic
+[guest info]   Ubuntu 14.04.3, x86_64, 3.19.0-28-generic
+[QEMU argument]
+x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2.5 \
+	-m 512 \
+	--usbdevice disk:format=qcow2:../usb.img.5 \
+	--enable-kvm
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1525123 b/results/classifier/deepseek-2-tmp/output/peripherals/1525123
new file mode 100644
index 000000000..6126b8862
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1525123
@@ -0,0 +1,39 @@
+
+USB assert failure on hcd-uhci.c
+
+When inserting the attached kernel moudle in the guest OS, QEMU quits with therse assert failure:
+
+
+[insert kernel module in guest root shell]
+root@qemu:~# insmod mymod.ko
+root@qemu:~# 
+Connection closed by foreign host.
+
+[host message]
+qemu-system-x86_64: hw/usb/core.c:718: usb_ep_get: Assertion `pid == 0x69 || pid == 0xe1' failed.
+Aborted
+
+The cause of this bug is due to misimplementation of UHCI.
+According to Intel's UHCI design guide, packet identification in transfer descriptor should have one of these three value : IN (69h), OUT (E1h), and SETUP (2Dh). Any other value in this field shoudl cause HALT OF only HOST CONTROLLER.
+However, due to misimplementation in QEMU, not only host controller halts, but QEMU itself exits with assertion failure.
+This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines.
+
+[How to run exploit code]
+Prepare linux kernel's source header, then type these lines in root shell.
+# make
+# insmod mymod.ko
+
+It needs uhci-hcd.h from linux kernel source.
+I attached linux 3.18.24's uhci-hcd.h for tempory measure; You should get proper version of uhci-hcd.h.
+In the following envrionment, this exploit worked, exiting whole QEMU, not only USB.
+
+QEMU was running on these environment :
+[CPU model] Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
+[qemu version] QEMU 2.5.0-rc3 (compiled from source, gcc 4.8.4)
+[host info] Ubuntu 14.04.3, x86_64, 3.19.0-32-generic
+[guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic
+[QEMU argument]
+x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2 \
+ -m 512 \
+ --usbdevice disk:format=qcow2:../usb.img \
+ --enable-kvm
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1548166 b/results/classifier/deepseek-2-tmp/output/peripherals/1548166
new file mode 100644
index 000000000..af96caec9
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1548166
@@ -0,0 +1,30 @@
+
+QEMU crash after send data from Host through serial port 
+
+Hi All
+
+I have two computer, one is Win7 32 another is Win7 64, Both computer meet this issue.
+My QEMU version is qemu-w32-setup-20160215
+
+I want used EDK2 OVMF with Intel UDK Debugger tools to do source level debug
+I had install com0com Virtual Com Port, and set COM3 connect to COM4
+
+Intel UDK Debugger tools used COM3
+QEMU run OVMF used COM4
+
+First execute Intel UDK Debugger tools, then launch QEMU
+C:\Program Files\qemu\qemu-system-x86_64.exe -bios "C:\EDK2\Build\OvmfX64\DEBUG_VS2010\FV\OVMF.fd" -serial COM4
+Then QEMU crashes on stratup
+
+I have do some experiment
+Execute terminal tool Tera Term and used COM3
+launch QEMU and used COM4
+C:\Program Files\qemu\qemu-system-x86_64.exe -bios "C:\EDK2\Build\OvmfX64\DEBUG_VS2010\FV\OVMF.fd" -serial COM4
+This is fine and i can see OVMF trace log on terminal
+But if i press "Down" key on terminal, then QEMU crashe
+It's caused by terminal send data("Down" key) to QEMU
+
+Have somebody can share some information about this?
+
+Thanks a lot.
+Sugar
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1574246 b/results/classifier/deepseek-2-tmp/output/peripherals/1574246
new file mode 100644
index 000000000..6bfa4843b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1583420 b/results/classifier/deepseek-2-tmp/output/peripherals/1583420
new file mode 100644
index 000000000..fef6d9358
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1603734 b/results/classifier/deepseek-2-tmp/output/peripherals/1603734
new file mode 100644
index 000000000..3110cea8b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1603734
@@ -0,0 +1,8 @@
+
+Hang in fsqrt
+
+At least qemu-i368 and qemu-x86_64 hang in floatx80_sqrt in versions 2.6.0 and git (2.6.50) for some input values, likely due to an infinite loop at fpu/softfloat.c:6569.
+
+Steps to reproduce:
+1) Compile attached code: gcc -o test test.c -lm
+2) `qemu-i368 test` and `qemu-x86_64 test` will hang at 100% cpu
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1603785 b/results/classifier/deepseek-2-tmp/output/peripherals/1603785
new file mode 100644
index 000000000..67d60aea6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1603785
@@ -0,0 +1,12 @@
+
+trace_usb_port_attach prints junk data
+
+Running qemu with tracing (-D ~/qemu_trace -d trace:\*) will result in a trace file with unprintable characters.
+
+example: usb_port_attach bus 0, port 1, devspeed <90>l<DB>.<D8>U, portspeed full+high
+
+The problem is in hw/usb/bus.c usb_mask_to_str. If speedmask doesn't match any of the defined speed nothing is written to *dest and uninitialized data is printed to the log.
+
+This happens with a real usb device that is forwarded into the machine.
+
+My qemu version is 2.6.0 but it looks like the problem exists in latest git also.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1605045 b/results/classifier/deepseek-2-tmp/output/peripherals/1605045
new file mode 100644
index 000000000..dd1702698
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/161 b/results/classifier/deepseek-2-tmp/output/peripherals/161
new file mode 100644
index 000000000..4b32ad2f0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/161
@@ -0,0 +1,2 @@
+
+virtio-scsi gives improper discard sysfs entries
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1611979 b/results/classifier/deepseek-2-tmp/output/peripherals/1611979
new file mode 100644
index 000000000..d71d2e1b5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1611979
@@ -0,0 +1,4 @@
+
+GTK+ interface, backspace is broken in the monitor console
+
+this has been broken for over 2 years
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1613 b/results/classifier/deepseek-2-tmp/output/peripherals/1613
new file mode 100644
index 000000000..04ea9d8a4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1613
@@ -0,0 +1,38 @@
+
+Enhanced SuperSpeed Isochronous Endpoints with high-bandwidth pipes not working (Webcams and Microphones)
+Description of problem:
+I have encountered an issue with QEMU when forwarding HD webcams and microphones in SuperSpeed mode.
+
+When passing the USB webcam "Logitech BRIO Ultra HD Webcam" to the guest using USB HighSpeed mode, all pixel formats and video modes work as expected. However, when using SuperSpeed mode, only the MJPEG format operates at low resolutions. I have attached a [USB_Webcam_Testing_Truth_Table.pdf](/uploads/309d493989da1164198af0b315012fb1/USB_Webcam_Testing_Truth_Table.pdf) that displays the functioning modes.
+
+This issue arises with both qemu-xhci and nec-usb-xhci xHCI implementations, as well as with usb-host and usb-redir.
+
+Upon tracing and comparing the USB packets from the host and guest systems, I discovered an issue with the isochronous endpoint configurations supporting "high bandwidth" pipes (e.g., SS Companion Descriptor with bMaxBurst > 0). I created three pcap files to illustrate the problem:
+1. [host-libusb.pcapng](/uploads/18a66948dc6dc10ff68b7f55d70fa209/host-libusb.pcapng) 
+2. [qemu-guest.pcapng](/uploads/b616507f2f7c1c042a9d085dc3af579f/qemu-guest.pcapng)
+3. [host-native.pcapng](/uploads/279aa7f264a75a77203fa7bf6c5afc83/host-native.pcapng)
+
+To generate each capture, I executed the following command:
+```console
+timeout --preserve-status 3s ffplay -f v4l2 -i "/dev/video0" -input_format mjpeg -framerate 30 -video_size 1920x1060
+```
+
+The "SET INTERFACE" packet reveals that the USB video driver selects bAlternateSetting=7, which has the following parameters:
+```
+wMaxPacketSize: 1024
+bMaxBurst: 2
+bmAttributes: 0x01
+    .... ..01 = Mult: 1
+```
+According to Section 4.14.2.1.3 of the xHCI specification, the size of an isoch transfer should be `Packet Size * (Max Burst Size + 1) * (Mult + 1) = 6144`.
+
+However, the host-libusb.pcapng capture shows that each transfer is only 1024 bytes in size.
+
+For higher bitrate formats, it is observed that the system generates erroneous transfers in which the data offset in the isodescriptor exceeds the packet size.
+
+Currently, I am unsure of the cause of this issue. If you need any additional information, logs, or specific USB packet captures, I would be more than happy to provide them.
+
+Thanks
+Additional information:
+[lsusb-cam-SuperSpeed.txt](/uploads/712ac9e67d0b53ce46573bee3df883d0/lsusb-cam-SuperSpeed.txt)
+[lsusb-cam-HighSpeed.txt](/uploads/70f855e471714fb1b48a7ed7912c0be4/lsusb-cam-HighSpeed.txt)
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1615823 b/results/classifier/deepseek-2-tmp/output/peripherals/1615823
new file mode 100644
index 000000000..63ef90b5c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1615823
@@ -0,0 +1,33 @@
+
+Windows 10 reports no compatible TPM found yet device manager shows it?
+
+Ubuntu 16.04 with stock kvm, libvirt, ovmf
+Qemu 2.5 installed from stock ubuntu ppa
+Qemu 2.6.1 built from tarball.
+Qemu 2.7.0-rc4 built from tarball.
+
+Windows 10 guest reports a TPM device is installed and the driver functional under Device Manager-->Security Devices.  TPM Administrator however advises no compatible TPM chip can be found.
+
+Qemu 2.5 is buggy and prevents the guest loading the TPM driver, this was addressed by http://git.qemu.org/?p=qemu.git;a=commit;h=2b1c2e8e5f1990f0a201a8cbf9d366fca60f4aa8
+
+Have tested the below cmd out on both qemu-2.6.1 and qemu-2.7.0-rc4, both suffer the same problem.  My TPM is most certainly compatible as installing Win10Pro onto the same host as bare metal provides me the desired and expected functionality aka Bitlocker and TPM Administrator work.
+
+sudo ./qemu-system-x86_64 \
+-enable-kvm \
+-machine q35 \
+-cpu host \
+-m 4096 \
+-smp 4,sockets=1,cores=2,threads=2 \
+-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
+-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \
+-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x2 \
+-drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on \
+-drive file=/mnt/120GB_SSD/wintpm_VARS.fd,if=pflash,format=raw,unit=1 \
+-drive file=/mnt/120GB_SSD/wintpm.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \
+-drive file="/mnt/share/Filestorage/Images/Microsoft Windows 10 Pro x64.iso",format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on \
+-device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 \
+-drive file=/mnt/share/Filestorage/Images/virtio-win-0.1.117.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-1,readonly=on \
+-device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 \
+-tpmdev passthrough,id=tpm-tpm0,path=/dev/tpm0,cancel-path=/sys/class/tpm/tpm0/device/cancel \
+-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1618301 b/results/classifier/deepseek-2-tmp/output/peripherals/1618301
new file mode 100644
index 000000000..13b3d0ef5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1636770 b/results/classifier/deepseek-2-tmp/output/peripherals/1636770
new file mode 100644
index 000000000..80e18a87a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1653384 b/results/classifier/deepseek-2-tmp/output/peripherals/1653384
new file mode 100644
index 000000000..83d43f639
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1653384
@@ -0,0 +1,60 @@
+
+Assertion failed with USB pass through with XHCI controller
+
+Starting qemu 2.8.0 with XHCI controller and host device passed through results in an assertion failure:
+
+qemu-system-x86_64: hw/usb/core.c:623: usb_packet_cleanup: Assertion `!usb_packet_is_inflight(p)' failed.
+
+Can be reproduced with the following command (passing through a Lenovo keyboard):
+
+qemu-system-x86_64 -usb  -device nec-usb-xhci,id=usb -device usb-host,vendorid=0x04b3,productid=0x3025,id=hostdev0,bus=usb.0,port=1
+
+If nec-usb-xhci is changed to usb-ehci, qemu tries to boot without assertion failures. 
+
+
+Can be reproduced with the latest master (commit dbe2b65) and v2.8.0.
+
+Bisected the issue to following commit:
+first bad commit: [94b037f2a451b3dc855f9f2c346e5049a361bd55] xhci: use linked list for transfers
+
+
+Backtrace from commit dbe2b65:
+
+#0  0x00007f2eb4657227 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
+        resultvar = 0
+        pid = 3453
+        selftid = 3453
+#1  0x00007f2eb465867a in __GI_abort () at abort.c:89
+        save_stage = 2
+        act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, sa_mask = {__val = {140734740550528, 93876690035339, 
+              140734740550624, 48833659808, 0, 0, 0, 21474836480, 140734740550792, 139838573009553, 140734740550560, 139838573043008, 
+              139838573024160, 93876666665872, 139838702616576, 139838573024160}}, sa_flags = 1528954938, 
+          sa_restorer = 0x55615b2202c0 <__PRETTY_FUNCTION__.38612>}
+        sigs = {__val = {32, 0 <repeats 15 times>}}
+#2  0x00007f2eb46502cd in __assert_fail_base (fmt=0x7f2eb47893a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
+    assertion=assertion@entry=0x55615b22003a "!usb_packet_is_inflight(p)", file=file@entry=0x55615b21fdf0 "hw/usb/core.c", line=line@entry=619, 
+    function=function@entry=0x55615b2202c0 <__PRETTY_FUNCTION__.38612> "usb_packet_cleanup") at assert.c:92
+        str = 0x55615cfdf510 ""
+        total = 4096
+#3  0x00007f2eb4650382 in __GI___assert_fail (assertion=0x55615b22003a "!usb_packet_is_inflight(p)", file=0x55615b21fdf0 "hw/usb/core.c", 
+    line=619, function=0x55615b2202c0 <__PRETTY_FUNCTION__.38612> "usb_packet_cleanup") at assert.c:101
+No locals.
+#4  0x000055615afc385e in usb_packet_cleanup ()
+No symbol table info available.
+#5  0x000055615afda555 in xhci_ep_free_xfer ()
+No symbol table info available.
+#6  0x000055615afdc156 in xhci_kick_epctx ()
+No symbol table info available.
+#7  0x000055615afda099 in xhci_ep_kick_timer ()
+No symbol table info available.
+#8  0x000055615b08ceee in timerlist_run_timers ()
+No symbol table info available.
+#9  0x000055615b08cf36 in qemu_clock_run_timers ()
+No symbol table info available.
+#10 0x000055615b08d2df in qemu_clock_run_all_timers ()
+No symbol table info available.
+#11 0x000055615b08be40 in main_loop_wait ()
+No symbol table info available.
+#12 0x000055615ae3870f in main_loop ()
+No symbol table info available.
+#13 0x000055615ae4027b in main ()
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1654826 b/results/classifier/deepseek-2-tmp/output/peripherals/1654826
new file mode 100644
index 000000000..d297556d5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1655702 b/results/classifier/deepseek-2-tmp/output/peripherals/1655702
new file mode 100644
index 000000000..0793520af
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1668103 b/results/classifier/deepseek-2-tmp/output/peripherals/1668103
new file mode 100644
index 000000000..8211fd1ec
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1671677 b/results/classifier/deepseek-2-tmp/output/peripherals/1671677
new file mode 100644
index 000000000..0144f6903
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1671677
@@ -0,0 +1,23 @@
+
+vfio-pci passthrough issue after resume from suspend
+
+
+I'm running into a weird issue with the vfio-pci driver through qemu
+
+I use it on a laptop and I passthrough an external GPU connected via PCI express. In general this works well, however if the laptop has *ever* suspended since its last boot, then the windows guest reports an error 43 on the card and I get no output on the monitor that it is connected to. This is really weird to me since it works fine if I boot the latop from power-off, and hotplug the card. It's only if the laptop has ever suspended since it's last boot that I see this issue. Even if it was suspended before the card was ever hotplugged. 
+
+In other words:
+laptop off -> boot -> hotplug GPU : works great
+laptop off -> boot -> do stuff (GPU *NOT* connected) -> sleep -> resume -> hotplug GPU: problem
+laptop off -> boot -> hotplug GPU -> unplug GPU -> hotplug GPU : works great
+laptop off -> boot -> hotplug GPU -> unplug GPU -> sleep -> resume -> hotplug GPU: problem
+
+Weird stuff...
+
+I'm honestly not sure that vfio-pci/qemu is to blame here since there are so many moving parts, but im not really sure where else to report this to
+
+What I have tried is using the sysfs interface to remove/rescan/poweroff/etc the PCI devices in questions (graphics card and it's HDMI audio) and this also does help.
+
+QEMU version: 2.6.1
+
+Please let me know what other information I can provide
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1674 b/results/classifier/deepseek-2-tmp/output/peripherals/1674
new file mode 100644
index 000000000..dfe528005
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1674
@@ -0,0 +1,24 @@
+
+Arrow key not functional in QEMU monitor when using nographic on Windows 11 host
+Description of problem:
+The arrow keys do not work on the Windows QEMU when using -nographic option. On the Linux QEMU they work.
+Steps to reproduce:
+1. Download the qemu source code from https://download.qemu.org/qemu-8.0.0.tar.xz. THe sha256sum of the file is bb60f0341531181d6cc3969dd19a013d0427a87f918193970d9adb91131e56d0.
+2. Prepare the build system on MSYS2 according to the instructions on https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2.
+3. Uncompress the source code using `tar -xf qemu-8.0.0.tar.xz`.
+4. Change the working directory to qemu-8.0.0/. The build configuration command is `./configure --target-list=arm-softmmu --extra-cflags="-g -ggdb"`
+5. Run the command `./qemu-system-arm -s -S -M virt -nographic`.
+6. Press Ctrl-C A to switch to QEMU monitor.
+7. Input "help" command to the monitor.
+8. Press Arrow-Up key.
+9. The previous "help" command does not appear in the monitor prompt.
+Additional information:
+1. The pre-built binary downloaded from https://qemu.weilnetz.de/w64/qemu-w64-setup-20230424.exe has the same behaviour.
+2. The QEMU from MSYS2, `pacman -S mingw-w64-x86_64-qemu`, has the same behaviour.
+3. If the "-nographic" option is removed, the arrow-up key works in the GTK console.
+4. Neither of arrow-up, arrow-down, arrow-right, arrow-left key work.
+5. If the valid kernel and rootfs are added in the command line by "-kernel" and "-initrd" options, neither key work after booting to the Linux successfully.
+6. If the code `dwMode |= ENABLE_LINE_INPUT;` in the function `qemu_chr_open_stdio()` is changed to `dwMode |= ENABLE_LINE_INPUT|ENABLE_VIRTUAL_TERMINAL_INPUT;`, build again. All arrow keys work.
+7. The VT sequence support was added in `EmulatorPkg/Win/Host/WinThunk.c` by this commit https://gitlab.com/qemu-project/edk2/-/commit/5601e90d5cdbc4cea748e00e34ae07ce39bd700f.
+8. The above commit is to add VT sequence support at compile-time. Microsoft provides some code to enable it at run-time on https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example-of-enabling-virtual-terminal-processing.
+9. The function readline_handle_byte() is not called when the VT sequence is not enabled.
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1674056 b/results/classifier/deepseek-2-tmp/output/peripherals/1674056
new file mode 100644
index 000000000..96ffe5c8f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1680991 b/results/classifier/deepseek-2-tmp/output/peripherals/1680991
new file mode 100644
index 000000000..c81bd0671
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1685526 b/results/classifier/deepseek-2-tmp/output/peripherals/1685526
new file mode 100644
index 000000000..c7db2cb0f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1685526
@@ -0,0 +1,4 @@
+
+UEFI firmware can't write to "fake" FAT hard disk
+
+Using the Tianocore OVMF UEFI firmware, a UEFI application cannot write to the emulated fat disk (-hda fat:rw:path/here). A file will get created or written, but will be corrupted.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1686980 b/results/classifier/deepseek-2-tmp/output/peripherals/1686980
new file mode 100644
index 000000000..eb69fc5ec
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1686980
@@ -0,0 +1,30 @@
+
+qemu is very slow when adding 16,384 virtio-scsi drives
+
+qemu runs very slowly when adding many virtio-scsi drives.  I have attached a small reproducer shell script which demonstrates this.
+
+Using perf shows the following stack trace taking all the time:
+
+    72.42%    71.15%  qemu-system-x86  qemu-system-x86_64       [.] drive_get
+            |          
+             --72.32%--drive_get
+                       |          
+                        --1.24%--__irqentry_text_start
+                                  |          
+                                   --1.22%--smp_apic_timer_interrupt
+                                             |          
+                                              --1.00%--local_apic_timer_interrupt
+                                                        |          
+                                                         --1.00%--hrtimer_interrupt
+                                                                   |          
+                                                                    --0.83%--__hrtimer_run_queues
+                                                                              |          
+                                                                               --0.64%--tick_sched_timer
+
+    21.70%    21.34%  qemu-system-x86  qemu-system-x86_64       [.] blk_legacy_dinfo
+            |
+            ---blk_legacy_dinfo
+
+     3.65%     3.59%  qemu-system-x86  qemu-system-x86_64       [.] blk_next
+            |
+            ---blk_next
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1694808 b/results/classifier/deepseek-2-tmp/output/peripherals/1694808
new file mode 100644
index 000000000..4686906ba
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1715203 b/results/classifier/deepseek-2-tmp/output/peripherals/1715203
new file mode 100644
index 000000000..afc0a971c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1715203
@@ -0,0 +1,8 @@
+
+Maintain Haiku support
+
+It was pointed out that the 2.10 release notes are pushing to drop Haiku support.  The qemu port is currently working as-is under Haiku.
+
+Was there a reason this was recommended? Is there anything Haiku can do to keep it from being dropped?
+
+We're working on a docker container to cross-compile rust-lang for Haiku, could this be of some use to qemu when complete?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1719339 b/results/classifier/deepseek-2-tmp/output/peripherals/1719339
new file mode 100644
index 000000000..a70ddfca5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1721275 b/results/classifier/deepseek-2-tmp/output/peripherals/1721275
new file mode 100644
index 000000000..8d3f5d692
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1721275
@@ -0,0 +1,27 @@
+
+Support more ARM CPUs
+
+Hi,
+
+This is an enhancement request, rather than a bug report.
+
+After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters.
+
+I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for.
+
+I'd like to have:
+cortex-m0
+cortex-m4
+cortex-m7
+cortex-m23
+cortex-m33
+
+cortex-a35
+cortex-a53
+cortex-a57
+
+Is it possible?
+Is it the right place to ask?
+Should I file separate requests for each?
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1722884 b/results/classifier/deepseek-2-tmp/output/peripherals/1722884
new file mode 100644
index 000000000..15c1db05f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/174 b/results/classifier/deepseek-2-tmp/output/peripherals/174
new file mode 100644
index 000000000..febb79096
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/174
@@ -0,0 +1,2 @@
+
+European keyboard PC-105 deadkey
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1747 b/results/classifier/deepseek-2-tmp/output/peripherals/1747
new file mode 100644
index 000000000..4547c23f8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1747
@@ -0,0 +1,17 @@
+
+eMMC support is missing as a storage type
+Additional information:
+There seems several attempts at this, but the most recent appears much more complete:
+* https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg00347.html
+
+
+
+Historical;
+"[PATCH v3 06/21] sd: emmc: Update CMD8 to send EXT_CSD register"
+https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg00118.html
+
+"[RFC PATCH 00/17] hw/sd: Rework models for eMMC support"
+https://lore.kernel.org/qemu-devel/8aa56da0-a54a-102a-fc85-2fa9f02c18d1@kaod.org/
+
+2011 eMMC original support
+https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02835.html
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1748756 b/results/classifier/deepseek-2-tmp/output/peripherals/1748756
new file mode 100644
index 000000000..343cd1d78
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1748756
@@ -0,0 +1,4 @@
+
+[Feature request] Support of TI AM1808 for Lego EV3
+
+It would be great if emulating TI AM1808 would be possible. It will be a big step towards Lego Mindstorms EV3 emulation.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1772165 b/results/classifier/deepseek-2-tmp/output/peripherals/1772165
new file mode 100644
index 000000000..06179c62c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1773 b/results/classifier/deepseek-2-tmp/output/peripherals/1773
new file mode 100644
index 000000000..fccbe2182
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1778 b/results/classifier/deepseek-2-tmp/output/peripherals/1778
new file mode 100644
index 000000000..c7ae0319b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1778
@@ -0,0 +1,2 @@
+
+Spice audio play at wrong speed and frequency after qemu-7.2.0
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1785485 b/results/classifier/deepseek-2-tmp/output/peripherals/1785485
new file mode 100644
index 000000000..4b8bd08f6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1796816 b/results/classifier/deepseek-2-tmp/output/peripherals/1796816
new file mode 100644
index 000000000..cb3dd912d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1797033 b/results/classifier/deepseek-2-tmp/output/peripherals/1797033
new file mode 100644
index 000000000..5463cf347
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1800088 b/results/classifier/deepseek-2-tmp/output/peripherals/1800088
new file mode 100644
index 000000000..3535498c3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1800088
@@ -0,0 +1,8 @@
+
+Assertion fail while usb camera redirect
+
+This may happen during usb camera redirect. But if i move the camera lens from left to right or up to down, this always happen. My qemu-version is 2.10.0 and following is the error information:
+
+2018-10-26T03:37:54.925231Z qemu-kvm: usbredirparser: error unexpected extra data ep 00
+qemu-kvm: hw/usb/redirect.c:1313: usbredir_chardev_read: Assertion `dev->read_buf == ((void *)0)' failed.
+2018-10-26 03:37:57.120+0000: shutting down, reason=crashed
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1808824 b/results/classifier/deepseek-2-tmp/output/peripherals/1808824
new file mode 100644
index 000000000..e76b55199
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1808824
@@ -0,0 +1,8 @@
+
+Mouse leaves VM window when Grab on Hover isn't selected Windows 10 and Intel HAX
+
+On Windows 10.0.17134 I have been having the problem that the mouse will leave the VM window after a short time when grab on hover isn't selected.  The VM will then try to grab on Hover and the mouse will grab in weird places and it will become very unwieldy to control the mouse in the VM window.
+
+This is exasperated by super slow response making it nearly unusable  if the Intel® Hardware Accelerated Execution Manager (Intel® HAXM) is not currently installed on my machine.
+
+I know they are different things but they compounded on each other when you have a mouse that is not staying in the VM window and the VM's visualized cpu is acting VERY slow the system is unusable.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1809291 b/results/classifier/deepseek-2-tmp/output/peripherals/1809291
new file mode 100644
index 000000000..9d7002756
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1809291
@@ -0,0 +1,13 @@
+
+SD Card not working in Ubuntu 18.10 (CMD 2,3 timeout).  The device worked fine in Ubuntu 18.04 and earlier versions but not in Ubuntu 18.10
+
+ARM PL181 MMC card no longer working in qemu-system-arm in Ubuntu 18.10
+The MMC driver code worked fine in Ubuntu 15.10 to 18.04.
+The command to run qemu-system-arm is
+
+    qemu-system-arm -M versatilepb -m 256M -sd sdimage -kernel t.bin -serial mon:stdio
+
+During SDC initialization, SDC commands 2, 3, 9, 13, 7, 16 all timeout, 
+which cause subsequent read/write commands 17/24 to fail also.
+
+Tried both ARM versatilepb and realview-pb-a8, realview-pbx-a9 boards: all the same.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/181 b/results/classifier/deepseek-2-tmp/output/peripherals/181
new file mode 100644
index 000000000..11f1f2834
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/181
@@ -0,0 +1,2 @@
+
+qemu crashes when doing iotest on  virtio-9p filesystem
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1810000 b/results/classifier/deepseek-2-tmp/output/peripherals/1810000
new file mode 100644
index 000000000..c3ac7d737
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1811916 b/results/classifier/deepseek-2-tmp/output/peripherals/1811916
new file mode 100644
index 000000000..e520aaa00
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1818398 b/results/classifier/deepseek-2-tmp/output/peripherals/1818398
new file mode 100644
index 000000000..5fd871e63
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1824528 b/results/classifier/deepseek-2-tmp/output/peripherals/1824528
new file mode 100644
index 000000000..d18408bcc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1824528
@@ -0,0 +1,19 @@
+
+qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]`
+
+Qemu compilation fails with below error on ppc64le host with gcc 9(9.0.1 20190328)
+repo: https://github.com/qemu/qemu.git
+branch: master
+commit e1be98540ee672ef93292b65a986055512237c35
+
+
+  CC      net/dump.o
+hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’:
+hw/usb/dev-mtp.c:1708:36: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
+ 1708 |                             dataset->filename);
+      |                             ~~~~~~~^~~~~~~~~~
+cc1: all warnings being treated as errors
+  CC      net/eth.o
+make: *** [/home/kvmci/qemu-main/rules.mak:69: hw/usb/dev-mtp.o] Error 1
+make: *** Waiting for unfinished jobs....
+  CC      net/announce.o
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1824704 b/results/classifier/deepseek-2-tmp/output/peripherals/1824704
new file mode 100644
index 000000000..1428e91e8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1825452 b/results/classifier/deepseek-2-tmp/output/peripherals/1825452
new file mode 100644
index 000000000..2783d761d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1825452
@@ -0,0 +1,26 @@
+
+Pulse audio backend doesn't work in  v4.0.0-rc4 release
+
+Using Gentoo linux, build from source: qemu v4.0.0-rc4 release (eeba63fc7fface36f438bcbc0d3b02e7dcb59983)
+
+Pulse audio backend doesn't initialize because of the:
+audio/paaudio.c:
+-    if (!popts->has_server) {
+-        char pidfile[64];
+-        char *runtime;
+-        struct stat st;
+-
+-        runtime = getenv("XDG_RUNTIME_DIR");
+-        if (!runtime) {
+-            return NULL;
+-        }
+-        snprintf(pidfile, sizeof(pidfile), "%s/pulse/pid", runtime);
+-        if (stat(pidfile, &st) != 0) {
+-            return NULL;
+-        }
+-    }
+XDG_RUNTIME_DIR is not set for me. There is no /run/user directory exist in my system.
+
+Also:
+$ less ~/.pulse/client.conf  
+default-server = unix:/home/ivan/.pulse_server
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1838475 b/results/classifier/deepseek-2-tmp/output/peripherals/1838475
new file mode 100644
index 000000000..32132f131
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1838475
@@ -0,0 +1,19 @@
+
+qemu-system-arm exits when cortex-m4 floating point used and irq occurs
+
+qemu-system-arm exits with 
+
+"...Secure UsageFault with CFSR.NOCP because NSACR.CP10 prevents stacking FP regs
+...taking pending nonsecure exception 3
+Taking exception 7 [Breakpoint]
+qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)" 
+
+when emulating Cortex-m4, executing at least 1 floating point instruction, and then an irq (e.g. sys tick) occurring.
+
+CPACR.CP10 and CPACR.CP11 are set to 0x3 respectively prior to executing the fp instructions.
+
+NOTE: NSACR does not appear to be a cortex m4 register.
+
+Attached is a simplified elf to repro the issue.
+
+The qemu command line is: "qemu-system-arm --gdb tcp::1234 -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel QemuExitWhenUsingFPAndIRQOccurs.elf -d int"
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1845 b/results/classifier/deepseek-2-tmp/output/peripherals/1845
new file mode 100644
index 000000000..b4b2522b4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1854878 b/results/classifier/deepseek-2-tmp/output/peripherals/1854878
new file mode 100644
index 000000000..b64004747
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1854878
@@ -0,0 +1,33 @@
+
+Physical USB thumbdrive treated as read-only
+
+So I have installed FreeDOS on my USB thumbdrive, by using Rufus. Everything goes as expected so far. That's good.
+
+When I run QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1
+
+it of course is read-only, just like the resulting console message says:
+WARNING: Image format was not specified for '\\.\PhysicalDrive1' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+
+
+So what I then did, was I ran QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw
+
+As expected, the above mentioned console message no longer appears.
+However, beyond that, QEMU doesn't behave as it should regarding read-only status. When I try any operation that involves writing to the drive, it becomes quite clear that the drive is still read-only. Any writing operations to the drive result in FreeDOS giving me the error message:
+Error writing to drive C: DOS area: sector not found.
+
+The above situation is clearly a bug. QEMU should not be treating it as read-only once I specify format=raw.
+
+Note that drive C is how the guest OS refers to the USB thumbdrive (it's drive E in my host OS, and drive C in my host OS is the actual system drive).
+
+And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this command line, so that all changes would be written to a temporary snapshot file:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot
+That last drive option "snapshot" tells QEMU to create a temporary snapshot file, and to write all changes to that. When I do that, all write operations are successful. So it seems that there is a bug in QEMU where it keeps read-only mode in place for a physical drive, even when format=raw is specified. Please fix this bug. Thanks in advance.
+
+Here's my current setup.
+Host OS: Windows 10 (64bit)
+Guest OS: FreeDOS
+QEMU version: 4.1.0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1857269 b/results/classifier/deepseek-2-tmp/output/peripherals/1857269
new file mode 100644
index 000000000..281acb3aa
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1859081 b/results/classifier/deepseek-2-tmp/output/peripherals/1859081
new file mode 100644
index 000000000..8aa0bf148
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1859378 b/results/classifier/deepseek-2-tmp/output/peripherals/1859378
new file mode 100644
index 000000000..785a3093a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1859384 b/results/classifier/deepseek-2-tmp/output/peripherals/1859384
new file mode 100644
index 000000000..d42cd04e5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1861458 b/results/classifier/deepseek-2-tmp/output/peripherals/1861458
new file mode 100644
index 000000000..8a131b412
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1861458
@@ -0,0 +1,15 @@
+
+Clock drift issue with -soundhw hda
+
+Here's the scenario: I'm working on code for loopback audio recording (i.e. recording what you're hearing) using WASAPI on Windows. As I usually develop on Linux, I'm using qemu to test this on a Windows 10 VM. The heart of WASAPI audio recording is the IAudioCaptureClient::GetBuffer function (https://docs.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudiocaptureclient-getbuffer). Among other things, this function produces a timestamp for when the audio buffer it returned is supposed to be played.
+
+When the audio device in question is the qemu hda device, this timestamp is wrong.
+
+There is a clock drift error (I measured it to be about 0.1%, i.e. 1ms drift every second = a full second after 16 minutes) that causes the audio clock to advance faster than the system clock. Paradoxically, this does not affect audio playback through qemu at all, no delay there. Only the timestamps returned to recording applications are completely bogus.
+
+Unfortunately I'm not intimately familiar with the inner workings of Intel HD Audio. All I can tell you is that this timestamp is supposedly obtained directly from the hardware (which would be qemu in this case), which is also why e.g. chromium implements a workaround for buggy hardware that returns incorrect timestamps.
+
+Here are the relevant parts of my command line (version 4.2.0):
+-enable-kvm -machine pc-q35-3.1,kernel-irqchip=on -cpu host,kvm=off,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=NvidiaFuckU -rtc base=localtime -nodefaults -soundhw hda
+
+Just wanted to let you know about this because it took me three days of utter confusion and frustration to figure this out.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1863526 b/results/classifier/deepseek-2-tmp/output/peripherals/1863526
new file mode 100644
index 000000000..71ac1b3c2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1863526
@@ -0,0 +1,22 @@
+
+NVIC CCR register not 8-bit accessible using Cortex-M4
+
+Head at commit b29c3e23f64938.
+
+Running with '-d unimp,guest_errors -trace nvic\*' I get:
+
+8871@1581892794.295746:nvic_sysreg_read NVIC sysreg read addr 0xd88 data 0xf00000 size 4
+8871@1581892794.295752:nvic_sysreg_write NVIC sysreg write addr 0xd88 data 0xf00000 size 4
+8871@1581892794.297780:nvic_sysreg_write NVIC sysreg write addr 0xd08 data 0x4200 size 4
+8871@1581892794.298040:nvic_sysreg_write NVIC sysreg write addr 0xd15 data 0x0 size 1
+NVIC: Bad write of size 1 at offset 0xd15
+8871@1581892794.298081:nvic_sysreg_write NVIC sysreg write addr 0xd16 data 0x0 size 1
+NVIC: Bad write of size 1 at offset 0xd16
+8871@1581892794.298116:nvic_sysreg_write NVIC sysreg write addr 0xd17 data 0x0 size 1
+NVIC: Bad write of size 1 at offset 0xd17
+8871@1581892794.298156:nvic_sysreg_write NVIC sysreg write addr 0xd18 data 0x0 size 1
+8871@1581892794.298161:nvic_set_prio NVIC set irq 4 secure-bank 0 priority 0
+8871@1581892794.298164:nvic_recompute_state NVIC state recomputed: vectpending 0 vectpending_prio 256 exception_prio 256
+8871@1581892794.298168:nvic_irq_update NVIC vectpending 0 pending prio 256 exception_prio 256: setting irq line to 0
+8871@1581892794.298201:nvic_sysreg_write NVIC sysreg write addr 0xd19 data 0x0 size 1
+8871@1581892794.298206:nvic_set_prio NVIC set irq 5 secure-bank 0 priority 0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1863601 b/results/classifier/deepseek-2-tmp/output/peripherals/1863601
new file mode 100644
index 000000000..0e5b72ea0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1863601
@@ -0,0 +1,4 @@
+
+unable to type "|" character in french keyboard.
+
+Unable to type "|" character when using french keyboard. It is displaying "<" instead of pipe.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1871267 b/results/classifier/deepseek-2-tmp/output/peripherals/1871267
new file mode 100644
index 000000000..fa514b167
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1871267
@@ -0,0 +1,10 @@
+
+Multiple (Repeating) Keystrokes in macOS
+
+Hi,
+
+I am finding this issue with v4.2.0, or the latest master - on a Windows host, with macOS guest. It happens using gtk (SPICE?) or VNC. When I get to a place to enter a keystroke, I quite reliably get multiple of the same key (i.e. press A, get AAAA).
+
+Thinking there may be a basic setting to address this? I did try it in Linux (kvm), no issue there.
+
+Thanks!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1873335 b/results/classifier/deepseek-2-tmp/output/peripherals/1873335
new file mode 100644
index 000000000..2ea98c38c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1873337 b/results/classifier/deepseek-2-tmp/output/peripherals/1873337
new file mode 100644
index 000000000..b8063141b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1874904 b/results/classifier/deepseek-2-tmp/output/peripherals/1874904
new file mode 100644
index 000000000..95d87c83a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1875 b/results/classifier/deepseek-2-tmp/output/peripherals/1875
new file mode 100644
index 000000000..cec7d8bf1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1876187 b/results/classifier/deepseek-2-tmp/output/peripherals/1876187
new file mode 100644
index 000000000..66748ae31
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1878134 b/results/classifier/deepseek-2-tmp/output/peripherals/1878134
new file mode 100644
index 000000000..488013f6b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1878134
@@ -0,0 +1,46 @@
+
+Assertion failures in ati_reg_read_offs/ati_reg_write_offs
+
+Hello,
+While fuzzing, I found inputs that trigger assertion failures in
+ati_reg_read_offs/ati_reg_write_offs
+
+uint32_t extract32(uint32_t, int, int): Assertion `start >= 0 && length > 0 && length <= 32 - start' failed
+
+#3  0x00007ffff6866092 in __GI___assert_fail (assertion=0x555556e760c0 <str> "start >= 0 && length > 0 && length <= 32 - start", file=0x555556e76120 <str> "/home/alxndr/Development/qemu/include/qemu/bitops.h", line=0x12c, function=0x555556e76180 <__PRETTY_FUNCTION__.extract32> "uint32_t extract32(uint32_t, int, int)") at assert.c:101
+#4  0x000055555653d8a7 in ati_mm_read (opaque=<optimized out>, addr=0x1a, size=<optimized out>) at /home/alxndr/Development/qemu/include/qemu/log-for-trace.h:29
+#5  0x000055555653c825 in ati_mm_read (opaque=<optimized out>, addr=0x4, size=<optimized out>) at /home/alxndr/Development/qemu/hw/display/ati.c:289
+#6  0x000055555601446e in memory_region_read_accessor (mr=0x63100004dc20, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:434
+#7  0x0000555556001a70 in 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=0x63100004dc20, attrs=...) at /home/alxndr/Development/qemu/memory.c:544
+#8  0x0000555556001a70 in memory_region_dispatch_read1 (mr=0x63100004dc20, addr=0x4, pval=<optimized out>, size=0x4, attrs=...) at /home/alxndr/Development/qemu/memory.c:1396
+
+
+I can reproduce it in qemu 5.0 built with using:
+cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none
+outl 0xcf8 0x80001018
+outl 0xcfc 0xe2000000
+outl 0xcf8 0x8000101c
+outl 0xcf8 0x80001004
+outw 0xcfc 0x7
+outl 0xcf8 0x8000fa20
+write 0xe2000004 0x1 0x1a
+readq 0xe2000000
+EOF
+
+Similarly for ati_reg_write_offs:
+cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none
+outl 0xcf8 0x80001018
+outl 0xcfc 0xe2000000
+outl 0xcf8 0x8000101c
+outl 0xcf8 0x80001004
+outw 0xcfc 0x7
+outl 0xcf8 0x8000fa20
+write 0xe2000000 0x8 0x6a00000000006a00
+EOF
+
+I also attached the traces to this launchpad report, in case the formatting is broken:
+
+qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial 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/deepseek-2-tmp/output/peripherals/1878645 b/results/classifier/deepseek-2-tmp/output/peripherals/1878645
new file mode 100644
index 000000000..6197d581e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1878915 b/results/classifier/deepseek-2-tmp/output/peripherals/1878915
new file mode 100644
index 000000000..fbc9596e8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1878915
@@ -0,0 +1,40 @@
+
+util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.
+
+qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)
+
+Stack trace:
+
+                Stack trace of thread 31002:
+                #0  0x00000000b7faf1cd __kernel_vsyscall (linux-gate.so.1 + 0x11cd)
+                #1  0x00000000b6c618e2 __libc_signal_restore_set (libc.so.6 + 0x348e2)
+                #2  0x00000000b6c4a309 __GI_abort (libc.so.6 + 0x1d309)
+                #3  0x00000000b6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1)
+                #4  0x00000000b6c59929 __GI___assert_fail (libc.so.6 + 0x2c929)
+                #5  0x0000000000ba80be get_sqe (qemu-system-i386 + 0x6d00be)
+                #6  0x0000000000ba80cb add_poll_add_sqe (qemu-system-i386 + 0x6d00cb)
+                #7  0x0000000000ba820c fill_sq_ring (qemu-system-i386 + 0x6d020c)
+                #8  0x0000000000ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
+                #9  0x0000000000aede63 blk_prw (qemu-system-i386 + 0x615e63)
+                #10 0x0000000000aeef95 blk_pread (qemu-system-i386 + 0x616f95)
+                #11 0x00000000008abbfa fdctrl_transfer_handler (qemu-system-i386 + 0x3d3bfa)
+                #12 0x0000000000906c3d i8257_channel_run (qemu-system-i386 + 0x42ec3d)
+                #13 0x00000000008ac119 fdctrl_start_transfer (qemu-system-i386 + 0x3d4119)
+                #14 0x00000000008ab233 fdctrl_write_data (qemu-system-i386 + 0x3d3233)
+                #15 0x0000000000708ae7 memory_region_write_accessor (qemu-system-i386 + 0x230ae7)
+                #16 0x00000000007059e1 access_with_adjusted_size (qemu-system-i386 + 0x22d9e1)
+                #17 0x000000000070b931 memory_region_dispatch_write (qemu-system-i386 + 0x233931)
+                #18 0x00000000006a87a2 address_space_stb (qemu-system-i386 + 0x1d07a2)
+                #19 0x0000000000829216 helper_outb (qemu-system-i386 + 0x351216)
+                #20 0x00000000b06d9fdc n/a (n/a + 0x0)
+
+Steps:
+
+0. qemu-img create -f raw fda.img 3840K
+1. mformat -i fda.img -n 48 -t 80 -h 2
+2. qemu-system-i386 -fda fda.img -hda freedos.qcow2
+3. Attempt to run 'dosfsck a:' in the guest
+
+According to hw/block/fdc.c, a 3840K image should result in a virtual floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides.
+
+The assert seems bogus either way.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1880066 b/results/classifier/deepseek-2-tmp/output/peripherals/1880066
new file mode 100644
index 000000000..9eeef9c31
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1883739 b/results/classifier/deepseek-2-tmp/output/peripherals/1883739
new file mode 100644
index 000000000..11f1cbc3a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1884017 b/results/classifier/deepseek-2-tmp/output/peripherals/1884017
new file mode 100644
index 000000000..6bdf41260
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1891829 b/results/classifier/deepseek-2-tmp/output/peripherals/1891829
new file mode 100644
index 000000000..935d54c17
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1892604 b/results/classifier/deepseek-2-tmp/output/peripherals/1892604
new file mode 100644
index 000000000..c8fd9a628
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1895363 b/results/classifier/deepseek-2-tmp/output/peripherals/1895363
new file mode 100644
index 000000000..c75ecad88
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1895602 b/results/classifier/deepseek-2-tmp/output/peripherals/1895602
new file mode 100644
index 000000000..a87381dd0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1895602
@@ -0,0 +1,12 @@
+
+older OS's do not detect CD change
+
+There are at least two older operating systems, being FreeBSD 2.2 and FreeDOS 1.2, that misbehave when the change command is used on the IDE CD drive, and work fine on a real machine.  In both cases, changing the CD causes the guest to either refuse to read the disc or appear to read bad data, and in both cases the guest read the disc without issue after a system_reset.
+
+A HD image that demonstrates this behavior can be produced if necessary, however the FreeDOS 1.2 CD can be booted directly and used to test:
+
+http://freedos.org/download/download/FD12CD.iso
+
+(choose install then abort and you get a prompt in which you can type "dir D:", say)
+
+note, running eject before the change command does nothing to help.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1899539 b/results/classifier/deepseek-2-tmp/output/peripherals/1899539
new file mode 100644
index 000000000..0f4d91d2f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1900155 b/results/classifier/deepseek-2-tmp/output/peripherals/1900155
new file mode 100644
index 000000000..2a60f71db
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1900155
@@ -0,0 +1,59 @@
+
+MIPS Malta fails booting due to IDE error
+
+As of commit 3e407488349:
+
+$ avocado --show=console run -t machine:malta tests/acceptance/boot_linux_console.py    
+console: [    0.000000] Linux version 4.5.0-2-4kc-malta (<email address hidden>) (gcc version 5.3.1 20160519 (Debian 5.3.1-20) ) #1 Debian 4.5.5-1 (2016-05-29)
+console: [    0.000000] earlycon: Early serial console at I/O port 0x3f8 (options '38400n8')
+console: [    0.000000] bootconsole [uart0] enabled
+console: [    0.000000] CPU0 revision is: 00019300 (MIPS 24Kc)
+console: [    0.000000] FPU revision is: 00739300
+console: [    0.000000] MIPS: machine is mti,malta
+[...]
+console: ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
+console: ata2.00: Drive reports diagnostics failure. This may indicate a drive
+console: ata2.00: fault or invalid emulation. Contact drive vendor for information.
+console: ata2.00: configured for UDMA/33
+console: scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     2.5+ PQ: 0 ANSI: 5
+console: Freeing unused kernel memory: 412K (80979000 - 809e0000)
+console: do_page_fault(): sending SIGSEGV to mount for invalid write access to 0018a000
+console: epc = 775cca54 in libc-2.27.so[775b3000+177000]
+console: ra  = 77754618 in ld-2.27.so[77743000+24000]
+console: do_page_fault(): sending SIGSEGV to klogd for invalid write access to 0018a000
+console: epc = 770f0a54 in libc-2.27.so[770d7000+177000]
+console: ra  = 77278618 in ld-2.27.so[77267000+24000]
+console: do_page_fault(): sending SIGSEGV to S20urandom for invalid write access to 0018a000
+console: epc = 77d0ca54 in libc-2.27.so[77cf3000+177000]
+console: ra  = 77e94618 in ld-2.27.so[77e83000+24000]
+console: do_page_fault(): sending SIGSEGV to mkdir for invalid write access to 0018a000
+console: epc = 776b8a54 in libc-2.27.so[7769f000+177000]
+console: ra  = 77840618 in ld-2.27.so[7782f000+24000]
+console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 0018a000
+console: epc = 77364a54 in libc-2.27.so[7734b000+177000]
+console: ra  = 774ec618 in ld-2.27.so[774db000+24000]
+console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 0018a000
+console: epc = 77bd4a54 in libc-2.27.so[77bbb000+177000]
+console: ra  = 77d5c618 in ld-2.27.so[77d4b000+24000]
+console: do_page_fault(): sending SIGSEGV to awk for invalid write access to 0018a000
+console: epc = 76f44a54 in libc-2.27.so[76f2b000+177000]
+console: ra  = 770cc618 in ld-2.27.so[770bb000+24000]
+console: do_page_fault(): sending SIGSEGV to cat for invalid write access to 0018a000
+console: epc = 770cca54 in libc-2.27.so[770b3000+177000]
+console: ra  = 77254618 in ld-2.27.so[77243000+24000]
+$ echo $?
+8
+
+55adb3c45620c31f29978f209e2a44a08d34e2da is the first bad commit
+commit 55adb3c45620c31f29978f209e2a44a08d34e2da
+Author: John Snow <email address hidden>
+Date:   Fri Jul 24 01:23:00 2020 -0400
+
+    ide: cancel pending callbacks on SRST
+
+    The SRST implementation did not keep up with the rest of IDE; it is
+    possible to perform a weak reset on an IDE device to remove the BSY/DRQ
+    bits, and then issue writes to the control/device registers which can
+    cause chaos with the state machine.
+
+    Fix that by actually performing a real reset.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1900352 b/results/classifier/deepseek-2-tmp/output/peripherals/1900352
new file mode 100644
index 000000000..b9033fe02
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1900352
@@ -0,0 +1,6 @@
+
+no sound in spice when VNC enabled
+
+Running Fedora32 with virt-manager → libvirt → qemu  I noticed that I got no sound in my spice client. The VM is configured with a SPICE-server and a QXL display, and in addition a VNC display.
+
+Apparently when I remove the VNC display, then the sound is routed just fine to the spice client: I can hear it, and `G_MESSAGES_DEBUG=all remote-viewer --spice-debug  spice://localhost:5900` mentions SpicePlaybackChannel and SpiceRecordChannel. With the VNC server configured, such messages are missing, and I cannot hear the sound (which is sent by the guest OS to the virtual hardware).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1901981 b/results/classifier/deepseek-2-tmp/output/peripherals/1901981
new file mode 100644
index 000000000..1aa597341
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1901981
@@ -0,0 +1,20 @@
+
+assert issue locates in hw/usb/dev-storage.c:248: usb_msd_send_status
+
+Hello,
+
+I found an assertion failure through hw/usb/dev-storage.c.
+
+This was found in latest version 5.1.0.
+
+--------
+
+qemu-system-x86_64: hw/usb/dev-storage.c:248: usb_msd_send_status: Assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed.
+[1]    29544 abort      sudo  -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic
+
+To reproduce the assertion failure, please run the QEMU with following command line.
+
+
+$ qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic user,model=rtl8139,hostfwd=tcp:0.0.0.0:5555-:22 -device piix4-usb-uhci,id=uhci -device usb-storage,drive=mydrive -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none
+
+The poc is attached.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1902112 b/results/classifier/deepseek-2-tmp/output/peripherals/1902112
new file mode 100644
index 000000000..5e9912acc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1902112
@@ -0,0 +1,44 @@
+
+[OSS-Fuzz] Issue 26693: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci: Index-out-of-bounds in xhci_runtime_write 
+
+OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26693
+
+=== Reproducer (build with --enable-sanitizers) ===
+export UBSAN_OPTIONS="print_stacktrace=1:silence_unsigned_overflow=1"
+cat << EOF | ./qemu-system-i386 -display none -machine\
+ accel=qtest, -m 512M -machine q35 -nodefaults -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
+outl 0xcf8 0x80000803
+outl 0xcfc 0x18caffff
+outl 0xcf8 0x80000810
+outl 0xcfc 0x555a2e46
+write 0x555a1004 0x4 0xe7b9aa7a
+EOF
+
+=== Stack Trace ===
+ 	
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/hcd-xhci.c:3012:30 in
+../hw/usb/hcd-xhci.c:3012:30: runtime error: index -1 out of bounds for type 'XHCIInterrupter [16]'
+#0 0x55bd2e97c8b0 in xhci_runtime_write /src/qemu/hw/usb/hcd-xhci.c:3012:30
+#1 0x55bd2edfdd13 in memory_region_write_accessor /src/qemu/softmmu/memory.c:484:5
+#2 0x55bd2edfdb14 in access_with_adjusted_size /src/qemu/softmmu/memory.c:545:18
+#3 0x55bd2edfd54b in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
+#4 0x55bd2ed7fa46 in flatview_write_continue /src/qemu/softmmu/physmem.c:2767:23
+#5 0x55bd2ed7cac0 in flatview_write /src/qemu/softmmu/physmem.c:2807:14
+#6 0x55bd2ed7c9f8 in address_space_write /src/qemu/softmmu/physmem.c:2899:18
+#7 0x55bd2e85cf9b in __wrap_qtest_writeq /src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9
+#8 0x55bd2e85b7b1 in op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:476:13
+#9 0x55bd2e85a84c in generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:678:17
+#10 0x55bd2e85dd6f in LLVMFuzzerTestOneInput /src/qemu/tests/qtest/fuzz/fuzz.c:150:5
+#11 0x55bd2e7e9661 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:595:15
+#12 0x55bd2e7d4732 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
+#13 0x55bd2e7da7ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:852:9
+#14 0x55bd2e8027d2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
+#15 0x7f3d153b783f in __libc_start_main
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1904464 b/results/classifier/deepseek-2-tmp/output/peripherals/1904464
new file mode 100644
index 000000000..1ae0eeef7
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1904464
@@ -0,0 +1,18 @@
+
+Build fails with 64 bits time_t
+
+time element is deprecated on new input_event structure in kernel's
+input.h [1]
+
+This will avoid the following build failure:
+
+hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
+hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no member named 'time'
+  198 |     if (gettimeofday(&evdev.time, NULL)) {
+      |                            ^
+
+Fixes:
+ - http://autobuild.buildroot.org/results/a538167e288c14208d557cd45446df86d3d599d5
+ - http://autobuild.buildroot.org/results/efd4474fb4b6c0ce0ab3838ce130429c51e43bbb
+
+[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1906180 b/results/classifier/deepseek-2-tmp/output/peripherals/1906180
new file mode 100644
index 000000000..46ce8e2a2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1906608 b/results/classifier/deepseek-2-tmp/output/peripherals/1906608
new file mode 100644
index 000000000..6f93d6b70
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1909247 b/results/classifier/deepseek-2-tmp/output/peripherals/1909247
new file mode 100644
index 000000000..ef4135083
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1909247
@@ -0,0 +1,30 @@
+
+QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c
+
+A use-after-free vulnerability was found in the am53c974 SCSI host bus adapter emulation of QEMU. It could occur in the esp_do_dma() function in hw/scsi/esp.c while handling the 'Information Transfer' command (CMD_TI). A privileged guest user may abuse this flaw to crash the QEMU process on the host, resulting in a denial of service or potential code execution with the privileges of the QEMU process.
+
+This issue was reported by Cheolwoo Myung (Seoul National University).
+
+Original report:
+Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in
+am53c974 emulator of QEMU enabled ASan.
+
+It occurs while transferring information, as it does not check the
+buffer to be transferred.
+
+A malicious guest user/process could use this flaw to crash the QEMU
+process resulting in DoS scenario.
+
+To reproduce this issue, please run the QEMU with the following command
+line.
+
+# To enable ASan option, please set configuration with the following
+$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers
+$ make
+
+# To reproduce this issue, please run the QEMU process with the following command line
+$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \
+-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \
+-drive id=SysDisk,if=none,file=./disk.img
+
+Please find attached the disk images to reproduce this issue.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1911216 b/results/classifier/deepseek-2-tmp/output/peripherals/1911216
new file mode 100644
index 000000000..cd1acb6a9
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1913341 b/results/classifier/deepseek-2-tmp/output/peripherals/1913341
new file mode 100644
index 000000000..9b5d9afd6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1913341
@@ -0,0 +1,24 @@
+
+Chardev behavior breaks polling based devices
+
+Currently in latest QEMU (9cd69f1a270235b652766f00b94114f48a2d603f at this time) the behavior of chardev sources is that when processed (before IO polling occurs), the chardev source will check the amount of space for reading.
+
+If it reports more than 0 bytes available to accept the read and a callback is not set, the code will set a child source connected to the QIOChannel submitted to the original source. If there's no buffer space reported, it will check for an active source, if registered it will detach this source. 
+
+Next time the loop fires, if the buffer now reports space (most likely the guest has run, emptying some bytes from the buffer), it will setup the callback again.
+
+However, if we have a stupid simple device (or driver) that doesn't have buffers big enough to fit an available write when one is sent (say a single byte buffer, polled serial port), then the poll will be set, the poll will occur and return quickly, then the callback will (depending on the backend chardev used) most likely read the 1 byte it has space for from the source, push it over to the frontend hardware side, and the IO loop will run again.
+
+Most likely the guest will not clear this byte before the next io loop cycle, meaning that the next prepare call on the source will see a full buffer in the guest and remove the poll for the data source, to allow the guest time to run to clear the buffer. Except, without a poll or a timeout set, the io loop might now block forever, since there's no report from the guest after clearing that buffer. This only returns in a sane amount of time because often some other device/timer is scheduled which sets a timeout on the poll to a reasonable time.
+
+I don't have a simple submittable bit of code to replicate at the moment but connecting a serial port to a pty then writing a large amount of data, while a guest that doesn't enable the fifo spins on an rx ready register, you can observe that RX on the guest takes anywhere from 1s to forever per byte.
+
+This logic all occurs in chardev/char-io.c
+
+Fixing this can be as simple as removing the logic to detach the child event source and changing the attach logic to only occur if there's buffer space and the poll isn't already setup. That fix could cause flow control issues potentially if the io runs on the same thread as the emulated guest (I am not sure about the details of this) and the guest is in a tight loop doing the poll. I don't see that as happening but the logic might be there for a reason.
+
+Another option is to set a timeout when the source gets removed, forcing the poll to exit with a fixed delay, this delay could potentially be derived from something like the baud rate set, forcing a minimum time before forward progress.
+
+If removing the logic isn't an option, another solution is to make the emulated hardware code itself kick the IO loop and trigger it to reschedule the poll. Similar to how the non-blocking write logic works, the read logic could recognize when the buffer has been emptied and reschedule the hw on the guest. In theory this sounds nice, but for it to work would require adding logic to all the emulated chardev frontends and in reality would likely be going through the effort to remove the callback only to within a few nanoseconds potentially want to add it back. 
+
+I'm planning to submit a patch with just outright removing the logic, but am filing this bug as a place to reference since tracking down this problem is non-obvious.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1913668 b/results/classifier/deepseek-2-tmp/output/peripherals/1913668
new file mode 100644
index 000000000..3c0be2b35
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1913668
@@ -0,0 +1,36 @@
+
+FPE in npcm7xx_pwm_calculate_freq
+
+Reproducer:
+cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \
+-accel qtest -qtest stdio
+write 0xf0103008 0x4 0x09000000
+write 0xf010300c 0x4 0xffffffff
+EOF
+
+Trace:
+../hw/misc/npcm7xx_pwm.c:94:17: runtime error: division by zero
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_pwm.c:94:17 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==717868==ERROR: AddressSanitizer: FPE on unknown address 0x5597c7190150 (pc 0x5597c7190150 bp 0x7fffcb17c5d0 sp 0x7fffcb17c4e0 T0)
+#0 0x5597c7190150 in npcm7xx_pwm_calculate_freq /hw/misc/npcm7xx_pwm.c:94:17
+#1 0x5597c7190150 in npcm7xx_pwm_update_freq /hw/misc/npcm7xx_pwm.c:122:21
+#2 0x5597c718f06d in npcm7xx_pwm_write /hw/misc/npcm7xx_pwm.c
+#3 0x5597c8d241fe in memory_region_write_accessor /softmmu/memory.c:491:5
+#4 0x5597c8d23bfb in access_with_adjusted_size /softmmu/memory.c:552:18
+#5 0x5597c8d23467 in memory_region_dispatch_write /softmmu/memory.c
+#6 0x5597c90b3ffb in flatview_write_continue /softmmu/physmem.c:2759:23
+#7 0x5597c90a971b in flatview_write /softmmu/physmem.c:2799:14
+#8 0x5597c90a971b in address_space_write /softmmu/physmem.c:2891:18
+#9 0x5597c8d11eee in qtest_process_command /softmmu/qtest.c:539:13
+#10 0x5597c8d0eb97 in qtest_process_inbuf /softmmu/qtest.c:797:9
+#11 0x5597c955f286 in fd_chr_read /chardev/char-fd.c:68:9
+#12 0x7f994c124aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae)
+#13 0x5597c9bba363 in glib_pollfds_poll /util/main-loop.c:232:9
+#14 0x5597c9bba363 in os_host_main_loop_wait /util/main-loop.c:255:5
+#15 0x5597c9bba363 in main_loop_wait /util/main-loop.c:531:11
+#16 0x5597c8c75599 in qemu_main_loop /softmmu/runstate.c:721:9
+#17 0x5597c6f021fd in main /softmmu/main.c:50:5
+#18 0x7f994bbc9cc9 in __libc_start_main csu/../csu/libc-start.c:308:16
+#19 0x5597c6e55bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1913669 b/results/classifier/deepseek-2-tmp/output/peripherals/1913669
new file mode 100644
index 000000000..498d4eb21
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/1914353 b/results/classifier/deepseek-2-tmp/output/peripherals/1914353
new file mode 100644
index 000000000..1446114c1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1914353
@@ -0,0 +1,51 @@
+
+QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID
+
+Via [qemu-security] list
+
++-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+
+| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote:
+| > Per the ARM Generic Interrupt Controller Architecture specification
+| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
+| > not 10:
+| >
+| >    - Table 4-21 GICD_SGIR bit assignments
+| >
+| >    The Interrupt ID of the SGI to forward to the specified CPU
+| >    interfaces. The value of this field is the Interrupt ID, in
+| >    the range 0-15, for example a value of 0b0011 specifies
+| >    Interrupt ID 3.
+| >
+...
+| > Correct the irq mask to fix an undefined behavior (which eventually
+| > lead to a heap-buffer-overflow, see [Buglink]):
+| >
+| >    $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio
+| >    [I 1612088147.116987] OPENED
+| >  [R +0.278293] writel 0x8000f00 0xff4affb0
+| >  ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]'
+| >  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13
+| >
+| > Cc: <email address hidden>
+| > Fixes: 9ee6e8bb853 ("ARMv7 support.")
+| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
+| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
+...
+
+On 210202 1221, Peter Maydell wrote:
+> In both cases the overrun is on the first writel to 0x8000f00,
+> but the fuzzer has for some reason not reported that but instead
+> blundered on until it happens to trigger some other issue that
+> resulted from the memory corruption it induced with the first write.
+>
+...
+> On the CVE:
+>
+> Since this can affect systems using KVM, this is a security bug for
+> us. However, it only affects an uncommon configuration:
+> you are only vulnerable if you are using "kernel-irqchip=off"
+> (the default is 'on', and turning it off is an odd thing to do).
+>
+> thanks
+> -- PMM
+>
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1917442 b/results/classifier/deepseek-2-tmp/output/peripherals/1917442
new file mode 100644
index 000000000..d73b8de95
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1917442
@@ -0,0 +1,77 @@
+
+[AHCI] crash when running a GNU/Hurd guest
+
+QEMU git hash = 51db2d7cf2
+
+Running guest OS using:
+
+$ gdb --args /extra/qemu/bin/qemu-system-i386 -M q35,accel=kvm -m 4096 -net user,hostfwd=tcp::8888-:22 -net nic -drive id=udisk,file=/dev/sdd,format=raw,if=none -device ide-drive,drive=udisk,bootindex=1 -curses
+
+...
+
+root@zamhurd:~# .ahcisata0 channel 5: setting WDCTL_RST failed for drive 0
+
+
+Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault.
+                                                                       [Switching to Thread 0x7ffff4f7bf00 (LWP 590666)]
+ahci_commit_buf (dma=0x555557335870, tx_bytes=2048) at ../hw/ide/ahci.c:1462
+1462        tx_bytes += le32_to_cpu(ad->cur_cmd->status);
+(gdb) bt full
+#0  ahci_commit_buf (dma=0x555557335870, tx_bytes=2048)
+    at ../hw/ide/ahci.c:1462
+        ad = 0x555557335870
+#1  0x0000555555893171 in dma_buf_commit (s=0x555557335930, tx_bytes=2048)
+    at ../hw/ide/core.c:805
+#2  0x00005555558934f8 in ide_dma_cb (opaque=0x555557335930, ret=0)
+    at ../hw/ide/core.c:887
+        s = 0x555557335930
+        n = 4
+        sector_num = 4491160
+        offset = 140732794753312
+        stay_active = false
+        prep_size = 0
+        __PRETTY_FUNCTION__ = "ide_dma_cb"
+#3  0x0000555555830720 in dma_complete (dbs=0x7ffee83d5120, ret=0)
+    at ../softmmu/dma-helpers.c:121
+        __PRETTY_FUNCTION__ = "dma_complete"
+#4  0x00005555558307cd in dma_blk_cb (opaque=0x7ffee83d5120, ret=0)
+    at ../softmmu/dma-helpers.c:139
+        dbs = 0x7ffee83d5120
+        cur_addr = 140732794753408
+        cur_len = 93825013280880
+        mem = 0x7ffeeccfef00
+        __PRETTY_FUNCTION__ = "dma_blk_cb"
+#5  0x0000555555d92bce in blk_aio_complete (acb=0x7ffee847bbe0)
+    at ../block/block-backend.c:1412
+#6  0x0000555555d92df0 in blk_aio_read_entry (opaque=0x7ffee847bbe0)
+    at ../block/block-backend.c:1466
+        acb = 0x7ffee847bbe0
+        rwco = 0x7ffee847bc08
+        qiov = 0x7ffee83d5180
+        __PRETTY_FUNCTION__ = "blk_aio_read_entry"
+#7  0x0000555555e85580 in coroutine_trampoline (i0=-398117056, i1=32766)
+    at ../util/coroutine-ucontext.c:173
+        arg = {p = 0x7ffee8453740, i = {-398117056, 32766}}
+        self = 0x7ffee8453740
+        co = 0x7ffee8453740
+        fake_stack_save = 0x0
+#8  0x00007ffff6544020 in __start_context () at /lib64/libc.so.6
+#9  0x00007ffeefdfd680 in  ()
+#10 0x0000000000000000 in  ()
+(gdb)
+(gdb) l
+1457	 */
+1458	static void ahci_commit_buf(const IDEDMA *dma, uint32_t tx_bytes)
+1459	{
+1460	    AHCIDevice *ad = DO_UPCAST(AHCIDevice, dma, dma);
+1461	
+1462	    tx_bytes += le32_to_cpu(ad->cur_cmd->status);
+1463	    ad->cur_cmd->status = cpu_to_le32(tx_bytes);
+1464	}
+1465	
+1466	static int ahci_dma_rw_buf(const IDEDMA *dma, bool is_write)
+(gdb) p ad
+$1 = (AHCIDevice *) 0x555557335870
+(gdb) p ad->cur_cmd
+$2 = (AHCICmdHdr *) 0x0
+(gdb)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1918321 b/results/classifier/deepseek-2-tmp/output/peripherals/1918321
new file mode 100644
index 000000000..5322683f0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/1918321
@@ -0,0 +1,84 @@
+
+[OSS-Fuzz] Issue 31875 megasas: Null-ptr dereference in megasas_finish_dcmd
+
+Hello,
+
+== QTest Reproducer ==
+/* 
+ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \
+ * 512M -machine q35 -nodefaults -device megasas -device \
+ * scsi-cd,drive=null0 -blockdev \
+ * driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio
+ * outl 0xcf8 0x80000801
+ * outl 0xcfc 0x05000000
+ * outl 0xcf8 0x80000816
+ * outl 0xcfc 0x19000000
+ * write 0x1e1ed300 0x1 0x01
+ * write 0x1e1ed307 0x1 0x01
+ * write 0x1e1ed316 0x1 0x01
+ * write 0x1e1ed328 0x1 0x01
+ * write 0x1e1ed32f 0x1 0x01
+ * outl 0x1940 0x1e1ed300
+ * outl 0x19c0 0x00
+ * EOF
+ */
+static void null_deref_megasas_finish_dcmd(void)
+{
+    QTestState *s = qtest_init(
+        "-display none , -m 512M -machine q35 -nodefaults -device megasas -device "
+        "scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0 ");
+    qtest_outl(s, 0xcf8, 0x80000801);
+    qtest_outl(s, 0xcfc, 0x05000000);
+    qtest_outl(s, 0xcf8, 0x80000816);
+    qtest_outl(s, 0xcfc, 0x19000000);
+    qtest_bufwrite(s, 0x1e1ed300, "\x01", 0x1);
+    qtest_bufwrite(s, 0x1e1ed307, "\x01", 0x1);
+    qtest_bufwrite(s, 0x1e1ed316, "\x01", 0x1);
+    qtest_bufwrite(s, 0x1e1ed328, "\x01", 0x1);
+    qtest_bufwrite(s, 0x1e1ed32f, "\x01", 0x1);
+    qtest_outl(s, 0x1940, 0x1e1ed300);
+    qtest_outl(s, 0x19c0, 0x00);
+    qtest_quit(s);
+}
+int main(int argc, char **argv)
+{
+    const char *arch = qtest_get_arch();
+
+    g_test_init(&argc, &argv, NULL);
+
+    if (strcmp(arch, "i386") == 0) {
+        qtest_add_func("fuzz/null_deref_megasas_finish_dcmd",
+                       null_deref_megasas_finish_dcmd);
+    }
+
+    return g_test_run();
+}
+
+== Stack Trace ==
+../hw/scsi/megasas.c:1884:21: runtime error: member access within null pointer of type 'union mfi_frame'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:1884:21 in
+../hw/scsi/megasas.c:1884:21: runtime error: member access within null pointer of type 'struct mfi_frame_header'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/scsi/megasas.c:1884:21 in
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==314546==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000003 (pc 0x55b1b4f4de73 bp 0x7ffcfc5a8bb0 sp 0x7ffcfc5a8900 T0)
+==314546==The signal is caused by a WRITE memory access.
+==314546==Hint: address points to the zero page.
+#0 0x55b1b4f4de73 in megasas_command_complete build/../hw/scsi/megasas.c:1884:40
+#1 0x55b1b5613914 in scsi_req_complete build/../hw/scsi/scsi-bus.c:1515:5
+#2 0x55b1b5448aeb in scsi_dma_complete_noio build/../hw/scsi/scsi-disk.c:345:9
+#3 0x55b1b5446fc7 in scsi_dma_complete build/../hw/scsi/scsi-disk.c:366:5
+#4 0x55b1b4fffc56 in dma_complete build/../softmmu/dma-helpers.c:121:9
+#5 0x55b1b4fffc56 in dma_blk_cb build/../softmmu/dma-helpers.c:139:9
+#6 0x55b1b6856016 in blk_aio_complete build/../block/block-backend.c:1412:9
+#7 0x55b1b6f48b06 in aio_bh_poll build/../util/async.c:164:13
+#8 0x55b1b6f08cec in aio_dispatch build/../util/aio-posix.c:381:5
+#9 0x55b1b6f4d59c in aio_ctx_dispatch build/../util/async.c:306:5
+#10 0x7fd88c098baa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa)
+#11 0x55b1b6f59a3c in glib_pollfds_poll build/../util/main-loop.c:232:9
+#12 0x55b1b6f59a3c in os_host_main_loop_wait build/../util/main-loop.c:255:5
+#13 0x55b1b6f59a3c in main_loop_wait build/../util/main-loop.c:531:11
+#14 0x55b1b61a78a9 in qemu_main_loop build/../softmmu/runstate.c:725:9
+#15 0x55b1b4c751e5 in main build/../softmmu/main.c:50:5
+#16 0x7fd88aec6d09 in __libc_start_main csu/../csu/libc-start.c:308:16
+#17 0x55b1b4bc8bb9 in _start (system-i386+0x2b5fbb9)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1926174 b/results/classifier/deepseek-2-tmp/output/peripherals/1926174
new file mode 100644
index 000000000..41ddb8bde
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/195 b/results/classifier/deepseek-2-tmp/output/peripherals/195
new file mode 100644
index 000000000..db2f89169
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/195
@@ -0,0 +1,2 @@
+
+wavcapture does not record silence
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/1980 b/results/classifier/deepseek-2-tmp/output/peripherals/1980
new file mode 100644
index 000000000..343d0134d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2021 b/results/classifier/deepseek-2-tmp/output/peripherals/2021
new file mode 100644
index 000000000..308119e74
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2021
@@ -0,0 +1,2 @@
+
+crashing when trying to read data from sensor though usb
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/205 b/results/classifier/deepseek-2-tmp/output/peripherals/205
new file mode 100644
index 000000000..ce46130b2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/205
@@ -0,0 +1,2 @@
+
+Arrow keys press is double in some programs in Dos
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2055 b/results/classifier/deepseek-2-tmp/output/peripherals/2055
new file mode 100644
index 000000000..1e65ac565
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2073 b/results/classifier/deepseek-2-tmp/output/peripherals/2073
new file mode 100644
index 000000000..f2053bb6c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/213 b/results/classifier/deepseek-2-tmp/output/peripherals/213
new file mode 100644
index 000000000..96be28d58
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/213
@@ -0,0 +1,2 @@
+
+memory writes via gdb don't work for memory mapped hardware
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2139 b/results/classifier/deepseek-2-tmp/output/peripherals/2139
new file mode 100644
index 000000000..79a405e9e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2158 b/results/classifier/deepseek-2-tmp/output/peripherals/2158
new file mode 100644
index 000000000..5fe6a98e4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2158
@@ -0,0 +1,10 @@
+
+Qemu will not release mouse even after using the release mouse keybind
+Description of problem:
+There wasn't a crash but this is an annoying problem. The mouse does not release when the VM sizes the window larger because, as far as I know, qemu moves the window and relies on the user to click to release the mouse.
+Steps to reproduce:
+1. Open qemu 
+2. Try to release the mouse using the keybind shown.
+3. It move the window and won't release.
+Additional information:
+In case it's really needed, I am using a custom QEMU VM Manager called "QEMU Manager".
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2160 b/results/classifier/deepseek-2-tmp/output/peripherals/2160
new file mode 100644
index 000000000..cf503e8ab
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2160
@@ -0,0 +1,2 @@
+
+msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-libusb"
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2167 b/results/classifier/deepseek-2-tmp/output/peripherals/2167
new file mode 100644
index 000000000..91b9e505a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/220 b/results/classifier/deepseek-2-tmp/output/peripherals/220
new file mode 100644
index 000000000..8166dc499
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/220
@@ -0,0 +1,2 @@
+
+Broken mouse movement inside MS-DOS for at least one program
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2243 b/results/classifier/deepseek-2-tmp/output/peripherals/2243
new file mode 100644
index 000000000..134f6f82d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2293 b/results/classifier/deepseek-2-tmp/output/peripherals/2293
new file mode 100644
index 000000000..319a47d0f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2293
@@ -0,0 +1,36 @@
+
+[u2f-passthru]: pamu2fcfg command will stuck forever in Guest OS of Qemu
+Description of problem:
+To use FIDO2 user verification we need to run `pamu2fcfg` command which will stuck forever in Guest OS of Qemu 
+
+Passing `-usb -device u2f-passthru,hidraw=/dev/hidraw2` for U2F-Passthrough
+Steps to reproduce:
+1. Make you have have plugged Yubikey.
+2. In Guest shell install package using following command `sudo apt-get install pamu2fcfg`
+3. Run $`pamu2fcfg` command will stuck forever.
+
+**Note:** If I run `pamu2fcfg` in my Ubuntu Host environment it works fine.
+Additional information:
+**lsusb output:**
+
+**$lusb**
+
+Bus 001 Device 002: ID 46f4:0005 **QEMU U2F USB key**
+
+Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+
+**Debug Details:**
+
+When pamu2fcfg was launched following will be the call flow.
+
+[u2f_key_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251") → [recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204") → [u2f_passthru_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332") → [u2f_passthru_read](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305") → [u2f_passthru_recv_from_host](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329") →[ u2f_transaction_get_from_nonce](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272") → [u2f_send_to_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302") →[ u2f_pending_in_add](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207") → [main_loop_wait](https://github.com/qemu/qemu/blob/master/system/runstate.c#L783 "https://github.com/qemu/qemu/blob/master/system/runstate.c#L783") (stuck here)
+
+From above call flow looks like guest is waiting for key.
+
+Even I have tried enabling U2F support flag in Qemu while building but that one was not helping either.
+
+**References:**
+
+https://github.com/Yubico/pam-u2f/tree/main
+
+https://www.qemu.org/docs/master/system/devices/usb-u2f.html
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2307 b/results/classifier/deepseek-2-tmp/output/peripherals/2307
new file mode 100644
index 000000000..95d5e6503
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2307
@@ -0,0 +1,40 @@
+
+QEMU Windows COM port filenames not recognized i.e. \\.\COM19 or \\.\CNCA0
+Steps to reproduce:
+1. Run qemu-system-arm with the comand line above.
+2. QEMU fails with `qemu-system-arm.exe: -gdb \\.\CNCA8: '\\.\CNCA8' is not a valid char driver`
+3. ```qemu-system-arm.exe -machine mps2-an500 -gdb \\.\COM19
+qemu-system-arm.exe: -gdb \\.\COM19: '\\.\COM19' is not a valid char driver
+```
+Additional information:
+Windows allows COM ports numbered 10 and higher to be prefixed with a `\\.\` escape as in `\\.\COM17`. Such COM port assignments are not uncommon when a plurality of USB serial adapters.
+Equally problematic are virtual COM port designations such as `\\.\CNCA8` created by the Windows 10x64 driver package known as `com0com`: https://pete.akeo.ie/2011/07/com0com-signed-drivers.html
+
+Upon checking the source pulled from the Github mirror an initial fix was to simply modify /chardev/char.c, but this appears insufficient. Sadly.
+
+Please ask if more information is required. I am actively working on extending an existing QEMU machine emulation. A patch to fix this problem is below. Please comment if applicable.
+
+Jerry.
+
+```
+diff --git a/chardev/char.c b/chardev/char.c
+index 3c43fb1278..7a3f342c72 100644
+--- a/chardev/char.c
++++ b/chardev/char.c
+@@ -418,6 +418,13 @@ QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename,
+         qemu_opt_set(opts, "path", filename, &error_abort);
+         return opts;
+     }
++       // JME
++    if (strstart(filename, "\\\\.\\", NULL)) {
++        qemu_opt_set(opts, "backend", "serial", &error_abort);
++        qemu_opt_set(opts, "path", filename, &error_abort);
++        return opts;
++    }
++
+     if (strstart(filename, "file:", &p)) {
+         qemu_opt_set(opts, "backend", "file", &error_abort);
+         qemu_opt_set(opts, "path", p, &error_abort);
+
+```
+/label ~"kind::Bug"
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2347 b/results/classifier/deepseek-2-tmp/output/peripherals/2347
new file mode 100644
index 000000000..72d44864c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2349 b/results/classifier/deepseek-2-tmp/output/peripherals/2349
new file mode 100644
index 000000000..101f8336c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/242 b/results/classifier/deepseek-2-tmp/output/peripherals/242
new file mode 100644
index 000000000..61edb260f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/242
@@ -0,0 +1,2 @@
+
+Implementation of Virtual Battery for Battery Status
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2660 b/results/classifier/deepseek-2-tmp/output/peripherals/2660
new file mode 100644
index 000000000..968b0c450
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2660
@@ -0,0 +1,2 @@
+
+EDK2 subhook submodule missing
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2774 b/results/classifier/deepseek-2-tmp/output/peripherals/2774
new file mode 100644
index 000000000..b275016ff
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2774
@@ -0,0 +1,4 @@
+
+Consider adding an `aliases` node to RISC-V DTB that includes `serial0` alias
+Additional information:
+Example of an [aliases section for physical SoC](https://github.com/torvalds/linux/blob/b62cef9a5c673f1b8083159f5dc03c1c5daced2f/arch/riscv/boot/dts/sophgo/cv1800b-milkv-duo.dts#L14-L20).
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2788 b/results/classifier/deepseek-2-tmp/output/peripherals/2788
new file mode 100644
index 000000000..1c8883c42
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2888 b/results/classifier/deepseek-2-tmp/output/peripherals/2888
new file mode 100644
index 000000000..a481b3b9c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/292 b/results/classifier/deepseek-2-tmp/output/peripherals/292
new file mode 100644
index 000000000..63a70921e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/292
@@ -0,0 +1,2 @@
+
+keyboard errors in DOS, found links to similar errors for reference
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/2923 b/results/classifier/deepseek-2-tmp/output/peripherals/2923
new file mode 100644
index 000000000..7fb7bda21
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/2926 b/results/classifier/deepseek-2-tmp/output/peripherals/2926
new file mode 100644
index 000000000..974180844
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/2926
@@ -0,0 +1,37 @@
+
+Excessive memory allocation on guest and host with gpu passthrough
+Description of problem:
+While gpu passthrough is enabled, the maximum amount of ram is allocated on the host (64 GB), even if the guest only has 8 GB configured as "currently allocated".
+If I disable the physical gpu, the guest only takes the 8 GB.
+Steps to reproduce:
+1. Install qemu-kvm virt-manager libvirt-daemon-system virtinst libvirt-clients and bridge-utils.
+1. Create a Windows vm with virt-manager
+1. Insert discrete GPU on a secondary pcie slot.
+1. Add `intel_iommu=on iommu=pt vfio-pci.ids=10de:17c8,10de:0fb0` to the GRUB kernel parameters.
+1. Add `options vfio-pci ids=10de:17c8,10de:0fb0` and `softdep nvidia pre: vfio-pci` to `/etc/modprobe.d/vfio.conf`.
+1. Update initrmfs image.
+1. Add pcie hardware on virt-manager.
+1. Install virtio and nvidia drivers on guest.
+Additional information:
+I'm using an Nvidia gtx 980Ti on a secondary slot for the guest.
+The first slot has an rtx 4090 used by the host.
+
+```
+OS: Linux Mint 22.1 x86_64 
+Host: MS-7E07 2.0 
+Kernel: 6.8.0-51-generic 
+Shell: bash 5.2.21 
+Resolution: 3840x2160, 3840x2160 
+DE: Cinnamon 6.4.8 
+WM: Mutter (Muffin) 
+Terminal: gnome-terminal 
+CPU: Intel i9-14900K (32) @ 5.700GHz 
+GPU: NVIDIA GeForce GTX 980 Ti 
+GPU: NVIDIA GeForce RTX 4090 
+GPU: Intel Raptor Lake-S GT1 [UHD Graphics 770] 
+Memory: 73717MiB / 96317MiB 
+```
+
+[vWin.xml](/uploads/3fe8133f67577f8724b060908b390c32/vWin.xml)
+[vWin.log](/uploads/efa029460a62b62cbcff464af7cdb72a/vWin.log)
+![Screenshot_from_2025-04-19_02-34-37](/uploads/0245ed4bf2dee96fcf396ef899ac2c2b/Screenshot_from_2025-04-19_02-34-37.png)
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/294 b/results/classifier/deepseek-2-tmp/output/peripherals/294
new file mode 100644
index 000000000..f354afa10
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/294
@@ -0,0 +1,2 @@
+
+Keyboard keys get stuck
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/316 b/results/classifier/deepseek-2-tmp/output/peripherals/316
new file mode 100644
index 000000000..5504a846b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/316
@@ -0,0 +1,2 @@
+
+[feature request] webcam support
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/338 b/results/classifier/deepseek-2-tmp/output/peripherals/338
new file mode 100644
index 000000000..96f240a98
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/338
@@ -0,0 +1,2 @@
+
+QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/349 b/results/classifier/deepseek-2-tmp/output/peripherals/349
new file mode 100644
index 000000000..c4fd6378f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/349
@@ -0,0 +1,2 @@
+
+USB folder sharing causing segment fault
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/357 b/results/classifier/deepseek-2-tmp/output/peripherals/357
new file mode 100644
index 000000000..f2e0d9500
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/431 b/results/classifier/deepseek-2-tmp/output/peripherals/431
new file mode 100644
index 000000000..3b0230e2e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/431
@@ -0,0 +1,2 @@
+
+USB passthrough in Windows Host non functional
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/441672 b/results/classifier/deepseek-2-tmp/output/peripherals/441672
new file mode 100644
index 000000000..e45174393
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/441672
@@ -0,0 +1,13 @@
+
+Windos XP BSOD with HP Photosmart usb device attached
+
+https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details of the problem.
+
+I was just testing attaching a USB device to see if it really worked, and tried my HP Photosmart C5580 All-in-One
+printer/scanner, and the Windows XP box then started getting bluescreens and crashing at random
+(fairly short :-) intervals.
+
+My latest attempt was on a fedora rawhide system with pretty up to date software
+(qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen.
+
+A reply to that bugzilla recommended adding this upstream bug, so here it is.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/445 b/results/classifier/deepseek-2-tmp/output/peripherals/445
new file mode 100644
index 000000000..e6bec8f69
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/445
@@ -0,0 +1,2 @@
+
+QEMU + DOS keyboard behavior
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/446 b/results/classifier/deepseek-2-tmp/output/peripherals/446
new file mode 100644
index 000000000..9f06f0e9f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/446
@@ -0,0 +1,2 @@
+
+usb-audio does not work with Mac OS
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/495 b/results/classifier/deepseek-2-tmp/output/peripherals/495
new file mode 100644
index 000000000..b666ab15f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/495
@@ -0,0 +1,2 @@
+
+sdhci: Another way to trigger Assertion wpnum < sd->wpgrps_size failed
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/500 b/results/classifier/deepseek-2-tmp/output/peripherals/500
new file mode 100644
index 000000000..2923de274
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/500
@@ -0,0 +1,2 @@
+
+6.1.0-rc0 Regression: Parameter 'audiodev' is missing
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/501 b/results/classifier/deepseek-2-tmp/output/peripherals/501
new file mode 100644
index 000000000..4b143ceea
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/501
@@ -0,0 +1,2 @@
+
+6.1.0-rc0 Regression: No keyboard input possible
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/521994 b/results/classifier/deepseek-2-tmp/output/peripherals/521994
new file mode 100644
index 000000000..b768a2581
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/532 b/results/classifier/deepseek-2-tmp/output/peripherals/532
new file mode 100644
index 000000000..2e802dedf
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/532
@@ -0,0 +1,2 @@
+
+USB-EHCI: Replace DMA processing in I/O handlers by asynchronous BH
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/533613 b/results/classifier/deepseek-2-tmp/output/peripherals/533613
new file mode 100644
index 000000000..a526b6c67
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/544 b/results/classifier/deepseek-2-tmp/output/peripherals/544
new file mode 100644
index 000000000..3e5c59740
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/544
@@ -0,0 +1,2 @@
+
+Assert xfer->packet.status != USB_RET_NAK in xhci
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/551 b/results/classifier/deepseek-2-tmp/output/peripherals/551
new file mode 100644
index 000000000..5e2514756
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/551
@@ -0,0 +1,2 @@
+
+Null-ptr dereference in megasas_command_complete
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/558 b/results/classifier/deepseek-2-tmp/output/peripherals/558
new file mode 100644
index 000000000..79515e781
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/558
@@ -0,0 +1,58 @@
+
+gtk UI interprets double/triple click as button release
+Description of problem:
+When using the GTK interface clicking rapidly in a down-up-down pattern, the final "down" event is erroneously followed by an immediate "up" event and the mouse device in the guest reports the pressed button as no longer being held.
+Steps to reproduce:
+1. Start a VM using the GTK interface.
+2. Open a tool to examine guest mouse input events, such as `xev` or `yutani-test`
+3. Click twice with any button, without releasing on the second click.
+4. Observe erroneous 'up' event in guest.
+5. Move the mouse while keeping the button pressed.
+6. Observe the guest reports the button is not held.
+Additional information:
+GTK 3 sends an additional `GDK_2BUTTON_PRESS` event after the initial `GDK_BUTTON_PRESS` event, which QEMU is misinterpreting as a release event. I confirmed this with the addition of some logging of `button->type` in `gd_button_event`:
+
+```
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4 # = PRESS
+button = 1, type = 5 # = 2BUTTON_PRESS
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+```
+
+```diff
+diff --git a/ui/gtk.c b/ui/gtk.c
+index cfb0728d1f..b9979f0e11 100644
+--- a/ui/gtk.c
++++ b/ui/gtk.c
+@@ -925,6 +925,13 @@ static gboolean gd_button_event(GtkWidget *widget, GdkEventButton *button,
+         return TRUE;
+     }
+ 
++    /* ignore additional events for double- and triple- press, as they are
++     * sent to us after a regular press event; otherwise we will misinterpret
++     * these as release events and eat the button! */
++    if (button->type == GDK_2BUTTON_PRESS || button->type == GDK_3BUTTON_PRESS) {
++        return TRUE;
++    }
++
+     qemu_input_queue_btn(vc->gfx.dcl.con, btn,
+                          button->type == GDK_BUTTON_PRESS);
+     qemu_input_event_sync();
+```
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/569 b/results/classifier/deepseek-2-tmp/output/peripherals/569
new file mode 100644
index 000000000..4c85e0416
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/569
@@ -0,0 +1,2 @@
+
+ESP SCSI adapter not working with DOS ASPI drivers
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/612297 b/results/classifier/deepseek-2-tmp/output/peripherals/612297
new file mode 100644
index 000000000..af1f793da
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/617 b/results/classifier/deepseek-2-tmp/output/peripherals/617
new file mode 100644
index 000000000..76256aaba
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/617
@@ -0,0 +1,27 @@
+
+USB passthrough with Conbee 2 failing after upgrade to Fedora 34 / Libvirt 7.0.0
+Description of problem:
+Hi,
+
+I upgraded recently from Fedora 32 to 34.
+
+For a little under a year, I've been running reliably a Home Assistant instance with Deconz add-on in a VM, with a Conbee 2 zigbee gateway in USB passthrough, controlling about 15 devices (door/window sensors, thermometers, leak sensors and push buttons).
+
+It has worked flawlessly but stopped working after upgrading Fedora. The Conbee shows up on the Linux guest but the serial can't be read by the Deconz application and it just does not work, the app can't get past the device connection screen.
+
+This is the state of what works and what doesn't:
+
+- Home Assistant Linux VM: NOK
+- Ubuntu Linux 20.04 VM: NOK
+- Windows 10 VM: NOK
+- Windows 10 physical machine: OK, can connect and pair a door sensor
+
+All running the latest Deconz app.
+
+The fact that the physical Windows machine works excludes a bricked device. I used the physical Windows to upgrade the Conbee 2 firmware with no improvement. 
+
+This does not seem to be an isolated issue: https://old.reddit.com/r/homeassistant/comments/o04sgw/conbee_ii_usb_passthrough_with_libvirt_660/
+
+Apologies if this has already been reported. Let me know what kind of logs you might want.
+
+Thanks!
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/646 b/results/classifier/deepseek-2-tmp/output/peripherals/646
new file mode 100644
index 000000000..87ac7b5a1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/646
@@ -0,0 +1,19 @@
+
+Infinite loop in xhci_ring_chain_length() in hw/usb/hcd-xhci.c (CVE-2020-14394)
+Description of problem:
+An infinite loop issue was found in the USB xHCI controller emulation of QEMU. Specifically, function `xhci_ring_chain_length()` in hw/usb/hcd-xhci.c may get stuck while fetching empty TRBs from guest memory, since the exit conditions of the loop depend on values that are fully controlled by guest. A privileged guest user may exploit this issue to hang the QEMU process on the host, resulting in a denial of service.
+Steps to reproduce:
+Build and load `xhci.ko` from within the guest:
+
+1) make
+2) insmod xhci.ko
+
+[Makefile](/uploads/98dbf7b4facc9b100817b3c8f63b5cb2/Makefile)
+
+[usb-xhci.h](/uploads/f225524b1553d8cf6c1dfa89369b6edc/usb-xhci.h)
+
+[xhci.c](/uploads/c635f742d12a2bba6ea472ddfe006d56/xhci.c)
+Additional information:
+This issue was reported by Gaoning Pan (Zhejiang University) and Xingwei Li (Ant Security Light-Year Lab).
+
+RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1908004.
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/657006 b/results/classifier/deepseek-2-tmp/output/peripherals/657006
new file mode 100644
index 000000000..cfc193af9
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/657006
@@ -0,0 +1,45 @@
+
+arm v7M - svc insn doesn't trigger PendSV handler
+
+The svc instruction doesn't work as expected.
+
+-> qemu 0.13.0 rc1 (git)
+
+Test : demo with freeRTOS (for example FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb.
+
+If we start the scheduler, it will call that function (__attribute__ (( naked ))) :
+
+void vPortStartFirstTask( void )
+
+{
+
+	__asm volatile(
+
+					" ldr r0, =0xE000ED08 	\n" /* Use the NVIC offset register to locate the stack. */
+
+					" ldr r0, [r0] 			\n"
+
+					" ldr r0, [r0] 			\n"
+
+					" msr msp, r0			\n" /* Set the msp back to the start of the stack. */
+
+					" svc 0					\n" /* System call to start first task. */
+
+				);
+
+}
+
+The 4 first lines in asm work fine. The scv 0 call will rise the right interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will never call the PendSV Handler (xPortPendSVHandler here). This function is recorded in the nvic vector.
+Next, (after the svc), the processor will execute the line after in code (this is a naked function) so the next function written after vPortStartFirstTask in the code.
+
+
+command line :
+console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S
+console 2 : arm-none-eabi-gdb -ex "target remote localhost:1234" gcc/RTOSDemo.axf
+
+arm-none-eabi from http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
+Same error with another project with arm-elf
+
+processor : arm cortex m3
+
+host : gentoo (2.6.35-r9) (without kqemu)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/658152 b/results/classifier/deepseek-2-tmp/output/peripherals/658152
new file mode 100644
index 000000000..483161849
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/667 b/results/classifier/deepseek-2-tmp/output/peripherals/667
new file mode 100644
index 000000000..4270d5fca
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/667
@@ -0,0 +1,2 @@
+
+Wacom EMR pen pressure support
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/686613 b/results/classifier/deepseek-2-tmp/output/peripherals/686613
new file mode 100644
index 000000000..00d2786a4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/686613
@@ -0,0 +1,6 @@
+
+USB MSD are not marked as removable
+
+ Filed from Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=589130
+
+Guests can access USB Mass Storage Device, but fail to mark them as removable.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/687 b/results/classifier/deepseek-2-tmp/output/peripherals/687
new file mode 100644
index 000000000..593309bce
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/687
@@ -0,0 +1,2 @@
+
+what is the DMAR?
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/688052 b/results/classifier/deepseek-2-tmp/output/peripherals/688052
new file mode 100644
index 000000000..39d9eeeb1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/69 b/results/classifier/deepseek-2-tmp/output/peripherals/69
new file mode 100644
index 000000000..8c8df439f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/69
@@ -0,0 +1,2 @@
+
+ALSA underruns occurr when using QEMU
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/696094 b/results/classifier/deepseek-2-tmp/output/peripherals/696094
new file mode 100644
index 000000000..1c101eb8d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/696094
@@ -0,0 +1,39 @@
+
+TI Stellaris lm3s811evb (ARM Cortex-M3) : Systick interrupt not working
+
+I've tried to create a small project that uses the CMSIS as base library.
+The problem is that the SysTick_interrupt_handler() doesn't get executed when the systick event is detected in QEMU. Furthermore, it seems asif QEMU gets stuck in an endless loop. QEMU doesn't respond to Ctrl-C on the command line and the GDB session also stalls. 'kill -9' is the only way to stop QEMU.
+
+It seems asif the initialisation of the NVIC works fine. I've traced the function calls in QEMU as follows:
+stellaris.c: stellaris_init() - Perform generic armv7 init: armv7m_init()
+   armv7m.c: armv7m_init() - Create and init the nvic:
+                               nvic = qdev_create(NULL, "armv7m_nvic");
+                               env->nvic = nvic;
+                               qdev_init_nofail(nvic);
+                           - Configure the programmable interrupt controller:
+                               Call: arm_pic_init_cpu() 
+                                        qemu_allocate_irqs(arm_pic_cpu_handler)
+                           - Initialise 64 interrupt structures.
+
+The following call sequence is observed when the systick event occur:
+armv7m_nvic.c: systick_timer_tick(): set pending interrupt
+armv7m_nvic.c: armv7m_nvic_set_pending() for irq:15
+  arm_gic.c: gic_set_pending_private(): GIC_SET_PENDING(15,)
+    arm_gic.c: gic_update() - Raise IRQ with qemu_set_irq()
+       irq.c: eqmu_set_irq() - Call the irq->handler 
+                               -- I assume the irq handler is 'arm_pic_cpu_handler()',
+                                  since that was passed as the parameter when
+                                  qemu_allocate_irqs() was called in ...
+          arm_pic.c: arm_pic_cpu_handler() - After evaluation, call cpu_interrupt()
+             exec.c: cpu_interrupt() is called.     
+
+The tools that were used during the testing of this project:
+  GCC: Codesourcery ARM eabi 2010q3
+  QEMU: Checked out on 31/12/2010 - Last commit: 0fcec41eec0432c77645b4a407d3a3e030c4abc4
+The project files are attached, for reproducing of the errors.
+   Note: The CMSIS wants to perform byte accesses to the NVIC. For the Cortex-M3, unaligned 8 bit and 16 bit accesses are allowed. The current QEMU implementation doesn't yet cater for it. As a work around, updated versions of
+arm_gic.c armv7m_nvic.h armv7m_nvic.c is also included.
+
+Launch project with: go_gdb.sh
+Attach debugger with: arm-none-eabi-gdbtui --command=gdbCommands_tui
+(s = step, n = next, c = continue, Ctrl-C = stop, print <variable> to look at variable contents)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/704 b/results/classifier/deepseek-2-tmp/output/peripherals/704
new file mode 100644
index 000000000..e17d52ad5
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/704
@@ -0,0 +1,2 @@
+
+linux-user: misaligned address for type 'struct linux_dirent64'
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/717929 b/results/classifier/deepseek-2-tmp/output/peripherals/717929
new file mode 100644
index 000000000..41e7898c8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/717929
@@ -0,0 +1,24 @@
+
+Serial communication between VMs problematic
+
+Hello,
+
+I want to setup serial communication between VM hosts but I have found it quite difficult...:
+
+...because when trying unix sockets:
+
+- host A has serial device as unix socket (bind)
+- host B has serial device as client of unix socket
+- host A is down thus not unix socket does exist
+- host B can't be started because cannot read the socket:
+
+error: Failed to start domain opd1s02
+error: internal error Process exited while reading console log output: char device redirected to /dev/pts/0
+connect(unix:/tmp/test.sock): Connection refused
+chardev: opening backend "socket" failed
+
+Can that work like the cable is not plugged in? So host B can start and when the socket would exist it would connect to it?
+
+...and when using pty and host device combination one cannot predict pty device under /dev/pts, it would be nice if would be possible to define exact device name.
+
+Tested on Fedora 14.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/72 b/results/classifier/deepseek-2-tmp/output/peripherals/72
new file mode 100644
index 000000000..b57ef8c09
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/72
@@ -0,0 +1,2 @@
+
+mouse offset or invisible wall 2.11.0-3
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/732155 b/results/classifier/deepseek-2-tmp/output/peripherals/732155
new file mode 100644
index 000000000..c874a2dbc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/732155
@@ -0,0 +1,95 @@
+
+system_reset doesn't work with qemu-kvm and latest SeaBIOS
+
+I've built qemu-kvm and seabios from the latest git sources, and found that the system_reset monitor command causes a freeze if I start qemu-system-x86_64 with the -no-kvm flag.  This is a serial log from an attempt at rebooting:
+
+$ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -bios ../seabios/out/bios.bin -serial /dev/stdout -no-kvm
+QEMU 0.14.50 monitor - type 'help' for more information
+(qemu) Changing serial settings was 0/0 now 3/0
+Start bios (version pre-0.6.3-20110309_171929-desk4)
+Ram Size=0x08000000 (0x0000000000000000 high)
+CPU Mhz=2202
+PCI: pci_bios_init_bus_rec bus = 0x0
+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: 0xf0000000
+region 1: 0xf2000000
+region 6: 0xf2010000
+PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139
+region 0: 0x0000c100
+region 1: 0xf2020000
+region 6: 0xf2030000
+Found 1 cpu(s) max supported 1 cpu(s)
+MP table addr=0x000fdb40 MPC table addr=0x000fdb50 size=224
+SMBIOS ptr=0x000fdb20 table=0x07fffef0
+ACPI tables: RSDP=0x000fdaf0 RSDT=0x07ffd6a0
+Scan for VGA option rom
+Running option rom at c000:0003
+Turning on vga text mode console
+SeaBIOS (version pre-0.6.3-20110309_171929-desk4)
+
+PS2 keyboard initialized
+Found 1 lpt ports
+Found 1 serial ports
+ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9)
+ATA controller 1 at 170/374/0 (irq 15 dev 9)
+DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
+Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
+Scan for option roms
+Running option rom at c900:0003
+pnp call arg1=60
+pmm call arg1=0
+pmm call arg1=2
+pmm call arg1=0
+Searching bootorder for: /pci@i0cf8/*@3
+Searching bootorder for: /rom@genroms/vapic.bin
+Running option rom at c980:0003
+ebda moved from 9fc00 to 9f400
+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 DVD/CD...
+Device reports MEDIUM NOT PRESENT
+atapi_is_ready returned -1
+Boot failed: Could not read from CDROM (code 0003)
+enter handle_18:
+  NULL
+Booting from ROM...
+Booting from c900:0336
+
+(qemu) 
+(qemu) system_reset
+(qemu) RESET REQUESTEDChanging serial settings was 0/0 now 3/0
+Start bios (version pre-0.6.3-20110309_171929-desk4)
+Attempting a hard reboot
+prep_reset
+apm_shutdown?
+i8042_reboot
+i8042: wait to write...
+i8042: outb
+RESET REQUESTED
+(qemu) 
+(qemu) 
+(qemu) 
+(qemu) info cpus
+* CPU #0: pc=0x00000000fffffff0 thread_id=18125 
+(qemu) system_reset
+(qemu) RESET REQUESTED
+(qemu) 
+(qemu) q
+
+I've tried fiddling a few build options in SeaBIOS but I'm not sure that's where the issue lies.  The RESET REQUESTED is me adding some extra debug to vl.c:1477 in the clause that tests for a reset request, and the i8042: lines are debug lines from seabios tracing the execution of the reset request.
+
+This may be a bug in SeaBIOS of course, since I can replicate the behaviour on my distro's qemu and kvm packages.  However it seems odd that qemu behaves differently with KVM turned on (i.e. system_reset works) than with it disabled.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/757654 b/results/classifier/deepseek-2-tmp/output/peripherals/757654
new file mode 100644
index 000000000..1ecd9b377
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/757654
@@ -0,0 +1,16 @@
+
+UHCI fails to signal stall response
+
+When TD execution results in STALL error (STALL handshake, no stall as a result of err count reaching 0), there is no way to know about it except for checking that TD. IMO it is an error condition and it should be reflected in the status register (and issue an interrupt if enabled).
+
+Ways to replicate:
+Send a query that is answered by stall (like set_idle request to a mouse)
+
+Expected behavior:
+UHCI hc sets status bit 1 (usb error interrupt) and issues an interrupt
+
+current behavior:
+Neither status bit is set nor interrupt triggered
+
+Version 0.14
+attached patch for current master (quick fix, it might be I got something wrong)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/79 b/results/classifier/deepseek-2-tmp/output/peripherals/79
new file mode 100644
index 000000000..57eef989e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/79
@@ -0,0 +1,2 @@
+
+support horisontal mouse wheel
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/827 b/results/classifier/deepseek-2-tmp/output/peripherals/827
new file mode 100644
index 000000000..171d4ac9c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/827
@@ -0,0 +1,2 @@
+
+Stack-overflow through virtio_blk_get_request
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/873460 b/results/classifier/deepseek-2-tmp/output/peripherals/873460
new file mode 100644
index 000000000..170e9b2c4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/peripherals/894037 b/results/classifier/deepseek-2-tmp/output/peripherals/894037
new file mode 100644
index 000000000..a94d06bcd
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/894037
@@ -0,0 +1,16 @@
+
+With VNC, "-usbdevice tablet" no longer makes mouse pointers line up
+
+I use qemu in VNC mode.  In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option.  This no longer works, and it behaves the same as if the option is not there.  This makes my VMs unusable to me.
+
+Here's how I'm booting WinXP:
+
+qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm &
+
+The Windows install hasn't changed, only qemu.
+
+I'm running this version of QEMU:
+
+QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard
+
+I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/906864 b/results/classifier/deepseek-2-tmp/output/peripherals/906864
new file mode 100644
index 000000000..487b2aa57
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/906864
@@ -0,0 +1,16 @@
+
+Always mouse grabbing with -usbdevice tablet
+
+version: QEMU emulator version 1.0 (qemu-kvm 1.0)
+             QEMU emulator version 1.0 (qemu 1.0)
+             (source builds)
+os: archlinux x86-64
+last working version: qemu-kvm 0.15.1
+
+commandline: each with "-usb -usbdevice tablet" and sdl output 
+
+expected behavior:  mouse gets grabbed only by forcing it (pressing release/grab-combination (CTRL-ALT))
+
+actual behavior:
+When moving the mouse over the window it gets instantly grabbed, so i cannot use window-manager-specific hotkeys anymore.  After pressing the release combination every mouse movement over or within the window will grab the mouse again. 
+I have tried this with several vga types and window managers: no difference
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/93 b/results/classifier/deepseek-2-tmp/output/peripherals/93
new file mode 100644
index 000000000..b6694f663
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/93
@@ -0,0 +1,2 @@
+
+qemu 1.4.2: usb keyboard not fully working
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/959852 b/results/classifier/deepseek-2-tmp/output/peripherals/959852
new file mode 100644
index 000000000..1090ba691
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/959852
@@ -0,0 +1,30 @@
+
+Build fails: osx 10.7, deprecated CoreAudio APIs
+
+Virtual audio driver for darwin is using deprecated APIs.
+
+○ → ./configure --cc=/usr/bin/gcc --disable-darwin-user --disable-bsd-user --disable-guest-agent
+
+
+○ → make 
+.
+.
+.
+  CC    audio/noaudio.o
+  CC    audio/wavaudio.o
+  CC    audio/mixeng.o
+  CC    audio/coreaudio.o
+audio/coreaudio.c: In function ‘isPlaying’:
+audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640)
+audio/coreaudio.c: In function ‘coreaudio_init_out’:
+audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270)
+audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640)
+audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675)
+audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640)
+audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640)
+audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675)
+audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419)
+audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433)
+audio/coreaudio.c: In function ‘coreaudio_fini_out’:
+audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433)
+  CC    audio/wavcapture.o
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/985288 b/results/classifier/deepseek-2-tmp/output/peripherals/985288
new file mode 100644
index 000000000..fb599cc19
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/985288
@@ -0,0 +1,4 @@
+
+scsi disk emulation doesn't enforce FUA (Force Unit Access) in write-back mode
+
+Microsoft NTFS utilizes the FUA bit in SCSI WRITE CDBs to insure integrity when a device advertises that it has write caching enabled.  The FUA bit is meant to ensure a write is written to non-volatile storage before returning.  This seems to not be enforced by QEMU's SCSI emulation code.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/peripherals/989504 b/results/classifier/deepseek-2-tmp/output/peripherals/989504
new file mode 100644
index 000000000..abe0d2885
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/peripherals/989504
@@ -0,0 +1,24 @@
+
+assertion failed when attaching USB MSD device
+
+version: git rev be5ea8ed4481f0ffa4ea0f7ba13e465701536001
+commandline: qemu-system-i386 -usb -fda dosusb.img -drive if=none,id=usbstick,file=usb.img -device usb-storage,bus=usb.0,drive=usbstick -boot a -L d:\_programs\qemu
+
+---------------------------
+Microsoft Visual C++ Runtime Library
+---------------------------
+Assertion failed!
+
+Program: E:\qemu-system-i386.exe
+File: C:/msys/home/User/qemu/hw/usb/hcd-uhci.c
+Line: 968
+
+Expression: ret == TD_RESULT_ASYNC_START
+
+For information on how your program can cause an assertion
+failure, see the Visual C++ documentation on asserts
+
+(Press Retry to debug the application - JIT must be enabled)
+---------------------------
+Abort   Retry   Ignore   
+---------------------------
\ No newline at end of file