summary refs log tree commit diff stats
path: root/results/classifier/deepseek-2-tmp/output/network
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
commitd0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
treef8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/deepseek-2-tmp/output/network
parent7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
downloademulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz
emulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip
add deepseek and gemma results
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/network')
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/101079
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/10104847
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/103636340
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/105082318
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/105418017
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/106177810
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/106605520
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/106711910
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/107971376
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1112
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/111928136
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/115891247
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/11714
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/11763666
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/11797314
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/118077747
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/118531127
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/11873349
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/11892
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/11924646
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/119642646
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/119672754
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/119677312
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/120228977
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/12131964
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/122179723
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/122828530
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/12532
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/126145080
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/127225225
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/12862
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/128625312
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/128862018
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/12969
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/12968826
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1297487169
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/12977819
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/129956612
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/131212
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/13152
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/132698613
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/133717
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/136525
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/138163916
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/138489221
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/13852
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/138873512
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/139521741
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/140228911
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/140275564
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/140427811
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/141446645
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/142423746
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/142639
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/14388
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/144144334
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/145106736
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/146191819
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/146390962
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/146724025
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/146994640
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/147072017
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/148199040
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/148690
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/14953808
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/150209539
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/151323412
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/152821438
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1532
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15429656
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15432
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/154316339
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15442
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/154510
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/154505259
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/154644522
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/155445115
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/155630625
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15602
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15699888
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15732
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/157432717
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15795
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/158169519
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/158378421
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15842
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/158543211
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/158675653
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15885917
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1592
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/15938
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/160430312
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/16129088
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/161792951
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/162659616
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/162897158
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1640525109
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/164242166
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/164361933
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/165692718
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/165926710
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1662
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/166260029
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/166827365
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/16729
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/167372214
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/168268112
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/168308412
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/168721416
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/168757815
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/168759924
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/169618020
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/169674616
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/170279823
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/17031479
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/170861730
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/171160228
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/171332810
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/172195217
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/172316132
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/172447720
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/17245906
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/17324
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/173665521
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/174400915
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/174589530
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/175454269
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/175460515
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/175809116
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/176102714
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/177041731
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/17772
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/177944713
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/17834
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/178750514
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/179168021
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/179379118
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/18094538
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/181153332
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/181435224
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/181438126
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/181888031
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/181910831
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/182345842
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/182379022
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/182462211
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/183519
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/183709415
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/183765116
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/183790934
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/183822819
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/183936734
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/184064612
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/184359024
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/184855611
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/185312334
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/185553543
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/18560278
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/185722612
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/18578118
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/185841525
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/186187520
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/186188422
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/186297916
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/186309667
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/187033144
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/187453920
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/18746769
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/187701510
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/187959037
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188116
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188224121
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188618
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188628510
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188681124
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188760429
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188846713
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/188994348
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/189015539
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/189015736
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/189015940
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/189016035
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/189268425
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/189478120
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/1902
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/19034934
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/190448632
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/190495414
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/191082665
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/191396924
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/191411716
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/191634425
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/191716111
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/191850
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/192087152
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/192210248
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/192460352
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/192544938
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/192649725
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/193712
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/194913
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/195721
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/197538
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/19842
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/20282
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/205853
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/20952
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/212515
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/21282
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/21292
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/214423
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/21762
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/2182
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/21822
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/218915
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/21912
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/219759
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/22392
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/22532
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/236264
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/23642
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/237012
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/24012
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/24092
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/241093
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/24442
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/2482
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/24942
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/252810
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/258417
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/26232
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/26882
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/269021
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/274068
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/274267
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/274527
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/27462
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/275824
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/276738
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/2772
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/278018
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/2822
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/28272
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/282922
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/284919
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/287615
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/2912
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/293465
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/295122
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/296223
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3082
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3232
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3352
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3472
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3482
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3542
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/3772
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/4022
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/4282
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/45361754
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/4602
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/47496837
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/48525022
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/48525829
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/49556622
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5172
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5332
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5342
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5352
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5392
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/54663855
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5572
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/56210713
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/58018
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/58873129
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/58931519
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/58982715
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/59055217
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/5938
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/59735131
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/59757533
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/60233680
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/60516
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/61495838
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/63609543
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/63895533
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/64111811
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/64346521
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/6589046
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/67602919
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/6769349
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/6917
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/72213
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/7412
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/76146912
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/7614716
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/77416
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/785668167
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/80858850
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/82945517
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/83343
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/8389744
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/84560
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/88801619
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/89914025
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/9033654
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/9078
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/9122
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/91672011
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/93560
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/935945153
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/93894524
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/95409915
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/9762
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/9844766
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/98560
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/98812829
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/98890917
-rw-r--r--results/classifier/deepseek-2-tmp/output/network/9997
319 files changed, 0 insertions, 7407 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/network/1010 b/results/classifier/deepseek-2-tmp/output/network/1010
deleted file mode 100644
index 111ea478..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1010
+++ /dev/null
@@ -1,79 +0,0 @@
-
-Errors on 9p mounts
-Description of problem:
-I'm trying to run Docker VMs with [Lima](https://github.com/lima-vm/lima), which uses QEMU. I'm trying to expose my home directory on macOS to the Ubuntu VM using `9p`. This is how the mount point looks like inside the Ubuntu VM:
-
-```
-root@lima-docker:~# mount | grep Users
-mount0 on /Users/carlos type 9p (rw,relatime,dirsync,fscache,cachetag=4294894070,access=user,trans=virtio,version=9p2000.u)
-root@lima-docker:~#
-```
-
-The problem I'm seeing is that doing an `ls -l /Users/carlos` gives a "Timer expired" error, and no output:
-
-```
-root@lima-docker:~# ls -l /Users/carlos
-ls: reading directory '/Users/carlos': Timer expired
-total 0
-```
-
-Under `strace`, it seems that the timer error is raised by the `getdents64` system call:
-
-```
-root@lima-docker:~# strace -f ls -l /Users/carlos
-[..]
-openat(AT_FDCWD, "/Users/carlos", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
-newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=1984, ...}, AT_EMPTY_PATH) = 0
-mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa16bf000
-getdents64(3, 0xffffa16bf040, 131072)   = -1 ETIME (Timer expired)
-[..]
-```
-
-I've also tried the `9p2000.L` protocol instead, and the results are a bit better. I do get a directory listing, but I see "xxx" errors:
-
-```
-root@lima-docker:~# ls -l /Users/carlos
-ls: /Users/carlos: Network dropped connection on reset
-ls: /Users/carlos/Music: Network dropped connection on reset
-ls: /Users/carlos/Pictures: Network dropped connection on reset
-ls: /Users/carlos/Desktop: Network dropped connection on reset
-ls: /Users/carlos/Library: Network dropped connection on reset
-ls: /Users/carlos/Public: Network dropped connection on reset
-ls: /Users/carlos/Movies: Network dropped connection on reset
-ls: /Users/carlos/Applications: Network dropped connection on reset
-ls: /Users/carlos/Dropbox: Network dropped connection on reset
-ls: /Users/carlos/Maildir: Network dropped connection on reset
-ls: /Users/carlos/Documents: Network dropped connection on reset
-ls: /Users/carlos/Downloads: Network dropped connection on reset
-total 0
-drwx------   5 carlos dialout  160 Dec  6 10:31  Applications
-drwx------   4 carlos dialout  128 Apr 28 14:40  Desktop
-drwx------  12 carlos dialout  384 Apr 30 08:44  Documents
-drwx------ 164 carlos dialout 5248 Apr 29 13:50  Downloads
-drwx------   8 carlos dialout  256 Sep  4  2021  Dropbox
-drwx------  82 carlos dialout 2624 Apr  8 14:05  Library
-drwxr-xr-x   3 carlos dialout   96 Nov 12 12:28  Maildir
-drwx------   4 carlos dialout  128 Jul 19  2021  Movies
-drwx------   4 carlos dialout  128 Aug 19  2021  Music
-drwx------   4 carlos dialout  128 Jul 19  2021  Pictures
-drwxr-xr-x   4 carlos dialout  128 Jul 19  2021  Public
-```
-
-The errors in this case seem to come from the `lgetxattr`system call:
-
-```
-root@lima-docker:~# strace -f ls -l /Users/carlos
-[..]
-statx(AT_FDCWD, "/Users/carlos/Downloads", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=5248, ...}) = 0
-lgetxattr("/Users/carlos/Downloads", "security.selinux", 0xaaaaec72da70, 255) = -1 ENETRESET (Network dropped connection on reset)
-write(2, "ls: ", 4ls: )                     = 4
-write(2, "/Users/carlos/Downloads", 23/Users/carlos/Downloads) = 23
-write(2, ": Network dropped connection on "..., 37: Network dropped connection on reset) = 37
-[..]
-```
-
-I've reported this to the Lima folks at https://github.com/lima-vm/lima/issues/831, and they suggested opening an issue here. Any ideas?
-Steps to reproduce:
-1. If you have Lima installed (I'm using version 0.10.0): `limactl start --name=docker ./lima-templates/docker.yaml`
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/1010484 b/results/classifier/deepseek-2-tmp/output/network/1010484
deleted file mode 100644
index cd999165..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1010484
+++ /dev/null
@@ -1,7 +0,0 @@
-
-slirp to accept non-local dns server
-
-current version of slirp doesn't allow feeded dns address to be outside of given network.
-in many scenarios you need to provide dns server that isn't local.
-
-this simple patch removes checking for if dns server isn't in local subnet.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1036363 b/results/classifier/deepseek-2-tmp/output/network/1036363
deleted file mode 100644
index 2a825155..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1036363
+++ /dev/null
@@ -1,40 +0,0 @@
-
-Major network performance problems on AMD hardware
-
-Hi,
-
-I am experiencing some major performance problems with all of our beefy AMD Opteron 6274 servers running Fedora 17 (kernel 3.4.4-5.fc17.x86_64, qemu 1.0-17).  The network performance between host and the virtual machine is terrible:
-
-# iperf -c 10.10.11.22 -r
-------------------------------------------------------------
-Server listening on TCP port 5001
-TCP window size: 85.3 KByte (default)
-------------------------------------------------------------
-------------------------------------------------------------
-Client connecting to 10.10.11.22, TCP port 5001
-TCP window size:  197 KByte (default)
-------------------------------------------------------------
-[  5] local 10.10.11.199 port 44192 connected with 10.10.11.22 port 5001
-[ ID] Interval       Transfer     Bandwidth
-[  5]  0.0-10.0 sec  2.45 GBytes  2.11 Gbits/sec
-[  4] local 10.10.11.199 port 5001 connected with 10.10.11.22 port 42601
-[  4]  0.0-10.0 sec  8.97 GBytes  7.71 Gbits/sec
-
-So the VM's receive is super slow.  I would be happy with 7.71 Gbps because it's closer to matching the speed of the 10G ethernet adapters but the iSCSI drive's write performance is few times faster than read.  Now running a similar test on the slowest machine I have, Intel core i3 I see this:
-
-# iperf -c 192.168.7.60 -r
-------------------------------------------------------------
-Server listening on TCP port 5001
-TCP window size: 85.3 KByte (default)
-------------------------------------------------------------
-------------------------------------------------------------
-Client connecting to 192.168.7.60, TCP port 5001
-TCP window size:  306 KByte (default)
-------------------------------------------------------------
-[  5] local 192.168.7.98 port 53992 connected with 192.168.7.60 port 5001
-[ ID] Interval       Transfer     Bandwidth
-[  5]  0.0-10.0 sec  22.5 GBytes  19.3 Gbits/sec
-[  4] local 192.168.7.98 port 5001 connected with 192.168.7.60 port 53339
-[  4]  0.0-10.0 sec  25.1 GBytes  21.5 Gbits/sec
-
-As you can image this is a huge difference in network IO.  Most setups are identical down to the same versions.  Vhost-net is enabled and it appears to use MSI-X on the VM.  I've tried all kinds of settings and while they improve performance a little I feel it's just masking a bigger problem.  All 12 of my AMD servers have this issue and it appears I'm not the only one complaining.  Any help would be appreciated.  Thanks.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1050823 b/results/classifier/deepseek-2-tmp/output/network/1050823
deleted file mode 100644
index 07217d25..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1050823
+++ /dev/null
@@ -1,18 +0,0 @@
-
-segmentation fault when using usb-net and -netdev tap
-
-The following command causes a Segmentation fault:
-
-qemu-kvm -usb -device usb-net,netdev=net0 -netdev tap,id=net0
-Segmentation fault
-
-The following command does not:
-
-qemu-kvm -usb -device usb-net,netdev=net0 -netdev user,id=net0
-
-Program received signal SIGSEGV, Segmentation fault.
-usbnet_can_receive (nc=0x55555657dc20)
-    at /home/pbonzini/work/upstream/qemu/hw/usb/dev-network.c:1292
-1292	    if (is_rndis(s) && s->rndis_state != RNDIS_DATA_INITIALIZED) {
-
-First reported at https://bugzilla.redhat.com/show_bug.cgi?id=843310
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1054180 b/results/classifier/deepseek-2-tmp/output/network/1054180
deleted file mode 100644
index 8cc7805a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1054180
+++ /dev/null
@@ -1,17 +0,0 @@
-
-DNS activity in slirp (user networking) mode quickly depletes file descriptors and crashes qemu
-
-Hi, we have encountered quite some trouble with filedescriptor depletion of the qemu process. We have figured out that it can be demonstrated easily by doing a lot of DNS queries inside the VM -- in our real world scenario this is caused by running centos network install with a fast mirror.
-
-This situation is further problematic because qemu can't handle fd depletion very well:
-1) if ulimit is 1024 then qemu hangs in infinite loop whenever it tries to open the 1025th fd
-2) setting ulimit >1024 does not help that much because qemu uses select and max. fd set size is 1024 per default => qemu crashes because of buffer overflow in select()
-3) setting ulimit > 1024 AND recompiling with large enough fd set size AND disabling gcc's fortify source seems to work, but that's really just a hot-fix
-
-The problem can be replicated quite easily by running something like
-
-while :; do echo >/dev/udp/10.0.2.3/53; done
-
-inside a Linux VM -- crash comes very soon.
-
-This problem is present in current qemu (1.2.0) and in earlier as well.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1061778 b/results/classifier/deepseek-2-tmp/output/network/1061778
deleted file mode 100644
index 4faec5e5..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1061778
+++ /dev/null
@@ -1,10 +0,0 @@
-
-signal mask not reset on exec
-
-Seen in qemu-1.0 under 12.04, but AFAICT from current git it hasn't changed.
-
-./main-loop.c:qemu_signal_init blocks SIGALRM so it can be handled via signalfd.
-
-./net/tap.c:launch_script does not reset the signal mask before the execv() call, and signal masks are inherited. So the script is run with SIGALRM blocked (as can be seen in /proc/$$/status, "SigBlk:	0000000000002000"). One reasonable example of where this bites is an interface up script that calls ping with a timeout to give things a chance to settle down before continuing, but abort if this doesn't happen within a reasonable time). Since ping uses SIGALRM for the timeout, this now never terminates.
-
-qemu-0.14 didn't block SIGALRM, so such scripts worked fine there.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1066055 b/results/classifier/deepseek-2-tmp/output/network/1066055
deleted file mode 100644
index d09abada..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1066055
+++ /dev/null
@@ -1,20 +0,0 @@
-
-Network performance regression with vde_switch
-
-I've noticed a significant network performance regression when using vde_switch, starting about one week ago (10/05/2012); before that date, I used to get about 1.5 Gbits host to guest, but now I can only get about 320 Mbits; I didn't find any modification in net/vde.*, just in hw/virtio*.
-
-My command line: 
- qemu-system-i386 -cdrom /bpd/bpd.iso -m 512 -boot d -enable-kvm \
-  -localtime -ctrl-grab -usbdevice tablet \
-  -device virtio-net-pci,mac=52:54:00:18:01:01,netdev=vde0,tx=bh,ioeventfd=on,x-txburst=32 \
-  -netdev vde,id=vde0 -vga std -tb-size 2M -cpu host -clock unix
-
-My host runs a kernel 3.6.1 and my guest runs a kernel 3.5.4; the same problem happens with other host and guest versions, too.
-
-I know there are better ways of running a guest, but using vde I get a cleaner environment in the host (just one tun/tap interface to manage...), which is quite good when running some accademic experiments.
-
-Interestingly, at the same time I've noticed a performance enhancement of about 25~30 % when using a tun/tap interface, bridged or not.
-
-Thank you, very much.
-
-Edivaldo de Araujo Pereira
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1067119 b/results/classifier/deepseek-2-tmp/output/network/1067119
deleted file mode 100644
index 1dcccbc9..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1067119
+++ /dev/null
@@ -1,10 +0,0 @@
-
-e1000 missing statistics
-
-The E1000 emulation is missing several counters that are used by other software.
-
-The following would be useful:
-  Good bytes receive counter GORCH/GORCL
-  Good bytes transmit counter GOTCH/GOTCL
-Broadcast packets sent/received
-Multicast packets sent/received.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1079713 b/results/classifier/deepseek-2-tmp/output/network/1079713
deleted file mode 100644
index 8c401fcf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1079713
+++ /dev/null
@@ -1,76 +0,0 @@
-
-failed to set sndbuf on VMs network interface
-
-I am trying to set "sndbuf" for a VMs network device to "0".
-I inserted to my XML file:
-      <tune>
-        <sndbuf>0</sndbuf>
-      </tune>
-The XML file validates, but I am not able to start the virtual machine.
-
-# virsh edit vm3
-<domain type='kvm'>
-  <name>vm3</name>
-  <uuid><HIDDEN></uuid>
-  <memory unit='KiB'>524288</memory>
-  <currentMemory unit='KiB'>524288</currentMemory>
-  <vcpu placement='static'>1</vcpu>
-  <os>
-    <type arch='x86_64' machine='pc-1.2'>hvm</type>
-    <boot dev='hd'/>
-  </os>
-  <features>
-    <acpi/>
-    <apic/>
-    <pae/>
-  </features>
-  <clock offset='utc'/>
-  <on_poweroff>destroy</on_poweroff>
-  <on_reboot>restart</on_reboot>
-  <on_crash>restart</on_crash>
-  <devices>
-    <emulator>/usr/bin/kvm</emulator>
-    <disk type='file' device='disk'>
-      <driver name='qemu' type='qcow2'/>
-      <source file='<HIDDEN>'/>
-      <target dev='vda' bus='virtio'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
-    </disk>
-    <controller type='usb' index='0'>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
-    </controller>
-    <interface type='bridge'>
-      <mac address='<HIDDEN>'/>
-      <source bridge='br2'/>
-      <model type='virtio'/>
-      <tune>
-        <sndbuf>0</sndbuf>
-      </tune>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
-    </interface>
-    <serial type='pty'>
-      <target port='0'/>
-    </serial>
-    <console type='pty'>
-      <target type='serial' port='0'/>
-    </console>
-    <input type='mouse' bus='ps2'/>
-    <graphics type='vnc' port='-1' autoport='yes'/>
-    <sound model='ich6'>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
-    </sound>
-    <video>
-      <model type='cirrus' vram='9216' heads='1'/>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
-    </video>
-    <memballoon model='virtio'>
-      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
-    </memballoon>
-  </devices>
-</domain>
-
-Domain vm3 XML configuration edited.
-
-# LANG=en_US.utf-8 virsh start vm3
-error: Failed to start domain vm3
-error: internal error Process exited while reading console log output: char device redirected to /dev/pts/4
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/111 b/results/classifier/deepseek-2-tmp/output/network/111
deleted file mode 100644
index b3692181..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/111
+++ /dev/null
@@ -1,2 +0,0 @@
-
-[OSS-Fuzz] Assertion Failure: !in6_zero(&ip_addr)
diff --git a/results/classifier/deepseek-2-tmp/output/network/1119281 b/results/classifier/deepseek-2-tmp/output/network/1119281
deleted file mode 100644
index 5a46af04..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1119281
+++ /dev/null
@@ -1,36 +0,0 @@
-
-The virtio network device breaks UuidCreateSequential()
-
-UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue.
-
-Here is the software I have tested this with:
- * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively)
- * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
- * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
-
-
-Here is how to test for this issue:
-* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver.
-
-* Boot the guest and copy the uuidtest.exe file (see attachement) to it
-
-* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below:
-
-        Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
-
-* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0.
-
-        UuidCreateSequential() returned 0
-        uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
-        Got a version 1 UUID
-        The UUID does not contain a non-multicast MAC address
-
-* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be.
-
-* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address.
-
-
-(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
-(2) Best do it with a single card to avoid confusion over which is the primary one.
-(3) If the first byte of the address is odd then this is a multicast address.
-    https://en.wikipedia.org/wiki/MAC_address#Address_details
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1158912 b/results/classifier/deepseek-2-tmp/output/network/1158912
deleted file mode 100644
index f3c620aa..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1158912
+++ /dev/null
@@ -1,47 +0,0 @@
-
-QEMU Version 1.4.0 - SLIRP hangs VM
-
-(Note: problem is not present in version 1.3.0)
-
-Stacktrace: please see attached gdb log file.
-
-Steps to reproduce:
-
-1. gdb -x debug-qemu.gdb testing/qemu-1.4.0/ppc64-softmmu/qemu-system-ppc64
-
-Contents of debug-qemu.gdb:
-
-run -L ./testing/qemu-1.4.0/pc-bios  -name "[DEBUG] Software und System-Entwicklung IBM POWER7" -cpu POWER7_v2.3 -M pseries -m 1024 -rtc base=utc -nodefaults -vga std -monitor vc -serial vc -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9011-10.0.2.11:22 -device virtio-net-pci,netdev=mynet0 -drive file=images/suse-ppc.img,if=virtio,index=0,media=disk,cache=unsafe -kernel images/iso/suseboot/vmlinux -append "root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0" -initrd images/iso/suseboot/initrd.img -drive if=scsi,bus=0,unit=0,media=cdrom
-
-
-2. build information
-    QEMU: ppc64 full emulation, version 1.4.0
-    Host OS: Windows XP
-    Guest OS: openSUSE 12.2 kernel 3.4.6-2.10-ppc64
-
-    PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH
-    PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig
-    THREADS=4
-    export PKG_CONFIG_LIBDIR
-    
-    sed -i 's/--static-libs/--static --libs/' configure
-    CC=i686-pc-mingw32-gcc ./configure \
-          --target-list=ppc64-softmmu \
-          --enable-debug \
-          --enable-sdl \
-          --static \
-          --enable-fdt && \
-    sed -i 's/ -Wl,--dynamicbase//g; s/-Wl,--nxcompat //g;'  config-host.mak && \
-    make -j$THREADS && {
-          echo "renaming binw.exe to bin.exe..."
-          for i in `echo $TARGET_LIST | tr ',' ' '`; do
-                 BINARCH=`echo $i | sed 's/-softmmu//'`
-                 mv $i/qemu-system-${BINARCH}w.exe \
-                        $i/qemu-system-$BINARCH.exe
-          done
-    }
-
-   
-3. From VM: 
-    Command to hang VM: zypper dup
-    Last message before VM hang:  Retrieving repository 'openSUSE-12.2-12.2-0' metadata -----------------------[|]
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1171 b/results/classifier/deepseek-2-tmp/output/network/1171
deleted file mode 100644
index e01c8a07..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1171
+++ /dev/null
@@ -1,4 +0,0 @@
-
-tulip: DMA reentrancy issue leads to stack overflow (CVE-2022-2962)
-Description of problem:
-A DMA reentrancy issue was found in the tulip emulation. When tulip reads or writes to  rx/tx descriptor ( tulip_desc_read/write ) or copies  rx/tx frame(tulip_copy_rx_bytes / tulip_copy_tx_buffers), it doesn't check whether the destination address is its own MMIO address. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1176366 b/results/classifier/deepseek-2-tmp/output/network/1176366
deleted file mode 100644
index 97b1c7ed..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1176366
+++ /dev/null
@@ -1,6 +0,0 @@
-
-TCPIP not working on qemu 1.4.50 (master)
-
-whenever I try, in the guest OS, in this case it's NT 3.1, to enable TCP/IP, it crashes the whole emulator. With either the ne2000 isa, ne2000 pci or PCnet, still crashes
-
-below is attached a screenshot.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1179731 b/results/classifier/deepseek-2-tmp/output/network/1179731
deleted file mode 100644
index 795fe7c2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1179731
+++ /dev/null
@@ -1,4 +0,0 @@
-
-is networking broken on windows hosts?
-
-just wondering as i just compiled the latest git and qemu goes into none responding mode when i try to do any networking stuff on guests (both linux and windows)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1180777 b/results/classifier/deepseek-2-tmp/output/network/1180777
deleted file mode 100644
index 829ba378..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1180777
+++ /dev/null
@@ -1,47 +0,0 @@
-
-RDP traffic freeze on quiet network
-
-Hi,
-
-I recently started using KVM over VirtualBox for my Office needs. I setup a Windows 7 VM on KVM and started using it through remote desktop. 
-
-What happens is that, after some hours of usage, the remote desktop connection freezes. I thought it was a remmina bug, as the it was enough to kill and restart it to successfully connect again to the VM.
-
-However, today I've switched to a different RDP client (2X Client chromium app) and the freeze just happened again!
-
-Some information:
-- the host and the VM are completely idle when the freeze occurs
-- I've tried sniffing the network packets toward the RDP port during the freeze and found that the client is sending packets but no packet is sent back
-
-
-Could this be a KVM issue? How can I further debug this one (I expect the freeze to happen again...)?
-
-ProblemType: Bug
-DistroRelease: Ubuntu 12.04
-Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8
-ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42
-Uname: Linux 3.2.0-41-generic x86_64
-ApportVersion: 2.0.1-0ubuntu17.2
-Architecture: amd64
-Date: Thu May 16 14:12:40 2013
-MachineType: Hewlett-Packard HP ProBook 4520s
-MarkForUpload: True
-ProcEnviron:
- TERM=xterm
- PATH=(custom, no user)
- LANG=en_US.UTF-8
- SHELL=/bin/bash
-ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash vt.handoff=7
-SourcePackage: qemu-kvm
-UpgradeStatus: No upgrade log present (probably fresh install)
-dmi.bios.date: 08/26/2010
-dmi.bios.vendor: Hewlett-Packard
-dmi.bios.version: 68AZZ Ver. F.0A
-dmi.board.name: 1411
-dmi.board.vendor: Hewlett-Packard
-dmi.board.version: KBC Version 57.30
-dmi.chassis.type: 10
-dmi.chassis.vendor: Hewlett-Packard
-dmi.modalias: dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr:
-dmi.product.name: HP ProBook 4520s
-dmi.sys.vendor: Hewlett-Packard
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1185311 b/results/classifier/deepseek-2-tmp/output/network/1185311
deleted file mode 100644
index 2734588f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1185311
+++ /dev/null
@@ -1,27 +0,0 @@
-
-could not hot-remove disabled NIC from Win2012 guest by 'devel_del id1'
-
-# qemu-latest-upstream -mon chardev=qmp,mode=control,pretty=on \
- -chardev socket,id=qmp,host=localhost,port=1234,server,nowait -vnc :0 \
- -monitor stdio /images/win2012-64-virtio.qcow2 \
- -device virtio-net-pci,netdev=ndev1,id=id1 -netdev tap,id=ndev1 \
- -device e1000,netdev=ndev2,id=id2 -netdev tap,id=ndev2 \
- -device rtl8139,netdev=ndev3,id=id3 -netdev tap,id=ndev3 \
- -smp 4 -m 3000 -usbdevice tablet
-
-If disable nic in guest's "Network Connections" panel, nic could not be hot-removed through qemu monitor.
-
-1) if disable nic in guest
-(qemu) devel_del id1 (nic still in "Network Connections". if enable nic, nic can work)
-(qemu) devel_del id1
-(qemu) devel_del id1
-
-2) if enable nic in guest
-(qemu) devel_del id1 (nic will be removed, disappear from "Network Connections")
-(qemu) devel_del id1
-Device 'id1' not found
-
-Could not reproduced this problem with all linux guests & other Windows guests
-Problem exists with virtio-nic/e1000/rtl8139, it seems the problem of pci-hotplug in piix4.
-
-Could not reproduce this problem with Vmware + win2012 guest.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1187334 b/results/classifier/deepseek-2-tmp/output/network/1187334
deleted file mode 100644
index 7261ff97..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1187334
+++ /dev/null
@@ -1,9 +0,0 @@
-
-crash on hot-unplug of vmxnet3
-
-Hot-unplug of a vmxnet3 device crashes as follows:
-
-(qemu) device_add id=ff,driver=vmxnet3
-[vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated.
-(qemu) device_del ff
-(qemu) qemu-system-x86_64: /home/pbonzini/work/upstream/qemu/net/net.c:315: qemu_del_net_client: Assertion `queues != 0' failed.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1189 b/results/classifier/deepseek-2-tmp/output/network/1189
deleted file mode 100644
index 9e4b4747..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1189
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Cannot Resolve Names When Host Is Running Systemd-Resolved
diff --git a/results/classifier/deepseek-2-tmp/output/network/1192464 b/results/classifier/deepseek-2-tmp/output/network/1192464
deleted file mode 100644
index 4b5a70a3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1192464
+++ /dev/null
@@ -1,6 +0,0 @@
-
-udp checksum computed as 0 not converted to 0xffff, from guest os that share a common linux bridge among multiple guest os
-
-UDP checksum computed as '0' during transmission of packets that uses e1000 NIC in the Guest as well as emulated h/w in the qemu layer, That needs to be converted to 0xffff, This occurs only when Hardware checksum offload is been set in the guest OS NIC and made it as a transmitter. The guest O.S use the N/W interface that is been shared to the linux brige created in the host (used source=<bridge>) in the xml tags of libvirt.
-
-As per RFC768(http://tools.ietf.org/html/rfc768 [^]), If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1196426 b/results/classifier/deepseek-2-tmp/output/network/1196426
deleted file mode 100644
index a3325db6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1196426
+++ /dev/null
@@ -1,46 +0,0 @@
-
-Setup virtual serial connection for Windows VMs FAILS
-
-Hi,
-
-To setup a virtual serial connections between two Windows 2008 R2(64-bit) guest VMs, I am referring the link 
-http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging
-
-I started the host VM using the command
-# /usr/local/bin/qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp::4445,server,nowait -hda /mnt/sda5/var/lib/libvirt/images/win2008host.img 
-
-To start a target VM, the link specifies the below command
-/usr/local/bin/qemu-system-x86_64 \--enable-kvm \-m 1024 \-drive file=win-target.img \-chardev stdio,id=mon0 \-mdev=mon0 \-serial tcp:127.0.0.1:4445.
-
-I am using the QEMU emulator version 0.15.1 (qemu-kvm-0.15.1). The command is lil bit changed and also doesn't have -mdev option. I executed the below command.
-
-# /usr/local/bin/qemu-system-x86_64 -enable-kvm -smp 1 -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp:127.0.0.1:4455 -hda /var/lib/libvirt/images/win2008target.img
-
-It through the error 
-inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,4455): Connection refused
-chardev: opening backend "socket" failed: Connection refused
-qemu: could not open serial device 'tcp:127.0.0.1:4455': Connection refused
-
-Please let me know if any one knows how to fix issue.
-
-My Linux System Info:
-# cat /etc/redhat-release 
-Fedora release 12 (Constantine)
-
-# uname -a
-Linux petla 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
-
-#cat /proc/cpuinfo
-processor	: 0
-vendor_id	: GenuineIntel
-cpu family	: 6
-model		: 44
-model name	: Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
-
-#/usr/local/bin/qemu-system-x86_64 --version
-QEMU emulator version 0.15.1 (qemu-kvm-0.15.1), Copyright (c) 2003-2008 Fabrice Bellard
-
-Guest VMs(host and target): Windows Server 2008 R2 (64-bit)
-
-Thanks in Advance
-Venkatesh
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1196727 b/results/classifier/deepseek-2-tmp/output/network/1196727
deleted file mode 100644
index 9824042c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1196727
+++ /dev/null
@@ -1,54 +0,0 @@
-
-SLIRP on Windows 7 64-bit host or is it me?
-
- Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit
-      Host: Windows 7 64-bit
-    Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64
- libiconv: 1.14
-        glib: 2.28.8
-gettext: 0.18.1.1
- pixman: 0.30.0
-   libSDL: 1.2.14
-   Driver: virtio-net-pci
-     Emu: full (non-KVM)
-
-I'm new to Windows 7 64-bit as a host for QEMU (previously I was running QEMU on Windows XP with no issues) so it could be me, now on Windows 7 SLIRP only works for me connecting internally from the host to the guest via SLIRP redirect, but any outbound requests from the guest to the Internet are failing with the following:
-
-if_start...
-m_get...
- m = 61f7bd40
-ip_input...
- m = 61f7bd40
- m_len = 48
-tcp_input...
- m = 61f7bd40  iphlen = 20  inso = 0
-tcp_fconnect...
- so = 33e140
- connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45
- tcp fconnect errno = 10035-Unknown error
-icmp_error...
- msrc = 61f7bd40
- msrc_len = 48
- 10.0.2.5 to 206.190.36.45
-m_get...
- m = 61f7b6c0
-ip_output...
- so = 0
- m0 = 61f7b6c0
-if_output...
- so = 0
- ifm = 61f7b6c0
-if_start...
-arp_table_search...
- ip = 0x502000a
- found hw addr = 52:54:00:12:34:56
-m_free...
- m = 61f7b6c0
-tcp_close...
- tp = 377840
-m_free...
- m = 0
-m_free...
- m = 61f7bd40
-
-Am I doing something wrong with my Windows host configuration or is this a bug in SLIRP only on W64 and not W32?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1196773 b/results/classifier/deepseek-2-tmp/output/network/1196773
deleted file mode 100644
index 7b5274cd..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1196773
+++ /dev/null
@@ -1,12 +0,0 @@
-
-pci_add auto nic failed on qemu monitor
-
-hello!
-execute "qemu-system-x86_64 -M pc -m 256 -hda pc/img.qcow2 -nographic -net nic,vlan=0,macaddr=00:e0:fc:00:00:01 -net tap,vlan=0,ifname=tap0,script=no -serial tcp::3333,server,nowait -boot c"
-and then
-(qemu) pci_add auto nic vlan=1,macaddr=00:e0:fc:40:20:02
-Property 'e1000.netdev' can't take value 'hub0port0', it's in use
-
-the qemu version is 1.4.1
-
-thx!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1202289 b/results/classifier/deepseek-2-tmp/output/network/1202289
deleted file mode 100644
index 0481944d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1202289
+++ /dev/null
@@ -1,77 +0,0 @@
-
-Windows 2008/7 Guest to Guest Very slow 10-20Mbit/s
-
-I'm not sure if I'm submitting this to the proper place or not, if not, please direct me accordingly.
-
-At this point I'm starting to get desperate, I'll take any options or suggestions that spring to mind:
-
-Anyway, the problem exists on multiple hosts of various quality.   From 4 core 8g mem machines to 12 core 64Gig mem machines with LVM and Raid-10. 
-
-Using iperf as the testing utility: (windows guest can be either Windows 7 or 2008R2)
--Windows Guest -> Windows Guest averages 20Mbit/s (The problem)
--Windows Guest -> Host averages 800Mbit/s
--Host -> Windows Guest averages 1.1Gbit/s
--Linux Guest -> Host averages 12GBit/s
--Linux Guest -> Linux Guest averages 10.2Gbit/s
-
-For windows guests, switching between e1000 and virtio drivers doesn't make much of a difference.  
-
-I use openvswitch to handle the bridging (makes bonding nics much easier) 
-
-Disabling TSO GRO on all the host nics, and virtual nics, as well as modding the registry using:
-netsh int tcp set global (various params here)  can slightly improve Windows -> windows throughput.   up to maybe 100Mbit/s    but even that is spotty at best.
-
-The Particulars of the fastest host which benchmarks about the same as the slowest host. 
-
-Ubuntu 12.04 64bit (updated to lastest as of  July 15th)
-Linux cckvm03 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
-
-libvirt: 
-Source: libvirt
-Version: 0.9.8-2ubuntu17.10
-
-qemu-kvm
-Package: qemu-kvm
-Version: 1.0+noroms-0ubuntu14.8
-Replaces: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0), kvm-data, qemu
-
-openvswitch
-Source: openvswitch
-Version: 1.4.0-1ubuntu1.5
-
-/proc/cpuifo
-
-processor       : 0
-vendor_id       : GenuineIntel
-cpu family      : 6
-model           : 45
-model name      : Intel(R) Xeon(R) CPU E5-2440 0 @ 2.40GHz
-stepping        : 7
-microcode       : 0x70d
-cpu MHz         : 2400.226
-cache size      : 15360 KB
-physical id     : 0
-siblings        : 12
-core id         : 0
-cpu cores       : 6
-apicid          : 0
-initial apicid  : 0
-fpu             : yes
-fpu_exception   : yes
-cpuid level     : 13
-wp              : yes
-flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
-pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt
-scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap
-erfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdc
-m pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm
-ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
-bogomips        : 4800.45
-clflush size    : 64
-cache_alignment : 64
-address sizes   : 46 bits physical, 48 bits virtual
-power management:
-
-
--Sample KVM line
-usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -name gvexch01 -uuid d28ffb4b-d809-3b40-ae3d-2925e6995394 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/gvexch01.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=dc,menu=on -drive file=/dev/vgroup/gvexch01,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/dev/vgroup/gvexch01-d,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=18,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bf:4e:1c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1213196 b/results/classifier/deepseek-2-tmp/output/network/1213196
deleted file mode 100644
index 63bd64e8..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1213196
+++ /dev/null
@@ -1,4 +0,0 @@
-
--serial tcp should hang up when DTR goes low
-
-In keeping with the spirit of serial modem control signals, de-asserting DTR should cause the TCP connection to break; asserting DTR should cause QEMU to initiate a new connection or for it to accept another (in server mode; this may involve waiting for one to arrive, too).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1221797 b/results/classifier/deepseek-2-tmp/output/network/1221797
deleted file mode 100644
index 87fb36e6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1221797
+++ /dev/null
@@ -1,23 +0,0 @@
-
-virt-install gets stuck during downloading install.img
-
-I have tried to install CentOS 6.4 using the latest version of all kvm related tools. My problem is that I get stuck at arround 20% during the download of the file install.img. Everything before that works just fine.
-
-I am using the following commands to install to server:
-virt-install \
-	-n test \
-	-r 1024 \
-	--disk path=/var/kvm/images/test.img,size=25 \
-	--vcpus=1 \
-	--os-type linux \
-	--os-variant=rhel6 \
-	--network bridge=br2 \
-	--nographics \
-	--location='http://mirror.netcologne.de/centos/6.4/os/x86_64' \
-	--extra-args='console=tty0 console=ttyS0,115200n8 serial' \
-
-I have checked that my server is ready for virtualization.
-
-If you need any further information I am happy to provide them
-
-Patrick Gramsl
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1228285 b/results/classifier/deepseek-2-tmp/output/network/1228285
deleted file mode 100644
index 82f0cb2b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1228285
+++ /dev/null
@@ -1,30 +0,0 @@
-
-e1000 nic TCP performances
-
-Hi,
-
-Here is the context :
-
-$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000
-$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000
-
-The bandwidth is really tiny :
-
-    . Iperf3 reports about 30 Mb/sec
-    . NetPerf reports about 50 Mb/sec
-
-
-With UDP sockets, there is no problem at all :
-
-    . Iperf3 reports about 1 Gb/sec
-    . NetPerf reports about 950 Mb/sec
-
-
-I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.)
-I've used the main GIT version of QEMU.
-
-
-Thanks in advance.
-
-See you,
-VInce
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1253 b/results/classifier/deepseek-2-tmp/output/network/1253
deleted file mode 100644
index 2dde05b4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1253
+++ /dev/null
@@ -1,2 +0,0 @@
-
-pull mirroring
diff --git a/results/classifier/deepseek-2-tmp/output/network/1261450 b/results/classifier/deepseek-2-tmp/output/network/1261450
deleted file mode 100644
index eeecd1da..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1261450
+++ /dev/null
@@ -1,80 +0,0 @@
-
-libvirtd reload and hooks problem routed-net
-
-if we do a reload of libvirt, some iptables rules, which are created through /etc/libvirt/hooks/qemu are not working anymore.
-Every time a other (one or two,thee) vm is affected. 
-
-
-our qemu file:
-
-#!/bin/bash
-
-
-do_net() {
-        local status=$2
-        local ip=$3
-        local in=$4
-        local out=$5
-
-        if [[ ! $status || ! $ip || ! $in || ! $out ]]; then
-                echo "Not all parameters were passed!"
-                exit 1
-        fi
-
-        if [ "$status" = "stopped" -o "$status" = "reconnect" ]; then
-                ip route del $ip via 191.255.255.1 dev $out
-                ip neigh del proxy $ip dev $in
-                iptables -D FORWARD -i $in -o $out -s 0.0.0.0/0 -d $ip/32 -j ACCEPT
-                iptables -D FORWARD -i $out -o $in -s $ip/32 -d 0.0.0.0/0 -j ACCEPT
-        fi
-
-        if [ "$status" = "start" -o "$status" = "reconnect" ]; then
-                ip route add $ip via 191.255.255.1 dev $out
-                ip neigh add proxy $ip dev $in
-                iptables -I FORWARD 4 -i $in -o $out -s 0.0.0.0/0 -d $ip/32 -j ACCEPT
-                iptables -I FORWARD 4 -i $out -o $in -s $ip/32 -d 0.0.0.0/0 -j ACCEPT
-                fi
-}
-
-CONF=//etc/libvirt/hooks/vms/*
-for file in $CONF
-do
-        guest_ipaddr=""
-        guest_name=""
-        type=""
-        destination="0.0.0.0/0"
-
-  while read line;    do
-    eval $line
-  done < $file
-        guest_ipaddrnet=$guest_ipaddr"/32"
-      for dest in ${destination}
-      do
-                if [ "${1}" = "${guest_name}" ]; then
-                        echo "SRC-IP="$guest_ipaddr " " $guest_ipaddrnet " VM="$guest_name " Dest="$dest
-                        if [ "${2}" = "stopped" ]; then
-                                        ip route del $guest_ipaddr via 191.255.255.1 dev virbr1
-                                       ip neigh del proxy $guest_ipaddr dev bond0
-                               iptables -D FORWARD -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT
-                               iptables -D FORWARD -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT
-                        fi
-                        if [ "${2}" = "start" ]; then
-                                 ip route add $guest_ipaddr via 191.255.255.1 dev virbr1
-                                 ip neigh add proxy $guest_ipaddr dev bond0
-                                 iptables -I FORWARD 4 -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT
-                                 iptables -I FORWARD 4 -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT
-                        fi
-                        if [ "${2}" = "reconnect" ]; then
-                                       ip route del $guest_ipaddr via 191.255.255.1 dev virbr1
-                                       ip neigh del proxy $guest_ipaddr dev bond0
-                               iptables -D FORWARD -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT
-                               iptables -D FORWARD -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT
-                               sleep 1
-                                 ip route add $guest_ipaddr via 191.255.255.1 dev virbr1
-                                 ip neigh add proxy $guest_ipaddr dev bond0
-                               iptables -I FORWARD 4 -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT
-                               iptables -I FORWARD 4 -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT
-                        fi
-                fi
-        done
-done
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1272252 b/results/classifier/deepseek-2-tmp/output/network/1272252
deleted file mode 100644
index ed580396..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1272252
+++ /dev/null
@@ -1,25 +0,0 @@
-
-qemu-img ftp/http convert
-
-Converting images with ftp or http as source could be done a lot faster. The way it works now (qemu 1.7.50) is significantly slower than the optimal way. 
-
-FTP - how it works now
-1. Connect and login to ftp-server. Ask for size of file.
-2. Get a chunk of data using rest+retr
-3. Goto step 1 again in a loop until all data is retrieved
-
-FTP - better solution
-1. Connect and login to ftp-server. Dont ask for size of file.
-2. Retrieve all remaining data
-3. Goto step 1 again if disconnected/io error (max NN errors etc)
-
-
-Http - how it works now
-1. Connect to webserver and ask for size of file / http HEAD.
-2. Get a chunk of data using http Range.
-3. Goto step 1 again in a loop until all data is retrieved.
-
-Http - better solution
-1. Connect to webserver.
-2. Retrieve all remaining data.
-3. Goto step 1 again if disconnected/io error (max NN errors).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1286 b/results/classifier/deepseek-2-tmp/output/network/1286
deleted file mode 100644
index 8ca85de6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1286
+++ /dev/null
@@ -1,2 +0,0 @@
-
-netdev tftp option docs don't mention that the TFTP server is read-only
diff --git a/results/classifier/deepseek-2-tmp/output/network/1286253 b/results/classifier/deepseek-2-tmp/output/network/1286253
deleted file mode 100644
index f6f583b9..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1286253
+++ /dev/null
@@ -1,12 +0,0 @@
-
-virtio-net acceleration features not set when plugged into backend dynamically
-
-When using indpendent transport and backend in this case virtio-net-device transport, none of the acceleration features are set after guest probes the transport the backend is plugged into. For virtio-net this leads to low throughput/performance.  This holds true for  virtio-mmio, PCI transports and most likely for others as well (CCW, S390) and other backends
-
-Command to run:
-./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \
-      -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \
-      -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \
-      -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58"
-
-For x86 same virtio command for network.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1288620 b/results/classifier/deepseek-2-tmp/output/network/1288620
deleted file mode 100644
index 1a316835..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1288620
+++ /dev/null
@@ -1,18 +0,0 @@
-
-memory leak with config file
-
-I have a Windows 7 SP1 Professional 64-bit installation on a QCOW2 image with compat=1.1, which I launch via
-
-qemu-system-x86_64 -drive file=windows_base_HDD.img,index=0,media=disk -enable-kvm -m 512M -vga std -net nic,vlan=0 -net user,vlan=0
-
-As soon as I start using the network in any application — for example, visiting www.google.com in Internet Explorer — QEMU starts gobbling memory until the (host) kernel kills it because of an OOM condition.  If I run the QEMU with the same options, but with model=e1000 option set for the NIC (i.e. -net -nic,vlan=0,model=e1000), I can use the network from the guest OS without any noticeable effect on QEMU's memory consumption.
-
-I do not have this problem when running QEMU with the exact same options (as above, without model=e1000) but with a Debian wheezy installation (on a QCOW image of the same format).  My host system in Ubuntu 13.10 x86_64, kernel image 3.11.0-17-generic, but with the QEMU packages from trusty (the codename for the next release):
-Output of `dpkg -l \*qemu\* | grep '^ii'`:
-ii  ipxe-qemu                             1.0.0+git-20130710.936134e-0ubuntu1        all          Virtual package to support use of kvm-ipxe with qemu
-ii  qemu-keymaps                          1.7.0+dfsg-3ubuntu2                        all          QEMU keyboard maps
-ii  qemu-system-common                    1.7.0+dfsg-3ubuntu2                        amd64        QEMU full system emulation binaries (common files)
-ii  qemu-system-x86                       1.7.0+dfsg-3ubuntu2                        amd64        QEMU full system emulation binaries (x86)
-ii  qemu-utils                            1.7.0+dfsg-3ubuntu2                        amd64        QEMU utilities
-
-(If necessary, I can try to reproduce this with QEMU built from the upstream source or the latest source from version control.)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1296 b/results/classifier/deepseek-2-tmp/output/network/1296
deleted file mode 100644
index ddfe186a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1296
+++ /dev/null
@@ -1,9 +0,0 @@
-
-qemu hangs on start with a bridged NIC
-Description of problem:
-qemu hangs on start with a bridged NIC. And there is no difference exists the bridge or not. At the same with a user NIC (`-nic user`) everything works flawlessly. Also I tried to add `-enable-kvm` key and had no luck.
-Steps to reproduce:
-1. Run qemu with the specified command line.
-Additional information:
-I ran the strace: `strace -s 1024 -tt -ff -y -o qemu_bridge -- qemu-system-x86_64 -nic bridge`
-Here are the logs: [qemu-bridge-strace.zip](/uploads/ecf8a2ba9133279fdd6f88fda5dd9ff3/qemu-bridge-strace.zip)
diff --git a/results/classifier/deepseek-2-tmp/output/network/1296882 b/results/classifier/deepseek-2-tmp/output/network/1296882
deleted file mode 100644
index 14c23ff4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1296882
+++ /dev/null
@@ -1,6 +0,0 @@
-
-add next free device option to qemu-img
-
-I'd like to propose an option to be added to qemu-img which returns the next free NBD (the device file) very similar to losetup -f. It would make life a lot easier.
-
-Followers of this enhancement request might be interested in the following workaround: http://stackoverflow.com/questions/22535222/next-free-device-option-for-qemu-nbd/
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1297487 b/results/classifier/deepseek-2-tmp/output/network/1297487
deleted file mode 100644
index 93cd9cf1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1297487
+++ /dev/null
@@ -1,169 +0,0 @@
-
-MTU not honored in virtio vnet
-
-I am observing a potential regression/different behavior between rel. 14.04 (dev branch) and release 13.04.
-
-My hardware is: Cisco UCS blade B200-M3 and the network adapter card: Cisco UCS VIC 1240.
-
-lsb_release -rd
-Description:	Ubuntu Trusty Tahr (development branch)
-Release:	14.04
-
-uname -a
-Linux konan2 3.13.0-19-generic #40-Ubuntu SMP Mon Mar 24 02:36:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
-
-The problem:
-After starting a kvm with virtio interfaces I am passing HTTP traffic via an external network traffic simulator.
-The tool is sending a TCP packet of 3481B, because the tool MTU is set to 1400B, it splits the packets into 3 TCP segments.
-When the 3 segments are received at the host eth1 interface, the host (ubuntu 14.04) reassembles the TCP packets into a larger packet (GRO), then passes the packet up on vnet1. At this point, because vnet1 MTU is 1500B, it is supposed to re-segment the packet and pass the 3 segments up to the VM. But it passes the big 3481B packet instead.
-
-This behavior did not happen when I tried the same scenario in release 13.04
-
-I can disable this behavior by disabling TSO (TCP segment offloading in the vnet), but I did not have to do this in rel. 13.04 and I feel the MTU is not honored as it should be with rel. 14.04.
-
- ip link show | grep eth1
-3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP mode DEFAULT group default qlen 1000
- ip link show | grep vnet1
-16: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN mode DEFAULT group default qlen 500
-
-I am attaching two tcpdump/pcap traces that show a TCP transaction passing on vnet1 when TSO is on and when TSO is off.
-
-Please see:
-
-- vnet1_tso_on.pcap
-- vnet1_tso_off.pcap
-
-in attachment.
-
-I noticed there was a driver upgrade in rel. 14.04:
-
-in 14.04:
-
-ethtool -i eth1
-driver: enic
-version: 2.1.1.50  
-firmware-version: 2.1(3a)
-bus-info: 0000:07:00.0
-supports-statistics: yes
-supports-test: no
-supports-eeprom-access: no
-supports-register-dump: no
-supports-priv-flags: no
-
-ethtool -i vnet1
-driver: tun
-version: 1.6
-firmware-version: 
-bus-info: tap
-supports-statistics: no
-supports-test: no
-supports-eeprom-access: no
-supports-register-dump: no
-supports-priv-flags: no
-
-ethtool -k vnet1
-Features for vnet1:
-rx-checksumming: off [fixed]
-tx-checksumming: on
-	tx-checksum-ipv4: off [fixed]
-	tx-checksum-ip-generic: on
-	tx-checksum-ipv6: off [fixed]
-	tx-checksum-fcoe-crc: off [fixed]
-	tx-checksum-sctp: off [fixed]
-scatter-gather: on
-	tx-scatter-gather: on
-	tx-scatter-gather-fraglist: on
-tcp-segmentation-offload: off
-	tx-tcp-segmentation: off
-	tx-tcp-ecn-segmentation: off
-	tx-tcp6-segmentation: off
-udp-fragmentation-offload: on
-generic-segmentation-offload: on
-generic-receive-offload: on
-large-receive-offload: off [fixed]
-rx-vlan-offload: off [fixed]
-tx-vlan-offload: on
-ntuple-filters: off [fixed]
-receive-hashing: off [fixed]
-highdma: off [fixed]
-rx-vlan-filter: off [fixed]
-vlan-challenged: off [fixed]
-tx-lockless: off [fixed]
-netns-local: off [fixed]
-tx-gso-robust: off [fixed]
-tx-fcoe-segmentation: off [fixed]
-tx-gre-segmentation: off [fixed]
-tx-ipip-segmentation: off [fixed]
-tx-sit-segmentation: off [fixed]
-tx-udp_tnl-segmentation: off [fixed]
-tx-mpls-segmentation: off [fixed]
-fcoe-mtu: off [fixed]
-tx-nocache-copy: on
-loopback: off [fixed]
-rx-fcs: off [fixed]
-rx-all: off [fixed]
-tx-vlan-stag-hw-insert: on
-rx-vlan-stag-hw-parse: off [fixed]
-rx-vlan-stag-filter: off [fixed]
-l2-fwd-offload: off [fixed]
-
-
-
-in 13.04 :
-
-ethtool -i eth1
-driver: enic
-version: 2.1.1.39
-firmware-version: 2.1(3a)
-bus-info: 0000:07:00.0
-supports-statistics: yes
-supports-test: no
-supports-eeprom-access: no
-supports-register-dump: no
-supports-priv-flags: no
-
-
-ethtool -i vnet1
-driver: tun
-version: 1.6
-firmware-version: 
-bus-info: tap
-supports-statistics: no
-supports-test: no
-supports-eeprom-access: no
-supports-register-dump: no
-supports-priv-flags: no
-
-
-ethtool -k vnet1
-Features for vnet1:
-rx-checksumming: off [fixed]
-tx-checksumming: on
-	tx-checksum-ipv4: off [fixed]
-	tx-checksum-ip-generic: on
-	tx-checksum-ipv6: off [fixed]
-	tx-checksum-fcoe-crc: off [fixed]
-	tx-checksum-sctp: off [fixed]
-scatter-gather: on
-	tx-scatter-gather: on
-	tx-scatter-gather-fraglist: on
-tcp-segmentation-offload: on
-	tx-tcp-segmentation: on
-	tx-tcp-ecn-segmentation: on
-	tx-tcp6-segmentation: on
-udp-fragmentation-offload: on
-generic-segmentation-offload: on
-generic-receive-offload: on
-large-receive-offload: off [fixed]
-rx-vlan-offload: off [fixed]
-tx-vlan-offload: off [fixed]
-ntuple-filters: off [fixed]
-receive-hashing: off [fixed]
-highdma: off [fixed]
-rx-vlan-filter: off [fixed]
-vlan-challenged: off [fixed]
-tx-lockless: off [fixed]
-netns-local: off [fixed]
-tx-gso-robust: off [fixed]
-tx-fcoe-segmentation: off [fixed]
-fcoe-mtu: off [fixed]
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1297781 b/results/classifier/deepseek-2-tmp/output/network/1297781
deleted file mode 100644
index 097064da..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1297781
+++ /dev/null
@@ -1,9 +0,0 @@
-
-Network device cannot communicate with host machine
-
-I know this used to work but it doesnt work any more using qemu 1.4.2  on fedora 19 everything works fine
-except when i add a NIC sharing the main interface from the host (not the virtual network)
-
-the hosts ip is 10.0.0.4, the router is 10.0.0.1 so when i boot my virtual machine it gets an ip from the router no problem 
-i get on the internet fine, and i can connect (ping,ftp, samba whatever) to all the computers on the network except the host
-10.0.0.4 i can't ping it, i cant do anything to it, but i can connect to all the other computers on the network and i know i used to be able to do this because thats how i shared files between the host and windows guest, with samba... but now i can't browse the host computer because it can't communicate... please help.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1299566 b/results/classifier/deepseek-2-tmp/output/network/1299566
deleted file mode 100644
index 89e7702b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1299566
+++ /dev/null
@@ -1,12 +0,0 @@
-
-virtio serial doesn't work with virtio nic
-
-If virtio NIC is not used virtserialport works and delivers data written to /dev/vport0p1 to localhost:4444:
-
-qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic
-
-If using virtio nic, write to /dev/vport0p1 succeeds, but no data is delivered to localhost:4444:
-
-qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic,model=virtio
-
-This bug exists in 2.0 release, Debian's QEMU 1.7 package and b3706faf from git.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1312 b/results/classifier/deepseek-2-tmp/output/network/1312
deleted file mode 100644
index 48e2ba46..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1312
+++ /dev/null
@@ -1,12 +0,0 @@
-
-TCP performance problems - GSO/TSO, MSS, 8139 related (Ignores lower MTU from PMTUD/MSS)
-Description of problem:
-MTU handling on guests using an RTL8139 virtualized NIC is broken; net/hw/8139.c works with a static MTU of 1500b for TCP offloading, leading to low throughput when clients connect from sub 1500MTU networks. PMTUD is ignored, and locking to a lower MTU in the OS mitigates the issue.
-Steps to reproduce:
-1. Create a guest with an RTL8139 nic
-2. Try to retrieve a file from a client behind a sub 1500 MTU link
-3. Observe low bandwidth due to retransmits
-Additional information:
-I just debugged this issue for an NGO which, for whatever reason, had an RTL8139 NIC in their guest. After i finally traced this to the RTL8139, i found this qemu-devel/netdev thread from six years ago, which apparently already debugged this issue and proposed a patch: https://lore.kernel.org/all/20161114162505.GD26664@stefanha-x1.localdomain/
-
-I did not test the patch proposed there, but note that `net/hw/8139.c` still looks as discussed in that qemu-devel/netdev thread. As i haven't found a bug report in the archives, i figured you might want to know.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1315 b/results/classifier/deepseek-2-tmp/output/network/1315
deleted file mode 100644
index fd1b8ec9..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1315
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Assertion failure in vmxnet3_activate_device
diff --git a/results/classifier/deepseek-2-tmp/output/network/1326986 b/results/classifier/deepseek-2-tmp/output/network/1326986
deleted file mode 100644
index c332509e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1326986
+++ /dev/null
@@ -1,13 +0,0 @@
-
-e1000 - no link detected by VXWorks based guest
-
-I'm trying to get a VXWorks image running inside a qemu guest.  I have the machine running, however, the vxworks image only has support for the 82544EI device so I had to change the device ID in e1000.c to get the device even recognized so I'm not sure if this is a bug or an issue for the development list.
-
-
-After changing e1000.c, the device is now seen by the guest OS, however, it never gets a link.  I've attached the e1000 debug logs in the hopes that someone can help me understand where to start looking into why this guest won't get a link.
-
-I tested the updated e1000 driver with a debian live CD and the card works under it, so it doesn't appear that the issue is with the driver string change but rather something in the e1000 driver itself.
-
-Here is the command I'm using to start QEMU:
-
-/opt/qemu/bin/qemu-system-i386  -cpu coreduo -hda /root/vxworks_test -m 2048 -netdev tap,ifname=tap0,id=net0 -netdev tap,ifname=tap1,id=net1 -device e1000,netdev=net0,mac=00:00:e8:01:02:03 -device e1000,netdev=net1,mac=00:00:e8:01:02:04 -boot c -curses -no-kvm -D /tmp/qemu.log 2>/tmp/e1000.log
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1337 b/results/classifier/deepseek-2-tmp/output/network/1337
deleted file mode 100644
index 503a6b62..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1337
+++ /dev/null
@@ -1,17 +0,0 @@
-
-Incorrect warnings when using vhost without numa
-Description of problem:
-Part A: Misleading error message. Running the above command for any architecture fails to initialize vhost, and prints the following, incorrect advice
-```
-qemu-system-mips: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on
-qemu-system-mips: vhost_set_mem_table failed: Invalid argument (22)
-qemu-system-mips: Error starting vhost: 22
-```
-
-Since the command line already contains `-object memory-backend-file,id=mem1,mem-path=/tmp/mem,size=256M,share=on` this error message should not be printed. For x86_64, this can be resolved by adding `-numa node,memdev=mem0` to the command line. As such, I think this error message should instead guide a user to adding that argument.
-
-Part B: No documented configuration to run vhost-user for machines that don't support numa.
-The mips malta machine does not support the `-numa` flag. It is unclear if this means that `vhost` cannot be used with this platform or if a non-numa configuration with a memory-backend-file can be used.
-Steps to reproduce:
-1. Run `vhost-user-vsock --socket=/tmp/vhost4.socket --uds-path=/tmp/foo` from https://github.com/rust-vmm/vhost-device.
-1. Run the above QEMU command
diff --git a/results/classifier/deepseek-2-tmp/output/network/1365 b/results/classifier/deepseek-2-tmp/output/network/1365
deleted file mode 100644
index 14f72b35..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1365
+++ /dev/null
@@ -1,25 +0,0 @@
-
-qemu on m1 mac loses network connection after some time running
-Description of problem:
-While running qemu with podman machine on m1 mac, after a while the network connections will stop answering.
-When running with the console window dmesg will start showing the following messages
-```
-uq: 0x1, name: output.0, 2263286224 uses ago
-[37689.0770611 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2268226224 uses ago
-[37693.7877481 virtio_net virtio@ emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2273326224 uses ago
-[37698.3116991 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2278226224 uses ago
-[37702.9616661 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2283266224 uses ago
-[37707.5462551 virtio_net virtiod empos1: IX timeout on queue: 0, sq: output.O, ug: Ox1, name: output.O, 2288226224 usecs ago
-[37712.205242) virtio_net virtio@ enposI: IX timeout on queue: 0, sq: output.o, uq: 0x1, name: output. 0, 2293276224 uses ago
-[37716.7708171 virtio_net virtiod enpOsi: IX timeout on queue: 0, sq: output.o, uq: 0x1, name: output. 0, 2298226224 uses ago
-
-```
-Steps to reproduce:
-1. Run `/opt/homebrew/bin/qemu-system-aarch64 -m 12048 -smp 8 -fw_cfg name=opt/com.coreos/config,file=$HOME/.config/containers/podman/machine/qemu/podman-machine-default.ign -qmp unix:$TEMP/podman/qmp_podman-machine-default.sock,server=on,wait=off -netdev socket,id=vlan,fd=3 -device virtio-net-pci,netdev=vlan,mac=5a:94:ef:e4:0c:ee -device virtio-serial -chardev socket,path=$TEMP/podman/podman-machine-default_ready.sock,server=on,wait=off,id=apodman-machine-default_ready -device virtserialport,chardev=apodman-machine-default_ready,name=org.fedoraproject.port.0 -pidfile $TEMP/podman/podman-machine-default_vm.pid -accel hvf -accel tcg -cpu host -M virt,highmem=on -drive file=/opt/homebrew/share/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on -drive file=$HOME/.local/share/containers/podman/machine/qemu/podman-machine-default_ovmf_vars.fd,if=pflash,format=raw -virtfs local,path=$HOME,mount_tag=vol0,security_model=mapped-xattr -drive if=virtio,file=$HOME/.local/share/containers/podman/machine/qemu/podman-machine-default_fedora-coreos-37.20221127.2.0-qemu.aarch64.qcow2`
-2. Keep using the system and eventually `ssh localhost
-3.
-Additional information:
-network configuration
-![image](/uploads/9ca7b1aa00aee2d3b9151881988ea393/image.png)
-
-I will try to add more info as I get them
diff --git a/results/classifier/deepseek-2-tmp/output/network/1381639 b/results/classifier/deepseek-2-tmp/output/network/1381639
deleted file mode 100644
index fd654b9a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1381639
+++ /dev/null
@@ -1,16 +0,0 @@
-
-sys_eeprom.c:353: buffer too small
-
-[qemu-2.1.2/roms/u-boot/board/matrix_vision/mvblx/sys_eeprom.c:353]: (error) Buffer is accessed out of bounds.
-
-        char ethaddr[9];
-
-        sprintf(ethaddr, "%02X:%02X:%02X:%02X:%02X:%02X",
-            e.mac[0],
-            e.mac[1],
-            e.mac[2],
-            e.mac[3],
-            e.mac[4],
-            e.mac[5]);
-
-18 into 9 won't go. Suggest increase size of ethaddr.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1384892 b/results/classifier/deepseek-2-tmp/output/network/1384892
deleted file mode 100644
index 5368832d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1384892
+++ /dev/null
@@ -1,21 +0,0 @@
-
-RTL8168 NIC VFIO not working anymore since QEMU 2.1
-
-After upgrading QEMU from 2.0 to 2.1 (and libiscsi from 1.7.0 to 1.12 as a dependency) my two RTL8168 NICs stopped working.
-The NICs do not respond to any command and even the LEDs on the network connection turn off, a few seconds after the VM started.
-To get them back running I had to downgrade to 2.0 and restart the system.
-Unfortunately, I have no clue what to do or how to debug this problem since there are no specific errors logged.
-I tried two different VMs: Debian Wheezy and IPFire (see attachment for further details).
-The QEMU 2.1 changelog states "Support for RTL8168 NICs." so there were some major changes done, I guess.
-
-On the IPFire guest the kernel log shows many of these lines:
-r8169 0000:00:07.0 green1: rtl_eriar_cond == 1 (loop: 100, delay: 100)
-r8169 0000:00:07.0 green1: rtl_phy_reset_cond == 1 (loop: 100, delay: 1)
-
-On the Debian guest there is only:
-r8169 0000:00:07.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw into memory
-r8169 0000:00:07.0: lan0: link down
-ADDRCONF(NETDEV_UP): lan0: link is not ready
-
-The commandline for IPFire can be seen in the attachment. It is the same for Debian.
-There are also the complete kernel logs for the working (2.0) and non-working (2.1) cases.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1385 b/results/classifier/deepseek-2-tmp/output/network/1385
deleted file mode 100644
index fb9324aa..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1385
+++ /dev/null
@@ -1,2 +0,0 @@
-
--net option doesn't work
diff --git a/results/classifier/deepseek-2-tmp/output/network/1388735 b/results/classifier/deepseek-2-tmp/output/network/1388735
deleted file mode 100644
index 4828e574..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1388735
+++ /dev/null
@@ -1,12 +0,0 @@
-
-QEMU no longer allows to use full TCP port range for VNC
-
-After upgrade to QEMU version 2.1.0 (Debian 2.1+dfsg-4ubuntu6), I am no longer able to use any TCP port for VNC display.
-For example, if I need to assign VNC server a TCP port 443, I used to run:
-# qemu-system-x86_64 -vnc :-5457
-qemu-system-x86_64: Failed to start VNC server on `:-1000': can't convert to a number:-5457
-expected behavior: as any VNC software, take port base of 5900, substract 5457 display number, and use TCP port 443
-
-I ask to change vnc port conversion routine to allow input values in range of all TCP ports, from 1 to 65535.
-
-I really depend on ability to use full TCP range for VNC port numbers, and inablity to do so in new version of QEMU is very disappointing.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1395217 b/results/classifier/deepseek-2-tmp/output/network/1395217
deleted file mode 100644
index 29282580..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1395217
+++ /dev/null
@@ -1,41 +0,0 @@
-
-Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11
-
-The networking code in qemu in versions 2.0.0 and beyond is non-functional with Solaris/Illumos 5.11 images. 
-
-Building 1.7.1, 2.0.0, 2.0.2, 2.1.2,and 2.2.0rc1with the following standard Slackware config:
-
-# From Slackware build tree . . . 
-./configure \
-  --prefix=/usr \
-  --libdir=/usr/lib64 \
-  --sysconfdir=/etc \
-  --localstatedir=/var \
-  --enable-gtk \
-  --enable-system \
-  --enable-kvm \
-  --disable-debug-info \
-  --enable-virtfs \
-  --enable-sdl \
-  --audio-drv-list=alsa,oss,sdl,esd \
-  --enable-libusb \
-  --disable-vnc \
-  --target-list=x86_64-linux-user,i386-linux-user,x86_64-softmmu,i386-softmmu \
-  --enable-spice \
-  --enable-usb-redir 
-
-
-And attempting to run the same VM image with the following command (or via virt-manager):
-
-macaddress="DE:AD:BE:EF:3F:A4"
-
-qemu-system-x86_64 nex4x -cdrom /dev/cdrom -name "Nex41" -cpu Westmere
--machine accel=kvm -smp 2 -m 4000 -net nic,macaddr=$macaddress  -net bridge,br=b
-r0 -net dump,file=/usr1/tmp/<FILENAME> -drive file=nex4x_d1 -drive file=nex4x_d2
- -enable-kvm
-
-Gives success on 1.7.1, and a deaf VM on all subsequent versions. 
-
-Notable in validating my config, is that a Windows 7 image runs cleanly with networking on *all* builds, so my configuration appears to be good - qemu just hates Solaris at this point.
-
-Watching with wireshark (as well as pulling network traces from qemu as noted above) it appears that the notable difference in the two configs is that for some reason, Solaris gets stuck arping for it's own interface on startup, and never really comes on line on the network.  If other hosts attempt to ping the Solaris instance, they can successfully arp the bad VM, but not the other way around.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1402289 b/results/classifier/deepseek-2-tmp/output/network/1402289
deleted file mode 100644
index b15dd1e1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1402289
+++ /dev/null
@@ -1,11 +0,0 @@
-
-netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49
-
-Subj.
-
-This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 installer.
-
-Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14).
-Linux kernel: 3.17.6 and 3.18.0.
-
-Debug log for machine in the attachment.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1402755 b/results/classifier/deepseek-2-tmp/output/network/1402755
deleted file mode 100644
index 52201baf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1402755
+++ /dev/null
@@ -1,64 +0,0 @@
-
-qemu-kvm: e1000 RX ring is filled with partial-pkt of size 0
-
-Hello,
-We are using CentOS 6.5 with qemu-kvm-0.12.1.2-2.415 as a host of or VMs.
-In the VM we use e1000 as the NIC emulation.
-We've modified the e1000 driver to our needs. This modification start the RX engine while the RX ring is empty (RDH == RDT)
-and at a later stage we fill the RX descriptors with buffers. This scheme works well on intel chips and VMware.
-What we observe in this setup is that from time to time the RX ring is filled with "partial packets" of size 0 (meaning, DD bit is set,
-No other status bits are set and packet size is also 0).
-
-Looking at the e1000 RX routine in qemu-kvm you can observe the following flow:
-1. A packet is avail for receive:
-2. The routine checks for RCTL_EN - it is enabled
-3. The routine checks that the RDH equal RDT (they are as the ring is empty) but also checks if rxov is on (it is still off) so it doesn’t
-Exit as it is supposed to.
-4. The routine now updates the descriptor status with the DD bit (and vlan which we don’t care)
-5. The routine checks if a buffer address is not NULL (it is as NULL since we haven’t filled it yet) – so is logs something.
-6. The routine now updates the guest memory with this value (DD is 1) 
-7. The routine updates the check_rxov flag in order to allow ovf check the next time around. 
-(but ovf will not occur since in the next iteration RDH != RDT)
-8. The routine loops over all the descriptors with the NULL buffer (which is all our ring) and writes the DD bit
-9. We get this endless partial packet problem we see.
-
-qemu-kvm-0.12.1.2-2.415.el6_5.3/qemu-kvm-0.12.1.2/hw/e1000.c
-static ssize_t
-e1000_receive(VLANClientState *nc, const uint8_t *buf, size_t size)
-{
-: : :
-if (!(s->mac_reg[RCTL] & E1000_RCTL_EN))
-return -1;
-
-: : :
-do {
-if (s->mac_reg[RDH] == s->mac_reg[RDT] && s->check_rxov) {
-set_ics(s, 0, E1000_ICS_RXO);
-return -1;
-}
-base = ((uint64_t)s->mac_reg[RDBAH] << 32) + s->mac_reg[RDBAL] +
-sizeof(desc) * s->mac_reg[RDH];
-cpu_physical_memory_read(base, (void *)&desc, sizeof(desc));
-desc.special = vlan_special;
-desc.status |= (vlan_status | E1000_RXD_STAT_DD);
-if (desc.buffer_addr) {
-cpu_physical_memory_write(le64_to_cpu(desc.buffer_addr),
-(void *)(buf + vlan_offset), size);
-desc.length = cpu_to_le16(size);
-desc.status |= E1000_RXD_STAT_EOP|E1000_RXD_STAT_IXSM;
-} else // as per intel docs; skip descriptors with null buf addr
-DBGOUT(RX, "Null RX descriptor!!\n");
-cpu_physical_memory_write(base, (void *)&desc, sizeof(desc));
-
-: : :
-if (++s->mac_reg[RDH] * sizeof(desc) >= s->mac_reg[RDLEN])
-s->mac_reg[RDH] = 0;
-s->check_rxov = 1;
-: : :
-} while (desc.buffer_addr == 0);
-}
-
-
-A workaround is to enable the RX machine only after the descriptor ring is filled for the first time.
-
-Moti
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1404278 b/results/classifier/deepseek-2-tmp/output/network/1404278
deleted file mode 100644
index c1e67f21..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1404278
+++ /dev/null
@@ -1,11 +0,0 @@
-
-tap connections not working on windows host
-
-using latest qemu 2.2.0 64bit for windows host (installed from qemu-w64-setup-20141210.exe obtained from http://qemu.weilnetz.de/w64/  ),OpenVPN 2.6.3-I601 64bit tap adapter named tap01 and calling qemu using the following.
-
-qemu-system-x86_64.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img"
-
-where the image contains a slackware 14.0 64bit install.
-The tap is bridged with the real network adapter and the bridge is given an ip of 10.1.1.41 (which works as the ip for the windows host). The tap adapter (in network connections) shows connected when the qemu vm is running. inside the vm, the network is given an ip of 10.1.1.143 (the netmask and default gateway are the same for the virtual and real pc).
-fault.
-The vm cannot see the rest of the local network or visa-versa. This used to work in early (0.9 32bit) versions of qemu.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1414466 b/results/classifier/deepseek-2-tmp/output/network/1414466
deleted file mode 100644
index d8553fcf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1414466
+++ /dev/null
@@ -1,45 +0,0 @@
-
--net user,hostfwd=... is not working
-
-QEMU version: git a46b3aaf6bb038d4f6f192a84df204f10929e75c
-
- /opt/qemu.git/bin/qemu-system-aarch64 --version
-QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard
-
-Hosts:
-ovs - host machine (Ubuntu 14.04.1, x86_64)
-debian8-arm64 - guest 
-
-Guest start:
-user@ovs:~$ /opt/qemu.git/bin/qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic -smp 1 -m 512 -kernel vmlinuz-run -initrd initrd-run.img -append "root=/dev/sda2 console=ttyAMA0" -global virtio-blk-device.scsi=off -device virtio-scsi-device,id=scsi -drive file=debian8-arm64.img,id=rootimg,cache=unsafe,if=none -device scsi-hd,drive=rootimg -netdev user,id=unet -device virtio-net-device,netdev=unet -net user,hostfwd=tcp:127.0.0.1:1122-:22
-
-root@debian8-arm64:~# netstat -ntplu | grep ssh
-tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      410/sshd        
-tcp6       0      0 :::22                   :::*                    LISTEN      410/sshd       
-
-(no firewall in guest vm)
-
-user@ovs:~$ netstat -ntplu | grep 1122
-tcp        0      0 127.0.0.1:1122          0.0.0.0:*               LISTEN      18722/qemu-system-a
-
-user@ovs:~$ time ssh user@127.0.0.1 -p 1122
-ssh_exchange_identification: read: Connection reset by peer
-
-real	1m29.341s
-user	0m0.005s
-sys	0m0.000s
-
-Inside guest vm sshd works fine:
-root@debian8-arm64:~# ssh user@127.0.0.1 -p 22
-user@127.0.0.1's password: 
-....
-user@debian8-arm64:~$ exit
-logout
-Connection to 127.0.0.1 closed.
-
-root@debian8-arm64:~# ssh user@10.0.2.15 -p 22
-user@10.0.2.15's password: 
-...
-user@debian8-arm64:~$ exit
-logout
-Connection to 10.0.2.15 closed.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1424237 b/results/classifier/deepseek-2-tmp/output/network/1424237
deleted file mode 100644
index 2ec54bf5..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1424237
+++ /dev/null
@@ -1,46 +0,0 @@
-
-missing manpage for bridge.conf
-
-There's currently no (easy) way to figure out the form of content of `/etc/qemu/bridge.conf`. Some howtos (e.g. https://wiki.archlinux.org/index.php/QEMU#Bridged_networking_using_qemu-bridge-helper) mention `bridge.conf.sample` which is not available according to `apt-file` and the official wiki at wiki.qemu.org doesn't mention the file at all, it seems necessary, though, because specification of `-net nic -net bridge,br=bridge0` fails with `failed to get mtu of bridge `bridge0': No such device` (can't be investigated further because setup is completely unclear).
-
-ProblemType: Bug
-DistroRelease: Ubuntu 14.10
-Package: qemu 2.1+dfsg-4ubuntu6.4
-Uname: Linux 3.19.0-031900-generic x86_64
-ApportVersion: 2.14.7-0ubuntu8.2
-Architecture: amd64
-CurrentDesktop: Unity
-Date: Sat Feb 21 19:39:07 2015
-EcryptfsInUse: Yes
-InstallationDate: Installed on 2015-01-26 (25 days ago)
-InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
-KvmCmdLine:
- COMMAND         STAT  EUID  RUID   PID  PPID %CPU COMMAND
- kvm-irqfd-clean S<       0     0  1026     2  0.0 [kvm-irqfd-clean]
- qemu-system-x86 Sl+      0     0 25905 25904 11.9 qemu-system-x86_64 -boot c -hda ubuntu.img -m 2048 -smp 16 -enable-kvm -vnc :0,abc -k de -drive file=/dev/sda14,if=ide -net nic -net bridge,br=bridge0
- kvm-pit/25905   S        0     0 25948     2  0.0 [kvm-pit/25905]
-MachineType: LENOVO 20221
-ProcEnviron:
- TERM=xterm
- PATH=(custom, no user)
- XDG_RUNTIME_DIR=<set>
- LANG=de_DE.UTF-8
- SHELL=/bin/bash
-ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-031900-generic root=UUID=ac20c93a-0ec5-445a-98cd-941f0fbc0e50 ro rootflags=subvol=@
-SourcePackage: qemu
-UpgradeStatus: No upgrade log present (probably fresh install)
-dmi.bios.date: 07/12/2013
-dmi.bios.vendor: LENOVO
-dmi.bios.version: 71CN51WW(V1.21)
-dmi.board.asset.tag: No Asset Tag
-dmi.board.name: INVALID
-dmi.board.vendor: LENOVO
-dmi.board.version: 31900003WIN8 STD MLT
-dmi.chassis.asset.tag: No Asset Tag
-dmi.chassis.type: 10
-dmi.chassis.vendor: LENOVO
-dmi.chassis.version: Lenovo IdeaPad Z500 Touch
-dmi.modalias: dmi:bvnLENOVO:bvr71CN51WW(V1.21):bd07/12/2013:svnLENOVO:pn20221:pvrLenovoIdeaPadZ500Touch:rvnLENOVO:rnINVALID:rvr31900003WIN8STDMLT:cvnLENOVO:ct10:cvrLenovoIdeaPadZ500Touch:
-dmi.product.name: 20221
-dmi.product.version: Lenovo IdeaPad Z500 Touch
-dmi.sys.vendor: LENOVO
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1426 b/results/classifier/deepseek-2-tmp/output/network/1426
deleted file mode 100644
index 51c2b1c7..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1426
+++ /dev/null
@@ -1,39 +0,0 @@
-
-On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client
-Description of problem:
-I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client.  
-Windows spice client virtviewer won't start like it does under Linux.  
-The error message indicaes that the spice-server itself failed to open spice sockets
-The registry to handle ```spice://``` URI handler is configured.
-Steps to reproduce:
-1. just run command
-Additional information:
-URI handler in registry is configure using a regestry import file ```spiceproto.reg```
-```
-Windows Registry Editor Version 5.00
-
-[HKEY_CLASSES_ROOT\spice]
-"URL Protocol"=""
-
-[HKEY_CLASSES_ROOT\spice\DefaultIcon]
-@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
-
-[HKEY_CLASSES_ROOT\spice\Extensions]
-[HKEY_CLASSES_ROOT\spice\shell]
-[HKEY_CLASSES_ROOT\spice\shell\open]
-[HKEY_CLASSES_ROOT\spice\shell\open\command] 
-@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
-
-[HKEY_CLASSES_ROOT\spice+unix]
-"URL Protocol"=""
-
-[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon]
-@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
-
-[HKEY_CLASSES_ROOT\spice+unix\Extensions]
-[HKEY_CLASSES_ROOT\spice+unix\shell]
-[HKEY_CLASSES_ROOT\spice+unix\shell\open]
-[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] 
-@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
-```
-This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1438 b/results/classifier/deepseek-2-tmp/output/network/1438
deleted file mode 100644
index b4c8a592..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1438
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Allow to use QEMU sockets as a CAN bus backend
-Additional information:
-Good possible example how it can be done is via UDP multicast in `python-can` library:
-- https://python-can.readthedocs.io/en/master/interfaces/udp_multicast.html
-
-Another option, with less features is using a simple serial/character device like in:
-- https://python-can.readthedocs.io/en/master/interfaces/serial.html
diff --git a/results/classifier/deepseek-2-tmp/output/network/1441443 b/results/classifier/deepseek-2-tmp/output/network/1441443
deleted file mode 100644
index 77cfb70b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1441443
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Is there a way to create a 10G network interface for VMs in KVM2.0?
-
-
-
-We have installed & configured the KVM 2.0 (qemu-kvm 2.0.0+dfsg-2ubuntu1.10) on Ubuntu 14.04. The physical server is connected to 10G network, KVM is configured in Bridged mode But the issue is, when we create Network interface on VMs, we have only 1G device as an options for vmhosts. Is this the limit of the KVM or is there a way to create a 10G network interface for VMs? Available device models
-
-E1000
-Ne2k_pci
-Pcnet
-Rtl8139
-virtio
-
-Please find the network configuration details
-
-Source device : Host device vnet1 (Bridge ‘br0’)
-Device model : virtio 
-
-Network configuration in the host /etc/network/interfaces
-
-auto br0
-iface br0 inet static
-        address 10.221.x.10
-        netmask 255.255.255.0
-        network 10.221.x.0
-        broadcast 10.221.x.255
-        gateway 10.221.x.1
-        # dns-* options are implemented by the resolvconf package, if installed
-        dns-nameservers X.X.X.X
-        dns-search XXX.NET
-        bridge_ports em1
-        bridge_fd 0
-        bridge_stp off
-        bridge_maxwait 0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1451067 b/results/classifier/deepseek-2-tmp/output/network/1451067
deleted file mode 100644
index b6aed6be..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1451067
+++ /dev/null
@@ -1,36 +0,0 @@
-
--smb option requires full path for Samba sharing to work
-
-This issue has been reported on qemu-devel a looong time ago: https://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00141.html
-
-QEMU version 2.2.1-4 on Arch Linux x86_64
-
-Steps to reproduce:
-
-host$ mkdir share
-host$ chmod o+rwx share
-host$ qemu <other options> -smb share
-
-vm$ smbclient //10.0.2.4/qemu -N
-smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it
-Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1]
-tree connect failed: NT_STATUS_BAD_NETWORK_NAME
-vm$ poweroff
-
-Workaround:
-
-host$ qemu <other options> -smb /full/path/to/share
-
-vm$ $ smbclient //10.0.2.4/qemu -N
-smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it
-Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1]
-smb: \> ls
-  .                                   D        0  Sat May  2 19:57:31 2015
-  ..                                  D        0  Sat May  2 19:57:31 2015
-
-		961302540 blocks of size 1024. 637557248 blocks available
-smb: \> quit
-
-Please, please fix this gotcha, whether in the documentation or in code. it can cause some serious bouts of hair-pulling.
-
--Alain
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1461918 b/results/classifier/deepseek-2-tmp/output/network/1461918
deleted file mode 100644
index 52e40a2e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1461918
+++ /dev/null
@@ -1,19 +0,0 @@
-
-guest hangs after use ethtool to set scatter-gather on
-
-On the guests,  i have a rtl8139 nic,  I use ethtool to set  scatter-gather on ( ethtool -K eth0 sg on ),
-after that,   at host side,  I  use scp to send a file into guest.  As a result, guest hang.
-At that point qemu is using 100% of one host CPU, about 100% guest.
-
-If guest is centOS6.5, with no problem.
-
-
-
-The guest system is Fedora release 19(Kernel 3.11.10-200.fc19.x86_64).
-
-host system is debian 7.1.
-Kernel:3.10.0
-Qemu: 2.3.0
-
-cmd:
-/boot/qemu-2.3.0-bin/qemu-system-x86_64 -vnc :13 -enable-kvm -name fedora -smp sockets=1,cores=2 -cpu core2duo -nodefaults -vga cirrus -k en-us -boot menu=on,splash-time=8000 -m 2048 -usb -drive file=/boot/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -netdev type=tap,id=net0,ifname=200,script=/etc/kvm/vtp-bridge -device rtl8139,romfile=,mac=FE:FC:FE:5C:58:65,netdev=net0,bus=pci.0,addr=0x12,id=net0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1463909 b/results/classifier/deepseek-2-tmp/output/network/1463909
deleted file mode 100644
index 6cc2848e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1463909
+++ /dev/null
@@ -1,62 +0,0 @@
-
-virtio: networking not working when guest's eth0 is not in promiscuous mode
-
-We are unable to get http responses from qemu guest machine until interface inside qemu guest machine is in promiscuous mode.
-
-Our configuration is following:
-
-<pre>
-     ------------------------
-     |       Host server    |
-     ------------------------
-     |     /eth1.10(IP1)    |
-LAN2-|-eth1-eth1.11(IP2)    |
-     |     \eth1.12(IP3)    |
-     |                      |
-LAN1-|-eth0(IP4) <IP[1-4]>  |
-     |              /       |
-     |      iptables[nat]   |
-     |    /  ________________
-     |    |  | Guest system |
-     |  tap0-|-eth0(guestIP)|
-     ------------------------
-</pre>
-
-Host server is connected to LAN1 with eth0 and to LAN2 with eth1. eth0 has IP4 assigned. eth1 is connected to the switch in trunk mode that has vlans 10, 11 and 12 allows. Thus in Host systems we have eth1.10, eth1.11 and eth1.12 interfaces with IP1, IP2 and IP3 respectfully.
-
-Inside Host systems we start Guest system using following command:
-
-> qemu-system-x86_64 -m 3G -nographic -monitor stdio -serial none -kernel /vmlinuz -initrd /webiface.gz -hda /data/data.img -net nic,model=virtio,macaddr=fe:32:31:30:29:00 -net tap,ifname=tap0,script=no,downscript=no
-
-tap interface was created with commands:
-> ip tuntap add dev tap0 mode tap user user                                                                                              
-> ip addr add 172.31.31.253/30 brd + dev tap0
-> ip link set dev tap0 up
-
-
-Routing for packets comming from LAN1 or LAN2 to guest system is identical and is done by iptables DNAT target:
-
-> iptables -t nat -A PREROUTING -d <IP1> -p tcp --dport 8580 -j DNAT --to-destination <guest IP>:80
-...
-> iptables -t nat -A PREROUTING -d <IP4> -p tcp --dport 8580 -j DNAT --to-destination <guest IP>:80
-
-Now the problem is that requests for @http://<IP4>:8580/index.html@ stall, until we put eth0 on Guest system in promiscuous mode. Note this concerns only packets coming through eth0 on Host system. Requests for @http://<IP[1-3]>:8580/index.html@ work as the should!
-
-It is really strange how promiscuous mode of the interface on guest system affects the way it receives packets. So we did further debuging with tcpdump. 
-
-For interesting (broken) case when packets arrive through eth0 of Host system, using tcpdump, we found that syn requests are coming out at tap0 interface:
-
-> 12:40:11.049007 c2:30:61:72:8d:14 > fe:32:31:30:29:00, ethertype IPv4 (0x0800), length 74: <IP>.45661 > <guestIP>.80: Flags [S], seq 1998302974, win 29200, options [mss 1352,sackOK,TS val 3509464 ecr 0,nop,wscale 7], length 0
-
-but no packet arrives on guest's eth0 interface! We confirmed that with tcpdump running with promiscuous mode disabled. So packets gone out from tap0 but never archived eth0 of the Guest system! Of course, once we run tcpdump without -p, guest interface will run in promiscuous mode and all packets/traffic will be visible on Guest also and everything works as expected.
-
-ifconfig shows no drops on tap0 interface. I've check MAC addresses of tap0(c2:30:61:72:8d:14) and guest's eth0 (fe:32:31:30:29:00). I don't see problem here.
-
-We've tried with eth1 interface not configured (no vlans) and still have this problem.
-
-This is Ubuntu 12.04.4 LTS server system with 3.2.0-67-generic kernel and QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard. 
-
-Googling we found that similar problem was reported with much older system (but very few details unfortunately):
-http://www.serverphorums.com/read.php?12,28222
-
-We failed to find any confirmation that this problem was fixed in newer version. Is this a known bug? Any suggestions how to debug?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1467240 b/results/classifier/deepseek-2-tmp/output/network/1467240
deleted file mode 100644
index ca45be4d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1467240
+++ /dev/null
@@ -1,25 +0,0 @@
-
-Regression - bridged networking broken for Mac OS X guest
-
-Using the instructions at http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ for running Mac OS X Snow Leopard under QEMU, bridged networking is broken when using QEMU git. The result is that Mac OS X is unable to obtain an IP address using DHCP. It works in the latest stable release - QEMU 2.3.0.
-
-Replace "-netdev user,id=hub0port0" with "-netdev bridge,br=br0,id=hub0port0" when testing bridged networking.
-
-Bisecting the git repository shows the following bad commit:
-commit a90a7425cf592a3afeff3eaf32f543b83050ee5c
-Author: Fam Zheng <email address hidden>
-Date:   Thu Jun 4 14:45:17 2015 +0800
-
-    tap: Drop tap_can_send
-
-    This callback is called by main loop before polling s->fd, if it returns
-    false, the fd will not be polled in this iteration.
-
-    This is redundant with checks inside read callback. After this patch,
-    the data will be sent to peer when it arrives. If the device can't
-    receive, it will be queued to incoming_queue, and when the device status
-    changes, this queue will be flushed.
-
-    Signed-off-by: Fam Zheng <email address hidden>
-    Message-id: <email address hidden>
-    Signed-off-by: Stefan Hajnoczi <email address hidden>
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1469946 b/results/classifier/deepseek-2-tmp/output/network/1469946
deleted file mode 100644
index 956b21f6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1469946
+++ /dev/null
@@ -1,40 +0,0 @@
-
-guest can't get IP when create guest with bridge.
-
-Environment:
-------------
-Host OS (ia32/ia32e/IA64):ia32e
-Guest OS (ia32/ia32e/IA64):ia32e
-Guest OS Type (Linux/Windows):linux
-kvm.git Commit:aefbef10e3ae6e2c6e3c54f906f10b34c73a2c66
-qemu.git Commit:dc1e1350f8061021df765b396295329797d66933
-Host Kernel Version:4.1.0
-Hardware:Ivytown_EP, Haswell_EP
-
-
-Bug detailed description:
---------------------------
-when create guest with bridge, the guest can not get ip.
-
-note:
-1. fail rate: 3/5
-2. this is a qemu bug:
-kvm      + qemu   =  result
-aefbef10 + dc1e1350    =  bad 
-aefbef10 + a4ef02fd   =  good
-
-Reproduce steps:
-----------------
-1. create guest:
-qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -device virtio-net-pci,netdev=net0,mac=$random_mac -netdev tap,id=net0,script=/etc/kvm/qemu-ifup rhel6u5.qcow
-
-Current result:
-----------------
-guest can't get IP
-
-Expected result:
-----------------
-guest can get ip
-
-Basic root-causing log:
-----------------------
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1470720 b/results/classifier/deepseek-2-tmp/output/network/1470720
deleted file mode 100644
index 02989925..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1470720
+++ /dev/null
@@ -1,17 +0,0 @@
-
-high IRQ-TLB generates network interruptions
-
- we are having a problem in our hosts, all the vm running on them suddenly, and for some seconds, lost network connectivity.
-
-the root cause appears to be the increase of irb-tlb from low values (less than 20) to more than >100k, that spike only last for some seconds then everything goes back to normal
-
-i've upload an screenshot of collectd for one hypervisor here
-http://zumbi.com.ar/tmp/irq-tlb.png
-
-
-we have hosts running precise (qemu 1.5, ovs 2.0.2, libvirt 1.2.2 and kernel 3.13) where the issue is frequent. also we have an small % of our fleet running trusty (qemu 2.0.0 ovs 2.0.2 libvirt 1.2.2 and kernel 3.16) where the problem seemed to be nonexistent until today
-
-issue seems to be isolated to < 10% of our hypervisors, some hypervisors had this problem every few days, others only once or twice. our vm are a black box to us we don't know what users run on them, but mostly cpu and network bound workload.
-most of our guests run centos 6.5 (kernel 2.6.32)
-
-vm are bridged to a linuxbridge then veth wired to an ovs switch (neutron openvswitch agent setup)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1481990 b/results/classifier/deepseek-2-tmp/output/network/1481990
deleted file mode 100644
index 84b26ec1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1481990
+++ /dev/null
@@ -1,40 +0,0 @@
-
-2.3.0 build fails on Ubuntu 12.04
-
-Build of 2.3.0 fails on Ubuntu 12.04:
-
-sudo make clean
-sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu
-sudo make
-
-  GEN   config-host.h
-  GEN   qemu-options.def
-  GEN   qmp-commands.h
-  GEN   qapi-types.h
-  GEN   qapi-visit.h
-  GEN   qapi-event.h
-  GEN   trace/generated-events.h
-  GEN   trace/generated-tracers.h
-   ...
-
- CC    migration/qemu-file-stdio.o
-  CC    migration/xbzrle.o
-  CC    migration/rdma.o
-migration/rdma.c: In function ‘qemu_rdma_dump_id’:
-migration/rdma.c:706:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:707:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:707:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function)
-migration/rdma.c:707:37: note: each undeclared identifier is reported only once for each function it appears in
-migration/rdma.c:708:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:708:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function)
-migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’:
-migration/rdma.c:800:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:800:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function)
-migration/rdma.c:802:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:802:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function)
-migration/rdma.c:841:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-make: *** [migration/rdma.o] Error 1
-
-Build succeeds with
-
-sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu --disable-rdma
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1486 b/results/classifier/deepseek-2-tmp/output/network/1486
deleted file mode 100644
index ff6d6b6d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1486
+++ /dev/null
@@ -1,90 +0,0 @@
-
-LXD fails to create VM with QEMU 7.2.0: "../../net/net.c:1106: net_client_init1: Assertion `nc' failed."
-Description of problem:
-Beginning with QEMU 7.2.0, LXD is unable to launch virtual machines using the default network profile, which breaks the out-of-box experience if a user wishes to create a virtual machine. This worked correctly with QEMU 7.1.0.
-
-Multiple users across different Linux distributions are reporting this issue:
-- https://discuss.linuxcontainers.org/t/failed-adding-nic-netdev-monitor-is-disconnected/15946
-- https://forums.gentoo.org/viewtopic-p-8774212.html
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030365
-
-```
-gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm
-Creating debian-sid-vm
-Starting debian-sid-vm                        
-Error: Failed setting up device via monitor: Failed setting up device "eth0": Failed adding NIC netdev: Monitor is disconnected
-Try `lxc info --show-log local:debian-sid-vm` for more info
-gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm
-Name: debian-sid-vm
-Status: STOPPED
-Type: virtual-machine
-Architecture: x86_64
-Created: 2023/02/10 23:47 UTC
-
-Log:
-
-warning: tap: open vhost char device failed: Permission denied
-warning: tap: open vhost char device failed: Permission denied
-qemu-system-x86_64: ../../net/net.c:1106: net_client_init1: Assertion `nc' failed.
-
-```
-
-```
-gibmat@tharkun:~$ qemu-system-x86_64 --version
-QEMU emulator version 7.2.0 (Debian 1:7.2+dfsg-2)
-Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
-gibmat@tharkun:~$ lxc version
-Client version: 5.0.2
-Server version: 5.0.2
-```
-Steps to reproduce:
-1. Install LXD and QEMU 7.2.0
-2. `lxc launch images:debian/sid debian-sid-vm --vm`
-  - This will fail as reported above
-3. Downgrade to QEMU 7.1.0 (such as from https://snapshot.debian.org/package/qemu/1%3A7.1%2Bdfsg-2/)
-4. `lxc launch images:debian/sid debian-sid-vm --vm`
-  - Now VM creation is successful
-    ```
-    gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm
-    Creating debian-sid-vm
-    Starting debian-sid-vm
-    gibmat@tharkun:~$ lxc list
-    +---------------+---------+------+-----------------------------------------------+-----------------+-----------+
-    |     NAME      |  STATE  | IPV4 |                     IPV6                      |      TYPE       | SNAPSHOTS |
-    +---------------+---------+------+-----------------------------------------------+-----------------+-----------+
-    | debian-sid-vm | RUNNING |      | fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c (eth0) | VIRTUAL-MACHINE | 0         |
-    +---------------+---------+------+-----------------------------------------------+-----------------+-----------+
-    gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm
-    Name: debian-sid-vm
-    Status: RUNNING
-    Type: virtual-machine
-    Architecture: x86_64
-    PID: 2502
-    Created: 2023/02/11 15:08 UTC
-    Last Used: 2023/02/11 15:08 UTC
-    
-    Resources:
-      Processes: -1
-      Network usage:
-        eth0:
-          Type: broadcast
-          State: UP
-          Host interface: tap5efa7582
-          MAC address: 00:16:3e:b8:2e:8c
-          MTU: 1500
-          Bytes received: 3.13kB
-          Bytes sent: 164B
-          Packets received: 12
-          Packets sent: 2
-          IP addresses:
-            inet6: fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c/64 (global)
-    
-    Log:
-    
-    warning: tap: open vhost char device failed: Permission denied
-    warning: tap: open vhost char device failed: Permission denied
-    
-    gibmat@tharkun:~$ qemu-system-x86_64 --version
-    QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b3)
-    Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
-    ```
diff --git a/results/classifier/deepseek-2-tmp/output/network/1495380 b/results/classifier/deepseek-2-tmp/output/network/1495380
deleted file mode 100644
index 8dedcda1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1495380
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Invalid parameter 'queues'. multi-queue vhost-user backends does not work.
-
-The command line which I use:
-/usr/bin/qemu-system-x86_64 -name instance-00000006 -S -machine pc-i440fx-2.4,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/hugepages/libvirt/qemu,share=yes,size=1073741824 -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 54d61ffc-c8cf-4227-9610-96bcf1590984 -smbios type=1,manufacturer=OpenStack,product=OpenStack,version=2014.1.3,serial=44454c4c-3300-1043-804c-b5c04f463532,uuid=54d61ffc-c8cf-4227-9610-96bcf1590984 -no-user-config -nodefaults -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/54d61ffc-c8cf-4227-9610-96bcf1590984/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev socket,id=charnet0,path=/var/run/vrouter/uvh_vif_tap35abd3c0-4f -netdev type=vhost-user,id=hostnet0,chardev=charnet0,queues=5 -device virtio-net-pci,netdev=hostnet0,id=net0,mq=on,mac=02:35:ab:d3:c0:4f,bus=pci.0,mq=on,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/54d61ffc-c8cf-4227-9610-96bcf1590984/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 10.10.6.14:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
-
-The error information :
-2015-09-14T06:16:05.914264Z qemu-system-x86_64: -netdev type=vhost-user,id=hostnet0,chardev=charnet0,queues=5: Invalid parameter 'queues'
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1502095 b/results/classifier/deepseek-2-tmp/output/network/1502095
deleted file mode 100644
index 956d8e5a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1502095
+++ /dev/null
@@ -1,39 +0,0 @@
-
-Sporadic input / output error — x86-64 linux guest
-
-** Setup: **
-
-→ Host
-    Qemu version 2.4.0.1
-    Linux: 4.1.1 (Debian 8.2, GCC 4.9.2, x86_64)
-    filesystem ext3 and ext4
-
-→ Guests (3 VMs)
-    architecture x86_64, Linux 3.16.0-4-amd64 (Debian 7.6)
-    virtual disk qcow2, uncompressed
-    guests filesystem ext3
-    virtual disks size:  VM1: 3GB,  VM2: 5GB,  VM3: 250GB
-
-→ Network
-    bridge (br0) and tap interfaces.
-
-
-** Command line **
-
-For all 3 VMs, the command line is similar to the following. Only RAM size and ID ("109") are changed.
-
-    /usr/local/bin/qemu-system-x86_64 -hda /media/raid1/qemu-109 -m 8G -smp 4 -enable-kvm \
-        -netdev bridge,id=br109 -device virtio-net-pci,netdev=br109,id=nic0,mac=00:00:00:00:01:09 \
-        -k it -daemonize
-
-
-** Problem **
-
-Sporadic, unexplained input output error.
-When I try to SSH to one of the instances, most of the times everything just works fine. Some other times, the SSH connection can be established, but as I interact with the guests via SSH (ls, cd, top) the guest reports "input / output error" on the SSH console. Sometimes, the SSH daemon on the guest answers "/bin/bash input output error". Sometimes the SSH client answers that the connection has been dropped by the host.
-
-When this happens, the web services I run on the VMs get unreachable, the VMs themselves are unreachable/unusable via SSH as described, and after killing the relative qemu processes and restarting the VMs, no recent logs are registered on /var/logs, arguably since the time of the crash.
-
-This only happens to one VM at a time, independently. The other VMs appear to run fine when one VM encounters the problem.
-
-I which instructions to further debug this.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1513234 b/results/classifier/deepseek-2-tmp/output/network/1513234
deleted file mode 100644
index 7b88deb5..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1513234
+++ /dev/null
@@ -1,12 +0,0 @@
-
-Cannot ping guest from host after closing laptop lid, and re-opening
-
-I am running Ubuntu 15.10 (this issue also exists on 15.04) x64. Desktop environment to re-produce is either GNOME 3.16 or OpenBox-3. 
-
-I have a Windows 8.1 VM that I run with QEMU and I will work out of that for my job most of the day. When I am going to leave I like to just close my laptop lid, come home, and then get back at it. Unfortunately whenever I get home and open back up my laptop, I can no longer RDP into my VM and can no longer ping it from the host.
-
-If I open up Virt-Manager I can see the desktop via the Console page but cannot RDP into it with FreeRDP (I use FreeRDP all day on this machine so I know this works fine). 
-
-If I use the Console tab to login to the Windows VM again, I notice that I can ping the host from the guest and am connected to the internet. Just can't seem to communicate with the VM via its IP anymore.
-
-I have a NIC NAT virtual card and am using a Bridge
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1528214 b/results/classifier/deepseek-2-tmp/output/network/1528214
deleted file mode 100644
index 5f72bad5..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1528214
+++ /dev/null
@@ -1,38 +0,0 @@
-
-qemu 1.7.0 vhost_net crash
-
-i find the crash in  /var/crash 
-the crash content is :
-<4>Pid: 6949, comm: qemu-system-x86 Not tainted 2.6.32-431.el6.x86_64 #1 Powerleader PR2530G2/SC612DI-8F
-<4>RIP: 0010:[<ffffffff8118a849>]  [<ffffffff8118a849>] fput+0x9/0x30
-<4>RSP: 0018:ffff88015b601d98  EFLAGS: 00010292
-<4>RAX: 0000000000000382 RBX: ffff881e46590000 RCX: 00000000000001c3
-<4>RDX: 0000000000000000 RSI: ffff881e46590130 RDI: 0000000000000000
-<4>RBP: ffff88015b601d98 R08: ffff881e46598518 R09: 0000000000000000
-<4>R10: 0000000000000000 R11: 0000000000000246 R12: ffff881e46590010
-<4>R13: 0000000000000000 R14: ffff880c29812748 R15: 0000000000000000
-<4>FS:  00007f6a74d20700(0000) GS:ffff8810b8840000(0000) knlGS:0000000000000000
-<4>CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
-<4>CR2: 0000000000000030 CR3: 0000001c544cc000 CR4: 00000000001427e0
-<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
-<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
-<4>Process qemu-system-x86 (pid: 6949, threadinfo ffff88015b600000, task ffff880c1ed9c040)
-<4>Stack:
-<4> ffff88015b601e58 ffffffffa02ac3c8 ffff881e46590000 0000000000000000
-<4><d> ffff881e46590080 ffff881e46590078 ffff88015b601e38 0000000000000286
-<4><d> ffffffff00000000 0000000000000001 ffff88015b601e58 0000000000000282
-<4>Call Trace:
-<4> [<ffffffffa02ac3c8>] vhost_net_ioctl+0x328/0x5d0 [vhost_net]
-<4> [<ffffffff8119db42>] vfs_ioctl+0x22/0xa0
-<4> [<ffffffff8119dce4>] do_vfs_ioctl+0x84/0x580
-<4> [<ffffffff8118a7d1>] ? __fput+0x1a1/0x210
-<4> [<ffffffff8119e261>] sys_ioctl+0x81/0xa0
-<4> [<ffffffff810e1e5e>] ? __audit_syscall_exit+0x25e/0x290
-<4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
-<4>Code: fe ff ff 31 d2 48 89 de 83 cf ff ff d0 e9 da fe ff ff 48 89 df e8 28 64 04 00 e9 bb fe ff ff 0f 1f 00 55 48 89 e5 0f 1f 44 00 00 <f0> 48 ff 4f 30 0f 94 c0 84 c0 75 0b c9 c3 66 0f 1f
-84 00 00 00 
-<1>RIP  [<ffffffff8118a849>] fput+0x9/0x30
-<4> RSP <ffff88015b601d98>
-<4>CR2: 0000000000000030
-
-how the bug occure
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/153 b/results/classifier/deepseek-2-tmp/output/network/153
deleted file mode 100644
index 4b7c2211..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/153
+++ /dev/null
@@ -1,2 +0,0 @@
-
-SLIRP SMB silently fails with MacOS smbd
diff --git a/results/classifier/deepseek-2-tmp/output/network/1542965 b/results/classifier/deepseek-2-tmp/output/network/1542965
deleted file mode 100644
index 9367f38a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1542965
+++ /dev/null
@@ -1,6 +0,0 @@
-
-Failed to set NBD socket ubuntu 15.10 & nbd client 3.10
-
-Running command to mount using nbd fails
-with error
-/build/qemu-YZq7uh/qemu-2.3+dfsg/nbd.c:nbd_init():L670: Failed to set NBD socket
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1543 b/results/classifier/deepseek-2-tmp/output/network/1543
deleted file mode 100644
index 787b51ba..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1543
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Heap-use-after-free in e1000e_receive_internal
diff --git a/results/classifier/deepseek-2-tmp/output/network/1543163 b/results/classifier/deepseek-2-tmp/output/network/1543163
deleted file mode 100644
index a5156ccd..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1543163
+++ /dev/null
@@ -1,39 +0,0 @@
-
-VMs unable to boot from network with e1000 since 2.2
-
-With KVM/QEMU version 1.4, using e1000 NIC, virtual machines boot from network alright; they get an IP from DHCP server (machine A), then connect to Microsoft System Center (machine B) and proceed to boot into Windows PE, install images etc.
-
-However, with versions at least 2.2 and 2.5, using same NIC, virtual machines fail to boot from network; they still get an IP from A, but then fail "contacting B using gateway (0.0.0.0). Different NICs do not help except for i82551, which however causes problems further down the road (presumably because there is no driver for that card in PE (based on Windows 7/8/10)).
-
-Note that actual physical machines work.
-
-Wireshark reveals this:
-
-QEMU 1.4 + Intel e1000
-**********************
-1) client sends DHCP discover
-2) machine A answers, offers an IP, gateway and itself as next server
-3) machine B answers, offers no IP, but gateway and itself as next server
-4) client requests the IP
-5) machine A ACKs
-6) client sends unicast request for ??? to B
-7) B offers (unicast) a boot file (some .com)
-8) client sends another unicast request for ??? to B
-9) B again offers the boot file
-(then they chat a bit, B offers another file, client downloads some stuff via TFTP etc.)
-
-
-QEMU 2.2/2.5 + Intel e1000
-**************************
-1) client sends DHCP discover
-2) machine A answers, offers an IP, gateway and itself as next server
-3) machine B answers, offers no IP, but gateway and itself as next server
-4) client requests the IP
-5) machine A ACKs
-6) client sends _broadcast_ request for ??? to B
-7) B offers (likewise broadcast) a boot file
-8) client sends another request, this time unicast and claims "Client IP address = 0.0.0.0"
-(and it basically hangs)
-
-
-So, since some time after 1.4, QEMUlated machines with otherwise trusty e1000 can no longer boot from network and it might be due to different behaviour.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1544 b/results/classifier/deepseek-2-tmp/output/network/1544
deleted file mode 100644
index 841bab82..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1544
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Abort in net_tx_pkt_do_sw_fragmentation
diff --git a/results/classifier/deepseek-2-tmp/output/network/1545 b/results/classifier/deepseek-2-tmp/output/network/1545
deleted file mode 100644
index 8cf223cf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1545
+++ /dev/null
@@ -1,10 +0,0 @@
-
-SSL is out of date on website
-Description of problem:
-The Linux KVM website is running an out of date SSL certificate.
-Steps to reproduce:
-1. visit the website. https://www.linux-kvm.org/page/Main_Page
-2.
-3.
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/1545052 b/results/classifier/deepseek-2-tmp/output/network/1545052
deleted file mode 100644
index 1ac4af44..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1545052
+++ /dev/null
@@ -1,59 +0,0 @@
-
-RDMA migration will hang forever if target QEMU fails to load vmstate
-
-Get a pair of machines with infiniband support. On one host run
-
-$ qemu-system-x86_64 -monitor stdio -incoming rdma:ibme:4444 -vnc :1 -m 1000
-
-To start an incoming migration.
-
-
-Now on the other host, run QEMU with an intentionally different configuration (ie different RAM size)
-
-$ qemu-system-x86_64 -monitor stdio -vnc :1 -m 2000
-
-Now trigger a migration on this source host
-
-(qemu) migrate rdma:ibpair:4444
-
-
-You will see on the target host, that it failed to load migration:
-
-dest_init RDMA Device opened: kernel name mlx4_0 uverbs device name uverbs0, infiniband_verbs class device path /sys/class/infiniband_verbs/uverbs0, infiniband class device path /sys/class/infiniband/mlx4_0, transport: (2) Ethernet
-qemu-system-x86_64: Length mismatch: pc.ram: 0x7d000000 in != 0x3e800000: Invalid argument
-qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram'
-
-This is to be expected, however, at this point QEMU has hung and no longer responds to the monitor
-
-GDB shows the target host is stuck in this callpath
-
-#0  0x00007ffff39141cd in write () at ../sysdeps/unix/syscall-template.S:81
-#1  0x00007ffff27fe795 in rdma_get_cm_event.part.15 () from /lib64/librdmacm.so.1
-#2  0x000055555593e445 in qemu_rdma_cleanup (rdma=0x7fff9647e010) at migration/rdma.c:2210
-#3  0x000055555593ea45 in qemu_rdma_close (opaque=0x555557796770) at migration/rdma.c:2652
-#4  0x00005555559397cc in qemu_fclose (f=f@entry=0x5555564b1450) at migration/qemu-file.c:270
-#5  0x0000555555936b88 in process_incoming_migration_co (opaque=0x5555564b1450) at migration/migration.c:361
-#6  0x0000555555a25a1a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:79
-#7  0x00007fffef5b3110 in ?? () from /lib64/libc.so.6
-
-
-
-Now, back on the source host again, you would expect to see that the migrate command failed. Instead, this QEMU is hung too. 
-
-GDB shows the source host, migrate thread, is stuck in this callpath:
-
-#0  0x00007ffff391522d in read#1  0x00007ffff00efd93 in ibv_get_cq_event () at /lib64/libibverbs.so.1
-#2  0x00005555559403f2 in qemu_rdma_block_for_wrid (rdma=rdma@entry=0x7fff3d07e010, wrid_requested=wrid_requested@entry=4000, byte_len=byte_len@entry=0x7fff39de370c) at migration/rdma.c:1511
-#3  0x000055555594058a in qemu_rdma_exchange_get_response (rdma=0x7fff3d07e010, head=head@entry=0x7fff39de3780, expecting=expecting@entry=2, idx=idx@entry=0)
-    at migration/rdma.c:1648
-#4  0x0000555555941e71 in qemu_rdma_exchange_send (rdma=0x7fff3d07e010, head=0x7fff39de3840, data=0x0, resp=0x7fff39de3870, resp_idx=0x7fff39de3880, callback=0x0) at migration/rdma.c:1725
-#5  0x00005555559447e4 in qemu_rdma_registration_stop (f=<optimized out>, opaque=<optimized out>, flags=0, data=<optimized out>) at migration/rdma.c:3302
-#6  0x000055555593bc4b in ram_control_after_iterate (f=f@entry=0x5555564c20f0, flags=flags@entry=0) at migration/qemu-file.c:157
-#7  0x0000555555740b59 in ram_save_setup (f=0x5555564c20f0, opaque=<optimized out>) at /home/berrange/src/virt/qemu/migration/ram.c:1959
-#8  0x00005555557451c1 in qemu_savevm_state_begin (f=0x5555564c20f0, params=params@entry=0x555555f6f048 <current_migration.37991+72>)
-    at /home/berrange/src/virt/qemu/migration/savevm.c:919
-#9  0x00005555559381a5 in migration_thread (opaque=0x555555f6f000 <current_migration.37991>) at migration/migration.c:1633
-#10 0x00007ffff390edc5 in start_thread (arg=0x7fff39de4700) at pthread_create.c:308
-
-
-It should have aborted migrate and set the status to failed.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1546445 b/results/classifier/deepseek-2-tmp/output/network/1546445
deleted file mode 100644
index f3542330..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1546445
+++ /dev/null
@@ -1,22 +0,0 @@
-
-support vhost user without specifying vhostforce
-
-[Impact]
-
- * vhost-user falls back to virtio-net which causes performance lose without specifying the vhostforce option. But it should be the default behavior for vhost-user, since guests using PMD doesn't support msi-x.
-
-[Test Case]
-
-  create a vhost-user virtio backend without specifying the vhostforce option, i.e. -netdev type=vhost-user,id=mynet1,chardev=<char_dev_for_the_controll_channel>
-  start the VM
-  vhost-user is not enabled
-
-[Regression Potential]
-
- * none
-
-vhost user nic doesn't support non msi guests(like pxe stage) by default.
-Vhost user nic can't fall back to qemu like normal vhost net nic does. So we should
-enable it for non msi guests.
-
-The problem has been fix in qemu upstream  - http://git.qemu.org/?p=qemu.git;a=commitdiff;h=24f938a682d934b133863eb421aac33592f7a09e. And the patch needs to be backported to 1:2.2+dfsg-5expubuntu9.8 .
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1554451 b/results/classifier/deepseek-2-tmp/output/network/1554451
deleted file mode 100644
index 225952ff..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1554451
+++ /dev/null
@@ -1,15 +0,0 @@
-
-unable to create preallocated image with gluster network protocol
-
-Unable to create preallocated image with gluster protocol
-
-Version: qemu-img-0.12.1.2-2.479.el6.x86_64
-Platform: RHEL 6
-I have tried creating preallocated image as follows :
-
-qemu-img create -f qcow2 -o preallocation=full gluster://localhost/vol1/vm1.img 10G
-
-I see error a follows :
-[root@ ]# qemu-img create -f qcow2 -o preallocation=full gluster://localhost/rep3vol/vm1.img 5G
-Formatting 'gluster://dhcp37-61.lab.eng.blr.redhat.com/rep3vol/newvm3.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='full' 
-Unknown option 'preallocation'
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1556306 b/results/classifier/deepseek-2-tmp/output/network/1556306
deleted file mode 100644
index 71c5f130..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1556306
+++ /dev/null
@@ -1,25 +0,0 @@
-
- vhost-user: qemu stops processing packets under high load of traffic
-
-Description of problem:
-- qemu socket becomes full, causing qemu to send incomplete
-SET_VRING_CALL messages to vhost-user backend (without proper fd set in
-ancillary data).
-- after some time, some interrupts are lost, causing the VM to stop
-transmitting packets.
-
-How reproducible:
-Run a stress tests of a vhost-user interface using an UDP
-traffic generator. Traffic generator (IXIA) was connected to 2 physical ports that are in turn connected to 2 virtio ports through a linux bridge, VM
-(running linux) doing routing to forward packets between the 2 virtio ports.
-When traffic reaches high pps rates of small packets,
-
-Actual results:
-- VM stop transmitting packets
-
-Expected results:
-- VM should never stop transmitting packets
-
-Additional info:
-We do propose a fix at:
-  http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00652.html
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1560 b/results/classifier/deepseek-2-tmp/output/network/1560
deleted file mode 100644
index 625d63ec..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1560
+++ /dev/null
@@ -1,2 +0,0 @@
-
-SLIRP hostfwd_add ignores bind address and uses `INADDR_ANY`
diff --git a/results/classifier/deepseek-2-tmp/output/network/1569988 b/results/classifier/deepseek-2-tmp/output/network/1569988
deleted file mode 100644
index 54120c7a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1569988
+++ /dev/null
@@ -1,8 +0,0 @@
-
-[2.6] user network broken reaching foreign servers on Win64
-
-Both on master and, starting with 2016-03-22 builds from http://qemu.weilnetz.de/w64/, user mode network can't reach foreign servers. For example, wget http://mifritscher resolves the DNS, but then the message "network target couldn't be reached" occures. 2016-03-03 works fine. I suspect the IPv6 changes. My connection is IPv4 only.
-
-I tested via knoppix 7.6. The command line is
-
-qemu-system-x86_64.exe -m 512 -k de --cdrom c:\Users\michaelfritscher\Downloads\linux\KNOPPIX_V7.4.2DVD-2014-09-28-DE.iso -netdev user,id=mynet0,restrict=n -device e1000,netdev=mynet0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1573 b/results/classifier/deepseek-2-tmp/output/network/1573
deleted file mode 100644
index ce39874f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1573
+++ /dev/null
@@ -1,2 +0,0 @@
-
-TCP Previous segment not captured
diff --git a/results/classifier/deepseek-2-tmp/output/network/1574327 b/results/classifier/deepseek-2-tmp/output/network/1574327
deleted file mode 100644
index 58f66d16..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1574327
+++ /dev/null
@@ -1,17 +0,0 @@
-
-qemu-system-x86_64 -net nic,model=help outputs to stderr instead of std
-
-qemu-system-x86_64 -net nic,model=help
-
-output comes to stderr instead of std
-
-
-qemu-system-x86_64 -net nic,model=help  -> stdout
-qemu-system-x86_64 -machine help -> stdout
-qemu-system-x86_64 -cpu help -> stdout
-
-as of https://github.com/qemu/qemu/blob/044d65525f6ac2093042ae18dbf8c1300b5c1c18/net/net.c#L831
-
-I run qemu 2.5 on x86_64
-
-kind regards
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1579 b/results/classifier/deepseek-2-tmp/output/network/1579
deleted file mode 100644
index 1823caa8..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1579
+++ /dev/null
@@ -1,5 +0,0 @@
-
-Cache vdpa initialization & startup slow ioctls
-Additional information:
-* vring groups are cached in this patch, still not upstream [this example patch](https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg05961.html).
-* hw/virtio/vhost-vdpa.c and net/vhost-vdpa.c are both files that worth exploring.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1581695 b/results/classifier/deepseek-2-tmp/output/network/1581695
deleted file mode 100644
index e2569a29..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1581695
+++ /dev/null
@@ -1,19 +0,0 @@
-
-getifaddrs: Address family not supported by protocol
-
-Calling ip addr fails with the following error message:
-Cannot open netlink socket: Address family not supported by protocol
-
-
-My use case is running a docker raspberry pi arm container on Ubuntu 14.04 x64 with qemu-static.
-
-My steps to reproduce are the following:
-
-# docker pull philipz/rpi-raspbian:latest
-# docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian bash
-root@3b4ddc174279:/# ip addr
-Cannot open netlink socket: Address family not supported by protocol
-
-A fix or an workaround would be awesome.
-
-note: we are also working with a embedded arm distro which has no package manager available, would be nice if the workaround would not depend on apt-get
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1583784 b/results/classifier/deepseek-2-tmp/output/network/1583784
deleted file mode 100644
index 4acb73f2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1583784
+++ /dev/null
@@ -1,21 +0,0 @@
-
-qio_task_free segfault websocket
-
-When connecting with websocket and tls to a vnc-ws port I get segfault
-
-==15252== Process terminating with default action of signal 11 (SIGSEGV): dumping core
-==15252==  Access not within mapped region at address 0x0
-==15252==    at 0x1: ???
-==15252==    by 0x56E1E2: qio_task_free (task.c:58)
-==15252==    by 0x56E42B: qio_task_complete (task.c:145)
-==15252==    by 0x56DBB8: qio_channel_websock_handshake_send (channel-websock.c:289)
-==15252==    by 0x7B3F689: g_main_dispatch (gmain.c:3154)
-==15252==    by 0x7B3F689: g_main_context_dispatch (gmain.c:3769)
-==15252==    by 0x50D42A: glib_pollfds_poll (main-loop.c:213)
-==15252==    by 0x50D42A: os_host_main_loop_wait (main-loop.c:258)
-==15252==    by 0x50D42A: main_loop_wait (main-loop.c:506)
-==15252==    by 0x28A8D1: main_loop (vl.c:1934)
-==15252==    by 0x28A8D1: main (vl.c:4656)
-
-qemu 2.6.0
-linux x64
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1584 b/results/classifier/deepseek-2-tmp/output/network/1584
deleted file mode 100644
index ce39874f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1584
+++ /dev/null
@@ -1,2 +0,0 @@
-
-TCP Previous segment not captured
diff --git a/results/classifier/deepseek-2-tmp/output/network/1585432 b/results/classifier/deepseek-2-tmp/output/network/1585432
deleted file mode 100644
index 85742052..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1585432
+++ /dev/null
@@ -1,11 +0,0 @@
-
-magnum coe-service-list  returns error
-
-magnum running on centos7,
-
-I didn't create any services on k8s cluster,
-
-but I got the result as follows:
-
-[root@localhost ~(keystone_admin)]# magnum coe-service-list --bay k8sbay3
-ERROR: Field `ports[0][node_port]' cannot be None (HTTP 500) (Request-ID: req-c66b68dd-5437-47fa-a389-7cb56a262fa5)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1586756 b/results/classifier/deepseek-2-tmp/output/network/1586756
deleted file mode 100644
index ebd2e853..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1586756
+++ /dev/null
@@ -1,53 +0,0 @@
-
-"-serial unix:" option of qemu-system-arm is broken in qemu 2.6.0
-
-I found a bug of "-serial unix:PATH_TO_SOCKET" in qemu 2.6.0 (qemu 2.5.1 works fine).
-Occasionally, a part of the output of qemu disappears in the bug.
-
-It looks like following commit is the cause:
-
-char: ensure all clients are in non-blocking mode (Author: Daniel P. Berrange <email address hidden>)
-http://git.qemu.org/?p=qemu.git;a=commitdiff;h=64c800f808748522727847b9cdc73412f22dffb9
-
-In this commit, UNIX socket is set to non-blocking mode, but qemu_chr_fe_write function doesn't handle EAGAIN.
-You should fix code like that:
-
----
-diff --git a/qemu-char.c b/qemu-char.c
-index b597ee1..0361d78 100644
---- a/qemu-char.c
-+++ b/qemu-char.c
-@@ -270,6 +270,7 @@ static int qemu_chr_fe_write_buffer(CharDriverState *s, const uint8_t *buf, int
- int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
- {
-     int ret;
-+    int offset = 0;
- 
-     if (s->replay && replay_mode == REPLAY_MODE_PLAY) {
-         int offset;
-@@ -280,7 +281,21 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
-     }
- 
-     qemu_mutex_lock(&s->chr_write_lock);
--    ret = s->chr_write(s, buf, len);
-+
-+    while (offset < len) {
-+    retry:
-+        ret = s->chr_write(s, buf, len);
-+        if (ret < 0 && errno == EAGAIN) {
-+            g_usleep(100);
-+            goto retry;
-+        }
-+
-+        if (ret <= 0) {
-+            break;
-+        }
-+
-+        offset += ret;
-+    }
- 
-     if (ret > 0) {
-         qemu_chr_fe_write_log(s, buf, ret);
----
-
-Or please do "git revert 64c800f808748522727847b9cdc73412f22dffb9".
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1588591 b/results/classifier/deepseek-2-tmp/output/network/1588591
deleted file mode 100644
index a1876741..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1588591
+++ /dev/null
@@ -1,7 +0,0 @@
-
-Qemu 2.6 Solaris 8 Sparc telnet terminate itself
-
-With Qemu 2.6, Solaris 8 can be installed and run. However, it sometimes terminate itself with I/O thread spun for 1000 iterations. 
-
-qemu-system-sparc -nographic -monitor null -serial mon:telnet:0.0.0.0:3000,server -hda ./Sparc8.disk -m 256 -boot c -net nic,macaddr=52:54:0:12:34:56 -net tap,ifname=tap0,script=no,downscript=noQEMU waiting for connection on: disconnected:telnet:0.0.0.0:3000,server
-main-loop: WARNING: I/O thread spun for 1000 iterations
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/159 b/results/classifier/deepseek-2-tmp/output/network/159
deleted file mode 100644
index 1f8c015e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/159
+++ /dev/null
@@ -1,2 +0,0 @@
-
-qemu-nbd -l and -s options don't work together
diff --git a/results/classifier/deepseek-2-tmp/output/network/1593 b/results/classifier/deepseek-2-tmp/output/network/1593
deleted file mode 100644
index f7fe19d6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1593
+++ /dev/null
@@ -1,8 +0,0 @@
-
-SLIRP hostfwd ignores bind address and uses `INADDR_ANY`
-Description of problem:
-When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic).
-Additional information:
-The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777
-
-Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1604303 b/results/classifier/deepseek-2-tmp/output/network/1604303
deleted file mode 100644
index 140ea2f0..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1604303
+++ /dev/null
@@ -1,12 +0,0 @@
-
-Solaris on KVM/QEMU: WARNING rtls0: Failure resetting PHY
-
-When running Solaris (both version 10 and 11) on a QEMU/KVM virtual host, the Solaris guest displays this warning just after starting the system:
-WARNING rtls0: Failure resetting PHY.
-
-Although the networking seems to work fine.
-
-I have this network device model selected for the Solaris guest: rtl8139
-
-See also:
-http://www.linux-kvm.org/page/Guest_Support_Status#UNIX_Family:_Solaris.2FOpenSolaris
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1612908 b/results/classifier/deepseek-2-tmp/output/network/1612908
deleted file mode 100644
index 5addf283..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1612908
+++ /dev/null
@@ -1,8 +0,0 @@
-
-qom-[list,tree,get,set] don't accept tcp endpoint arg
-
-Hi, 
-
-I'm using origin/master [6bbbb0ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. 
-
-I have a patch to fix this issue that I can submit to the developer list.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1617929 b/results/classifier/deepseek-2-tmp/output/network/1617929
deleted file mode 100644
index 88eb1090..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1617929
+++ /dev/null
@@ -1,51 +0,0 @@
-
-qemu hangs in pselect syscall
-
-I'm using git commit d75aa4372f0414c9960534026a562b0302fcff29 (v2.7.0-rc4) configured with;
-    --enable-linux-user \
-    --disable-system \
-    --disable-tools \
-    --disable-guest-agent \
-    --static --disable-linux-aio \
-    --disable-fdt \
-    --without-pixman \
-    --disable-blobs \
-Stable version (v2.6.0) also have the same problem.
-
-In a chroot environment I ran below command-line to compile some things, different sources each time.
-    /usr/bin/qemu-arm -0 /usr/bin/edje_cc /usr/bin/edje_cc -id /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/images_mob/ -DBROWSER_RESOLUTION_720x1280=1 -DPROFILE_MOBILE=1 /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/edc/TextPopup_mob.edc /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/build-tizen/services/SimpleUI/720x1280_TextPopup.edj
-
-Here is back trace with gdb;
-#0  safe_syscall_end () at /usr/src/debug/qemu-2.6.94/linux-user/host/i386/safe-syscall.inc.S:78
-#1  0x60049370 in safe_pselect6 (nfds=10, readfds=0xffa31b5c, writefds=0xffa31bdc, exceptfds=0xffa31c5c, timeout=0x0, sig=0x0)
-    at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:855
-#2  0x6004b2fe in do_select (n=10, rfd_addr=1082122232, wfd_addr=1082122360, efd_addr=1082122488, target_tv_addr=0)
-    at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:1386
-#3  0x6005e5ba in do_syscall (cpu_env=0x640d0454, num=142, arg1=10, arg2=1082122232, arg3=1082122360, arg4=1082122488, arg5=0, arg6=1087473216, arg7=0, 
-    arg8=0) at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:9690
-#4  0x60045def in cpu_loop (env=0x640d0454) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:876
-#5  0x60047640 in main (argc=10, argv=0xffa33c84, envp=0xffa33cb0) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:4817
-
-Attached core file taken from gdb. To see the stack frame, you could try; 
-$ tar -xf reproduced_118_04.tar.bz2; gdb --core core.1823 qemu-arm
-
-And recent strace log for PID 1823(stucked one);
-79965 [  313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL)
-79966 [  313s]  ==>[pselect6(0xa)=]
-79967 [  313s]  [pselect6=0x1]<==
-79968 [  313s] 1823 :0x8e _newselect(10,[9,],[],[],NULL)
-79969 [  313s] 1823 :0x8e =>  = 0x00000001 ([9,],[],[],NULL)
-79970 [  313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3)
-79971 [  313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3)
-79972 [  313s] 1823 :0xfc =>  = 0
-79973 [  313s] 1823 :0x3 read(9,0x407fdeec,16)
-79974 [  313s] 1823 :0x3 read(9,0x407fdeec,16)
-79975 [  313s] 1823 :0x3 =>  = 8
-79976 [  313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0)
-79977 [  313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0)
-79978 [  313s] 1823 :0x107 =>  = 0
-79979 [  313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL)
-79980 [  313s]  ==>[pselect6(0xa)=]
-
-I'm using 64-bit Ubuntu with kernel release Linux 3.19.0-25-generic #26~14.04.1-Ubuntu.
-Reproducibility is low. One occurrence out of 50+ trials.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1626596 b/results/classifier/deepseek-2-tmp/output/network/1626596
deleted file mode 100644
index 4f1adae8..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1626596
+++ /dev/null
@@ -1,16 +0,0 @@
-
-Lockup with vhost network
-
-After using Qemu in this configuration successfully for quite a while, I changed two things:
-- moved the VM from a 8-core 4GHz host to a slower 2-core 1.6 Ghz machine
-- upgraded qemu from 2.1 to 2.5
-
-and almost immediately (in a couple hours) got hit with a vhost-related lockup.
-
-QEMU command line is:
-
-qemu-system-x86_64 -enable-kvm -daemonize -monitor unix:./monitor,server,nowait -cpu host -M q35 -balloon virtio -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd -drive if=none,id=hd,cache=writeback,aio=native,format=raw,file=xxxx.img,discard=unmap,detect-zeroes=unmap -device virtio-net-pci,netdev=net0,mac=xxxx -netdev tap,vhost=on,id=net0,script=xxxx.sh -usbdevice tablet -smp 2 -m 512 -vnc xxxx:yz
-
-VM was running fine, except no network traffic was passed from/to it. Shutting down the VM, it hung at "Will now halt." The QEMU process was unkillable, so the only choice was to sysrq-b the entire box.
-
-dmesg with sysrq-w attached.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1628971 b/results/classifier/deepseek-2-tmp/output/network/1628971
deleted file mode 100644
index b9cb36b4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1628971
+++ /dev/null
@@ -1,58 +0,0 @@
-
--netdev user: guestfwd doesn't work
-
-Hello!
-
-QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu4), Copyright (c) 2003-2008 Fabrice Bellard
-
-The IP address 192.168.1.46 is assigned to eth0.
-
-qemu-system-x86_64 \
-    -no-hpet \
-    -nodefconfig \
-    -machine accel=kvm \
-    -cpu host \
-    -smp 2 \
-    -drive if=virtio,file=yakkety-server-cloudimg-amd64.img \
-    -device virtio-net-pci,netdev=net0 \
-    -netdev 'user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842' \
-    -m 1024 \
-    -initrd yakkety-server-cloudimg-amd64-initrd-generic \
-    -kernel yakkety-server-cloudimg-amd64-vmlinuz-generic \
-    -append 'root=/dev/vda1 modprobe.blacklist=floppy systemd.log_level=debug systemd.journald.forward_to_console=1'
-
-Without the guestfwd=... part everything works nicely. With it I get the following message.
-
-
-qemu-system-x86_64: -netdev user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842: conflicting/invalid host:port in guest forwarding rule 'tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842'
-qemu-system-x86_64: -netdev user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842: Device 'user' could not be initialized
-
-
-But I just compiled c640f2849ee8775fe1bbd7a2772610aa77816f9f, and I get the same behavior.
-
-pas@strange:~/qemu/x86_64-softmmu$ ./qemu-system-x86_64 -net 'user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80'
-qemu-system-x86_64: -net user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80: conflicting/invalid host:port in guest forwarding rule 'tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80'
-qemu-system-x86_64: -net user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80: Device 'user' could not be initialized
-
-
-After poking a bit around it seems that this check fails in slirp/slirp.c: (around line 1074)
-
-    if ((guest_addr->s_addr & slirp->vnetwork_mask.s_addr) !=
-        slirp->vnetwork_addr.s_addr ||
-        guest_addr->s_addr == slirp->vhost_addr.s_addr ||
-        guest_addr->s_addr == slirp->vnameserver_addr.s_addr) {
-        return -1;
-    }
-
-Because guest_addr, and slirp has equivalent s_addr values.
-
-x86_64-softmmu/qemu-system-x86_64 -net 'user,net=10.0.2.0/24,host=10.0.2.2,guestfwd=tcp:12.0.0.2:80-cmd:echo ok'
-
-guest_addr: 12.0.0.2
-vnetwork_mask: 12.0.0.2
-vhost_addr: 12.0.0.2
-vnameserver_addr: 12.0.0.2
-guest_addr & mask: 12.0.0.2
-
-
-Thanks in advance for looking into this!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1640525 b/results/classifier/deepseek-2-tmp/output/network/1640525
deleted file mode 100644
index ee51e503..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1640525
+++ /dev/null
@@ -1,109 +0,0 @@
-
--net socket,connect/listen does not work in 2.7.0
-
-Using 2.7.0 release on Debian Sid. What I did: start one VM with:
-----
-/home/pierre/build/qemu/build/x86_64-softmmu/qemu-system-x86_64 \
--smp 4 \
--cpu Nehalem \
--soundhw ac97 \
--k fr \
--localtime \
--enable-kvm \
--m 4099 \
--drive file=/mnt/virtualMachines/qemu/lfs-7.10-porg.qcow2,cache=writeback \
--cdrom /mnt/virtualMachines/qemu/grub-img.iso \
--boot order=c,once=d,menu=on \
--vga std \
--serial mon:stdio \
--net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:58 \
--net user,vlan=0,hostfwd=tcp::2223-10.0.2.9:22 \
--net nic,vlan=1,model=e1000,macaddr=52:54:00:12:34:56 \
--net socket,vlan=1,listen=:4321
-----
-Start another one with:
-----
-/home/pierre/build/qemu/build/x86_64-softmmu/qemu-system-x86_64 \
--smp 4 \
--cpu Nehalem \
--soundhw ac97 \
--k fr \
--localtime \
--enable-kvm \
--m 4099 \
--drive file=/mnt/virtualMachines/qemu/lfs-7.10-october.qcow2,cache=writeback \
--cdrom /mnt/virtualMachines/qemu/grub-img.iso \
--boot order=c \
--serial mon:stdio \
--vga std \
--net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:57 \
--net socket,vlan=0,connect=localhost:4321
-----
-The network settings of the first machine are:
-----
-1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
-    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-    inet 127.0.0.1/8 scope host lo
-       valid_lft forever preferred_lft forever
-2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
-    link/ether 52:54:00:12:34:58 brd ff:ff:ff:ff:ff:ff
-3: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
-    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
-4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
-    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
-    inet 10.0.2.9/24 brd 10.0.2.255 scope global br0
-       valid_lft forever preferred_lft forever
-----
-The network settings on the second machine are:
-----
-1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
-    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-    inet 127.0.0.1/8 scope host lo
-       valid_lft forever preferred_lft forever
-2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
-    link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
-    inet 10.0.2.10/24 brd 10.0.2.255 scope global enp0s3
-       valid_lft forever preferred_lft forever
-----
-typing "ping -c 1 10.0.2.10" on the first machine returns:
-----
-PING 10.0.2.10 (10.0.2.10): 56 data bytes
-92 bytes from virtuallfs (10.0.2.9): Destination Host Unreachable
---- 10.0.2.10 ping statistics ---
-1 packets transmitted, 0 packets received, 100% packet loss
-----
-and something similar when typing "ping -c 1 10.0.2.9" on the second machine.
-
-This very same setting works as expected in version 2.6.0. I could bisect, and the offending commit is 16a3df403b1:
-----
-commit 16a3df403b10c4ac347159e39005fd520b2648bb
-Author: Zhang Chen <email address hidden>
-Date:   Fri May 13 15:35:19 2016 +0800
-
-    net/net: Add SocketReadState for reuse codes
-    
-    This function is from net/socket.c, move it to net.c and net.h.
-    Add SocketReadState to make others reuse net_fill_rstate().
-    suggestion from jason.
-    
-    v4:
-     - move 'rs->finalize = finalize' to rs_init()
-    
-    v3:
-     - remove SocketReadState init callback
-     - put finalize callback to net_fill_rstate()
-    
-    v2:
-     - rename ReadState to SocketReadState
-     - add SocketReadState init and finalize callback
-    
-    v1:
-     - init patch
-    
-    Signed-off-by: Zhang Chen <email address hidden>
-    Signed-off-by: Li Zhijian <email address hidden>
-    Signed-off-by: Wen Congyang <email address hidden>
-    Signed-off-by: Jason Wang <email address hidden>
-----
-
-BTW, the systems on both VM are built from http://www.linuxfromscratch.org. But I do not think this is important, since I could do the bisect. Of course, I'll be happy to try other VMs, if you point me to some.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1642421 b/results/classifier/deepseek-2-tmp/output/network/1642421
deleted file mode 100644
index 486a25c9..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1642421
+++ /dev/null
@@ -1,66 +0,0 @@
-
-qemu-system-x86_64: ipv6 and dns is broken with netdev user
-
-Hi,
-
-dhcp inside qemu returns an ipv6 address as dns-server. However this is not
-working. If i replace it with the ipv4 address '10.0.0.2' dns is working
-again. I would expect that the qemu emulated dhcp server responds either an
-ipv4 configuration that is working or its dns server/forwarder listens on the
-ipv6 address returned by the emulated dhcp server.
-
-I used latest qemu from git ( b0bcc86d2a87456f5a276f941dc775b265b309cf) and used the following commands:
-
-$ ./qemu-system-x86_64 -enable-kvm -M pc -device virtio-rng-pci -device
-virtio-net-pci,netdev=user.0 -drive file=buildenv.img,if=virtio,bus=1,unit=0
--no-reboot -netdev user,id=user.0,hostfwd=tcp::5022-:22,hostfwd=tcp::7587-:7588
--m 1024 -usb -nographic -smp 4
-
-buildenv.img is a debian jessie amd64 installation.
-
-Inside qemu the network is configured to use dhcp:
-
-$ cat /etc/network/interfaces
-allow-hotplug eth0
-iface eth0 inet dhcp
-
-$ ifconfig eth0
-eth0      Link encap:Ethernet  HWaddr 52:54:00:12:34:56
-          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
-          inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link
-          inet6 addr: fec0::5054:ff:fe12:3456/64 Scope:Site
-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
-          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
-          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
-          collisions:0 txqueuelen:1000
-          RX bytes:3215 (3.1 KiB)  TX bytes:3638 (3.5 KiB)
-
-$ cat /etc/resolv.conf
-nameserver fec0::3
-
-$ arp google.de
-google.de: Host name lookup failure
-
-$ strace -f arp google.de
-...
-socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
-connect(4, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "fec0::3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
-poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
-sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
-poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
-poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
-sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
-poll([{fd=4, events=POLLIN}], 1, 5000)  = 0 (Timeout)
-close(4)                                = 0
-...
-
-$ echo nameserver 10.0.0.2 > /etc/resolv.conf
-
-$ arp google.de
-google.de (216.58.208.35) -- no entry
-
-Note: I reported this bug also to debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844566
-
-Regards,
-
-  Manuel
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1643619 b/results/classifier/deepseek-2-tmp/output/network/1643619
deleted file mode 100644
index 25856ef2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1643619
+++ /dev/null
@@ -1,33 +0,0 @@
-
-netlink broken on big-endian mips
-
-Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159)
-
-As the summary says, netlink is completely broken on big-endian mips running qemu-user.
-
-Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes.
-
-[...]
-[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
-[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
-[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
-[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
-[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0
-[pid 11249] time([1479745823])          = 1479745823
-[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40
-[pid 11249] recvmsg(3,
-
-Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped.
-
-Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason.
-
---- a/linux-user/syscall.c
-+++ b/linux-user/syscall.c
-@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
- #ifdef TARGET_NR_socket
-     case TARGET_NR_socket:
-         ret = do_socket(arg1, arg2, arg3);
--        fd_trans_unregister(ret);
-         break;
- #endif
- #ifdef TARGET_NR_socketpair
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1656927 b/results/classifier/deepseek-2-tmp/output/network/1656927
deleted file mode 100644
index f9a9717a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1656927
+++ /dev/null
@@ -1,18 +0,0 @@
-
-Network (TCP) access regression
-
-Starting a VM with
-
-/usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winp
-ro.qcow,index=0,media=disk,format=qcow2 -m 4096 -vga vmware -vnc :3 -k en-us -device rtl8139,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfw
-d=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemonize
-
-in 2.5.1, all works fine
-
-in any version after 2.5.1.1, the network terminate TCP connections after a certain period .
-
-To reproduce, starts an app that use always connected TCP sockets (I am using Metatrader 4), let it run a an hour, the app does not realize the TCP is out of order but the TCP connection is closed by QEMU
-
-in 2.5.1.x, Metatrader works perfectly
-
-Thank you for your help
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1659267 b/results/classifier/deepseek-2-tmp/output/network/1659267
deleted file mode 100644
index 579f173c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1659267
+++ /dev/null
@@ -1,10 +0,0 @@
-
-It's not possible to start a VM with a network cable unplugged
-
-There should be a command line (sub)option to unplug a network cable.
-While from the monitor interface I can issue:
-
-set_link virtio-net-pci.0 off
-
-There's no way to fire a VM from command line with that cable already unplugged.
-As an example, virtualbox can do it.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/166 b/results/classifier/deepseek-2-tmp/output/network/166
deleted file mode 100644
index a01a5b25..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/166
+++ /dev/null
@@ -1,2 +0,0 @@
-
-qemu-bridge-helper failure but qemu not exit
diff --git a/results/classifier/deepseek-2-tmp/output/network/1662600 b/results/classifier/deepseek-2-tmp/output/network/1662600
deleted file mode 100644
index b3c9bb87..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1662600
+++ /dev/null
@@ -1,29 +0,0 @@
-
-error while building from source on Ubuntu 16.04
-
-I'm trying to build Qemu from source (from git) as specified here: http://www.qemu-project.org/download/#source
-
-Here is the git commit hash for the source: 7d2c6c95511e42dffe2b263275e09957723d0ff4
-
-During the 'make' step, I get the following error:
-
-migration/rdma.c: In function ‘qemu_rdma_dump_id’:
-migration/rdma.c:749:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:750:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:750:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function)
-migration/rdma.c:750:37: note: each undeclared identifier is reported only once for each function it appears in
-migration/rdma.c:751:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:751:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function)
-migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’:
-migration/rdma.c:850:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:850:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function)
-migration/rdma.c:852:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-migration/rdma.c:852:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function)
-migration/rdma.c:891:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’
-make: *** [migration/rdma.o] Error 1
-
-I searched around a bit, my problem seems related to this: https://patchwork.kernel.org/patch/992952/
-
-That issue makes me think my libibverbs may be out of date, but I checked and I have libibverbs-dev installed.  Is that the correct version?
-
-FYI, I installed libibverbs-dev as suggested here: http://wiki.qemu-project.org/index.php/Hosts/Linux#Recommended_additional_packages
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1668273 b/results/classifier/deepseek-2-tmp/output/network/1668273
deleted file mode 100644
index 8fda6a39..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1668273
+++ /dev/null
@@ -1,65 +0,0 @@
-
-DoS possible on - a QEMU process using userspace SLIRP?
-
-Steps to reproduce:
-
-- Launch a VM using QEMU:
-
-$ qemu-system-x86_64 -machine accel=kvm \
-                     -hda Fedora-Cloud-Base-25-1.3.x86_64.qcow2 \
-                     -m 2G \
-                     -smp 2 \
-                     -vnc :8 \
-                     -boot dc \
-                     -vga std \
-                     -cpu host \
-                     -net nic,vlan=0 \
-                     -net user,vlan=0,hostfwd=tcp::10024-:22,hostfwd=tcp::8082-:80
-
-- SSH into the VM, install httpd, start httpd
-
-$ ssh -p 10024 root@localhost 'dnf install -y httpd && systemctl start httpd'
-
-- Compile and run the following Java program:
-
-$ cat <<EOF > URLConnectionReader.java
-import java.net.*;
-import java.io.*;
-
-public class URLConnectionReader {
-    public static void main(String[] args) throws Exception {
-        int i = 0;
-        while (i < 1024) {
-            URL this_is_404 = new URL("http://localhost:8082/blah");
-            URLConnection yc = this_is_404.openConnection();
-            try {
-                BufferedReader in = new BufferedReader(new InputStreamReader(
-                            yc.getInputStream()));
-                String inputLine;
-                while ((inputLine = in.readLine()) != null)
-                    System.out.println(inputLine);
-                in.close();
-            } catch (Exception e) {
-                //HttpURLConnection urlConnection = (HttpURLConnection) yc;
-                //urlConnection.disconnect();
-            }
-            i++;
-        }
-        Thread.sleep(1000000000);
-    }
-}
-
-$ javac URLConnectionReader.java
-
-$ java URLConnectionReader &
-
-The java program tries to open a lot of HTTP connections, but never calls disconnect() on any.
-
-- Take a look at the list of open FDs of the qemu process:
-
-$ ls -tl /proc/${qemu-pid}/fd
-
-$ lsof -p ${qemu-pid}
-All of the TCP connections will be stuck at FIN_WAIT2
-
-The VM becomes unresponsive. Neither SSH or VNC works on this.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1672 b/results/classifier/deepseek-2-tmp/output/network/1672
deleted file mode 100644
index 040d5852..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1672
+++ /dev/null
@@ -1,9 +0,0 @@
-
-failed to migrate using multifd with multifd-channels larger than 2
-Description of problem:
-try to using multifd live migration on QEMU v8.0.0 using multifd channels larger than 2, but failed.
-Steps to reproduce:
-1. start source / dest qemu vm
-2. migrate_set_capability multifd on && migrate_set_parameter multifd-channels 8
-
-then live migration will failed
diff --git a/results/classifier/deepseek-2-tmp/output/network/1673722 b/results/classifier/deepseek-2-tmp/output/network/1673722
deleted file mode 100644
index 097a5c7d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1673722
+++ /dev/null
@@ -1,14 +0,0 @@
-
-Reading register at offset. It is not fully implemented warning make VM impossible to use
-
-Hi,
-
-Since this commit:
-https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347
-
-We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying:
-e1000: Reading register at offset: 0x00002410. It is not fully implemented. 
-
-User got so much of this warning that they can't use the VM. 
-
-Thanks for the help
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1682681 b/results/classifier/deepseek-2-tmp/output/network/1682681
deleted file mode 100644
index 38695c87..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1682681
+++ /dev/null
@@ -1,12 +0,0 @@
-
-qemu 2.5 network model rtl8139 collisions Ubuntu 16.04.2 LTS
-
-When I use NIC model rtl8139, I have a lot collisions and very low transfer.
-I tested that with brctl and Open vSwitch, because I thought that was a vSwitch issue. 
-When I change NIC model to virtio all works as expect.
-
-Host: Ubuntu 16.04.2 LTS
-Guest: Ubuntu 14.04.5 LTS - affected
-Guest: Ubuntu 16.04.2 LTS - not affected
-
-QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.10)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1683084 b/results/classifier/deepseek-2-tmp/output/network/1683084
deleted file mode 100644
index fc479d0f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1683084
+++ /dev/null
@@ -1,12 +0,0 @@
-
-DNS server not working in QEMU usermode networking
-
-Nslookup is returning "unknown host".
-I try to ping 10.0.2.3 and it fails. Pinging 10.0.2.2 and 10.0.2.15 works correctly.
-Downloading files via wget using a static IP works well.
-
-Results of qemu monitor command "info network" included as an attachment. 
-
-This bug was reported as a question on stack overflow: http://stackoverflow.com/questions/43308310/dns-server-not-working-in-qemu-usermode-networking.
-
-This bug exists on 2.8.0 and 2.9-rc3.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1687214 b/results/classifier/deepseek-2-tmp/output/network/1687214
deleted file mode 100644
index f40de55e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1687214
+++ /dev/null
@@ -1,16 +0,0 @@
-
-Rapid tremendous memory hog when using -net nic,vlan=0 -net user,vlan=0
-
-A rapid tremendous memory hog is occuring when I use -net nic,vlan=0 -net user,vlan=0. Tested with QEMU 2.8.0 & 2.9.0 in Gentoo. All available memory (8GB) + swap (over 20GB) is exhausted very rapidly. 
-
-This bug is possibly related to 
-https://bugs.launchpad.net/qemu/+bug/1310714 
-and maybe to
-https://bugs.launchpad.net/qemu/+bug/1288620
-
-The bug IS present wheh I use -net nic,vlan=0 -net user,vlan=0 (tested with no model and model=e1000 and model=virtio, with all these the bug is present)
-
-The bug is NOT present with I use this:
--netdev type=user,id=mynet0 -device virtio-net-pci,netdev=mynet0
-
-I tested this bug only using windows guests (Windows XP & Windows 8).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1687578 b/results/classifier/deepseek-2-tmp/output/network/1687578
deleted file mode 100644
index b986b1a6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1687578
+++ /dev/null
@@ -1,15 +0,0 @@
-
-when migrate vm, reboot in guest os, the guest os sometime hang
-
-qemu version:v2.9.0-rc5 release
-
-1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-inc qemu+ssh://10.59.163.38/system
-2.run reboot in guest os, add reboot in /etc/rc.local
-3.guest os hang sometime.
-
-strace output of qemu:
-
-ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout)
-ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 698000000}, NULL, 8) = 0 (Timeout)
-poll([{fd=20, events=POLLOUT}], 1, 0)   = 1 ([{fd=20, revents=POLLOUT|POLLHUP}])
-ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}], 6, {0, 999000000}, NULL, 8^C <unfinished ...>
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1687599 b/results/classifier/deepseek-2-tmp/output/network/1687599
deleted file mode 100644
index 72ea8dd4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1687599
+++ /dev/null
@@ -1,24 +0,0 @@
-
-Bind 2nd VM to same OVS vhost-user port caused 1st vm traffic broken 
-
-Binding 2nd VM to same OVS vhost-user port caused 1st vm traffic broken. If it illegal to share same vhost port, how about the first VM open the path exclusively?
-
-
-#OVS side to create the vhost-user port:
-ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
-ovs-vsctl add-port br0 phy0 -- set Interface phy0 type=dpdk options:dpdk-devargs=0000:0a:00.0
-ovs-vsctl add-port br0 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuser
-
-#QEMU VM1
-qemu-system-x86_64 -name vm1 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu1.qcow2  \
-  -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \
-  -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \
-  -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \  -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
-  -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off
-
-#VM2
-qemu-system-x86_64 -name vm2 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu2.qcow2  \
-  -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \
-  -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \
-  -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \  -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
-  -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1696180 b/results/classifier/deepseek-2-tmp/output/network/1696180
deleted file mode 100644
index 6d89a85c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1696180
+++ /dev/null
@@ -1,20 +0,0 @@
-
-Issues with qemu-img, libgfapi, and encryption at rest
-
-Hi,
-
-Encryption-at-rest has been supported for some time now.  The client is responsible for encrypting the files with a help of a master key file.  I have a properly setup environment and everything appears to be working fine but when I use qemu-img to move a file to gluster I get the following:
-
-
-# qemu-img convert -f raw -O raw linux.iso gluster://gluster01/virt0/linux.raw
-[2017-06-06 16:52:25.489720] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL
-[2017-06-06 16:52:25.490778] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL
-[2017-06-06 16:52:25.492263] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL
-[2017-06-06 16:52:25.497226] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_create+0x44d) [0x7f30f7a3cf5d] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL
-
-On and on until I get this message:
-
-[2017-06-06 17:00:03.467361] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-0: All subvolumes are down. Going offline until atleast one of them comes back up.
-[2017-06-06 17:00:03.467442] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-1: All subvolumes are down. Going offline until atleast one of them comes back up.
-
-I asked for help assuming it's a problem with glusterfs and was told it appears qemu-img's implementation of libgfapi doesn't call the xlator function correctly.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1696746 b/results/classifier/deepseek-2-tmp/output/network/1696746
deleted file mode 100644
index e907729d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1696746
+++ /dev/null
@@ -1,16 +0,0 @@
-
-netdev user,restrict=on prevents forwarded ports from being accessed from other systems
-
-I've got a guest only network and I'm wanting to access SSH on one of the guests externally.
-I'm using -netdev user,id=usernet0,hostfwd=tcp::2222-:22,restrict=yes -device virtio-net-pci,netdev=usernet0
-to forward 2222 to 22 in the guest.
-
-The docs state:
-restrict=on|off
-
-    If this option is enabled, the guest will be isolated, i.e. it will not be able to contact the host and no guest IP packets will be routed over the host to the outside. This option does not affect any explicitly set forwarding rules.
-
-
-However, with restrict=on, the forwarded port is only accessible from the host. Other systems receive no data.
-
-This was tested with qemu 2.8. Changelog for 2.9 doesn't mention any (relevant) user networking changes, so that should also fail.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1702798 b/results/classifier/deepseek-2-tmp/output/network/1702798
deleted file mode 100644
index 7ef57ac9..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1702798
+++ /dev/null
@@ -1,23 +0,0 @@
-
-colo: secondary vm can't receive any packet
-
-Following document 'COLO-FT.txt', I test colo feature on my hosts. It seems goes well,but I found the secondary vm can't receive any packets. I attached the process and find out the reason as follow, the filter-redirector(red0) didn't flush it's queue because the secondary vm in migrate state(RUN_STATE_INMIGRATE) :
-int qemu_can_send_packet(NetClientState *sender)
-{
-    int vm_running = runstate_is_running():
-
-    if (!vm_running) {         // it will return false on the secondary vm
-        return 0;
-    }
-    ------
-}
-
-How does it produce outbound packets in the secondary vm as it in migrate state?
-static void *qemu_kvm_cpu_thread_fn(void *arg)
-{
-    ------
-    do {
-        if (cpu_can_run(cpu)) {      // it will return false on the secondary vm
-            r = kvm_cpu_exec(cpu);
-    ------
-}
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1703147 b/results/classifier/deepseek-2-tmp/output/network/1703147
deleted file mode 100644
index 156fdba1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1703147
+++ /dev/null
@@ -1,9 +0,0 @@
-
-Xfer:features:read truncating xml sent to gdb frontends
-
-Around line 1326 in gdbstub.c:
-
-            if (len > (MAX_PACKET_LENGTH - 5) / 2)
-                len = (MAX_PACKET_LENGTH - 5) / 2;
-
-is truncating processor reg description xml files longer than 2045 bytes.  Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1708617 b/results/classifier/deepseek-2-tmp/output/network/1708617
deleted file mode 100644
index 8861ceb2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1708617
+++ /dev/null
@@ -1,30 +0,0 @@
-
-qemu2.9 meet a question using reconnect about ovs+dpdk
-
-env:
-qemu-2.9
-dpdk-16.11
-ovs-2.6.1
-host os:Linux compute 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
-guest os is same with host
-
-1. ovs service is normal
-2. start 2 qemu vm, using vhostuser port as server
-taskset 0x3f qemu-system-x86_64 -cpu host -smp 2,cores=2 -drive file=$QCOW2_IMAGE -m 4096M --enable-kvm -name $VM_NAME -nographic -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0,server -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6  -nographic -vnc :0 
-qemu-system-x86_64: -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0,server: QEMU waiting for connection on: disconnected:unix:/usr/local/var/run/openvswitch/dpdkvhostuser0,server
-
-taskset 0x3f qemu-system-x86_64 -cpu host -smp 2,cores=2 -drive file=$QCOW2_IMAGE -m 4096M --enable-kvm -name $VM_NAME -nographic -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0,server -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6  -nographic -vnc :0 
-qemu-system-x86_64: -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0,server: QEMU waiting for connection on: disconnected:unix:/usr/local/var/run/openvswitch/dpdkvhostuser1,server
-
-3. add br and vhostuser port as client
-ovs-vsctl add-br br1 -- set bridge br1 datapath_type=netdev
-ovs-vsctl add-port br1 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuserclient  options:vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostuser0"			
-ovs-vsctl add-port br1 dpdkvhostuser1 -- set Interface dpdkvhostuser1 type=dpdkvhostuserclient  options:vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostuser1"			
-			
-4. ping between 2 vm is ok
-5. restart ovs process
- systemctl restart openvswitch
-
-6. there is a question ping between 2 vm error
-
-7. change qemu from 2.9 to 2.7, everything become ok
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1711602 b/results/classifier/deepseek-2-tmp/output/network/1711602
deleted file mode 100644
index ef97b8b0..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1711602
+++ /dev/null
@@ -1,28 +0,0 @@
-
---copy-storage-all failing with qemu 2.10
-
-We fixed an issue around disk locking already in regard to qemu-nbd [1], but there still seem to be issues.
-
-$ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.196/system
-error: internal error: qemu unexpectedly closed the monitor: 2017-08-18T12:10:29.800397Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
-2017-08-18T12:10:48.545776Z qemu-system-x86_64: load of migration failed: Input/output error
-
-Source libvirt log for the guest:
-2017-08-18 12:09:08.251+0000: initiating migration
-2017-08-18T12:09:08.809023Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer
-2017-08-18T12:09:08.809481Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer
-
-Target libvirt log for the guest:
-2017-08-18T12:09:08.730911Z qemu-system-x86_64: load of migration failed: Input/output error
-2017-08-18 12:09:09.010+0000: shutting down, reason=crashed
-
-Given the timing it seems that the actual copy now works (it is busy ~10 seconds on my environment which would be the copy).
-Also we don't see the old errors we saw before, but afterwards on the actual take-over it fails.
-
-Dmesg has no related denials as often apparmor is in the mix.
-
-Need to check libvirt logs of source [2] and target [3] in Detail.
-
-[1]: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02200.html
-[2]: http://paste.ubuntu.com/25339356/
-[3]: http://paste.ubuntu.com/25339358/
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1713328 b/results/classifier/deepseek-2-tmp/output/network/1713328
deleted file mode 100644
index 47407fc6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1713328
+++ /dev/null
@@ -1,10 +0,0 @@
-
-Unable to C-a in -nographic if -serial telnet
-
-qemu-system-i386 (version 2.6.1, running on Linux/x86_64) started with:
-
-qemu-system-i386 -m 64M -machine type=pc -rtc base=localtime,clock=host -nographic -serial telnet:127.0.0.1:1234,server,nowait -net nic,model=ne2k_pci -net user,hostfwd=tcp:127.0.0.1:2200-:22,tftp=/
-
-does not accept the escape key (C-a) to perform functions such as switching from monitor to console. Verified both in GNU screen and in the Linux console.
-
-If '-serial telnet:127.0.0.1:1234,server,nowait' is removed from the command line, the escape key is accepted (and Qemu doesn't enter the monitor immediately).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1721952 b/results/classifier/deepseek-2-tmp/output/network/1721952
deleted file mode 100644
index 7ad4d078..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1721952
+++ /dev/null
@@ -1,17 +0,0 @@
-
-Network issue above 2.5.1.1
-
-Hi,
-WHen running a QEMU guest (Windows7) on a linux x86-64 server, the network stops working after some time for any version above 2.5.1.1
-
-In 2.5.1.1, all is fine (no issue with network)
-Any version ablve (trying 2.10.1 now), the application in windows stops accessing the internet after a while
-
-THis is my starting line:
-/usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winpro.qcow,index=0,media=disk,format=qco
-w2 -m 4096 -vga vmware -vnc :3 -k en-us -device e1000,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfwd=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemon
-ize
-
-Thisis my configure line:
-./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-kvm --disable-gtk --disable-xen --disable-user --enable-vnc-sasl --disable-libusb --disable-debug-info --disable-spi
-ce --enable-lzo --enable-pie --disable-werror --enable-linux-aio --enable-vhost-net --disable-tcmalloc --enable-vde --enable-nettle --disable-smartcard --enable-curl
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1723161 b/results/classifier/deepseek-2-tmp/output/network/1723161
deleted file mode 100644
index 3baa584e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1723161
+++ /dev/null
@@ -1,32 +0,0 @@
-
-Migration failing in qemu-2.10.1 but working qemu-2.9.1 and earlier with same options
-
-
-Qemu-2.10.1 migration failing with the following error:
-Receiving block device images
-qemu-system-x86_64: error while loading section id 2(block)
-qemu-system-x86_64: load of migration failed: Input/output error
-
-Migration is setup on the destination system of the migration using:
--incoming tcp:0:4444
-
-Migration is initiated from the source using the following commands in its qemu monitor:
-migrate -b "tcp:localhost:4444"
-
-The command-line used in both the source and destination is:
-qemu-system-x86_64 \
-        -nodefaults \
-        -pidfile vm0.pid \
-        -enable-kvm \
-        -machine q35 \
-        -cpu host -smp 2 \
-        -m 4096M \
-        -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly \
-        -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
-        -drive file=${HDRIVE},format=qcow2 \
-        -drive media=cdrom \
-        -usb -device usb-tablet \
-        -vga std -vnc :0 \
-        -net nic,macaddr=${TAPMACADDR} -net user,net=192.168.2.0/24,dhcpstart=192.168.2.10 \
-        -serial stdio \
-        -monitor unix:${MONITORSOCKET},server,nowait
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1724477 b/results/classifier/deepseek-2-tmp/output/network/1724477
deleted file mode 100644
index eb0a8b77..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1724477
+++ /dev/null
@@ -1,20 +0,0 @@
-
-Build-in websocket broken since v2.9.0-rc0
-
-Since upgrading to 2.9.0, the qemu's build-in websocket was no longer available. 
-
-Host: Ubuntu 16.04 LTS
-Command-line: /bin/qemu-system-x86_64 -enable-kvm -vnc 0.0.0.0:8,websocket
-
-I have tested the following qemu versions:
-
-master      Fail
-2.10.1      Fail
-2.9.1       Fail
-2.9.0       Fail
-2.9.0-rc3   Fail
-2.9.0-rc0   Fail
-
-2.8.1.1     Pass
-2.7.1       Pass
-2.6.2       Pass
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1724590 b/results/classifier/deepseek-2-tmp/output/network/1724590
deleted file mode 100644
index aa893c35..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1724590
+++ /dev/null
@@ -1,6 +0,0 @@
-
-Usermode networking hostfwd only listens on IPv4
-
-When forwarding ports in usermode networking (-net user,hostfwd=), QEMU binds to IPv4 only. Therefore, connecting to the port over IPv6 results in 'connection refused'.
-
-I experienced this in QEMU 2.10.1, but it looks to still be present in the current master (861cd431c99e56ddb5953ca1da164a9c32b477ca), since slirp_hostfwd in net/slirp.c uses in_addr instead of in6_addr.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1732 b/results/classifier/deepseek-2-tmp/output/network/1732
deleted file mode 100644
index 322bd094..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1732
+++ /dev/null
@@ -1,4 +0,0 @@
-
-Is there a way to disconnect the network of guest?
-Description of problem:
-When guest is running,I wan to disconnect the network(not detach the net),which should keep disconnect after migrate or restart if we not reconnect it againt.  Whether qemu has some ways to do it?
diff --git a/results/classifier/deepseek-2-tmp/output/network/1736655 b/results/classifier/deepseek-2-tmp/output/network/1736655
deleted file mode 100644
index 945ba131..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1736655
+++ /dev/null
@@ -1,21 +0,0 @@
-
-2k3/xp guests w/virtio-net randomly DHCP fail on boot
-
-Host:
-Debian GNU/Linux 9 with Linux 4.13.0-0.bpo.1-amd64
-QEMU 2.10.1
-
-Guest:
-Windows 2003 Standard SP2 (x64)
-Windows XP SP3 (i386)
-
-QEMU command line:
-http://cfp.vim-cn.com/cbdF3
-
-Description:
-After upgrading from QEMU 2.8 to 2.10.1, my Windows 2003 x64 and Windows XP guests with "virtio-net-pci" NIC would randomly fail to aquire DHCP address on boot. When it fails, cycle disable/enable the connection in Control Panel could make it connect successfully. As an immediate workaround, I switched to the RTL8139 NIC which works fine. Further investigation showed that manually reverting commit '4a3f03ba8dbf53fce36d0c1dd5d0cc0f340fe5f3' on top of 2.10.1 "fixed" the problem.
-
-Here are the test results:
-git branch 4a3f03b: 25 boots, 8 failures
-git branch 39f099e: 60 boots, 0 failure
-2.10.1 with revert: 194 boots, 0 failure
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1744009 b/results/classifier/deepseek-2-tmp/output/network/1744009
deleted file mode 100644
index 349fd812..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1744009
+++ /dev/null
@@ -1,15 +0,0 @@
-
-qemu for windows fails to use multicast socket as netdev
-
-My host OS is Windows 7 x64 SP1. I installed qemu for windows from https://qemu.weilnetz.de/w64/.The version is 2.10.1, qemu-w64-setup-20171006.exe. I run qemu with the following command:
-
-qemu-system-x86_64.exe -net nic -net socket,mcast=234.5.5.5:6000 disk1.qcow2
-
-It stopped with error:
-bind: Unknown error
-qemu-system-x86_64.exe: -net socket,mcast=234.5.5.5:6000: Device 'socket' could not be initialized
-
-Using the -netdev option has the same problem:
-qemu-system-x86_64.exe -netdev socket,id=hostnet0,mcast=234.5.5.5:6000 -device e1000,netdev=hostnet0 disk1.qcow2
-
-I tried many versions from https://qemu.weilnetz.de/w64/, but none of them could work.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1745895 b/results/classifier/deepseek-2-tmp/output/network/1745895
deleted file mode 100644
index 4435943d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1745895
+++ /dev/null
@@ -1,30 +0,0 @@
-
-Unable to migrate vhost-net to virtio-1.0-capable kernel
-
-I am running QEMU 2.11 (from upstream source, not Red Hat package) on stock RHEL 6 and RHEL 7 kernels. Only the RHEL 7 kernel supports VIRTIO_F_VERSION_1 in its vhost-net driver.
-
-When migrating a guest using vhost-net from the RHEL 6 host to RHEL 7, the PCI config is rejected by QEMU on the target machine.
-
-A simple test case:
-
-1. On the RHEL 7 host, prepare for an incoming migration:
-
-  rhel7# qemu-system-x86_64 -S -accel kvm -nographic -monitor stdio -nodefaults -netdev tap,id=net0,vhost=on,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=54:52:00:ff:ff:ff -incoming tcp:0.0.0.0:12345
-
-2. On the RHEL 6 host, start a guest and migrate it to the RHEL 7 host:
-
-  rhel6# qemu-system-x86_64 -S -accel kvm -nographic -monitor stdio -nodefaults -netdev tap,id=net0,vhost=on,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=54:52:00:ff:ff:ff
-QEMU 2.11.0 monitor - type 'help' for more information
-  (qemu) migrate tcp:rhel7:12345
-
-The RHEL 7 QEMU errors out:
-
-  qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x20 read: 0 device: c cmask: ff wmask: 0 w1cmask:0
-  qemu-system-x86_64: Failed to load PCIDevice:config
-  qemu-system-x86_64: Failed to load virtio-net:virtio
-  qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-net'
-  qemu-system-x86_64: load of migration failed: Invalid argument
-
-If I start the source QEMU with vhost=off, or the target QEMU with disable-modern=true, the migration is successful.
-
-My hunch here is that the target QEMU prepares the PCI device to support VIRTIO_F_VERSION_1, as that's available in the kernel there, but then fails to (or does not know to) disable this during the migration.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1754542 b/results/classifier/deepseek-2-tmp/output/network/1754542
deleted file mode 100644
index 7b5d8b2f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1754542
+++ /dev/null
@@ -1,69 +0,0 @@
-
-colo:  vm crash with segmentation fault
-
-I use Arch Linux x86_64
-both qemu 2.11.1 Zhang Chen's(https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10)
-Following document 'COLO-FT.txt',
-I test colo feature on my hosts
-
-I run this command
-Primary:
-sudo qemu-system-x86_64 -boot c   -enable-kvm -m 2048 -smp 2  -qmp stdio  -name primary \
--device piix3-usb-uhci \
--device usb-tablet -netdev tap,id=hn0,vhost=off \
--device virtio-net-pci,id=net-pci0,netdev=hn0 \
--drive if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,children.0.file.filename=/var/lib/libvirt/images/1.raw,children.0.driver=raw -S
-
-Secondary:
-sudo qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdio  -name secondary \
--device piix3-usb-uhci \
--device usb-tablet -netdev tap,id=hn0,vhost=off \
--device virtio-net-pci,id=net-pci0,netdev=hn0 \
--drive if=none,id=colo-disk0,file.filename=/var/lib/libvirt/images/2.raw,driver=raw,node-name=node0 \
--drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
-file.driver=qcow2,top-id=active-disk0,\
-file.file.filename=/mnt/ramfs/active_disk.img,\
-file.backing.driver=qcow2,\
-file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
-file.backing.backing=colo-disk0 \
--incoming tcp:0:8888
-
-Secondary:
-{'execute':'qmp_capabilities'}
-{ 'execute': 'nbd-server-start',
-  'arguments': {'addr': {'type': 'inet', 'data': {'host': '192.168.0.33', 'port': '8889'} } }
-}
-{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', 'writable': true } }
-
-Primary:
-{'execute':'qmp_capabilities'}
-{ 'execute': 'human-monitor-command',
-  'arguments': {'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=192.168.0.33,file.port=8889,file.export=colo-disk0,node-name=nbd_client0'}}
-{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': 'nbd_client0' } }
-{ 'execute': 'migrate-set-capabilities',
-      'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } }
-{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:192.168.0.33:8888' } }
-{ 'execute': 'migrate-set-parameters' , 'arguments':{ 'x-checkpoint-delay': 2000 } }
-
-Above are all OK.Two VM syncing.
-
-Primary:
-{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 'child': 'children.1'}}
-{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del blk-buddy0'}}
-
-Secondary:
-{ 'execute': 'nbd-server-stop' }
-{ 'execute': 'x-colo-lost-heartbeat' }
-
-But When I execute x-colo-lost-heartbeat.Primary run Secondary cash
-
-
- { 'execute': 'nbd-server-stop' }
-{"return": {}}
-qemu-system-x86_64: Disconnect client, due to: Unexpected end-of-file before all bytes were read
- { 'execute': 'x-colo-lost-heartbeat' }
-{"return": {}}
-qemu-system-x86_64: Can't receive COLO message: Input/output error
-**
-ERROR:/build/qemu/src/qemu-2.11.1/qom/object.c:907:object_unref: assertion failed (obj->ref > 0): (0 > 0)
-[1]    2972 abort      sudo /usr/bin/qemu-system-x86_64 -boot c -enable-kvm -m 2048 -smp 2 -qmp stdi
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1754605 b/results/classifier/deepseek-2-tmp/output/network/1754605
deleted file mode 100644
index fcab3cf2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1754605
+++ /dev/null
@@ -1,15 +0,0 @@
-
-ppc64 migration bad_dest test is failed with failed to connect to socket
-
-On ppc64le machine the following test failed.
-
-# QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/migration-test V=1
-/ppc64/migration/deprecated: OK
-/ppc64/migration/bad_dest: qemu-system-ppc64: Failed to connect socket: Connection refused
-OK
-/ppc64/migration/postcopy/unix: OK
-
-Head is at f6d81cdec807bb85325afedb536b17c5331483c7
-configured with options: configure --target-list=ppc64-softmmu
-
-This test case is added through 2c9bb29703caa8fd31078cc38b3b53762557c27c
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1758091 b/results/classifier/deepseek-2-tmp/output/network/1758091
deleted file mode 100644
index a149c266..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1758091
+++ /dev/null
@@ -1,16 +0,0 @@
-
-vmxnet3 unable to send IPv6 ESP packets
-
-My vmxnet3 network driver (in a closed source custom OS) is unable to send network packets that are structured as follows: Ethernet-Header(IPv6-Header(ESP(encrypted data))). I can verify that the packet is sent in the VM but is dropped in qemu. I first encountered this problem on qemu 2.10.1 but master is affected as well. After some debug printing in qemu I could identify the following call chain as being problematic:
-
-eth_is_ip6_extension_header_type
-eth_parse_ipv6_hdr
-net_tx_pkt_parse_headers
-net_tx_pkt_parse
-vmxnet3_process_tx_queue
-
-The problem seems to be the definition of the ESP header (https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) that does not follow the standard IPv6 extension header format starting with next type and length. Thus the parsed ext_hdr in eth_parse_ipv6_hdr does not contain valid data, in particular the length will contain bogus data and lead to a info->full_hdr_len that is larger than the packet itself and the loop would then try to read beyond the end of the packet.
-
-Using the e1000 driver I can send these packets. My guess is that the net_tx_pkt_parse function is not called in that case.
-
-My guess for a fix would be to remove "case IP6_ESP:" from eth_is_ip6_extension_header_type and not regard the ESP header as a IPv6 extension header. In a quick test this seems to fix the problem. But that should be verified by someone who is familiar with the code.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1761027 b/results/classifier/deepseek-2-tmp/output/network/1761027
deleted file mode 100644
index ef5a2ccf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1761027
+++ /dev/null
@@ -1,14 +0,0 @@
-
-Unexpected error: "AioContext polling is not implemented on Windows"
-
-When run it this error happens:
-Unexpected error in aio_context_set_poll_params() at /home/stefan/src/qemu/repo.or.cz/qemu/ar7/util/aio-win32.c:413:
-C:\Program Files\qemu\qemu-system-x86_64.exe: AioContext polling is not implemented on Windows
-
-This application has requested the Runtime to terminate it in an unusual way.
-Please contact the application's support team for more information.
-
-
-
-System:
-Windows 10 x64
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1770417 b/results/classifier/deepseek-2-tmp/output/network/1770417
deleted file mode 100644
index 491cb372..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1770417
+++ /dev/null
@@ -1,31 +0,0 @@
-
-Qemu can not parse long fqdns during drive-mirror
-
-During migration of an openstack booted instance, I got the following error:
-
-Apr 12 10:55:22 cmp1 libvirtd[4133]: 2018-04-12 10:55:22.133+0000: 4139: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'drive-mirror': error parsing address 'cmp0.sandriichenko-deploy-heat-virtual-mcp-pike-ovs-76.bud-mk.local:49153'
-
-A bit more info in libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1568939
-
-To reproduce it with qemu only, I followed the guide at https://github.com/qemu/qemu/blob/master/docs/interop/live-block-operations.rst#id21. On dest and source compute nodes, I launched an instance:
-
-qemu-system-x86_64 -display none -nodefconfig -M q35 -nodefaults -m 512 -blockdev node-name=node-TargetDisk,driver=qcow2,file.driver=file,file.node-name=file,file.filename=./test-instance-mirror.qcow2 -device virtio-blk,drive=node-TargetDisk,id=virtio0 -S -monitor stdio -qmp unix:./qmp-sock,server,nowait -incoming tcp:localhost:6666
-
-Then on dest node I launched nbd server:
-
-(qemu) nbd_server_start cmp0:49153
-(qemu) nbd_server_add -w node-TargetDisk
-
-On the source node:
-
-(qemu) drive_mirror -n  node-TargetDisk nbd:cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153:exportname=node-TargetDisk
-error parsing address 'cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153'
-
-When using short host name instead of FQDN address seems to be parsed fine:
-
-(qemu) drive_mirror -n  node-TargetDisk nbd:cmp0:49153:exportname=node-TargetDisk qcow2
-Image is not in qcow2 format
-
-(not sure why it is not a qcow2 format, as I have qcow2 image with raw backing file, but this is unrelated)
-
-QEMU version is 2.11.1 from bionic
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1777 b/results/classifier/deepseek-2-tmp/output/network/1777
deleted file mode 100644
index 43d0c748..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1777
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Allow logging of IP addresses of connections made to QEMU socket backends for e.g. VNC or SPICE console
diff --git a/results/classifier/deepseek-2-tmp/output/network/1779447 b/results/classifier/deepseek-2-tmp/output/network/1779447
deleted file mode 100644
index 16f594f0..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1779447
+++ /dev/null
@@ -1,13 +0,0 @@
-
-SLIRP SMB silently fails with MacOS smbd
-
-When using the -net user,id=net0,ipv6=off,smb=/path/to/share/option,hostfwd=tcp::19500-:22 I can successfully mount_smbfs the shared directory on the guest when QEMU is running on a Linux or FreeBSD host. However, on a MacOS host the mount_smbfs command just fails with
-`mount_smbfs: unable to open connection: syserr = Connection reset by peer`.
-After some debugging it turns out this is because the smbd shipped by macos is incompatible and doesn't use the same config file/command line arguments.
-
-I have since got it working by compiling the sources form samba.org and using the --smbd= configure option pointing to that binary.
-
-Would it be possible to print a warning message or even better abort the launch saying smbd is incompatible with QEMU if the -smb= flag is passed? It appears that smbd should die with an error code on invalid arguments so QEMU should be able to report that.
-
-
-This was happening with QEMU built from git sources at c1c2a435905ae76b159c573b0c0d6f095b45ebc6.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1783 b/results/classifier/deepseek-2-tmp/output/network/1783
deleted file mode 100644
index eb149043..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1783
+++ /dev/null
@@ -1,4 +0,0 @@
-
-Emulate Breakout Network Connections
-Additional information:
-This functionality is required to model/QA real-world implementations for datacenter fabrics in virtual environments. Break-out cabling is how port density is achieved in practice on modern optical fabrics.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1787505 b/results/classifier/deepseek-2-tmp/output/network/1787505
deleted file mode 100644
index 48578dfd..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1787505
+++ /dev/null
@@ -1,14 +0,0 @@
-
-Solaris host: no network connection, mouse pointer mismatch
-
-This is probably a bit far afield but on a Solaris 10 SPARC host (Sun M3000) running a Windows XP guest like this:
-
-./qemu-system-x86_64 -m 1024 -boot d  -smp 3 -net nic -net user -hda  /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
-
-the vnc server starts up and Windows boots normally.  However, there is no network connectivity.  There are no network devices visible in XP's Networking tab of Control Panel and a ping of the local router reports "unreachable".
-
-Also, the keyboard works fine but the guest mouse pointer is offset from the host mouse position by an amount that varies by screen position.  This makes it impossible to point to locations near the edge of the qemu window.  This seems to be a previously reported problem, but the suggested fix, " -device usb-tablet", prevents qemu from even starting:
-
-qemu-system-x86_64: -device usb-tablet: No 'usb-bus' bus found for device 'usb-tablet'
-
-The physical mouse is connected to the USB port of a Sun Ray 2fs controlling the M3000 via Sun Ray server.  I apologize if this is a configuration issue and not a bug but I don't know where else to report it and have been unable to find a solution in the documentation.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1791680 b/results/classifier/deepseek-2-tmp/output/network/1791680
deleted file mode 100644
index 0161e224..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1791680
+++ /dev/null
@@ -1,21 +0,0 @@
-
-network bridge does not work
-
-hi there
-
-the network bridge does not seem to work described as here: https://en.wikibooks.org/wiki/QEMU/Networking
-
-When i add that parameters in a 192.168.80.x subnet, my emulated raspbian ARM gets the IP 10.0.2.15.... While all other computers get 192.168.80.x
-
-The command i use is:
-
-
-qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000,mac=52:54:00:12:34:56 &
-
-
-Does not build up a network bridge to 192.168.80.x...
-
-The host system i use is win10 x64 v1803
-
-Best regards,
-Jan
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1793791 b/results/classifier/deepseek-2-tmp/output/network/1793791
deleted file mode 100644
index 6b9cb8f4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1793791
+++ /dev/null
@@ -1,18 +0,0 @@
-
-Crash with nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed
-
-Qemu version on both sides: 2.12.1
-Host A Linux: 4.9.76
-Host B Linux: 4.14.67
-
-While calling from Host A:
-virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource --persistent --verbose --copy-storage-all
-
-I get a qemu crash with:
-
-2018-09-21 16:12:23.073+0000: 14428: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f922c03d990
-qemu-system-x86_64: block/nbd-client.c:606: nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed.
-2018-09-21 16:12:41.230+0000: shutting down, reason=crashed
-2018-09-21 16:12:52.900+0000: shutting down, reason=failed
-
-It doesn't do it every time, but most of the time.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1809453 b/results/classifier/deepseek-2-tmp/output/network/1809453
deleted file mode 100644
index 1e562298..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1809453
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Windows  qemu download Big file bug in net user mode
-
-hi 
-
-Windows qemu with -net user downloading big files has a bug, -net tap is good!
-
-I suspect that the Slirp protocol has a bug on the Windows pc, which is normal on ubuntu.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1811533 b/results/classifier/deepseek-2-tmp/output/network/1811533
deleted file mode 100644
index a2a5e888..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1811533
+++ /dev/null
@@ -1,32 +0,0 @@
-
-Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer
-
-Host:
-Gentoo linux x86_64, kernel 4.20.1
-Qemu 3.1.0 
-CPU: Intel i7 6850K
-Chipset: X99
-
-Guest:
-Windows 10 Pro 64bit (1809)
-Machine type: pc-q35_3.1
-Hyper-V enlightenments: hv_stimer,hv_reenlightenment,hv_frequencies,hv_vapic,hv_reset,hv_synic,hv_runtime,hv_vpindex,hv_time,hv_relaxed,hv_spinlocks=0x1fff
-Memory: 16GB backed by 2MB huge pages
-
-Issue:
-Once guest is started, log gets flooded with:
-
-qemu-system-x86_64: vhost_region_add_section: Overlapping but not coherent sections at 103000
-
-or 
-
-qemu-system-x86_64: vhost_region_add_section:Section rounded to 0 prior to previous 1f000
-
-(line endings change)
-
-and as time goes guest loses network access (virtio-net-pci) and general performance diminishes to extent of freezing applications.
-
-Observations:
-1) problem disappears when hv_stimer is removed
-2) problem disappears when memory backing with huge pages is disabled
-3) problem disappears when machine type is downgraded to pc-q35_3.0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1814352 b/results/classifier/deepseek-2-tmp/output/network/1814352
deleted file mode 100644
index 73d4f8a6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1814352
+++ /dev/null
@@ -1,24 +0,0 @@
-
-SIOCGIFNAME takes a struct ifreq not an integer
-
-The ioctl SIOCGIFNAME takes a pointer to a struct ifreq, not an integer.  This leads to if_indextoname() not correctly returning interface names (well, not if they're longer than 4 characters including the trailing NULL ;-).
-
-This is observed on v3.1.0.
-
-The following one-line patch will be sent to the qemu-devel mailing list:
-
-"""
-diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
-index ae8951625f..37501f575c 100644
---- a/linux-user/ioctls.h
-+++ b/linux-user/ioctls.h
-@@ -178,7 +178,7 @@
- #endif /* CONFIG_USBFS */
- 
-   IOCTL(SIOCATMARK, IOC_R, MK_PTR(TYPE_INT))
--  IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(TYPE_INT))
-+  IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_int_ifreq)))
-   IOCTL(SIOCGIFFLAGS, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_short_ifreq)))
-   IOCTL(SIOCSIFFLAGS, IOC_W, MK_PTR(MK_STRUCT(STRUCT_short_ifreq)))
-   IOCTL(SIOCGIFADDR, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_sockaddr_ifreq)))
-"""
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1814381 b/results/classifier/deepseek-2-tmp/output/network/1814381
deleted file mode 100644
index 65b8b158..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1814381
+++ /dev/null
@@ -1,26 +0,0 @@
-
-qemu can't resolve ::1 when no network is available
-
-I'm not sure if this is a qemu thing or a getaddrinfo/glibc thing, or
-even just something about my laptop.  However we have a test failure
-in nbdkit which only occurs when my laptop is not connected to wifi or
-other networking.  It boils down to:
-
-  $ qemu-img info --image-opts "file.driver=nbd,file.host=::1,file.port=1234"
-  qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': addre
-ss resolution failed for ::1:1234: Address family for hostname not supported
-
-In a successful case it should connect to a local NBD server on port
-1234, but if you don't have that you will see:
-
-  qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': Faile
-d to connect socket: Connection refused
-
-I can ‘ping6 ::1’ fine.
-
-It also works if I replace ‘::1’ with ‘localhost6’.
-
-My /etc/hosts contains:
-
-127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
-::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1818880 b/results/classifier/deepseek-2-tmp/output/network/1818880
deleted file mode 100644
index e7f01563..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1818880
+++ /dev/null
@@ -1,31 +0,0 @@
-
-Deadlock when detaching network interface
-
-[Impact]
-Qemu guests hang indefinitely
-
-[Description]
-When running a Qemu guest with VirtIO network interfaces, detaching an interface that's currently being used can result in a deadlock. The guest instance will hang and become unresponsive to commands, and the only option is to kill -9 the instance.
-The reason for this is a dealock between a monitor and an RCU thread, which will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. The monitor thread will acquire the BQL for detaching the network interface, and fire up a helper thread to deal with detaching the network adapter. That new thread needs to wait on the RCU thread to complete the deletion, but the RCU thread wants the BQL to commit its transactions.
-This bug is already fixed upstream (73c6e4013b4c rcu: completely disable pthread_atfork callbacks as soon as possible) and included for other series (see below), so we don't need to backport it to Bionic onwards.
-
-Upstream commit: https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c
-
-$ git describe --contains 73c6e4013b4c
-v2.10.0-rc2~1^2~8
-
-$ rmadison qemu
-===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe   | amd64, ...
-     qemu | 1:2.11+dfsg-1ubuntu7    | bionic/universe           | amd64, ...
-     qemu | 1:2.12+dfsg-3ubuntu8    | cosmic/universe           | amd64, ...
-     qemu | 1:3.1+dfsg-2ubuntu2     | disco/universe            | amd64, ...
-
-[Test Case]
-Being a racing condition, this is a tricky bug to reproduce consistently. We've had reports of users running into this with OpenStack deployments and Windows Server guests, and the scenario is usually like this:
-1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface
-2) Stress the network interface with e.g. Windows HLK test suite or similar
-3) Repeatedly attach/detach the network adapter that's in use
-It usually takes more than ~4000 attach/detach cycles to trigger the bug.
-
-[Regression Potential]
-Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with autokpkgtest and scripted Qemu runs.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1819108 b/results/classifier/deepseek-2-tmp/output/network/1819108
deleted file mode 100644
index 6a65919a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1819108
+++ /dev/null
@@ -1,31 +0,0 @@
-
-qemu-bridge-helper failure but qemu not exit
-
-When qemu-bridge-helper run failed, its parent process qemu is still alive.
-This is my command line:
-
-qemu-system-x86_64 -curses -enable-kvm -cpu host -smp 4 -m 4096 \
-  -vnc :1 \
-  -kernel /data/xugang_vms/boot/vmlinuz \
-  -initrd /data/xugang_vms/boot/initram \
-  -append 'module_blacklist=drm,evbug net.ifnames=0 biosdevname=0 ROOTDEV=rootfs' \
-  -drive file=/data/xugang_vms/instances/vn7/rootfs.img,format=qcow2,if=virtio \
-  -monitor unix:/data/xugang_vms/var/monitor/vn7.sock,server,nowait \
-  -netdev bridge,br=vmbr99,helper="/root/bridgehelper --ns=kvm_1 ",id=n1 -device virtio-net,netdev=n1,mac=92:99:98:76:01:07
-
-"/root/bridgehelper" is self defined helper binary by me. But after bridge-helper exited with failure(not send fd to qemu process yet), the linux vm's console will be messed up. I checked the qemu source code(at net/tap.c) and found following snip:
-
-===>
-do {
-            fd = recv_fd(sv[0]);
-        } while (fd == -1 && errno == EINTR);
-        saved_errno = errno;
-
-        close(sv[0]);
-
-        while (waitpid(pid, &status, 0) != pid) {
-            /* loop */
-        }
-<=========
-
-why recv_fd will infinitely wait for recv? Maybe it shall waitpid and then recv_fd ?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1823458 b/results/classifier/deepseek-2-tmp/output/network/1823458
deleted file mode 100644
index 4fd9cb7e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1823458
+++ /dev/null
@@ -1,42 +0,0 @@
-
-race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu
-
-[impact]
-
-on shutdown of a guest, there is a race condition that results in qemu crashing instead of normally shutting down.  The bt looks similar to this (depending on the specific version of qemu, of course; this is taken from 2.5 version of qemu):
-
-(gdb) bt
-#0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
-#1  0x00005636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at /build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73
-#2  0x00005636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at /build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205
-#3  0x00005636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, dev=0x5636c1bf6b70)
-    at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195
-#4  0x00005636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, ring=0x7ffe65c087e0) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364
-#5  0x00005636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895
-#6  0x00005636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, vdev=vdev@entry=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262
-#7  0x00005636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, dev=dev@entry=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293
-#8  0x00005636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, ncs=0x5636c209d110, total_queues=total_queues@entry=1) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371
-#9  0x00005636c08d7745 in virtio_net_vhost_status (status=7 '\a', n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150
-#10 virtio_net_set_status (vdev=<optimized out>, status=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162
-#11 0x00005636c08ec42c in virtio_set_status (vdev=0x5636c2853338, val=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624
-#12 0x00005636c098fed2 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605
-#13 0x00005636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724
-#14 vm_stop (state=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407
-#15 0x00005636c085d240 in main_loop_should_exit () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883
-#16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931
-#17 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683
-
-
-[test case]
-
-unfortunately since this is a race condition, it's very hard to arbitrarily reproduce; it depends very much on the overall configuration of the guest as well as how exactly it's shut down - specifically, its vhost user net must be closed from the host side at a specific time during qemu shutdown.
-
-I have someone with such a setup who has reported to me their setup is able to reproduce this reliably, but the config is too complex for me to reproduce so I have relied on their reproduction and testing to debug and craft the patch for this.
-
-[regression potential]
-
-the change adds flags to prevent repeated calls to both vhost_net_stop() and vhost_net_cleanup() (really, prevents repeated calls to vhost_dev_cleanup()).  Any regression would be seen when stopping and/or cleaning up a vhost net.  Regressions might include failure to hot-remove a vhost net from a guest, or failure to cleanup (i.e. mem leak), or crashes during cleanup or stopping a vhost net.
-
-[other info]
-
-this was originally seen in the 2.5 version of qemu - specifically, the UCA version in trusty-mitaka (which uses the xenial qemu codebase).  However, this appears to still apply upstream, and I am sending a patch to the qemu list to patch upstream as well.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1823790 b/results/classifier/deepseek-2-tmp/output/network/1823790
deleted file mode 100644
index 6b3400d3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1823790
+++ /dev/null
@@ -1,22 +0,0 @@
-
-QEMU mishandling of SO_PEERSEC forces systemd into tight loop
-
-While building Debian images for embedded ARM target systems I detected that QEMU seems to force newer systemd daemons into a tight loop.
-
-My setup is the following:
-
-Host machine: Ubuntu 18.04, amd64
-LXD container: Debian Buster, arm64, systemd 241
-QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 1:3.1+dfsg-7)
-
-To easily reproduce the issue I have created the following repository:
-https://github.com/lueschem/edi-qemu
-
-The call where systemd gets looping is the following:
-2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 (Numerical result out of range)
-
-Furthermore I also verified that the issue is not related to LXD.
-The same behavior can be reproduced using systemd-nspawn.
-
-This issue reported against systemd seems to be related:
-https://github.com/systemd/systemd/issues/11557
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1824622 b/results/classifier/deepseek-2-tmp/output/network/1824622
deleted file mode 100644
index 1468496b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1824622
+++ /dev/null
@@ -1,11 +0,0 @@
-
-Qemu 4.0.0-rc3 COLO Primary Crashes with "Assertion `event_unhandled_count > 0' failed."
-
-Hello Everyone,
-Now with Qemu 4.0.0-rc3, COLO is finally working so I gave it a try, but the Primary is always crashing during Network use. Typing fast in ssh or running "top" with 0.1 second delay (change with 'd') reliably trigger the crash for me. I use the attached scripts to run Qemu, in my case both primary and secondary run on the same Host for testing purposes. See the files in the attached .tar.bz2 for more Info, they also contain a Coredump.
-
-Regards,
-Lukas Straub
-
-Configure CMDline:
-./configure --target-list=x86_64-softmmu,i386-softmmu --enable-debug-info
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1835 b/results/classifier/deepseek-2-tmp/output/network/1835
deleted file mode 100644
index 0e12cab2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1835
+++ /dev/null
@@ -1,19 +0,0 @@
-
-IPv4 guest/outbound port forwarding not working
-Description of problem:
-Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in `tcpdump` running on host.
-Steps to reproduce:
-1. Build libslirp, I am using HEAD @ master.
-1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`).
-1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`).
-1. Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address `guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655`. For image, I am using a ordinary Fedora 38 workstation live cdrom.
-1. In your guest OS (emulated enviroment), open a terminal and run `curl http://10.0.2.100:6657`, this sends a http get to the 
-slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response `::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -`, nothing but just `ls` the directory.
-5. Repeat step 4, you will see the `curl` command gets stuck.
-Additional information:
-I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side.
-
-
-
-
-![Screenshot_2023-08-17_at_11.45.02_AM](/uploads/2f93c50bba1105860f2b85226703d65b/Screenshot_2023-08-17_at_11.45.02_AM.png)
diff --git a/results/classifier/deepseek-2-tmp/output/network/1837094 b/results/classifier/deepseek-2-tmp/output/network/1837094
deleted file mode 100644
index 603dc055..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1837094
+++ /dev/null
@@ -1,15 +0,0 @@
-
-UndefinedBehaviorSanitizer crash around slirp::ip_reass()
-
-tag: v4.1.0-rc1
-
-./configure --enable-sanitizers --extra-cflags=-O1
-
-==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000008 (pc 0x00000046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130)
-==26130==The signal is caused by a WRITE memory access.
-==26130==Hint: address points to the zero page.
-    #0 0x0000561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55
-    #1 0x0000561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9
-    #2 0x0000561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18
-
-I only had access to the last packet which isn't the culprit, I'm now seeing how to log the network traffic of the guest to provide more useful information.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1837651 b/results/classifier/deepseek-2-tmp/output/network/1837651
deleted file mode 100644
index a749ed83..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1837651
+++ /dev/null
@@ -1,16 +0,0 @@
-
--netdev socket uses 100% cpu on Windows host
-
-On Windows hosts, any `-netdev socket` option (tcp listen, tcp connect, udp passing a fd) causes qemu to use 100% cpu. The guest still runs, but only sluggishly.
-
-A simple testcase is:
-
-> qemu-system-i386.exe -netdev socket,listen=:8000,id=n
-
-And, in another command prompt:
-
-> echo foo | nc.exe localhost 8000
-
-Where nc.exe is netcat.
-
-Tested on qemu 3.1 (from https://qemu.weilnetz.de/w64/) and 4.0 (self compiled).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1837909 b/results/classifier/deepseek-2-tmp/output/network/1837909
deleted file mode 100644
index 86f57053..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1837909
+++ /dev/null
@@ -1,34 +0,0 @@
-
-test-char fails if host has no network interfaces
-
-# ./tests/test-char 
-# random seed: R02S8602535bf831a74bca571d8c416d8161
-1..34
-# Start of char tests
-...
-ok 12 /char/websocket
-# Start of stdio tests
-# End of stdio tests
-# Start of socket tests
-# Start of server tests
-# Start of mainloop tests
-Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421:
-# 
-# address resolution failed for 127.0.0.1:42275: Name or service not known
-# 
-
-Aborted (core dumped)
-
-
-# ip a
-1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
-    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-    inet 127.0.0.1/8 scope host lo
-       valid_lft forever preferred_lft forever
-    inet6 ::1/128 scope host 
-       valid_lft forever preferred_lft forever
-
-
-This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available
-
-This host setup may seem niche, but it is what the 'mock' RPM build tool has by default. In Fedora we run the test suite during the RPM build, so the failing test causes a bit of pain for certain workflows
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1838228 b/results/classifier/deepseek-2-tmp/output/network/1838228
deleted file mode 100644
index 865e6f69..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1838228
+++ /dev/null
@@ -1,19 +0,0 @@
-
-Slirp Broadcast traffic
-
-Hi all,
-
-Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1)
-
-I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server.
-
-DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets.
-
-Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?)
-
-Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.)
-
-WDYT? Did I miss some configuration options or use too old a version?
-
-Thanks,
-Chris
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1839367 b/results/classifier/deepseek-2-tmp/output/network/1839367
deleted file mode 100644
index 70e2b9b4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1839367
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Wrong interrupts generated for I.MX6 FEC controller
-
-The imx_eth_update function in hw/net/imx_fec.c has the following comment (https://github.com/qemu/qemu/blob/864ab314f1d924129d06ac7b571f105a2b76a4b2/hw/net/imx_fec.c#L421-L445):
-
-    /*
-     * Previous versions of qemu had the ENET_INT_MAC and ENET_INT_MAC
-     * interrupts swapped. This worked with older versions of Linux (4.14
-     * and older) since Linux associated both interrupt lines with Ethernet
-     * MAC interrupts. Specifically,
-     * - Linux 4.15 and later have separate interrupt handlers for the MAC and
-     *   timer interrupts. Those versions of Linux fail with versions of QEMU
-     *   with swapped interrupt assignments.
-     * - In linux 4.14, both interrupt lines were registered with the Ethernet
-     *   MAC interrupt handler. As a result, all versions of qemu happen to
-     *   work, though that is accidental.
-     * - In Linux 4.9 and older, the timer interrupt was registered directly
-     *   with the Ethernet MAC interrupt handler. The MAC interrupt was
-     *   redirected to a GPIO interrupt to work around erratum ERR006687.
-     *   This was implemented using the SOC's IOMUX block. In qemu, this GPIO
-     *   interrupt never fired since IOMUX is currently not supported in qemu.
-     *   Linux instead received MAC interrupts on the timer interrupt.
-     *   As a result, qemu versions with the swapped interrupt assignment work,
-     *   albeit accidentally, but qemu versions with the correct interrupt
-     *   assignment fail.
-     *
-     * To ensure that all versions of Linux work, generate ENET_INT_MAC
-     * interrrupts on both interrupt lines. This should be changed if and when
-     * qemu supports IOMUX.
-     */
-
-Unfortunately, this behavior causes the QNX Sabrelite BSP (http://blackberry.qnx.com/en/developers/bsp) to hang on ethernet initialization. This is caused by the fact that QEMU is firing the ENET_INT_TS_TIMER timer interrupt unexpectedly (when the ENET_INT_MAC flag is set). The BSP functions correctly on the actual hardware, but it is unable to handle the deliberately incorrect interrupt firing by QEMU.
-
-From reading the comment, it appears that this behavior is necessary to support certain versions of Linux. However, it would be very useful to be able to restore the correct interrupt behavior (possibly via a command-line flag).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1840646 b/results/classifier/deepseek-2-tmp/output/network/1840646
deleted file mode 100644
index ec16bd64..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1840646
+++ /dev/null
@@ -1,12 +0,0 @@
-
-qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122: logical fault
-
-qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122:16: warning: Logical conjunction always evaluates to false: alen <= 0 && alen >= sizeof(args) - 1. [incorrectLogicOperator]
-
-Source code is
-
-   if (alen <= 0 && alen >= sizeof(args) - 1) {
-
-Maybe better code:
-
-   if (alen <= 0 || alen >= sizeof(args) - 1) {
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1843590 b/results/classifier/deepseek-2-tmp/output/network/1843590
deleted file mode 100644
index c76393b6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1843590
+++ /dev/null
@@ -1,24 +0,0 @@
-
-NBD tests  use hardcoded port 10810
-
-QEMU v3.1.0
-
-$ ./configure --block-drv-rw-whitelist=qcow2,raw,file,host_device,nbd,iscsi,rbd,blkdebug,luks,null-co,nvme,copy-on-read,throttle,vxhs,gluster [...]
-
-$ ./check -v -nbd 001 002 003 004 005 008 009 010 011 021 032 033 045 077 094 104 119 123 132 143 145 147 151 152 162 181 184 194 205 208 218 222
-[...]
-104         - output mismatch (see 104.out.bad)
---- tests/qemu-iotests/104.out	2018-12-11 17:44:35.000000000 +0000
-+++ tests/qemu-iotests/104.out.bad	2019-09-11 11:59:11.822058653 +0000
-@@ -6,7 +6,7 @@
- file format: IMGFMT
- virtual size: 1.0K (1024 bytes)
- Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1234
--image: TEST_DIR/t.IMGFMT
--file format: IMGFMT
--virtual size: 1.5K (1536 bytes)
-+Failed to find an available port: Address already in use
-+qemu-img: Could not open 'nbd:127.0.0.1:10810': Failed to connect socket: Connection refused
-+./common.rc: line 203: kill: (28391) - No such process
- ***done
-Failed 1 of 32 tests
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1848556 b/results/classifier/deepseek-2-tmp/output/network/1848556
deleted file mode 100644
index 6a11acc4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1848556
+++ /dev/null
@@ -1,11 +0,0 @@
-
-qemu-img check failing on remote image in Eoan
-
-The "qemu-img check" function is failing on remote (HTTP-hosted) images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils version 1:3.1+dfsg-2ubuntu3.5, the following worked:
-
-$ /usr/bin/qemu-img check  http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
-No errors were found on the image.
-19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
-Image end offset: 514064384
-
-The 10.193.37.117 server holds an Apache server that hosts the cloud images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-0ubuntu9, the same command never returns. (I've left it for up to an hour with no change.) I'm able to wget the image from the same server and installation on which qemu-img check fails. I've tried several .img files on the server, ranging from Bionic to Eoan, with the same results with all of them.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1853123 b/results/classifier/deepseek-2-tmp/output/network/1853123
deleted file mode 100644
index 68893771..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1853123
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Memory synchronization error between kvm and target, e1000(dpdk)
-
-Hi folks.
-
-I use linux with dpdk drivers on the target system, and e1000 emulation device with tap interface for host. I use kvm for accelerate.
-Version qemu 4.0.94 and master (Nov 12 10:14:33 2019)
-Version dpdk stable-17.11.4
-Version linux host 4.15.0-66-generic (ubuntu 18.04)
-
-I type command "ping <target ip> -f" and wait about 1-2 minutes. Network subsystem freezes.
-
-For receive the eth pack from host system (tap interface) to host system the e1000 using ring buffer. 
-
-The e1000 write body of eth pack, set E1000_RXD_STAT_DD flag and move RDH (Ring Device Head).
-(file hw/net/e1000.c function e1000_receive_iov() )
-
-The dpdk driver is reading from E1000_RXD_STAT_DD flags (ignoring RDH), if flag is set: read buffer, unset flag E1000_RXD_STAT_DD and move RDT (Ring Device Tail).
-(source drivers/net/e1000/em_rxtx.c function eth_em_recv_scattered_pkts() )
-
-I see what the driver unet E1000_RXD_STAT_DD (rxdp->status = 0; ), but sometimes rxdp->status remains equal to 7. On the next cycle, this this buffer is read, RDT moved to far. RDH becomes equal RDT and network is freezes.
-
-If I insert some delay after unset E1000_RXD_STAT_DD, and repeatedly unset E1000_RXD_STAT_DD (if rxdp->status == 7 ), then all work fine.
-If check E1000_RXD_STAT_DD without delay, status rxdp->status always valid.
-
-This only appears on kvm. If I use tcg all works fine.
-
-I trying set watchpoint for memory on the qemu (for tcg), and see, that for one package cycle of set/unse STAT_DD repeated once.
-
-I trying set watchpoint for memory on the qemu (for kvm), and see, that rxdp->status changed to 0(unset) only once, but is changes immediately before set flag. 
-
-
-Please help me with advice on how to catch and fix this error. 
-Theoretically, it would help me to trace the memory access when writing to E1000_RXD_STAT_DD, RHD and RDT, both from the target and the host system. But I have no idea how this can be done.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1855535 b/results/classifier/deepseek-2-tmp/output/network/1855535
deleted file mode 100644
index bcf49f72..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1855535
+++ /dev/null
@@ -1,43 +0,0 @@
-
-Connection reset by peer when using port fwd
-
-$ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp cores=8 -serial mon:stdio -nographic \
--drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \
--device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
--cdrom /qemu/aix72.iso \
--prom-env boot-command='boot disk:' \
--name ctsprod -k es \
--netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \
--device virtio-net-pci,netdev=netdev0 \
--netdev bridge,id=hostnet0,br=virbr0 \
--device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \
--device virtio-net,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0,script=no,downscript=no \
--monitor telnet:127.0.0.1:5801,server,nowait,nodelay
-
-
-$ ssh -p 2222 root@127.0.0.1 -v
-
-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
-debug1: Reading configuration data /etc/ssh/ssh_config
-debug1: /etc/ssh/ssh_config line 19: Applying options for *
-debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222.
-debug1: Connection established.
-debug1: permanently_set_uid: 0/0
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_rsa type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_rsa-cert type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_dsa type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_dsa-cert type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_ecdsa type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_ecdsa-cert type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_ed25519 type -1
-debug1: key_load_public: No such file or directory
-debug1: identity file /root/.ssh/id_ed25519-cert type -1
-debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
-ssh_exchange_identification: read: Connection reset by peer
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1856027 b/results/classifier/deepseek-2-tmp/output/network/1856027
deleted file mode 100644
index beba2688..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1856027
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Suddenly no internet in guest system!
-
-I use Opensuse 15.1 i have installed androidx86_64 as a guest system, it runs for over 3 years. i had a internetconnection, i could use apps etc. but since yesterday i can´t connect to the internet with the guest system in the host system all works fine. What could be the reason? There haven´t been an update and i haven´t changed anything. 
-The settings in nic are: bridge br0: Hostdevice eth0
-devicemodel: e1000
-
-The qemu Version is from the opensuse repo: 3.1.1
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1857226 b/results/classifier/deepseek-2-tmp/output/network/1857226
deleted file mode 100644
index 829af376..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1857226
+++ /dev/null
@@ -1,12 +0,0 @@
-
-'set_link net0 off' not working with e1000e driver
-
-I'm encountering a bug with the e1000e network driver, that appears to got previously reported at rhbz. Steps to reproduce are provided in detail there:
-
-https://bugzilla.redhat.com/show_bug.cgi?id=1707646
-
-It is about switching off network link state (set_link net0 off) having no effect when using the e1000e driver.
-
-Version details:
-QEMU emulator version 4.1.1 (qemu-4.1.1-1.fc31)
-Fedora 31
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1857811 b/results/classifier/deepseek-2-tmp/output/network/1857811
deleted file mode 100644
index c7b38de3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1857811
+++ /dev/null
@@ -1,8 +0,0 @@
-
-qemu user static binary seems to lack support for network namespace.
-
-Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message.
-
-Unable to configure loopback interface: Operation not supported
-
-If I disable emerge's network-sandbox which utilizes network namespace, the error disappears.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1858415 b/results/classifier/deepseek-2-tmp/output/network/1858415
deleted file mode 100644
index 715756d3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1858415
+++ /dev/null
@@ -1,25 +0,0 @@
-
-in tcp_emu function has OOB bug
-
-qemu version: 4.1.0 
-
-```c
-int tcp_emu(struct socket *so, struct mbuf *m){
-............
-case EMU_REALAUDIO:
-............
-    while (bptr < m->m_data + m->m_len) {
-        case 6:
-............
-            lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1];
-............               
-            *(uint8_t *)bptr++ = (p >> 8) & 0xff;
-            *(uint8_t *)bptr = p & 0xff;
-............
-    }
-............
-............
-}
-```
-
-bptr)[1] and  bptr++ ,may make bptr ==  m->m_data + m->m_len,and cause OOB(out of bounds.)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1861875 b/results/classifier/deepseek-2-tmp/output/network/1861875
deleted file mode 100644
index 8c88d23e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1861875
+++ /dev/null
@@ -1,20 +0,0 @@
-
-VDE networking barely working 
-
-Running qemu with a vde_switch and slirpvde:
-
-  vde_switch -F -sock /tmp/qemu_vde_switch -M /tmp/qemu_vde_mgmt
-  slirpvde -s /tmp/qemu_vde_switch -dhcp
-  qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none -nodefaults -accel hax -net nic,macaddr=52:54:00:0e:e0:61,model=virtio -net vde,sock=/tmp/qemu_vde_switch -device virtio-rng-pci -drive file=worker.qcow2,if=virtio -drive file=cloud-init.iso,format=raw,if=virtio
-
-There is some network connectivity, ping and curl work, but bigger transfers like apt-get update break with the following errors printed in the output of vde_switch:
-
-  vde_switch: send_sockaddr port 2: No buffer space available
-  vde_switch: send_sockaddr port 2: No buffer space available
-  vde_switch: send_sockaddr port 2: No buffer space available
-
-I've tried to change the MTU size and model of the adapter inside of the VM, but nothing worked.
-
-OS: macOS 10.15.2
-qemu: 4.2.0
-vde2 (vde_switch / slirpvde): 2.3.2
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1861884 b/results/classifier/deepseek-2-tmp/output/network/1861884
deleted file mode 100644
index d0650a3f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1861884
+++ /dev/null
@@ -1,22 +0,0 @@
-
-qemu socket multicast not working
-
-Running two qemu vms on the same socket multicast address:
-
-  qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none
-    -nodefaults -accel hax
-    -netdev user,id=mynet0
-    -device virtio-net-pci,netdev=mynet0
-    -netdev socket,id=vlan,mcast=239.192.0.1:1235
-    -device virtio-net-pci,netdev=vlan
-    -device virtio-rng-pci
-    -drive file=worker.qcow2,if=virtio
-    -drive file=cloud-init.iso,format=raw,if=virtio
-
-The two machines have a static ip on the socket network interface, 192.168.100.11 and 192.168.100.12, but are unable to reach each other. 
-
-Is there additional configuration necessary on macos? Does this only work on Linux?
-
-guest OS: Debian 10 (Buster)
-host OS: macOS 10.15.2
-qemu: 4.2.0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1862979 b/results/classifier/deepseek-2-tmp/output/network/1862979
deleted file mode 100644
index bfa8eb18..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1862979
+++ /dev/null
@@ -1,16 +0,0 @@
-
-Cannot Create Socket Networking in Windows Host using Multicast
-
-Hello QEMU devs,
-
-I am trying to create a simulated VLAN using socket networking, and the only way to connect multiple networks in QEMU using socket networking is by using the multicast `mcast` option of the `socket` network backend.
-
-However, when I try use the following arguments in QEMU to create a multicast socket network:
-
-`-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234`
-
-it fails with:
-
-`can't bind ip address=230.0.0.1: unknown error` in my Windows host.
-
-I would like to know if this is a bug, or if I am missing a prerequisite before running the QEMU command.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1863096 b/results/classifier/deepseek-2-tmp/output/network/1863096
deleted file mode 100644
index c3c80c30..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1863096
+++ /dev/null
@@ -1,67 +0,0 @@
-
-vhost-user multi-queues interrupt failed when Qemu reconnection happens
-
-After upgrade qemu to v4.2.0, vhost-user multi-queues interrupt failed with event idx interrupt mode when reconnection happens.
-
-Test Environment:
-DPDK version: DPDK v19.11
-Other software versions: qemu 4.2.0.
-OS: Linux 4.15.0-20-generic
-Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
-Hardware platform: Purley.
-
-The reproduce step is:
-1. Launch l3fwd-power example app with client mode::
-
-    ./l3fwd-power -l 1-16 \
-    -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\
-    --log-level=9 \
-    --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \
-    -- -p 0x1 \
-    --parse-ptype 1 \
-    --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)"
-
-2. Launch VM1 with server mode:
-
-3. Relauch l3fwd-power sample to for reconnection:
-
-    ./l3fwd-power -l 1-16 \
-    -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\
-    --log-level=9 \
-    --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \
-    -- -p 0x1 \
-    --parse-ptype 1 \
-    --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)"
-
-4. Set vitio-net with 16 quques and give vitio-net ip address:
-
-    ethtool -L [ens3] combined 16    # [ens3] is the name of virtio-net
-    ifconfig [ens3] 1.1.1.1
-
-5. Send packets with different IPs from virtio-net, notice to bind each vcpu to different send packets process::
-
-    taskset -c 0 ping 1.1.1.2
-    taskset -c 1 ping 1.1.1.3
-    taskset -c 2 ping 1.1.1.4
-    taskset -c 3 ping 1.1.1.5
-    taskset -c 4 ping 1.1.1.6
-    taskset -c 5 ping 1.1.1.7
-    taskset -c 6 ping 1.1.1.8
-    taskset -c 7 ping 1.1.1.9
-    taskset -c 8 ping 1.1.1.2
-    taskset -c 9 ping 1.1.1.2
-    taskset -c 10 ping 1.1.1.2
-    taskset -c 11 ping 1.1.1.2
-    taskset -c 12 ping 1.1.1.2
-    taskset -c 13 ping 1.1.1.2
-    taskset -c 14 ping 1.1.1.2
-    taskset -c 15 ping 1.1.1.2
-
-If everything ok, then we can see the result such as following:
-
-    L3FWD_POWER: lcore 0 is waked up from rx interrupt on port 0 queue 0
-    ...
-    ...
-    L3FWD_POWER: lcore 15 is waked up from rx interrupt on port 0 queue 15
-
-But we can't see the log above because of the bug.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1870331 b/results/classifier/deepseek-2-tmp/output/network/1870331
deleted file mode 100644
index 2da9f54c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1870331
+++ /dev/null
@@ -1,44 +0,0 @@
-
-default nic device created even though supplied by configfile
-
-QEMU emulator version 4.1.94
-
-Documentation states that qemu will create a default nic as long as not explicitly forbidden (-nic none) or defined ( e.g. -nic <options>).
-
-Observation:
-Even though qemu-system-ppc is started with "-readconfig" (which defines a nic), another nic gets created. When additionally suppling "-nic none", only the nic of the config file is created.
-As matter of fact, if all items that are defined in config file are supplied as command line arguments, no further nic is created. 
-
-Expectation:
-When a nic is defined in config file, the default guest-nic should not get created.
-That would match behavior when all items, defined in config file are supplied as command line arguments.
-
-
-Attached config file.
-
-(qemu) info pci
- Bus 0, device 0, function 0:
- Host bridge: PCI device 1057:0002
- PCI subsystem 1af4:1100
- id ""
- Bus 0, device 1, function 0:
- VGA controller: PCI device 1234:1111
- PCI subsystem 1af4:1100
- BAR0: 32 bit prefetchable memory at 0x80000000 [0x80ffffff].
- BAR2: 32 bit memory at 0x81000000 [0x81000fff].
- BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
- id ""
- Bus 0, device 2, function 0:
- Ethernet controller: PCI device 10ec:8029
- PCI subsystem 1af4:1100
- IRQ 23.
- BAR0: I/O at 0x1000 [0x10ff].
- BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe].
- id ""
- Bus 0, device 3, function 0:
- Ethernet controller: PCI device 10ec:8029
- PCI subsystem 1af4:1100
- IRQ 24.
- BAR0: I/O at 0x1100 [0x11ff].
- BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe].
- id ""
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1874539 b/results/classifier/deepseek-2-tmp/output/network/1874539
deleted file mode 100644
index 0b5afc78..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1874539
+++ /dev/null
@@ -1,20 +0,0 @@
-
-tulip driver broken in v5.0.0-rc4
-
-In a qemu-system-hppa system, qemu release v5.0.0-rc, the tulip nic driver is broken.
-The tulip nic is detected, even getting DHCP info does work.
-But when trying to download bigger files via network, the tulip driver gets stuck.
-
-For example when trying to download a 100MB file:
-
-root@debian:~# wget https://speed.hetzner.de/100MB.bin
---2020-04-23 20:26:43--  https://speed.hetzner.de/100MB.bin
-Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
-Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
-<waiting and stuck here>
-
-When reverting this commit, everything works again:
-commit 8ffb7265af64ec81748335ec8f20e7ab542c3850
-Author: Prasad J Pandit <email address hidden>
-Date:   Tue Mar 24 22:57:22 2020 +0530
-PATCH: net: tulip: check frame size and r/w data length
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1874676 b/results/classifier/deepseek-2-tmp/output/network/1874676
deleted file mode 100644
index 370d29be..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1874676
+++ /dev/null
@@ -1,9 +0,0 @@
-
-[Feature request] MDIO bus
-
-Various network devices open-code a MDIO bus with a dedicated PHY.
-Introduce a new MDIO subsystem to
-- reuse various duplicated components
-- be able to interchange PHYs
-- have common tracing
-- use libqos to test all the PHYs from different NICs
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1877015 b/results/classifier/deepseek-2-tmp/output/network/1877015
deleted file mode 100644
index 06702e23..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1877015
+++ /dev/null
@@ -1,10 +0,0 @@
-
-virtio only support packed ring size power of 2
-
-Issue discription:
-When QEMU starts with "-device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
-
-It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 between 256 and 1024
-
-Analysis:
-According to virtio1.1 spec, the packed queue size value does not have to be a power of 2.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1879590 b/results/classifier/deepseek-2-tmp/output/network/1879590
deleted file mode 100644
index aa6c864a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1879590
+++ /dev/null
@@ -1,37 +0,0 @@
-
-Using qemu-system-sparc64 no network interface seems to exist
-
-Using boot command:
-
-qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2
-
-After I log into solaris system I see no network devices other than the loopback device.
-All the docs I can see suggest it should come up with a default network device that allows communication via the hosts network. Host is ubuntu 64bit.  
-
-root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version
-QEMU emulator version 5.0.0
-Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
-
-
-dladm show-link
-ifconfig -a
-
-
-
-ok boot
-Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
-FCode UFS Reader 1.12 00/07/17 15:48:16.
-Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
-Loading: /platform/sun4v/ufsboot
-SunOS Release 5.10 Version Generic_118822-23 64-bit
-Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
-Use is subject to license terms.
-Hostname: unknown
-
-unknown console login: root
-Last login: Wed Feb  8 09:01:28 on console
-Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
-# dladm show-link
-# ifconfig -a
-lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
-        inet 127.0.0.1 netmask ff000000
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1881 b/results/classifier/deepseek-2-tmp/output/network/1881
deleted file mode 100644
index d32c1b07..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1881
+++ /dev/null
@@ -1,16 +0,0 @@
-
-netdev-socket test_stream_unix() is unreliable
-Description of problem:
-test_stream_unix is unreliable and causes random CI job failures such as this one:
-https://gitlab.com/qemu-project/qemu/-/jobs/5020899550
-
-```
-576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") ERROR         
-576/839 qemu:qtest+qtest-sh4 / qtest-sh4/netdev-socket                            ERROR          62.85s   killed by signal 6 SIGABRT
->>> MALLOC_PERTURB_=249 QTEST_QEMU_BINARY=./qemu-system-sh4 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img /home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/tests/qtest/netdev-socket --tap -k
-――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
-stderr:
-**
-ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n")
-(test program exited with status code -6)
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/1882241 b/results/classifier/deepseek-2-tmp/output/network/1882241
deleted file mode 100644
index 56a607ec..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1882241
+++ /dev/null
@@ -1,21 +0,0 @@
-
-file transfer over cifs to 64bit guest corrupts large files
-
-qemu 4.0 compiled fom source.
-vm called by
-qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay
-
-copying large files eg 2.4gb or reading them on a cifs mount in the guest causes corruption every time. For smaller files 40-60mb corruption is more than 50% of the time. tested by md5sum on cifs server, or on host machine vs. on guest vm.
-corruption is seen only with 64bit guest using cifs with i82551 emulated network device
-ie. 32bit guest using cifs with i82551 emulated network device gives no corruption.
-
-changing the emulated device to vmxnet3 removes the data corruption (see below)
-
-qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay
-
-this corruption is repeatable. ie. I created new vm, call using top example, installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then run md5sum "filecopied"
-the md5sum is different every time. copy same file to the host, or to a 32bit guest with the same virtual network device and bridge and md5sums are correct. The host pysical network adapter is
-lspci|grep Ether
-1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
-
-physically connected via gigabit ethernet to cifs server (via gigabit switch)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1886 b/results/classifier/deepseek-2-tmp/output/network/1886
deleted file mode 100644
index 8e49c803..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1886
+++ /dev/null
@@ -1,18 +0,0 @@
-
-migration-test is unreliable
-Description of problem:
-The following intermittent failure occurred in the CI:
-
-```
->>> QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=116 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-x86_64 /builds/qemu-project/qemu/build/tests/qtest/migration-test --tap -k
-――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
-stderr:
-qemu-system-x86_64: Unable to read from socket: Connection reset by peer
-Memory content inconsistency at 5b43000 first_byte = bd last_byte = bc current = 4f hit_edge = 1
-**
-ERROR:../tests/qtest/migration-test.c:300:check_guests_ram: assertion failed: (bad == 0)
-(test program exited with status code -6)
-```
-  
-You can find the full output here:
-https://gitlab.com/qemu-project/qemu/-/jobs/5080200417
diff --git a/results/classifier/deepseek-2-tmp/output/network/1886285 b/results/classifier/deepseek-2-tmp/output/network/1886285
deleted file mode 100644
index 1f44d3ef..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1886285
+++ /dev/null
@@ -1,10 +0,0 @@
-
-Provide SMB option to support Windows 2000
-
-As of SAMBA 4.11 (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is disabled by default (and may be removed in the future). This breaks SMB shares with Windows 2000 guests.
-
-Adding the following line to smb.conf fixes this:
-
-min protocol = NT1
-
-I would propose that an option be added to add this line to smb.conf to support these legacy operating systems.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1886811 b/results/classifier/deepseek-2-tmp/output/network/1886811
deleted file mode 100644
index a9835862..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1886811
+++ /dev/null
@@ -1,24 +0,0 @@
-
-systemd complains Failed to enqueue loopback interface start request: Operation not supported
-
-This symptom seems similar to
-https://bugs.launchpad.net/qemu/+bug/1823790
-
-Host Linux: Debian 11 Bullseye (testing) on x84-64 architecture
-qemu version: latest git of git commit hash eb2c66b10efd2b914b56b20ae90655914310c925
-compiled with "./configure --static --disable-system" 
-
-Down stream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964289
-Bug report (closed) to systemd: https://github.com/systemd/systemd/issues/16359
-
-systemd in armhf and armel (both little endian 32-bit) containers fail to start with
-Failed to enqueue loopback interface start request: Operation not supported
-
-How to reproduce on Debian (and probably Ubuntu):
-mmdebstrap --components="main contrib non-free" --architectures=armhf --variant=important bullseye /var/lib/machines/armhf-bullseye
-systemd-nspawn -D /var/lib/machines/armhf-bullseye -b
-
-When "armhf" architecture is replaced with "mips" (32-bit big endian) or "ppc64"
-(64-bit big endian), the container starts up fine.
-
-The same symptom is also observed with "powerpc" (32-bit big endian) architecture.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1887604 b/results/classifier/deepseek-2-tmp/output/network/1887604
deleted file mode 100644
index 56bfe8fb..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1887604
+++ /dev/null
@@ -1,29 +0,0 @@
-
-Forward host UNIX socket to guest TCP port
-
-Hello. I've been racking my brain trying to work out if this is possible.
-
-I would like to be able to forward to a guest TCP port, via a host UNIX socket to avoid opening a TCP port on the host. For example:
-
-qemu-system-i386 [...] -nic user,hostfwd=unix:/path/to/socket-:22
-
-and then connect to the VM like:
-
-ssh -o "ProxyCommand socat - unix-connect:/path/to/socket" user@0.0.0.0
-
-QEMU, as versatile as it is, doesn't appreciate my intuited syntax "hostfwd=unix:...". It is also unhappy with:
-
-qemu-system-i386 [...] \
-    -chardev socket,id=foo,path=/path/to/socket,server,nowait \
-    -nic user,hostfwd=chardev:foo-:22
-
-And:
-
-qemu-system-i386 [...] \
-    -nic user \
-    -chardev socket,id=foo,path=/path/to/socket,server,nowait \
-    -chardev socket,id=foo,host=10.0.2.15,port=22
-
-I already found out how to connect in the opposite direction, **from** guest TCP to host UNIX, via guestfwd -> cmd -> socat. So I feel like there ought to be a way.
-
-If this is not yet a feature I would like to request it, and if it is, please tell me how!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1888467 b/results/classifier/deepseek-2-tmp/output/network/1888467
deleted file mode 100644
index 5dbefd01..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1888467
+++ /dev/null
@@ -1,13 +0,0 @@
-
-qemu-img http convert bug
-
-Hello, Why the file sizes of http conversion and local conversion are inconsistent?
-
-Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。
-My image size is 40 G, raw format.
-
-The source is the same file, but the access method is different
-http method of qemu-img: qemu-img convert -f raw -O vdi http://xxx xxx.vdi(19G,after conversion)
-local method of qemu-img: qemu-img convert -f raw -O vdi xxx.raw xxx.vdi(3G,after conversion)
-
-thank you
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1889943 b/results/classifier/deepseek-2-tmp/output/network/1889943
deleted file mode 100644
index 84e4f284..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1889943
+++ /dev/null
@@ -1,48 +0,0 @@
-
-Improper TCP/IP packet splitting on e1000e/vmxnet3
-
-Problem Description:
-When using a tap interface and the guest sends a TCP packet that would need to be segmented, it is fragmented using IP fragmentation. The host does not reassemble the IP fragments and forwards them to the next hop. This causes issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios). 
-This issue occurs on the e1000e and vmxnet3 NIC models, and possibly others. It does not occur on the virtio(which passes the entire packet through to the host w/o fragmentation or segmentation) or the e1000 model(). 
-
-Test scenario:
-Setup a tap and network bridge using the directions here: https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c
-Boot the machine into any modern guest(a Fedora 31 live iso was used for testing)
-Begin a wireshark capture on the host machine
-On the host(or another machine on the network) run: npx http-echo-server(See https://github.com/watson/http-echo-server)
-On the guest run
-Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta ut. Phasellus at quam bibendum, fermentum libero sit amet, ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus ligula, hendrerit nec aliquam non, finibus a turpis. Proin scelerisque convallis ante, et pharetra elit. Donec nunc nisl, viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis neque posuere placerat quis quis massa. Donec quis lacus ligula. Donec mollis vel nisi eget elementum. Nam id magna porta nunc consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor mattis. Praesent in mattis tortor. In venenatis convallis quam, in posuere nibh. Proin non dignissim massa. Cras at mi ut lorem tristique fringilla. Nulla ac quam condimentum metus tincidunt vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus condimentum, arcu sem molestie augue, in suscipit mauris odio mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan urna maximus. Nam nec odio volutpat, varius est id, tempus libero. Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. Etiam tempor, est sit amet vulputate molestie, urna neque sodales leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor dapibus maximus faucibus ut erat. Ut pharetra tempor massa in bibendum. Interdum et malesuada fames ac ante ipsum primis in faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet volutpat egestas, est est pulvinar erat, sed luctus nisl ligula eget justo vestibulum.” <ECHOSERVERIP:PORT>
-
-2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/
-
-Compare results from an e1000, a virtio, and a e1000e card:
-+--------+-----------+---------+------------+
-| Model  | Fragment  | Segment | Wire Size  |
-+--------+-----------+---------+------------+
-| e1000e | Yes       | NO      | 1484 + 621 |
-+--------+-----------+---------+------------+
-| e1000  | No        | Yes     | 1516 + 620 |
-+--------+-----------+---------+------------+
-| Virtio | NO        | NO      | 2068       |
-+--------+-----------+---------+------------+
-
-Expected Results:
-TCP Segment to proper size OR pass full size to host and let the host split if necessary.
-
-Configuration changes that did not work:
-Disable host, guest, router firewalls
-Different Hosts
-Different Physical NICs
-Libvirt based NAT/Routed modes
-Fedora 32 vs 31
-Qemu 4.2.0 vs github commit d74824cf7c8b352f9045e949dc636c7207a41eee
-
-System Information:
-lsb_release -rd
-Description:	Fedora release 32 (Thirty Two)
-Release:	32
-
-uname -a
-Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-
-I can provide additional logs, debug info, etc. if needed.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1890155 b/results/classifier/deepseek-2-tmp/output/network/1890155
deleted file mode 100644
index 2f2d8c57..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1890155
+++ /dev/null
@@ -1,39 +0,0 @@
-
-Abort in vmxnet3_validate_interrupt_idx
-
-Hello,
-Reproducer:
-
-cat << EOF | ./i386-softmmu/qemu-system-i386 \
--device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic
-outl 0xcf8 0x80001014
-outl 0xcfc 0xe0001000
-outl 0xcf8 0x80001018
-outl 0xcf8 0x80001004
-outw 0xcfc 0x7
-write 0x0 0x1 0xe1
-write 0x1 0x1 0xfe
-write 0x2 0x1 0xbe
-write 0x3 0x1 0xba
-write 0x52 0x1 0x61
-writeq 0xe0001020 0xef0bff5ecafe0000
-EOF
-
-==============================================================
- #7 0x55b271a89b67 in hw_error /home/alxndr/Development/qemu/general-fuzz/softmmu/cpus.c:927:5
- #8 0x55b272fc6433 in vmxnet3_validate_interrupt_idx /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1355:9
- #9 0x55b272fc4e6d in vmxnet3_validate_interrupts /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1364:5
- #10 0x55b272fbe723 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1546:5
- #11 0x55b272fb6fba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9
- #12 0x55b272fb410f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9
- #13 0x55b271ac4193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5
- #14 0x55b271ac3637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18
- #15 0x55b271ac1256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16
- #16 0x55b270e724a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23
- #17 0x55b270e5acc6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14
-
-
-qemu: hardware error: Bad interrupt index: 97
-Aborted
-
--Alex
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1890157 b/results/classifier/deepseek-2-tmp/output/network/1890157
deleted file mode 100644
index e40ddb91..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1890157
+++ /dev/null
@@ -1,36 +0,0 @@
-
-Assertion failure in net_tx_pkt_reset through vmxnet3
-
-Hello,
-Reproducer:
-
-cat << EOF | ./i386-softmmu/qemu-system-i386 \
--device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic
-outl 0xcf8 0x80001014
-outl 0xcfc 0xe0001000
-outl 0xcf8 0x80001018
-outl 0xcf8 0x80001004
-outw 0xcfc 0x7
-outl 0xcf8 0x80001083
-write 0x0 0x1 0xe1
-write 0x1 0x1 0xfe
-write 0x2 0x1 0xbe
-write 0x3 0x1 0xba
-writeq 0xe0001020 0xefefff5ecafe0000
-writeq 0xe0001020 0xffff5e5ccafe0002
-EOF
-
-==============================================================
-qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:450: void net_tx_pkt_reset(struct NetTxPkt *): Assertion `pkt->raw' failed.
-
-    #9 0x564838761930 in net_tx_pkt_reset /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:450:5
-    #10 0x564838881749 in vmxnet3_deactivate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1159:9
-    #11 0x56483888cf71 in vmxnet3_reset /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1170:5
-    #12 0x564838882124 in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1610:9
-    #13 0x56483887f10f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9
-    #14 0x56483738f193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5
-    #15 0x56483738e637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18
-    #16 0x56483738c256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16
-    #17 0x56483673d4a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23
-
--Alex
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1890159 b/results/classifier/deepseek-2-tmp/output/network/1890159
deleted file mode 100644
index 58dd1d42..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1890159
+++ /dev/null
@@ -1,40 +0,0 @@
-
-Assertion failure in net_tx_pkt_add_raw_fragment through vmxnet3
-
-Hello,
-Reproducer:
-
-cat << EOF | ./i386-softmmu/qemu-system-i386 \
--device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic
-outl 0xcf8 0x80001010
-outl 0xcfc 0xe0000000
-outl 0xcf8 0x80001014
-outl 0xcfc 0xe0001000
-outl 0xcf8 0x80001018
-outl 0xcf8 0x80001001
-outl 0xcfc 0x3fff3fff
-outl 0xcf8 0x80001016
-outl 0xcfc 0x5c84ff00
-outl 0xcf8 0x800010ff
-write 0x0 0x1 0xe1
-write 0x1 0x1 0xfe
-write 0x2 0x1 0xbe
-write 0x3 0x1 0xba
-writeq 0xff001020 0xef0bff5ecafe0000
-writel 0xe0000605 0xa7ff845e
-EOF
-
-==============================================================
-qemu-system-i386: hw/net/net_tx_pkt.c:382: _Bool net_tx_pkt_add_raw_fragment(struct NetTxPkt *, hwaddr, size_t): Assertion `pkt->max_raw_frags > pkt->raw_frags' failed.
-Aborted
-
-
-#9 0x5607db7efdc0 in net_tx_pkt_add_raw_fragment /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:382:5
-#10 0x5607db902ef0 in vmxnet3_process_tx_queue /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:653:18
-#11 0x5607db9021db in vmxnet3_io_bar0_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1097:9
-#12 0x5607da41f193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5
-#13 0x5607da41e637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18
-#14 0x5607da41c256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16
-#15 0x5607d97cd4a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23
-
--Alex
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1890160 b/results/classifier/deepseek-2-tmp/output/network/1890160
deleted file mode 100644
index 632d73e4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1890160
+++ /dev/null
@@ -1,35 +0,0 @@
-
-Abort in vmxnet3_validate_queues
-
-Hello,
-Reproducer:
-
-cat << EOF | ./i386-softmmu/qemu-system-i386 \
--device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic
-outl 0xcf8 0x80001014
-outl 0xcfc 0xe0001000
-outl 0xcf8 0x80001018
-outl 0xcf8 0x80001004
-outw 0xcfc 0x7
-write 0x0 0x1 0xe1
-write 0x1 0x1 0xfe
-write 0x2 0x1 0xbe
-write 0x3 0x1 0xba
-write 0x3e 0x1 0xe1
-writeq 0xe0001020 0xef0bff5ecafe0000
-EOF
-
-==============================================================
-qemu: hardware error: Bad TX queues number: 225
-
-    #6 0x7f04b89d455a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7
-    #7 0x558f5be89b67 in hw_error /home/alxndr/Development/qemu/general-fuzz/softmmu/cpus.c:927:5
-    #8 0x558f5d3c3968 in vmxnet3_validate_queues /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1388:9
-    #9 0x558f5d3bb716 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1449:5
-    #10 0x558f5d3b6fba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9
-    #11 0x558f5d3b410f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9
-    #12 0x558f5bec4193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5
-    #13 0x558f5bec3637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18
-    #14 0x558f5bec1256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16
-
--Alex
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1892684 b/results/classifier/deepseek-2-tmp/output/network/1892684
deleted file mode 100644
index 3fa72528..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1892684
+++ /dev/null
@@ -1,25 +0,0 @@
-
-curl and wget segfaults when link has redirects
-
-Hello,
-
-I've been using qemu-user-static with aarch64 docker images and faced the problem
-using binares from the following release: https://github.com/multiarch/qemu-user-static/releases/tag/v5.0.0-2.
-
-curl and wget fails with segmentation fault when trying to fetch something from the link
-that has some redirects.
-
-In order to reproduce you can run the following:
-
-1) Register qemu on x86_64 machine
-   docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
-2) Run arm64v8 docker image and try to run wget or curl
-   docker run --rm -it arm64v8/ubuntu bash
-   $ apt update
-   $ apt install curl wget
-   $ curl -L http://erratique.ch/software/astring/releases/astring-0.8.3.tbz
-   $ wget  http://erratique.ch/software/astring/releases/astring-0.8.3.tbz
-
-This error cannot be reproduced with binaries from eariler release https://github.com/multiarch/qemu-user-static/releases/tag/v4.2.0-7.
-curl and wget work fine with the given link and don't fail with segfault when using
-older qemu-user-static binaries
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1894781 b/results/classifier/deepseek-2-tmp/output/network/1894781
deleted file mode 100644
index c90bd666..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1894781
+++ /dev/null
@@ -1,20 +0,0 @@
-
-[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)
-
-(following from https://gitlab.com/libvirt/libvirt/-/issues/68#note_400960567)
-
-As is very well explained in https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/, and easily confirmed with captures, NBD stream starts in cleartext and upgrades to TLS inline (similar to STARTTLS mechanism). As a rationale, it is stated that this provides better error messages for the user of NBD.
-
-However, this approach has downsides:
-
-1) Clear indication to a network observer that NBD (and therefore likely qemu/libvirt) is used. In contrast, TLS1.3 hides even the SNI of the servers (ESNI, https://blog.cloudflare.com/encrypted-sni/).
-2) Potential for bugs in NBD protocol negotiation code. That code just statistically, likely less looked at code than gnutls. This is not a reflection on NBD code quality, just the fact that TLS code does receive a bit more scrutiny. 
-3) Inability to inspect TLS listener interface for compliance, e.g. with a security scanner. Making sure TLS listeners only select certain ciphersuits is a requirement of some compliance regimes. 
-
-I think it's fully possible to satisfy the original requirement of good error messages as well, detecting that the other end is initiating TLS connection.
-
-It's very unlikely that it's currently sae to recommend to run QEMU migration stream over a hostile network, but it should be possible to do with TLS only option.
-
-Solution to this, just like in the case of SMTP, is to provide TLS only option (no initial cleartext at all) for QEMU migration, which hopefully it not a large addition.
-
-Thank you for your consideration!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/190 b/results/classifier/deepseek-2-tmp/output/network/190
deleted file mode 100644
index 74d4177d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/190
+++ /dev/null
@@ -1,2 +0,0 @@
-
-'set_link net0 off' not working with e1000e driver
diff --git a/results/classifier/deepseek-2-tmp/output/network/1903493 b/results/classifier/deepseek-2-tmp/output/network/1903493
deleted file mode 100644
index 43bb1216..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1903493
+++ /dev/null
@@ -1,4 +0,0 @@
-
-About wireless network card bridging
-
-As a rookie, I don’t know if I should ask this question here. If it’s not right, I hope people who see it can help submit it to the right place. Qemu-kvm can add wireless network card bridging, after all, now you see that vbox and vmware can directly choose wireless network card bridging, and even hyper-v can be easily set up, arp proxy is too difficult for us rookies . I hope that qemu or other links can add a function to bridge the wireless network card, which can be directly set in virt-manager (for so many years, it seems that I can only use bridge-utils to bridge the Ethernet)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1904486 b/results/classifier/deepseek-2-tmp/output/network/1904486
deleted file mode 100644
index f0be5819..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1904486
+++ /dev/null
@@ -1,32 +0,0 @@
-
-resource leak in /net/tap.c
-
-Hi,there might be a resource leak in function net_init_tap in /net/tap.c. 
-
- 811         fd = monitor_fd_param(monitor_cur(), tap->fd, errp);
- 812         if (fd == -1) {
- 813             return -1;
- 814         }
- 815 
- 816         ret = qemu_try_set_nonblock(fd);
- 817         if (ret < 0) {
- 818             error_setg_errno(errp, -ret, "%s: Can't use file descriptor %d",
- 819                              name, fd);
- 820             return -1;
- 821         }
- 822 
- 823         vnet_hdr = tap_probe_vnet_hdr(fd, errp);
- 824         if (vnet_hdr < 0) {
- 825             close(fd);
- 826             return -1;
- 827         }
- 828 
- 829         net_init_tap_one(tap, peer, "tap", name, NULL,
- 830                          script, downscript,
- 831                          vhostfdname, vnet_hdr, fd, &err);
- 832         if (err) {
- 833             error_propagate(errp, err);
- 834             return -1;
- 835         }
-
-fd should be closed before return in line 820 and line 834, similar to the implementation in line 825.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1904954 b/results/classifier/deepseek-2-tmp/output/network/1904954
deleted file mode 100644
index b9ed412b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1904954
+++ /dev/null
@@ -1,14 +0,0 @@
-
-lan9118 bug peeked received message size not equal to actual received message size
-
-peeked message is not equal to read message
-
-
-Bug in the code at line:
-https://github.com/qemu/qemu/blob/master/hw/net/lan9118.c#L1209
-
-s->tx_status_fifo_head should be s->rx_status_fifo_head
-
-Thanks,
-
-Alfred
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1910826 b/results/classifier/deepseek-2-tmp/output/network/1910826
deleted file mode 100644
index 50106005..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1910826
+++ /dev/null
@@ -1,65 +0,0 @@
-
-[OSS-Fuzz] Issue 29224 rtl8139: Stack-overflow in rtlNUMBER_transmit_one
-
-=== Reproducer ===
-cat << EOF | ../build/qemu-system-i386 -machine q35 \
--nodefaults  -device rtl8139,netdev=net0 \
--netdev user,id=net0 -display none -qtest stdio
-outl 0xcf8 0x80000804
-outb 0xcfc 0x26
-outl 0xcf8 0x80000817
-outb 0xcfc 0xff
-write 0x1 0x1 0x42
-write 0x5 0x1 0x42
-write 0x9 0x1 0x42
-write 0xd 0x1 0x42
-write 0xff000044 0x4 0x11
-write 0xff000037 0x1 0x1c
-writel 0xff000030 0xff000000
-write 0xff000040 0x4 0x100006
-write 0xff000010 0x4 0x01020
-EOF
-
-=== Stack Trace ===
-==2819215==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd2c714040 (pc 0x5639b3a933d9 bp 0x7ffd2c716210 sp 0x7ffd2c714040 T0)
-#0 rtl8139_transmit_one /src/qemu/hw/net/rtl8139.c:1815
-#1 rtl8139_transmit /src/qemu/hw/net/rtl8139.c:2388:9
-#2 rtl8139_TxStatus_write /src/qemu/hw/net/rtl8139.c:2442:5
-#3 rtl8139_io_writel /src/qemu/hw/net/rtl8139.c:2865:13
-#4 rtl8139_ioport_write /src/qemu/hw/net/rtl8139.c:3290:9
-#5 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
-#6 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
-#7 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
-#8 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
-#9 flatview_write /src/qemu/softmmu/physmem.c:2799:14
-#10 address_space_write /src/qemu/softmmu/physmem.c:2891:18
-#11 address_space_rw /src/qemu/softmmu/physmem.c:2901:16
-#12 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12
-#13 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12
-#14 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12
-#15 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12
-#16 rtl8139_write_buffer /src/qemu/hw/net/rtl8139.c:778:5
-#17 rtl8139_do_receive /src/qemu/hw/net/rtl8139.c:1172:9
-#18 rtl8139_transfer_frame /src/qemu/hw/net/rtl8139.c:1798:9
-#19 rtl8139_transmit_one /src/qemu/hw/net/rtl8139.c:1845:5
-#20 rtl8139_transmit /src/qemu/hw/net/rtl8139.c:2388:9
-#21 rtl8139_TxStatus_write /src/qemu/hw/net/rtl8139.c:2442:5
-#22 rtl8139_io_writel /src/qemu/hw/net/rtl8139.c:2865:13
-#23 rtl8139_ioport_write /src/qemu/hw/net/rtl8139.c:3290:9
-#24 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
-#25 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
-#26 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
-#27 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
-#28 flatview_write /src/qemu/softmmu/physmem.c:2799:14
-#29 address_space_write /src/qemu/softmmu/physmem.c:2891:18
-#30 address_space_rw /src/qemu/softmmu/physmem.c:2901:16
-#31 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12
-#32 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12
-#33 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12
-#34 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12
-#35 rtl8139_write_buffer /src/qemu/hw/net/rtl8139.c:778:5
-#36 rtl8139_do_receive /src/qemu/hw/net/rtl8139.c:1172:9
-#37 rtl8139_transfer_frame /src/qemu/hw/net/rtl8139.c:1798:9
-Repeat until we run out of stack
-
-https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29224
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1913969 b/results/classifier/deepseek-2-tmp/output/network/1913969
deleted file mode 100644
index aa7fc235..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1913969
+++ /dev/null
@@ -1,24 +0,0 @@
-
-unable to migrate non shared storage when TLS is used
-
-Operating system: Gentoo
-Architecture: x86_64
-kernel version: 5.4.72, 5.10.11
-libvirt version: at least 6.9.0, 6.10.0, 7.0.0
-Hypervisor and version: qemu 5.1.0, 5.2.0
-
-With software versions described above and following configurations:
-libvirt:
-key_file = "/etc/ssl/libvirt/server.lan.key"
-cert_file = "/etc/ssl/libvirt/server.lan.crt"
-ca_file = "/etc/ssl/libvirt/ca.crt"
-log_filters="3:remote 4:event 3:util.json 3:rpc 1:*"
-log_outputs="1:file:/var/log/libvirt/libvirtd.log"
-qemu:
-default_tls_x509_cert_dir = "/etc/ssl/qemu"
-default_tls_x509_verify = 1
-migration with tls:
-virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource --copy-storage-all --verbose --tls
-never succeeds. Progress stops typically at high progress amounts (95%-98%), and network traffic drastically drops as well (from 1 gbps+ to nothing). domjobinfo progress also stops. Without --tls migrations succeed without issues without any other changes to hosts or configurations.
-
-Note: I reported this originally as libvirt bug: https://gitlab.com/libvirt/libvirt/-/issues/108.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1914117 b/results/classifier/deepseek-2-tmp/output/network/1914117
deleted file mode 100644
index d307ab13..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1914117
+++ /dev/null
@@ -1,16 +0,0 @@
-
-Short files returned via FTP on Qemu with various architectures and OSes
-
-
-Qemu 5.2 on Mac OS X Big Sur.
-
-I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). 
-Still getting the same problem,.
-
-On the following architectures: 
-arm64, amd64 and sometimes i386 running NetBSD host OS; 
-i386 running OpenBSD host OS:
-
-I have seen a consistent problem with FTP returning short files. The file will be a couple of bytes too short. I do not believe this is a problem with the OS. Downloading the perl source code from CPAN does not work properly, nor does downloading bind from isc. I've tried this on different architectures as above.
-
-(Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My gut feel is there is something not right on the Mac OS version of Qemu or a bug in 5.2 - obviously in the network layer somewhere. If you have anything you want me to try, please let me know - happy to help get a resolution.)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1916344 b/results/classifier/deepseek-2-tmp/output/network/1916344
deleted file mode 100644
index 5d2f0d8c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1916344
+++ /dev/null
@@ -1,25 +0,0 @@
-
-User mode networking not working properly on QEMU on Mac OS X host
-
-Steps to reproduce:
-
-1. Install QEMU using homebrew on Mac OS X (I used Big Sur)
-2. Spin up a guest VM (say) Cent OS8 using user mode networking.
-3. Install podman inside the guest
-4. Run podman pull alpine
-
-The result is:
-
-[root@localhost ~]# podman pull alpine
-Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
-Trying to pull docker.io/library/alpine:latest...
-Getting image source signatures
-Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB
-  unexpected EOF
-Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF
-
-This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest.
-
-This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X.
-
-This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1917161 b/results/classifier/deepseek-2-tmp/output/network/1917161
deleted file mode 100644
index e889ea46..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1917161
+++ /dev/null
@@ -1,11 +0,0 @@
-
-Parameter 'type' expects a netdev backend type
-
-When using QEMU on an M1 Mac with Mac OS 11.1, I see this error message when trying to enable networking for a guest:
-
-Parameter 'type' expects a netdev backend type
-
-Example command:
-qemu-system-i386 -m 700 -hda <Windows XP HD file> -netdev user,id=n0 -device rtl8139,netdev=n0
-
-What should happen is networking should work when issuing the above command. What actually happens is QEMU exits immediately.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1918 b/results/classifier/deepseek-2-tmp/output/network/1918
deleted file mode 100644
index ed4edc92..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1918
+++ /dev/null
@@ -1,50 +0,0 @@
-
-Build failure on FreeBSD 13.2-RELEASE-p3 amd64 with --vhost-user
-Description of problem:
-- Assumption that the python interpreter is in PATH as `python3`
-- Attempt to include Linux headers on a FreeBSD system
-Steps to reproduce:
-1. `$ ./configure --prefix=/opt/qemu --enable-vhost-user` (log attached below)
-2. `$ ninja -C build`
-3. See it running a python script without an explicit python interpreter
-4. Work around by invoking the python script through the interpreter that meson found:
-
-```diff
-diff --git a/ui/meson.build b/ui/meson.build
-index 0a1e8272a3..c6456f54c4 100644
---- a/ui/meson.build
-+++ b/ui/meson.build
-@@ -81,7 +81,7 @@ if dbus_display
-                       input: 'dbus-display1.xml',
-                       output: 'dbus-display1.xml',
-                       env: env,
--                      command: [xml_pp, '@INPUT@', '@OUTPUT@'])
-+                      command: [python, xml_pp, '@INPUT@', '@OUTPUT@'])
-   dbus_display1 = custom_target('dbus-display gdbus-codegen',
-                                 output: ['dbus-display1.h', 'dbus-display1.c'],
-                                 input: xml,
-
-```
-
-5. Then fails trying to include a Linux header:
-
-```console
-/usr/bin/cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../bsd-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iui -I../ui -I/usr/local/include/capstone -I/usr/local/include/pixman-1 -I/usr/local/include/l
-ibpng16 -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/local/include/SDL2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/gtk-3.0 
--I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libepoll-shim -I/usr/local/include/
-atk-1.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/vte-2.91 -I/usr/local/include/webp -fcolor-diagnostics -Wall -Winvalid-pch -st
-d=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wn
-ested-externs -Wendif-labels -Wexpansion-to-defined -Wmissing-format-attribute -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compar
-e -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -Wthread-safety -iquote . -iquote /usr/home/nico/build/qemu -iquote /usr/home/nico/build/qemu/include -iquote /usr/home/nico/build/qemu/host/include/x86_64 -iquote /usr/home/nico/build/qe
-mu/host/include/generic -iquote /usr/home/nico/build/qemu/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fPIE -DAVIF_DLL -DHWY_SHARED_DEFINE -D_REENTRANT -D_THREAD_SAFE -
-MD -MQ libcommon.fa.p/hw_net_vhost_net.c.o -MF libcommon.fa.p/hw_net_vhost_net.c.o.d -o libcommon.fa.p/hw_net_vhost_net.c.o -c ../hw/net/vhost_net.c
-In file included from ../hw/net/vhost_net.c:37:
-/usr/home/nico/build/qemu/linux-headers/linux/vhost.h:14:10: fatal error: 'linux/vhost_types.h' file not found
-#include <linux/vhost_types.h>
-         ^~~~~~~~~~~~~~~~~~~~~
-```
-
-I don't know what that is about. Full build log is attached below.
-Additional information:
-[config_log](/uploads/49d1c33d4b3951f79f826a701ceff1c2/config_log)
-[build_log_fail](/uploads/2cb3b49e7503a430457c4d99b1c60dbe/build_log_fail)
diff --git a/results/classifier/deepseek-2-tmp/output/network/1920871 b/results/classifier/deepseek-2-tmp/output/network/1920871
deleted file mode 100644
index 9c3ea14e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1920871
+++ /dev/null
@@ -1,52 +0,0 @@
-
-netperf UDP_STREAM high packet loss on QEMU tap network
-
-Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output:
-
-Socket  Message  Elapsed      Messages                
-Size    Size     Time         Okay Errors   Throughput
-bytes   bytes    secs            #      #   10^6bits/sec
-
-212992   65507   10.00      144710      0    7583.56
-212992           10.00          32              1.68
-
-We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,xxxxx". I can got:
-Socket  Message  Elapsed      Messages                
-Size    Size     Time         Okay Errors   Throughput
-bytes   bytes    secs            #      #   10^6bits/sec
-
-212992   65507   10.00       18351      0     961.61
-212992           10.00       18350            961.56
-
-most of UDP packets are recived.
-
-And If we check the tap qemu used, we can see:
-ifconfig tap0
-tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
-        inet6 fe80::ecc6:21ff:fe6f:b174  prefixlen 64  scopeid 0x20<link>
-        ether ee:c6:21:6f:b1:74  txqueuelen 1000  (Ethernet)
-        RX packets 282  bytes 30097 (29.3 KiB)
-        RX errors 0  dropped 0  overruns 0  frame 0
-        TX packets 9086214  bytes 12731596673 (11.8 GiB)
-        TX errors 0  dropped 16349024 overruns 0  carrier 0  collisions 0
-lots of TX packets are dropped.
-
-list other packet size:
-
-➜  boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1
-MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET
-Socket  Message  Elapsed      Messages                
-Size    Size     Time         Okay Errors   Throughput
-bytes   bytes    secs            #      #   10^6bits/sec
-
-212992       1   10.00     2297941      0       1.84
-212992           10.00     1462024              1.17
-
-➜  boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128
-MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET
-Socket  Message  Elapsed      Messages                
-Size    Size     Time         Okay Errors   Throughput
-bytes   bytes    secs            #      #   10^6bits/sec
-
-212992     128   10.00     2311547      0     236.70
-212992           10.00     1359834            139.25
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1922102 b/results/classifier/deepseek-2-tmp/output/network/1922102
deleted file mode 100644
index e0c63025..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1922102
+++ /dev/null
@@ -1,48 +0,0 @@
-
-Broken tap networking on macOS host
-
-Building QEMU with GLib newer than 2.58.3 corrupts tap networking. 
-Tap device was provided by Tun/Tap kernel extension installed from brew:
-  brew install tuntap
-
-Checked revisions:
-  553032d (v5.2.0)
-  6d40ce0 (v6.0.0-rc1)
-
-Host:
- MacBook Pro (Retina, 15-inch, Mid 2015)
- macOS Catalina 10.15.6 (19G2021)
-
-Guest:
-  Linux Ubuntu 4.4.0-206-generic x86_64
-  Also tested macOS Catalina 10.15.7 as a guest, the behaviour is the same.
-
-QEMU command line:
-
-qemu-system-x86_64 \
-  -drive file=hdd.qcow2,if=virtio,format=qcow2 \
-  -m 3G \
-  -nic tap,script=tap-up.sh
-
-tap-up.sh:
- 
- #!/bin/sh
-
- TAPDEV="$1"
- BRIDGEDEV="bridge0"
-
- ifconfig "$BRIDGEDEV" addm "$TAPDEV"
-
-Enabling/disabling Hypervisor.Framework acceleration (`-accel hvf`) has no effect. 
-
-How to reproduce: 
-  1. Build & install GLib > 2.58.3 (tested 2.60.7, 2.60.7)
-  2. Build qemu-system-x86_64 with GLib > 2.58.3
-  3. Boot any guest any guest with tap networking enabled
-  4. See that the external network is inaccessible
-
-Hotfix:
-  1. Build & install GLib 2.58.3
-  2. Build qemu-system-x86_64 with GLib 2.58.3
-  3. Boot any guest with tap networking enabled
-  4. See that the external network is accessible, everything is working as expected
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1924603 b/results/classifier/deepseek-2-tmp/output/network/1924603
deleted file mode 100644
index 4d922e39..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1924603
+++ /dev/null
@@ -1,52 +0,0 @@
-
-Incorrect feature negotiation for vhost-vdpa netdevice
-
-QEMU cmdline:
-=============
-./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -m 2G -hda  /gautam/centos75_1.qcow2 -name gautam,process=gautam -enable-kvm -netdev vhost-vdpa,id=mynet0,vhostdev=/dev/vhost-vdpa-0 -device virtio-net-pci,netdev=mynet0,mac=02:AA:BB:DD:00:20,disable-modern=off,page-per-vq=on -cpu host --nographic
-
-Host OS:
-========
-Linux kernel 5.11 running on x86 host
-
-Guest OS:
-==========
-CentOS 7.5
-
-Root cause analysis:
-=====================
-
-For vhost-vdpa netdevice, the feature negotiation results in sending the superset of features received from device in call to get_features vdpa ops callback.
-
-During the feature-negotiation phase, the acknowledged feature bits are initialized with backend_features  and then checked for supported feature bits in vhost_ack_features():
-
-void vhost_net_ack_features(struct vhost_net *net, uint64_t features)
-{
-  net->dev.acked_features = net->dev.backend_features;
-  vhost_ack_features(&net->dev, vhost_net_get_feature_bits(net), features);
-}
-
- 
-The vhost_ack_features() function just builds up on the dev.acked_features and never trims it down:
-
-void vhost_ack_features(struct vhost_dev *hdev, const int *feature_bits, uint64_t features)
-{     const int *bit = feature_bits;
-
-      while (*bit != VHOST_INVALID_FEATURE_BIT) {
-           uint64_t bit_mask = (1ULL << *bit);      
-
-            if (features & bit_mask)
-                 hdev->acked_features |= bit_mask;
-
-            bit++;
-       }
-}
-
-Because of this hdev->acked_features is always minimally equal to the value of device features and this is the value that is passed to the device in set_features callback:
-
-static int vhost_dev_set_features(struct vhost_dev *dev, bool enable_log)
-{
-       uint64_t *features = dev->acked_features;
-       .....
-       r = dev->vhost_ops->*vhost_set_features*(dev, features);
-}
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1925449 b/results/classifier/deepseek-2-tmp/output/network/1925449
deleted file mode 100644
index e622faff..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1925449
+++ /dev/null
@@ -1,38 +0,0 @@
-
-Failure building with clang-10 and libssh 
-
-On Fedora 32, configuring with --enable-libssh and building with clang:
-
-qemu 5.2.94
-
-  Compilation
-    host CPU                     : x86_64
-    host endianness              : little
-    C compiler                   : clang-10
-    Host C compiler              : clang-10
-
-  Dependencies
-    libssh support               : YES
-
-triggers:
-
-FAILED: libblock.fa.p/block_ssh.c.o 
-block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated [-Werror,-Wdeprecated-declarations]
-    state = ssh_is_server_known(s->session);
-            ^
-/usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been explicitly marked deprecated here
-SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session);
-^
-/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED'
-#define SSH_DEPRECATED __attribute__ ((deprecated))
-                                       ^
-block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated [-Werror,-Wdeprecated-declarations]
-    r = ssh_get_publickey(s->session, &pubkey);
-        ^
-/usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been explicitly marked deprecated here
-SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key);
-^
-/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED'
-#define SSH_DEPRECATED __attribute__ ((deprecated))
-                                       ^
-2 errors generated.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1926497 b/results/classifier/deepseek-2-tmp/output/network/1926497
deleted file mode 100644
index 3a762d8d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1926497
+++ /dev/null
@@ -1,25 +0,0 @@
-
-dp83932 stops working after a short while
-
-Following the instructions here https://wiki.qemu.org/Documentation/Platforms/m68k I was able to successfully install debian. However, running apt-get update stalls after the first 1-2MB.
-
-root@debian:~# apt-get update
-Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB]
-Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease
-Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB]
-18% [2 Packages 2,155 kB/8,735 kB 25%]
-
-After running apt-get update. I don't seem to be able to send any packets anymore. ping host lookups fail and a subsequent apt-get update makes no progress.
-
-I'm launching qemu with:
-
-  qemu-system-m68k -boot c \
- -M q800 -serial none -serial mon:stdio -m 1000M \
- -net nic,model=dp83932 -net user \
- -append "root=/dev/sda2 rw console=ttyS0 console=tty" \
- -kernel vmlinux-4.16.0-1-m68k \
- -initrd initrd.img-4.16.0-1-m68k \
- -drive file=m68k-deb10.qcow2,format=qcow2 \
- -nographic
-
-I see this with qemu v6.0.0-rc5
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/1937 b/results/classifier/deepseek-2-tmp/output/network/1937
deleted file mode 100644
index 5028004d..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1937
+++ /dev/null
@@ -1,12 +0,0 @@
-
-Live migration with TLS fail (GNUTLS AUTO_REKEY)
-Description of problem:
-Live migration with TLS fail in postcopy stage when:
-
-#
-Steps to reproduce:
-1. run VM with heavy RAM load: `nohup stress-ng --vm 6 --vm-bytes 12G &`
-2. run precopy for more that 80sec
-3. switch into post-copy stage
-Additional information:
-This only occurs with TLS transport, if clear qemu+tcp is used then everything works.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1949 b/results/classifier/deepseek-2-tmp/output/network/1949
deleted file mode 100644
index 58d5947a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1949
+++ /dev/null
@@ -1,13 +0,0 @@
-
-chardev zombie TCP session
-Description of problem:
-When user terminates TCP session ungracefully (eg: power-cycle or network cable disconnect), the TCP session keeps in established status forever. In this state, new sessions can't access the chardev, since the zombie TCP session keeps exclusive access to chardev.
-Steps to reproduce:
-1.Establish client session to chardev TCP socket.  
-2.Power-off the client machine.  
-3.Establish a new client session  
-4.Observe that old TCP session is never killed and new session can connect but not interact with chardev.
-Additional information:
-Suggestions to resolve this and improve the chardev feature:
-- enable TCP keep-alive for chardev server.
-- allow multiple client sessions concurrently, where chardev output is broadcasted to all client sessions, and chardev input is shared by all clients.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1957 b/results/classifier/deepseek-2-tmp/output/network/1957
deleted file mode 100644
index 4ca3d235..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1957
+++ /dev/null
@@ -1,21 +0,0 @@
-
-Reading files failed from QEMU TFTP server
-Description of problem:
-QEMU TFTP server on Linux is sensitive to the filename delimiters:
-
-After building QEMU UEFI firmware with the entire NetworkPkg stack and booting to UEFI shell, one can use `tftp` command to read files from the QEMU TFTP server specified during QEMU launching. i.e. `tftp 10.0.2.2 Boot\BCD`. However, when setting up the TFTP folder to be exactly the same (Linux and Windows), the result for running this command is different. On Windows host, this tftp command from emulated UEFI shell will proceed properly. But on Linux host, this will fail with "File Not Found".
-
-The issue seems to be around the slirp engine used by QEMU: the received packet will hand off to slirp as is, which leads to a host specific libc implementation of "open" function call: https://git.launchpad.net/ubuntu/+source/libslirp/tree/src/tftp.c#n113. Thus the server result would be different when the host is different.
-
-This will cause the PXE boot to fail when setting up the PXE folder on through QEMU on Linux because Windows will attempt to read BCD file at the same directory of the initial boot file, with a `\` in between.
-
-As TFTP protocol seems to be folder agnostic (just file names), in this case, should the TFTP server (QEMU here) handle the path normalization to make sure the file lookup to go through? Otherwise, Windows PXE boot on QEMU Linux host will always fail.
-
-Any suggestion here? Thanks in advance!
-Steps to reproduce:
-1. Build OVMF UEFI with full network stack
-2. Launch QEMU with the built UEFI with nic enabled, boot to UEFI shell.
-3. Invoke `tftp 10.0.2.2 Boot\BCD` from UEFI shell.
-4. When performing step 1-3 on Windows, this will succeed. But on Linux, this will fail with "File Not Found"
-Additional information:
-Attached is a wireshark dump from QEMU on Linux host. The same command sequence will all be successful on Windows host.
diff --git a/results/classifier/deepseek-2-tmp/output/network/1975 b/results/classifier/deepseek-2-tmp/output/network/1975
deleted file mode 100644
index 77ba0a43..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1975
+++ /dev/null
@@ -1,38 +0,0 @@
-
-SEGV on exit: net_cleanup() frees devices it doesn't own.
-Description of problem:
-On exiting QEMU, the `net_cleanup()` function iterates over all existing `net_clients`, both netdevs and nics, and deletes them all. Freeing the netdevs is fine, and they are correctly detached from their peer nic as appropriate. But the nics belong to an actual device and this can cause a use-after-free or double-free.
-
-Mostly this doesn't happen because emulated devices *don't* bother to clean up after themselves on exit; none of their state is going to outlast the QEMU process so there's no point. But XenBus devices interact with the external XenStore and do need to perform a cleanup. The `xen_netdev_unrealize()` function calls `qemu_del_nic()` on the nic which `net_cleanup()` already stole from it, and crashes...
-
-```
-QEMU: Terminated
-
-Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
-qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451
-451	    int i, queues = MAX(nic->conf->peers.queues, 1);
-(gdb) bt
-#0  qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451
-#1  0x0000555555a89ce3 in xen_device_unrealize (dev=<optimized out>) at ../hw/xen/xen-bus.c:973
-#2  0x0000555555e5c847 in notifier_list_notify (list=<optimized out>, data=0x0) at ../util/notify.c:39
-#3  0x00007ffff5fe51e6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111
-#4  0x00007ffff5fe532e in __GI_exit (status=<optimized out>) at exit.c:141
-#5  0x00007ffff5fccb91 in __libc_start_call_main (main=main@entry=0x5555558837a0 <main>, argc=argc@entry=23, argv=argv@entry=0x7fffffffd7a8) at ../sysdeps/nptl/libc_start_call_main.h:74
-#6  0x00007ffff5fccc4b in __libc_start_main_impl
-    (main=0x5555558837a0 <main>, argc=23, argv=0x7fffffffd7a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd798) at ../csu/libc-start.c:360
-#7  0x0000555555885345 in _start ()
-```
-Steps to reproduce:
-1. Launch a Xen guest as described at https://qemu-project.gitlab.io/qemu/system/i386/xen.html (which will get a Xen NIC by default).
-2. Terminate QEMU.
-
-It doesn't need to boot, doesn't need to do anything. Just launch a completely non-functional guest and then hit `Ctrl-a x` on the default monitor:
-```
-$ ./qemu-system-x86_64 -accel kvm,xen-version=0x40010,kernel-irqchip=split -display none
-QEMU: Terminated
-Segmentation fault
-
-```
-
-For `net_cleanup()` to clean up the *netdevs* makes sense, because those might have state which persists in the system after QEMU exits, and need to be cleaned up. But deleting the nics doesn't seem to be necessary. 
-Fix at https://lore.kernel.org/qemu-devel/61ea91785772a8138ad12b305cbd5aac4aa1e86a.camel@infradead.org
diff --git a/results/classifier/deepseek-2-tmp/output/network/1984 b/results/classifier/deepseek-2-tmp/output/network/1984
deleted file mode 100644
index 06f087cb..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/1984
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Fails to start dataplane while using vdpa-dev with vduse backend
diff --git a/results/classifier/deepseek-2-tmp/output/network/2028 b/results/classifier/deepseek-2-tmp/output/network/2028
deleted file mode 100644
index ac3de84e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2028
+++ /dev/null
@@ -1,2 +0,0 @@
-
-CAN sja1000 standard frame filter bug
diff --git a/results/classifier/deepseek-2-tmp/output/network/2058 b/results/classifier/deepseek-2-tmp/output/network/2058
deleted file mode 100644
index 3918c1ee..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2058
+++ /dev/null
@@ -1,53 +0,0 @@
-
-QEMU should pad Ethernet frames from vmnet.framework on macOS hosts
-Description of problem:
-When using a `vmnet` network device on a macOS host, the host’s [ARP](https://en.wikipedia.org/wiki/Address_Resolution_Protocol) replies are smaller than the 64-octet minimum frame size defined for Ethernet in IEEE Std 802.3-2022 (subclause 4.2.3.3 and Table 4–2).
-
-When QEMU presents such frames to a guest, the guest’s Ethernet device driver may drop them with “frame too short” or “runt” errors, since they are smaller than actual Ethernet frames should ever be. This prevents the guest from resolving the host’s MAC address, so the guest and host can’t communicate as expected.
-
-I observed this problem with a Mac OS X 10.4.11 guest using a `sungem` or `rtl8139` virtual network device, but it might also affect other guests and virtual network devices.
-Additional information:
-To prevent this problem, QEMU should pad Ethernet frames received from `vmnet` to the minimum size, 60 bytes before the frame check sequence, before handing them off to a guest. (QEMU’s virtual network devices used to add such padding, but that was changed earlier this year in commits such as 63b901bf and aee87b43.)
-
-Here is a patch for `net/vmnet-common.m` that calls `eth_pad_short_frame()` for this, as `net/tap.c` and `net/slirp.c` already do:
-
-```
---- net/vmnet-common.m.orig	2023-12-19 13:24:34.000000000 -0800
-+++ net/vmnet-common.m	2023-12-27 13:30:15.000000000 -0800
-@@ -18,6 +18,7 @@
- #include "qemu/error-report.h"
- #include "qapi/error.h"
- #include "sysemu/runstate.h"
-+#include "net/eth.h"
- 
- #include <vmnet/vmnet.h>
- #include <dispatch/dispatch.h>
-@@ -150,10 +151,23 @@
-  */
- static void vmnet_write_packets_to_qemu(VmnetState *s)
- {
-+    uint8_t *pkt;
-+    size_t pktsz;
-+    uint8_t min_pkt[ETH_ZLEN];
-+    size_t min_pktsz = sizeof(min_pkt);
-+
-     while (s->packets_send_current_pos < s->packets_send_end_pos) {
--        ssize_t size = qemu_send_packet_async(&s->nc,
--                                      s->iov_buf[s->packets_send_current_pos].iov_base,
--                                      s->packets_buf[s->packets_send_current_pos].vm_pkt_size,
-+        pkt = s->iov_buf[s->packets_send_current_pos].iov_base;
-+        pktsz = s->packets_buf[s->packets_send_current_pos].vm_pkt_size;
-+
-+        if (net_peer_needs_padding(&s->nc)) {
-+            if (eth_pad_short_frame(min_pkt, &min_pktsz, pkt, pktsz)) {
-+                pkt = min_pkt;
-+                pktsz = min_pktsz;
-+            }
-+        }
-+
-+        ssize_t size = qemu_send_packet_async(&s->nc, pkt, pktsz,
-                                       vmnet_send_completed);
- 
-         if (size == 0) {
-
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/2095 b/results/classifier/deepseek-2-tmp/output/network/2095
deleted file mode 100644
index 8e02e264..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2095
+++ /dev/null
@@ -1,2 +0,0 @@
-
-RFE: support AF_UNIX userspace backend for virtio-vsock matching firecracker
diff --git a/results/classifier/deepseek-2-tmp/output/network/2125 b/results/classifier/deepseek-2-tmp/output/network/2125
deleted file mode 100644
index 9dbf19e1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2125
+++ /dev/null
@@ -1,15 +0,0 @@
-
-The value of 'tx_queue_size' is set to only 256 in the network device option on qemu 8.2.
-Description of problem:
-I have been using the 'tx_queue_size' value set to 1024 in the network device option on qemu 7.2 without any issues.\
-but when I upgrade to qemu 8.2 I got this error message (and also qemu 8.1) and I cannot use any value other than 256
-```
-qemu-system-x86_64: -device virtio-net-pci,mq=on,vectors=6,netdev=hostnet_34,id=dpdk_34,mac=F2:20:AF:40:12:65,bus=bridge,addr=0x7,page-per-vq=on,rx_queue_size=1024,tx_queue_size=1024,mrg_rxbuf=on,disable-legacy=on,disable-modern=off,host_mtu=1500,csum=on,guest_csum=on,host_tso4=on,host_tso6=on: Invalid tx_queue_size (= 1024), must be a power of 2 between 256 and 256
-```
-
-and I think virtqueue max size value has never changed from 1024.\
-https://gitlab.com/qemu-project/qemu/-/blob/staging-8.2/include/hw/virtio/virtio.h?ref_type=heads#L62
-Steps to reproduce:
-1. boot qemu-system-x86_64 on qemu 8.2 and network device option set tx_queue_size value over 256
-Additional information:
-- I'm using hardware vDPA offloading with mellanox NIC card.
diff --git a/results/classifier/deepseek-2-tmp/output/network/2128 b/results/classifier/deepseek-2-tmp/output/network/2128
deleted file mode 100644
index 4a6abde1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2128
+++ /dev/null
@@ -1,2 +0,0 @@
-
-avocado tests using landley.net URLs sometimes time out fetching assets
diff --git a/results/classifier/deepseek-2-tmp/output/network/2129 b/results/classifier/deepseek-2-tmp/output/network/2129
deleted file mode 100644
index f19ca805..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2129
+++ /dev/null
@@ -1,2 +0,0 @@
-
-migration-test sometimes fails
diff --git a/results/classifier/deepseek-2-tmp/output/network/2144 b/results/classifier/deepseek-2-tmp/output/network/2144
deleted file mode 100644
index 21eeaa1a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2144
+++ /dev/null
@@ -1,23 +0,0 @@
-
-macOS build fails when using --enable-debug
-Description of problem:
-the build fails because a symbol can't be found:
-
-```
-ld: Undefined symbols:
-  _lasi_82596_init, referenced from:
-      _machine_HP_common_init_tail in hw_hppa_machine.c.o
-```
-Steps to reproduce:
-1. on macOS 14.3 in build folder
-2. ../configure --enable-debug
-3. make -j12
-Additional information:
-the default build with
-
-```
-../configure
-make -j12
-```
-
-succeeds normally.
diff --git a/results/classifier/deepseek-2-tmp/output/network/2176 b/results/classifier/deepseek-2-tmp/output/network/2176
deleted file mode 100644
index 5ae32a96..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2176
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Events delivered during Capabilities Negotiation mode
diff --git a/results/classifier/deepseek-2-tmp/output/network/218 b/results/classifier/deepseek-2-tmp/output/network/218
deleted file mode 100644
index c115db6e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/218
+++ /dev/null
@@ -1,2 +0,0 @@
-
-qemu-storage-daemon --nbd-server fails with "too many connections" error
diff --git a/results/classifier/deepseek-2-tmp/output/network/2182 b/results/classifier/deepseek-2-tmp/output/network/2182
deleted file mode 100644
index f4f63bdd..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2182
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Replication and Network
diff --git a/results/classifier/deepseek-2-tmp/output/network/2189 b/results/classifier/deepseek-2-tmp/output/network/2189
deleted file mode 100644
index f05e79ab..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2189
+++ /dev/null
@@ -1,15 +0,0 @@
-
-vhost_user:When configure queues of vhost-user NIC exceeds max_queues, the virtual machine is always paused
-Description of problem:
-When the virtual machine uses the vhost-user network card and sets the queue number of the network card to exceed the maximum number of supported queues, the virtual machine fails to start and stays in the paused state.
-And the virtual machine log file kept print "qemu - system - x86_64: -netdev host-user,chardev=charnet0,queues=5,id=hostnet0:you are asking more queues than supported:4”
-Steps to reproduce:
-1.Configure vhost-user network cards for VMS and use multiple queues.
-2.The number of NIC queues configured in the VM xml file is greater than the maximum number of queues supported by the VM, that is, the number of Vcpus on the VM.
-3.Execute "virsh create VM_xml_file" cmd to start VM.
-Additional information:
-According to normal logic, if the number of configured vhost-user NIC queues exceeds max-queues, the qemu process should be stopped, rather than paused the virtual machine.
-I am confused about this patch:https://github.com/qemu/qemu/commit/c89804d674e4e3804bd3ac1fe79650896044b4e8
-The process will remain in the do...while loop, when vhost_user_start is called in net_vhost_user_event, if queues > max_queues in vhost_user_start.
-/label ~"kind::Bug"
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/2191 b/results/classifier/deepseek-2-tmp/output/network/2191
deleted file mode 100644
index 20f2c7c9..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2191
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Support exposing exports based on authentication
diff --git a/results/classifier/deepseek-2-tmp/output/network/2197 b/results/classifier/deepseek-2-tmp/output/network/2197
deleted file mode 100644
index d37eb06a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2197
+++ /dev/null
@@ -1,59 +0,0 @@
-
-qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly
-Description of problem:
-Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**.
-
-When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero.
-Steps to reproduce:
-1. compile this code to binary executable:
-```c
-#include <unistd.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <linux/if_alg.h>
-
-int create_alg(const char *alg)
-{
-        struct sockaddr_alg salg;
-        int sk;
-
-        sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0);
-        if (sk < 0)
-                return -1;
-
-        memset(&salg, 0, sizeof(salg));
-        salg.salg_family = AF_ALG;
-        strcpy((char *) salg.salg_type, "hash");
-        strcpy((char *) salg.salg_name, alg);
-
-        if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) {
-                close(sk);
-                return -1;
-        }
-
-        return sk;
-}
-
-int main() {
-        int fd = create_alg("hmac(sha1)");
-        char buf[10];
-        int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0);
-        if(ret < 0){
-                perror("err");
-        }
-        else{
-                puts("SUCCESS!");
-        }
-        return 0;
-}
-```
-2. run it in any qemu user space emulator
-
-On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`.
-
-The error is neither informative nor intuitive and could be misleading for user programs.
-Additional information:
-I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing.
diff --git a/results/classifier/deepseek-2-tmp/output/network/2239 b/results/classifier/deepseek-2-tmp/output/network/2239
deleted file mode 100644
index 037cd85e..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2239
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Legacy system requirments: iptables
diff --git a/results/classifier/deepseek-2-tmp/output/network/2253 b/results/classifier/deepseek-2-tmp/output/network/2253
deleted file mode 100644
index eb2bb3db..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2253
+++ /dev/null
@@ -1,2 +0,0 @@
-
-NO_CAST.INTEGER_OVERFLOW in /hw/net/eepro100.c
diff --git a/results/classifier/deepseek-2-tmp/output/network/2362 b/results/classifier/deepseek-2-tmp/output/network/2362
deleted file mode 100644
index 3afe64e3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2362
+++ /dev/null
@@ -1,64 +0,0 @@
-
-short packets dropped by some network cards when using certain network backends
-Description of problem:
-Effectively a duplicate of https://gitlab.com/qemu-project/qemu/-/issues/2058 -- short ethernet packets (such as ARP packets) are discarded by various networking devices now.
-
-QEMU previously padded ethernet frames to 64 bytes when some network cards received them, but this was removed in various commits (140eae9c8f760e9260356fe9b56b802a02f0a9d2, c445f200ad241b443aa7a61a5381b26f56a18f0e, c58da33f2f8410b6f22cd1d33377dadf3a4d8867, 05db4476c5d25e437d807175de9f862bf5bf732c, 6d0d261dbfa6122e9b3bdcab7d934ca49f069c21, 63b901bfd30a0975bc326ba8527880fabac2e66, aee87b43fe2206acb8f5e334b42790df33a1cbad).
-
-969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 fixed SLIRP and TAP support, however the other various network backends (socket, dgram, vde, others) all have the same issue that some network cards will reject short packets.
-
-This does not fail on older versions of QEMU.
-Steps to reproduce:
-I have a python script that shows connecting two VMs of your choice using a socketpair connected to one of the affected NIC types (pcnet). If you start your OS (I used alpine linux as my test), and give each VM a unique IP address (eg, `ip addr add 192.168.0.1/24 dev eth0`), ping will fail to work. When you run tcpdump, you can see that the OS is sending out short ARP packets, but the other VM cannot see them.
-
-Using an older version of QEMU allows the ping to succeed.
-
-```python
-#!/usr/bin/env python3
-
-import argparse
-import shlex
-import socket
-import subprocess
-
-
-QEMU_PATH = "bin/qemu-system-x86_64"
-NIC = "pcnet"
-vnc = True
-
-if __name__ == "__main__":
-    parser = argparse.ArgumentParser()
-    parser.add_argument("qcow")
-    args = parser.parse_args()
-
-    p1, p2 = socket.socketpair()
-
-    qargs1 = [
-        QEMU_PATH, "-snapshot",
-        "-m", "2G",
-        "-drive", f"file={args.qcow}",
-        "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:01",
-        "-netdev", f"socket,id=n,fd={p1.fileno()}"
-    ]
-    if vnc:
-        qargs1 += ["-display", "vnc=:2"]
-
-    print("+", shlex.join(qargs1))
-    proc1 = subprocess.Popen(qargs1, pass_fds=[p1.fileno()])
-
-    qargs2 = [
-        QEMU_PATH, "-snapshot",
-        "-m", "2G",
-        "-drive", f"file={args.qcow}",
-        "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:02",
-        "-netdev", f"socket,id=n,fd={p2.fileno()}"
-    ]
-    if vnc:
-        qargs2 += ["-display", "vnc=:3"]
-
-    print("+", shlex.join(qargs2))
-    proc2 = subprocess.Popen(qargs2, pass_fds=[p2.fileno()])
-
-    proc1.wait()
-    proc2.wait()
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/2364 b/results/classifier/deepseek-2-tmp/output/network/2364
deleted file mode 100644
index bfe64b73..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2364
+++ /dev/null
@@ -1,2 +0,0 @@
-
-how to create two qemu instances on Windows11 so that they can access to each other in the same network?
diff --git a/results/classifier/deepseek-2-tmp/output/network/2370 b/results/classifier/deepseek-2-tmp/output/network/2370
deleted file mode 100644
index b50e6cae..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2370
+++ /dev/null
@@ -1,12 +0,0 @@
-
-[RFE] vde support on Windows
-Additional information:
-A vdeswitch approach can be yet another solution for #2364 .   
-On Windows, other methods to simultaneously bridge local qemu-VMs and allow bridge members to connect to the internet are troublesome. 
-Compared to MAC/Linux wherein who use kernel provided bridging. Windows users don't have it easy.  
-
-**Ref**: 
-1. qemu manual for ```netdev vde```  
-   https://qemu.readthedocs.io/_/downloads/en/v8.2.1/pdf/#page=75 
-2. virtualsquare/VDE-2 github bug Can't understand how to get it running on Windows10 64 bit ```#28```  
-   https://github.com/virtualsquare/vde-2/issues/28
diff --git a/results/classifier/deepseek-2-tmp/output/network/2401 b/results/classifier/deepseek-2-tmp/output/network/2401
deleted file mode 100644
index d70e48cc..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2401
+++ /dev/null
@@ -1,2 +0,0 @@
-
-"-nic none" option has no equivalent in config file
diff --git a/results/classifier/deepseek-2-tmp/output/network/2409 b/results/classifier/deepseek-2-tmp/output/network/2409
deleted file mode 100644
index 29985206..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2409
+++ /dev/null
@@ -1,2 +0,0 @@
-
-High CPU usage on network traffic on Apple laptops
diff --git a/results/classifier/deepseek-2-tmp/output/network/2410 b/results/classifier/deepseek-2-tmp/output/network/2410
deleted file mode 100644
index 1f0b7864..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2410
+++ /dev/null
@@ -1,93 +0,0 @@
-
-linux-user: `Setsockopt` with IP_OPTIONS returns "Protocol not available" error
-Description of problem:
-It seems that call to `setsockopt(sd, SOL_IP, IP_OPTIONS,_)` behaves differently on RISC-V Qemu than on x64 Linux. 
-On Linux syscall returns 0, but on Qemu it fails with `Protocol not available`.
-According [man](https://man7.org/linux/man-pages/man7/ip.7.html) `IP_OPTIONS` on `SOCK_STREAM` socket "should work".
-Steps to reproduce:
-1. Use below toy program `setsockopt.c` and compile it without optimizations like:
-```
-    gcc -Wall -W -Wextra -std=gnu17 -pedantic setsockopt.c -o setsockopt
-```
-
-```
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <arpa/inet.h>
-#include <netinet/in.h>
-#include <unistd.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-int main() {
-    {
-        int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
-        if(sd < 0) {
-            perror("Opening stream socket error");
-            exit(1);
-        }
-        else
-            printf("Opening stream socket....OK.\n");
-
-        struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}};
-        int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16);
-
-        if (err < 0) {
-            perror("Connect error");
-            close(sd);
-        }
-        else
-            printf("Connect...OK.\n");
-    }
-    {
-        int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
-        if(sd < 0) {
-            perror("Opening stream socket error");
-            exit(1);
-        }
-        else
-            printf("Opening stream socket....OK.\n");
-
-        char option[4] = {0};
-        if(setsockopt(sd, SOL_IP, IP_OPTIONS, (char *)option, sizeof(option)) < 0) {
-            perror("setsockopt error");
-            close(sd);
-            exit(1);
-        }
-        else
-            printf("setsockopt...OK.\n");
-
-        struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}};
-        int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16);
-
-        if (err < 0) {
-            perror("Connect error");
-            close(sd);
-        }
-        else
-            printf("Connect...OK.\n");
-    }
-    return 0;
-}
-```
-
-
-2. Run program on Qemu and compare output with output from x64 build. In my case it looks like:
-```
-root@AMDC4705:~/runtime/connect$ ./setsockopt-x64
-Opening stream socket....OK.
-Connect error: Network is unreachable
-Opening stream socket....OK.
-setsockopt...OK.
-Connect error: Network is unreachable
-
-root@AMDC4705:/runtime/connect# ./setsockopt-riscv
-Opening stream socket....OK.
-Connect error: Network is unreachable
-Opening stream socket....OK.
-setsockopt error: Protocol not available
-```
-Additional information:
-In above demo option `value` is quite artificial. However I tried passing many different `option` arguments (with same `SOL_IP` + `IP_OPTIONS` combination) but always ended up with `setsockopt` failure. 
-From the other hand on x64 it worked fine. Then I realized that appropriate path in Qemu was unimplemented: https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2141
diff --git a/results/classifier/deepseek-2-tmp/output/network/2444 b/results/classifier/deepseek-2-tmp/output/network/2444
deleted file mode 100644
index cea28b12..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2444
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Use of vulnerable function 'strcpy' at can_socketcan.c:213. This function is unsafe.
diff --git a/results/classifier/deepseek-2-tmp/output/network/248 b/results/classifier/deepseek-2-tmp/output/network/248
deleted file mode 100644
index b7b4a5e1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/248
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Reconnect failed with loopback virtio1.1 server mode test
diff --git a/results/classifier/deepseek-2-tmp/output/network/2494 b/results/classifier/deepseek-2-tmp/output/network/2494
deleted file mode 100644
index 7ad34952..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2494
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Isolated network between VMs not visible to the host
diff --git a/results/classifier/deepseek-2-tmp/output/network/2528 b/results/classifier/deepseek-2-tmp/output/network/2528
deleted file mode 100644
index 55f598b6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2528
+++ /dev/null
@@ -1,10 +0,0 @@
-
-nbd: CVE-2024-7409 fix is incomplete
-Description of problem:
-Patch will hit list soon, but opening issue here since if this misses 9.1, we would need to allocate a second CVE for having an incomplete fix (a remaining use-after-free) in the code originally proposed for CVE-2024-7409.
-Steps to reproduce:
-1. stress test of attempting repeated 'qemu-nbd --list' in parallel with repeated 'nbd-server-start/nbd-server-stop' loops in a qemu process revealed a use-after-free SEGV of nbd_server->listener
-2.
-3.
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/2584 b/results/classifier/deepseek-2-tmp/output/network/2584
deleted file mode 100644
index f650c1c2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2584
+++ /dev/null
@@ -1,17 +0,0 @@
-
-nbd URI wrong export name (regression in qemu 9.1)
-Description of problem:
-qemu with an nbd URI seems to pass the wrong export name to the server, if the exportname is `.`.  This seems
-to be a regression in qemu 9.1, because it didn't happen in 9.0.
-Steps to reproduce:
-```
-$ nbdkit -fv -U - null --run 'qemu-img info "nbd+unix:///.?socket=$unixsocket"'
-...
-nbdkit: null[1]: debug: null: open readonly=0 exportname="" tls=0
-```
-
-In qemu 9.0 this was correct:
-
-```
-nbdkit: null[1]: debug: null: open readonly=0 exportname="." tls=0
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/2623 b/results/classifier/deepseek-2-tmp/output/network/2623
deleted file mode 100644
index 3b6e1efd..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2623
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Timeout waiting for ARP/RARP packets
diff --git a/results/classifier/deepseek-2-tmp/output/network/2688 b/results/classifier/deepseek-2-tmp/output/network/2688
deleted file mode 100644
index 91cfe4d2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2688
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Add `disable_host_loopback` for network user backend
diff --git a/results/classifier/deepseek-2-tmp/output/network/2690 b/results/classifier/deepseek-2-tmp/output/network/2690
deleted file mode 100644
index 314259f1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2690
+++ /dev/null
@@ -1,21 +0,0 @@
-
-"Guest says index 40947 is available"
-Description of problem:
-As discussed [here](https://github.com/danobi/vmtest/issues/96) I have been running several instances of QEMU in parallel at `SCHED_IDLE`, and I've been getting QGA setup failures.
-Steps to reproduce:
-1. Install [vmtest](https://github.com/danobi/vmtest)
-2. Run lots of copies of the command in the [github issues](https://github.com/danobi/vmtest/issues/96) via `chrt --idle 0`.
-3. Unclear if this is the cause, but then I use the computer in the meantime so probably starve the `SCHED_IDLE` QEMU threads running from 2.
-
-This leads to failures to connect to the guest agent and then at the end I see this:
-
-```
-Guest says index 40947 is available
-    qemu-system-x86_64: Guest says index 40947 is available
-    qemu-system-x86_64: Guest says index 40947 is available
-```
-
-
-The developer of vmtest seemed to think this may be of interest to QEMU developers based on the tone of the [comment they found](https://github.com/danobi/vmtest/issues/96#issuecomment-2483860554) in the QEMU code.
-
-I've now installed QEMU from Git master so I can report back whether the bug still appeared.
diff --git a/results/classifier/deepseek-2-tmp/output/network/2740 b/results/classifier/deepseek-2-tmp/output/network/2740
deleted file mode 100644
index f3f6876a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2740
+++ /dev/null
@@ -1,68 +0,0 @@
-
-Out-of-bounds access and heap-use-after-free in smc91c111_writeb()
-Description of problem:
-An out-of-bounds access bug was triggered by my fuzzer.
-
-The error is:
-
-```
-../hw/net/smc91c111.c:457:17: runtime error: index 48 out of bounds for type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]')
-SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/net/smc91c111.c:457:17 in
-=================================================================
-==60006==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000385b4 at pc 0x5de3d1ac6add bp 0x7ffc4d4b2b30 sp 0x7ffc4d4b2b28
-WRITE of size 1 at 0x6290000385b4 thread T0
-warning: DWARF unit at offset 0x00417a37 has unsupported address size: 31 (supported are 2, 4, 8)
-    #0 0x5de3d1ac6adc in smc91c111_writeb smc91c111.c
-    #1 0x5de3d1abf6e3 in smc91c111_writefn smc91c111.c
-    #2 0x5de3d2d9e2d3 in memory_region_write_accessor memory.c
-    #3 0x5de3d2d9da4a in access_with_adjusted_size memory.c
-    #4 0x5de3d2d9ce78 in memory_region_dispatch_write
-    #5 0x5de3d2df5e44 in flatview_write_continue_step physmem.c
-    #6 0x5de3d2de2d40 in flatview_write physmem.c
-    #7 0x5de3d2de29d7 in address_space_write
-    ...
-
-0x6290000385b4 is located 5044 bytes inside of 16176-byte region [0x629000037200,0x62900003b130)
-freed by thread T0 here:
-    #0 0x5de3d1100027 in __interceptor_free.part.0 asan_malloc_linux.cpp
-    #1 0x5de3d2f35106 in object_unref
-    #2 0x5de3d24ac45c in qemu_get_nic_models
-    #3 0x5de3d24acead in qemu_create_nic_bus_devices
-    #4 0x5de3d2722553 in realview_init realview.c
-    #5 0x5de3d1468182 in machine_run_board_init
-    #6 0x5de3d237e40a in qmp_x_exit_preconfig
-    #7 0x5de3d238505c in qemu_init
-    ...
-
-previously allocated by thread T0 here:
-    #0 0x5de3d1101217 in malloc
-    #1 0x7ea39d40a738 in g_malloc
-    #2 0x5de3d24acead in qemu_create_nic_bus_devices
-    #3 0x5de3d2722553 in realview_init realview.c
-    #4 0x5de3d1468182 in machine_run_board_init
-    #5 0x5de3d237e40a in qmp_x_exit_preconfig
-    #6 0x5de3d238505c in qemu_init
-    ...
-```
-Steps to reproduce:
-```
-export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
-cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
-clock_step
-readw 0x4e000000
-readw 0x4e000000
-clock_step
-writel 0x4e00000c 0x2402e660
-readb 0x4e000008
-readl 0x4e000000
-clock_step
-readb 0x4e000000
-writel 0x4e000000 0x66308c81
-writew 0x4e000008 0xe40ba4c
-readb 0x4e000000
-readw 0x4e000000
-readl 0x4e000008
-EOF
-```
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/2742 b/results/classifier/deepseek-2-tmp/output/network/2742
deleted file mode 100644
index 6de57e35..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2742
+++ /dev/null
@@ -1,67 +0,0 @@
-
-heap-buffer-overflow in smc91c111_do_tx()
-Description of problem:
-A buffer-overflow bug was triggered by my fuzzer at smc91c111_do_tx().
-
-I've patched hw/net/smc91c111.c with:
-
-```
-diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c
-index 702d0e8e83..286298bf06 100644
---- a/hw/net/smc91c111.c
-+++ b/hw/net/smc91c111.c
-@@ -429,7 +429,7 @@ static void smc91c111_writeb(void *opaque, hwaddr offset,
-              /* Ignore.  */
-              return;
-          case 2: /* Packet Number Register */
--            s->packet_num = value;
-+            s->packet_num = value & (NUM_PACKETS - 1);
-              return;
-          case 3: case 4: case 5:
-              /* Should be readonly, but linux writes to them anyway. Ignore.  */
-```
-
-The error is:
-
-```
-==2724739==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000022941 at pc 0x595ebbed687b bp 0x7fffa0098a50 sp 0x7fffa0098a48
-READ of size 1 at 0x629000022941 thread T0
-    #0 0x595ebbed687a in smc91c111_do_tx hw/net/smc91c111.c:240:19
-    #1 0x595ebbed687a in smc91c111_queue_tx hw/net/smc91c111.c:284:5
-    #2 0x595ebbed687a in smc91c111_writeb hw/net/smc91c111.c:419:17
-    #3 0x595ebbed687a in smc91c111_writefn hw/net/smc91c111.c:666:9
-    #4 0x595ebd174d33 in memory_region_write_accessor system/memory.c:497:5
-    #5 0x595ebd1744aa in access_with_adjusted_size system/memory.c:573:18
-    #6 0x595ebd1738d8 in memory_region_dispatch_write system/memory.c
-    #7 0x595ebd1cc984 in flatview_write_continue_step system/physmem.c:2786:18
-    #8 0x595ebd1b9880 in flatview_write_continue system/physmem.c:2816:19
-    #9 0x595ebd1b9880 in flatview_write system/physmem.c:2847:12
-    #10 0x595ebd1b9517 in address_space_write system/physmem.c:2967:18
-    #11 0x595ebc77d5c3 in qtest_process_command system/qtest.c:522:13
-    #12 0x595ebc77b83b in qtest_process_inbuf system/qtest.c:776:9
-    ...
-```
-Steps to reproduce:
-```
-export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
-cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
-clock_step
-clock_step
-writel 0x4e000000 0x2b1e08f5
-writew 0x4e000000 0x2b1e08f5
-writel 0x4e00000c 0x66027d24
-clock_step
-readb 0x4e000000
-writel 0x4e000008 0x238e1f29
-writew 0x4e000000 0x41d9fe3b
-writel 0x4e00000c 0x27022a2d
-clock_step
-readw 0x4e000004
-clock_step
-readb 0x4e000008
-clock_step
-writew 0x4e000000 0x620c5fdf
-EOF
-```
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/2745 b/results/classifier/deepseek-2-tmp/output/network/2745
deleted file mode 100644
index 7b48d5b8..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2745
+++ /dev/null
@@ -1,27 +0,0 @@
-
-Qemu should send RARP for vhostuser regardless of whether virtio supports GUEST_ANNOUNCE
-Description of problem:
-When virtio reports to qemu that GUEST_ANNOUNCE is supported, qemu will not send RARP. The assumption, I think, is that guest kernel will do whatever is needed to announce the guest. The problem with this assumption is that 1) kernel won't send RARPs; 2) for IPv4 and IPv6 it will send GARPs and NAs; 3) for interfaces with no IP addresses, I think it won't send anything at all.
-
-RARPs are useful because they allow to notify regardless of IP configuration. I've [asked](https://issues.redhat.com/browse/RHEL-71919]) RHEL kernel folks to consider issuing RARPs from the guest kernel, but it won't happen overnight, and regardless, it's not a complete solution since we cannot expect all guests running a patched kernel with such feature.
-
-RARP packets are also often expected by underlying network components. For example, OVN controller has a special "activation-strategy=rarp" configuration that makes OVN wait for a RARP from destination chassis on live migration, and only then unblock traffic for the port. Since RARP is not issed by Qemu nor virtio-net, the OVN port is never unblocked (until its configuration is reset by CMS).
-
-I think what should be done from Qemu side is to send RARP for vhostuser ports regardless of whether virtio supports GUEST_ANNOUNCE. I **think** this can be achieved by removing this code:
-
-```
-    /* If guest supports GUEST_ANNOUNCE do nothing */
-    if (virtio_has_feature(dev->acked_features, VIRTIO_NET_F_GUEST_ANNOUNCE)) {
-        return 0;
-    }
-```
-Steps to reproduce:
-1. Start a VM with vhostuser* port and fresh virtio guest driver.
-2. Live migrate it.
-3. Observe that RARP is not sent from the migrated port. GARP (or NA for IPv6) is sent instead.
-Additional information:
-Some external bugs that may be relevant:
-
-- RHEL kernel request to send RARPs from virtio: https://issues.redhat.com/browse/RHEL-71919 (won't fix the issue for older unpatched kernels)
-- Request for OVN to handle GARPs and NAs: https://issues.redhat.com/browse/FDP-1042 (won't solve for unaddressed ports!)
-- An attempt to work around the issue in OpenStack Neutron OVN env by disabling activation strategy: https://issues.redhat.com/browse/OSPRH-12571 (not a great long term solution)
diff --git a/results/classifier/deepseek-2-tmp/output/network/2746 b/results/classifier/deepseek-2-tmp/output/network/2746
deleted file mode 100644
index 69decbcf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2746
+++ /dev/null
@@ -1,2 +0,0 @@
-
-NO_CAST.INTEGER_OVERFLOW in /hw/net/e1000.c
diff --git a/results/classifier/deepseek-2-tmp/output/network/2758 b/results/classifier/deepseek-2-tmp/output/network/2758
deleted file mode 100644
index f30e0562..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2758
+++ /dev/null
@@ -1,24 +0,0 @@
-
-Out-of-bounds access smc91c111_readb()
-Description of problem:
-An out-of-bounds bug was triggered by my fuzzer.
-
-It looks like the code doesn't have boundary checks for `data`'s access.
-
-The error is `hw/net/smc91c111.c:605:24: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')`
-
-It's likely that the line 457 also needs a check.
-Steps to reproduce:
-```
-export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
-cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
-writew 0x4e00000c 0x46084a4a
-writel 0x4e00000c 0x5c022fcc
-clock_step
-writel 0x4e000004 0x2fffa1b1
-clock_step
-readl 0x4e000008
-EOF
-```
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/2767 b/results/classifier/deepseek-2-tmp/output/network/2767
deleted file mode 100644
index 0d5f1538..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2767
+++ /dev/null
@@ -1,38 +0,0 @@
-
-sigfaul on netdev stream
-Description of problem:
-qemu sigfault if use netdev socket and hubport
-Steps to reproduce:
-1. Preconfigure network interface on /etc/network/interface or try connect from qemu server port another qemu process or other softvare (gnuradio, etc)
-```
-auto qt-test0
-iface qt-test0 
-        address 192.168.10.1/30
-        mtu 16384
-        pre-up ip tuntap add $IFACE mode tap
-        post-down ip link del dev $IFACE
-```
-2. Run qemu from the cmdline
-Additional information:
-```
-(gdb) bt
-#0  0x0000555555b547d0 in object_get_class ()
-#1  0x0000555555b9d44c in qio_channel_writev ()
-#2  0x000055555598295c in ?? ()
-#3  0x000055555597cf67 in ?? ()
-#4  0x0000555555980eb9 in qemu_net_queue_send_iov ()
-#5  0x000055555597b8e4 in ?? ()
-#6  0x000055555597ce32 in ?? ()
-#7  0x0000555555980df5 in qemu_net_queue_send ()
-#8  0x000055555598fb52 in ?? ()
-#9  0x0000555555d26755 in ?? ()
-#10 0x0000555555d270d2 in aio_dispatch ()
-#11 0x0000555555d3f5ef in ?? ()
-#12 0x00007ffff70f100e in ?? () from /usr/lib/libglib-2.0.so.0
-#13 0x00007ffff70f4988 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
-#14 0x0000555555d40f69 in main_loop_wait ()
-#15 0x000055555592fc83 in qemu_main_loop ()
-#16 0x0000555555c7c817 in qemu_default_main ()
-#17 0x00007ffff7f9a496 in libc_start_main_stage2 (main=0x5555556cc0f0 <main>, argc=12, argv=0x7fffffffebd8) at src/env/__libc_start_main.c:95
-#18 0x00005555556cd0d8 in _start ()
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/277 b/results/classifier/deepseek-2-tmp/output/network/277
deleted file mode 100644
index 5c4f5f0a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/277
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Multi-queue vhost-user fails to reconnect with qemu version >=4.2
diff --git a/results/classifier/deepseek-2-tmp/output/network/2780 b/results/classifier/deepseek-2-tmp/output/network/2780
deleted file mode 100644
index 6768f90c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2780
+++ /dev/null
@@ -1,18 +0,0 @@
-
-Out-of-bounds access in smc91c111_receive()
-Description of problem:
-An out-of-bounds access happens at hw/net/smc91c111.c:705.
-
-`hw/net/smc91c111.c:705:5: runtime error: index -1 out of bounds for type 'int[4]'`
-Steps to reproduce:
-```
-export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb"
-cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio
-writew 0x4e000005 0x227
-writel 0x4e00000b 0x25ab1f2
-writew 0x4e000000 0xaa6c
-clock_step
-EOF
-```
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/282 b/results/classifier/deepseek-2-tmp/output/network/282
deleted file mode 100644
index bdaec332..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/282
+++ /dev/null
@@ -1,2 +0,0 @@
-
-[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)
diff --git a/results/classifier/deepseek-2-tmp/output/network/2827 b/results/classifier/deepseek-2-tmp/output/network/2827
deleted file mode 100644
index e6e394a1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2827
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Document how to use QEMU user mode networking with passt
diff --git a/results/classifier/deepseek-2-tmp/output/network/2829 b/results/classifier/deepseek-2-tmp/output/network/2829
deleted file mode 100644
index 2d35f1ed..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2829
+++ /dev/null
@@ -1,22 +0,0 @@
-
-SMB sharing on FIPS enabled hosts with Samba broken
-Description of problem:
-Similar to #2593 , newer security features on GNU+Linux host OSes are continuing
-to break communication with guests running older OSes.
-
-QEMU executes the `smbd` process in [slirp.c](net/slirp.c) to facilitate the SMB
-sharing between guest and host.
-
-The host `smbd` process links in GnuTLS for authentication ciphers and algorithm
-primitives.  When `smbd` processes SMB requests from these older OS's SMB implementations,
-it errors out with error lines:
-
-`Failed to setup SPNEGO negTokenInit request`
-
-`Failed to start SPNEGO handler for negprot OID list!`
-Steps to reproduce:
-1. Access a GNU+Linux machine with GnuTLS library in FIPS mode which `smbd` links against
-2. Run `qemu-system-*` with an older guest OS with a `smb` share to host
-3. See errors in `/tmp/qemu.smb*/log.smbd`
-Additional information:
-#
diff --git a/results/classifier/deepseek-2-tmp/output/network/2849 b/results/classifier/deepseek-2-tmp/output/network/2849
deleted file mode 100644
index 534f8d36..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2849
+++ /dev/null
@@ -1,19 +0,0 @@
-
-Qemu 9.2.x & Ubuntu 24.04 Network Issue
-Description of problem:
-After successfully starting, I cannot access the Internet with the virtual machine. I can connect to the VM via SSH and execute various commands. We want a simple NAT network..
-
-We built the Qemu distribution ourselves with the following command:
-
-./configure --target-list=x86_64-softmmu --disable-install-blobs --enable-strip --enable-user --enable-system --enable-linux-user --disable-xen --enable-modules --enable-module-upgrades --enable-linux-aio --enable-fdt --enable-gnutls --enable-libiscsi --enable-libssh --enable-vnc --enable-kvm --enable-vhost-user
-make -j 12
-sudo make install
-
-Check Libvirt:
-$systemctl status libvirtd - active
-
-after the VM was successfully started, the IP 10.2.15 was set to ens3 altname enp0s3 assign.
-
-A ping to 8.8.8.8 can not be resolved.
-Additional information:
-We can rule out an image problem because this image runs without problems on the Windows Mac guest system and an Internet connection is possible.
diff --git a/results/classifier/deepseek-2-tmp/output/network/2876 b/results/classifier/deepseek-2-tmp/output/network/2876
deleted file mode 100644
index a5c08eef..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2876
+++ /dev/null
@@ -1,15 +0,0 @@
-
-IPv6 support for hostfwd + guestfwd
-Description of problem:
-When using hostfwd, only IPv4 connections are forwarded.
-Steps to reproduce:
-1. Start vm with the aforementioned command using a system image that comes with a socket listening on both IPv4 and IPv6. (I used Arch Linux Box which comes with `sshd` enabled by default).
-2. Connect to the forwarded socket:
-  - IPv4 succeeds:
-    - `ssh -oPasswordAuthentication=yes arch@127.0.0.1 -p 52022`
-    - `nc -zv 127.0.0.1 52022`
-  - IPv6 does not:
-    - `ssh -oPasswordAuthentication=yes arch@::1 -p 52022`
-    - `nc -zv ::1 52022`
-Additional information:
-#
diff --git a/results/classifier/deepseek-2-tmp/output/network/291 b/results/classifier/deepseek-2-tmp/output/network/291
deleted file mode 100644
index 9abfd204..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/291
+++ /dev/null
@@ -1,2 +0,0 @@
-
-deadlock in e1000e
diff --git a/results/classifier/deepseek-2-tmp/output/network/2934 b/results/classifier/deepseek-2-tmp/output/network/2934
deleted file mode 100644
index d26e9c56..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2934
+++ /dev/null
@@ -1,65 +0,0 @@
-
-RSS eBPF failed to load
-Description of problem:
-I am seeing a failure to load the eBPF program for rss steering.
-Steps to reproduce:
-1. Using libvirt, enable rss='on' for the vhost driver.
-2.
-3.
-Additional information:
-Libvirt log:
-```
-libbpf: prog 'tun_rss_steering_prog': BPF program load failed: Invalid argument
-libbpf: prog 'tun_rss_steering_prog': -- BEGIN PROG LOAD LOG --
-back-edge from insn 587 to 501
-processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
--- END PROG LOAD LOG --
-libbpf: prog 'tun_rss_steering_prog': failed to load: -22
-libbpf: failed to load object 'rss_bpf'
-libbpf: failed to load BPF skeleton 'rss_bpf': -22
-2025-04-26T09:22:19.054471Z qemu-system-x86_64: -device {"driver":"virtio-net-pci","packed":true,"tx":"bh","ioeventfd":true,"event_idx":true,"host_ecn":true,"mrg_rxbuf":true,"guest_ecn":true,"mq":true,"vectors":14,"rx_queue_size":1024,"tx_queue_size":256,"rss":true,"netdev":"hostnet0","id":"net0","mac":"52:54:00:c3:6f:c2","bus":"pci.1","addr":"0x0"}: warning: Unable to load eBPF program
-```
-[qemu-log.txt](/uploads/2d5e49a38a54297586a4b1f16423fc27/qemu-log.txt)
-
-XML:
-```xml
-   <interface type='bridge'>
-      <mac address='52:54:00:be:49:ff'/>
-      <source bridge='inet'/>
-      <model type='virtio'/>
-      <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='on' queues='6' rx_queue_size='1024' tx_queue_size='256' rss='on' packed='on'>
-        <host ecn='on' mrg_rxbuf='on'/>
-        <guest ecn='on'/>
-      </driver>
-      <link state='up'/>
-      <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
-    </interface>
-```
-
-Host kernel .config:
-```
-❯ zcat /proc/config.gz |grep -i bpf
-CONFIG_BPF=y
-CONFIG_HAVE_EBPF_JIT=y
-CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
-# BPF subsystem
-CONFIG_BPF_SYSCALL=y
-CONFIG_BPF_JIT=y
-CONFIG_BPF_JIT_ALWAYS_ON=y
-CONFIG_BPF_JIT_DEFAULT_ON=y
-CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
-# CONFIG_BPF_PRELOAD is not set
-# CONFIG_BPF_LSM is not set
-# end of BPF subsystem
-CONFIG_CGROUP_BPF=y
-CONFIG_NETFILTER_BPF_LINK=y
-CONFIG_NETFILTER_XT_MATCH_BPF=m
-CONFIG_NET_CLS_BPF=m
-CONFIG_NET_ACT_BPF=m
-CONFIG_BPF_STREAM_PARSER=y
-CONFIG_LWTUNNEL_BPF=y
-# HID-BPF support
-CONFIG_HID_BPF=y
-# end of HID-BPF support
-CONFIG_BPF_EVENTS=y
-```
diff --git a/results/classifier/deepseek-2-tmp/output/network/2951 b/results/classifier/deepseek-2-tmp/output/network/2951
deleted file mode 100644
index 96689364..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2951
+++ /dev/null
@@ -1,22 +0,0 @@
-
-First byte of USB NIC is hardcoded to 0x40
-Description of problem:
-Incus recently added support for USB attached network interfaces.
-As with any network device, we generate a MAC address (using our MAC OUI) and allow the user to override that to a value of their choice.
-
-That's when we noticed that no matter what MAC address we set, the resulting MAC always has the prefix swapped to "40:". Looking into the code, this is done on purpose here:
-
-https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/dev-network.c?ref_type=heads#L1386
-
-Unfortunately there is no comment in the code or in any of the commits touching that code as far as why that is.
-
-We've also looked at the libvirt code handling those devices and that code seems to also assume that a user provided MAC will be correctly passed through to the guest, no mention of the odd prefix override.
-
-This is a bit concerning as there are valid IEEE OUI with the "40:" prefix.
-So this means that QEMU may be generating collisions with actual physical MAC addresses...
-
-For a few months now, I've been applying this small patch to my own Incus packages (which bundle QEMU) and haven't heard or seen any obvious issue from the change.
-
-https://github.com/zabbly/incus/blob/daily/patches/qemu-0001-usb-net-mac.patch
-
-Does anyone know why this hardcoded MAC address prefix exists?
diff --git a/results/classifier/deepseek-2-tmp/output/network/2962 b/results/classifier/deepseek-2-tmp/output/network/2962
deleted file mode 100644
index 4b539747..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/2962
+++ /dev/null
@@ -1,23 +0,0 @@
-
-DHCP UDP checksum workaround code appears to be broken
-Description of problem:
-I am running dnsmasq DHCP server in an lxc-container.  It is using a VETH pair for the network.  The VETH device on the host is in a bridge.  I create a TAP device and place it in the bridge.  When booting the guest, I notice that the DHCP OFFER has an invalid UDP checksum all the way through the bridge and into the guest.  I am able to fix this by disabling checksum offload inside the container, or adding an nftables rule that zeros out the checksum, or by reverting commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce.
-Steps to reproduce:
-1. From a debian 12 host, `apt-get install lxc lxc-templates`
-2. `ip link add brtest type bridge`
-3. `ip link set brtest up`
-4. Create a container: `lxc-create -n dhcp -t debian -- --package=dnsmasq`
-5. Edit the lxc container file `/var/lib/lxc/dhcp/config` and make sure the link is properly set to `lxc.net.0.link = brtest`, the type is set to `veth`, and give it an IP `lxc.net.0.ipv4.address = 192.168.255.1/24`
-6. Start the container: `lxc-start -n dhcp`
-7. Attach to the container: `lxc-attach -n dhcp`
-8. Stop dnsmasq and networking: `systemctl stop dnsmasq.service networking.service`
-9. Run a DHCP server: `dnsmasq --dhcp-authoritative --dhcp-range=192.168.255.2,192.168.255.254,255.255.255.0,1h --dns-loop-detect`
-10. Exit the container: `exit`
-11. Download the linux mint 22.1 installer: https://linuxmint.com/edition.php?id=319
-12. Create a TAP device and throw it in the bridge: `ip tuntap add dev taptest mode tap` .. `ip link set dev taptest up master brtest`
-13. Run qemu: `qemu-system-x86_64 -enable-kvm -smp 4,sockets=1,threads=1 -machine pc-q35-9.2,accel=kvm,kernel_irqchip=on -m 4096 -device virtio-net-pci,netdev=nic91 -netdev tap,id=nic91,ifname=taptest,script=no,downscript=no -cdrom linuxmint-22.1-cinnamon-64bit.iso` .. I run it with vnc as this is on a headless server.
-14. Once the guest has booted, you can run a tcpdump on the NIC and see that the guest receives the DHCP offer, but the UDP checksum is bunk.
-Additional information:
-I was able to test reverting the commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce and that appears to function once again.
-
-![image](/uploads/1d649230eabee269f78031eb0b2de265/image.png){width=901 height=38}
diff --git a/results/classifier/deepseek-2-tmp/output/network/308 b/results/classifier/deepseek-2-tmp/output/network/308
deleted file mode 100644
index 6dd77c1f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/308
+++ /dev/null
@@ -1,2 +0,0 @@
-
-QEMU: net: vmxnet: integer overflow may crash guest
diff --git a/results/classifier/deepseek-2-tmp/output/network/323 b/results/classifier/deepseek-2-tmp/output/network/323
deleted file mode 100644
index 0d1a6cf8..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/323
+++ /dev/null
@@ -1,2 +0,0 @@
-
-qemu 5.2.0: Add reconnect option support for netdev socket
diff --git a/results/classifier/deepseek-2-tmp/output/network/335 b/results/classifier/deepseek-2-tmp/output/network/335
deleted file mode 100644
index dce47474..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/335
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Broken tap networking on macOS host
diff --git a/results/classifier/deepseek-2-tmp/output/network/347 b/results/classifier/deepseek-2-tmp/output/network/347
deleted file mode 100644
index d9477d86..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/347
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Forward host UNIX socket to guest TCP port
diff --git a/results/classifier/deepseek-2-tmp/output/network/348 b/results/classifier/deepseek-2-tmp/output/network/348
deleted file mode 100644
index 2b0ec898..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/348
+++ /dev/null
@@ -1,2 +0,0 @@
-
-qemu-user fails to run container using systemd-networkd: "Could not create manager: Protocol not supported"
diff --git a/results/classifier/deepseek-2-tmp/output/network/354 b/results/classifier/deepseek-2-tmp/output/network/354
deleted file mode 100644
index b7cd22cf..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/354
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Emulation error when calling the SIOCGIFNETMASK ioctl through qemu-user
diff --git a/results/classifier/deepseek-2-tmp/output/network/377 b/results/classifier/deepseek-2-tmp/output/network/377
deleted file mode 100644
index 1990a741..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/377
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Indentation should be done with spaces, not with TABs, in the net subsystem
diff --git a/results/classifier/deepseek-2-tmp/output/network/402 b/results/classifier/deepseek-2-tmp/output/network/402
deleted file mode 100644
index 9095dc29..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/402
+++ /dev/null
@@ -1,2 +0,0 @@
-
-e1000 / e1000e randomly stop sending packets to VM with DPDK app in VM
diff --git a/results/classifier/deepseek-2-tmp/output/network/428 b/results/classifier/deepseek-2-tmp/output/network/428
deleted file mode 100644
index 8e67de6b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/428
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Windows: Very low network throughput with tap-netdev & virtio-serial
diff --git a/results/classifier/deepseek-2-tmp/output/network/453617 b/results/classifier/deepseek-2-tmp/output/network/453617
deleted file mode 100644
index 45969735..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/453617
+++ /dev/null
@@ -1,54 +0,0 @@
-
-kvm hangs at 100% cpu when connecting to forwarded ports (when listed incorrectly on the command line)
-
-Binary package hint: qemu-kvm
-
-If kvm is started using two separate "-net user,hostfwd=<forwarding rule>" arguments to forward ports from the host to the client, it won't complain, but will return a connection refused error and hang at 100% cpu when trying to connect to either forwarded port.
-
-However, if kvm is started with the hostfwd rules combined together into a single "-net user" argument, it works fine.
-
-As an example, this command line doesn't generate any warnings or errors, but causes kvm to hang for me:
-
-kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2
-
-... but this command line works fine:
-
-kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2
-
-ProblemType: Bug
-Architecture: amd64
-Date: Fri Oct 16 17:19:59 2009
-DistroRelease: Ubuntu 9.10
-KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
-MachineType: Sony Corporation VGN-SZ650N
-NonfreeKernelModules: nvidia
-Package: kvm (not installed)
-PccardctlIdent:
- Socket 0:
-   no product info available
-PccardctlStatus:
- Socket 0:
-   no card
-ProcCmdLine: root=UUID=3ee4953e-48f0-497c-ae78-18cbb18cfef8 ro quiet splash
-ProcEnviron:
- LANGUAGE=en_US.UTF-8
- PATH=(custom, user)
- LANG=en_US.UTF-8
- SHELL=/bin/bash
-ProcVersionSignature: Ubuntu 2.6.31-14.47-generic
-SourcePackage: qemu-kvm
-Uname: Linux 2.6.31-14-generic x86_64
-dmi.bios.date: 07/12/2007
-dmi.bios.vendor: Phoenix Technologies LTD
-dmi.bios.version: R0081S5
-dmi.board.asset.tag: N/A
-dmi.board.name: VAIO
-dmi.board.vendor: Sony Corporation
-dmi.board.version: N/A
-dmi.chassis.type: 10
-dmi.chassis.vendor: Sony Corporation
-dmi.chassis.version: N/A
-dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrR0081S5:bd07/12/2007:svnSonyCorporation:pnVGN-SZ650N:pvrJ002VXGP:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:
-dmi.product.name: VGN-SZ650N
-dmi.product.version: J002VXGP
-dmi.sys.vendor: Sony Corporation
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/460 b/results/classifier/deepseek-2-tmp/output/network/460
deleted file mode 100644
index 8aa5f8d6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/460
+++ /dev/null
@@ -1,2 +0,0 @@
-
-vmxnet3: Assertion failure in eth_setup_ip4_fragmentation
diff --git a/results/classifier/deepseek-2-tmp/output/network/474968 b/results/classifier/deepseek-2-tmp/output/network/474968
deleted file mode 100644
index 784358ad..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/474968
+++ /dev/null
@@ -1,37 +0,0 @@
-
-kvm smb server hogs cpu guest freeze
-
-Binary package hint: qemu-kvm
-
-kvm hogs the CPU reproducibly. I installed an Ubuntu using KVM. I run the machine with -net nic,model=rtl8139,macaddr=f0:00:BA:12:34:56 -net user,hostfwd=tcp::2223-:22,smb=/tmp/share, sshed into the machine and typed "telnet 10.0.2.4 139" to try whether the SMB server works. KVM then hogs the CPU.
-
-ProblemType: Bug
-Architecture: amd64
-Date: Thu Nov  5 01:23:09 2009
-DistroRelease: Ubuntu 9.10
-KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
-MachineType: LENOVO 766636G
-Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3
-PccardctlIdent:
- Socket 0:
-   no product info available
-PccardctlStatus:
- Socket 0:
-   no card
-ProcCmdLine: root=/dev/mapper/cryptroot source=UUID=9c3d5596-27c6-4fd5-bfcd-fa8eef6f1230 ro quiet splash  crashkernel=384M-2G:64M,2G-:128M
-SourcePackage: qemu-kvm
-Uname: Linux 2.6.32-999-generic x86_64
-dmi.bios.date: 07/01/2008
-dmi.bios.vendor: LENOVO
-dmi.bios.version: 7NETB6WW (2.16 )
-dmi.board.name: 766636G
-dmi.board.vendor: LENOVO
-dmi.board.version: Not Available
-dmi.chassis.asset.tag: No Asset Information
-dmi.chassis.type: 10
-dmi.chassis.vendor: LENOVO
-dmi.chassis.version: Not Available
-dmi.modalias: dmi:bvnLENOVO:bvr7NETB6WW(2.16):bd07/01/2008:svnLENOVO:pn766636G:pvrThinkPadX61s:rvnLENOVO:rn766636G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
-dmi.product.name: 766636G
-dmi.product.version: ThinkPad X61s
-dmi.sys.vendor: LENOVO
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/485250 b/results/classifier/deepseek-2-tmp/output/network/485250
deleted file mode 100644
index 6b13ac26..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/485250
+++ /dev/null
@@ -1,22 +0,0 @@
-
-nic e1000 network interface does not work with 32-bit windows 2003r2 with  sp2
-
-nic e1000 network interface does not work with win2k3r2 32bit
-
-e1000 driver in win2k3r2 32bit seems to be broken. The interface is able to
-receive ip from the dhcp server, but not able to ping it from any linux guest or
-host, but was able to ping it from windows guest.
-
-Running network test, netperf, between the windows guest fails with the message 
-"netperf: receive_response: no response received. errno 104 counter 0"
-
-cmdline used:
-/usr/local/bin/qemu-system-x86_64 -drive file=win2003r2sp2-32.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:04,model=e1000  -net tap,vlan=0,script=/home/yogi/qemu-ifup  -m 2048 -enable-kvm  -usbdevice tablet -vnc :1
-
-uname -a
-Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
-
-Distro: fedora 11
-
-Thx
-yogi
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/485258 b/results/classifier/deepseek-2-tmp/output/network/485258
deleted file mode 100644
index b6c6438c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/485258
+++ /dev/null
@@ -1,29 +0,0 @@
-
-64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test
-
-64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test
-
-Steps to recreate:
-1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git
-
-2)Download Soap Stone Benchmark(http://soap-stone.sourceforge.net/) and IBM java 1.4 for windows
-
-3)use  win2k3r2sp2 64-bit as the server and win2k3r2sp2 32-bit as client (this bug does not occur when win2k3r2sp2 64-bit is the client)
-
-4) Running the test will reset the  network interface on the server(win2k3r2sp264bit).
-
-5)Then shutdown the server(win2k3r2sp2 64bit), which will generate a blue screen.
-
-
-Qemu cmd line used:
-/usr/local/bin/qemu-system-x86_e 'vm1'  -drive file=win2003r2-64.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:01,model=rtl8139  -net tap,vlan=0,script=/home/yogi/qemu-ifup  -m 10240   -usbdevice tablet -vnc :0 -enable-kvm
-
-uname -a
-Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
-
-Distro: fedora 11
-
-I have attached the generated Blue Screen..
-
-Thx
-yogi
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/495566 b/results/classifier/deepseek-2-tmp/output/network/495566
deleted file mode 100644
index 9e2c6bbd..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/495566
+++ /dev/null
@@ -1,22 +0,0 @@
-
-qemu network adapter initialization fails when using macaddr=<multicast MAC-address>
-
-Not sure if ultra-strange, nondocumented feature in qemu (or linux kernel) or really bug: Network card initialization fails if first byte of mac address  is not 00. The problem occurs at least with model=pcnet/rtl8139, in both cases the network adapter is not usable.
-
-How to reproduce:
-
-* Take standard  initrd/kernel (tested with hardy)
-
-* Start qemu (cmd see below) and enter "modprobe pcnet32" at prompt:
-qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=00:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount
-
-You will see "pcnet32 ... at 0x..., 00:22:33:44:55:66
-
-* Do same with mac address 11:22:33:44:55:66
-qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=11:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount
-
-You will see "pcnet32 ... at 0x..., 00:00:00:00:00:00
-
-The network adapter is non-functional, "ip link set eth0 up" does not report error, but does not work (indicates at least some linux kernel influence)
-
-With the rtl8139 adapter, mac-address in guest is correct, but adapter does not work either (indicates qemu influence)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/517 b/results/classifier/deepseek-2-tmp/output/network/517
deleted file mode 100644
index 6343d76a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/517
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Abort in vmxnet3_setup_tx_offloads
diff --git a/results/classifier/deepseek-2-tmp/output/network/533 b/results/classifier/deepseek-2-tmp/output/network/533
deleted file mode 100644
index 4c51e67f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/533
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Assertion failure in vmxnet3_get_next_body_rx_descr: d->btype == VMXNET3_RXD_BTYPE_BODY
diff --git a/results/classifier/deepseek-2-tmp/output/network/534 b/results/classifier/deepseek-2-tmp/output/network/534
deleted file mode 100644
index a870bbd6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/534
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Memcpy param-overlap through e1000e_write_to_rx_buffers
diff --git a/results/classifier/deepseek-2-tmp/output/network/535 b/results/classifier/deepseek-2-tmp/output/network/535
deleted file mode 100644
index 77a89660..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/535
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Assertion failure in iov_from_buf_full through the e1000e
diff --git a/results/classifier/deepseek-2-tmp/output/network/539 b/results/classifier/deepseek-2-tmp/output/network/539
deleted file mode 100644
index 822dc2a2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/539
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Abort in vmxnet3_validate_interrupt_idx
diff --git a/results/classifier/deepseek-2-tmp/output/network/546638 b/results/classifier/deepseek-2-tmp/output/network/546638
deleted file mode 100644
index a7055adc..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/546638
+++ /dev/null
@@ -1,55 +0,0 @@
-
-Connection error when use PXE+NFS to boot guest
-
-I use NFS+PXE to boot RHEL 5. The installation is slow, and I send Ctrl+Alt+F4, then find that half (but not all) of connections are dropped:
-
-nfs: server 192.168.122.50 OK
-nfs: server 192.168.122.50 OK
-nfs: server 192.168.122.50 OK
-nfs: server 192.168.122.50 not responding, still trying
-nfs: server 192.168.122.50 OK
-nfs: server 192.168.122.50 not responding, still trying
-nfs: server 192.168.122.50 not responding, still trying
-:
-:
-
-I have checked that there is no IP conflict.
-
-Host machine
-Kernel: 2.6.32.9-70.fc12.x86_64
-QEMU version: 0.12.3-2.fc12.x86_64
-libvirt version: 0.7.1-15.fc12.x86_64
-
-Guest machine 1 (NFS server)
-Kernel: 2.6.18-164.el5
-nfs-utils version: 1.0.9-42.el5
-Set up command: virt-install --connect qemu:///system -n m5 --vnc --accelerate --ram=256 --noreboot --os-type=linux --pxe --os-variant=rhel5 --mac=52:54:00:50:00:00 --file=/dev/VolGroup00/m5
-
-Guest machine 2 (the machine to be installed via PXE+NFS)
-Set up command: virt-install --connect qemu:///system -n e51 --vnc --accelerate --ram=128 --noreboot --os-type=linux --pxe –os-variant=rhel5 --mac=52:54:00:51:01:00 --file=/dev/VolGroup00/e51
-
-============================================================================
-I try to use NFS under different situations to test.
-Test 1) Try normal NFS mount. This test successes.
-Test 2) Try to boot a diskless machine via PXE, use a NFS mount point at root. This test suffers the same problem
-
-At test 1)
-NFS client mount an export of the NFS server, and use command "find ." to see if it runs smoothly.
-Result: it runs smoothly for thousands of lines.
-
-Guest machine 3 (NFS server)
-Kernel: 2.6.18-164.el5
-Set up command: virt-install --connect qemu:///system -n dm1 --vnc --accelerate --ram=256 --noreboot --os-type=linux --pxe --os-variant=rhel5 --mac=52:54:00:d1:00:00 --file=/dev/VolGroup00/dm1
-
-NFS client is Guest machine 1 mentioned before.
-
-At test 2)
-Set up a PXE server, write a customized initrd, in which init script uses "mkrootdev -t nfs -o nolock,ro" to set root directory on a NFS mount.
-
-Result: the client machine can boot, but very slowly, with numerous
-nfs: server 192.168.122.110 OK
-nfs: server 192.168.122.110 not responding, still trying
-
-NFS server: it is Guest machine 3
-Client to be booted: Guest machine 4
-Set up command: virt-install --connect qemu:///system -n de11 --vnc --accelerate --ram=128 --noreboot --os-type=linux --pxe –os-variant=rhel5 --nodisk --mac=52:54:00:d1:01:00
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/557 b/results/classifier/deepseek-2-tmp/output/network/557
deleted file mode 100644
index c7f2c2e2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/557
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Stack-overflow through pcnet_tmd_load
diff --git a/results/classifier/deepseek-2-tmp/output/network/562107 b/results/classifier/deepseek-2-tmp/output/network/562107
deleted file mode 100644
index f482ffd1..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/562107
+++ /dev/null
@@ -1,13 +0,0 @@
-
-QEmu GDB stub uses IPv6 instead of v4 (or both)
-
-This bug has been reported by several people already.
-
-See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/
-and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248
-
-
-Seems like a very easy fix. 
-
-Regards,
-Matthijs ter Woord
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/580 b/results/classifier/deepseek-2-tmp/output/network/580
deleted file mode 100644
index de2ee9a7..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/580
+++ /dev/null
@@ -1,18 +0,0 @@
-
-access internet from guest
-Description of problem:
-I can ssh back to host using ssh 10.0.2.2.
-Also I can login to guest from host using ssh riscv@localhost -p 3333.
-However,
-I could not get internet access from the guest os system, such as:
-```
-[riscv@fedora-riscv ~]$ wget www.google.com
---2019-12-15 05:53:04--  http://www.google.com/
-Resolving www.google.com (www.google.com)... 216.58.194.164, 2607:f8b0:4005:804::2004
-Connecting to www.google.com (www.google.com)|216.58.194.164|:80... failed: Connection refused.
-Connecting to www.google.com (www.google.com)|2607:f8b0:4005:804::2004|:80... failed: Network is unreachable.
-```
-Therefore, I could not use dnf to install packages.
-Any help will be appreciated.
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/588731 b/results/classifier/deepseek-2-tmp/output/network/588731
deleted file mode 100644
index a0f85775..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/588731
+++ /dev/null
@@ -1,29 +0,0 @@
-
-PXE boot not working
-
-/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor
-
-
-
-net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
- [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
- DHCP (net0 02:5a:3b:27:00:a1)................ Connection timed out (0x4c106035)                                                            
- No more network devices                                                                                                                    
-                                                                                                                                                                                                     
-No bootable device. 
-
-
-
-After doing a system_reset ....
-
-net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
- [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
-DHCP (net0 02:5a:3b:27:00:a1).... ok                                                                                                       
-net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1                                                                                                   
-Booting from filename "boot.pxe"                                                                                                          
-tftp://x.x.x./boot.pxe.. ok      
-
-
-And it magaically works.
-
-using HEAD.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/589315 b/results/classifier/deepseek-2-tmp/output/network/589315
deleted file mode 100644
index fc1b6974..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/589315
+++ /dev/null
@@ -1,19 +0,0 @@
-
-qemu: Improve error reporting when migration can't connect
-
-Tested with upstream qemu as of Jun 3 2010
-
-If the source qemu instance can't connect to the migration destination (say
-there is no listening QEMU instance, or port is blocked by a firewall), all we
-get is info migrate -> Migration status: failed. This is all we have to report
-back to libvirt users if their firewall is misconfigured, which is crappy.
-
-Ideally, if we can't connect, migration would fail immediately with a relevant
-message and strerror(). More info from 'info migrate' would be nice too, no
-idea how this will play with QMP though.
-
-As a slightly related issue, try entering
-
-migrate tcp:127.0.0.0:6000
-
-We get a 'migration failed' error, and then the monitor hangs!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/589827 b/results/classifier/deepseek-2-tmp/output/network/589827
deleted file mode 100644
index aa0861d2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/589827
+++ /dev/null
@@ -1,15 +0,0 @@
-
-QEMU netdev tap type id name is not used on linux host
-
-Tested with 0.12.3, 0.12.4, and latest git as of 4 jun 2010.
-The new -netdev type seems to ignore manual specifications of tap ifname.
-
-    qemu-system-x86_64 -hda disk.img -netdev tap,id=ids_e0 -device e1000,netdev=ids_e0
- **creates tap0 instead of ids_e0.  tap0 passes traffic, ids_e0 doesn't exist
-(I tried -netdev type=tap as well for brevity)
-
-QEMU creates a tap0 (or appropriate) interface and does not name this "ids_e0" as would be expected.  I also tried 'pre' creating the tap interface.
-
-Previous alterantive was
-    qemu-system-x86_64 -hda disk.img -net nic,model=e1000,vlan=99 -net tap,ifname=ids_e0,vlan=99 
-  **creates ids_e0 as expected, and passes traffic as expected.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/590552 b/results/classifier/deepseek-2-tmp/output/network/590552
deleted file mode 100644
index 881740cb..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/590552
+++ /dev/null
@@ -1,17 +0,0 @@
-
-New default network card doesn't work with tap networking
-
-Unfortunately, I can provide very little information.
-
-Hope this will be useful anyway.
-
-I've upgraded qemu using debian apt to lastest unstable (QEMU PC emulator version 0.12.4 (Debian 0.12.4+dfsg-2), Copyright (c) 2003-2008 Fabrice Bellard): looks like at some point the default network card for -net nic option was switched to intel gigabit instead of the good old ne2k_pci.
-
-I was using -net tap -net nic options and my network stopped working.
-When not working,
-- tcpdump on the host shows me taht all packets are sent and received fine from guest
-- tcpdump on guest shows that packets from host are NOT received
-
-obviously, both host tap interface and guest eth0 interfaces, routing tables, dns, firewall, etc... are well configured.
-
-Having banged my head for a while, I finally stopped the host and started it again using -net nic,model=ne2k_pci option, then my network magically started working again.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/593 b/results/classifier/deepseek-2-tmp/output/network/593
deleted file mode 100644
index 303e01a6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/593
+++ /dev/null
@@ -1,8 +0,0 @@
-
-USB ECM network device does not work under XHCI
-Description of problem:
-No data is ever received by the USB ECM network device when it is attached to an XHCI controller. (USB 1.0 controllers work OK.)
-Additional information:
-There are some patches it appears were submitted to the GitHub mirror that resolve the problem (I tested them applied to git master, and confirmed they work): https://github.com/qemu/qemu/pull/100
-
-I guess they never were submitted to the mailing list, or somehow got missed?
diff --git a/results/classifier/deepseek-2-tmp/output/network/597351 b/results/classifier/deepseek-2-tmp/output/network/597351
deleted file mode 100644
index 9d80328c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/597351
+++ /dev/null
@@ -1,31 +0,0 @@
-
-Slow UDP performance with virtio device
-
-I'm working on an app that is very sensitive to round-trip latency
-between the guest and host, and qemu/kvm seems to be significantly
-slower than it needs to be.
-
-The attached program is a ping/pong over UDP.  Call it with a single
-argument to start a listener/echo server on that port.  With three
-arguments it becomes a counted "pinger" that will exit after a
-specified number of round trips for performance measurements.  For
-example:
-
-  $ gcc -o udp-pong udp-pong.c
-  $ ./udp-pong 12345 &                       # start a listener on port 12345
-  $ time ./udp-pong 127.0.0.1 12345 1000000  # time a million round trips
-
-When run on the loopback device on a single machine (true on the host
-or within a guest), I get about 100k/s.
-
-When run across a port forward using "user" networking on qemu (or
-kvm, the performance is the same) and the default rtl8139 driver (both
-the host and guest are Ubuntu Lucid), I get about 10k/s.  This seems
-very slow, but perhaps unavoidably so?
-
-When run in the same configuration using the "virtio" driver, I get
-only 2k/s.  This is almost certainly a bug in the virtio driver, given
-that it's a paravirtualized device that is 5x slower than the "slow"
-hardware emulation.
-
-I get no meaningful change in performance between kvm/qemu.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/597575 b/results/classifier/deepseek-2-tmp/output/network/597575
deleted file mode 100644
index bb312b41..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/597575
+++ /dev/null
@@ -1,33 +0,0 @@
-
-Hangs on HTTP errors when using the curl block driver
-
-Hi,
-
-It seems that qemu-kvm does not handle HTTP errors gracefully when using the curl block driver and a synchronous request is made (i.e. one using bdrv_read_em() for example). In these cases, if an HTTP error (such as 404 or 416) is returned, the aio thread exits but the main thread never finishes waiting for I/O completion, thus freezing KVM.
-
-Versions affected:
-At least 0.11.1 and 0.12.4 were tested and found to be affected.
-
-How to reproduce:
-Simply specify a non-existing path for an HTTP URL as a CDROM drive.
-kvm -drive file=test.img,format=qcow2,if=ide,index=0,boot=on -drive file=http://127.0.0.1/static/test1.iso,media=cdrom,index=2,if=ide -boot c
-
-qemu-kvm will hang on boot using 100% cpu as it will try to open the block device. At that point, the backtrace is (qemu-kvm-0.12.4):
-
-#0  0x000000000047aaaf in qemu_aio_wait () at aio.c:163
-#1  0x000000000047a055 in bdrv_read_em (bs=0x1592320, sector_num=0, buf=0x7fffcf7e9ae0 "¨\237~Ïÿ\177", nb_sectors=4)
-    at block.c:1939
-#2  0x0000000000479c0e in bdrv_pread (bs=0x1592320, offset=<value optimized out>, buf=0x7fffcf7e9ae0, count1=2048)
-    at block.c:716
-#3  0x000000000047a862 in bdrv_open2 (bs=0x1591a30, filename=0x1559f00 "http://127.0.0.1/static/test1.iso", 
-    flags=0, drv=0x84eca0) at block.c:316
-#4  0x000000000040dcb4 in drive_init (opts=0x1559e60, opaque=<value optimized out>, fatal_error=0x7fffcf7ea494)
-    at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2471
-#5  0x000000000040e086 in drive_init_func (opts=0x155db00, opaque=0x0)
-    at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2488
-#6  0x0000000000475421 in qemu_opts_foreach (list=<value optimized out>, func=0x40e070 <drive_init_func>, 
-    opaque=0x8495e0, abort_on_failure=12) at qemu-option.c:817
-#7  0x000000000040e9af in main (argc=7, argv=0x7fffcf7ea838, envp=<value optimized out>)
-    at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:6011
-
-Thanks
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/602336 b/results/classifier/deepseek-2-tmp/output/network/602336
deleted file mode 100644
index ac16e0d2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/602336
+++ /dev/null
@@ -1,80 +0,0 @@
-
-bad network performance with 10Gbit
-
-Hello,
-I have trouble with the network performance inside my virtual machines. I don't know if this is realy a bug, but I didn't find a solution for this problem in other forums or maillists.
-
-My KVM-Host machine is connected to a 10Gbit Network. All interfaces are configured to a mtu of 4132. On this host I have no problems and I can use the full bandwidth:
-
-CPU_Info:
-2x Intel Xeon X5570
-flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
-
-KVM Version:
-QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3), Copyright (c) 2003-2008 Fabrice Bellard
-0.12.3+noroms-0ubuntu9
-
-KVM Host Kernel:
-2.6.32-22-server #36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010 x86_64 GNU/Linux
-
-KVM Host OS:
-Ubuntu 10.04 LTS
-Codename: lucid
-
-KVM Guest Kernel:
-2.6.32-22-server #36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010 x86_64 GNU/Linux
-
-KVM Guest OS:
-Ubuntu 10.04 LTS
-Codename: lucid
-
-
-# iperf -c 10.10.80.100 -w 65536 -p 12345 -t 60 -P4
-[ ID] Interval Transfer Bandwidth
-[ 4] 0.0-60.0 sec 18.8 GBytes 2.69 Gbits/sec
-[ 5] 0.0-60.0 sec 15.0 GBytes 2.14 Gbits/sec
-[ 6] 0.0-60.0 sec 19.3 GBytes 2.76 Gbits/sec
-[ 3] 0.0-60.0 sec 15.1 GBytes 2.16 Gbits/sec
-[SUM] 0.0-60.0 sec 68.1 GBytes 9.75 Gbits/sec
-
-
-Inside a virtual machine don't reach this result:
-
-# iperf -c 10.10.80.100 -w 65536 -p 12345 -t 60 -P 4
-[ ID] Interval Transfer Bandwidth
-[ 3] 0.0-60.0 sec 5.65 GBytes 808 Mbits/sec
-[ 4] 0.0-60.0 sec 5.52 GBytes 790 Mbits/sec
-[ 5] 0.0-60.0 sec 5.66 GBytes 811 Mbits/sec
-[ 6] 0.0-60.0 sec 5.70 GBytes 816 Mbits/sec
-[SUM] 0.0-60.0 sec 22.5 GBytes 3.23 Gbits/sec
-
-I only can use 3,23Gbits of 10Gbits. I use the virtio driver for all of my vms, but I have also tried to use the e1000 nic device instead.
-
-With starting the iperf performance test on multiple vms simultaneously I can use the full bandwidth of the kvm host's interface. But only one vm can't use the full bandwith. Is this a known limitation, or can I improve this performance?
-
-Does anyone have an idea how I can improve my network performance? It's very important, because I want to use the network interface to boot all vms via AOE (ATA over Ethernet).
-
-If I mount a harddisk via AOE inside a vm I get only this results:
-Write |CPU |Rewrite |CPU |Read |CPU
-102440 |10 |51343 |5 |104249 |3
-
-On the KVM Host I get those results on a mouted AOE Device:
-Write |CPU |Rewrite |CPU |Read |CPU
-205597 |19 |139118 |11 |391316 |11
-
-If I mount the AOE Device directly on the kvm-host and put a virtual harddisk-file in it I got the following results inside a vm using this harddisk-file:
-Write |CPU |Rewrite |CPU |Read |CPU
-175140 |12 |136113 |24 |599989 |29
-
-I have just tested vhost_net, but without success.
-I have upgraded my kernel to 2.6.35-6 with vhost_net support and have
-installed the qemu-kvm version from
-git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git (0.12.50)
-But I still have the same results as before.
-
-I had already posted my problem into a few forums, but still got no
-reply.
-
-I would feel very happy if someone can help me.
-
-best regards
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/605 b/results/classifier/deepseek-2-tmp/output/network/605
deleted file mode 100644
index e46d6d7a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/605
+++ /dev/null
@@ -1,16 +0,0 @@
-
-QEMU crashes when receiving network connection on NetBSD
-Description of problem:
-After booting the VM, connecting to the TCP port 2222 of the host immediately crashes the VM and qemu prints:
-
-**
-Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
-Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
-Steps to reproduce:
-1. start VM as indicated
-2. telnet localhost 2222
-3. crash
-Additional information:
-**
-Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
-Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0)
diff --git a/results/classifier/deepseek-2-tmp/output/network/614958 b/results/classifier/deepseek-2-tmp/output/network/614958
deleted file mode 100644
index 265303b8..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/614958
+++ /dev/null
@@ -1,38 +0,0 @@
-
-copy-paste between client and host
-
-Hi,
-
-I propose that copy/paste between VMs be implemented somehow directly in QEMU.
-This has been discussed repeatedly elsewhere; various solutions are proposed.  See below.
-
-As it is, each user has to do their own research and testing if they are to find a solution.   This makes the product frustratingly unattractive for many.
-
-Most solutions involve either running vnc and using a vnc client that supports copy/paste (this can be tricky to find itself), or running some other tcp-based copy-paste application. 
-
-For many users, the networking in a client VM is unimportant--they just want to run some application there, and setting up netoworking in a VM itself can be an issue.  Most of these solutions rely on un-maintained software, and some require that other software be installed to make them work (Basic interpreter, Java, etc).  Any of these solutions take some work to set up.
-
-I can tell you, the absence of a copy/paste mechanism makes the project an immediate no-go for many users.  I work with a guy who spent a lot of time trying, gave up, and switched to VirtualBox for this exact reason.
-
-It would be much better if copy/paste worked out of the box.  Ideally, it should work independently of networking.
-
-Cheers!
-
-Some discussions and proposed solutions:
------------------------------------------------------
-http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=161
-    Somebody suggests VNC into the virtual host, and use vncviewer
-    Somebody else suggests TCP/IP Clipboard (text editor with tcp/ip)
-
-http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=2626
-    primitive app for sharing text across machines (in Basic)
-    http://homepage.mac.com/bnej/shareclip/
-
-http://borderworlds.dk/blog/20070217-00.html
-    Says doesn't know a good solution but points to unmaintained package
-    Qemu Guest Tools
-    http://wolfpackally.wo.funpic.de/qemu/qgt/
-
-http://bonzoli.com/docs/How_to_setup_Qemu_on_Fedora_8.html
-    proposes Java remoteclip running on client and server
-    http://www.cs.cmu.edu/afs/cs/user/rcm/WWW/RemoteClip/
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/636095 b/results/classifier/deepseek-2-tmp/output/network/636095
deleted file mode 100644
index 3c55402b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/636095
+++ /dev/null
@@ -1,43 +0,0 @@
-
-tap downscript is not executed when exiting qemu through "quit" monitor command
-
-When you tell qemu to shutdown using the "quit" monitor command, the downscript of the tap interface is not executed.
-
-
-To reproduce:
-
-
-Create the test script /tmp/qemu-ifdown-test.sh :
-
-==
-#!/bin/bash
-
-touch /tmp/is_this_working
-==
-
-Run:
-
-==
-# chmod +x /tmp/qemu-ifdown-test.sh
-# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server
-VNC server running on `127.0.0.1:5900'
-# nc -U /tmp/monitor.socket 
-QEMU 0.12.5 monitor - type 'help' for more information
-(qemu) quit
-quit
-# ls /tmp/is*
-ls: cannot access /tmp/is*: No such file or directory
-
-==
-
-If I quit qemu by sending a SIGTERM instead of using the "quit" command, the downscript does get executed:
-
-==
-# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server
-VNC server running on `127.0.0.1:5900'
-# killall qemu-system-x86_64
-# ls /tmp/is*
-/tmp/is_this_working
-==
-
-Issue occurs with both 0.12.3 and 0.12.5
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/638955 b/results/classifier/deepseek-2-tmp/output/network/638955
deleted file mode 100644
index 30f46687..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/638955
+++ /dev/null
@@ -1,33 +0,0 @@
-
-emulated netcards don't work with recent sunos kernel
-
-hi there,
-
-i'm using qemu-kvm backend in version: # qemu-kvm -version
-QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
-
-and there are just *not working any of model=$type with combinations of recent sunos (solaris, openindiana, opensolaris, ..) ..
-
-you can download for testing purposes iso from here: http://dlc-origin.openindiana.org/isos/147/ or from here: http://genunix.org/distributions/indiana/ << osol and oi are also bubuntu-like *live cds, so no need to bother with installing
-
-behaviour is as follows:
-e1000 - receiving doesn't work, transmitting works .. dladm (tool for handle ethers) shows that is all ok, correct mode is loaded up, it just seems like this driver works at 100% but ..
-
-rtl8169|pcnet - works in 10Mbit mode with several other issues like high cpu utilization and so .. dladm is unable to recognize options for this kind of -nic
-
-others - just don't work
-
-.. i experienced this issue several times in past .. woraround was, that rtl8169 worked so-so .. with recent sunos kernel it doesn't.
-
-it's easy to reproduce, this is why i'm not putting here more then launching script for my virtual machine:
-
-# cat openindiana.sh
-qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdrom /home/kvm/+images/oi-dev-147-x86.iso -boot d \
--vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,server,nowait \
--net nic,model=e1000,vlan=1 -net tap,ifname=oi0,script=no,vlan=1 &
-
-sleep 2;
-ip l set oi0 up;
-ip a a 192.168.99.9/24 dev oi0;
-
-regards by daniel
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/641118 b/results/classifier/deepseek-2-tmp/output/network/641118
deleted file mode 100644
index 68964cec..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/641118
+++ /dev/null
@@ -1,11 +0,0 @@
-
-NetBSD guest only supports network without ACPI
-
-Git commit: abdfd9500e07fab7d6ffd4385fa30a065c329a39
-Host: Linux 64bit Debian
-Guest: NetBSD5.0.2/i386
-
-Networking works only when ACPI is disabled in the guest. Without it the network card (wm0) is not detected.
-
-Boot: qemu -hda netbsd5.0.2-i386 -boot c -enable-kvm
-Configure: --enable-linux-aio --enable-io-thread --enable-kvm
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/643465 b/results/classifier/deepseek-2-tmp/output/network/643465
deleted file mode 100644
index 04590d7a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/643465
+++ /dev/null
@@ -1,21 +0,0 @@
-
-Crash at network boot
-
-When I boot on lan, I crash qemu:
-
-Program received signal SIGSEGV, Segmentation fault.
-[Switching to Thread 0x7ffff491a710 (LWP 10614)]
-0x00000000005a1de8 in lsi_update_irq (s=0x125d5a0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c:426
-426     /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c: No such file or directory.
-        in /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c
-(gdb) bt
-#0  0x00000000005a1de8 in lsi_update_irq (s=0x125d5a0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c:426
-#1  0x00000000005a4f67 in lsi_mmio_writew (opaque=0x125d5a0, addr=<value optimized out>, val=2) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c:1775
-#2  0x00000000004fdf3b in cpu_physical_memory_rw (addr=4043505728, buf=0x7ffff7ff2028 "\002", len=2, is_write=1) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/exec.c:3215
-#3  0x000000000042bf65 in handle_mmio (env=0xcaa6d0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:831
-#4  kvm_run (env=0xcaa6d0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:979
-#5  0x000000000042c249 in kvm_cpu_exec (env=0x125d5a0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:1651
-#6  0x000000000042c471 in kvm_main_loop_cpu (_env=<value optimized out>) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:1893
-#7  ap_main_loop (_env=<value optimized out>) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:1943
-#8  0x00007ffff79c0894 in start_thread (arg=<value optimized out>) at pthread_create.c:297
-#9  0x00007ffff5ac927d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/658904 b/results/classifier/deepseek-2-tmp/output/network/658904
deleted file mode 100644
index 05d2a501..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/658904
+++ /dev/null
@@ -1,6 +0,0 @@
-
-QEMU refers to VLAN, but doesn't mean 802.1Q
-
-Throughout the (sparse) documentation and the cmd-line help text, Qemu refers to VLAN ("virtual" LANs), which are unrelated to 802.1Q (tagged ethernet) VLAN, which, IMHO is _very_ confusing. Beyond that, it's also unnecessary, as the network in question isn't "virtual", only the devices used to implement it are.
-
-To avoid further frustration and confusion, can the term VLAN, _please_ be removed from source and documentation and replaced with something more suitable? Perhaps vNIC (seems like VMware is using that term for a similiar concept)?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/676029 b/results/classifier/deepseek-2-tmp/output/network/676029
deleted file mode 100644
index b73c5d48..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/676029
+++ /dev/null
@@ -1,19 +0,0 @@
-
-Silently fail with wrong vde socket dir
-
-Hi,
-
-Using qemu 0.12.5, kvm silently fail with exit code 1 when using -net vde and a wrong path for sock. Actually, the sock option is mean to be the socket dir of the vde_switch, not the socket itself.
-
-With -net vde,sock=/var/run/vde/vde0/ctl , strace ends with the following messages :
-
-connect(7, {sa_family=AF_FILE, path="/var/run/vde/vde0/ctl/ctl"}, 110) = -1 ENOTDIR (Not a directory)
-close(7)                                = 0
-close(8)                                = 0
-exit_group(1)                           = ?
-root ~# 
-
-Please add a meaningful message.
-
-Regards,
-Étienne
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/676934 b/results/classifier/deepseek-2-tmp/output/network/676934
deleted file mode 100644
index 8d2c8458..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/676934
+++ /dev/null
@@ -1,9 +0,0 @@
-
-Ability to use -net socket with unix sockets
-
-It would be a nice feature (simplifying access control for example) to be able to do something like:
-
-qemu -net socket,listen=unix:/tmp/qemunet
-qemu -net socket,connect=unix:/tmp/qemunet
-
-For now one has to use TCP connections even for guests running on the same host, which involves setting up iptables to restrict access.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/691 b/results/classifier/deepseek-2-tmp/output/network/691
deleted file mode 100644
index 923a3723..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/691
+++ /dev/null
@@ -1,7 +0,0 @@
-
-`-nic model=help` on qemu-system-riscv64 doesn't output supported models
-Description of problem:
-`-nic model=help` doesn't list out the supported NIC models and instead launches QEMU with warnings.
-![image](/uploads/6b0ea448ee8757a5b14081bb19dd6060/image.png)
-Steps to reproduce:
-1. run `qemu-system-riscv64 -machine virt -nic model=help`
diff --git a/results/classifier/deepseek-2-tmp/output/network/722 b/results/classifier/deepseek-2-tmp/output/network/722
deleted file mode 100644
index e24d215f..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/722
+++ /dev/null
@@ -1,13 +0,0 @@
-
-Qemu slirp connectivity lost when host enters vpn(openvpn or wireguard)
-Description of problem:
-No connectivity after host enters a vpn, tested with valid openvpn
-and wireguard.
-Steps to reproduce:
-1. Open the vpn.
-2. Open a virtual machine using slirp
-3. Ping 8.8.8.8(if you can...)
-Additional information:
-The bug is independent on the order of execution, if you start the vm
-to see it works, and run the vpn script, the connectivity in the vm
-will drop, and come back when the tunneled connection is over.
diff --git a/results/classifier/deepseek-2-tmp/output/network/741 b/results/classifier/deepseek-2-tmp/output/network/741
deleted file mode 100644
index c488cd5a..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/741
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Document "net/net.h" API
diff --git a/results/classifier/deepseek-2-tmp/output/network/761469 b/results/classifier/deepseek-2-tmp/output/network/761469
deleted file mode 100644
index 8abf063c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/761469
+++ /dev/null
@@ -1,12 +0,0 @@
-
-multicast VPN breaks IPv6 Duplicate Address Detection
-
-The multicast VPN facility in Qemu uses Multicast Loopback to make sure that other Qemu processes on the Host server receive the transmission. The side effect of this is that the process sending the packet also gets the packet back on its receive channel and currently this is not filtered but passed directly to the Virtual Machine.
-
-You can see this effect by running tcpdump in the virtual machine. Every packet sent appears to be duplicated.
-
-For IPv4 it doesn't appear to cause much of a problem, however with IPv6 the duplicate neighbor solicitation packet is precisely what the system uses to detect duplicate addresses. So IPv6 addresses fail to establish.
-
-If you run 'ip addr' on a virtual Linux machine with IPv6 enabled you will see 'dadfailed' next to the link local address. 'ping6' will then not work.
-
-Checked against 0.12.1.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/761471 b/results/classifier/deepseek-2-tmp/output/network/761471
deleted file mode 100644
index aa0e11d0..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/761471
+++ /dev/null
@@ -1,6 +0,0 @@
-
-Multicast VPN TTL hardcoded at 1
-
-The multicast VPN opens sockets with the default TTL of 1 and there doesn't appear to be an option anywhere that will allow you to increase that.
-
-This limits the usability of the VPN to the local network where the host server lives.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/774 b/results/classifier/deepseek-2-tmp/output/network/774
deleted file mode 100644
index 6461ad60..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/774
+++ /dev/null
@@ -1,16 +0,0 @@
-
-Win(PE) NIC issue with pc-q35-6.1
-Description of problem:
-When booting WinPE (via PXE via WDS) on a `pc-q35-6.1` machine, the NIC will not initialize.
-
-What I got with `pnputil.exe /enum-devices /class net` is `Device has problem: 56 0x38 (CM_PROB_NEED_CLASS_CONFIG)` See: [CM_PROB_NEED_CLASS_CONFIG](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cm-prob-need-class-config)
-
-I'm using virt manager and I've tried both `e1000e` and `virtio` network adapters (virtio with drivers injected into the image of course). Both yield the aforementioned error and `ipconfig` remains empty. This is an obscure problem - I haven't checked if a normal windows install behaves the same way, but it might be unique to winpe.
-
-However, with `pc-q35-5.2`, the NIC initializes without a problem.
-Steps to reproduce:
-1. Create `pc-q35-6.1` based vm in virt manager with default settings (network bridged to network bridge)
-2. PXE boot Windows Setup
-3. Observe hang (observe errors with console `SHIFT+F10`)
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/785668 b/results/classifier/deepseek-2-tmp/output/network/785668
deleted file mode 100644
index b9d39d21..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/785668
+++ /dev/null
@@ -1,167 +0,0 @@
-
-bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM
-
-Binary package hint: qemu-kvm
-
-Description: Ubuntu 10.4.2
-Release: 10.04
-
-
-When setting a KVM host with a bond0 interface made of eth0 and eth1 and using this bond0 interface for a bridge to KVM VMs, the ARP tables do not get updated correctly and
-
-Reproducible: 100%, with any of the load balancing mode
-
-How to reproduce the problem
-
-- Prerequisites:
-1 One KVM system with 10.04.02 server,  configured as a virtual host is needed. The following /etc/network/interfaces was used for the test :
-
-# grep  -v ^# /etc/network/interfaces
-auto lo
-iface lo inet loopback
-
-
-auto bond0
-iface bond0 inet manual
-	post-up ifconfig $IFACE up
-	pre-down ifconfig $IFACE down
-	bond-slaves none
-	bond_mode balance-rr
-	bond-downdelay 250
-	bond-updelay 120
-auto eth0
-allow-bond0 eth0
-iface eth0 inet manual
-	bond-master bond0
-auto eth1
-allow-bond0 eth1
-iface eth1 inet manual
-	bond-master bond0
-
-auto br0
-iface br0 inet dhcp
-	# dns-* options are implemented by the resolvconf package, if installed
-	bridge-ports bond0
-	bridge-stp off
-	bridge-fd 9
-	bridge-hello 2
-	bridge-maxage 12
-	bridge_max_wait 0
-
-One VM running Maverick 10.10 server, standard installation, using the following /etc/network/interfaces file :
-
-grep -v ^# /etc/network/interfaces
-
-auto lo
-iface lo inet loopback
-
-auto eth0
-iface eth0 inet static
-        address 10.153.107.92
-        netmask 255.255.255.0
-        network 10.153.107.0
-        broadcast 10.153.107.255
-
---------------
-On a remote bridged network system :
-$ arp -an
-? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0
-? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0
-? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0
-
-On KVMhost
-$ arp -an
-? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0
-
-On VM
-$ arp -an
-? (10.153.107.61) at <incomplete> on eth0
-
-1) Test #1 : ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) :
-
-- On remote bridged network system :
-caribou@marvin:~$ arp -an
-? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0
-? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0
-? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0
-
-- On KVMhost
-ubuntu@VMhost:~$ arp -an
-? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0
-
-- On VM
-ubuntu@vm1:~$ ping 10.153.107.80
-PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data.
-From 10.153.107.92 icmp_seq=1 Destination Host Unreachable
-From 10.153.107.92 icmp_seq=2 Destination Host Unreachable
-From 10.153.107.92 icmp_seq=3 Destination Host Unreachable
-^C
---- 10.153.107.80 ping statistics ---
-4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3010ms
-pipe 3
-ubuntu@vm1:~$ arp -an
-? (10.153.107.61) at <incomplete> on eth0
-? (10.153.107.80) at <incomplete> on eth0
-
-2) Test #2 : ping from remote bridged network system (10.153.107.80) to VM (10.153.107.92) :
-
-- On remote bridged network system :
-$ ping 10.153.107.92
-PING 10.153.107.92 (10.153.107.92) 56(84) bytes of data.
-64 bytes from 10.153.107.92: icmp_req=1 ttl=64 time=327 ms
-64 bytes from 10.153.107.92: icmp_req=2 ttl=64 time=158 ms
-64 bytes from 10.153.107.92: icmp_req=3 ttl=64 time=157 ms
-^C
---- 10.153.107.92 ping statistics ---
-3 packets transmitted, 3 received, 0% packet loss, time 2003ms
-rtt min/avg/max/mdev = 157.289/214.500/327.396/79.831 ms
-caribou@marvin:~$ arp -an
-? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0
-? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0
-? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0
-? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0
-
-- On KVMhost
-$ arp -an
-? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0
-
-- On VM
-arp -an
-? (10.153.107.61) at <incomplete> on eth0
-? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on eth0
-
-
-3) Test #3 : New ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) :
-- On remote bridged network system :
-$ arp -an
-? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0
-? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0
-? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0
-? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0
-
-- On KVMhost
-ubuntu@VMhost:~$ arp -an
-? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0
-
-- On VM
-ubuntu@vm1:~$ ping 10.153.107.80
-PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data.
-64 bytes from 10.153.107.80: icmp_req=1 ttl=64 time=154 ms
-64 bytes from 10.153.107.80: icmp_req=2 ttl=64 time=170 ms
-64 bytes from 10.153.107.80: icmp_req=3 ttl=64 time=154 ms
-^C
---- 10.153.107.80 ping statistics ---
-3 packets transmitted, 3 received, 0% packet loss, time 2003ms
-rtt min/avg/max/mdev = 154.072/159.465/170.058/7.504 ms
-
-tcpdump traces are available for those tests. Test system is available upon request.
-
-Workaround:
-
-Use the bonded device in "active-backup" mode
-
-ProblemType: Bug
-DistroRelease: Ubuntu 10.04.02
-Package: qemu-kvm-0.12.3+noroms-0ubuntu9.6
-Uname: Linux 2.6.35-25-serverr x86_64
-Architecture: amd64
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/808588 b/results/classifier/deepseek-2-tmp/output/network/808588
deleted file mode 100644
index dfdfe47c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/808588
+++ /dev/null
@@ -1,50 +0,0 @@
-
-Netperf tests cause i82551 network down
-
-1. boot up a guest with 82551 nic
-# qemu-kvm -net nic,model=i82551 ...
-2. launch netperf server in the guest
-3.on the host 
-for b in 32 64 128 256 512 1024 1460 2048 4096 8192  9000 16384 32768  65495 65507
-do ./netperf -t TCP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b
-done
-
-for b in 32 64 128 256 512 1024 1460 2048 4096 8192  9000 16384 32768  65495 65507
-do ./netperf -t UDP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b
-done
-
-
-Result:
-Guest network becomes down
-
-
-netperf client output:
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 32
- 87380  16384     32    10.97      19.61
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 64
- 87380  16384     64    11.55      79.68
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 128
- 87380  16384    128    10.16      14.20
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 256
- 87380  16384    256    11.17      12.85
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 512
- 87380  16384    512    10.01      16.38
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1024
-Interrupted system call
-netperf: remote error 4./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1460
-establish control: are you sure there is a netserver listening on 10.66.9.39 at port 12865?
-establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 10.66.9.39 port 12865 address family AF_UNSPEC
-./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 2048
-
-
-qemu debug message:
-....
-EE100   nic_receive             command 0x0000, link 0x3d3e6822, addr 0xffffffff, size 1518
-EE100   nic_can_receive         0x29a0180
-EE100   nic_receive             0x29a0180 received broadcast, len=60
-EE100   nic_receive             Receive buffer (0 bytes) too small for data (60 bytes); data truncated
-EE100   nic_receive             command 0x8000, link 0x37b32022, addr 0xffffffff, size 0
-                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-EE100   nic_receive             receive: Running out of frames
-                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
-EE100   eepro100_write1         addr=Command/Status+1 val=0x20
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/829455 b/results/classifier/deepseek-2-tmp/output/network/829455
deleted file mode 100644
index 6fd58126..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/829455
+++ /dev/null
@@ -1,17 +0,0 @@
-
-user mode network stack - hostfwd not working with restrict=y
-
-I find that explicit hostfwd commands do not seem to work with restrict=yes option, even if the docs clearly state that hostfwd should override restrict setting.
-
-I am using this config:
-
--net user,name=test,net=192.168.100.0/24,host=192.168.100.44,restrict=y,hostfwd=tcp:127.0.0.1:3389-192.168.100.1:3389
-
-(my guest has static IP address configured as 192.168.100.1/24)
-
-and I cannot log into my guest via rdp. the client hanging indefinitely.
-by just changing to "restrict=no" I can log in.
-
-maybe I am doing something wrong, but I cannot figure out what.
-
-running QEMU emulator version 0.14.0 (qemu-kvm-0.14.0)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/833 b/results/classifier/deepseek-2-tmp/output/network/833
deleted file mode 100644
index 6d0fcb93..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/833
+++ /dev/null
@@ -1,43 +0,0 @@
-
-linux-user: sendmsg fails to send messages without iov
-Description of problem:
-When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux.
-
-A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526
-
-A message without data but only ancillary data is used to set the IV.
-Steps to reproduce:
-See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`).
-
-(Test case is to be considered GPL, as I've copied bits from `ell`)
-
-Native:
-```
-$ strace -esendmsg ./a.out 
-sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0
-sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
-+++ exited with 0 +++
-```
-
-
-Qemu (observe missing sendmsg call):
-```
-$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out 
-sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
-+++ exited with 0 +++
-```
-
-For a practical reproducer:
-
-1. Compile and run `ell`'s `test-cipher` test case:
-
-```
-$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher 
-TEST: unsupported
-TEST: aes
-TEST: aes_ctr
-test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed.
-Aborted (core dumped)
-```
-
-A strace will look similar.
diff --git a/results/classifier/deepseek-2-tmp/output/network/838974 b/results/classifier/deepseek-2-tmp/output/network/838974
deleted file mode 100644
index eeeaa769..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/838974
+++ /dev/null
@@ -1,4 +0,0 @@
-
-Confusing error report for missing vde support
-
-The error that appears in qemu 0.15 is "parameter 'type' expects a network client type" when trying to use vde for networking as if the parameter is wrong, but the problem is that the executable was compiled without vde support.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/845 b/results/classifier/deepseek-2-tmp/output/network/845
deleted file mode 100644
index a4df35c4..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/845
+++ /dev/null
@@ -1,60 +0,0 @@
-
-Heap-use-after-free in remote_object_finalize
-Description of problem:
-While I was working with `QIOChannel` in my downstream QEMU fork, I looked at `hw/remote/remote-obj.c` as a usage example.
-
-I did the same thing to `remote_object_finalize` function in order to free the QIOChannel when the connection closed:
-
-```c
-    if (o->ioc) {
-        qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
-        qio_channel_close(o->ioc, NULL);
-    }
-
-    object_unref(OBJECT(o->ioc));
-```
-
-After the connection is closed for a while, my program SIGSEGV:
-
-```
-Thread 2 Crashed:
-0   qemu-system-aarch64           	0x000000010164513c qemu_coroutine_get_aio_context + 12 (qemu-coroutine.c:203)
-1   qemu-system-aarch64           	0x000000010145ad82 qio_channel_restart_read + 50
-2   qemu-system-aarch64           	0x0000000101614c8a aio_dispatch_handler + 378 (aio-posix.c:332)
-3   qemu-system-aarch64           	0x0000000101613fad aio_dispatch_handlers + 125 (aio-posix.c:372)
-4   qemu-system-aarch64           	0x0000000101613ef3 aio_dispatch + 51 (aio-posix.c:383)
-5   qemu-system-aarch64           	0x0000000101631e18 aio_ctx_dispatch + 104 (async.c:307)
-6   libglib-2.0.0.dylib           	0x000000010284b90c g_main_context_dispatch + 364
-7   qemu-system-aarch64           	0x0000000101644728 glib_pollfds_poll + 88 (main-loop.c:233)
-8   qemu-system-aarch64           	0x0000000101644170 os_host_main_loop_wait + 128 (main-loop.c:256)
-9   qemu-system-aarch64           	0x000000010164403c main_loop_wait + 188 (main-loop.c:530)
-10  qemu-system-aarch64           	0x00000001012f3014 qemu_main_loop + 36 (runstate.c:721)
-11  qemu-system-aarch64           	0x0000000100c25e38 qemu_main + 40 (main.c:51)
-12  qemu-system-aarch64           	0x0000000100c7b1f4 call_qemu_main + 52 (cocoa.m:1746)
-13  qemu-system-aarch64           	0x000000010161a459 qemu_thread_start + 185 (qemu-thread-posix.c:521)
-14  libsystem_pthread.dylib       	0x00007fff6a6e2109 _pthread_start + 148
-15  libsystem_pthread.dylib       	0x00007fff6a6ddb8b thread_start + 15
-```
-
-So apparently, there is a dangling pointer of the QIOChannel in AIOContext.
-
-And indeed, that caused by the fact that when the fd read/write is blocked, it sets the fd handlers to the AIO context before yielding the coroutine (https://gitlab.com/qemu-project/qemu/-/blob/master/io/channel.c#L544).
-
-So after the fd is closed, the AIO still dispatches the fd readable event when the main loop dispatches again, using the dangling QIOChannel pointer (When the fd is reused I think).
-
-I suggest adding a `qio_channel_detach_aio_context()` call before the channel is shutdown in `remote-obj.c`, or before the fd is closed in `qio_channel_close()` in `io/channel.c`
-
-```c
-
-    if (o->ioc) {
-        qio_channel_detach_aio_context(o->ioc);
-        qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
-        qio_channel_close(o->ioc, NULL);
-    }
-
-    object_unref(OBJECT(o->ioc));
-```
-
-This bug might have slipped through the cracks because `mpqemu_remote_msg_loop_co` issues a shutdown request immediately after an I/O error occured on the QIOChannel.
-Additional information:
-
diff --git a/results/classifier/deepseek-2-tmp/output/network/888016 b/results/classifier/deepseek-2-tmp/output/network/888016
deleted file mode 100644
index f65e03be..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/888016
+++ /dev/null
@@ -1,19 +0,0 @@
-
-RHEL 6.1 guest fails to boot with vhost 
-
-Tried to boot 6.1 guest on hs22 blade with/without  vhost enabled. 
-
-With vhost enabled,  guest aborted with core dump. 
-
-installed guest with autotest.    
-Command : 
-/usr/local/bin/qemu-system-x86_64 -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-20111108-193209-fc6O',server,nowait -serial unix:'/tmp/serial-20111108-193209-fc6O',server,nowait -drive file='/home/pradeep/autotest/client/tests/kvm/images/rhel6.1-64.qed',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=idQhUaOc,mac='9a:b7:ea:c9:0e:0d',id='idVR6XQz' -netdev tap,id=idQhUaOc,vhost=on,script=/home/pradeep/qemu-ifup-latest -m 1024 -smp 8 -vnc :0 -monitor stdio
-QEMU 0.15.91 monitor - type 'help' for more information
-(qemu) Aborted (core dumped)
-
-
-host:
-
-2.6.32-214
-m/c: hs22
-vhost modules are loaded.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/899140 b/results/classifier/deepseek-2-tmp/output/network/899140
deleted file mode 100644
index 685a5f4b..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/899140
+++ /dev/null
@@ -1,25 +0,0 @@
-
-Problem with Linux Kernel Traffic Control
-
-Hi,
-
-The two last main versions of QEMU (0.15 and 1.0) have an important problem when running on a Linux distribution which running itself a Traffic Control (TC) instance.
-Indeed, when TC is configured with a Token Bucket Filter (TBF) with a particular rate, the effective rate is very slower than the desired one.
-
-For instance, lets consider the following configuration :
-
-# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms
-
-The effective rate will be about 100kbit/s ! (verified with iperf)
-I've encountered this problem on versions 0.15 and 1.0 but not with the 0.14...
-In the 0.14, we have a rate of 19.2 mbit/s which is quiet normal.
-
-I've done the experimentation on several hosts :
- 
-- Debian 32bit core i7, 4GB RAM
-- Debian 64bit core i7, 8GB RAM
-- 3 different high performance servers : Ubuntu 64 bits, 48 AMD Opteron, 128GB of RAM
-
-The problem is always the same... The problem is also seen with a Class Based Queuing (CBQ) in TC.
-
-Thanks
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/903365 b/results/classifier/deepseek-2-tmp/output/network/903365
deleted file mode 100644
index 444bc8b3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/903365
+++ /dev/null
@@ -1,4 +0,0 @@
-
-[feature request] bind nat (-net user) to other interface (like eth0:2)
-
--net user mode is very nice because it does not require any changes in host system. However if host system has muplitple IPs You cant use it, or even switch to another. Qemu should be able to "bind" to eth0:1 eth0:2 so that outgoing traffic uses this interface and thus other IP.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/907 b/results/classifier/deepseek-2-tmp/output/network/907
deleted file mode 100644
index 04b872e3..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/907
+++ /dev/null
@@ -1,8 +0,0 @@
-
-qemu-system-x86_64 -blockdev fails with "CURL: Error opening file" when supplied url of ISO file
-Steps to reproduce:
-1. Run: qemu-system-x86_64 -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true
-
-The command returns error: qemu-system-x86_64: -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true,discard=unmap: CURL: Error opening file:
-Additional information:
-This bug is not present in qemu 6.1.0, it surfaced with an update to 6.2.0
diff --git a/results/classifier/deepseek-2-tmp/output/network/912 b/results/classifier/deepseek-2-tmp/output/network/912
deleted file mode 100644
index ecbac7eb..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/912
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Cannot access RHEL8_s390x installed OS using SSH from host OS network
diff --git a/results/classifier/deepseek-2-tmp/output/network/916720 b/results/classifier/deepseek-2-tmp/output/network/916720
deleted file mode 100644
index 60e579e2..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/916720
+++ /dev/null
@@ -1,11 +0,0 @@
-
-select fails on windows because a non-socket fd is in the rfds set
-
-The select call in file main_loop.c at line 460 fails on windows because a non-socket fd is in the rfds set. As a result, gdb remote connections will never be accepted by qemu. The select function returns with -1. WSAGetLastError returns code 10038 (WSAENOTSOCK).
-
-I start qemu as follows:
-qemu-system-arm -cpu cortex-m3 -M lm3s6965evb -nographic -monitor null -serial null -semihosting -kernel test1.elf -S -gdb tcp:127.0.0.1:2200
-
-qemu is configure with:
-CFLAGS="-O4 -march=i686"
-configure --target-list="i386-softmmu arm-softmmu sparc-softmmu ppc-softmmu" --prefix=/home/qemu/install --cc=mingw32-gcc --host-cc=mingw32-gcc --audio-drv-list="dsound sdl" --audio-card-list="ac97 es1370 sb16 cs4231a adlib gus"
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/935 b/results/classifier/deepseek-2-tmp/output/network/935
deleted file mode 100644
index 460b4072..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/935
+++ /dev/null
@@ -1,60 +0,0 @@
-
-insert ivshmem device into pci-bridge, but vm network disconnects
-Description of problem:
-To extend PCI slot number in Windows vm, a new pci-bridge is created in Windows vm as bus.1. But when I insert a ivshmem file in host to this pci-bridge(bus.1), the Windows vm disconnects(lose remote desktop connection).
-Steps to reproduce:
-1. add new pci-bridge into windows vm, add windows vm xml configuration like this:
-```xml
-<devices>
-  <controller type='pci' index='0' model='pci-root'/>
-  <controller type='pci' index='1' model='pci-bridge'>
-    <address type='pci' domain='0' bus='0' slot='0x0d' function='0' multifunction='off'/>
-  </controller>
-</devices>
-```
-
-2.restart this Windows vm, new pci-bridge has been created, its name is pci.1 and bus is bus.1:
-```sh
-$ virsh qemu-monitor-command --hmp --domain 56 --cmd info pci
-  Bus  0, device  13, function 0:
-    PCI bridge: PCI device 1b36:0001
-      IRQ 10.
-      BUS 0.
-      secondary bus 1.
-      subordinate bus 1.
-      IO range [0xc000, 0xcfff]
-      memory range [0xfe000000, 0xfe1fffff]
-      prefetchable memory range [0xe4000000, 0xe41fffff]
-      BAR0: 64 bit memory at 0xfe422000 [0xfe4220ff].
-      id "pci.1"
-```
-3. create a shm file `/dev/shm/test1` in host using `shm_open()`, size is 32M
-
-4. create new object: 
-```sh
-virsh qemu-monitor-command --hmp --domain 56 --cmd object_add memory-backend-file,share=on,id=objtest1,size=32M,mem-path=/dev/shm/test1
-```
-
-5. insert this ivshmem file into new pci-bridge and use bus.1 slot number(1:1.0):
-```sh
-virsh qemu-monitor-command --hmp --domain 56 --cmd device_add ivshmem-plain,memdev=objtest1,id=test1,bus=pci.1,addr=0x01.0x00
-```
-
-6. After inserting this ivshmem file into new pci-bridge, the remote desktop connection of this windows vm disconnects.
-
-7. New ivshmem file has been created:
-```
-$ virsh qemu-monitor-command --hmp --domain 57 --cmd info pci
-  Bus  1, device   1, function 0:
-    RAM controller: PCI device 1af4:1110
-      BAR0: 32 bit memory at 0xfe1fff00 [0xfe1fffff].
-      BAR2: 64 bit prefetchable memory at 0x4bc000000 [0x4bfffffff].
-      id "test1"
-
-```
-Additional information:
-When insert ivshmem file into bus.1(pci-bridge), the remote desktop connection of Windows vm is sometimes disconnected, and sometimes it is normal.
-
-The newly added ivshmem device can be found in the device manager of the Windows vm, but sometimes it cannot be found.
-
-Thanks for your help!
diff --git a/results/classifier/deepseek-2-tmp/output/network/935945 b/results/classifier/deepseek-2-tmp/output/network/935945
deleted file mode 100644
index e1a5da33..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/935945
+++ /dev/null
@@ -1,153 +0,0 @@
-
-SLIRP still not working for win32
-
-SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP.
-
-Here is an example slirp debug log:
-
-arp_table_add...
-ip = 0x502000a
-hw addr = 52:54:00:12:34:56
-arp_table_add...
-ip = 0x502000a
-hw addr = 52:54:00:12:34:56
-m_get...
-m = 5bd4f0b8
-ip_input...
-m = 5bd4f0b8
-m_len = 84
-icmp_input...
-m = 5bd4f0b8
-m_len = 84
-icmp_type = 8
-ip_output...
-so = 0
-m0 = 5bd4f0b8
-if_output...
-so = 0
-ifm = 5bd4f0b8
-if_start...
-arp_table_search...
-ip = 0x502000a
-found hw addr = 52:54:00:12:34:56
-m_free...
-m = 5bd4f0b8
-m_get...
-m = 5bd4f0b8
-ip_input...
-m = 5bd4f0b8
-m_len = 84
-icmp_input...
-m = 5bd4f0b8
-m_len = 84
-icmp_type = 8
-ip_output...
-so = 0
-m0 = 5bd4f0b8
-if_output...
-so = 0
-ifm = 5bd4f0b8
-if_start...
-arp_table_search...
-ip = 0x502000a
-found hw addr = 52:54:00:12:34:56
-m_free...
-m = 5bd4f0b8
-arp_table_add...
-ip = 0x502000a
-hw addr = 52:54:00:12:34:56
-m_get...
-m = 5bd4f0b8
-ip_input...
-m = 5bd4f0b8
-m_len = 55
-udp_input...
-m = 5bd4f0b8
-iphlen = 20
-sosendto...
-so = 5bd104a0
-m = 5bd4f0b8
-sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8
-m_free...
-m = 0
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-m_get...
-m = 5bd4f728
-ip_input...
-m = 5bd4f728
-m_len = 55
-udp_input...
-m = 5bd4f728
-iphlen = 20
-sosendto...
-so = 5bd104a0
-m = 5bd4f728
-sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8
-m_free...
-m = 5bd4f0b8
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-m_get...
-m = 5bd4f0b8
-ip_input...
-m = 5bd4f0b8
-m_len = 55
-udp_input...
-m = 5bd4f0b8
-iphlen = 20
-sosendto...
-so = 5bd104a0
-m = 5bd4f0b8
-sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8
-m_free...
-m = 5bd4f728
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-ip_slowtimo...
-tcp_slowtimo...
-[repeated]
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/938945 b/results/classifier/deepseek-2-tmp/output/network/938945
deleted file mode 100644
index f152b713..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/938945
+++ /dev/null
@@ -1,24 +0,0 @@
-
-Slirp cannot be forward and makes segmentation faults
-
-Hi,
-
-Let's consider the following lines:
-
-$ qemu -enable-kvm -name opeth -hda debian1.img -k fr -localtime -m 512 -net user,vlan=0 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:10 -net socket,vlan=1,listen=127.0.0.1:5900 -net nic,vlan=1,model=$model,macaddr=a2:00:00:00:00:04
-
-$qemu -enable-kvm -name nightwish -hda debian2.img -k fr -localtime -m 512 -net socket,vlan=0,connect=127.0.0.1:5900 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:02
-
-
-My configuration is clear and allows to transmit packets between the Slirp and the guest nightwish.
-But when I try to do on nightwish :
-
-$ wget www.qemu.org
-
-The opeth QEMU makes a segfault :    "11586 Segmentation Fault"
-
-This phenomenon is not always present... If the Segfault does not appear, nightwish cannot enable a connection with internet :(
-
-
-Thanks
-Vince
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/954099 b/results/classifier/deepseek-2-tmp/output/network/954099
deleted file mode 100644
index e8ba5bd0..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/954099
+++ /dev/null
@@ -1,15 +0,0 @@
-
-Assertion failed arp_table.c line 41 on raspberry pi fedora image boot up
-
-OS Win XP pro, 32 bit SP3
-Intel Core Duo, 4G RAM.
-
-Qemu 1.0.1
-
-Launch command:
-qemu-system-arm.exe -M versatilepb -cpu arm1136-r2 -hda raspberrypi-fedora-remix-14-r1.img -kernel zImage-devtmpfs -m 192 -append "root=/dev/sda2" -vga std -net nic -net user -localtime
-
-Starting HAL daemon: eth0: link up
-Assert fires :
-File : slirp\arp_table.c line 41
-Expression (ip_addr & htonl(~0xf << 28))) 1=0
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/976 b/results/classifier/deepseek-2-tmp/output/network/976
deleted file mode 100644
index dc4ef6ca..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/976
+++ /dev/null
@@ -1,2 +0,0 @@
-
-Qemu - Bridge direct network connection not working
diff --git a/results/classifier/deepseek-2-tmp/output/network/984476 b/results/classifier/deepseek-2-tmp/output/network/984476
deleted file mode 100644
index 474242f5..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/984476
+++ /dev/null
@@ -1,6 +0,0 @@
-
-"segmentaion" error when DMAing
-
-When working with QEMU's PCI network card E1000 emulator, I accidentally put virtual addresses into the memory mapped registers when I should have put physical addresses. Short story is, the address was too large for the physical address space so when the network card tried to DMA the location it tossed a "segmentaion" error out to the console. That's right--not a "segmentation" error, but a "segmentaion" error. I just thought I'd let ya'll know about that little typo. 
-
-My "qemu -version" gives "QEMU emulator version 0.15.0, Copyright (c) 2003-2008 Fabrice Bellard" on linux version 2.6.32. I guess it might be an older version, dunno if the typo's still there.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/985 b/results/classifier/deepseek-2-tmp/output/network/985
deleted file mode 100644
index 560c69e0..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/985
+++ /dev/null
@@ -1,60 +0,0 @@
-
-pkg_add is working very slow on NetBSD
-Description of problem:
-pkg_add is working very slow, it installs one package in ~30 minutes although network speed is normal.
-Steps to reproduce:
-1. `wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/images/NetBSD-9.2-amd64.iso`
-2. `qemu-img create -f qcow2 disk.qcow2 15G`
-3. Install
-```
-qemu-system-x86_64 -m 2048 -enable-kvm \
-  -drive if=virtio,file=disk.qcow2,format=qcow2 \
-  -netdev user,id=mynet0,hostfwd=tcp::7722-:22 \
-  -device e1000,netdev=mynet0 \
-  -cdrom NetBSD-9.2-amd64.iso
-```
-       # Installation steps
-       - 1) Boot Normally
-       - a) Installation messages in English
-       - a) unchanged
-       - a) Install NetBSD to hard disk
-       - b) Yes
-       - a) 15G
-       - a) GPT
-       - a) This is the correct geometry
-       - b) Use default partition sizes
-       - x) Partition sizes are ok
-       - b) Yes
-       - a) Use BIOS console
-       - b) Installation without X11
-       - a) CD-ROM / DVD / install image media
-       - Hit enter to continue
-       - a) configure network (Select defaults here, perform autoconf)
-       - x) Finished configuring
-       - Hit enter to continue
-       - x) Exit Install System
-       - Close QEMU
-4. Run
-```
- qemu-system-x86_64 -m 2048 \
-  -drive if=virtio,file=disk.qcow2,format=qcow2 \
-  -enable-kvm  \
-  -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:7722-:22 \
-  -device e1000,netdev=mynet0
-```
-5. Login as root
-6. In NetBSD
-```
-export PKG_PATH="http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r)/All/" && \
-pkg_add pkgin
-
-```
-You should see that each of the package's installation takes ~30 minutes.
-Additional information:
-NetBSD 9.2 is also tested in Debian 11 with 'QEMU 6.2.0' and encountered same slowness. 
-
-NetBSD 7.1 and 8.1 are tested on openSUSE Tumbleweed and encountered same slowness.
-
-OpenBSD's pkg_add is working correctly.
-
-I am not sure if it will help but Virtualbox(at least 6.1) is working correctly.
diff --git a/results/classifier/deepseek-2-tmp/output/network/988128 b/results/classifier/deepseek-2-tmp/output/network/988128
deleted file mode 100644
index 983229f6..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/988128
+++ /dev/null
@@ -1,29 +0,0 @@
-
-smbd crashes when called with "smb ports = 0"
-
-The smb.conf generated by qemu-kvm contains a "smb ports = 0" directive. This
-causes at least version 3.6.4 of Samba to crash with
-
-[0] vostro:/tmp/qemu-smb.6836-0# smbd -i -s smb.conf
-Unable to setup corepath for smbd: Operation not permitted
-smbd version 3.6.4 started.
-Copyright Andrew Tridgell and the Samba Team 1992-2011
-open_sockets_smbd: No sockets available to bind to.
-===============================================================
-Abnormal server exit: open_sockets_smbd() failed
-===============================================================
-BACKTRACE: 6 stack frames:
- #0 smbd(log_stack_trace+0x1a) [0x7fe50c14f8ba]
- #1 smbd(+0x6a0743) [0x7fe50c3bd743]
- #2 smbd(+0x6a0a41) [0x7fe50c3bda41]
- #3 smbd(main+0xa52) [0x7fe50be26d42]
- #4 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fe508ac0ead]
- #5 smbd(+0x10a6b9) [0x7fe50be276b9]
-
-Changing "smb ports" to a non-privilileged port works around the issue.
-
-I'd like to help fix this, but I am not sure what qemu-kvm's intention is here.
-Zero is not a valid port, and the smb.conf manpage does not describe any
-special meaning of zero here. I found that previous versions of samba apparently
-did not bind to any port if zero was specified - but in that case, how is
-qemu communicating with samba?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/988909 b/results/classifier/deepseek-2-tmp/output/network/988909
deleted file mode 100644
index d6731d28..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/988909
+++ /dev/null
@@ -1,17 +0,0 @@
-
-Assert failed in arp_table.c
-
-
-With latest git (8001954) hen running:
-
-qemu-system-64 -hda $VDISK -kernel arch/x86/boot/bzImage \
-        -append "ro root=/dev/hda1 console=ttyS0 init=/bin/systemd" \
-        -curses \
-        -net nic  -smp 3 -m 312 $@
-
-I'm getting this:
-
- qemu-system-x86_64: slirp/arp_table.c:75: arp_table_search: Assertion `(ip_addr & (__extension__ ({ register unsigned int __v, __x = (~(0xf << 28)); if (__builtin_constant_p (__x)) __v = ((((__x) & 0xff000000) >> 24) | (((__x) & 0x00ff0000) >> 8) | (((__x) & 0x0000ff00) << 8) | (((__x) & 0x000000ff) << 24)); else __asm__ ("bswap %0" : "=r" (__v) : "0" (__x)); __v; }))) != 0' failed. 
-
-Bug #824650 seems to be related to this one, but it is not. Fix for that one is already upstream. 
-I can help on testing.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/network/999 b/results/classifier/deepseek-2-tmp/output/network/999
deleted file mode 100644
index 7bd9e72c..00000000
--- a/results/classifier/deepseek-2-tmp/output/network/999
+++ /dev/null
@@ -1,7 +0,0 @@
-
-Update ipv4 function calls
-Description of problem:
-Qemu still uses obsolete ipv4 functions, it would be fine to convert them to their ipv6 counterparts:
-* gethostbyname
-* inet_aton
-* inet_ntoa