From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/zero-shot/108/device/102      |   16 +
 results/classifier/zero-shot/108/device/1024     |   25 +
 results/classifier/zero-shot/108/device/1033     |   42 +
 results/classifier/zero-shot/108/device/1034980  |   37 +
 results/classifier/zero-shot/108/device/1047999  |  135 +++
 results/classifier/zero-shot/108/device/1050823  |   37 +
 results/classifier/zero-shot/108/device/1077     |   16 +
 results/classifier/zero-shot/108/device/112      |   16 +
 results/classifier/zero-shot/108/device/1132     |  130 +++
 results/classifier/zero-shot/108/device/1134     |   18 +
 results/classifier/zero-shot/108/device/1140     |   16 +
 results/classifier/zero-shot/108/device/116      |   16 +
 results/classifier/zero-shot/108/device/118      |   16 +
 results/classifier/zero-shot/108/device/119      |   16 +
 results/classifier/zero-shot/108/device/1191     |   24 +
 results/classifier/zero-shot/108/device/1198350  |   67 ++
 results/classifier/zero-shot/108/device/1208     |   24 +
 results/classifier/zero-shot/108/device/1221     |   44 +
 results/classifier/zero-shot/108/device/1225     |   16 +
 results/classifier/zero-shot/108/device/1237     |   16 +
 results/classifier/zero-shot/108/device/1248469  |   23 +
 results/classifier/zero-shot/108/device/1282     |   18 +
 results/classifier/zero-shot/108/device/1284     |   29 +
 results/classifier/zero-shot/108/device/1300     |   26 +
 results/classifier/zero-shot/108/device/1305     |   29 +
 results/classifier/zero-shot/108/device/1318     |   34 +
 results/classifier/zero-shot/108/device/132      |   16 +
 results/classifier/zero-shot/108/device/1332234  |   72 ++
 results/classifier/zero-shot/108/device/1342     |   39 +
 results/classifier/zero-shot/108/device/1346     |   50 +
 results/classifier/zero-shot/108/device/1354     |   16 +
 results/classifier/zero-shot/108/device/1363     |   18 +
 results/classifier/zero-shot/108/device/1391     |   43 +
 results/classifier/zero-shot/108/device/1406     |   16 +
 results/classifier/zero-shot/108/device/1413     |   37 +
 results/classifier/zero-shot/108/device/1445633  |   34 +
 results/classifier/zero-shot/108/device/1478     |   81 ++
 results/classifier/zero-shot/108/device/149      |   16 +
 results/classifier/zero-shot/108/device/1507     |   52 +
 results/classifier/zero-shot/108/device/1515     |   33 +
 results/classifier/zero-shot/108/device/1519     |   27 +
 results/classifier/zero-shot/108/device/1564     |   85 ++
 results/classifier/zero-shot/108/device/157      |   16 +
 results/classifier/zero-shot/108/device/1574     |  104 ++
 results/classifier/zero-shot/108/device/1581308  |   40 +
 results/classifier/zero-shot/108/device/1581976  |   37 +
 results/classifier/zero-shot/108/device/1586613  |   29 +
 results/classifier/zero-shot/108/device/1629618  |  126 ++
 results/classifier/zero-shot/108/device/1634852  |   64 ++
 results/classifier/zero-shot/108/device/1637974  |   99 ++
 results/classifier/zero-shot/108/device/1660035  |   53 +
 results/classifier/zero-shot/108/device/1661     |   26 +
 results/classifier/zero-shot/108/device/1663     |   49 +
 results/classifier/zero-shot/108/device/1672     |   23 +
 results/classifier/zero-shot/108/device/1675549  |   34 +
 results/classifier/zero-shot/108/device/168      |   16 +
 results/classifier/zero-shot/108/device/1696773  | 1337 ++++++++++++++++++++++
 results/classifier/zero-shot/108/device/1699628  |   37 +
 results/classifier/zero-shot/108/device/1712027  |   68 ++
 results/classifier/zero-shot/108/device/1724     |   60 +
 results/classifier/zero-shot/108/device/1731347  |   58 +
 results/classifier/zero-shot/108/device/1732981  |   35 +
 results/classifier/zero-shot/108/device/1733720  |   92 ++
 results/classifier/zero-shot/108/device/1737194  |  644 +++++++++++
 results/classifier/zero-shot/108/device/174      |   16 +
 results/classifier/zero-shot/108/device/1744654  |   22 +
 results/classifier/zero-shot/108/device/1745895  |   50 +
 results/classifier/zero-shot/108/device/1748     |   71 ++
 results/classifier/zero-shot/108/device/1759     |   25 +
 results/classifier/zero-shot/108/device/1760176  |   88 ++
 results/classifier/zero-shot/108/device/1761     |   16 +
 results/classifier/zero-shot/108/device/1767     |   18 +
 results/classifier/zero-shot/108/device/1769     |   16 +
 results/classifier/zero-shot/108/device/1773     |   24 +
 results/classifier/zero-shot/108/device/1794     |   42 +
 results/classifier/zero-shot/108/device/1815445  |   35 +
 results/classifier/zero-shot/108/device/182      |   16 +
 results/classifier/zero-shot/108/device/1824853  |   95 ++
 results/classifier/zero-shot/108/device/1835839  |  284 +++++
 results/classifier/zero-shot/108/device/184      |   16 +
 results/classifier/zero-shot/108/device/1847     |   16 +
 results/classifier/zero-shot/108/device/1854     |   33 +
 results/classifier/zero-shot/108/device/1854878  |   63 +
 results/classifier/zero-shot/108/device/1859     |   23 +
 results/classifier/zero-shot/108/device/1864     |   36 +
 results/classifier/zero-shot/108/device/1866     |   16 +
 results/classifier/zero-shot/108/device/1866792  |   93 ++
 results/classifier/zero-shot/108/device/187      |   16 +
 results/classifier/zero-shot/108/device/1875080  |   39 +
 results/classifier/zero-shot/108/device/1877716  |  147 +++
 results/classifier/zero-shot/108/device/1880     |   28 +
 results/classifier/zero-shot/108/device/1882787  |   82 ++
 results/classifier/zero-shot/108/device/1882851  |  507 ++++++++
 results/classifier/zero-shot/108/device/1888     |   27 +
 results/classifier/zero-shot/108/device/1890160  |  120 ++
 results/classifier/zero-shot/108/device/1902306  |   58 +
 results/classifier/zero-shot/108/device/1909418  |  440 +++++++
 results/classifier/zero-shot/108/device/1911797  |   42 +
 results/classifier/zero-shot/108/device/1922102  |   97 ++
 results/classifier/zero-shot/108/device/193      |   16 +
 results/classifier/zero-shot/108/device/1945540  |  190 +++
 results/classifier/zero-shot/108/device/2021     |   16 +
 results/classifier/zero-shot/108/device/2033     |   16 +
 results/classifier/zero-shot/108/device/204      |   16 +
 results/classifier/zero-shot/108/device/2044     |   20 +
 results/classifier/zero-shot/108/device/2049     |   26 +
 results/classifier/zero-shot/108/device/2122     |   22 +
 results/classifier/zero-shot/108/device/2174     |   16 +
 results/classifier/zero-shot/108/device/219      |   16 +
 results/classifier/zero-shot/108/device/221      |   16 +
 results/classifier/zero-shot/108/device/2213     |   30 +
 results/classifier/zero-shot/108/device/224      |   16 +
 results/classifier/zero-shot/108/device/2243     |   24 +
 results/classifier/zero-shot/108/device/2268     |   58 +
 results/classifier/zero-shot/108/device/2272     |   36 +
 results/classifier/zero-shot/108/device/2282     |   16 +
 results/classifier/zero-shot/108/device/2294     |   16 +
 results/classifier/zero-shot/108/device/2312     |   59 +
 results/classifier/zero-shot/108/device/2327     |   76 ++
 results/classifier/zero-shot/108/device/2336     |   38 +
 results/classifier/zero-shot/108/device/2348     |   22 +
 results/classifier/zero-shot/108/device/2357     |   33 +
 results/classifier/zero-shot/108/device/2438     |   16 +
 results/classifier/zero-shot/108/device/2443     |   33 +
 results/classifier/zero-shot/108/device/2454     |   23 +
 results/classifier/zero-shot/108/device/2468     |   48 +
 results/classifier/zero-shot/108/device/248      |   16 +
 results/classifier/zero-shot/108/device/251      |   16 +
 results/classifier/zero-shot/108/device/2636     |   16 +
 results/classifier/zero-shot/108/device/2640     |   16 +
 results/classifier/zero-shot/108/device/2653     |   16 +
 results/classifier/zero-shot/108/device/2654     |   29 +
 results/classifier/zero-shot/108/device/2663     |   22 +
 results/classifier/zero-shot/108/device/2695     |   18 +
 results/classifier/zero-shot/108/device/2698     |   24 +
 results/classifier/zero-shot/108/device/2700     |   23 +
 results/classifier/zero-shot/108/device/2707     |   25 +
 results/classifier/zero-shot/108/device/2724     |   23 +
 results/classifier/zero-shot/108/device/2734     |   39 +
 results/classifier/zero-shot/108/device/2741     |   76 ++
 results/classifier/zero-shot/108/device/2752     |  292 +++++
 results/classifier/zero-shot/108/device/2801     |   16 +
 results/classifier/zero-shot/108/device/2803     |  123 ++
 results/classifier/zero-shot/108/device/2805     |   37 +
 results/classifier/zero-shot/108/device/2812     |   16 +
 results/classifier/zero-shot/108/device/283      |   16 +
 results/classifier/zero-shot/108/device/2831     |   35 +
 results/classifier/zero-shot/108/device/2841     |   26 +
 results/classifier/zero-shot/108/device/2858     |   16 +
 results/classifier/zero-shot/108/device/2859     |   16 +
 results/classifier/zero-shot/108/device/2885     |   16 +
 results/classifier/zero-shot/108/device/2893     |   27 +
 results/classifier/zero-shot/108/device/2905     |   39 +
 results/classifier/zero-shot/108/device/2913     |   16 +
 results/classifier/zero-shot/108/device/2923     |   28 +
 results/classifier/zero-shot/108/device/2929     |   22 +
 results/classifier/zero-shot/108/device/2939     |   16 +
 results/classifier/zero-shot/108/device/2940     |   16 +
 results/classifier/zero-shot/108/device/296      |   16 +
 results/classifier/zero-shot/108/device/2968     |   37 +
 results/classifier/zero-shot/108/device/318      |   16 +
 results/classifier/zero-shot/108/device/319      |   16 +
 results/classifier/zero-shot/108/device/325      |   16 +
 results/classifier/zero-shot/108/device/331      |   16 +
 results/classifier/zero-shot/108/device/346      |   16 +
 results/classifier/zero-shot/108/device/405      |   16 +
 results/classifier/zero-shot/108/device/406      |   16 +
 results/classifier/zero-shot/108/device/422      |   16 +
 results/classifier/zero-shot/108/device/42226390 |  197 ++++
 results/classifier/zero-shot/108/device/431      |   16 +
 results/classifier/zero-shot/108/device/448      |   16 +
 results/classifier/zero-shot/108/device/468      |   16 +
 results/classifier/zero-shot/108/device/477      |   27 +
 results/classifier/zero-shot/108/device/487      |   16 +
 results/classifier/zero-shot/108/device/503      |   16 +
 results/classifier/zero-shot/108/device/51       |   16 +
 results/classifier/zero-shot/108/device/513      |   16 +
 results/classifier/zero-shot/108/device/529      |   19 +
 results/classifier/zero-shot/108/device/54       |   16 +
 results/classifier/zero-shot/108/device/55       |   16 +
 results/classifier/zero-shot/108/device/554      |   16 +
 results/classifier/zero-shot/108/device/558      |   72 ++
 results/classifier/zero-shot/108/device/569      |   16 +
 results/classifier/zero-shot/108/device/617      |   41 +
 results/classifier/zero-shot/108/device/63       |   16 +
 results/classifier/zero-shot/108/device/651      |   16 +
 results/classifier/zero-shot/108/device/663      |   26 +
 results/classifier/zero-shot/108/device/667      |   16 +
 results/classifier/zero-shot/108/device/678      |   62 +
 results/classifier/zero-shot/108/device/68       |   16 +
 results/classifier/zero-shot/108/device/71       |   16 +
 results/classifier/zero-shot/108/device/723460   |   70 ++
 results/classifier/zero-shot/108/device/743      |   26 +
 results/classifier/zero-shot/108/device/752      |   28 +
 results/classifier/zero-shot/108/device/776      |   40 +
 results/classifier/zero-shot/108/device/784      |   28 +
 results/classifier/zero-shot/108/device/788      |   16 +
 results/classifier/zero-shot/108/device/791      |   16 +
 results/classifier/zero-shot/108/device/800      |   40 +
 results/classifier/zero-shot/108/device/801      |   27 +
 results/classifier/zero-shot/108/device/804      |   24 +
 results/classifier/zero-shot/108/device/808      |   33 +
 results/classifier/zero-shot/108/device/823733   |  163 +++
 results/classifier/zero-shot/108/device/837      |   45 +
 results/classifier/zero-shot/108/device/879      |   18 +
 results/classifier/zero-shot/108/device/896      |   16 +
 results/classifier/zero-shot/108/device/897      |   16 +
 results/classifier/zero-shot/108/device/901      |   25 +
 results/classifier/zero-shot/108/device/902      |   16 +
 results/classifier/zero-shot/108/device/924      |   16 +
 results/classifier/zero-shot/108/device/98       |   16 +
 211 files changed, 10891 insertions(+)
 create mode 100644 results/classifier/zero-shot/108/device/102
 create mode 100644 results/classifier/zero-shot/108/device/1024
 create mode 100644 results/classifier/zero-shot/108/device/1033
 create mode 100644 results/classifier/zero-shot/108/device/1034980
 create mode 100644 results/classifier/zero-shot/108/device/1047999
 create mode 100644 results/classifier/zero-shot/108/device/1050823
 create mode 100644 results/classifier/zero-shot/108/device/1077
 create mode 100644 results/classifier/zero-shot/108/device/112
 create mode 100644 results/classifier/zero-shot/108/device/1132
 create mode 100644 results/classifier/zero-shot/108/device/1134
 create mode 100644 results/classifier/zero-shot/108/device/1140
 create mode 100644 results/classifier/zero-shot/108/device/116
 create mode 100644 results/classifier/zero-shot/108/device/118
 create mode 100644 results/classifier/zero-shot/108/device/119
 create mode 100644 results/classifier/zero-shot/108/device/1191
 create mode 100644 results/classifier/zero-shot/108/device/1198350
 create mode 100644 results/classifier/zero-shot/108/device/1208
 create mode 100644 results/classifier/zero-shot/108/device/1221
 create mode 100644 results/classifier/zero-shot/108/device/1225
 create mode 100644 results/classifier/zero-shot/108/device/1237
 create mode 100644 results/classifier/zero-shot/108/device/1248469
 create mode 100644 results/classifier/zero-shot/108/device/1282
 create mode 100644 results/classifier/zero-shot/108/device/1284
 create mode 100644 results/classifier/zero-shot/108/device/1300
 create mode 100644 results/classifier/zero-shot/108/device/1305
 create mode 100644 results/classifier/zero-shot/108/device/1318
 create mode 100644 results/classifier/zero-shot/108/device/132
 create mode 100644 results/classifier/zero-shot/108/device/1332234
 create mode 100644 results/classifier/zero-shot/108/device/1342
 create mode 100644 results/classifier/zero-shot/108/device/1346
 create mode 100644 results/classifier/zero-shot/108/device/1354
 create mode 100644 results/classifier/zero-shot/108/device/1363
 create mode 100644 results/classifier/zero-shot/108/device/1391
 create mode 100644 results/classifier/zero-shot/108/device/1406
 create mode 100644 results/classifier/zero-shot/108/device/1413
 create mode 100644 results/classifier/zero-shot/108/device/1445633
 create mode 100644 results/classifier/zero-shot/108/device/1478
 create mode 100644 results/classifier/zero-shot/108/device/149
 create mode 100644 results/classifier/zero-shot/108/device/1507
 create mode 100644 results/classifier/zero-shot/108/device/1515
 create mode 100644 results/classifier/zero-shot/108/device/1519
 create mode 100644 results/classifier/zero-shot/108/device/1564
 create mode 100644 results/classifier/zero-shot/108/device/157
 create mode 100644 results/classifier/zero-shot/108/device/1574
 create mode 100644 results/classifier/zero-shot/108/device/1581308
 create mode 100644 results/classifier/zero-shot/108/device/1581976
 create mode 100644 results/classifier/zero-shot/108/device/1586613
 create mode 100644 results/classifier/zero-shot/108/device/1629618
 create mode 100644 results/classifier/zero-shot/108/device/1634852
 create mode 100644 results/classifier/zero-shot/108/device/1637974
 create mode 100644 results/classifier/zero-shot/108/device/1660035
 create mode 100644 results/classifier/zero-shot/108/device/1661
 create mode 100644 results/classifier/zero-shot/108/device/1663
 create mode 100644 results/classifier/zero-shot/108/device/1672
 create mode 100644 results/classifier/zero-shot/108/device/1675549
 create mode 100644 results/classifier/zero-shot/108/device/168
 create mode 100644 results/classifier/zero-shot/108/device/1696773
 create mode 100644 results/classifier/zero-shot/108/device/1699628
 create mode 100644 results/classifier/zero-shot/108/device/1712027
 create mode 100644 results/classifier/zero-shot/108/device/1724
 create mode 100644 results/classifier/zero-shot/108/device/1731347
 create mode 100644 results/classifier/zero-shot/108/device/1732981
 create mode 100644 results/classifier/zero-shot/108/device/1733720
 create mode 100644 results/classifier/zero-shot/108/device/1737194
 create mode 100644 results/classifier/zero-shot/108/device/174
 create mode 100644 results/classifier/zero-shot/108/device/1744654
 create mode 100644 results/classifier/zero-shot/108/device/1745895
 create mode 100644 results/classifier/zero-shot/108/device/1748
 create mode 100644 results/classifier/zero-shot/108/device/1759
 create mode 100644 results/classifier/zero-shot/108/device/1760176
 create mode 100644 results/classifier/zero-shot/108/device/1761
 create mode 100644 results/classifier/zero-shot/108/device/1767
 create mode 100644 results/classifier/zero-shot/108/device/1769
 create mode 100644 results/classifier/zero-shot/108/device/1773
 create mode 100644 results/classifier/zero-shot/108/device/1794
 create mode 100644 results/classifier/zero-shot/108/device/1815445
 create mode 100644 results/classifier/zero-shot/108/device/182
 create mode 100644 results/classifier/zero-shot/108/device/1824853
 create mode 100644 results/classifier/zero-shot/108/device/1835839
 create mode 100644 results/classifier/zero-shot/108/device/184
 create mode 100644 results/classifier/zero-shot/108/device/1847
 create mode 100644 results/classifier/zero-shot/108/device/1854
 create mode 100644 results/classifier/zero-shot/108/device/1854878
 create mode 100644 results/classifier/zero-shot/108/device/1859
 create mode 100644 results/classifier/zero-shot/108/device/1864
 create mode 100644 results/classifier/zero-shot/108/device/1866
 create mode 100644 results/classifier/zero-shot/108/device/1866792
 create mode 100644 results/classifier/zero-shot/108/device/187
 create mode 100644 results/classifier/zero-shot/108/device/1875080
 create mode 100644 results/classifier/zero-shot/108/device/1877716
 create mode 100644 results/classifier/zero-shot/108/device/1880
 create mode 100644 results/classifier/zero-shot/108/device/1882787
 create mode 100644 results/classifier/zero-shot/108/device/1882851
 create mode 100644 results/classifier/zero-shot/108/device/1888
 create mode 100644 results/classifier/zero-shot/108/device/1890160
 create mode 100644 results/classifier/zero-shot/108/device/1902306
 create mode 100644 results/classifier/zero-shot/108/device/1909418
 create mode 100644 results/classifier/zero-shot/108/device/1911797
 create mode 100644 results/classifier/zero-shot/108/device/1922102
 create mode 100644 results/classifier/zero-shot/108/device/193
 create mode 100644 results/classifier/zero-shot/108/device/1945540
 create mode 100644 results/classifier/zero-shot/108/device/2021
 create mode 100644 results/classifier/zero-shot/108/device/2033
 create mode 100644 results/classifier/zero-shot/108/device/204
 create mode 100644 results/classifier/zero-shot/108/device/2044
 create mode 100644 results/classifier/zero-shot/108/device/2049
 create mode 100644 results/classifier/zero-shot/108/device/2122
 create mode 100644 results/classifier/zero-shot/108/device/2174
 create mode 100644 results/classifier/zero-shot/108/device/219
 create mode 100644 results/classifier/zero-shot/108/device/221
 create mode 100644 results/classifier/zero-shot/108/device/2213
 create mode 100644 results/classifier/zero-shot/108/device/224
 create mode 100644 results/classifier/zero-shot/108/device/2243
 create mode 100644 results/classifier/zero-shot/108/device/2268
 create mode 100644 results/classifier/zero-shot/108/device/2272
 create mode 100644 results/classifier/zero-shot/108/device/2282
 create mode 100644 results/classifier/zero-shot/108/device/2294
 create mode 100644 results/classifier/zero-shot/108/device/2312
 create mode 100644 results/classifier/zero-shot/108/device/2327
 create mode 100644 results/classifier/zero-shot/108/device/2336
 create mode 100644 results/classifier/zero-shot/108/device/2348
 create mode 100644 results/classifier/zero-shot/108/device/2357
 create mode 100644 results/classifier/zero-shot/108/device/2438
 create mode 100644 results/classifier/zero-shot/108/device/2443
 create mode 100644 results/classifier/zero-shot/108/device/2454
 create mode 100644 results/classifier/zero-shot/108/device/2468
 create mode 100644 results/classifier/zero-shot/108/device/248
 create mode 100644 results/classifier/zero-shot/108/device/251
 create mode 100644 results/classifier/zero-shot/108/device/2636
 create mode 100644 results/classifier/zero-shot/108/device/2640
 create mode 100644 results/classifier/zero-shot/108/device/2653
 create mode 100644 results/classifier/zero-shot/108/device/2654
 create mode 100644 results/classifier/zero-shot/108/device/2663
 create mode 100644 results/classifier/zero-shot/108/device/2695
 create mode 100644 results/classifier/zero-shot/108/device/2698
 create mode 100644 results/classifier/zero-shot/108/device/2700
 create mode 100644 results/classifier/zero-shot/108/device/2707
 create mode 100644 results/classifier/zero-shot/108/device/2724
 create mode 100644 results/classifier/zero-shot/108/device/2734
 create mode 100644 results/classifier/zero-shot/108/device/2741
 create mode 100644 results/classifier/zero-shot/108/device/2752
 create mode 100644 results/classifier/zero-shot/108/device/2801
 create mode 100644 results/classifier/zero-shot/108/device/2803
 create mode 100644 results/classifier/zero-shot/108/device/2805
 create mode 100644 results/classifier/zero-shot/108/device/2812
 create mode 100644 results/classifier/zero-shot/108/device/283
 create mode 100644 results/classifier/zero-shot/108/device/2831
 create mode 100644 results/classifier/zero-shot/108/device/2841
 create mode 100644 results/classifier/zero-shot/108/device/2858
 create mode 100644 results/classifier/zero-shot/108/device/2859
 create mode 100644 results/classifier/zero-shot/108/device/2885
 create mode 100644 results/classifier/zero-shot/108/device/2893
 create mode 100644 results/classifier/zero-shot/108/device/2905
 create mode 100644 results/classifier/zero-shot/108/device/2913
 create mode 100644 results/classifier/zero-shot/108/device/2923
 create mode 100644 results/classifier/zero-shot/108/device/2929
 create mode 100644 results/classifier/zero-shot/108/device/2939
 create mode 100644 results/classifier/zero-shot/108/device/2940
 create mode 100644 results/classifier/zero-shot/108/device/296
 create mode 100644 results/classifier/zero-shot/108/device/2968
 create mode 100644 results/classifier/zero-shot/108/device/318
 create mode 100644 results/classifier/zero-shot/108/device/319
 create mode 100644 results/classifier/zero-shot/108/device/325
 create mode 100644 results/classifier/zero-shot/108/device/331
 create mode 100644 results/classifier/zero-shot/108/device/346
 create mode 100644 results/classifier/zero-shot/108/device/405
 create mode 100644 results/classifier/zero-shot/108/device/406
 create mode 100644 results/classifier/zero-shot/108/device/422
 create mode 100644 results/classifier/zero-shot/108/device/42226390
 create mode 100644 results/classifier/zero-shot/108/device/431
 create mode 100644 results/classifier/zero-shot/108/device/448
 create mode 100644 results/classifier/zero-shot/108/device/468
 create mode 100644 results/classifier/zero-shot/108/device/477
 create mode 100644 results/classifier/zero-shot/108/device/487
 create mode 100644 results/classifier/zero-shot/108/device/503
 create mode 100644 results/classifier/zero-shot/108/device/51
 create mode 100644 results/classifier/zero-shot/108/device/513
 create mode 100644 results/classifier/zero-shot/108/device/529
 create mode 100644 results/classifier/zero-shot/108/device/54
 create mode 100644 results/classifier/zero-shot/108/device/55
 create mode 100644 results/classifier/zero-shot/108/device/554
 create mode 100644 results/classifier/zero-shot/108/device/558
 create mode 100644 results/classifier/zero-shot/108/device/569
 create mode 100644 results/classifier/zero-shot/108/device/617
 create mode 100644 results/classifier/zero-shot/108/device/63
 create mode 100644 results/classifier/zero-shot/108/device/651
 create mode 100644 results/classifier/zero-shot/108/device/663
 create mode 100644 results/classifier/zero-shot/108/device/667
 create mode 100644 results/classifier/zero-shot/108/device/678
 create mode 100644 results/classifier/zero-shot/108/device/68
 create mode 100644 results/classifier/zero-shot/108/device/71
 create mode 100644 results/classifier/zero-shot/108/device/723460
 create mode 100644 results/classifier/zero-shot/108/device/743
 create mode 100644 results/classifier/zero-shot/108/device/752
 create mode 100644 results/classifier/zero-shot/108/device/776
 create mode 100644 results/classifier/zero-shot/108/device/784
 create mode 100644 results/classifier/zero-shot/108/device/788
 create mode 100644 results/classifier/zero-shot/108/device/791
 create mode 100644 results/classifier/zero-shot/108/device/800
 create mode 100644 results/classifier/zero-shot/108/device/801
 create mode 100644 results/classifier/zero-shot/108/device/804
 create mode 100644 results/classifier/zero-shot/108/device/808
 create mode 100644 results/classifier/zero-shot/108/device/823733
 create mode 100644 results/classifier/zero-shot/108/device/837
 create mode 100644 results/classifier/zero-shot/108/device/879
 create mode 100644 results/classifier/zero-shot/108/device/896
 create mode 100644 results/classifier/zero-shot/108/device/897
 create mode 100644 results/classifier/zero-shot/108/device/901
 create mode 100644 results/classifier/zero-shot/108/device/902
 create mode 100644 results/classifier/zero-shot/108/device/924
 create mode 100644 results/classifier/zero-shot/108/device/98

(limited to 'results/classifier/zero-shot/108/device')

diff --git a/results/classifier/zero-shot/108/device/102 b/results/classifier/zero-shot/108/device/102
new file mode 100644
index 00000000..53a4f1e1
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/102
@@ -0,0 +1,16 @@
+device: 0.920
+performance: 0.747
+debug: 0.721
+graphic: 0.541
+semantic: 0.369
+permissions: 0.260
+other: 0.243
+PID: 0.242
+boot: 0.214
+files: 0.190
+vnc: 0.072
+network: 0.040
+KVM: 0.034
+socket: 0.013
+
+Mouse stops working when connected usb-storage-device
diff --git a/results/classifier/zero-shot/108/device/1024 b/results/classifier/zero-shot/108/device/1024
new file mode 100644
index 00000000..39f4f8d7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1024
@@ -0,0 +1,25 @@
+device: 0.935
+graphic: 0.916
+files: 0.778
+debug: 0.726
+performance: 0.710
+network: 0.704
+PID: 0.695
+other: 0.694
+socket: 0.692
+vnc: 0.671
+boot: 0.627
+semantic: 0.626
+permissions: 0.529
+KVM: 0.035
+
+Unable to build QEMU with dbus display support on Windows
+Description of problem:
+When building QEMU on Windows with `./configure --enable-dbus-display --enable-modules`, the following error appears:
+
+`ERROR: Modules are not available for Windows`
+Steps to reproduce:
+1. Attempt to build QEMU on Windows (MSYS2 MinGW) with dbus display support
+Additional information:
+Attempting to build with only `--enable-dbus-display` does not work either, as it requires `--enable-modules`, which does not work on Windows:
+`../meson.build:1598:0: ERROR: Feature dbus_display cannot be enabled: -display dbus requires --enable-modules`
diff --git a/results/classifier/zero-shot/108/device/1033 b/results/classifier/zero-shot/108/device/1033
new file mode 100644
index 00000000..bfb66ad1
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1033
@@ -0,0 +1,42 @@
+device: 0.962
+graphic: 0.936
+semantic: 0.894
+debug: 0.835
+PID: 0.807
+other: 0.774
+performance: 0.681
+network: 0.590
+files: 0.492
+vnc: 0.435
+permissions: 0.410
+socket: 0.386
+boot: 0.199
+KVM: 0.044
+
+fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented'
+Description of problem:
+Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109
+
+Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in:
+
+```
+dpkg-buildpackage: info: source package clementine
+dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye
+dpkg-buildpackage: info: source distribution bullseye
+dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com>
+dpkg-buildpackage: info: host architecture armhf
+ dpkg-source --before-build .
+ fakeroot debian/rules clean
+semop(1): encountered an error: Function not implemented
+dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1
+```
+
+This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109.
+Steps to reproduce:
+1. Setup (s)chroot with arm architecture (although the architecture may not matter) 
+2. Run fakeroot in the chroot
+3. Observe the failure related to the semop syscall
+Additional information:
+- Not sure what other information I can provide to be helpful.
+- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does.
+- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin).
diff --git a/results/classifier/zero-shot/108/device/1034980 b/results/classifier/zero-shot/108/device/1034980
new file mode 100644
index 00000000..2382232d
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1034980
@@ -0,0 +1,37 @@
+device: 0.923
+graphic: 0.892
+socket: 0.802
+PID: 0.770
+performance: 0.754
+network: 0.727
+vnc: 0.701
+permissions: 0.649
+files: 0.577
+semantic: 0.564
+boot: 0.551
+debug: 0.472
+other: 0.206
+KVM: 0.142
+
+pseries machine: vscsi scsi qemu cd-rom does not work in win32
+
+On Win32, the cd-rom device is not detected at all in the pseries machine (SLOF):
+   
+   qemu-system-ppc64 -M pseries -m 512 -cdrom img.iso
+      ....etc.
+   VSCSI: Looking for disks
+   Populating /pci@800000020000001,0
+
+
+On Linux however, the scsi qemu cd-rom device is detected and works fine in the pseries machine:
+
+   qemu-system-ppc64 -M pseries -m 512 -cdrom img.iso
+      ....etc.
+   VSCSI: Looking for disks
+      SCSI ID 2 CD-ROM   : "QEMU     QEMU CD-ROM      1.1."
+   Populating /pci@800000020000001,0
+
+This started to work in version 1.2, thanks!
+
+Closing this bug, since it is working now according to comment #1
+
diff --git a/results/classifier/zero-shot/108/device/1047999 b/results/classifier/zero-shot/108/device/1047999
new file mode 100644
index 00000000..2e977799
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1047999
@@ -0,0 +1,135 @@
+device: 0.951
+semantic: 0.947
+graphic: 0.936
+debug: 0.935
+performance: 0.930
+other: 0.927
+permissions: 0.913
+files: 0.905
+PID: 0.900
+vnc: 0.873
+boot: 0.873
+network: 0.830
+KVM: 0.826
+socket: 0.816
+
+error building process in sdlaudio.o
+
+./configure --enable-sdl --enable-virtfs --enable-vnc --enable-cocoa --enable-mixemu --enable-brlapi --enable-vnc-tls --enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --enable-curses --enable-curl --enable-bluez --enable-tcg-interpreter --enable-nptl --enable-system --enable-user --enable-linux-user --enable-guest-base --enable-pie --enable-uuid --enable-vde --enable-attr --enable-docs --enable-vhost-net --enable-smartcard --enable-guest-agent --enable-seccomp --audio-drv-list="alsa oss sdl esd pa" --audio-card-list="ac97 es1370 sb16 cs4231a adlib gus hda" --prefix=/opt/qemu
+
+audio/sdlaudio.c:55: error: expected specifier-qualifier-list before ‘SDL_mutex’
+audio/sdlaudio.c: In function ‘sdl_logerr’:
+audio/sdlaudio.c:69: warning: implicit declaration of function ‘SDL_GetError’
+audio/sdlaudio.c:69: warning: nested extern declaration of ‘SDL_GetError’
+audio/sdlaudio.c:69: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
+audio/sdlaudio.c: In function ‘sdl_lock’:
+audio/sdlaudio.c:74: warning: implicit declaration of function ‘SDL_LockMutex’
+audio/sdlaudio.c:74: warning: nested extern declaration of ‘SDL_LockMutex’
+audio/sdlaudio.c:74: error: ‘SDLAudioState’ has no member named ‘mutex’
+audio/sdlaudio.c: In function ‘sdl_unlock’:
+audio/sdlaudio.c:83: warning: implicit declaration of function ‘SDL_UnlockMutex’
+audio/sdlaudio.c:83: warning: nested extern declaration of ‘SDL_UnlockMutex’
+audio/sdlaudio.c:83: error: ‘SDLAudioState’ has no member named ‘mutex’
+audio/sdlaudio.c: In function ‘sdl_post’:
+audio/sdlaudio.c:92: warning: implicit declaration of function ‘SDL_SemPost’
+audio/sdlaudio.c:92: warning: nested extern declaration of ‘SDL_SemPost’
+audio/sdlaudio.c:92: error: ‘SDLAudioState’ has no member named ‘sem’
+audio/sdlaudio.c: In function ‘sdl_wait’:
+audio/sdlaudio.c:101: warning: implicit declaration of function ‘SDL_SemWait’
+audio/sdlaudio.c:101: warning: nested extern declaration of ‘SDL_SemWait’
+audio/sdlaudio.c:101: error: ‘SDLAudioState’ has no member named ‘sem’
+audio/sdlaudio.c: In function ‘aud_to_sdlfmt’:
+audio/sdlaudio.c:121: error: ‘AUDIO_S8’ undeclared (first use in this function)
+audio/sdlaudio.c:121: error: (Each undeclared identifier is reported only once
+audio/sdlaudio.c:121: error: for each function it appears in.)
+audio/sdlaudio.c:124: error: ‘AUDIO_U8’ undeclared (first use in this function)
+audio/sdlaudio.c:127: error: ‘AUDIO_S16LSB’ undeclared (first use in this function)
+audio/sdlaudio.c:130: error: ‘AUDIO_U16LSB’ undeclared (first use in this function)
+audio/sdlaudio.c: In function ‘sdl_to_audfmt’:
+audio/sdlaudio.c:144: error: ‘AUDIO_S8’ undeclared (first use in this function)
+audio/sdlaudio.c:149: error: ‘AUDIO_U8’ undeclared (first use in this function)
+audio/sdlaudio.c:154: error: ‘AUDIO_S16LSB’ undeclared (first use in this function)
+audio/sdlaudio.c:159: error: ‘AUDIO_U16LSB’ undeclared (first use in this function)
+audio/sdlaudio.c:164: error: ‘AUDIO_S16MSB’ undeclared (first use in this function)
+audio/sdlaudio.c:169: error: ‘AUDIO_U16MSB’ undeclared (first use in this function)
+audio/sdlaudio.c: At top level:
+audio/sdlaudio.c:182: error: expected ‘)’ before ‘*’ token
+audio/sdlaudio.c: In function ‘sdl_close’:
+audio/sdlaudio.c:222: error: ‘SDLAudioState’ has no member named ‘initialized’
+audio/sdlaudio.c:226: warning: implicit declaration of function ‘SDL_PauseAudio’
+audio/sdlaudio.c:226: warning: nested extern declaration of ‘SDL_PauseAudio’
+audio/sdlaudio.c:227: warning: implicit declaration of function ‘SDL_CloseAudio’
+audio/sdlaudio.c:227: warning: nested extern declaration of ‘SDL_CloseAudio’
+audio/sdlaudio.c:228: error: ‘SDLAudioState’ has no member named ‘initialized’
+audio/sdlaudio.c: At top level:
+audio/sdlaudio.c:232: error: expected declaration specifiers or ‘...’ before ‘Uint8’
+audio/sdlaudio.c: In function ‘sdl_callback’:
+audio/sdlaudio.c:274: error: ‘buf’ undeclared (first use in this function)
+audio/sdlaudio.c: In function ‘sdl_init_out’:
+audio/sdlaudio.c:339: error: ‘SDL_AudioSpec’ undeclared (first use in this function)
+audio/sdlaudio.c:339: error: expected ‘;’ before ‘req’
+audio/sdlaudio.c:345: error: ‘req’ undeclared (first use in this function)
+audio/sdlaudio.c:352: warning: implicit declaration of function ‘sdl_open’
+audio/sdlaudio.c:352: warning: nested extern declaration of ‘sdl_open’
+audio/sdlaudio.c:352: error: ‘obt’ undeclared (first use in this function)
+audio/sdlaudio.c:370: error: ‘SDLAudioState’ has no member named ‘initialized’
+audio/sdlaudio.c: In function ‘sdl_audio_init’:
+audio/sdlaudio.c:396: warning: implicit declaration of function ‘SDL_InitSubSystem’
+audio/sdlaudio.c:396: warning: nested extern declaration of ‘SDL_InitSubSystem’
+audio/sdlaudio.c:396: error: ‘SDL_INIT_AUDIO’ undeclared (first use in this function)
+audio/sdlaudio.c:401: error: ‘SDLAudioState’ has no member named ‘mutex’
+audio/sdlaudio.c:401: warning: implicit declaration of function ‘SDL_CreateMutex’
+audio/sdlaudio.c:401: warning: nested extern declaration of ‘SDL_CreateMutex’
+audio/sdlaudio.c:402: error: ‘SDLAudioState’ has no member named ‘mutex’
+audio/sdlaudio.c:404: warning: implicit declaration of function ‘SDL_QuitSubSystem’
+audio/sdlaudio.c:404: warning: nested extern declaration of ‘SDL_QuitSubSystem’
+audio/sdlaudio.c:408: error: ‘SDLAudioState’ has no member named ‘sem’
+audio/sdlaudio.c:408: warning: implicit declaration of function ‘SDL_CreateSemaphore’
+audio/sdlaudio.c:408: warning: nested extern declaration of ‘SDL_CreateSemaphore’
+audio/sdlaudio.c:409: error: ‘SDLAudioState’ has no member named ‘sem’
+audio/sdlaudio.c:411: warning: implicit declaration of function ‘SDL_DestroyMutex’
+audio/sdlaudio.c:411: warning: nested extern declaration of ‘SDL_DestroyMutex’
+audio/sdlaudio.c:411: error: ‘SDLAudioState’ has no member named ‘mutex’
+audio/sdlaudio.c: In function ‘sdl_audio_fini’:
+audio/sdlaudio.c:423: warning: implicit declaration of function ‘SDL_DestroySemaphore’
+audio/sdlaudio.c:423: warning: nested extern declaration of ‘SDL_DestroySemaphore’
+audio/sdlaudio.c:423: error: ‘SDLAudioState’ has no member named ‘sem’
+audio/sdlaudio.c:424: error: ‘SDLAudioState’ has no member named ‘mutex’
+audio/sdlaudio.c:425: error: ‘SDL_INIT_AUDIO’ undeclared (first use in this function)
+make: *** [audio/sdlaudio.o] Error 1
+
+System:
+Linux insanelive 3.5.3-iatom-bfq #3 SMP Sat Sep 1 20:30:22 MSK 2012 i686 GNU/Linux
+Debian 6.0.5 Squeeze
+
+On Sat, Sep 8, 2012 at 10:09 PM, Oleg Bobuh <email address hidden> wrote:
+> ** Description changed:
+
+Is this qemu.git/master?
+
+>   ./configure --enable-sdl --enable-virtfs --enable-vnc --enable-cocoa
+>   --enable-mixemu --enable-brlapi --enable-vnc-tls --enable-vnc-sasl
+>   --enable-vnc-jpeg --enable-vnc-png --enable-curses --enable-curl
+>   --enable-bluez --enable-tcg-interpreter --enable-nptl --enable-system
+>   --enable-user --enable-linux-user --enable-guest-base --enable-pie
+>   --enable-uuid --enable-vde --enable-attr --enable-docs --enable-vhost-
+>   net --enable-smartcard --enable-guest-agent --enable-seccomp --audio-
+>   drv-list="alsa oss sdl esd pa" --audio-card-list="ac97 es1370 sb16
+>   cs4231a adlib gus hda" --prefix=/opt/qemu
+
+./configure output should say:
+SDL support       yes
+
+If you get "no" then something is wrong.  SDL on Debian ships with
+pkgconfig information, which ./configure uses to find the correct -I
+and -l compiler flags.
+
+Do you have the libsdl1.2-dev package installed?
+
+Please post the contents of ./config.log after running ./configure.
+
+Stefan
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1050823 b/results/classifier/zero-shot/108/device/1050823
new file mode 100644
index 00000000..67e5c87e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1050823
@@ -0,0 +1,37 @@
+device: 0.952
+network: 0.934
+socket: 0.885
+graphic: 0.821
+vnc: 0.779
+PID: 0.766
+debug: 0.700
+semantic: 0.680
+files: 0.630
+KVM: 0.614
+boot: 0.570
+performance: 0.528
+other: 0.445
+permissions: 0.369
+
+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
+
+Patch has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=278412d0e710e2e848c
+... so I think it should be OK now to close this ticket.
+
diff --git a/results/classifier/zero-shot/108/device/1077 b/results/classifier/zero-shot/108/device/1077
new file mode 100644
index 00000000..53b7e4c9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1077
@@ -0,0 +1,16 @@
+device: 0.948
+network: 0.890
+performance: 0.843
+debug: 0.568
+graphic: 0.534
+semantic: 0.430
+other: 0.381
+socket: 0.380
+files: 0.353
+vnc: 0.340
+permissions: 0.307
+boot: 0.293
+PID: 0.233
+KVM: 0.006
+
+Qemu - Can't connect to ESXi guest
diff --git a/results/classifier/zero-shot/108/device/112 b/results/classifier/zero-shot/108/device/112
new file mode 100644
index 00000000..82fab23a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/112
@@ -0,0 +1,16 @@
+device: 0.937
+network: 0.804
+performance: 0.723
+debug: 0.319
+graphic: 0.284
+socket: 0.260
+semantic: 0.236
+boot: 0.231
+files: 0.205
+other: 0.169
+permissions: 0.112
+PID: 0.101
+KVM: 0.027
+vnc: 0.016
+
+setting unsupported timeout for i6300esb watchdog causes hw reset
diff --git a/results/classifier/zero-shot/108/device/1132 b/results/classifier/zero-shot/108/device/1132
new file mode 100644
index 00000000..4d490728
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1132
@@ -0,0 +1,130 @@
+device: 0.959
+permissions: 0.959
+vnc: 0.951
+other: 0.949
+graphic: 0.945
+semantic: 0.945
+performance: 0.942
+PID: 0.926
+boot: 0.922
+socket: 0.919
+debug: 0.914
+KVM: 0.906
+files: 0.903
+network: 0.790
+
+[SPARC/Leon3] Application compiled by RCC 1.2 won't start
+Description of problem:
+Even simple "hello world" application compiled by Gaisler RCC 1.2 compiler ("space-certified" GCC 4.4.6 with RTEMS OS) for Leon3 CPU won't start on QEMU - QEMU silently exits before getting into `Init`.
+
+In real hardware it works.
+
+(I know that the GCC 4.4.6 is quite ancient now, usage of this toolchain is forced)
+Steps to reproduce:
+Steps provided for Windows system, but I suspect it works exactly the same in Linux system.
+
+1. Get `sparc-rtems-4.10-gcc-4.4.6-1.2.25-mingw` GCC from here: https://www.gaisler.com/anonftp/rcc/rcc-1.2/1.2.25/
+2. Unpack it to `c:\opt` (it doesn't work from other directories. `/opt` for Linux)
+3. Create simple "Hello world" RTEMS application.
+4. Run it by `qemu-system-sparc -machine leon3_generic -nographic -monitor null -serial stdio -m 64M -kernel fail.elf`
+5. Result is exiting before getting into `Init`.
+
+Simple example attached (with ELF). It should print `It works. Exiting.` and exit.
+
+[leon3-rcc-start-fail.zip](/uploads/69d79dcc496e86bb07d5c69212d94ced/leon3-rcc-start-fail.zip)
+Additional information:
+Log:
+
+```
+...
+
+----------------
+IN: ambapp_for_each_dev
+0x40005430:  clr  %o0   ! 0x0
+0x40005434:  ret
+0x40005438:  restore  %g0, %o0, %o0
+
+----------------
+IN: amba_initialize
+0x40003aa8:  cmp  %o0, 0
+0x40003aac:  be  0x40003b4c
+0x40003ab0:  nop
+
+----------------
+IN: amba_initialize
+0x40003b4c:  mov  1, %g1
+0x40003b50:  ta  0
+
+     1: Trap Instruction (v=80)
+pc: 40003b50  npc: 40003b54
+%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000
+%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0
+%l0-7: 40025800 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+%i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 43fffec0 40002b78
+psr: f3400fe5 (icc: -Z-- SPE: SPE) wim: 00000002
+fsr: 00000000 y: ffffffff
+
+----------------
+IN:
+0x40003a18:  cmp  %g1, 3
+0x40003a1c:  bne  0x40003a34
+0x40003a20:  and  %i0, 0xf00, %l4
+
+----------------
+IN:
+0x40003a34:  ta  0
+
+     2: Trap Instruction (v=80)
+pc: 40003a34  npc: 40003a38
+%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000
+%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470
+%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800
+%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0
+psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002
+fsr: 00000000 y: ffffffff
+
+     3: Trap Instruction (v=80)
+pc: 40003a34  npc: 40003a38
+%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000
+%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470
+%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800
+%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0
+psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002
+fsr: 00000000 y: ffffffff
+
+// repeating until sudden and quiet exit from QEMU
+```
+
+After digging it seems that target code requires byte access to GRLIB APB PNP registers that is not implemented in QEMU now. 
+Adding code supporting byte access seems to help.
+
+The quick patch is:
+
+```
+--- a/hw/misc/grlib_ahb_apb_pnp.c
++++ b/hw/misc/grlib_ahb_apb_pnp.c
+@@ -249,6 +249,11 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
+     val = apb_pnp->regs[offset >> 2];
+     trace_grlib_apb_pnp_read(offset, val);
+ 
++    if (size == 1) {
++        val >>= (24 - (offset & 3) * 8);
++        val &= 0x0ff;
++    }
++
+     return val;
+ }
+ 
+@@ -263,7 +268,7 @@ static const MemoryRegionOps grlib_apb_pnp_ops = {
+     .write      = grlib_apb_pnp_write,
+     .endianness = DEVICE_BIG_ENDIAN,
+     .impl = {
+-        .min_access_size = 4,
++        .min_access_size = 1,
+         .max_access_size = 4,
+     },
+ };
+
+```
+
+The custom compiled QEMU with this patch is used in project for over half a year and it works fine, but I don't know if it is a proper fix.
diff --git a/results/classifier/zero-shot/108/device/1134 b/results/classifier/zero-shot/108/device/1134
new file mode 100644
index 00000000..a1827b77
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1134
@@ -0,0 +1,18 @@
+device: 0.936
+other: 0.892
+semantic: 0.554
+graphic: 0.418
+boot: 0.293
+performance: 0.233
+permissions: 0.165
+debug: 0.152
+vnc: 0.106
+network: 0.083
+files: 0.037
+socket: 0.009
+PID: 0.007
+KVM: 0.001
+
+Make ivshmem more generic not only a PCI device
+Additional information:
+It will also benefit from making it more portable, see https://gitlab.com/qemu-project/qemu/-/issues/666
diff --git a/results/classifier/zero-shot/108/device/1140 b/results/classifier/zero-shot/108/device/1140
new file mode 100644
index 00000000..0491a12c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1140
@@ -0,0 +1,16 @@
+device: 0.952
+performance: 0.944
+graphic: 0.853
+permissions: 0.603
+semantic: 0.384
+debug: 0.358
+PID: 0.305
+other: 0.273
+boot: 0.217
+vnc: 0.189
+network: 0.016
+files: 0.011
+socket: 0.001
+KVM: 0.001
+
+High CPU usage on AMD after migrating guests
diff --git a/results/classifier/zero-shot/108/device/116 b/results/classifier/zero-shot/108/device/116
new file mode 100644
index 00000000..81f5a1a8
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/116
@@ -0,0 +1,16 @@
+device: 0.929
+performance: 0.742
+graphic: 0.627
+network: 0.522
+debug: 0.457
+boot: 0.355
+semantic: 0.224
+permissions: 0.223
+other: 0.091
+PID: 0.089
+socket: 0.078
+vnc: 0.040
+files: 0.020
+KVM: 0.001
+
+qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974
diff --git a/results/classifier/zero-shot/108/device/118 b/results/classifier/zero-shot/108/device/118
new file mode 100644
index 00000000..df583bde
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/118
@@ -0,0 +1,16 @@
+device: 0.938
+debug: 0.816
+network: 0.706
+performance: 0.663
+socket: 0.648
+boot: 0.551
+graphic: 0.524
+other: 0.382
+vnc: 0.327
+permissions: 0.322
+PID: 0.312
+semantic: 0.214
+files: 0.060
+KVM: 0.040
+
+USB device 1.1 not correctly passedthru from Linux host to Windows guest
diff --git a/results/classifier/zero-shot/108/device/119 b/results/classifier/zero-shot/108/device/119
new file mode 100644
index 00000000..28cd3f2b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/119
@@ -0,0 +1,16 @@
+device: 0.926
+performance: 0.696
+semantic: 0.627
+graphic: 0.565
+permissions: 0.220
+network: 0.219
+boot: 0.137
+socket: 0.122
+debug: 0.109
+PID: 0.034
+files: 0.029
+vnc: 0.022
+KVM: 0.013
+other: 0.011
+
+USB assert failure on hcd-uhci.c
diff --git a/results/classifier/zero-shot/108/device/1191 b/results/classifier/zero-shot/108/device/1191
new file mode 100644
index 00000000..62fc76a4
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1191
@@ -0,0 +1,24 @@
+device: 0.930
+graphic: 0.867
+boot: 0.835
+other: 0.698
+performance: 0.685
+debug: 0.469
+semantic: 0.446
+PID: 0.410
+vnc: 0.279
+socket: 0.266
+permissions: 0.245
+files: 0.148
+network: 0.144
+KVM: 0.070
+
+AC97+CoreAudio no audio when out frequency not 44,1KHz & always forces host to use 44,1KHz (or less if frequency not supported)
+Description of problem:
+AC97+CoreAudio outputs no audio when output frequency not 44,1KHz. Also always forces host to use 44,1KHz (or less if frequency not supported on host output)
+Steps to reproduce:
+1. Boot any OS with (only) AC97 audio on macOS
+2. Attempt to play audio with output frequency in guest set to 48KHz
+3. Observe lack of output
+Additional information:
+I'm using QEMU to test a Custom OS written by me, but this shouldn't be a code issue on our side, rather an issue with QEMU itself, if this is mistaken, please inform us.
diff --git a/results/classifier/zero-shot/108/device/1198350 b/results/classifier/zero-shot/108/device/1198350
new file mode 100644
index 00000000..3076b28e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1198350
@@ -0,0 +1,67 @@
+device: 0.943
+boot: 0.911
+graphic: 0.861
+socket: 0.835
+semantic: 0.830
+PID: 0.815
+network: 0.798
+files: 0.793
+other: 0.792
+performance: 0.760
+vnc: 0.746
+debug: 0.714
+permissions: 0.711
+KVM: 0.510
+
+USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument
+
+Host Gentoo linux 32bit
+Guest Windows XP SP3
+qemu 1.4.2 and
+qemu fresh get clone and build 2013-07-04 (version1.5.50)
+qemu command line
+
+qemu-system-i386 -enable-kvm localtime -m 2047 -boot d /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb -device usb-ehci,id=ehci -usbdevice host:1493:19
+
+The device I am trying to use with the guest is an interface for the Suunto Ambit 2 GPS watch which has no linux support.
+
+When the USB device is plugged in qemu reports to the command line:
+
+USBDEVFS_DISCONNECT: Invalid argument
+Invalid argument
+
+dmesg shows
+
+[237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci
+[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0
+[237755.582781] usb 2-1.5: config 1 has no interface number 0
+[237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019
+[237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
+[237755.583633] usb 2-1.5: Product: Ambit
+[237755.583634] usb 2-1.5: Manufacturer: Suunto
+[237755.583636] usb 2-1.5: SerialNumber: CE83095110000700
+[237756.584937] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci
+[237756.832658] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci
+[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use
+
+In the windows guest Device Manager a HID device is listed but nothing else happens, no found new hardware dialog or the Suunto software (which is sitting there waiting) is not triggered as it should be.
+
+I have tried successfully with several other devices (flash drive, mouse, printer and video capture device). Because this device pretends to be an HID device my kernel's hid-generic driver was picking it up first until I modified hid-core.c to ignore this vendorid/productid. But still no joy.
+
+I'm guessing it has something to do with the the dmesg lines:
+
+[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0
+[237755.582781] usb 2-1.5: config 1 has no interface number 0
+
+But read that these warnings are not important though I don't get them for other devices. Nor do I get:
+
+[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use
+
+I've done alot of searching and I've run out of ideas. Any help would be great.
+
+I also have this issue. Does anyone have a work around? (it works with Virtual Box)
+
+Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1208 b/results/classifier/zero-shot/108/device/1208
new file mode 100644
index 00000000..da0d91bb
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1208
@@ -0,0 +1,24 @@
+device: 0.953
+semantic: 0.649
+graphic: 0.544
+PID: 0.414
+files: 0.299
+boot: 0.296
+debug: 0.222
+other: 0.153
+performance: 0.148
+vnc: 0.133
+socket: 0.131
+permissions: 0.102
+network: 0.075
+KVM: 0.001
+
+Raspberry Pi 4 Model B
+Additional information:
+There have been some attempts at implementing this a few years ago: see:
+* https://gitlab.com/philmd/qemu/-/tree/raspi4_wip
+* https://github.com/0xMirasio/qemu-patch-raspberry4
+
+
+
+Thanks!
diff --git a/results/classifier/zero-shot/108/device/1221 b/results/classifier/zero-shot/108/device/1221
new file mode 100644
index 00000000..cf62a7ef
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1221
@@ -0,0 +1,44 @@
+device: 0.965
+network: 0.907
+performance: 0.891
+files: 0.866
+KVM: 0.861
+other: 0.859
+vnc: 0.858
+PID: 0.852
+socket: 0.816
+permissions: 0.771
+semantic: 0.757
+graphic: 0.748
+debug: 0.605
+boot: 0.577
+
+qga return "frozen" when vm just been created from snapfile
+Steps to reproduce:
+1. virsh create lisa.xml  
+Domain lisa created from lisa.xml
+
+2. virsh domblklist lisa  
+ vda      /mnt/a/b/srv.qcow2
+
+3. virsh snapshot-create-as lisa  --disk-only --diskspec vda,file=/tmp/f1,snapfile=/tmp/sp1  --no-metadata --quiesce  
+Domain snapshot 20220919165217 created
+
+4. virsh shutdown lisa  
+Domain lisa is being shutdown
+
+5. modify lisa.xml: replace /mnt/a/b/srv/qcow2 with /tmp/sp1
+
+6. virsh create lisa.xml  
+Domain lisa created from lisa.xml
+
+7. virsh domblklist lisa  
+ vda      /tmp/sp1
+ 
+8. virsh qemu-agent-command lisa '{"execute":"guest-fsfreeze-status"}'  
+{"return":"frozen"}
+
+9. virsh snapshot-create-as lisa  --disk-only --diskspec vda,file=/tmp/f2,snapfile=/tmp/sp2  --no-metadata --quiesce  
+error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance
+Additional information:
+Is "frozen" a normal value in step8? If not, what's the best way to avoid this?
diff --git a/results/classifier/zero-shot/108/device/1225 b/results/classifier/zero-shot/108/device/1225
new file mode 100644
index 00000000..011ebc6b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1225
@@ -0,0 +1,16 @@
+device: 0.950
+performance: 0.783
+other: 0.704
+network: 0.677
+socket: 0.665
+files: 0.652
+semantic: 0.648
+debug: 0.612
+graphic: 0.563
+permissions: 0.537
+PID: 0.451
+vnc: 0.440
+boot: 0.172
+KVM: 0.078
+
+Can't update to Windows 11 22H2
diff --git a/results/classifier/zero-shot/108/device/1237 b/results/classifier/zero-shot/108/device/1237
new file mode 100644
index 00000000..5f6b301b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1237
@@ -0,0 +1,16 @@
+device: 0.934
+KVM: 0.898
+performance: 0.787
+network: 0.663
+debug: 0.640
+graphic: 0.549
+PID: 0.400
+semantic: 0.244
+boot: 0.230
+vnc: 0.157
+permissions: 0.123
+files: 0.099
+other: 0.093
+socket: 0.038
+
+after OS upgrade usb-redir connection broken during migration and qemu-kvm: terminating on signal 15
diff --git a/results/classifier/zero-shot/108/device/1248469 b/results/classifier/zero-shot/108/device/1248469
new file mode 100644
index 00000000..8ef2ff54
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1248469
@@ -0,0 +1,23 @@
+device: 0.957
+boot: 0.918
+performance: 0.794
+network: 0.715
+graphic: 0.610
+other: 0.599
+permissions: 0.599
+socket: 0.588
+semantic: 0.436
+files: 0.408
+debug: 0.345
+vnc: 0.314
+PID: 0.265
+KVM: 0.015
+
+qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit
+
+boot windows 7 32bit guest with -readconfig q35-chipset.cfg paramter,in guest's device manager,there's a device 3420 not work,it shows error "This device cannot find enough free resources that it can use(code 12)".
+
+Can you still reproduce this problem with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1282 b/results/classifier/zero-shot/108/device/1282
new file mode 100644
index 00000000..743d8bd3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1282
@@ -0,0 +1,18 @@
+device: 0.962
+graphic: 0.866
+network: 0.855
+semantic: 0.545
+boot: 0.502
+socket: 0.476
+debug: 0.375
+performance: 0.360
+PID: 0.246
+other: 0.213
+files: 0.202
+permissions: 0.089
+vnc: 0.043
+KVM: 0.003
+
+sdhci: DMA reentrancy issue leads to an infinite loop
+Description of problem:
+When sdhci transfers multiple blocks, it doesnot check if the dma-write buffer pointer overlaps with its MMIO region, crafted content can cause DoS because of infinite loop and CPU consumption.
diff --git a/results/classifier/zero-shot/108/device/1284 b/results/classifier/zero-shot/108/device/1284
new file mode 100644
index 00000000..4797d180
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1284
@@ -0,0 +1,29 @@
+device: 0.946
+graphic: 0.919
+debug: 0.620
+semantic: 0.551
+boot: 0.295
+PID: 0.225
+permissions: 0.194
+performance: 0.181
+network: 0.136
+other: 0.129
+socket: 0.102
+vnc: 0.088
+files: 0.081
+KVM: 0.004
+
+macOS QXL VGA not available
+Description of problem:
+```
+qemu-system-aarch64: QXL VGA not available
+```
+```
+qemu-system-aarch64: -device qxl-vga: 'qxl-vga' is not a valid device model name
+```
+Steps to reproduce:
+1. Build QEMU on macOS with SPICE support (meson)
+2. Run commands listed above
+3. Observe QXL not working
+Additional information:
+I'm wiring up QEMU SPICE support on Darwin for Nixpkgs. The same issue can be observed in macports qemu builds with spice. Could this be a packaging issue?
diff --git a/results/classifier/zero-shot/108/device/1300 b/results/classifier/zero-shot/108/device/1300
new file mode 100644
index 00000000..c02cf69a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1300
@@ -0,0 +1,26 @@
+device: 0.961
+graphic: 0.940
+network: 0.880
+files: 0.868
+vnc: 0.859
+socket: 0.807
+semantic: 0.804
+PID: 0.793
+debug: 0.736
+boot: 0.693
+permissions: 0.666
+other: 0.463
+performance: 0.348
+KVM: 0.202
+
+Build failure when configuring CONFIG_VHOST_USER_FS/CONFIG_VIRTIO
+Description of problem:
+Attempting to configure CONFIG_VHOST_USER_FS or CONFIG_VIRTIO results in a build failure. Complete build log (with configure output) is attached.
+Steps to reproduce:
+1. Add `CONFIG_VIRTIO` and `CONFIG_VHOST_USER_FS` (`y` *or* `n`) to `configs/devices/x86_64-softmmu/gentoo.mak` (done via the [ebuild](https://github.com/gentoo/gentoo/blob/master/app-emulation/qemu/qemu-7.1.0.ebuild))
+2. Configure with `--with-devices-x86_64=gentoo`
+3. Attempt building
+Additional information:
+[build.log](/uploads/72fc1284f5245d9384e521d3b1c65953/build.log)
+
+Reported downstream [here](https://bugs.gentoo.org/873190).
diff --git a/results/classifier/zero-shot/108/device/1305 b/results/classifier/zero-shot/108/device/1305
new file mode 100644
index 00000000..39324739
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1305
@@ -0,0 +1,29 @@
+device: 0.924
+socket: 0.922
+network: 0.813
+vnc: 0.798
+performance: 0.779
+graphic: 0.761
+semantic: 0.725
+PID: 0.655
+permissions: 0.602
+debug: 0.595
+boot: 0.557
+KVM: 0.452
+files: 0.442
+other: 0.330
+
+qemu will detach usbredir if backend chardev socket disconnect
+Description of problem:
+When using the usbredir device in the VM, initiate a hot migration to the VM.  
+After the migration is completed, the drive letter of the usb in the VM has changed.  
+Actually the device has been unplugged and re-plugged in the VM.  
+I think we should keep the plugged state of the device after the migration?
+Steps to reproduce:
+1. Start a usbredirserver `usbredirserver -p 7000 -v 4 5-2`;
+2. Start a VM with a usbredir device attached to it;
+3. Mount the usb device in the VM;
+4. Migrate the VM, after the migration done, wait a minute，the drive letter of the usb in the VM has changed.
+Additional information:
+I've found this bug https://bugzilla.redhat.com/show_bug.cgi?id=1254971, this is just to allow the chardev to be reconnected in time when it is disconnected.   
+Can we make chardev reconnect without unpluging the usbredir device?
diff --git a/results/classifier/zero-shot/108/device/1318 b/results/classifier/zero-shot/108/device/1318
new file mode 100644
index 00000000..5d23da08
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1318
@@ -0,0 +1,34 @@
+device: 0.945
+graphic: 0.910
+network: 0.865
+PID: 0.801
+performance: 0.796
+socket: 0.766
+permissions: 0.700
+semantic: 0.655
+vnc: 0.647
+debug: 0.575
+KVM: 0.409
+boot: 0.403
+files: 0.341
+other: 0.184
+
+vsock device fails with "qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)" when queue_reset=true
+Description of problem:
+Immediately after guest vsock driver initialize, qemu prints error messages.  I'm not able to connect to the guest with vsock:
+
+```
+[    0.654463] Run /init as init process
+[    0.679778] NET: Registered PF_VSOCK protocol family
+qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)
+qemu-system-x86_64: Error starting vhost: 95
+ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
+# 
+```
+Steps to reproduce:
+1. Clone `git://passt.top/passt`
+2. In `passt/test`, run `make mbuto.img`
+3. Run `qemu-system-x86_64 -enable-kvm -m 2048 -kernel KERNEL -initrd mbuto.img -nographic -serial stdio -nodefaults -append "console=ttyS0" -device vhost-vsock-pci,guest-cid=31415,queue_reset=true` replacing KERNEL with the host kernel image.
+Additional information:
+- Problem goes away if `queue_reset=false`, which means it goes away with default options prior to `69e1c14aa222` ("virtio: core: vq reset feature negotation support")
+- Occurs both with and without KVM
diff --git a/results/classifier/zero-shot/108/device/132 b/results/classifier/zero-shot/108/device/132
new file mode 100644
index 00000000..bbd3204a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/132
@@ -0,0 +1,16 @@
+device: 0.923
+debug: 0.825
+graphic: 0.417
+performance: 0.400
+semantic: 0.300
+network: 0.235
+boot: 0.210
+other: 0.056
+vnc: 0.042
+permissions: 0.036
+PID: 0.035
+socket: 0.006
+files: 0.006
+KVM: 0.004
+
+AVX instruction VMOVDQU implementation error for YMM registers
diff --git a/results/classifier/zero-shot/108/device/1332234 b/results/classifier/zero-shot/108/device/1332234
new file mode 100644
index 00000000..92acb38b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1332234
@@ -0,0 +1,72 @@
+device: 0.945
+semantic: 0.903
+graphic: 0.838
+other: 0.833
+permissions: 0.821
+PID: 0.795
+vnc: 0.693
+performance: 0.692
+socket: 0.659
+boot: 0.643
+files: 0.639
+network: 0.621
+KVM: 0.555
+debug: 0.462
+
+qemu-system-ppc no longer able to read real cdrom
+
+When I use to send the -cdrom /dev/cdrom option to QEMU, I would be able to use a real cdrom. With QEMU v2.0.0, real cdroms don't work. A quick look at the output from the "info block" command shows this:
+
+ide1-cd0: /dev/cdrom (raw, read-only)
+      Removable device: not locked, tray closed
+
+This indicates that the cdrom is set to /dev/cdrom. I remember versions of QEMU prior to 1.5 were able to use a real cdrom. 
+
+qemu-system-ppc is being run on Mac OS 10.6.8.
+
+According to https://bugs.launchpad.net/qemu/+bug/588691 CD-ROM drives should be working again, so I assume we can close this bug nowadays? Or can you still reproduce it with the latest version of QEMU?
+
+
+> On Sep 24, 2018, at 5:14 AM, Thomas Huth <email address hidden> wrote:
+> 
+> According to https://bugs.launchpad.net/qemu/+bug/588691 CD-ROM drives
+> should be working again, so I assume we can close this bug nowadays? Or
+> can you still reproduce it with the latest version of QEMU?
+> 
+> ** Changed in: qemu
+>       Status: New => Incomplete
+
+
+I cannot reproduce this issue with QEMU. This report can now be closed. Thank you.
+
+
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1332234
+> 
+> Title:
+>  qemu-system-ppc no longer able to read real cdrom
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  When I use to send the -cdrom /dev/cdrom option to QEMU, I would be
+>  able to use a real cdrom. With QEMU v2.0.0, real cdroms don't work. A
+>  quick look at the output from the "info block" command shows this:
+> 
+>  ide1-cd0: /dev/cdrom (raw, read-only)
+>        Removable device: not locked, tray closed
+> 
+>  This indicates that the cdrom is set to /dev/cdrom. I remember
+>  versions of QEMU prior to 1.5 were able to use a real cdrom.
+> 
+>  qemu-system-ppc is being run on Mac OS 10.6.8.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1332234/+subscriptions
+
+
+
diff --git a/results/classifier/zero-shot/108/device/1342 b/results/classifier/zero-shot/108/device/1342
new file mode 100644
index 00000000..61a2cf19
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1342
@@ -0,0 +1,39 @@
+device: 0.933
+graphic: 0.860
+network: 0.811
+vnc: 0.707
+PID: 0.693
+socket: 0.622
+semantic: 0.577
+boot: 0.499
+other: 0.479
+performance: 0.474
+permissions: 0.429
+debug: 0.384
+files: 0.353
+KVM: 0.199
+
+Default machine setting of force-legacy=true causes problems for any modern VirtIO device using MMIO
+Description of problem:
+The default causes problems if you enable any non-legacy VirtIO device which has the VIRTIO_F_VERSION_1 feature bit will not properly read all feature bits. This is because reading VIRTIO_MMIO_VERSION returns VIRT_VERSION_LEGACY which in turn results in the driver not reading all feature bits, e.g. the qtest access:
+
+```
+static uint64_t qvirtio_mmio_get_features(QVirtioDevice *d)
+{
+    QVirtioMMIODevice *dev = container_of(d, QVirtioMMIODevice, vdev);
+    uint64_t lo;
+    uint64_t hi = 0;
+
+    qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 0);
+    lo = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES);
+
+    if (dev->version >= 2) {
+        qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 1);
+        hi = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES);
+    }
+
+    return (hi << 32) | lo;
+}
+```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/1346 b/results/classifier/zero-shot/108/device/1346
new file mode 100644
index 00000000..4af327df
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1346
@@ -0,0 +1,50 @@
+device: 0.940
+graphic: 0.929
+performance: 0.890
+debug: 0.791
+semantic: 0.785
+PID: 0.772
+files: 0.768
+socket: 0.706
+permissions: 0.690
+vnc: 0.683
+network: 0.653
+other: 0.629
+boot: 0.583
+KVM: 0.515
+
+simulate x86_64 virtio-gpu-gl qemu report error
+Description of problem:
+when I run the below command, it can run ok, and myos can get the virtio-gpu feature,but it less 3d feature.
+   ```
+   ./qemu-system-x86_64 -nographic -M q35 -m 1024 -cpu Nehalem -smp 8 -kernel myos -device virtio-gpu
+   ```
+so I delete ```-nographic``` and modify the device to :
+```
+-device virtio-gpu-gl -display sdl,gl=on
+```
+but qemu tells me ERROR:
+```
+qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed.
+```
+Additional information:
+I modify the code qemu/ui/sdl2-gl.c function sdl2_gl_switch():
+
+`    
+#if 0
+if (is_placeholder(new_surface) && qemu_console_get_index(dcl->con)) {
+        qemu_gl_fini_shader(scon->gls);
+        scon->gls = NULL;
+        sdl2_window_destroy(scon);
+        return;
+    }
+#endif
+`
+and, qemu can run myos with ```-nographic```, and i can get 3d feature:
+   ```
+   ./qemu-system-x86_64 -nographic -M q35 -m 1024 -cpu Nehalem -smp 8 -kernel myos -device virtio-gpu-gl -display sdl,gl=on
+   ```
+
+I think there is something bug.
+
+thanks
diff --git a/results/classifier/zero-shot/108/device/1354 b/results/classifier/zero-shot/108/device/1354
new file mode 100644
index 00000000..7ea7c589
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1354
@@ -0,0 +1,16 @@
+device: 0.976
+debug: 0.771
+performance: 0.741
+other: 0.655
+PID: 0.439
+semantic: 0.435
+graphic: 0.434
+permissions: 0.308
+network: 0.214
+vnc: 0.214
+boot: 0.200
+socket: 0.109
+files: 0.035
+KVM: 0.012
+
+-device usb-tablet not working on android guest.
diff --git a/results/classifier/zero-shot/108/device/1363 b/results/classifier/zero-shot/108/device/1363
new file mode 100644
index 00000000..3a1b9ac9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1363
@@ -0,0 +1,18 @@
+device: 0.946
+semantic: 0.941
+debug: 0.924
+performance: 0.859
+graphic: 0.828
+other: 0.777
+network: 0.586
+boot: 0.584
+PID: 0.549
+vnc: 0.520
+permissions: 0.435
+socket: 0.114
+KVM: 0.005
+files: 0.002
+
+TriCore: writing to registers is not working (as it's supposed to)
+Description of problem:
+Reading the tricore register list from QEMU works just fine. However, writing this registers is not working as expected. It looks like the bug is on QEMU's side, since third party gdb client faces the same issues.
diff --git a/results/classifier/zero-shot/108/device/1391 b/results/classifier/zero-shot/108/device/1391
new file mode 100644
index 00000000..8523dc6a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1391
@@ -0,0 +1,43 @@
+device: 0.944
+graphic: 0.720
+performance: 0.719
+files: 0.508
+PID: 0.442
+semantic: 0.414
+vnc: 0.344
+boot: 0.311
+debug: 0.303
+socket: 0.300
+network: 0.256
+other: 0.136
+permissions: 0.059
+KVM: 0.005
+
+virtio-blk: BDRV_REQ_REGISTERED_BUF optimization hint crashes on macOS
+Description of problem:
+When using QEMU 7.2.0 on macOS with the virtio-blk drive, the process will exit and QMP shows a `BLOCK_IO_ERROR` event. This appears to be caused by this line: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/block/virtio-blk.c#L405 introduced in https://gitlab.com/qemu-project/qemu/-/commit/baf422684d73c7bf38e2c18815e18d44fcf395b6
+
+Commenting that line out fixes the issue.
+Steps to reproduce:
+1. Run the QEMU command above with a Ubuntu 22.04 server ISO image.
+2. Follow the installer and try to get to the end.
+3. The process will crash before you can finish installing.
+Additional information:
+Following event appears on QMP:
+```
+{
+    data =     {
+        action = report;
+        device = "drive437EC806-41A4-4CCE-A747-713352E7C27C";
+        "node-name" = "#block785";
+        nospace = 0;
+        operation = write;
+        reason = "Invalid argument";
+    };
+    event = "BLOCK_IO_ERROR";
+    timestamp =     {
+        microseconds = 808474;
+        seconds = 1671867673;
+    };
+}
+```
diff --git a/results/classifier/zero-shot/108/device/1406 b/results/classifier/zero-shot/108/device/1406
new file mode 100644
index 00000000..5800e3b9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1406
@@ -0,0 +1,16 @@
+device: 0.960
+files: 0.939
+boot: 0.485
+performance: 0.477
+network: 0.215
+graphic: 0.166
+vnc: 0.143
+PID: 0.086
+socket: 0.082
+debug: 0.052
+permissions: 0.044
+other: 0.033
+semantic: 0.012
+KVM: 0.006
+
+WANTED: Schematics, Service, Tech Notes, .pdf  IBM Power4 970MP/FX Apple PowerMac G5 Early/Late 2005
diff --git a/results/classifier/zero-shot/108/device/1413 b/results/classifier/zero-shot/108/device/1413
new file mode 100644
index 00000000..b2437350
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1413
@@ -0,0 +1,37 @@
+device: 0.952
+graphic: 0.942
+KVM: 0.877
+performance: 0.864
+vnc: 0.800
+PID: 0.764
+boot: 0.722
+socket: 0.719
+debug: 0.657
+semantic: 0.639
+network: 0.594
+other: 0.575
+files: 0.560
+permissions: 0.430
+
+I tried to use qemu-nbd in the shell script, but it seems that qemu-nbd has some delay.
+Description of problem:
+
+Steps to reproduce:
+1.
+```
+cat ~/test.sh
+#!/bin/bash
+qemu-nbd -c /dev/nbd0 $1
+mount -t ntfs3 -o uid=1000,gid=1000 /dev/disk/by-label/OS /mnt/OS
+```
+2.
+```
+sudo ~/test.sh ~/VM/win7_i386.qcow2
+mount: /mnt/OS: special device /dev/disk/by-label/OS does not exist.
+       dmesg(1) may have more information after failed mount system call.
+
+```
+Additional information:
+But when I added a one-second delay between qemu-nbd and mount commands, the problem was solved.
+
+The qemu-img convert command also has a similar problem. It seems that these commands have a certain delay. Is this in line with expectations?
diff --git a/results/classifier/zero-shot/108/device/1445633 b/results/classifier/zero-shot/108/device/1445633
new file mode 100644
index 00000000..48b98230
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1445633
@@ -0,0 +1,34 @@
+device: 0.942
+performance: 0.937
+graphic: 0.926
+network: 0.766
+semantic: 0.740
+permissions: 0.686
+socket: 0.650
+other: 0.648
+vnc: 0.619
+PID: 0.615
+boot: 0.497
+debug: 0.487
+files: 0.340
+KVM: 0.192
+
+Creating a passthrough USB device causes excessive CPU usage in the guest
+
+My host machine is a Lenovo X1 Carbon (3rd gen) laptop running 64-bit Ubuntu Linux 14.04.  My guest machine is running 64-bit Ubuntu Linux 12.04.  My QEMU was compiled moments ago from the git repository, and it says its version is:
+qemu-x86_64 version 2.2.93, Copyright (c) 2003-2008 Fabrice Bellard
+
+My issue is that when I create a passthrough for a USB host device to the guest, it causes qemu's CPU utilization on the host to increase significantly and stay there.  After the passthrough is created, qemu's CPU usage in top hovers between 20% and 30% (evenly spread across CPUs).  In virt-manager's CPU usage chart, it shows the guest's CPU usage growing from 0% to about 5%, although running "top" in the guest does not show an increase in CPU usage.  These usage levels drop back down to normal (0 to 1%) only after I physically unplug the device or remove the passthrough mapping.
+
+It doesn't seem to matter what the device is.  I have tested it using:
+A Realtek rtl8192cu-based 802.11n adapter
+An HP optical mouse
+A Samsung Galaxy S5 phone
+
+The behavior is the same regardless of device, and they otherwise seem to work properly in the guest machine.
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1478 b/results/classifier/zero-shot/108/device/1478
new file mode 100644
index 00000000..60823294
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1478
@@ -0,0 +1,81 @@
+device: 0.925
+debug: 0.909
+graphic: 0.906
+other: 0.903
+vnc: 0.899
+boot: 0.894
+permissions: 0.892
+semantic: 0.888
+PID: 0.875
+performance: 0.864
+files: 0.860
+socket: 0.851
+KVM: 0.834
+network: 0.825
+
+Qemu 7.2.0 i386: core2: init crash (glibc)
+Description of problem:
+The toolchain-builder project (a side project of Buildroot to build pre-built toolchains) reported an issue with Qemu 7.2.0 for  x86-core2--glibc--bleeding-edge toolchain, see:
+
+https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337
+
+Reverting back to Qemu 7.1.0, the system boot correctly with the same system image.
+I reproduced the issue with the current Qemu master (6b433719eabf0abc74cff0cfd5687f0137c4198a)
+
+Here is the boot log obtained with Qemu 7.2.0:
+   ```
+Run /sbin/init as init process
+random: fast init done
+EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended
+EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
+Starting syslogd: OK
+traps: syslogd[52] general protection fault ip:b7e21465 sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000]
+Starting klogd: OK
+traps: klogd[56] general protection fault ip:b7e94465 sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000]
+Running sysctl: traps: logger[62] general protection fault ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000]
+Segmentation fault
+traps: logger[64] general protection fault ip:b7dd3b6c sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000]
+Segmentation fault
+
+traps: init[100] general protection fault ip:b7dda465 sp:bfd5f42c error:0 in libc.so.6[b7d54000+123000]
+Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+CPU: 0 PID: 1 Comm: init Not tainted 5.15.18 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
+Call Trace:
+ dump_stack_lvl+0x32/0x41
+ dump_stack+0xd/0x10
+ panic+0x90/0x206
+ do_exit.cold+0xa9/0xa9
+ do_group_exit+0x2a/0x90
+ get_signal+0x115/0x7e0
+ arch_do_signal_or_restart+0x90/0x5a0
+ ? put_pid+0xc/0x20
+ ? kernel_clone+0x10b/0x3d0
+ exit_to_user_mode_prepare+0xf8/0x1c0
+ syscall_exit_to_user_mode+0x1b/0x40
+ do_int80_syscall_32+0x41/0x90
+ entry_INT80_32+0xf0/0xf0
+EIP: 0xb7de5d88
+Code: 37 01 00 00 65 ff 15 10 00 00 00 89 d0 5a 5b 5e 5f 5d c3 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 59 b8 be 00 00 00 cd 80 <51> 3d 01 f0 ff ff 0f 83 06 e9 f6 ff c3 e8 81 a0 06 00 05 9a a0 0e
+EAX: 00000064 EBX: 0059aa1c ECX: 00561f5b EDX: 00000008
+ESI: 0059cc20 EDI: bfd5fa64 EBP: 0059b138 ESP: bfd5fa20
+DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
+Kernel Offset: disabled
+---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
+   ```
+I did a git bisect on qemu sources up to this commit:
+
+https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44
+Steps to reproduce:
+Build the Buildroot qemu_x86_defconfig with BR2_x86_core2 target architecture variant added manually
+1. git clone https://gitlab.com/buildroot.org/buildroot.git
+2. git switch --detach c419ef62d84b5be65599452ab84f7ed719bbe470
+3. make qemu_x86_defconfig
+4. make menuconfig (enable BR2_x86_core2)
+5. make
+6. ./output/images/start-qemu.sh
+Additional information:
+System built with gcc options:
+   ```
+i686-buildroot-linux-gnu-gcc.br_real' '--sysroot' 'output/host/i686-buildroot-linux-gnu/sysroot' '-fstack-protector-strong' '-fPIE' '-pie' '-Wl,-z,now' '-Wl,-z,relro'
+   ```
diff --git a/results/classifier/zero-shot/108/device/149 b/results/classifier/zero-shot/108/device/149
new file mode 100644
index 00000000..88a6711e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/149
@@ -0,0 +1,16 @@
+device: 0.980
+network: 0.953
+socket: 0.916
+performance: 0.914
+debug: 0.597
+PID: 0.480
+boot: 0.428
+other: 0.415
+graphic: 0.325
+permissions: 0.301
+semantic: 0.299
+files: 0.213
+vnc: 0.131
+KVM: 0.006
+
+vmxnet3 unable to send IPv6 ESP packets
diff --git a/results/classifier/zero-shot/108/device/1507 b/results/classifier/zero-shot/108/device/1507
new file mode 100644
index 00000000..897534a7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1507
@@ -0,0 +1,52 @@
+device: 0.942
+performance: 0.922
+files: 0.913
+graphic: 0.898
+PID: 0.896
+socket: 0.848
+network: 0.827
+semantic: 0.798
+vnc: 0.751
+debug: 0.686
+permissions: 0.648
+boot: 0.624
+other: 0.613
+KVM: 0.584
+
+export/fuse/fuse.c:fuse_fallocate does not do anything but returns success
+Description of problem:
+block/export/fuse.c:fuse_fallocate with `FALLOC_FL_PUNCH_HOLE` does not do anything even though it returns 0 (success). A later read incorrectly returns old data instead of zeros. 
+Should probably return EOPNOTSUPP.
+
+FALLOC_FL_PUNCH_HOLE:
+>Within the specified range, partial filesystem blocks are zeroed,
+and whole filesystem blocks are removed from the file.  After a
+successful call, subsequent reads from this range will return
+zeros.
+https://man7.org/linux/man-pages/man2/fallocate.2.html
+Steps to reproduce:
+```sh
+touch /tmp/data /tmp/fuse_exp 
+dd if=/dev/random of=/tmp/data count=1000 bs=1M
+qemu-storage-daemon --blockdev node-name=node0,driver=raw,file.driver=file,file.filename=/tmp/data --export type=fuse,id=node0-export,node-name=node0,mountpoint=/tmp/fuse_exp,writable=on
+
+hexdump /tmp/fuse_exp -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+fallocate -l 1G --punch-hole /tmp/fuse_exp
+echo $?
+# 0
+hexdump /tmp/fuse_exp -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+
+
+hexdump /tmp/data -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+fallocate -l 1G --punch-hole /tmp/data
+hexdump /tmp/data -n 16
+# 0000000 0000 0000 0000 0000 0000 0000 0000 0000
+
+# sudo bpftrace -e 'uretprobe:/usr/bin/qemu-storage-daemon:blk_co_pdiscard { printf("ret=%d\n",retval); }'
+# ret=0
+# sudo bpftrace -e 'kretfunc:fuse_file_fallocate { printf("len=%d \t mode=%d ret=%d\n", args->length , args->mode,retval); }'
+# len=1073741824   mode=3 ret=0
+```
diff --git a/results/classifier/zero-shot/108/device/1515 b/results/classifier/zero-shot/108/device/1515
new file mode 100644
index 00000000..c0aa3fd0
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1515
@@ -0,0 +1,33 @@
+device: 0.957
+graphic: 0.917
+PID: 0.853
+vnc: 0.834
+socket: 0.811
+semantic: 0.784
+performance: 0.772
+network: 0.769
+other: 0.687
+boot: 0.667
+debug: 0.536
+KVM: 0.531
+files: 0.500
+permissions: 0.472
+
+qemu have  the way to change the windows sid?
+Description of problem:
+I want to change the guest of windows sid after clone guest, have  the way to change it before new guest start? "virt-sysprep" Seems impossible to do it. Although it can be done manually as follow:
+
+[change sid in windows system](https://www.heelpbook.net/2019/microsoft-changing-sid-of-cloned-vms/)
+
+query windows sid:
+cmd: whoami /user
+
+
+step:
+1.clone a new windows guest vm_new
+
+2.change the sid of vm_new  (step2 I don't know how to do that)
+
+3.start vm_new
+
+4.query the vm_new's sid is change
diff --git a/results/classifier/zero-shot/108/device/1519 b/results/classifier/zero-shot/108/device/1519
new file mode 100644
index 00000000..1ac4d1fb
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1519
@@ -0,0 +1,27 @@
+device: 0.940
+performance: 0.863
+vnc: 0.841
+files: 0.768
+graphic: 0.740
+network: 0.722
+debug: 0.662
+permissions: 0.660
+boot: 0.533
+PID: 0.522
+semantic: 0.471
+socket: 0.456
+other: 0.387
+KVM: 0.247
+
+audio recording not working on qemu
+Description of problem:
+QEMU fails to record audio from the guest even when the device options hda-duplex and hda-micro options are used. Tried using the other available audio backends (alsa and sdl) but recording on the guest still fails
+Steps to reproduce:
+1. run the qemu command line above with any of the available audio backends
+2. record audio on the guest 
+3. arecord -vv -d 5 recordng.wav
+4. there's an attempt to record but it hangs
+5. play recorded audio, there's no output
+6. aplay recordng.wav
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/1564 b/results/classifier/zero-shot/108/device/1564
new file mode 100644
index 00000000..c8375e88
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1564
@@ -0,0 +1,85 @@
+device: 0.985
+graphic: 0.721
+performance: 0.648
+PID: 0.640
+socket: 0.469
+debug: 0.453
+network: 0.436
+boot: 0.394
+vnc: 0.297
+KVM: 0.249
+semantic: 0.229
+files: 0.136
+permissions: 0.125
+other: 0.047
+
+stat64 on sparc64 failed to get correct major/minor dev
+Description of problem:
+The reported device major/minor is not correct, e.g: stat /dev/zero:
+Reported: Device type: 0,10500000
+Correct : Device type: 1,5
+Steps to reproduce:
+1. "stat /dev/zero" or "ls -l /dev/zero"
+Additional information:
+The problem is a missing padding into target_stat64 struct related to sparc64. Here patch to solve the issue (it also fixes some incorrect variables size):
+
+```
+--- qemu-20230327/linux-user/syscall_defs.h	2023-03-27 15:41:42.000000000 +0200
++++ qemu-20230327/linux-user/syscall_defs.h.new	2023-03-27 21:43:25.615115126 +0200
+@@ -1450,7 +1450,7 @@ struct target_stat {
+ 	unsigned int	st_dev;
+ 	abi_ulong	st_ino;
+ 	unsigned int	st_mode;
+-	unsigned int	st_nlink;
++	short int	st_nlink;
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 	unsigned int	st_rdev;
+@@ -1465,8 +1465,7 @@ struct target_stat {
+ 
+ #define TARGET_HAS_STRUCT_STAT64
+ struct target_stat64 {
+-	unsigned char	__pad0[6];
+-	unsigned short	st_dev;
++	uint64_t	st_dev;
+ 
+ 	uint64_t	st_ino;
+ 	uint64_t	st_nlink;
+@@ -1476,14 +1475,13 @@ struct target_stat64 {
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 
+-	unsigned char	__pad2[6];
+-	unsigned short	st_rdev;
++	unsigned int	__pad0;
++	uint64_t	st_rdev;
+ 
+         int64_t		st_size;
+ 	int64_t		st_blksize;
+ 
+-	unsigned char	__pad4[4];
+-	unsigned int	st_blocks;
++	int64_t		st_blocks;
+ 
+ 	abi_ulong	target_st_atime;
+ 	abi_ulong	target_st_atime_nsec;
+@@ -1522,8 +1520,7 @@ struct target_stat {
+ 
+ #define TARGET_HAS_STRUCT_STAT64
+ struct target_stat64 {
+-	unsigned char	__pad0[6];
+-	unsigned short	st_dev;
++	uint64_t st_dev;
+ 
+ 	uint64_t st_ino;
+ 
+@@ -1533,8 +1530,7 @@ struct target_stat64 {
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 
+-	unsigned char	__pad2[6];
+-	unsigned short	st_rdev;
++	uint64_t        st_rdev;
+ 
+ 	unsigned char	__pad3[8];
+```
diff --git a/results/classifier/zero-shot/108/device/157 b/results/classifier/zero-shot/108/device/157
new file mode 100644
index 00000000..acc14560
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/157
@@ -0,0 +1,16 @@
+device: 0.930
+performance: 0.778
+socket: 0.443
+graphic: 0.412
+semantic: 0.352
+debug: 0.345
+other: 0.299
+vnc: 0.297
+permissions: 0.257
+boot: 0.245
+PID: 0.190
+network: 0.093
+KVM: 0.040
+files: 0.019
+
+Xbox One controller USB passthrough disconnections and stops
diff --git a/results/classifier/zero-shot/108/device/1574 b/results/classifier/zero-shot/108/device/1574
new file mode 100644
index 00000000..d3af878a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1574
@@ -0,0 +1,104 @@
+device: 0.974
+permissions: 0.959
+graphic: 0.956
+debug: 0.955
+performance: 0.954
+other: 0.954
+semantic: 0.954
+KVM: 0.953
+files: 0.943
+boot: 0.933
+socket: 0.914
+PID: 0.913
+network: 0.898
+vnc: 0.882
+
+The guest paused after living migration on destination host, vm-entry error code 0x80000021
+Description of problem:
+The guest start on source host, then living migration to destination host, the guest status is pausing.   
+source host CPU: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz     
+destination host CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz   
+If the guest migration from E5-2650 to Silver 4114, the guest runs normally without pausing.
+Steps to reproduce:
+1. start guest, on source host, host CPU: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz.
+2. living migration guest to destination host, host CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz.
+3. migration finished, the guest pausing.
+Additional information:
+/label ~"kind::Bug"
+qemu log:
+```
+KVM: entry failed, hardware error 0x80000021
+
+If you're running a guest on an Intel machine without unrestricted mode
+support, the failure can be most likely due to the guest entering an invalid
+state for Intel VT. For example, the guest maybe running in big real mode
+which is not supported on less recent Intel processors.
+
+EAX=94d14da0 EBX=95341e20 ECX=00000000 EDX=00000000
+ESI=00000000 EDI=00000046 EBP=95203eb0 ESP=95203eb0
+EIP=94d14f76 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+```
+host log:
+```
+kernel: [228693.951391] *** Guest State ***
+kernel: [228693.951411] CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
+kernel: [228693.951422] CR4: actual=0x0000000000002040, shadow=0x0000000000000000, gh_mask=fffffffffffff871
+kernel: [228693.951430] CR3 = 0x0000000000000000
+kernel: [228693.951437] PDPTR0 = 0x0000000000000000  PDPTR1 = 0x0000000000000000
+kernel: [228693.951445] PDPTR2 = 0x0000000000000000  PDPTR3 = 0x0000000000000000
+kernel: [228693.951452] RSP = 0xffffffff95203eb0  RIP = 0xffffffff94d14f76
+kernel: [228693.951459] RFLAGS=0x00000286         DR7 = 0x0000000000000400
+kernel: [228693.951467] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
+kernel: [228693.951476] CS:   sel=0xf000, attr=0x0009b, limit=0x0000ffff, base=0x00000000ffff0000
+kernel: [228693.951485] DS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951494] SS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951502] ES:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951510] FS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951519] GS:   sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951527] GDTR:                           limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951537] LDTR: sel=0x0000, attr=0x00082, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951545] IDTR:                           limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951553] TR:   sel=0x0000, attr=0x0008b, limit=0x0000ffff, base=0x0000000000000000
+kernel: [228693.951562] EFER =     0x0000000000000000  PAT = 0x0007040600070406
+kernel: [228693.951569] DebugCtl = 0x0000000000000000  DebugExceptions = 0x0000000000000000
+kernel: [228693.951578] Interruptibility = 00000000  ActivityState = 00000000
+kernel: [228693.951586] InterruptStatus = 00b1
+kernel: [228693.951591] *** Host State ***
+kernel: [228693.951597] RIP = 0xffffffffc4b064ff  RSP = 0xffffaf14ccf87d10
+kernel: [228693.951606] CS=0010 SS=0018 DS=0000 ES=0000 FS=0000 GS=0000 TR=0040
+kernel: [228693.951614] FSBase=00007f0b2657a640 GSBase=ffff9c083f580000 TRBase=fffffe00001a0000
+kernel: [228693.951623] GDTBase=fffffe000019e000 IDTBase=fffffe0000000000
+kernel: [228693.951631] CR0=0000000080050033 CR3=000000029800c004 CR4=00000000003726e0
+kernel: [228693.951639] Sysenter RSP=fffffe00001a0000 CS:RIP=0010:ffffffff95801590
+kernel: [228693.951648] EFER = 0x0000000000000d01  PAT = 0x0407050600070106
+kernel: [228693.951655] *** Control State ***
+kernel: [228693.951662] CPUBased=0xb5a06dfa SecondaryExec=0x00032ff2 TertiaryExec=0x0000000000000000
+kernel: [228693.951671] PinBased=0x000000ff EntryControls=0000d1ff ExitControls=002befff
+kernel: [228693.951679] ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000
+kernel: [228693.951686] VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000
+kernel: [228693.951695] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000
+kernel: [228693.951702]         reason=80000021 qualification=0000000000000000
+kernel: [228693.951709] IDTVectoring: info=00000000 errcode=00000000
+kernel: [228693.951717] TSC Offset = 0xfffe2c437c9ab552
+kernel: [228693.951724] SVI|RVI = 00|b1 TPR Threshold = 0x00
+kernel: [228693.951734] virt-APIC addr = 0x00000002a3014000
+kernel: [228693.951736] PostedIntrVec = 0xf2
+kernel: [228693.951743] EPT pointer = 0x000000012dfe705e
+kernel: [228693.951749] PLE Gap=00000080 Window=00001000
+kernel: [228693.951755] Virtual processor ID = 0x0009
+```
diff --git a/results/classifier/zero-shot/108/device/1581308 b/results/classifier/zero-shot/108/device/1581308
new file mode 100644
index 00000000..119dc59a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1581308
@@ -0,0 +1,40 @@
+device: 0.966
+vnc: 0.918
+graphic: 0.893
+PID: 0.861
+network: 0.823
+KVM: 0.788
+files: 0.772
+socket: 0.753
+other: 0.745
+performance: 0.722
+boot: 0.711
+permissions: 0.706
+semantic: 0.645
+debug: 0.477
+
+ohci doesn't check the 'num-ports' property
+
+command:
+qemu-system-x86_64 -m 1024 -enable-kvm /root/centos6.img -enable-kvm -device pci-ohci,num-ports=100,masterbus=1
+
+The ohci doesn't check the 'num-ports' property and would case an out-of-bands write,crash the qemu process.
+
+    ohci->num_ports = num_ports;
+    if (masterbus) {
+        USBPort *ports[OHCI_MAX_PORTS];
+        for(i = 0; i < num_ports; i++) {
+            ports[i] = &ohci->rhport[i].port;
+        }
+
+The version of qemu is 2.6.0 release from 
+http://wiki.qemu-project.org/download/qemu-2.6.0.tar.bz2
+
+I was able to reproduce the crash, and proposed now a fix on the qemu-devel mailing list (see https://patchwork.ozlabs.org/patch/625092/ for details)
+
+The fix has been included in the repository:
+
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d400fc018b326104d26
+
+Thanks for reporting the issue!
+
diff --git a/results/classifier/zero-shot/108/device/1581976 b/results/classifier/zero-shot/108/device/1581976
new file mode 100644
index 00000000..0f6ed4d3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1581976
@@ -0,0 +1,37 @@
+device: 0.964
+vnc: 0.848
+socket: 0.837
+network: 0.693
+graphic: 0.664
+other: 0.506
+semantic: 0.496
+boot: 0.396
+files: 0.382
+performance: 0.366
+debug: 0.325
+KVM: 0.310
+PID: 0.260
+permissions: 0.065
+
+man qemu contains a bug in description of "-virtfs" command line argument
+
+The description of command line argument looks like this:
+
+ -virtfs
+       fsdriver[,path=path],mount_tag=mount_tag[,security_model=security_model][,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd]
+
+
+note, that there is no "id" attribute in the list of parameters.
+
+later on the man there the "id" attribute is documented, as it were present:
+
+           id=id
+               Specifies identifier for this device
+
+i think that it was copied from above section (about "-fsdev") without reviewing.
+
+Fixed by the following commit:
+
+https://github.com/qemu/qemu/commit/b44a6b09705e9e8a3005229b58de36d176020548
+
+
diff --git a/results/classifier/zero-shot/108/device/1586613 b/results/classifier/zero-shot/108/device/1586613
new file mode 100644
index 00000000..17062230
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1586613
@@ -0,0 +1,29 @@
+device: 0.952
+KVM: 0.926
+vnc: 0.891
+performance: 0.884
+other: 0.862
+graphic: 0.843
+semantic: 0.803
+network: 0.782
+PID: 0.769
+permissions: 0.746
+socket: 0.730
+debug: 0.564
+files: 0.562
+boot: 0.466
+
+usb-hub can not be detached when detach usbdevice  VM
+
+I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）.
+when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists.
+It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that:
+
+2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0
+
+2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument  
+
+From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows:
+libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know
+libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle
+
diff --git a/results/classifier/zero-shot/108/device/1629618 b/results/classifier/zero-shot/108/device/1629618
new file mode 100644
index 00000000..39f5dfdd
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1629618
@@ -0,0 +1,126 @@
+device: 0.932
+permissions: 0.908
+other: 0.902
+debug: 0.891
+performance: 0.887
+boot: 0.881
+socket: 0.879
+semantic: 0.875
+network: 0.852
+KVM: 0.852
+files: 0.843
+graphic: 0.827
+PID: 0.817
+vnc: 0.800
+
+QEMU causes host hang / reset on PPC64EL
+
+QEMU causes a host hang / reset on PPC64EL when used in KVM + HV mode (kvm_hv module).
+
+After a random amount of uptime, starting new QEMU virtual machines will cause the host to experience a soft CPU lockup.  Depending on configuration and other random factors the host will either checkstop and reboot, or hang indefinitely.  The following stacktrace was pulled from an instance where the host simply hung after starting a fourth virtual machine.
+
+Command line:
+
+qemu-system-ppc64 --enable-kvm -name pbuild-vnode001 -M pseries -cpu host -smp 14,cores=14,threads=1,sockets=1 -m 64G -realtime mlock=on -kernel vmlinux-4.7.0-1-powerpc64le -initrd initrd.img-4.7.0-1-powerpc64le
+
+Lockup trace:
+
+[  527.393933] KVM guest htab at c000003ae4000000 (order 29), LPID 4
+[  574.637695] INFO: rcu_sched self-detected stall on CPU
+[  574.637799] 	112-...: (5249 ticks this GP) idle=699/140000000000001/0 softirq=5358/5382 fqs=5072 
+[  574.637877] 	 (t=5250 jiffies g=19853 c=19852 q=64401)
+[  574.637947] Task dump for CPU 112:
+[  574.637982] qemu-system-ppc R  running task        0 12037  11828 0x00040004
+[  574.638051] Call Trace:
+[  574.638081] [c000001c1cddb430] [c0000000000f2710] sched_show_task+0xe0/0x180 (unreliable)
+[  574.638164] [c000001c1cddb4a0] [c0000000001326f4] rcu_dump_cpu_stacks+0xe4/0x150
+[  574.638246] [c000001c1cddb4f0] [c000000000137a04] rcu_check_callbacks+0x6b4/0x9c0
+[  574.638328] [c000001c1cddb610] [c00000000013f7c4] update_process_times+0x54/0xa0
+[  574.638409] [c000001c1cddb640] [c000000000156c28] tick_sched_handle.isra.5+0x48/0xe0
+[  574.638489] [c000001c1cddb680] [c000000000156d24] tick_sched_timer+0x64/0xd0
+[  574.638602] [c000001c1cddb6c0] [c000000000140274] __hrtimer_run_queues+0x124/0x420
+[  574.638683] [c000001c1cddb750] [c00000000014123c] hrtimer_interrupt+0xec/0x2c0
+[  574.638765] [c000001c1cddb810] [c00000000001fe5c] __timer_interrupt+0x8c/0x270
+[  574.638847] [c000001c1cddb860] [c00000000002053c] timer_interrupt+0x9c/0xe0
+[  574.638915] [c000001c1cddb890] [c000000000002750] decrementer_common+0x150/0x180
+[  574.639001] --- interrupt: 901 at kvmppc_hv_get_dirty_log+0x1c4/0x570 [kvm_hv]
+[  574.639001]     LR = kvmppc_hv_get_dirty_log+0x1f8/0x570 [kvm_hv]
+[  574.639114] [c000001c1cddbc30] [d00000001a524980] kvm_vm_ioctl_get_dirty_log_hv+0xd0/0x170 [kvm_hv]
+[  574.639209] [c000001c1cddbc80] [d00000001a4d4140] kvm_vm_ioctl_get_dirty_log+0x40/0x60 [kvm]
+[  574.639291] [c000001c1cddbcb0] [d00000001a4ca3cc] kvm_vm_ioctl+0x3fc/0x760 [kvm]
+[  574.639372] [c000001c1cddbd40] [c0000000002d9e18] do_vfs_ioctl+0xd8/0x8e0
+[  574.639442] [c000001c1cddbde0] [c0000000002da6f4] SyS_ioctl+0xd4/0xf0
+[  574.639512] [c000001c1cddbe30] [c000000000009260] system_call+0x38/0x108
+[  580.601573] NMI watchdog: BUG: soft lockup - CPU#112 stuck for 22s! [qemu-system-ppc:12037]
+[  580.601655] Modules linked in: xt_tcpudp(E) rpcsec_gss_krb5(E) nfsv4(E) dns_resolver(E) ext4(E) ecb(E) crc16(E) jbd2(E) mbcache(E) tun(E) btrfs(E) crc32c_generic(E) raid6_pq(E) xor(E) dm_crypt(E) xts(E) gf128mul(E) algif_skcipher(E) af_alg(E) dm_mod(E) bonding(E) cpufreq_stats(E) iptable_filter(E) ip_tables(E) x_tables(E) bridge(E) stp(E) llc(E) ipmi_devintf(E) ipmi_msghandler(E) i2c_dev(E) fuse(E) raid1(E) md_mod(E) ses(E) sd_mod(E) enclosure(E) sg(E) binfmt_misc(E) radeon(E) ttm(E) drm_kms_helper(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) drm(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) snd_timer(E) evdev(E) i2c_algo_bit(E) snd(E) soundcore(E) at24(E) ahci(E) mpt3sas(E) nvmem_core(E) libahci(E) raid_class(E) scsi_transport_sas(E) powernv_rng(E) rng_core(E) uinput(E) kvm_hv(E) kvm(E) ib_srp(E) scsi_transport_srp(E) ofpart(E) powernv_flash(E) mtd(E) nfsd(E) opal_prd(E) auth_rpcgss(E) parport_pc(E) lp(E) parport(E) autofs4(E) nfsv3(E) nfs_acl(E) nfs(E) lockd(E) grace(E) sunrpc(E) fscache(E) ib_ipoib(E) ib_umad(E) rdma_ucm(E) ib_uverbs(E) rdma_cm(E) iw_cm(E) ib_cm(E) ib_sa(E) configfs(E) hid_generic(E) usbhid(E) hid(E) xhci_pci(E) xhci_hcd(E) usbcore(E) tg3(E) usb_common(E) ptp(E) pps_core(E) libphy(E) ib_mthca(E) ib_mad(E) ib_core(E) ib_addr(E)
+[  580.603295] CPU: 112 PID: 12037 Comm: qemu-system-ppc Tainted: G            E   4.6.0-2-powerpc64le #1 Debian 4.6.3-1
+[  580.603386] task: c000001f706f0180 ti: c000001c1cdd8000 task.ti: c000001c1cdd8000
+[  580.603456] NIP: d00000001a52cb54 LR: d00000001a52cb88 CTR: 0000000000000000
+[  580.603524] REGS: c000001c1cddb900 TRAP: 0901   Tainted: G            E    (4.6.0-2-powerpc64le Debian 4.6.3-1)
+[  580.603613] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 24048444  XER: 00000000
+[  580.603784] CFAR: d00000001a52cb18 SOFTE: 1 
+GPR00: d00000001a52cb88 c000001c1cddbb80 d00000001a53c580 40016e77790fe611 
+GPR04: 0000000beceac194 00000000019a4544 0000000000000001 0000000000000000 
+GPR08: 4000000000000000 0000000000000000 0000000000000001 8000000101a9b824 
+GPR12: c00000000009aea0 c00000000fbbf000 
+[  580.604205] NIP [d00000001a52cb54] kvmppc_hv_get_dirty_log+0x1c4/0x570 [kvm_hv]
+[  580.604274] LR [d00000001a52cb88] kvmppc_hv_get_dirty_log+0x1f8/0x570 [kvm_hv]
+[  580.604341] Call Trace:
+[  580.604366] [c000001c1cddbb80] [d00000001a52cb88] kvmppc_hv_get_dirty_log+0x1f8/0x570 [kvm_hv] (unreliable)
+[  580.604469] [c000001c1cddbc30] [d00000001a524980] kvm_vm_ioctl_get_dirty_log_hv+0xd0/0x170 [kvm_hv]
+[  580.604562] [c000001c1cddbc80] [d00000001a4d4140] kvm_vm_ioctl_get_dirty_log+0x40/0x60 [kvm]
+[  580.604685] [c000001c1cddbcb0] [d00000001a4ca3cc] kvm_vm_ioctl+0x3fc/0x760 [kvm]
+[  580.604765] [c000001c1cddbd40] [c0000000002d9e18] do_vfs_ioctl+0xd8/0x8e0
+[  580.604837] [c000001c1cddbde0] [c0000000002da6f4] SyS_ioctl+0xd4/0xf0
+[  580.604906] [c000001c1cddbe30] [c000000000009260] system_call+0x38/0x108
+[  580.604977] Instruction dump:
+[  580.605012] 2ba90003 419effc4 7fa97000 419effbc 81314310 2f890000 409effb0 7d00b0a8 
+[  580.605127] 7d09a039 40820014 7d08a378 7d00b1ad <41e20008> 7e89a378 4c00012c 2fa90000 
+[  637.648374] INFO: rcu_sched self-detected stall on CPU
+[  637.648473] 	112-...: (21002 ticks this GP) idle=699/140000000000001/0 softirq=5358/5382 fqs=20825 
+[  637.648554] 	 (t=21003 jiffies g=19853 c=19852 q=260741)
+[  637.648612] Task dump for CPU 112:
+[  637.648646] qemu-system-ppc R  running task        0 12037  11828 0x00040004
+[  637.648719] Call Trace:
+[  637.648745] [c000001c1cddb430] [c0000000000f2710] sched_show_task+0xe0/0x180 (unreliable)
+[  637.648825] [c000001c1cddb4a0] [c0000000001326f4] rcu_dump_cpu_stacks+0xe4/0x150
+[  637.648903] [c000001c1cddb4f0] [c000000000137a04] rcu_check_callbacks+0x6b4/0x9c0
+[  637.648985] [c000001c1cddb610] [c00000000013f7c4] update_process_times+0x54/0xa0
+[  637.649067] [c000001c1cddb640] [c000000000156c28] tick_sched_handle.isra.5+0x48/0xe0
+[  637.649147] [c000001c1cddb680] [c000000000156d24] tick_sched_timer+0x64/0xd0
+[  637.649216] [c000001c1cddb6c0] [c000000000140274] __hrtimer_run_queues+0x124/0x420
+[  637.649296] [c000001c1cddb750] [c00000000014123c] hrtimer_interrupt+0xec/0x2c0
+[  637.649374] [c000001c1cddb810] [c00000000001fe5c] __timer_interrupt+0x8c/0x270
+[  637.649456] [c000001c1cddb860] [c00000000002053c] timer_interrupt+0x9c/0xe0
+[  637.649525] [c000001c1cddb890] [c000000000002750] decrementer_common+0x150/0x180
+[  637.649645] --- interrupt: 901 at kvmppc_hv_get_dirty_log+0x1c4/0x570 [kvm_hv]
+[  637.649645]     LR = kvmppc_hv_get_dirty_log+0x1f8/0x570 [kvm_hv]
+[  637.649760] [c000001c1cddbc30] [d00000001a524980] kvm_vm_ioctl_get_dirty_log_hv+0xd0/0x170 [kvm_hv]
+[  637.649854] [c000001c1cddbc80] [d00000001a4d4140] kvm_vm_ioctl_get_dirty_log+0x40/0x60 [kvm]
+[  637.649936] [c000001c1cddbcb0] [d00000001a4ca3cc] kvm_vm_ioctl+0x3fc/0x760 [kvm]
+[  637.650014] [c000001c1cddbd40] [c0000000002d9e18] do_vfs_ioctl+0xd8/0x8e0
+[  637.650083] [c000001c1cddbde0] [c0000000002da6f4] SyS_ioctl+0xd4/0xf0
+[  637.650153] [c000001c1cddbe30] [c000000000009260] system_call+0x38/0x108
+
+Host QEMU version: 1:2.6+dfsg-3.1
+Host kernel version: 4.6.0
+
+Hi Timothy, sounds like this is a KVM (i.e. kernel) problem which might not directly be related to QEMU. So you likely should report this bug in the kernel bug tracker of your distro instead. Anyway, I've got some questions:
+
+1) Can you always reproduce this problem after a while, or does it occur only very seldom? Is there something special going on in the guest or host at that point in time or is it rather random?
+
+2) Could you please check whether you can reproduce this problem with the latest upstream kernel v4.8 in the host and guest? There have been some fixes recently that could be related to this problem (e.g. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=135e8c9250dd5c8c9a)
+
+3) Can you reproduce this bug when using the latest version of QEMU (v2.7) in the host?
+
+After running 4.8 for the past week or so I think I can state the problem is resolved at this point.  The machine has not hard reset once since the update, even after numerous host and VM reboots.
+
+Unfortunately, the machine just crashed again.  It seems related to the use of 4K pages instead of the more typical 64K pages; the machine is rock solid with 64K pages.
+
+Still seeing this issue.  Only seems to happen with 4K pages on the host.  Any further debugging I could try?
+
+No idea (apart from asking why're you're still using 4k pages on the host - hardly anybody seems to do that anymore).
+Anyway, this sounds like a kernel bug, not a QEMU problem, so you should try to get help via the kernel bug tracker or the KVM mailing list instead.
+
+Closing, since this is a kernel problem, not a QEMU problem.
+
diff --git a/results/classifier/zero-shot/108/device/1634852 b/results/classifier/zero-shot/108/device/1634852
new file mode 100644
index 00000000..04c51cb1
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1634852
@@ -0,0 +1,64 @@
+device: 0.929
+performance: 0.899
+network: 0.886
+PID: 0.870
+graphic: 0.843
+permissions: 0.835
+files: 0.796
+socket: 0.787
+vnc: 0.782
+KVM: 0.777
+debug: 0.730
+other: 0.656
+boot: 0.652
+semantic: 0.443
+
+Qemu VirtFS mounts are not accessible after resuming guest from hibernation
+
+Host OS:  Funtoo Linux
+Host Kernel:  4.7.4-gentoo
+Qemu Version:  2.7.0
+Guest OS:  Ubuntu 14.04
+Guest Kernel:  reproduced with both 4.4.0-42-generic and 3.13.0-98-generic
+
+Qemu command line:
+
+qemu-system-x86_64 \
+    -machine type=pc,accel=kvm \
+    -cpu host \
+    -smp 3 \
+    -m 8G \
+    -netdev bridge,id=hn0,vhost=on \
+    -device virtio-net-pci,netdev=hn0,mac=52:54:fa:70:35:f7 \
+    -drive file=/dev/mapper/vg-ubuntu,format=raw,if=virtio,cache=none,discard=on \
+    -virtfs local,path=/home/dharding/code,security_model=passthrough,mount_tag=code \
+    -virtfs local,path=/home/dharding/xfer,security_model=passthrough,mount_tag=xfer \
+    -display gtk
+
+
+Relevant lines from guest /etc/fstab:
+code /home/dharding/code 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0
+xfer /home/dharding/xfer 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0
+
+
+Steps to reproduce:
+- start qemu using the above command line
+- in the guest, run "sudo pm-hibernate"
+- after qemu exits, run again using the same command line
+- once the guest resumes from hibernation, run "ls /home/dharding/code"
+- the ls command will hang forever
+
+The ls call stack is:
+
+[<ffffffffc00743a0>] p9_client_rpc+0x110/0x460 [9pnet]
+[<ffffffffc0076a50>] p9_client_getattr_dotl+0x60/0x160 [9pnet]
+[<ffffffffc009ef77>] v9fs_vfs_getattr_dotl+0x47/0xa0 [9p]
+[<ffffffff81202a5c>] vfs_getattr_nosec+0x2c/0x40
+[<ffffffff81202b26>] vfs_getattr+0x26/0x30
+[<ffffffff81202bf5>] vfs_fstatat+0x65/0xa0
+[<ffffffff8120306f>] SYSC_newstat+0x1f/0x40
+[<ffffffff812032be>] SyS_newstat+0xe/0x10
+[<ffffffff817fa4f6>] entry_SYSCALL_64_fastpath+0x16/0x75
+
+The root cause lies in the 9pnet_virtio driver in the guest kernel: it does not support suspend/hibernation...
+
diff --git a/results/classifier/zero-shot/108/device/1637974 b/results/classifier/zero-shot/108/device/1637974
new file mode 100644
index 00000000..802fe0c3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1637974
@@ -0,0 +1,99 @@
+device: 0.940
+permissions: 0.936
+semantic: 0.928
+other: 0.926
+PID: 0.923
+graphic: 0.916
+files: 0.912
+network: 0.887
+performance: 0.881
+vnc: 0.871
+KVM: 0.870
+boot: 0.852
+debug: 0.849
+socket: 0.809
+
+dead code in pl080 functions
+
+pl080 is arm dma controller virtual device.
+source code path: hw/dma/pl080.c
+I find there are two same dead code in pl080_read and pl080_write,
+Here's the code, comments are my opinion:
+=========================
+240 static uint64_t pl080_read(void *opaque, hwaddr offset,
+241                            unsigned size)
+242 {
+243     PL080State *s = (PL080State *)opaque;
+244     uint32_t i;
+245     uint32_t mask;
+246 
+247     if (offset >= 0xfe0 && offset < 0x1000) {
+248         if (s->nchannels == 8) {
+249             return pl080_id[(offset - 0xfe0) >> 2];
+250         } else {
+251             return pl081_id[(offset - 0xfe0) >> 2];
+252         }
+253     }
+254     if (offset >= 0x100 && offset < 0x200) {   //// here offset is limited in 0x100~0x200
+255         i = (offset & 0xe0) >> 5;
+256         if (i >= s->nchannels)
+257             goto bad_offset;
+258         switch (offset >> 2) {                 //// then here, offset>>2 is in range  64~128
+259         case 0: /* SrcAddr */                  //// while the switch case is 0,1,2,3,4,
+260             return s->chan[i].src;             //// so, NONE of the switch case would be selected !
+261         case 1: /* DestAddr */                 //// this switch is A DEAD CODE, it is contradictory with if.
+262             return s->chan[i].dest;
+263         case 2: /* LLI */
+264             return s->chan[i].lli;
+265         case 3: /* Control */
+266             return s->chan[i].ctrl;
+267         case 4: /* Configuration */
+268             return s->chan[i].conf;
+269         default:
+270             goto bad_offset;
+271         }
+272     }
+        .....................................
+=============================================
+
+I guess, switch statement should like this :
+switch((offset-0x100)>>2)
+{
+...
+}
+
+On 31 October 2016 at 10:48, jeyyej <email address hidden> wrote:
+> Public bug reported:
+>
+> pl080 is arm dma controller virtual device.
+> source code path: hw/dma/pl080.c
+> I find there are two same dead code in pl080_read and pl080_write,
+
+> + if this DEADCODE is not the author's original purpose,
+> + Then there must be something in logic goes wrong, pl080 have NEVER works correctly ?
+
+Yes, this code is incorrect. However the only registers
+affected are those that set up the DMA channels, and
+the code for actually doing DMA transfers will assert if
+the guest ever tries to use it (see the hw_error() call in
+pl080_run()), so even if the guest could set up the DMA
+channels it would run into problems later.
+
+This device is only used in the versatilepb board, and
+I don't think Linux attempts to use it for DMA, so nobody's
+ever needed to care that it's actually totally broken
+for anything beyond "shouldn't crash the kernel when it
+tries to probe for and initialize it".
+
+thanks
+-- PMM
+
+
+@Peter Maydell Oh, I see, but would you try to fix this code ?
+
+I have no requirement for a working pl080, since I have no guest code that requires one. If somebody else (you?) wants to send a patch that fixes it, I'm happy to review it.
+
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=156448ab640baaeca18
+
diff --git a/results/classifier/zero-shot/108/device/1660035 b/results/classifier/zero-shot/108/device/1660035
new file mode 100644
index 00000000..6bfff2ee
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1660035
@@ -0,0 +1,53 @@
+device: 0.950
+performance: 0.805
+socket: 0.748
+network: 0.742
+semantic: 0.691
+vnc: 0.651
+PID: 0.634
+other: 0.593
+files: 0.587
+graphic: 0.563
+permissions: 0.538
+boot: 0.486
+debug: 0.443
+KVM: 0.350
+
+hw/timer/altera_timer.c:207: bad size in memset ?
+
+hw/timer/altera_timer.c:207:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
+
+Source code is
+
+     memset(t->regs, 0, ARRAY_SIZE(t->regs));
+
+Maybe better code
+
+     memset(t->regs, 0, R_MAX * sizeof( uint32_t));
+
+On 28 January 2017 at 13:16, dcb <email address hidden> wrote:
+> Public bug reported:
+>
+> hw/timer/altera_timer.c:207:5: warning: ‘memset’ used with length equal
+> to number of elements without multiplication by element size [-Wmemset-
+> elt-size]
+>
+> Source code is
+>
+>      memset(t->regs, 0, ARRAY_SIZE(t->regs));
+>
+> Maybe better code
+>
+>      memset(t->regs, 0, R_MAX * sizeof( uint32_t));
+
+Better still -- just memset(t->regs, 0, sizeof(t->regs));
+
+Chris, could you send a patch to fix this, please?
+
+thanks
+-- PMM
+
+
+This problem should have been fixed with QEMU v2.10.0:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc16ee9d4ecec35ea04e
+
diff --git a/results/classifier/zero-shot/108/device/1661 b/results/classifier/zero-shot/108/device/1661
new file mode 100644
index 00000000..20092622
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1661
@@ -0,0 +1,26 @@
+device: 0.958
+other: 0.726
+graphic: 0.410
+semantic: 0.401
+boot: 0.381
+files: 0.291
+permissions: 0.267
+vnc: 0.248
+debug: 0.246
+socket: 0.240
+performance: 0.225
+PID: 0.208
+network: 0.161
+KVM: 0.037
+
+x86 cpu support request: LX Geode
+Description of problem:
+The Geode LX family of CPUs were used in early generations of the One Laptop Per Child (OLPC) systems (XO 1.0).
+
+They are _basically_ i686-compatible but they lack the 'long-nop' (0x0f 0x1f) instruction available on many other i686-class devices.
+
+Since i686 is a reasonably common baseline for toolchains and the software that is distributed using those toolchains, it would be convenient to be able to use QEMU to test boundary compatibility cases for this CPU.
+Steps to reproduce:
+N/A - feature does not currently exist
+Additional information:
+I'm not adding additional context here at the moment, but please let me know what else would be helpful to know (and/or if I'm off-track with this feature request for any reason).  Thank you!
diff --git a/results/classifier/zero-shot/108/device/1663 b/results/classifier/zero-shot/108/device/1663
new file mode 100644
index 00000000..3a76998e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1663
@@ -0,0 +1,49 @@
+device: 0.957
+graphic: 0.936
+files: 0.877
+semantic: 0.876
+PID: 0.849
+performance: 0.849
+vnc: 0.776
+network: 0.748
+socket: 0.741
+permissions: 0.723
+debug: 0.663
+KVM: 0.660
+other: 0.646
+boot: 0.632
+
+make check-venv fails with errors about incompatible avocado
+Description of problem:
+```
+$ rm -rf build/
+$ ./configure --target-list=x86_64-softmmu,i386-softmmu
+$ make -j 16
+$ ./scripts/device-crash-test -q --tcg-only ./qemu-system-i386
+Module 'qemu' not found.
+  Try 'make check-venv' from your build directory,
+  and then one way to run this script is like so:
+  > $builddir/pyvenv/bin/python3 "/home/berrange/src/virt/qemu/scripts/device-crash-test"
+$ make check-venv
+make[1]: Entering directory '/home/berrange/src/virt/qemu/build'
+  GIT     ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+  VENVPIP install -e /home/berrange/src/virt/qemu/python/
+  VENVPIP install -r /home/berrange/src/virt/qemu/tests/requirements.txt
+ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
+avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 101.0 which is incompatible.
+avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 101.0 which is incompatible.
+make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
+```
+
+Despite this, it seems to have at least partially populated the venv, since I can now run device-crash-test.
+
+My host does have some avocado related python bits present:
+
+```
+python-avocado-common-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-plugins-output-html-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-plugins-varianter-yaml-to-mux-98.0-1.module_f38+15908+ffe8d4e2.noarch
+```
+
+I would expect the venv to not use these host packages however, since they're outdated compare to what QEMU askes for in tests/requirements.txt
diff --git a/results/classifier/zero-shot/108/device/1672 b/results/classifier/zero-shot/108/device/1672
new file mode 100644
index 00000000..90ec8ea1
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1672
@@ -0,0 +1,23 @@
+device: 0.956
+graphic: 0.899
+performance: 0.896
+network: 0.881
+PID: 0.800
+debug: 0.780
+vnc: 0.760
+permissions: 0.721
+boot: 0.683
+socket: 0.667
+semantic: 0.638
+files: 0.576
+other: 0.417
+KVM: 0.004
+
+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/zero-shot/108/device/1675549 b/results/classifier/zero-shot/108/device/1675549
new file mode 100644
index 00000000..81278507
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1675549
@@ -0,0 +1,34 @@
+device: 0.954
+graphic: 0.933
+network: 0.823
+socket: 0.747
+vnc: 0.719
+performance: 0.652
+PID: 0.650
+semantic: 0.600
+files: 0.583
+debug: 0.574
+other: 0.518
+permissions: 0.497
+boot: 0.466
+KVM: 0.025
+
+tcg  softmmu i386 crashes on BE hardware 
+
+Hi,
+today i try to test qemu 2.9rc 1 with qemu-system-i386 if i set display as sdl and i push a key on keyboard qemu exit with an error 
+
+translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
+
+This issue was not present on qemu 2.8.0 
+
+Test Machine PowerMac G5 Quad Fedora 25 Server PPC64
+Qemu build with target-list=i386-softmuu --with-sdlabi=2.0 
+
+Ciao 
+Luigi
+
+This is likely the same or at least a similar problem as reported in this bug here:
+https://bugs.launchpad.net/qemu/+bug/1675108
+
+
diff --git a/results/classifier/zero-shot/108/device/168 b/results/classifier/zero-shot/108/device/168
new file mode 100644
index 00000000..590701a4
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/168
@@ -0,0 +1,16 @@
+device: 0.951
+graphic: 0.679
+debug: 0.659
+network: 0.611
+semantic: 0.546
+performance: 0.483
+files: 0.319
+boot: 0.271
+vnc: 0.167
+permissions: 0.165
+PID: 0.107
+other: 0.068
+socket: 0.033
+KVM: 0.009
+
+ivshmem PCI device exposes wrong endianness on ppc64le
diff --git a/results/classifier/zero-shot/108/device/1696773 b/results/classifier/zero-shot/108/device/1696773
new file mode 100644
index 00000000..f2b45553
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1696773
@@ -0,0 +1,1337 @@
+device: 0.921
+permissions: 0.906
+other: 0.894
+debug: 0.892
+performance: 0.886
+socket: 0.882
+vnc: 0.880
+boot: 0.877
+PID: 0.876
+graphic: 0.873
+network: 0.870
+semantic: 0.861
+files: 0.860
+KVM: 0.854
+
+golang calls to exec crash user emulation
+
+An example program can be found here:
+
+https://github.com/willnewton/qemucrash
+
+This code starts a goroutine (thread) and calls exec repeatedly. This works ok natively but when run under ARM user emulation it segfaults (usually, there are occasionally other failures).
+
+You will need to apply the patch from https://bugs.launchpad.net/qemu/+bug/1696353 to run this sample app on current master.
+
+This bug is mentioned in this account from Cloudflare of porting their software stack to arm64:
+
+https://blog.cloudflare.com/porting-our-software-to-arm64/
+
+The relevant section from that blog reads as follows:
+
+# Intermittent Go Failures
+
+> With a decent amount of Go code running through our CI system, it was easy to spot a trend of intermittent segfaults.
+
+> Going on a hunch, we confirmed a hypothesis that non-deterministic failures are generally due to threading issues. Unfortunately, opinion on the issue tracker showed that Go / QEMU incompatibilities aren’t a priority, so we were left without an upstream fix.
+
+> The workaround we came up with is simple: if the problem is threading-related, limit where the threads can run! When we package our internal go binaries, we add a .deb post-install script to detect if we’re running under ARM64 emulation, and if so, reduce the number of CPUs the go binary can run under to one. We lose performance by pinning to one CPU, but this slowdown is negligible when we’re already running under emulation, and slow code is better than non-working code.
+
+> With the workaround in place, reports of intermittent crashes dropped to zero. Onto the next problem!
+
+Observed the same here... (details of the environment at the end of the post)
+
+Just building a hello world is good enough to crash go 3 times out of 4:
+
+--8<---------------------------------------------------------------------
+ubuntu@qemu:~$ cat <<EOF > hello.go
+> package main
+> 
+> import "fmt"
+> 
+> func main() {
+>   fmt.Println("Hello")
+> }
+> EOF
+
+--8<---------------------------------------------------------------------
+
+If I build it with affinity set to a single CPU, all is fine:
+
+ubuntu@qemu:~$ taskset -c 1 /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+ubuntu@qemu:~$ taskset -c 1 /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+ubuntu@qemu:~$ taskset -c 1 /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+ubuntu@qemu:~$ taskset -c 1 /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+
+
+But with the go build going multithreaded, all sorts of hells break loose:
+
+--8<---------------------------------------------------------------------
+ubuntu@qemu:~$ /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+fatal error: exitsyscall: syscall frame is no longer valid
+fatal error: malloc deadlock
+panic during panic
+
+runtime stack:
+runtime.startpanic_m()
+	/usr/lib/go-1.10/src/runtime/panic.go:690 +fatal error: unexpected signal during runtime execution
+0x178stack trace unavailable
+--8<---------------------------------------------------------------------
+
+or this:
+
+--8<---------------------------------------------------------------------
+ubuntu@qemu:~$ /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+fatal error: unexpected signal value
+panic during panic
+
+goroutine 0 [idle]:
+runtime: unexpected return pc for runtime.sigtramp called from 0x14420009ff0
+stack: frame={sp:0x14420007900, fp:0x14420007920} stack=[0x14420002000,0x1442000a000)
+0000014420007800:  0000000000000000  0000000000000084 
+0000014420007810:  000000000043d694 <runtime.sigtrampgo+44>  0000000000000000 
+0000014420007820:  0000000000000000  0000000000000000 
+0000014420007830:  00000144200ae000  0000000000000000 
+0000014420007840:  0000014420007920  00000144200079a0 
+0000014420007850:  000000000045266c <runtime.sigtramp+52>  0000014400000004 
+0000014420007860:  0000014420007920  00000144200079a0 
+0000014420007870:  00000144200ae180  0000000000000000 
+0000014420007880:  0000000000000000  0000000000000000 
+0000014420007890:  0000000000000000  0000000000000000 
+00000144200078a0:  0000000000000000  0000000000000000 
+00000144200078b0:  0000000000000000  00000144200ae180 
+00000144200078c0:  0000000000000000  0000000000000000 
+00000144200078d0:  0000000000000000  0000000000000000 
+00000144200078e0:  0000000000000000  0000000000000000 
+00000144200078f0:  0000000000000000  0000000000000000 
+0000014420007900: <0000014420009ff0  0000000000000004 
+0000014420007910:  0000014420007920  00000144200079a0 
+0000014420007920: >0000000000000004  0000000000000002 
+0000014420007930:  00000144201a4180  0000000000000000 
+0000014420007940:  000000000000000c  0000000000000001 
+0000014420007950:  0000000000000000  0000000000000000 
+0000014420007960:  0000000000000000  0000000000000000 
+0000014420007970:  0000000000000000  0000000000000000 
+0000014420007980:  0000000000000000  0000000000000000 
+0000014420007990:  0000000000000000  0000000000000000 
+00000144200079a0:  0000000000000000  0000000000000000 
+00000144200079b0:  0000014420002000  0000000000000000 
+00000144200079c0:  0000000000008000  0000000000000000 
+00000144200079d0:  0000000000000000  0000000000000000 
+00000144200079e0:  0000000000000000  0000000000000000 
+00000144200079f0:  0000000000000000  0000000000000000 
+0000014420007a00:  0000000000000000  0000000000000000 
+0000014420007a10:  0000000000000000  0000000000000000 
+runtime.startpanic_m()
+	/usr/lib/go-1.10/src/runtime/panic.go:690 +0x178
+runtime.startpanic()
+	/usr/lib/go-1.10/src/runtime/panic.go:589 +0x14
+runtime.sighandler(0x14400000004, 0x14420007920, 0x144200079a0, 0x144200ae180)
+	/usr/lib/go-1.10/src/runtime/signal_sighandler.go:86 +0x4c4
+runtime.sigtrampgo(0x4, 0x14420007920, 0x144200079a0)
+	/usr/lib/go-1.10/src/runtime/signal_unix.go:349 +0x19c
+runtime: unexpected return pc for runtime.sigtramp called from 0x14420009ff0
+stack: frame={sp:0x14420007900, fp:0x14420007920} stack=[0x14420002000,0x1442000a000)
+0000014420007800:  0000000000000000  0000000000000084 
+0000014420007810:  000000000043d694 <runtime.sigtrampgo+44>  0000000000000000 
+0000014420007820:  0000000000000000  0000000000000000 
+0000014420007830:  00000144200ae000  0000000000000000 
+0000014420007840:  0000014420007920  00000144200079a0 
+0000014420007850:  000000000045266c <runtime.sigtramp+52>  0000014400000004 
+0000014420007860:  0000014420007920  00000144200079a0 
+0000014420007870:  00000144200ae180  0000000000000000 
+0000014420007880:  0000000000000000  0000000000000000 
+0000014420007890:  0000000000000000  0000000000000000 
+00000144200078a0:  0000000000000000  0000000000000000 
+00000144200078b0:  0000000000000000  00000144200ae180 
+00000144200078c0:  0000000000000000  0000000000000000 
+00000144200078d0:  0000000000000000  0000000000000000 
+00000144200078e0:  0000000000000000  0000000000000000 
+00000144200078f0:  0000000000000000  0000000000000000 
+0000014420007900: <0000014420009ff0  0000000000000004 
+0000014420007910:  0000014420007920  00000144200079a0 
+0000014420007920: >0000000000000004  0000000000000002 
+0000014420007930:  00000144201a4180  0000000000000000 
+0000014420007940:  000000000000000c  0000000000000001 
+0000014420007950:  0000000000000000  0000000000000000 
+0000014420007960:  0000000000000000  0000000000000000 
+0000014420007970:  0000000000000000  0000000000000000 
+0000014420007980:  0000000000000000  0000000000000000 
+0000014420007990:  0000000000000000  0000000000000000 
+00000144200079a0:  0000000000000000  0000000000000000 
+00000144200079b0:  0000014420002000  0000000000000000 
+00000144200079c0:  0000000000008000  0000000000000000 
+00000144200079d0:  0000000000000000  0000000000000000 
+00000144200079e0:  0000000000000000  0000000000000000 
+00000144200079f0:  0000000000000000  0000000000000000 
+0000014420007a00:  0000000000000000  0000000000000000 
+0000014420007a10:  0000000000000000  0000000000000000 
+runtime.sigtramp(0x2, 0x144201a4180, 0x0, 0xc, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
+	/usr/lib/go-1.10/src/runtime/sys_linux_arm64.s:263 +0x34
+
+goroutine 88 [syscall]:
+syscall.Syscall6(0x5f, 0x1, 0x2039, 0x144205909a0, 0x1000004, 0x0, 0x0, 0x144201a2320, 0x144200ac000, 0x40009efaf8)
+	/usr/lib/go-1.10/src/syscall/asm_linux_arm64.s:36 +0x8 fp=0x14420590940 sp=0x14420590930 pc=0x471870
+os.(*Process).blockUntilWaitable(0x1442036c000, 0x0, 0x0, 0x410a64)
+	/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x64 fp=0x14420590a40 sp=0x14420590940 pc=0x49077c
+os.(*Process).wait(0x1442036c000, 0x14420262310, 0x144205841e0, 0x144203d6398)
+	/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x2c fp=0x14420590ac0 sp=0x14420590a40 pc=0x48a234
+os.(*Process).Wait(0x1442036c000, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20 fp=0x14420590af0 sp=0x14420590ac0 pc=0x489898
+os/exec.(*Cmd).Wait(0x144203d62c0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c fp=0x14420590b70 sp=0x14420590af0 pc=0x4e1354
+os/exec.(*Cmd).Run(0x144203d62c0, 0x144200f6150, 0x14420440840)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48 fp=0x14420590b90 sp=0x14420590b70 pc=0x4e0ad0
+cmd/go/internal/work.(*Builder).toolID(0x1442029c0a0, 0x826cab, 0x3, 0x11, 0x14420591290)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274 fp=0x14420590d40 sp=0x14420590b90 pc=0x5bc57c
+cmd/go/internal/work.(*Builder).buildActionID(0x1442029c0a0, 0x144201537c0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:221 +0x116c fp=0x14420591450 sp=0x14420590d40 pc=0x5c0e04
+cmd/go/internal/work.(*Builder).build(0x1442029c0a0, 0x144201537c0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64 fp=0x14420591e70 sp=0x14420591450 pc=0x5c153c
+cmd/go/internal/work.(*Builder).Do.func1(0x144201537c0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50 fp=0x14420591ef0 sp=0x14420591e70 pc=0x5e7cd8
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c fp=0x14420591fc0 sp=0x14420591ef0 pc=0x5e7f74
+runtime.goexit()
+	/usr/lib/go-1.10/src/runtime/asm_arm64.s:1037 +0x4 fp=0x14420591fc0 sp=0x14420591fc0 pc=0x451cec
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 1 [semacquire]:
+sync.runtime_Semacquire(0x1442027725c)
+	/usr/lib/go-1.10/src/runtime/sema.go:56 +0x2c
+sync.(*WaitGroup).Wait(0x14420277250)
+	/usr/lib/go-1.10/src/sync/waitgroup.go:129 +0x68
+cmd/go/internal/work.(*Builder).Do(0x1442029c0a0, 0x14420152c80)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:173 +0x36c
+cmd/go/internal/work.runBuild(0xa5d0a0, 0x144200da010, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/build.go:325 +0x4bc
+main.main()
+	/usr/lib/go-1.10/src/cmd/go/main.go:140 +0x6f4
+
+goroutine 19 [syscall]:
+os/signal.signal_recv(0x0)
+	/usr/lib/go-1.10/src/runtime/sigqueue.go:139 +0xc8
+os/signal.loop()
+	/usr/lib/go-1.10/src/os/signal/signal_unix.go:22 +0x18
+created by os/signal.init.0
+	/usr/lib/go-1.10/src/os/signal/signal_unix.go:28 +0x30
+
+goroutine 11 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 12 [syscall]:
+syscall.Syscall6(0x5f, 0x1, 0x2008, 0x1442059e9a0, 0x1000004, 0x0, 0x0, 0x144203d8140, 0x1442006ec00, 0x40009e31e8)
+	/usr/lib/go-1.10/src/syscall/asm_linux_arm64.s:36 +0x8
+os.(*Process).blockUntilWaitable(0x144203e2240, 0x0, 0x0, 0x410a64)
+	/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x64
+os.(*Process).wait(0x144203e2240, 0x1442026a180, 0x14420544020, 0x1442058a238)
+	/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x2c
+os.(*Process).Wait(0x144203e2240, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x1442058a160, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x1442058a160, 0x14420132150, 0x14420318840)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x1442029c0a0, 0x8285a2, 0x7, 0x2c, 0x1442059f320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x1442029c0a0, 0x1442017c8c0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x1442029c0a0, 0x1442017c8c0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x1442017c8c0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 13 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 14 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 15 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 16 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 82 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 83 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 84 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 85 [runnable]:
+os.(*File).Read(0x144200d4060, 0x144202ac000, 0x8000, 0x8000, 0x8000, 0x8000, 0x7ed900)
+	/usr/lib/go-1.10/src/os/file.go:103 +0x24c
+io.copyBuffer(0x40b3596000, 0x144203f8000, 0x894040, 0x144200d4060, 0x144202ac000, 0x8000, 0x8000, 0x7ed900, 0x144200d4000, 0x40b3596000)
+	/usr/lib/go-1.10/src/io/io.go:400 +0x100
+io.Copy(0x40b3596000, 0x144203f8000, 0x894040, 0x144200d4060, 0x144203f8000, 0x0, 0x29)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+cmd/go/internal/cache.FileHash(0x144200cc8a0, 0x29, 0x0, 0x0, 0x0, 0x0, 0x144200cc8a0, 0x29)
+	/usr/lib/go-1.10/src/cmd/go/internal/cache/hash.go:149 +0x228
+cmd/go/internal/work.(*Builder).fileHash(0x1442029c0a0, 0x144200cc8a0, 0x29, 0x144200cc8a0, 0x29)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:358 +0x28
+cmd/go/internal/work.(*Builder).buildActionID(0x1442029c0a0, 0x14420153400, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:286 +0x650
+cmd/go/internal/work.(*Builder).build(0x1442029c0a0, 0x14420153400, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x14420153400)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 86 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 87 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 89 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 90 [syscall]:
+syscall.Syscall6(0x5f, 0x1, 0x1ffd, 0x1442058e9a0, 0x1000004, 0x0, 0x0, 0x14420236140, 0x1442006f400, 0x40009e2b20)
+	/usr/lib/go-1.10/src/syscall/asm_linux_arm64.s:36 +0x8
+os.(*Process).blockUntilWaitable(0x1442055a300, 0x0, 0x0, 0x410a64)
+	/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x64
+os.(*Process).wait(0x1442055a300, 0x144201f6110, 0x144205d6040, 0x144202a00d8)
+	/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x2c
+os.(*Process).Wait(0x1442055a300, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x144202a0000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x144202a0000, 0x14420144070, 0x144205de580)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x1442029c0a0, 0x8285a2, 0x7, 0x2c, 0x1442058f320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x1442029c0a0, 0x1442017c780, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x1442029c0a0, 0x1442017c780, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x1442017c780)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 91 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 92 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 93 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 94 [syscall]:
+syscall.Syscall6(0x5f, 0x1, 0x2036, 0x1442058c9a0, 0x1000004, 0x0, 0x0, 0x144203d8320, 0x1442038ec00, 0x40009ef430)
+	/usr/lib/go-1.10/src/syscall/asm_linux_arm64.s:36 +0x8
+os.(*Process).blockUntilWaitable(0x144200284b0, 0x0, 0x0, 0x410a64)
+	/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x64
+os.(*Process).wait(0x144200284b0, 0x1442026a2a0, 0x144205441a0, 0x1442058a4f8)
+	/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x2c
+os.(*Process).Wait(0x144200284b0, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x1442058a420, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x1442058a420, 0x144201322a0, 0x14420319080)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x1442029c0a0, 0x826cab, 0x3, 0x11, 0x1442058d290)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x1442029c0a0, 0x14420153a40, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:221 +0x116c
+cmd/go/internal/work.(*Builder).build(0x1442029c0a0, 0x14420153a40, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x14420153a40)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 95 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 96 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 97 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 98 [syscall]:
+syscall.Syscall6(0x5f, 0x1, 0x2033, 0x1442059c9a0, 0x1000004, 0x0, 0x0, 0x14420274730, 0x144205b0000, 0x40009e2b20)
+	/usr/lib/go-1.10/src/syscall/asm_linux_arm64.s:36 +0x8
+os.(*Process).blockUntilWaitable(0x1442055a660, 0x0, 0x0, 0x410a64)
+	/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x64
+os.(*Process).wait(0x1442055a660, 0x144200c4380, 0x1442033e1a0, 0x144200eee98)
+	/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x2c
+os.(*Process).Wait(0x1442055a660, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x144200eedc0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x144200eedc0, 0x144201123f0, 0x144205e0dc0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x1442029c0a0, 0x826cab, 0x3, 0x11, 0x1442059d290)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x1442029c0a0, 0x14420153cc0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:221 +0x116c
+cmd/go/internal/work.(*Builder).build(0x1442029c0a0, 0x14420153cc0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x14420153cc0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 99 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x14420277250, 0x1442029c0a0, 0x144201ae940)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 133 [IO wait]:
+internal/poll.runtime_pollWait(0x4089492918, 0x72, 0x144201aa000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144203d82e8, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144203d82e8, 0x144201aa001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144203d82d0, 0x144201aa000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144203da060, 0x144201aa000, 0x200, 0x200, 0x144201aa000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144203da060, 0x144201aa000, 0x200, 0x200, 0x14420268528, 0x1, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x144201322a0, 0x894040, 0x144203da060, 0x40ab556000, 0x144201322a0, 0x404701)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x144201322a0, 0x894040, 0x144203da060, 0x0, 0x0, 0x0, 0x4e37c4, 0x14420268500, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x144201322a0, 0x894040, 0x144203da060, 0x0, 0x4e3830, 0x1442016a060)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x1442016a060, 0x1442046bfb0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x1442058a420, 0x14420544240)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 73 [runnable]:
+internal/poll.runtime_pollWait(0x4089492d28, 0x72, 0x144202b4019)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x14420236068, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x14420236068, 0x144202b4001, 0x5e7, 0x5e7)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x14420236050, 0x144202b4019, 0x5e7, 0x5e7, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x1442008a010, 0x144202b4019, 0x5e7, 0x5e7, 0x144202b4000, 0x144201a6000, 0x19)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x1442008a010, 0x144202b4019, 0x5e7, 0x5e7, 0x19, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x14420144000, 0x894040, 0x1442008a010, 0x40ab556000, 0x14420144000, 0x1442047de01)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x14420144000, 0x894040, 0x1442008a010, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x14420144000, 0x894040, 0x1442008a010, 0x0, 0x144201b0180, 0x5e7fc4)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x5e7fe8, 0x1)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144202a0000, 0x144205d60a0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 74 [runnable]:
+internal/poll.runtime_pollWait(0x4089492b88, 0x72, 0x144204e4200)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x14420236108, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x14420236108, 0x144204e4201, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144202360f0, 0x144204e4200, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x1442008a028, 0x144204e4200, 0x200, 0x200, 0x144204e4200, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x1442008a028, 0x144204e4200, 0x200, 0x200, 0x0, 0x0, 0x144201a51b8)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x14420144070, 0x894040, 0x1442008a028, 0x40ab556000, 0x14420144070, 0x1442047d601)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x14420144070, 0x894040, 0x1442008a028, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x14420144070, 0x894040, 0x1442008a028, 0x0, 0x144201b0180, 0x5e7fc4)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x5e7fe8, 0x1)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144202a0000, 0x144205d60e0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 132 [IO wait]:
+internal/poll.runtime_pollWait(0x4089492ec8, 0x72, 0x144204a4000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144203d8248, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144203d8248, 0x144204a4001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144203d8230, 0x144204a4000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144203da048, 0x144204a4000, 0x200, 0x200, 0x144204a4000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144203da048, 0x144204a4000, 0x200, 0x200, 0x144200d62a8, 0x1, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x144201321c0, 0x894040, 0x144203da048, 0x40ab556000, 0x144201321c0, 0x404701)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x144201321c0, 0x894040, 0x144203da048, 0x0, 0x0, 0x0, 0x4e37c4, 0x144200d6280, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x144201321c0, 0x894040, 0x144203da048, 0x0, 0x4e3830, 0x144200aa0c0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x144200aa0c0, 0x14420537fb0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x1442058a420, 0x14420544200)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 75 [IO wait]:
+internal/poll.runtime_pollWait(0x402b24ee30, 0x72, 0x1442033a000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x14420274658, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x14420274658, 0x1442033a001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x14420274640, 0x1442033a000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144203dc048, 0x1442033a000, 0x200, 0x200, 0x1442033a000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144203dc048, 0x1442033a000, 0x200, 0x200, 0x0, 0x0, 0x144201a5038)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x14420112310, 0x894040, 0x144203dc048, 0x40ab556000, 0x14420112310, 0x1442047ce01)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x14420112310, 0x894040, 0x144203dc048, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x14420112310, 0x894040, 0x144203dc048, 0x0, 0x144201b0180, 0x5e7fc4)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x5e7fe8, 0x1)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144200eedc0, 0x1442033e200)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 76 [IO wait]:
+internal/poll.runtime_pollWait(0x402b24ec90, 0x72, 0x1442033c000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144202746f8, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144202746f8, 0x1442033c001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144202746e0, 0x1442033c000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144203dc060, 0x1442033c000, 0x200, 0x200, 0x1442033c000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144203dc060, 0x1442033c000, 0x200, 0x200, 0x0, 0x0, 0x144201a4eb8)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x144201123f0, 0x894040, 0x144203dc060, 0x40ab556000, 0x144201123f0, 0x1442047c601)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x144201123f0, 0x894040, 0x144203dc060, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x144201123f0, 0x894040, 0x144203dc060, 0x0, 0x144201b0180, 0x5e7fc4)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x5e7fe8, 0x1)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144200eedc0, 0x1442033e240)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 162 [runnable]:
+os/exec.(*Cmd).Start.func1(0x144203d62c0, 0x14420584240)
+	/usr/lib/go-1.10/src/os/exec/exec.go:395
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 163 [runnable]:
+os/exec.(*Cmd).Start.func1(0x144203d62c0, 0x14420584280)
+	/usr/lib/go-1.10/src/os/exec/exec.go:395
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+--8<---------------------------------------------------------------------
+
+It worked once for me:
+
+--8<---------------------------------------------------------------------
+ubuntu@qemu:~$ /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+--8<---------------------------------------------------------------------
+
+but then again:
+
+--8<---------------------------------------------------------------------
+ubuntu@qemu:~$ /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go build
+�Afatal error: malloc deadlock
+panic during panic
+[signal SIGSEGV: segmentation violation code=0x1 addr=0x90 pc=0x90]
+
+runtime stack:
+runtime.startpanic_m()
+	/usr/lib/go-1.10/src/runtime/panic.go:690 +0x178
+SIGILL: illegal instructionruntime.systemstack(
+0x4000000000PC=0x44f790)
+	/usr/lib/go-1.10/src/runtime/asm_arm64.s:229 + m=0x8c
+19runtime.mstart sigcode=()
+2	/usr/lib/go-1.10/src/runtime/proc.go
+:1175
+
+
+goroutine goroutine 80 [ [idlerunning]:
+]:
+runtime.systemstack_switch()
+	/usr/lib/go-1.10/src/runtime/asm_arm64.s:178 +0x8 fp=0x144205dcc30runtime.morestack sp=()
+	0x144205dcc20/usr/lib/go-1.10/src/runtime/asm_arm64.s:301 pc= +0x68
+0x44f650
+runtime.startpanic()
+	/usr/lib/go-1.10/src/runtime/panic.go:589 +
+0x14goroutine  fp=80x144205dcc40 [ sp=running0x144205dcc30]:
+ pc=0x428efc
+runtime.systemstack_switch()
+runtime.throw	(/usr/lib/go-1.10/src/runtime/asm_arm64.s0x82ca61:178 +0x8,  fp=0x144205dcc30 sp=0x144205dcc20 pc=0x44f6500xf
+)
+runtime.startpanic	(/usr/lib/go-1.10/src/runtime/panic.go)
+:	615/usr/lib/go-1.10/src/runtime/panic.go +:0x54589 fp= +0x144205dcc600x14 sp= fp=0x144205dcc400x144205dcc40 pc= sp=0x428fec0x144205dcc30
+ pc=0x428efc
+runtime.throw(0x82ca61, 0xf)
+	/usr/lib/go-1.10/src/runtime/panic.go:615 +0x54 fp=0x144205dcc60 sp=0x144205dcc40 pc=0x428fec
+runtime.mallocgcruntime.mallocgc((0x100x10, , 0x78e2800x78e280, , 0x144202ca0010x144202ca001, , 0x00x0)
+)
+		/usr/lib/go-1.10/src/runtime/malloc.go/usr/lib/go-1.10/src/runtime/malloc.go::621621 + +0x8180x818 fp= fp=0x144205dcd100x144205dcd10 sp= sp=0x144205dcc600x144205dcc60 pc= pc=0x410e200x410e20
+
+runtime.convT2Estringruntime.convT2Estring(0x78e280(, 0x78e2800x144205dcf60, , 0x144205dcf600x7, , 0x70x144203aa270, )
+	0x144203aa270/usr/lib/go-1.10/src/runtime/iface.go)
+:	365/usr/lib/go-1.10/src/runtime/iface.go +:0x58365 fp= +0x144205dcd40 sp=0x580x144205dcd10 fp= pc=0x144205dcd400x40ead0 sp=0x144205dcd10
+ pc=0x40ead0
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x14420174140, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xc2c fp=0x144205dd450 sp=0x144205dcd40cmd/go/internal/work.(*Builder).buildActionID pc=0x5c08c4(
+0x144202a60a0cmd/go/internal/work.(*Builder).build, (0x144201741400x144202a60a0, , 0x00x14420174140, , 0x00x0, , 0x00x0, )
+0x0	)
+/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go	:/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go304: +2190x64 + fp=0xc2c0x144205dde70 fp= sp=0x144205dd4500x144205dd450 sp= pc=0x144205dcd400x5c153c pc=
+0x5c08c4
+cmd/go/internal/work.(*Builder).Do.func1(0x14420174140cmd/go/internal/work.(*Builder).build)
+(	0x144202a60a0/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go, :0x14420174140106,  +0x00x50,  fp=0x00x144205ddef0)
+ sp=	0x144205dde70/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go pc=:0x5e7cd8304
+ +0x64cmd/go/internal/work.(*Builder).Do.func2 fp=(0x144205dde700x144200ca7b0 sp=, 0x144205dd4500x144202a60a0 pc=, 0x5c153c0x1442019a9a0)
+
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:cmd/go/internal/work.(*Builder).Do.func1164( +0x144201741400x8c)
+ fp=	0x144205ddfc0/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go sp=:0x144205ddef0106 pc= +0x5e7f740x50
+ fp=0x144205ddef0runtime.goexit sp=(0x144205dde70)
+ pc=	0x5e7cd8/usr/lib/go-1.10/src/runtime/asm_arm64.s
+:1037cmd/go/internal/work.(*Builder).Do.func2 +(0x40x144200ca7b0 fp=, 0x144205ddfc00x144202a60a0 sp=, 0x144205ddfc00x1442019a9a0 pc=)
+0x451cec	
+/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c fp=0x144205ddfc0 sp=0x144205ddef0 pc=0x5e7f74
+runtime.goexit()
+	/usr/lib/go-1.10/src/runtime/asm_arm64.s:created by 1037 +0x4cmd/go/internal/work.(*Builder).Do fp=0x144205ddfc0
+ sp=0x144205ddfc0 pc=0x451cec
+created by cmd/go/internal/work.(*Builder).Do
+		/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go::151151 + +0x34c0x34c
+
+
+goroutine 1 [semacquire]:
+sync.runtime_Semacquire(0x144200ca7bc)
+	/usr/lib/go-1.10/src/runtime/sema.go:56 +0x2c
+sync.(*WaitGroup).Wait(0x144200ca7b0)
+	/usr/lib/go-1.10/src/sync/waitgroup.go:129 +0x68
+cmd/go/internal/work.(*Builder).Do(0x144202a60a0, 0x1442014b040)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:173 +0x36c
+cmd/go/internal/work.runBuild(0xa5d0a0, 0x144200d4010, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/build.go:325 +0x4bc
+main.main()
+	/usr/lib/go-1.10/src/cmd/go/main.go:140 +0x6f4
+
+goroutine 19 [syscall]:
+os/signal.signal_recv(0x0)
+	/usr/lib/go-1.10/src/runtime/sigqueue.go:139 +0xc8
+os/signal.loop()
+	/usr/lib/go-1.10/src/os/signal/signal_unix.go:22 +0x18
+created by os/signal.init.0
+	/usr/lib/go-1.10/src/os/signal/signal_unix.go:28 +0x30
+
+goroutine 9 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 10 [chan receive]:
+os/exec.(*Cmd).Wait(0x1442011e000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:469 +0xe4
+os/exec.(*Cmd).Run(0x1442011e000, 0x14420142070, 0x1442015c000)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144204ed320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x14420174000, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x14420174000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x14420174000)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 11 [chan receive]:
+os/exec.(*Cmd).Wait(0x144202aa000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:469 +0xe4
+os/exec.(*Cmd).Run(0x144202aa000, 0x144200f0070, 0x14420204000)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144205df320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x1442014b7c0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x1442014b7c0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x1442014b7c0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 12 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 13 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 14 [runnable]:
+syscall.Wait4(0x20dd, 0x144204eea80, 0x0, 0x144203a2000, 0x2, 0x2, 0x2)
+	/usr/lib/go-1.10/src/syscall/syscall_linux.go:252 +0x74
+os.(*Process).wait(0x144200283f0, 0x144202d4060, 0x1442037c020, 0x144202c80d8)
+	/usr/lib/go-1.10/src/os/exec_unix.go:38 +0x7c
+os.(*Process).Wait(0x144200283f0, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x144202c8000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x144202c8000, 0x1442012a070, 0x14420136000)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144204ef320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x14420174b40, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x14420174b40, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x14420174b40)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 15 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 16 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 82 [runnable]:
+syscall.Wait4(0x20e5, 0x144204f2a80, 0x0, 0x1442022e000, 0x2, 0x2, 0x2)
+	/usr/lib/go-1.10/src/syscall/syscall_linux.go:252 +0x74
+os.(*Process).wait(0x14420376390, 0x144205f4060, 0x1442019a020, 0x144203440d8)
+	/usr/lib/go-1.10/src/os/exec_unix.go:38 +0x7c
+os.(*Process).Wait(0x14420376390, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x14420344000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x14420344000, 0x1442010c150, 0x144204cc000)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144204f3320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x1442014be00, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x1442014be00, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x1442014be00)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 83 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 84 [syscall]:
+syscall.Syscall6(0x5f, 0x1, 0x20d8, 0x144204e69a0, 0x1000004, 0x0, 0x0, 0x144202ac140, 0x1442009c800, 0x40009e16c8)
+	/usr/lib/go-1.10/src/syscall/asm_linux_arm64.s:36 +0x8
+os.(*Process).blockUntilWaitable(0x144200c67e0, 0x0, 0x0, 0x410a64)
+	/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x64
+os.(*Process).wait(0x144200c67e0, 0x144201ee0d0, 0x14420524020, 0x144202dc0d8)
+	/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x2c
+os.(*Process).Wait(0x144200c67e0, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x144202dc000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x144202dc000, 0x14420150070, 0x14420324580)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144204e7320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x14420174c80, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x14420174c80, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x14420174c80)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 85 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 86 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 87 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 88 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 89 [runnable]:
+syscall.Wait4(0x20e9, 0x144204f0a80, 0x0, 0x1442022c000, 0x2, 0x2, 0x2)
+	/usr/lib/go-1.10/src/syscall/syscall_linux.go:252 +0x74
+os.(*Process).wait(0x144205f01e0, 0x1442025c1c0, 0x144204e4020, 0x144200c00d8)
+	/usr/lib/go-1.10/src/os/exec_unix.go:38 +0x7c
+os.(*Process).Wait(0x144205f01e0, 0x0, 0x0, 0x856708)
+	/usr/lib/go-1.10/src/os/exec.go:123 +0x20
+os/exec.(*Cmd).Wait(0x144200c0000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x3c
+os/exec.(*Cmd).Run(0x144200c0000, 0x1442013c070, 0x144200e8000)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144204f1320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x1442014bcc0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x1442014bcc0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x1442014bcc0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 90 [chan receive]:
+os/exec.(*Cmd).Wait(0x144203e6000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:469 +0xe4
+os/exec.(*Cmd).Run(0x144203e6000, 0x144201300e0, 0x144200ea000)
+	/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x48
+cmd/go/internal/work.(*Builder).toolID(0x144202a60a0, 0x8285a2, 0x7, 0x2c, 0x144204eb320)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/buildid.go:183 +0x274
+cmd/go/internal/work.(*Builder).buildActionID(0x144202a60a0, 0x1442014b400, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:219 +0xbec
+cmd/go/internal/work.(*Builder).build(0x144202a60a0, 0x1442014b400, 0x0, 0x0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:304 +0x64
+cmd/go/internal/work.(*Builder).Do.func1(0x1442014b400)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:106 +0x50
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:164 +0x8c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 91 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 92 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 93 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 94 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 95 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 96 [select]:
+cmd/go/internal/work.(*Builder).Do.func2(0x144200ca7b0, 0x144202a60a0, 0x1442019a9a0)
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:154 +0x10c
+created by cmd/go/internal/work.(*Builder).Do
+	/usr/lib/go-1.10/src/cmd/go/internal/work/exec.go:151 +0x34c
+
+goroutine 54 [IO wait]:
+internal/poll.runtime_pollWait(0x402b252ea8, 0x72, 0x144203c4000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144200d01a8, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144200d01a8, 0x144203c4001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144200d0190, 0x144203c4000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144200ce028, 0x144203c4000, 0x200, 0x200, 0x144203c4000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144200ce028, 0x144203c4000, 0x200, 0x200, 0x0, 0x0, 0x1442046a5b8)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x1442010c000, 0x894040, 0x144200ce028, 0x40aad15000, 0x1442010c000, 0x14420069e01)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x1442010c000, 0x894040, 0x144200ce028, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x1442010c000, 0x894040, 0x144200ce028, 0x0, 0x1442019c200, 0x5e7fc4)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x5e7fe8, 0x1)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x14420344000, 0x1442019a080)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 55 [IO wait]:
+internal/poll.runtime_pollWait(0x403c3f0c70, 0x72, 0x144204d0600)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144200d0248, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144200d0248, 0x144204d0601, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144200d0230, 0x144204d0600, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144200ce040, 0x144204d0600, 0x200, 0x200, 0x144204d0600, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144200ce040, 0x144204d0600, 0x200, 0x200, 0x0, 0x0, 0x144203b51b8)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x1442010c150, 0x894040, 0x144200ce040, 0x40aad15000, 0x1442010c150, 0x1442006de01)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x1442010c150, 0x894040, 0x144200ce040, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x1442010c150, 0x894040, 0x144200ce040, 0x0, 0x1442019c200, 0x5e7fc4)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x5e7fe8, 0x1)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x14420344000, 0x1442019a0c0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 98 [IO wait]:
+internal/poll.runtime_pollWait(0x402b2528f8, 0x72, 0x14420340619)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x1442016e068, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x1442016e068, 0x14420340601, 0x5e7, 0x5e7)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x1442016e050, 0x14420340619, 0x5e7, 0x5e7, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x14420172010, 0x14420340619, 0x5e7, 0x5e7, 0x14420340600, 0x14420348000, 0x19)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x14420172010, 0x14420340619, 0x5e7, 0x5e7, 0x19, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x14420142000, 0x894040, 0x14420172010, 0x40aad15000, 0x14420142000, 0x144201be601)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x14420142000, 0x894040, 0x14420172010, 0x0, 0x0, 0x0, 0x144201beb80, 0x144201beba0, 0x144201bebc0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x14420142000, 0x894040, 0x14420172010, 0x144201beca0, 0x144201becc0, 0x144201bece0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x144201bee40, 0x144201bee60)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x1442011e000, 0x144203ae0a0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 97 [IO wait]:
+internal/poll.runtime_pollWait(0x402b252d08, 0x72, 0x144201a8000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x1442025e568, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x1442025e568, 0x144201a8001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x1442025e550, 0x144201a8000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x1442000e0a0, 0x144201a8000, 0x200, 0x200, 0x144201a8000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x1442000e0a0, 0x144201a8000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x144200f0000, 0x894040, 0x1442000e0a0, 0x40aad15000, 0x144200f0000, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x144200f0000, 0x894040, 0x1442000e0a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x144200f0000, 0x894040, 0x1442000e0a0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144202aa000, 0x1442000c0e0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 99 [IO wait]:
+internal/poll.runtime_pollWait(0x403c3f0ee0, 0x72, 0x144202cc000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x1442016e108, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x1442016e108, 0x144202cc001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x1442016e0f0, 0x144202cc000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x14420172028, 0x144202cc000, 0x200, 0x200, 0x144202cc000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x14420172028, 0x144202cc000, 0x200, 0x200, 0x144201cc1e0, 0x144201cc200, 0x144201cc220)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x14420142070, 0x894040, 0x14420172028, 0x40aad15000, 0x14420142070, 0x144201cc301)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x14420142070, 0x894040, 0x14420172028, 0x0, 0x0, 0x0, 0x144201c1f60, 0x144201c1f80, 0x144201c2020)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x14420142070, 0x894040, 0x14420172028, 0x144201c2100, 0x144201c2120, 0x144201c2140)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x144201c2200, 0x144201c2220)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x1442011e000, 0x144203ae0e0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 114 [IO wait]:
+internal/poll.runtime_pollWait(0x402b2525b8, 0x72, 0x144201a6000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x1442025e608, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x1442025e608, 0x144201a6001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x1442025e5f0, 0x144201a6000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x1442000e0b8, 0x144201a6000, 0x200, 0x200, 0x144201a6000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x1442000e0b8, 0x144201a6000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x144200f0070, 0x894040, 0x1442000e0b8, 0x40aad15000, 0x144200f0070, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x144200f0070, 0x894040, 0x1442000e0b8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x144200f0070, 0x894040, 0x1442000e0b8, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144202aa000, 0x1442000c120)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 41 [IO wait]:
+internal/poll.runtime_pollWait(0x402b252f78, 0x72, 0x144204d0000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144204d20b8, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144204d20b8, 0x144204d0001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144204d20a0, 0x144204d0000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x1442027c020, 0x144204d0000, 0x200, 0x200, 0x144204d0000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x1442027c020, 0x144204d0000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x14420130000, 0x894040, 0x1442027c020, 0x40aad15000, 0x14420130000, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x14420130000, 0x894040, 0x1442027c020, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x14420130000, 0x894040, 0x1442027c020, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144203e6000, 0x14420550080)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 42 [IO wait]:
+internal/poll.runtime_pollWait(0x402b252278, 0x72, 0x144204d0800)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144204d2158, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144204d2158, 0x144204d0801, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144204d2140, 0x144204d0800, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x1442027c090, 0x144204d0800, 0x200, 0x200, 0x144204d0800, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x1442027c090, 0x144204d0800, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x144201300e0, 0x894040, 0x1442027c090, 0x40aad15000, 0x144201300e0, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x144201300e0, 0x894040, 0x1442027c090, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x144201300e0, 0x894040, 0x1442027c090, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144203e6000, 0x144205500c0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 130 [IO wait]:
+internal/poll.runtime_pollWait(0x402b253118, 0x72, 0x144203d2000)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x14420282518, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x14420282518, 0x144203d2001, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x14420282500, 0x144203d2000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x14420286030, 0x144203d2000, 0x200, 0x200, 0x144203d2000, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x14420286030, 0x144203d2000, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x1442012a000, 0x894040, 0x14420286030, 0x40aad15000, 0x1442012a000, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x1442012a000, 0x894040, 0x14420286030, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x1442012a000, 0x894040, 0x14420286030, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144202c8000, 0x1442037c080)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 131 [IO wait]:
+internal/poll.runtime_pollWait(0x403c3f0fb0, 0x72, 0x144204d0c00)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x144202825b8, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x144202825b8, 0x144204d0c01, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x144202825a0, 0x144204d0c00, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x14420286068, 0x144204d0c00, 0x200, 0x200, 0x144204d0c00, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x14420286068, 0x144204d0c00, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x1442012a070, 0x894040, 0x14420286068, 0x40aad15000, 0x1442012a070, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x1442012a070, 0x894040, 0x14420286068, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x1442012a070, 0x894040, 0x14420286068, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144202c8000, 0x1442037c0c0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 71 [IO wait]:
+internal/poll.runtime_pollWait(0x402b252a98, 0x72, 0x144204d0200)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x14420276388, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x14420276388, 0x144204d0201, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x14420276370, 0x144204d0200, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144200f6010, 0x144204d0200, 0x200, 0x200, 0x144204d0200, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144200f6010, 0x144204d0200, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x1442013c000, 0x894040, 0x144200f6010, 0x40aad15000, 0x1442013c000, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x1442013c000, 0x894040, 0x144200f6010, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x1442013c000, 0x894040, 0x144200f6010, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144200c0000, 0x144204e4080)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+
+goroutine 72 [IO wait]:
+internal/poll.runtime_pollWait(0x402b252418, 0x72, 0x144204d0a00)
+	/usr/lib/go-1.10/src/runtime/netpoll.go:173 +0x3c
+internal/poll.(*pollDesc).wait(0x14420276428, 0x72, 0xffffffffffffff01, 0x894b40, 0xa63de0)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:85 +0xa0
+internal/poll.(*pollDesc).waitRead(0x14420276428, 0x144204d0a01, 0x200, 0x200)
+	/usr/lib/go-1.10/src/internal/poll/fd_poll_runtime.go:90 +0x30
+internal/poll.(*FD).Read(0x14420276410, 0x144204d0a00, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/internal/poll/fd_unix.go:157 +0x138
+os.(*File).read(0x144200f6028, 0x144204d0a00, 0x200, 0x200, 0x144204d0a00, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file_unix.go:226 +0x40
+os.(*File).Read(0x144200f6028, 0x144204d0a00, 0x200, 0x200, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/os/file.go:107 +0x48
+bytes.(*Buffer).ReadFrom(0x1442013c070, 0x894040, 0x144200f6028, 0x40aad15000, 0x1442013c070, 0x1)
+	/usr/lib/go-1.10/src/bytes/buffer.go:205 +0x88
+io.copyBuffer(0x8937a0, 0x1442013c070, 0x894040, 0x144200f6028, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:386 +0x294
+io.Copy(0x8937a0, 0x1442013c070, 0x894040, 0x144200f6028, 0x0, 0x0, 0x0)
+	/usr/lib/go-1.10/src/io/io.go:362 +0x44
+os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:275 +0x40
+os/exec.(*Cmd).Start.func1(0x144200c0000, 0x144204e40c0)
+	/usr/lib/go-1.10/src/os/exec/exec.go:396 +0x20
+created by os/exec.(*Cmd).Start
+	/usr/lib/go-1.10/src/os/exec/exec.go:395 +0x468
+--8<---------------------------------------------------------------------
+
+Here's what it is:
+
+--8<---------------------------------------------------------------------
+ubuntu@qemu:~$ /usr/bin/qemu-aarch64-static --version
+qemu-aarch64 version 4.0.91
+Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
+ubuntu@qemu:~$ /usr/bin/qemu-aarch64-static /usr/lib/go-1.10/bin/go version
+go version go1.10.4 linux/arm64
+ubuntu@qemu:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 18.04.2 LTS
+Release:	18.04
+Codename:	bionic
+ubuntu@qemu:~$ uname -a
+Linux qemu 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+ubuntu@qemu:~$ lscpu
+Architecture:        x86_64
+CPU op-mode(s):      32-bit, 64-bit
+Byte Order:          Little Endian
+CPU(s):              24
+On-line CPU(s) list: 0-23
+Thread(s) per core:  1
+Core(s) per socket:  1
+Socket(s):           24
+NUMA node(s):        1
+Vendor ID:           GenuineIntel
+CPU family:          6
+Model:               94
+Model name:          Intel Core Processor (Skylake, IBRS)
+Stepping:            3
+CPU MHz:             2194.916
+BogoMIPS:            4389.83
+Virtualization:      VT-x
+Hypervisor vendor:   KVM
+Virtualization type: full
+L1d cache:           32K
+L1i cache:           32K
+L2 cache:            4096K
+L3 cache:            16384K
+NUMA node0 CPU(s):   0-23
+Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
+--8<---------------------------------------------------------------------
+
+
+The 'qemucrash' test case from this bug still crashes as of current head-of-git (4.1 rc1).
+
+The 'qemucrash' test case problem seems to be because we were incorrectly implementing 'sigaltstack' as setting a process-wide signal stack. This is incorrect, as sigaltstack stacks are supposed to be per-thread, and the Go runtime relies on this. I've just sent a patch which seems to me to fix the qemucrash test case, at least:
+
+https://<email address hidden>/
+
+
+The sigaltstack fix is now in master (commit 5bfce0b74fbd5d530) and at least in my test environment this also fixes the "can't build hello.go reliably" example. So I'm marking this as 'fix committed'. If there are still problems with running Go binaries, these are likely to be independent bugs, so please open fresh LP issues for them.
+
+
+Note that this fix will be in the upcoming 4.1 release.
+
+
diff --git a/results/classifier/zero-shot/108/device/1699628 b/results/classifier/zero-shot/108/device/1699628
new file mode 100644
index 00000000..bd523605
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1699628
@@ -0,0 +1,37 @@
+device: 0.932
+semantic: 0.834
+network: 0.803
+socket: 0.784
+PID: 0.767
+files: 0.764
+vnc: 0.763
+boot: 0.743
+permissions: 0.706
+debug: 0.680
+graphic: 0.675
+performance: 0.587
+other: 0.458
+KVM: 0.141
+
+Direct Sound Audio does not stop
+
+The Bug:
+DirectSound Audio does not stop because dsound_ctl_out does not end up calling IDirectSoundBuffer_Stop. This is due to a bug in dsound_get_status_out where the status flags returned from IDirectSoundBuffer_GetStatus are compared with DSERR_BUFFERLOST (an error code) rather than DSBSTATUS_BUFFERLOST (a status flag). The status is actually (DSBSTATUS_LOOPING | DSBSTATUS_PLAYING) and one of those flags happens to be set in the DSERR_BUFFERLOST value. As a result, dsound_get_status_out returns -1 and dsound_ctl_out exits before calling IDirectSoundBuffer_Stop.
+
+The Fix:
+A simple replacement of DSERR_BUFFERLOST with DSBSTATUS_BUFFERLOST in dsound_get_status_out. 
+Should be: "if (*statusp & DSBSTATUS_BUFFERLOST) {"
+
+Version Information:
+I was able to produce this bug in Qemu 2.9.0 and with the latest source pulled from git://git.qemu-project.org/qemu.git (commit 8dfaf23ae1). I was able to verify my suggested fix with the latest source.
+
+Guest OS:
+Discovered running Minoca OS v0.4 (www.github.com/minoca/os). Images at https://www.minocacorp.com/download/nightlies/latest-x86. The Qemu test images I tried (http://wiki.qemu.org/Testing/System_Images) didn't have an easy sound setup (was looking for 'aplay' or similar).
+
+Qemu Command Line:
+./qemu-system-x86_64.exe -m 512 -hda pc.img -smp 4 -usbdevice keyboard -device intel-hda -device hda-duplex
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4ba664cb0aab
+
+
diff --git a/results/classifier/zero-shot/108/device/1712027 b/results/classifier/zero-shot/108/device/1712027
new file mode 100644
index 00000000..d210e0f7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1712027
@@ -0,0 +1,68 @@
+device: 0.979
+other: 0.896
+graphic: 0.881
+socket: 0.860
+performance: 0.810
+PID: 0.754
+KVM: 0.730
+debug: 0.710
+files: 0.709
+semantic: 0.682
+vnc: 0.682
+boot: 0.634
+network: 0.619
+permissions: 0.613
+
+qemu: Cryptography adding encrypted disk with luks format failed
+
+I'm using libvirt to attach luks encrypted disk to a running VM. The qemu-monitor-command like the 
+
+following:
+
+{"execute":"object-add","arguments":{"qom-type":"secret","id":"virtio-disk11-luks-secret0","props":{"data":"El7jOYLCZwrij2Mue0q2tA==","keyid":"masterKey0","iv":"J2je0WJjCa89L3iKc1lceg==","format":"base64"}}
+
+the masterKey0 specify the secret which has been created before. 
+
+command above return with error message "Incorrect number of padding bytes XXX found on decrypted 
+
+data". This is triggered by the following code snippets in qemu/crypto/secret.c:
+         
+if (plaintext[ciphertextlen - 1] > 16 ||
+             plaintext[ciphertextlen - 1] > ciphertextlen) {
+             error_setg(errp, "Incorrect number of padding bytes (%d) "
+                     "found on decrypted data",
+                     (int)plaintext[ciphertextlen - 1]); 
+                   …
+         }
+
+The bug is: There is on padding in plaintext if the actual length of the plaintext  decrypted is 
+
+equal to ciphertext.
+
+In this case, the last element in plaintext array may be one of the character in base64 code table 
+
+or other.
+
+I would like to know why length of padding bytes cannot exceed 16 and whether i can remove 
+
+judement: “plaintext[ciphertextlen - 1] > 16” so that I can eliminate the error above. 
+
+Much appreciate it if doubts above is cleared up.
+
+libvirt/qemu version:
+
+# virsh version
+Compiled against library: libvirt 3.0.0
+Using library: libvirt 3.0.0
+Using API: QEMU 3.0.0
+Running hypervisor: QEMU 2.7.1
+
+OS: Ubuntu 12.04 LTS
+
+If the alg is GCRY_CIPHER_AES256 and length of data to be encrypted is multiple of 16 (16/32/48...),the length of encryted data is equal to the raw data. There is no padding and the bug is triggerd.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1724 b/results/classifier/zero-shot/108/device/1724
new file mode 100644
index 00000000..cb86a204
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1724
@@ -0,0 +1,60 @@
+device: 0.973
+socket: 0.949
+debug: 0.944
+files: 0.943
+permissions: 0.918
+graphic: 0.914
+boot: 0.901
+network: 0.868
+performance: 0.854
+vnc: 0.818
+PID: 0.800
+semantic: 0.708
+other: 0.357
+KVM: 0.196
+
+qemu-system-riscv64 can't break by gdb
+Description of problem:
+The qemu-system-riscv64 can't break by gdb.  
+( => The target is not responding to interrupt requests.  
+Stop debugging it? (y or n) Quit)  
+
+I using old qemu-system-risc64(7.2) don't has this issue.  
+
+This test case running simple OS(riscv-xv6).
+Steps to reproduce:
+1.qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -global   virtio-mmio.force-legacy=false -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-  device,drive=x0,bus=virtio-mmio-bus.0 -S -gdb tcp::26000  
+  
+  
+2.test@test-VirtualBox:~$ riscv64-unknown-linux-gnu-gdb -q                                                                                                                                                 
+(gdb) target remote :26000  
+Remote debugging using :26000  
+warning: No executable has been specified and target does not support  
+determining executable automatically.  Try using the "file" command.  
+0x0000000000001000 in ?? ()  
+(gdb) c  
+Continuing.  
+
+3.check xv6 is running.  
+xv6 kernel is booting  
+
+hart 2 starting  
+hart 1 starting  
+init: starting sh  
+$  
+
+4.Can't stop by GDB.  
+(gdb) c  
+Continuing.  
+^C^CThe target is not responding to interrupt requests.  
+Stop debugging it? (y or n) Quit  
+(gdb)
+Additional information:
+Test on new QEMU.  
+
+```
+commit cab35c73be9d579db105ef73fa8a60728a890098 (HEAD -> master, origin/staging, origin/master, origin/HEAD)
+Merge: 48ab886d3d d7ee93e243
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jun 20 10:26:53 2023 +0200
+```
diff --git a/results/classifier/zero-shot/108/device/1731347 b/results/classifier/zero-shot/108/device/1731347
new file mode 100644
index 00000000..235830d4
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1731347
@@ -0,0 +1,58 @@
+device: 0.928
+vnc: 0.902
+graphic: 0.893
+network: 0.795
+performance: 0.789
+semantic: 0.762
+KVM: 0.749
+other: 0.699
+debug: 0.624
+socket: 0.617
+PID: 0.602
+files: 0.590
+permissions: 0.576
+boot: 0.452
+
+VFIO Passthrough of SAS2008-based HBA card fails on E3-1225v3 due to failed DMA mapping (-14)
+
+There is a bug preventing multiple people with my combination of hardware from using PCI passthrough. I am not actually sure whether the bug is in kernel/kvm, vfio or qemu, however, as qemu is the highest-level of these, I am reporting the bug here as you will likely know better where the origin of the bug may be found. 
+
+When attempting to pass through this device to a KVM using VFIO, this results in error -14 (Bad Address):
+
+# qemu-system-x86_64 -enable-kvm -m 10G -net none -monitor stdio -serial
+# none -parallel none -vnc :1 -device vfio-pci,host=1:00.0 -S
+QEMU 2.9.1 monitor - type 'help' for more information
+(qemu) c
+(qemu) qemu-system-x86_64: VFIO_MAP_DMA: -14
+qemu-system-x86_64: vfio_dma_map(0x7f548f0a1fc0, 0xfebd0000, 0x2000, 0x7f54a909d000) = -14 (Bad address)
+qemu: hardware error: vfio: DMA mapping failed, unable to continue
+
+See also:
+https://bugzilla.proxmox.com/show_bug.cgi?id=1556
+https://www.redhat.com/archives/vfio-users/2016-May/msg00088.html
+
+This has occurred on Proxmox (Proxmox and Debian packages, Ubuntu kernel), Ubuntu,
+and pure Debian packages and kernel on Proxmox. However, this error
+reportedly does NOT occur for:
+
+- different distributions(!) (Fedora 24, 25)
+- different HBA cards (SAS2308, SAS3008)
+- different CPU (E3-1220v5)
+
+I would be thankful for any input and I'll be happy to provide any further info necessary. This is my first time delving this deep into anything close to the kernel.
+
+Thanks and best regards,
+Johannes Falke
+
+
+
+Hello！
+   Has your problem been solved? I also encountered a similar problem. My ioctl() also returned an error -14(Bad address).
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1732981 b/results/classifier/zero-shot/108/device/1732981
new file mode 100644
index 00000000..43241219
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1732981
@@ -0,0 +1,35 @@
+device: 0.931
+other: 0.798
+network: 0.793
+socket: 0.755
+graphic: 0.746
+semantic: 0.673
+performance: 0.603
+vnc: 0.559
+PID: 0.529
+debug: 0.500
+permissions: 0.462
+boot: 0.449
+files: 0.424
+KVM: 0.256
+
+usb-net on aarch64 has wrong class IDs, isn't recognized by Windows
+
+If I run qemu-system-aarch64 with "-device usb-net,...", the resulting USB device will be seen in the guest as class 0x2, subclass 0x2, protocol 0xFF, instead of the expected class 0xe0, subclass 0x1, protocol 0x3. This prevents Windows' in-box class driver from binding to the device. On x86 and x64 Windows, this is not an issue, as another driver will bind to the device, but in Windows for ARM64, that driver is unavailable, so the USB device is incorrectly recognized as a serial port.
+
+Installing a modified version of the inbox driver in "Disable Driver Signature Enforcement" mode solves the issue, but it's not a very clean solution.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1733720 b/results/classifier/zero-shot/108/device/1733720
new file mode 100644
index 00000000..84216c3e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1733720
@@ -0,0 +1,92 @@
+device: 0.937
+performance: 0.931
+graphic: 0.903
+other: 0.869
+semantic: 0.835
+debug: 0.814
+socket: 0.769
+boot: 0.755
+files: 0.709
+vnc: 0.708
+permissions: 0.568
+network: 0.539
+KVM: 0.500
+PID: 0.458
+
+raspi2 with multiple CPU's #1
+
+Greetings,
+
+I am running a small program for raspi2 (from http://wiki.osdev.org/ARM_RaspberryPi_Tutorial_C).
+
+This code writes "Hello World", but the output ir repeated 4 times.
+
+My thought was that this is emulating a 4 cpu core system.
+
+However, when I check the MPIDR registed for CPU number, it always returns 1.
+
+I git cloned github.com/qemu/qemu.git, made & installed on Acer ARM CB5-311 under Crouton/ubuntu.
+
+
+./qemu.sh 
+1111
+
+Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> uname -a
+Linux localhost 3.10.18 #1 SMP Mon Nov 13 16:34:10 PST 2017 armv7l armv7l armv7l GNU/Linux
+
+Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> qemu-system-arm --version
+QEMU emulator version 2.10.91 (v2.11.0-rc1-dirty)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+=====
+static inline uint32_t read_mpdir(void)
+{
+  uint32_t id;
+  
+  asm volatile("mrc p15, 0, %[id], c0, c0, 0 @ read MIDR\n\t"
+	       : [id] "=r" (id));
+  return id;
+}
+======
+void kernel_main(uint32_t r0, uint32_t r1, uint32_t atags)
+{
+	// Declare as unused
+	(void) r0;
+	(void) r1;
+	(void) atags;
+
+	uint32_t cpu_id;
+
+	cpu_id = read_mpdir() & 0x03;
+
+	uart_putc( "01234"[cpu_id] ); /* output is "1111" */
+
+	if (cpu_id == 0) { /* code never executes 8^( */ }
+
+====== qemu.sh
+qemu-system-arm -m 256 -M raspi2 -no-reboot -serial stdio  -kernel myos.elf
+
+Thanks much,
+-KenD
+
+NOT A BUG
+
+Reviewed the code and found the problem.
+
+asm volatile("mrc p15, 0, %[id], c0, c0, 0 @ read MIDR\n\t" ...
+
+I miscopied the code above; MIDR should have been MIPDR ( 5 )
+
+I now get:
+
+Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> ./qemu.sh 
+0H312ello, kernel World!
+
+Sorry about the bogus report!
+-KenD
+
+Sorry again, "MPIDR" 
+
+Gotta learn to type!
+
+
diff --git a/results/classifier/zero-shot/108/device/1737194 b/results/classifier/zero-shot/108/device/1737194
new file mode 100644
index 00000000..4dd2f9f6
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1737194
@@ -0,0 +1,644 @@
+device: 0.963
+boot: 0.954
+socket: 0.945
+semantic: 0.943
+KVM: 0.940
+PID: 0.937
+graphic: 0.930
+permissions: 0.930
+vnc: 0.919
+performance: 0.911
+files: 0.907
+other: 0.905
+debug: 0.901
+network: 0.874
+
+Windows NT 4.0 fails to boot from qcow2 installation
+
+Windows NT 4.0 will not boot from an installation more than once if installed in a qcow2 image file. A quick fix to this problem is to use the qcow format instead.
+
+Steps to reproduce this issue:
+
+Create the image file:
+qemu-img create -f qcow2 winnt4.qcow2 1G
+
+Boot from a Windows NT 4.0 Workstation CD:
+qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
+
+During the installation process you have the choise between FAT and NTFS. You can pick anyone.
+
+After finishing the installation the guest will reboot to install additional items. Once this is done the guest will be bootable. Eject any CD media from QEMU and reboot. You will then see Windows NT 4.0 booting up to the desktop. Go to "Start->Shut down" to shut down. Then when Windows is ready quit QEMU. 
+
+Now try to boot using this command:
+qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus 
+ 
+The BIOS screen will display an error message:
+
+For NTFS: 
+Booting from Hard Disk...
+A disk read error occurred.
+Insert a system diskette and restart
+the system.
+
+For FAT:
+No bootable device.
+
+Additional information:
+qemu-system-i386 version: 2.10.1
+qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
+
+If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
+https://winworldpc.com/product/windows-nt-40/40
+
+If you do two identical installs with qcow2 and raw, do you see any differences with qemu-img compare afterwards that might indicate what could possibly have gone wrong?
+
+
+> On Dec 8, 2017, at 1:41 PM, John Snow <email address hidden> wrote:
+> 
+> If you do two identical installs with qcow2 and raw, do you see any
+> differences with qemu-img compare afterwards that might indicate what
+> could possibly have gone wrong?
+
+I think what you want is for me to compare a broken qcow2 file with a working qcow file. I'm not sure how to do that but if you sent me directions I can send you the results. 
+
+I did try using the broken qcow2 file in a Windows XP VM. When I try to open the "Program Files" folder I see this error message: "D:\Program Files is not accessible. The file or directory is corrupted and unreadable". The WINNT folder does open.
+
+I tried checking the disk with Windows XP's disk repair utility. It failed to complete and displayed this error message: "Windows was unable to complete the disk check".
+
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1737194
+> 
+> Title:
+>  Windows NT 4.0 fails to boot from qcow2 installation
+> 
+> Status in QEMU:
+>  New
+> 
+> Bug description:
+>  Windows NT 4.0 will not boot from an installation more than once if
+>  installed in a qcow2 image file. A quick fix to this problem is to use
+>  the qcow format instead.
+> 
+>  Steps to reproduce this issue:
+> 
+>  Create the image file:
+>  qemu-img create -f qcow2 winnt4.qcow2 1G
+> 
+>  Boot from a Windows NT 4.0 Workstation CD:
+>  qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
+> 
+>  During the installation process you have the choise between FAT and
+>  NTFS. You can pick anyone.
+> 
+>  After finishing the installation the guest will reboot to install
+>  additional items. Once this is done the guest will be bootable. Eject
+>  any CD media from QEMU and reboot. You will then see Windows NT 4.0
+>  booting up to the desktop. Go to "Start->Shut down" to shut down. Then
+>  when Windows is ready quit QEMU.
+> 
+>  Now try to boot using this command:
+>  qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus 
+> 
+>  The BIOS screen will display an error message:
+> 
+>  For NTFS: 
+>  Booting from Hard Disk...
+>  A disk read error occurred.
+>  Insert a system diskette and restart
+>  the system.
+> 
+>  For FAT:
+>  No bootable device.
+> 
+>  Additional information:
+>  qemu-system-i386 version: 2.10.1
+>  qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
+> 
+>  If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
+>  https://winworldpc.com/product/windows-nt-40/40
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions
+
+
+
+Hi,
+
+I've been experiencing various disk I/O issues with Windows NT too, as well as with Windows 3.1. I think `-M isapc` may be to blame somehow.
+
+I've documented my experiences over at https://bugs.launchpad.net/qemu/+bug/1745312.
+
+That report contains information on how to lift out and build the before-and-after QEMU commits that I think relate to this being broken. John Arbuckle, perhaps you could run through that and see if you continue to have issues.
+
+I was initially going to post that report as a comment in this thread, until I realized I was having I/O issues on multiple operating systems.
+
+> On Jan 25, 2018, at 2:53 AM, i336_ <email address hidden> wrote:
+> 
+> Hi,
+> 
+> I've been experiencing various disk I/O issues with Windows NT too, as
+> well as with Windows 3.1. I think `-M isapc` may be to blame somehow.
+> 
+> I've documented my experiences over at
+> https://bugs.launchpad.net/qemu/+bug/1745312.
+> 
+> That report contains information on how to lift out and build the
+> before-and-after QEMU commits that I think relate to this being broken.
+> John Arbuckle, perhaps you could run through that and see if you
+> continue to have issues.
+> 
+> I was initially going to post that report as a comment in this thread,
+> until I realized I was having I/O issues on multiple operating systems.
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1737194
+> 
+> Title:
+>  Windows NT 4.0 fails to boot from qcow2 installation
+> 
+> Status in QEMU:
+>  New
+> 
+> Bug description:
+>  Windows NT 4.0 will not boot from an installation more than once if
+>  installed in a qcow2 image file. A quick fix to this problem is to use
+>  the qcow format instead.
+> 
+>  Steps to reproduce this issue:
+> 
+>  Create the image file:
+>  qemu-img create -f qcow2 winnt4.qcow2 1G
+> 
+>  Boot from a Windows NT 4.0 Workstation CD:
+>  qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
+> 
+>  During the installation process you have the choise between FAT and
+>  NTFS. You can pick anyone.
+> 
+>  After finishing the installation the guest will reboot to install
+>  additional items. Once this is done the guest will be bootable. Eject
+>  any CD media from QEMU and reboot. You will then see Windows NT 4.0
+>  booting up to the desktop. Go to "Start->Shut down" to shut down. Then
+>  when Windows is ready quit QEMU.
+> 
+>  Now try to boot using this command:
+>  qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus 
+> 
+>  The BIOS screen will display an error message:
+> 
+>  For NTFS: 
+>  Booting from Hard Disk...
+>  A disk read error occurred.
+>  Insert a system diskette and restart
+>  the system.
+> 
+>  For FAT:
+>  No bootable device.
+> 
+>  Additional information:
+>  qemu-system-i386 version: 2.10.1
+>  qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
+> 
+>  If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
+>  https://winworldpc.com/product/windows-nt-40/40
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions
+
+I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my Mac OS X system. Here is the error message I usually saw: 
+
+  LINK  qemu-io
+Undefined symbols for architecture x86_64:
+  "_use_rt_clock", referenced from:
+      _bdrv_acct_start in block.o
+      _bdrv_acct_done in block.o
+Undefined symbols for architecture x86_64:
+      _qemu_clock_get_ns in qemu-timer.o
+  "_use_rt_clock", referenced from:
+      _bdrv_acct_start in block.o
+      _bdrv_acct_done in block.o
+      _qemu_clock_get_ns in qemu-timer.o
+
+In your report you mention using the raw disk image format and VHD(x). I have had great success with the qcow image format. Could you try it and let us know if it fixes things for you?
+
+To create a qcow image file:
+ qemu-img create -f qcow <HD image file name>.qcow 1G
+
+
+
+On 25 January 2018 at 15:58, John Arbuckle <email address hidden> wrote:
+> I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc
+> and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my
+> Mac OS X system. Here is the error message I usually saw:
+>
+>   LINK  qemu-io
+> Undefined symbols for architecture x86_64:
+>   "_use_rt_clock", referenced from:
+>       _bdrv_acct_start in block.o
+>       _bdrv_acct_done in block.o
+> Undefined symbols for architecture x86_64:
+>       _qemu_clock_get_ns in qemu-timer.o
+>   "_use_rt_clock", referenced from:
+>       _bdrv_acct_start in block.o
+>       _bdrv_acct_done in block.o
+>       _qemu_clock_get_ns in qemu-timer.o
+
+If you configure with --disable-tools does it manage to build,
+or does it just go on to fail to link the main QEMU binary
+with the same error? (We've had some issues in the past I think
+where configure put libraries on the main binary link line but
+not on the tools link lines, so maybe worth a try...)
+
+thanks
+-- PMM
+
+
+> # WinNT 4 Terminal Server
+> 
+> Most of the time, NTLDR will fire up normally. But every so often...
+> 
+>   SeaBIOS (version rel-1.7.3-117-g31b8b4e-20131206_080705-nilsson.home.kraxel.org)
+> 
+>   Booting from Hard Disk...
+>   A disk read error occurred.
+>   Insert a system diskette and restart
+>   the system.
+> 
+> (NB. You're seeing the old SeaBIOS version included with e689f7c, which was the first buggy commit.)
+> 
+> If NT gets past this point without erroring out (ie, it makes it to the boot menu), the rest of the system is 100% fine and there are no other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to enable disk compression, answer "Yes" to "Compress entire disk now?" and have the process fully complete. No hitches.
+> 
+
+I tried adding -M isapc to my Windows NT 4.0 VM's arguments and I saw the same error message at first. Then I tried it again by making a few changes. I played with the network card settings and removed the "-M isapc" argument to make things work again. Then I went back and added the "-M isapc" option again and Windows booted. I restarted several times and didn't see the error message. I am using qemu-system-i386 version 2.10.1. Just to see if I could see any of the disk errors you saw I ran in the command prompt "chkdsk c:" a couple of times. It came back with no errors every time. 
+
+
+> On Jan 25, 2018, at 11:16 AM, Peter Maydell <email address hidden> wrote:
+> 
+> On 25 January 2018 at 15:58, John Arbuckle <email address hidden> wrote:
+>> I did try to build at commits 306ec6c3cece7004429c79c1ac93d49919f1f1cc
+>> and e689f7c668cbd9d08f330e17c3dd3a059c9553d3. Both failed to build on my
+>> Mac OS X system. Here is the error message I usually saw:
+>> 
+>>  LINK  qemu-io
+>> Undefined symbols for architecture x86_64:
+>>  "_use_rt_clock", referenced from:
+>>      _bdrv_acct_start in block.o
+>>      _bdrv_acct_done in block.o
+>> Undefined symbols for architecture x86_64:
+>>      _qemu_clock_get_ns in qemu-timer.o
+>>  "_use_rt_clock", referenced from:
+>>      _bdrv_acct_start in block.o
+>>      _bdrv_acct_done in block.o
+>>      _qemu_clock_get_ns in qemu-timer.o
+> 
+> If you configure with --disable-tools does it manage to build,
+> or does it just go on to fail to link the main QEMU binary
+> with the same error? (We've had some issues in the past I think
+> where configure put libraries on the main binary link line but
+> not on the tools link lines, so maybe worth a try...)
+> 
+> thanks
+> -- PMM
+> 
+
+It still fails to build: 
+
+Build commands: ./configure --disable-tools --target-list=i386-softmmu && make -j 4
+
+QEMU at commit: 306ec6c3cece7004429c79c1ac93d49919f1f1cc
+
+  LINK  i386-softmmu/qemu-system-i386
+Undefined symbols for architecture x86_64:
+  "_use_rt_clock", referenced from:
+      _bdrv_acct_start in block.o
+      _bdrv_acct_done in block.o
+      _qemu_clock_get_ns in qemu-timer.o
+      _cpu_get_clock in cpus.o
+      _cpu_enable_ticks in cpus.o
+      _cpu_disable_ticks in cpus.o
+      _icount_warp_rt in cpus.o
+      ...
+ld: symbol(s) not found for architecture x86_64
+clang: error: linker command failed with exit code 1 (use -v to see invocation)
+make[1]: *** [qemu-system-i386] Error 1
+make: *** [subdir-i386-softmmu] Error 2
+
+
+
+
+On 25 January 2018 at 16:43, John Arbuckle <email address hidden> wrote:
+>> On Jan 25, 2018, at 11:16 AM, Peter Maydell <email address hidden> wrote:
+>> If you configure with --disable-tools does it manage to build,
+>> or does it just go on to fail to link the main QEMU binary
+>> with the same error?
+
+> It still fails to build:
+
+That's a shame. Thanks for testing. I guess there was a bug that
+we fixed at some point but figuring out what the bug fix was and
+backporting it to the commits to be tested is probably too much
+effort to be worthwhile.
+
+-- PMM
+
+
+Hi John & others:
+
+(3 separate things.)
+
+1: Image formats
+
+Regarding qcow, unfortunately there is no change if I use this format.
+
+- Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it crashed when it decided it couldn't find COMMAND.COM (a frequent failure mode I forgot to mention).
+
+- NT initially crashed with one of its famous disk read errors. Of course.
+
+- After the initial NT crash, repeated QEMU reloads began showing the boot menu rather consistently, so I pointed my test harness to the qcow image. Of course, it crashed on the first try in the test harness :), then launched successfully 42 times before crashing again. This sort of behavior is pretty consistent with what happened with raw images.
+
+I just did 77 runs with commit 306ec6c and the qcow image worked just as well as the raw image did.
+
+One thing. I converted my raw disk images to qcow so I could test and reply somewhat more quickly. (Just stumbled on the new activity in the thread after manually checking a couple hours ago, glad I did!. I'm actually subscribed now :) )
+
+It could be strongly argued that I should create _new_ disk images. But my three counter-arguments are that
+
+ a) the storage format shouldn't influence the guest.
+ b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that.
+ c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b).
+
+If anyone wants to strongly argue for creating new images, I can try that. *resigned grumble*
+
+Also... is qcow working stably for you, with no issues? If it is I'm very fascinated to hear that.
+
+And - you're using `-M isapc`, right? I find that if I don't, NT will hit a STOP error pretty much instantaneously (within the first few fractions of a second after it's obvious the kernel has initialized).
+
+---
+
+2: Bitness
+
+The few error messages I saw in your build failure hinted at 64-bit incompatibility.
+
+Well... I was able, at length, to get QEMU to build for 32-bit. It mostly boiled down to careful analysis of config-host.mak, removing -m64 and substituting -m32, and poking {C,LD}FLAGS until it compiled.
+
+As I noted in the other thread, the built QEMU had a 100% broken TCG and required some form of hardware acceleration to even start correctly. In my case this was KVM.
+
+Oh, also, on the subject of compilation - this isn't bitness-related, but QEMU's Makefiles accept the standard `V=2` for verbose build that shows the compilation commands. I'd imagine the result would probably be best attached as a file. I have no idea if this information will be useful to the QEMU developers.
+
+---
+
+3: Bisection
+
+I initially thought to cram this info somewhere in the I/O report but decided against it due to that post's final length. But it could be relevant here.
+
+Here's the approach I used to rapidly bounce back and forth and in search of the before-and-after "edges". I used this for the I/O issues discussed here and also for another issue (https://bugs.launchpad.net/qemu/+bug/1745316), and if you feel like it, you could use this to track down why the older QEMU versions are not building on OS X.
+
+This could be worth it - the fixes could be minimal and a hacky "good enough" backport could be viable, or this may just end up confirming that the breakage was major.
+
+I'll just document the exact workflow I used.
+
+First, I created a new base directory somewhere, to hold all the subdirs with branches I'd be testing.
+
+Next, I switched to the dir with the qemu git checkout, and:
+
+$ git rev-list 306ec6c3cece7004429c79c1ac93d49919f1f1cc..master | tac | nl -n ln > /path/to/basedir/branchlist.txt
+
+$ Now for the wince part:
+
+$ wc -l branchlist.txt
+28734
+
+Wooooo!
+(...not.)
+
+[Note: I'm using a fractionally old local clone. That number, and all the numbers below, are likely going to be slightly bigger.]
+
+Now, define this function (my interactive sessions use bash, this may work with zsh/others):
+
+$ z() { n="$1"; b="$(grep "^$n[^0-9]" /path/to/basedir/branchlist.txt | cut -d$'\t' -f2)"; sb="${b:0:7}"; d="/path/to/basedir/$n-$sb/"; mkdir "$d"; git archive "$b" | tar xC "$d"; }
+
+Now, you can just do something like
+
+$ z 14367
+
+and then, in a separate terminal, you can cd over to the newly-created /path/to/basedir/14367-1bfa316/, and configure and build it.
+
+The function just lets you refer to the commits by number as you work, which makes it much easier (indeed, possible at all) to select which commit to build, and also keep track of where you're up to.
+
+NOTE: The `tac` in the line that generated branchlist.txt means that commit 1 will be older than commit 28734. Smaller numbers go back in time, which makes sense to me. For opposite behavior remove the `tac`.
+
+The number in the `z` line above is 28734/2, ie, this jumps straight into the middle of the list. (Of (obvious) note is that the generated list does not represent _all_ the commits.) If that commit fails to build, you might jump back by half, eg 7184. If that one works, you might jump forward by half, or 21550.
+
+It's kind of meditative... but it does get irritating toward the end when you're jumping forward by 30... then back by 7... then forward by 3... (like an annoying padlock!)
+
+(I can strongly recommend keeping notes of which builds worked and which didn't. I totally didn't jump in the wrong direction a few times...)
+
+If you're so inclined, you could probably wrap all of this into a bit of automation. `make`'s return code is admittedly much much easier to script off of than hooking up a test harness to do a bunch of automated runs and deciding for itself whether it produced a fail or pass. Or (in the case of the other bug I found), testing mouse movements. For these reasons it was much easier for me to use this workflow manually.
+
+Even with a starting list of nearly 30k commits, this works exponentially at best, and better-than-exponentially if you decide to arbitrarily jump back or forward by more than half. So while this isn't a 10-minute job, it _shouldn't_ take all day, either.
+
+
+
+> On Jan 26, 2018, at 9:51 AM, David Lindsay <email address hidden> wrote:
+> 
+> Hi John & others:
+> 
+> (3 separate things.)
+> 
+> 1: Image formats
+> 
+> Regarding qcow, unfortunately there is no change if I use this format.
+> 
+> - Windows 3.1 initially hung at "Starting MS-DOS..."; upon restart it
+> crashed when it decided it couldn't find COMMAND.COM (a frequent failure
+> mode I forgot to mention).
+
+I have tried using Windows 3.1 in QEMU in the past. It was a long time ago so I will have to go back and try it again. Hopefully one of the files here would help: https://winworldpc.com/product/windows-3/31
+
+> 
+> - NT initially crashed with one of its famous disk read errors. Of
+> course.
+> 
+> - After the initial NT crash, repeated QEMU reloads began showing the
+> boot menu rather consistently, so I pointed my test harness to the qcow
+> image. Of course, it crashed on the first try in the test harness :),
+> then launched successfully 42 times before crashing again. This sort of
+> behavior is pretty consistent with what happened with raw images.
+> 
+> I just did 77 runs with commit 306ec6c and the qcow image worked just as
+> well as the raw image did.
+
+Have you tried the latest commit or release of QEMU yet?
+
+> It could be strongly argued that I should create _new_ disk images. But
+> my three counter-arguments are that
+> 
+> a) the storage format shouldn't influence the guest.
+
+This is what I thought. But this is just a theory. It doesn't work in real life.
+
+> b) I exhaustively tested the bisection point I found, and the "before" state is absolutely rock solid. I'd say I've tested 450+ consecutive good runs without any hitches at this point - the 350 runs I documented, and a hundred or so more that I did before that.
+> c) it could be very well argued that QEMU-level errors have left corruption in the disk image. My argument here is to reiterate (b).
+> 
+> If anyone wants to strongly argue for creating new images, I can try
+> that. *resigned grumble*
+> 
+> Also... is qcow working stably for you, with no issues? If it is I'm
+> very fascinated to hear that.
+
+That is correct. I went back to QEMU 0.9 and tried a bunch of releases to around 2.x until I realized it was the image file that was the problem. I must have installed Windows NT 4.0 around 20 times before finding the answer to my problem. 
+
+> And - you're using `-M isapc`, right? I find that if I don't, NT will
+> hit a STOP error pretty much instantaneously (within the first few
+> fractions of a second after it's obvious the kernel has initialized).
+
+Actually I like using the PCI network cards so I never had a reason to use "-M isapc" until you contacted me. Windows NT 4.0 runs rock solid for me without it. The only issue I noticed is when I play StarCraft in my Windows NT 4.0 VM, the mouse starts moving around erratically after around 45 minutes of use.
+
+
+> 2: Bitness
+> 
+> The few error messages I saw in your build failure hinted at 64-bit
+> incompatibility.
+> 
+> Well... I was able, at length, to get QEMU to build for 32-bit. It
+> mostly boiled down to careful analysis of config-host.mak, removing -m64
+> and substituting -m32, and poking {C,LD}FLAGS until it compiled.
+> 
+> As I noted in the other thread, the built QEMU had a 100% broken TCG and
+> required some form of hardware acceleration to even start correctly. In
+> my case this was KVM.
+
+I'm not too sure about 32-bit host support. All my QEMU-running computers are 64-bit. If you have figured out how to fix these problems making patch and sending it in would probably help a lot of people. Let me know if you need help doing this.
+
+> 
+> 3: Bisection
+> 
+> I initially thought to cram this info somewhere in the I/O report but
+> decided against it due to that post's final length. But it could be
+> relevant here.
+> 
+> Here's the approach I used to rapidly bounce back and forth and in
+> search of the before-and-after "edges". I used this for the I/O issues
+> discussed here and also for another issue
+> (https://bugs.launchpad.net/qemu/+bug/1745316), and if you feel like it,
+> you could use this to track down why the older QEMU versions are not
+> building on OS X.
+
+The thing is if the newest versions of QEMU work, why try debugging an older version?
+
+> 
+> This could be worth it - the fixes could be minimal and a hacky "good
+> enough" backport could be viable, or this may just end up confirming
+> that the breakage was major.
+> 
+> I'll just document the exact workflow I used.
+
+<snip>
+
+> It's kind of meditative... but it does get irritating toward the end
+> when you're jumping forward by 30... then back by 7... then forward by
+> 3... (like an annoying padlock!)
+
+'git bisect' is a lot easier to use. It does most of the work for you.
+
+<snip>
+
+> Even with a starting list of nearly 30k commits, this works
+> exponentially at best, and better-than-exponentially if you decide to
+> arbitrarily jump back or forward by more than half. So while this isn't
+> a 10-minute job, it _shouldn't_ take all day, either.
+
+Sorry I couldn't help with verifying the commits you wanted me to test out. I tried seeing if I could make a quick hack to make QEMU compile but I realized the hack would probably add to the problems we are facing. 
+
+I have just found some Windows 95 iso's that I will try out in QEMU 2.11. I will let you know if I notice any disk corruption issues. 
+
+
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1737194
+> 
+> Title:
+>  Windows NT 4.0 fails to boot from qcow2 installation
+> 
+> Status in QEMU:
+>  New
+> 
+> Bug description:
+>  Windows NT 4.0 will not boot from an installation more than once if
+>  installed in a qcow2 image file. A quick fix to this problem is to use
+>  the qcow format instead.
+> 
+>  Steps to reproduce this issue:
+> 
+>  Create the image file:
+>  qemu-img create -f qcow2 winnt4.qcow2 1G
+> 
+>  Boot from a Windows NT 4.0 Workstation CD:
+>  qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
+> 
+>  During the installation process you have the choise between FAT and
+>  NTFS. You can pick anyone.
+> 
+>  After finishing the installation the guest will reboot to install
+>  additional items. Once this is done the guest will be bootable. Eject
+>  any CD media from QEMU and reboot. You will then see Windows NT 4.0
+>  booting up to the desktop. Go to "Start->Shut down" to shut down. Then
+>  when Windows is ready quit QEMU.
+> 
+>  Now try to boot using this command:
+>  qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus 
+> 
+>  The BIOS screen will display an error message:
+> 
+>  For NTFS: 
+>  Booting from Hard Disk...
+>  A disk read error occurred.
+>  Insert a system diskette and restart
+>  the system.
+> 
+>  For FAT:
+>  No bootable device.
+> 
+>  Additional information:
+>  qemu-system-i386 version: 2.10.1
+>  qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
+> 
+>  If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
+>  https://winworldpc.com/product/windows-nt-40/40
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1737194/+subscriptions
+
+
+
+I have installed Windows 95 OSR 2.5 in QEMU using the qcow2 format. So far there hasn't been any major problems that prevent Windows from booting. 
+
+I downloaded the ISO file from here: https://winworldpc.com/product/windows-95/osr-3
+
+Used this floppy boot image to boot QEMU: https://winworldpc.com/product/microsoft-windows-boot-disk/95-osr2x
+
+Created the hard drive image file like this: qemu-img create -f qcow2 ~/windows95.qcow2 2G
+
+I used my Windows XP VM to format this qcow2 file to the FAT format. 
+
+My first attempt to boot the hard drive image file failed probably because the CPU was set to something Windows 95 couldn't handle properly. Changing the cpu to a pentium removed the booting problem. 
+
+This is the command-line I used to boot Windows 95:
+qemu-system-i386 -hda windows95.qcow2 -boot c -netdev user,id=mynet0 -device ne2k_isa,netdev=mynet0 -soundhw sb16 -m 32 -cpu pentium -vga cirrus -localtime 
+
+The version of QEMU I used is today's git version (commit e607bbee553cfe73072870cef458cfa4e78133e2).
+
+
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/174 b/results/classifier/zero-shot/108/device/174
new file mode 100644
index 00000000..135225a9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/174
@@ -0,0 +1,16 @@
+device: 0.983
+performance: 0.770
+semantic: 0.359
+graphic: 0.330
+boot: 0.272
+permissions: 0.210
+PID: 0.158
+vnc: 0.077
+other: 0.069
+debug: 0.039
+files: 0.033
+socket: 0.021
+network: 0.018
+KVM: 0.017
+
+European keyboard PC-105 deadkey
diff --git a/results/classifier/zero-shot/108/device/1744654 b/results/classifier/zero-shot/108/device/1744654
new file mode 100644
index 00000000..f3fecb23
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1744654
@@ -0,0 +1,22 @@
+device: 0.948
+graphic: 0.936
+socket: 0.895
+semantic: 0.865
+network: 0.813
+permissions: 0.676
+vnc: 0.669
+KVM: 0.655
+files: 0.652
+PID: 0.651
+other: 0.563
+performance: 0.549
+debug: 0.485
+boot: 0.474
+
+commit: 4fe6d78 "virtio: postpone the execution of event_notifier_cleanup function" will cause vhost-user device crash
+
+The new commit: 4fe6d78 break the existing vhost-user devices, such as vhost-user-scsi/blk and vhost-vsocks when exit the host driver,  kvm_io_ioeventfd_del will hit the abort().
+
+Thanks for the bug report. Patch has now been reverted:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1ef8185a0613dd2ed2
+
diff --git a/results/classifier/zero-shot/108/device/1745895 b/results/classifier/zero-shot/108/device/1745895
new file mode 100644
index 00000000..0665160d
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1745895
@@ -0,0 +1,50 @@
+device: 0.949
+PID: 0.906
+debug: 0.894
+network: 0.878
+socket: 0.877
+performance: 0.830
+graphic: 0.803
+semantic: 0.763
+other: 0.743
+permissions: 0.734
+vnc: 0.687
+boot: 0.652
+KVM: 0.602
+files: 0.556
+
+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.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1748 b/results/classifier/zero-shot/108/device/1748
new file mode 100644
index 00000000..e64a42fd
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1748
@@ -0,0 +1,71 @@
+device: 0.969
+graphic: 0.949
+performance: 0.879
+files: 0.869
+debug: 0.816
+PID: 0.792
+KVM: 0.756
+boot: 0.690
+semantic: 0.669
+network: 0.658
+vnc: 0.651
+permissions: 0.648
+socket: 0.617
+other: 0.406
+
+qcow2: disk size exceeds virtual size
+Description of problem:
+Disk size of qcow2 image file exceeds its virtual size after repeatedly writing, and deleting data in qemu vm.
+Steps to reproduce:
+1. qemu-img create -f qcow2 tmp.qcow2 32M
+2. attach tmp.qcow2 as a device to qemu vm
+3. mount the device in qemu vm, and repeatedly writing, and deleting data
+Additional information:
+xml for attaching tmp.qcow2
+```xml
+   <disk device="disk" type="file">
+      <target bus="virtio" dev="vdb"/>
+      <source file="/path/to/tmp.qcow2"/>
+      <driver type="qcow2" name="qemu" cache="none" discard="unmap"/>
+   </disk>
+```
+in fact, set discard="unmap" or not seems has `little impact` on the final result.
+reproducible shell script.
+```sh
+#! /bin/sh
+
+for i in {1..1000}; do
+    for j in {1..27}; do
+        dd if=/dev/zero of=/mnt/test-$j bs=1M count=1 &
+    done
+    sync
+    sleep 10
+    rm -f /mnt/test-*   
+    fstrim /mnt
+done
+```
+MOUNT the device and run this script, problem happens about 30 minutes.
+
+final result looks like:
+```sh
+# qemu-img info tmp.qcow2 --force
+image: tmp.qcow2
+file format: qcow2
+virtual size: 32 MiB (33554432 bytes)
+disk size: 33 MiB
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+Child node '/file':
+    filename: tmp.qcow2
+    protocol type: file
+    file length: 32.3 MiB (33882112 bytes)
+    disk size: 33 MiB
+    Format specific information:
+        extent size hint: 1048576
+```
diff --git a/results/classifier/zero-shot/108/device/1759 b/results/classifier/zero-shot/108/device/1759
new file mode 100644
index 00000000..7286b058
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1759
@@ -0,0 +1,25 @@
+device: 0.948
+graphic: 0.929
+files: 0.893
+boot: 0.865
+PID: 0.768
+debug: 0.740
+vnc: 0.603
+performance: 0.543
+socket: 0.512
+semantic: 0.379
+network: 0.293
+other: 0.282
+permissions: 0.244
+KVM: 0.030
+
+qemu-system-i386 error during install windows 95/98
+Description of problem:
+Installation of the Windows starts but when Windows 95 is supposed to copy files it failes like: ![qemu803_win95](/uploads/40e94adda4cdf5c57fa751d5db04ef7b/qemu803_win95.png)
+Installation of Windows 98 failes like: ![qemu803_win98](/uploads/110ece638cd71f8ec41dd029379af807/qemu803_win98.png)
+Steps to reproduce:
+1. get boot floppy & install cd for windows 95
+2. create hard drive C image
+3. try to install Windows 95
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/1760176 b/results/classifier/zero-shot/108/device/1760176
new file mode 100644
index 00000000..2a9332c1
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1760176
@@ -0,0 +1,88 @@
+device: 0.973
+other: 0.970
+graphic: 0.963
+boot: 0.960
+performance: 0.960
+PID: 0.957
+semantic: 0.953
+files: 0.945
+socket: 0.911
+permissions: 0.910
+debug: 0.874
+vnc: 0.865
+network: 0.815
+KVM: 0.704
+
+optical drive doesn't open in Lubuntu 18.04 on '12 MacPro
+
+Running an install to HD of Lubuntu 18.04 and after running update/upgrade this morning now the optical drive door doesn't respond to keyboard "eject" key on a Mac keyboard for '12 MacPro . . . .  I tried to use "xfburn" to get the door to open, nothing seems to get it to work that I know of.  Yesterday there was no issue . . . .  Tried to run "apt -f install" and it showed some old kernels to "autoremove" . . . which I did; didn't try to reboot into old kernel to test, perhaps now old kernel is gone?
+
+F
+
+Sorry, I'm not sure if I understand you.
+
+Does this bug have anything to do with QEMU? Are you running a virtual machine?
+
+If so:
+(A) What is your host OS, version, and QEMU version?
+(B) What is your guest OS and version?
+(C) What are you trying to do, and
+(D) What is the expected behavior?
+
+@John Snow:
+
+Don't know on the "QEMU" front, this is install to HD partitions of Lu
+18.04 . . . while trying to burn an iso to DVD, pressing the "eject"
+keyboard button will not open the open drive door, so no DVD can be put
+there . . . problem remains in Lu.  Whereas I have a couple installs of
+OpenSUSE & OSX and the keyboard "eject" button works without issue . . . .
+
+
+You probably meant to file this bug against a different component, you've filed it against QEMU which is an emulator/hypervisor for VMs.
+
+@John:
+
+Thanks for the clarification . . . don't know how that happened, although
+it is very obtuse as far as even getting to the "report a bug filing" place
+. . . but I didn't select QEMU or even mention that in my comments . . . .
+Any way to change that in this bug number, or it has to be a "fresh" start?
+
+
+
+On Wed, Apr 4, 2018 at 8:00 AM, John Snow <email address hidden>
+wrote:
+
+> You probably meant to file this bug against a different component,
+> you've filed it against QEMU which is an emulator/hypervisor for VMs.
+>
+> ** Changed in: qemu
+>        Status: Incomplete => Invalid
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1760176
+>
+> Title:
+>   optical drive doesn't open in Lubuntu 18.04 on '12 MacPro
+>
+> Status in QEMU:
+>   Invalid
+>
+> Bug description:
+>   Running an install to HD of Lubuntu 18.04 and after running
+>   update/upgrade this morning now the optical drive door doesn't respond
+>   to keyboard "eject" key on a Mac keyboard for '12 MacPro . . . .  I
+>   tried to use "xfburn" to get the door to open, nothing seems to get it
+>   to work that I know of.  Yesterday there was no issue . . . .  Tried
+>   to run "apt -f install" and it showed some old kernels to "autoremove"
+>   . . . which I did; didn't try to reboot into old kernel to test,
+>   perhaps now old kernel is gone?
+>
+>   F
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1760176/+subscriptions
+>
+
+
diff --git a/results/classifier/zero-shot/108/device/1761 b/results/classifier/zero-shot/108/device/1761
new file mode 100644
index 00000000..2ee7b3a5
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1761
@@ -0,0 +1,16 @@
+device: 0.922
+performance: 0.709
+graphic: 0.594
+boot: 0.501
+debug: 0.485
+semantic: 0.335
+vnc: 0.280
+PID: 0.197
+permissions: 0.160
+other: 0.089
+network: 0.076
+socket: 0.071
+KVM: 0.058
+files: 0.018
+
+vexpress-a9 board maps both RAM and flash at address 0
diff --git a/results/classifier/zero-shot/108/device/1767 b/results/classifier/zero-shot/108/device/1767
new file mode 100644
index 00000000..c8dede87
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1767
@@ -0,0 +1,18 @@
+device: 0.926
+performance: 0.731
+graphic: 0.495
+other: 0.444
+semantic: 0.375
+boot: 0.337
+debug: 0.267
+permissions: 0.223
+network: 0.191
+PID: 0.118
+files: 0.101
+KVM: 0.087
+vnc: 0.030
+socket: 0.008
+
+Add iphone emulated device
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/1769 b/results/classifier/zero-shot/108/device/1769
new file mode 100644
index 00000000..fdf4bd42
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1769
@@ -0,0 +1,16 @@
+device: 0.960
+performance: 0.859
+network: 0.674
+graphic: 0.627
+other: 0.365
+permissions: 0.293
+debug: 0.291
+semantic: 0.266
+boot: 0.212
+files: 0.071
+PID: 0.064
+socket: 0.058
+vnc: 0.024
+KVM: 0.003
+
+RHEL9 ppc64le Power9 pseries guest userspace segfaults
diff --git a/results/classifier/zero-shot/108/device/1773 b/results/classifier/zero-shot/108/device/1773
new file mode 100644
index 00000000..77518e7e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1773
@@ -0,0 +1,24 @@
+device: 0.961
+boot: 0.803
+graphic: 0.790
+performance: 0.521
+vnc: 0.504
+debug: 0.444
+network: 0.305
+semantic: 0.283
+PID: 0.227
+socket: 0.222
+permissions: 0.196
+other: 0.134
+files: 0.086
+KVM: 0.039
+
+qemu does not use the mic of the webcam dedicated to the VM
+Description of problem:
+
+Steps to reproduce:
+1. plug two webcams to the desktop, one for the host and one for the VM
+2. launch QEMU VM
+3. QEMU VM take the desktop webcam mic instead of the webcam mic dedicated to the VM.
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/1794 b/results/classifier/zero-shot/108/device/1794
new file mode 100644
index 00000000..f34fdc87
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1794
@@ -0,0 +1,42 @@
+device: 0.952
+graphic: 0.903
+performance: 0.899
+debug: 0.882
+files: 0.858
+PID: 0.841
+semantic: 0.808
+socket: 0.772
+permissions: 0.755
+vnc: 0.728
+network: 0.699
+boot: 0.663
+KVM: 0.599
+other: 0.538
+
+Virtio-GPU doesn't fill Response data for cursor queue
+Description of problem:
+Implementation of virtio-gpu in Qemu is likely not fill Response header in cursor commands.
+
+Inside the virtio 1.2 specification, document said:
+```
+VIRTIO_GPU_CMD_UPDATE_CURSOR
+    Update cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA.
+    Full cursor update. Cursor will be loaded from the specified resource_id and will be moved to pos. The driver must 
+    transfer the cursor into the resource beforehand (using control queue commands) and make sure the commands to fill 
+    the resource are actually processed (using fencing).
+
+VIRTIO_GPU_CMD_MOVE_CURSOR
+    Move cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA.
+    Move cursor to the place specified in pos. The other fields are not used and will be ignored by the device.
+```
+The cursor commands do have a response like control commands.
+
+But in [hw/display/virtio-gpu.c#L1136](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu.c#L1136), QEMU doesn't care anything about response, just fetching command and execute.
+
+It this a Implementation compromise or I missing something in the specification?
+Steps to reproduce:
+1. Write any kernel that using virtio-gpu.
+2. Run on qemu.
+3. No response on cursor command.
+Additional information:
+Specification: [virtio-v1.2-cs01.html](https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007)
diff --git a/results/classifier/zero-shot/108/device/1815445 b/results/classifier/zero-shot/108/device/1815445
new file mode 100644
index 00000000..7cbbb3b5
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1815445
@@ -0,0 +1,35 @@
+device: 0.921
+graphic: 0.873
+performance: 0.735
+other: 0.712
+semantic: 0.511
+debug: 0.440
+vnc: 0.429
+files: 0.416
+socket: 0.362
+boot: 0.275
+PID: 0.256
+network: 0.249
+permissions: 0.236
+KVM: 0.098
+
+change and eject commands are not working on an overlay
+
+From qemu monitor, 'change' and 'eject' commands are not working on a CD overlay.
+'info block' returns:
+  cd0-overlay0: /home/guillaume/test/cd0-overlay0 (qcow2)
+    Attached to:      cd0-device
+    Removable device: not locked, tray closed
+    Cache mode:       writeback, ignore flushes
+    Backing file:     /home/guillaume/test.iso (chain depth: 1)
+
+But 'eject cd0-overlay0' returns:
+  Device 'cd0-overlay0' not found
+I also tried 'cd0-device' and 'cd0'.
+
+Same problem with 'change' command.
+
+Can you please provide your QEMU version, command line, and any QMP/HMP commands you issued, and the expected/desired effect?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/182 b/results/classifier/zero-shot/108/device/182
new file mode 100644
index 00000000..a2639e41
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/182
@@ -0,0 +1,16 @@
+device: 0.946
+network: 0.831
+socket: 0.711
+performance: 0.612
+PID: 0.507
+debug: 0.462
+boot: 0.440
+vnc: 0.417
+permissions: 0.360
+graphic: 0.356
+semantic: 0.273
+other: 0.163
+KVM: 0.097
+files: 0.036
+
+qemu-xhci device should detect if libusb host supports streams
diff --git a/results/classifier/zero-shot/108/device/1824853 b/results/classifier/zero-shot/108/device/1824853
new file mode 100644
index 00000000..b9262ea9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1824853
@@ -0,0 +1,95 @@
+device: 0.923
+debug: 0.914
+boot: 0.897
+performance: 0.879
+other: 0.873
+PID: 0.866
+permissions: 0.861
+socket: 0.851
+graphic: 0.834
+network: 0.828
+semantic: 0.818
+KVM: 0.760
+vnc: 0.751
+files: 0.712
+
+4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed
+
+I tried to bootstrap and regtested gcc trunk (gcc svn rev 270278, datestamp 20190411) inside my arm64-gentoo installation under qemu-system-aarch64.
+
+Qemu version was 4.0.0-rc3 and -cpu cortex-a57. Qemu configured with only --target-list=aarch64-softmmu,aarch64-linux-user and compiled using gcc "version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1~16.04)".
+
+Executable created from gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c compiled with -O2 crashed the whole qemu-system.
+
+To investigate a bit I also manually run
+~/gcc/inst/trunk/bin/gcc ~/gcc/src/trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c
+with different options like:
+-O0 -lm -o d0.exe
+-O1 -lm -o d1.exe
+-O2 -lm -o d2.exe
+-O0 -static -lm -o s0.exe
+-O1 -static -lm -o s1.exe
+-O2 -static -lm -o s2.exe
+
+So, now I have 6 different arm64 executables created with different optimization levels. O0 and O1 versions run ok.
+Three sN.exe static executables I've also tried in qemu user mode (with same -cpu), no issue in user mode.
+
+And inside qemu-system I can see that
+running "d2.exe" (attached) gives:
+tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed.
+
+And running "s2.exe" gives:
+tcg/tcg.c:320: set_jmp_reset_offset: Assertion `s->tb_jmp_reset_offset[which] == off' failed.
+
+It seems like this test is an counter-example for logic that "tcg_ctx->nb_ops < 4000" implies tcg will fit into 16-bit signed size (see tcg_op_buf_full comments).
+
+Richard's changes in abebf92597186 and 9f754620651d were not enough, translation block must be smaller, or we have to find some proper way to bail out when buffer overflows.
+I don't know why this situation is not caught by code_gen_highwater logic in tcg.c
+
+I've also tried this "bail out" patch
+
+diff --git a/tcg/tcg.c b/tcg/tcg.c
+--- a/tcg/tcg.c
++++ b/tcg/tcg.c
+@@ -3949,7 +3949,8 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb)
+                 size_t off = tcg_current_code_size(s);
+                 s->gen_insn_end_off[num_insns] = off;
+                 /* Assert that we do not overflow our stored offset.  */
+-                assert(s->gen_insn_end_off[num_insns] == off);
++                if (s->gen_insn_end_off[num_insns] != off)
++                  return -1;
+             }
+             num_insns++;
+             for (i = 0; i < TARGET_INSN_START_WORDS; ++i) {
+
+But then running "d2.exe" just hangs the whole qemu-system. It seems that when tcg_gen_code return -1 (like in highwater logic mentioned before), we just re-call it again and again.
+
+
+
+Also attaching static-compiled executable "s2.exe".
+
+Returning -1 does not help because all that signals that the buffer is full.
+We then flush the buffer and try again, assuming the at the buffer will not fill.
+Given that the buffer is usually many megabytes, this is reasonable.
+
+We need something different to signal that the buffer is not full, but that
+another offset has overflowed.
+
+Patch set posted:
+https://patchwork.ozlabs.org/project/qemu-devel/list/?series=102978
+
+
+
+Richard, thank you for solving this so fast!
+I certainly can confirm attached executables work fine for me on patched version.
+
+I'll also re-run full gcc regtest a bit later, but it runs for a rather long time, not sure this result will be important next week.
+
+Hopefully, patchset will be included into 4 release.
+
+Unfortunately the fix is too big for this point in the 4.0 release cycle; it'll go into 4.1.
+
+
+The fix should now be in git master (commits 8b86d6d25807e13a6 and 6e6c4efed995d9ec), so it will be in the 4.1 release.
+
+
diff --git a/results/classifier/zero-shot/108/device/1835839 b/results/classifier/zero-shot/108/device/1835839
new file mode 100644
index 00000000..7efb3d83
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1835839
@@ -0,0 +1,284 @@
+device: 0.948
+other: 0.947
+performance: 0.947
+permissions: 0.941
+semantic: 0.925
+PID: 0.923
+debug: 0.914
+boot: 0.909
+graphic: 0.904
+socket: 0.903
+files: 0.891
+network: 0.890
+vnc: 0.880
+KVM: 0.859
+
+qemu-user: $0 incorrectly always reports absolute path
+
+We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1].
+
+The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked.
+
+A simple reproducer is this:
+
+On normal system (no emulation):
+
+root@nofan:~> sh -c 'echo $0'
+sh
+root@nofan:~>
+
+On qemu-user:
+
+(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0'
+/bin/sh
+(sid-m68k-sbuild)root@nofan:/#
+
+> [1] https://lists.debian.org/debian-68k/2019/07/msg00007.html
+
+Tentative patch
+
+On 7/9/19 1:54 PM, Laurent Vivier wrote:
+> ** Patch added: "Enable binfmt-misc preserve-arg[0] flag"
+>    https://bugs.launchpad.net/qemu/+bug/1835839/+attachment/5275869/+files/0001-linux-user-manage-binfmt-misc-preserve-arg-0-flags.patch
+
+Thanks! I just tried the patch and ran the setup script with:
+
+./scripts/qemu-binfmt-conf.sh --debian --qemu-path=/usr/bin --qemu-suffix=-static --preserve-arg0 yes
+
+and:
+
+root@nofan:~/qemu> systemctl restart binfmt-support.service 
+root@nofan:~/qemu>
+
+But still don't get the correct path:
+
+(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0'
+/bin/sh
+(sid-m68k-sbuild)root@nofan:/#
+
+Do I need to do anything else?
+
+-- 
+ .''`.  John Paul Adrian Glaubitz
+: :' :  Debian Developer - <email address hidden>
+`. `'   Freie Universitaet Berlin - <email address hidden>
+  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+Is the proposed patch backwards compatible (ie "old QEMU binary works with newer binfmt-misc registration" and "new QEMU binary works with older binfmt-misc registration") ? Because binfmt-misc stuff is whole-system but QEMU binaries are per-chroot, this kind of thing is awkward to change if we don't have back-compat (and typically the kernel semantics for these things often don't allow back-compat or any kind of migration-path to the new better setup :-( )
+
+
+Le 09/07/2019 à 14:12, John Paul Adrian Glaubitz a écrit :
+> On 7/9/19 1:54 PM, Laurent Vivier wrote:
+>> ** Patch added: "Enable binfmt-misc preserve-arg[0] flag"
+>>    https://bugs.launchpad.net/qemu/+bug/1835839/+attachment/5275869/+files/0001-linux-user-manage-binfmt-misc-preserve-arg-0-flags.patch
+> 
+> Thanks! I just tried the patch and ran the setup script with:
+> 
+> ./scripts/qemu-binfmt-conf.sh --debian --qemu-path=/usr/bin --qemu-
+> suffix=-static --preserve-arg0 yes
+> 
+> and:
+> 
+> root@nofan:~/qemu> systemctl restart binfmt-support.service 
+> root@nofan:~/qemu>
+
+if you use systemctl, the parameter of "./scripts/qemu-binfmt-conf.sh"
+must be "--systemd m68k" rather than "--debian".
+
+> 
+> But still don't get the correct path:
+> 
+> (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0'
+> /bin/sh
+> (sid-m68k-sbuild)root@nofan:/#
+
+Well, I've tested that, and it should work...
+
+Thanks,
+LAurent
+
+
+
+On 7/9/19 2:51 PM, Laurent Vivier wrote:
+> if you use systemctl, the parameter of "./scripts/qemu-binfmt-conf.sh"
+> must be "--systemd m68k" rather than "--debian".
+
+I tried that and I now get:
+
+root@nofan:/local_scratch/sid-m68k-sbuild> chroot .
+chroot: failed to run command ‘/bin/bash’: No such file or directory
+root@nofan:/local_scratch/sid-m68k-sbuild>
+
+>> But still don't get the correct path:
+>>
+>> (sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0'
+>> /bin/sh
+>> (sid-m68k-sbuild)root@nofan:/#
+> 
+> Well, I've tested that, and it should work...
+
+Oh, I'm not arguing that. I'm sure the error is on my side ;). I'm just trying
+to find out what I'm doing wrong.
+
+-- 
+ .''`.  John Paul Adrian Glaubitz
+: :' :  Debian Developer - <email address hidden>
+`. `'   Freie Universitaet Berlin - <email address hidden>
+  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+Le 09/07/2019 à 14:16, Peter Maydell a écrit :
+> Is the proposed patch backwards compatible (ie "old QEMU binary works
+> with newer binfmt-misc registration" and "new QEMU binary works with
+> older binfmt-misc registration") ? Because binfmt-misc stuff is whole-
+> system but QEMU binaries are per-chroot, this kind of thing is awkward
+> to change if we don't have back-compat (and typically the kernel
+> semantics for these things often don't allow back-compat or any kind of
+> migration-path to the new better setup :-( )
+> 
+
+If you don't enable the preserve-arg[0] flag, old and new QEMU will work.
+
+If you enable the flag, only new QEMU with -0/QEMU_ARGV0 will work.
+
+The best solution would be to force preserve-arg[0] with open-binary
+flag and rely on AT_FDEXEC to detect the binfmt-misc environment, but
+this breaks compatibility with existing environment and old QEMU.
+
+Regarding the "binfmt-misc stuff is whole-system" problem, I've proposed
+months ago a kernel based solution [1] to have a configuration per
+namespace (chroot), but no one seems really interested (I think
+maintainer is afraid by potential security issues).
+
+[1] ns: introduce binfmt_misc namespace
+    https://patchwork.kernel.org/cover/10634807/
+
+
+Le 09/07/2019 à 15:07, John Paul Adrian Glaubitz a écrit :
+> On 7/9/19 2:51 PM, Laurent Vivier wrote:
+>> if you use systemctl, the parameter of "./scripts/qemu-binfmt-conf.sh"
+>> must be "--systemd m68k" rather than "--debian".
+> 
+> I tried that and I now get:
+> 
+> root@nofan:/local_scratch/sid-m68k-sbuild> chroot .
+> chroot: failed to run command ‘/bin/bash’: No such file or directory
+> root@nofan:/local_scratch/sid-m68k-sbuild>
+
+What is the content of:
+
+/etc/binfmt.d/qemu-m68k.conf
+/proc/sys/fs/binfmt_misc/qemu-m68k
+
+what is the result of "file sid-m68k-sbuild/usr/bin/qemu-m68k-static"?
+
+Bonus: if you don't want to copy qemu-m68k-static into the chroot, you
+can use "--persistent" with qemu-binfmt-conf.sh.
+
+Thanks,
+Laurent
+
+
+On 7/9/19 4:01 PM, Laurent Vivier wrote:
+> What is the content of:
+> 
+> /etc/binfmt.d/qemu-m68k.conf
+> /proc/sys/fs/binfmt_misc/qemu-m68k
+
+root@nofan:~> cat /etc/binfmt.d/qemu-m68k.conf
+:qemu-m68k:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x04:\xff\xff\xff\xff\xff\xff\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-m68k-static:P
+root@nofan:~> cat /proc/sys/fs/binfmt_misc/qemu-m68k
+enabled
+interpreter /usr/bin/qemu-m68k-static
+flags: OCF
+offset 0
+magic 7f454c4601020100000000000000000000020004
+mask ffffffffffffff00fffffffffffffffffffeffff
+root@nofan:~>
+
+> what is the result of "file sid-m68k-sbuild/usr/bin/qemu-m68k-static"?
+> 
+> Bonus: if you don't want to copy qemu-m68k-static into the chroot, you
+> can use "--persistent" with qemu-binfmt-conf.sh.
+I'm doing that and I don't have a copy of qemu in the chroot.
+
+But I think I forgot to pass --persistent to the script while testing.
+
+Adrian
+
+-- 
+ .''`.  John Paul Adrian Glaubitz
+: :' :  Debian Developer - <email address hidden>
+`. `'   Freie Universitaet Berlin - <email address hidden>
+  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+After building qemu-m68k, I did:
+
+root@nofan:~/qemu> scripts/qemu-binfmt-conf.sh --systemd m68k --qemu-path=/usr/bin --qemu-suffix=-static --preserve-arg0 yes --persistent yes
+Setting /usr/bin/qemu-m68k-static as binfmt interpreter for m68k for systemd-binfmt.service
+root@nofan:~/qemu> rm /usr/bin/qemu-m68k-static
+root@nofan:~/qemu> cp -av m68k-linux-user/qemu-m68k /usr/bin/qemu-m68k-static 
+'m68k-linux-user/qemu-m68k' -> '/usr/bin/qemu-m68k-static'
+root@nofan:~/qemu> systemctl restart binfmt-support.service 
+root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/
+(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0'
+/bin/sh
+(sid-m68k-sbuild)root@nofan:/#
+
+-- 
+ .''`.  John Paul Adrian Glaubitz
+: :' :  Debian Developer - <email address hidden>
+`. `'   Freie Universitaet Berlin - <email address hidden>
+  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+Le 09/07/2019 à 17:09, John Paul Adrian Glaubitz a écrit :
+> On 7/9/19 4:01 PM, Laurent Vivier wrote:
+>> What is the content of:
+>>
+>> /etc/binfmt.d/qemu-m68k.conf
+>> /proc/sys/fs/binfmt_misc/qemu-m68k
+> 
+> root@nofan:~> cat /etc/binfmt.d/qemu-m68k.conf
+> :qemu-m68k:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x04:\xff\xff\xff\xff\xff\xff\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-m68k-static:P
+> root@nofan:~> cat /proc/sys/fs/binfmt_misc/qemu-m68k
+> enabled
+> interpreter /usr/bin/qemu-m68k-static
+> flags: OCF
+> offset 0
+> magic 7f454c4601020100000000000000000000020004
+> mask ffffffffffffff00fffffffffffffffffffeffff
+
+This is not consistent: you have 'P' in /etc/binfmt.d/qemu-m68k.conf but
+'OCF' in /proc/sys/fs/binfmt_misc/qemu-m68k.
+
+Check "systemctl status binfmt-support.service"
+
+With 'P' when you change the binary you must reload the configuration
+because the binary is loaded in memory once when the configuration is
+updated.
+
+Thanks,
+Laurent
+
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+Laurent's patch has been included here:
+https://gitlab.com/qemu-project/qemu/-/commit/6e1c0d7b951e19c53b8467e8bc4b71ee73a394ea
+So I assume we can mark this as fixed now.
+
diff --git a/results/classifier/zero-shot/108/device/184 b/results/classifier/zero-shot/108/device/184
new file mode 100644
index 00000000..c99bd1b6
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/184
@@ -0,0 +1,16 @@
+device: 0.964
+performance: 0.894
+graphic: 0.742
+network: 0.610
+boot: 0.502
+debug: 0.289
+semantic: 0.263
+socket: 0.135
+KVM: 0.135
+other: 0.127
+PID: 0.119
+permissions: 0.106
+vnc: 0.103
+files: 0.040
+
+SSE CMP ops with 8bit immediate throw sigill with oversized byte
diff --git a/results/classifier/zero-shot/108/device/1847 b/results/classifier/zero-shot/108/device/1847
new file mode 100644
index 00000000..e408350b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1847
@@ -0,0 +1,16 @@
+device: 0.924
+network: 0.675
+performance: 0.496
+graphic: 0.358
+debug: 0.344
+boot: 0.304
+semantic: 0.297
+other: 0.196
+PID: 0.058
+files: 0.050
+permissions: 0.042
+socket: 0.030
+vnc: 0.017
+KVM: 0.003
+
+TriCore missing ftoq31, ftoq31z, and q31tof instructions
diff --git a/results/classifier/zero-shot/108/device/1854 b/results/classifier/zero-shot/108/device/1854
new file mode 100644
index 00000000..bcd6f27b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1854
@@ -0,0 +1,33 @@
+device: 0.934
+graphic: 0.892
+files: 0.865
+PID: 0.855
+permissions: 0.661
+vnc: 0.655
+debug: 0.634
+network: 0.626
+semantic: 0.578
+socket: 0.563
+boot: 0.363
+performance: 0.288
+other: 0.127
+KVM: 0.087
+
+s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Description of problem:
+The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 .
+Reverting that commit fixes the issue.
+Steps to reproduce:
+1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below.
+2. Run it under qemu-s390x.
+
+```
+ ./qemu-s390x nolibc-test
+**
+ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Aborted (core dumped)
+
+```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/1854878 b/results/classifier/zero-shot/108/device/1854878
new file mode 100644
index 00000000..250b55b2
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1854878
@@ -0,0 +1,63 @@
+device: 0.964
+graphic: 0.923
+semantic: 0.751
+performance: 0.734
+other: 0.676
+PID: 0.608
+permissions: 0.568
+files: 0.468
+socket: 0.438
+debug: 0.394
+boot: 0.389
+network: 0.370
+vnc: 0.334
+KVM: 0.281
+
+Physical USB thumbdrive treated as read-only
+
+So I have installed FreeDOS on my USB thumbdrive, by using Rufus. Everything goes as expected so far. That's good.
+
+When I run QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1
+
+it of course is read-only, just like the resulting console message says:
+WARNING: Image format was not specified for '\\.\PhysicalDrive1' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+
+
+So what I then did, was I ran QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw
+
+As expected, the above mentioned console message no longer appears.
+However, beyond that, QEMU doesn't behave as it should regarding read-only status. When I try any operation that involves writing to the drive, it becomes quite clear that the drive is still read-only. Any writing operations to the drive result in FreeDOS giving me the error message:
+Error writing to drive C: DOS area: sector not found.
+
+The above situation is clearly a bug. QEMU should not be treating it as read-only once I specify format=raw.
+
+Note that drive C is how the guest OS refers to the USB thumbdrive (it's drive E in my host OS, and drive C in my host OS is the actual system drive).
+
+And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this command line, so that all changes would be written to a temporary snapshot file:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot
+That last drive option "snapshot" tells QEMU to create a temporary snapshot file, and to write all changes to that. When I do that, all write operations are successful. So it seems that there is a bug in QEMU where it keeps read-only mode in place for a physical drive, even when format=raw is specified. Please fix this bug. Thanks in advance.
+
+Here's my current setup.
+Host OS: Windows 10 (64bit)
+Guest OS: FreeDOS
+QEMU version: 4.1.0
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1859 b/results/classifier/zero-shot/108/device/1859
new file mode 100644
index 00000000..781872fe
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1859
@@ -0,0 +1,23 @@
+device: 0.944
+boot: 0.937
+graphic: 0.934
+debug: 0.826
+performance: 0.783
+socket: 0.736
+semantic: 0.674
+files: 0.674
+vnc: 0.646
+permissions: 0.341
+PID: 0.331
+network: 0.218
+other: 0.125
+KVM: 0.002
+
+Trying to boot Windows Server 2008 Windows Host
+Description of problem:
+On Windows 10 trying to boot Windows Server 2008 R2 I am just stuck on starting Windows if I do get past Starting Windows it just goes to 0x0000007F BSOD
+Steps to reproduce:
+1. Run Windows Server with my command line input
+2. Stuck on Starting Windows
+Additional information:
+![Capture](/uploads/d46fb1980c1b57fed6e0b7d1af98fbaa/Capture.PNG)
diff --git a/results/classifier/zero-shot/108/device/1864 b/results/classifier/zero-shot/108/device/1864
new file mode 100644
index 00000000..84a9da35
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1864
@@ -0,0 +1,36 @@
+device: 0.955
+graphic: 0.920
+performance: 0.871
+vnc: 0.841
+debug: 0.721
+files: 0.710
+PID: 0.673
+semantic: 0.643
+permissions: 0.546
+socket: 0.485
+boot: 0.485
+network: 0.410
+KVM: 0.216
+other: 0.168
+
+x86 VM with TCG and SMP fails to start on 8.1.0
+Description of problem:
+I'm running Colima on MacOS to run Docker. After upgrading qemu to 8.1.0 my x86_64 VM fails to start. If I downgrade qemu to 8.0.4 everything runs normally. Relevant logs:
+
+```
+[   60.976187] rcu: 	0-...!: (0 ticks this GP) idle=0d58/0/0x0 softirq=44/44 fqs=0 (false positive?)
+[   60.979262] 	(detected by 1, t=6005 jiffies, g=-1171, q=1981 ncpus=2)
+[   60.982317] Sending NMI from CPU 1 to CPUs 0:
+[   11.583693] NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xb/0x10
+[   11.583693] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.006 msecs
+[   60.982317] rcu: rcu_preempt kthread timer wakeup didn't happen for 6004 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
+[   60.982317] rcu: 	Possible timer handling issue on cpu=0 timer-softirq=15
+[   60.982317] rcu: rcu_preempt kthread starved for 6005 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
+[   60.982317] rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
+[   60.982317] rcu: RCU grace-period kthread stack dump:
+[   60.982317] task:rcu_preempt     state:I stack:0     pid:15    ppid:2      flags:0x00004000
+```
+
+[serial.log](/uploads/1039eceff37133504eb93401df1db137/serial.log)
+Steps to reproduce:
+1. `colima start --arch x86_64`
diff --git a/results/classifier/zero-shot/108/device/1866 b/results/classifier/zero-shot/108/device/1866
new file mode 100644
index 00000000..6ae29f6c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1866
@@ -0,0 +1,16 @@
+device: 0.930
+network: 0.908
+performance: 0.851
+graphic: 0.685
+vnc: 0.468
+other: 0.395
+boot: 0.372
+debug: 0.309
+files: 0.257
+semantic: 0.182
+PID: 0.174
+socket: 0.116
+permissions: 0.059
+KVM: 0.037
+
+mips/mip64 virtio broken on master (and 8.1.0 with tcg fix)
diff --git a/results/classifier/zero-shot/108/device/1866792 b/results/classifier/zero-shot/108/device/1866792
new file mode 100644
index 00000000..59d0d7ac
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1866792
@@ -0,0 +1,93 @@
+device: 0.951
+performance: 0.908
+vnc: 0.878
+other: 0.875
+graphic: 0.839
+PID: 0.819
+files: 0.810
+permissions: 0.800
+debug: 0.783
+socket: 0.771
+semantic: 0.712
+network: 0.640
+boot: 0.632
+KVM: 0.449
+
+formating vdi-disk over nbd fails
+
+Hi,
+after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd partitioning works fine, but the system hangs up during formating with mkfs.ext4.
+
+Same procedure with qcow2-image works fine 
+Tested on Fedora 31 kernel  5.5.7-200.fc31.x86_64
+
+
+-----------------
+#! /bin/sh
+
+qemu-img create -f qcow2 ~/test.qcow2 32G
+#qemu-img version 4.1.1 (qemu-4.1.1-1.fc31)
+
+modprobe nbd max_part=8
+qemu-nbd --connect=/dev/nbd2 ~/test.qcow2
+#qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31)
+
+parted -s /dev/nbd2 "mklabel gpt"
+parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G "
+parted  -s -a optimal /dev/nbd2 "p"
+
+mkfs.ext4 /dev/nbd2p1
+#Format hangs up due to IO errors.
+#Tested on Fedora 31, kernel 5.5.7-200.fc31.x86_64
+
+mkdir /mnt/test_qcow2
+
+mount /dev/nbd2p1 /mnt/test_qcow2
+df -H
+
+-------------------
+#! /bin/sh
+
+qemu-img create -f vdi ~/test.vdi 32G
+
+modprobe nbd max_part=8
+qemu-nbd --connect=/dev/nbd4 ~/test.vdi
+
+parted -s /dev/nbd4 "mklabel gpt"
+parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G "
+parted  -s -a optimal /dev/nbd4 "p"
+
+mkfs.ext4 /dev/nbd4p1
+#Format hangs up due to IO errors 
+#Tested on Fedora 31 kernel  5.5.7-200.fc31.x86_64
+
+mkdir /mnt/test_vdi
+
+mount /dev/nbd4p1 /mnt/test_vdi
+df -H
+----------------------
+
+
+Kind regards
+  Eilert
+
+PS.: There may be a connection to this bug:
+​ 	
+#1661758 qemu-nbd causes data corruption in VDI-format disk images
+
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/187 b/results/classifier/zero-shot/108/device/187
new file mode 100644
index 00000000..8209f3ed
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/187
@@ -0,0 +1,16 @@
+device: 0.946
+performance: 0.732
+graphic: 0.651
+network: 0.544
+debug: 0.543
+PID: 0.455
+semantic: 0.436
+other: 0.395
+permissions: 0.378
+socket: 0.259
+boot: 0.232
+KVM: 0.227
+vnc: 0.050
+files: 0.042
+
+Cannot boot arm kernel images on s390x
diff --git a/results/classifier/zero-shot/108/device/1875080 b/results/classifier/zero-shot/108/device/1875080
new file mode 100644
index 00000000..910bbbc4
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1875080
@@ -0,0 +1,39 @@
+device: 0.952
+graphic: 0.864
+network: 0.719
+performance: 0.697
+socket: 0.691
+other: 0.639
+semantic: 0.636
+permissions: 0.561
+files: 0.535
+PID: 0.503
+vnc: 0.500
+boot: 0.442
+debug: 0.418
+KVM: 0.305
+
+USB host device data transfer with control endpoint
+
+QEMU emulator version 4.2.0
+Host -> Arch Linux kernel version: 5.4.34-1-lts
+Guest -> Various Linux Distros
+
+I sent a control message with data through endpoint zero.
+On the other side message is received with all fields correct except data buffer.
+I've tested the data field inside guest with usbmon and data field was correct but after packet leaved qemu, data filed is lost.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1877716 b/results/classifier/zero-shot/108/device/1877716
new file mode 100644
index 00000000..402ef428
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1877716
@@ -0,0 +1,147 @@
+device: 0.952
+permissions: 0.947
+semantic: 0.943
+performance: 0.936
+debug: 0.929
+other: 0.918
+PID: 0.912
+files: 0.906
+graphic: 0.893
+boot: 0.893
+KVM: 0.889
+socket: 0.870
+vnc: 0.862
+network: 0.819
+
+Win10 guest unusable after a few minutes
+
+On Arch Linux, the recent qemu package update seems to misbehave on some systems. In my case, my Windows 10 guest runs fine for around 5 minutes and then start to get really sluggish, even unresponsive. It needs to be forced off. I could reproduce this on a minimal VM with no passthrough, although my current testing setup involves an nvme pcie passthrough.
+
+I bisected it to the following commit which rapidly starts to run sluggishly on my setup:
+https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf
+
+I've ran the previous commit ( https://github.com/qemu/qemu/commit/b321051cf48ccc2d3d832af111d688f2282f089b ) for the entire night without an issue so far.
+
+I believe this might be a duplicate of https://bugs.launchpad.net/qemu/+bug/1873032 , although I'm not sure.
+
+Linux cc 5.6.10-arch1-1 #1 SMP PREEMPT Sat, 02 May 2020 19:11:54 +0000 x86_64 GNU/Linux
+AMD Ryzen 7 2700X Eight-Core Processor
+
+
+
+Note that bisecting is difficult due to the nature of the bug (does not appear before 5 to 10 minutes on my machine).
+
+
+
+I can also replicate the problem on current master. I can solve it by building master with --disable-linux-io-uring.
+
+I also tried building Linux 5.4.39 where the issue happens too:
+Linux cc 5.4.39qemu #1 SMP PREEMPT Sat May 9 12:11:38 CEST 2020 x86_64 GNU/Linux
+
+I attached the logs of that latest run.
+
+On Sat, May 9, 2020 at 9:16 AM Xavier <email address hidden> wrote:
+>
+> Public bug reported:
+>
+> On Arch Linux, the recent qemu package update seems to misbehave on some
+> systems. In my case, my Windows 10 guest runs fine for around 5 minutes
+> and then start to get really sluggish, even unresponsive. It needs to be
+> forced off. I could reproduce this on a minimal VM with no passthrough,
+> although my current testing setup involves an nvme pcie passthrough.
+>
+> I bisected it to the following commit which rapidly starts to run sluggishly on my setup:
+> https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf
+
+Thanks for bisecting this bug! Arch Linux can work around it in the
+short term by building with ./configure --disable-linux-io-uring
+and/or removing the liburing build dependency.
+
+I will try to reproduce the issue and send a QEMU patch to fix it.
+
+
+On Mon, May 11, 2020 at 10:12 AM Stefan Hajnoczi <email address hidden> wrote:
+> On Sat, May 9, 2020 at 9:16 AM Xavier <email address hidden> wrote:
+> >
+> > Public bug reported:
+> >
+> > On Arch Linux, the recent qemu package update seems to misbehave on some
+> > systems. In my case, my Windows 10 guest runs fine for around 5 minutes
+> > and then start to get really sluggish, even unresponsive. It needs to be
+> > forced off. I could reproduce this on a minimal VM with no passthrough,
+> > although my current testing setup involves an nvme pcie passthrough.
+> >
+> > I bisected it to the following commit which rapidly starts to run sluggishly on my setup:
+> > https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf
+>
+> Thanks for bisecting this bug! Arch Linux can work around it in the
+> short term by building with ./configure --disable-linux-io-uring
+> and/or removing the liburing build dependency.
+
+Hmm...a brief look at the Arch Linux package source suggests QEMU is
+not being built with io_uring enabled. Anatol, please confirm whether
+this is correct.
+
+If io_uring is not enabled then this bug may affect most existing
+users on Linux. Initially I thought it was because Arch Linux had
+enabled the new io_uring feature but I was probably mistaken.
+
+
+Stefan,
+
+Arch explicitly disabled io_uring for qemu after discovering this bug. That's why you don't see it enabled in the recent version.
+
+5.0.0-6 doesn't have io_uring enabled.
+5.0.0-5 does have it, and you can grab it here: [1].
+
+[1] https://archive.archlinux.org/packages/q/qemu/qemu-5.0.0-5-x86_64.pkg.tar.zst
+
+As of version 5.0.0-6 (released a day ago), qemu on Arch is no longer built with io_uring support because of this bug. The previous version (5.0.0-5) was built with io_uring support and this bug was happening on my machine. Before the fixed version was released I myself added --disable-linux-io-uring to the build file of 5.0.0-5 and that fixed the issue for me. Now I'm running 5.0.0-6 and it's working as good as ever.
+You can track the changes of qemu build files here: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qemu
+
+That's good news! Most users do not have io_uring enabled yet.
+
+I have been able to reproduce the issue and found that nodes are not being removed from the AioContext->aio_handlers list when aio_set_fd_handler() is called. perf shows that large amounts of CPU time are spent in aio_pending().
+
+Working on getting to the bottom of the issue and fixing it.
+
+Thank you Stefan for looking at this issue.
+
+As Alexander and @postfactum mentioned Arch disabled io_uring feature after this bug has been discovered. Here is an Arch Linux issue that tracks it https://bugs.archlinux.org/task/66578
+
+Please try this patch series:
+https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html
+
+Unofficial x86_64 build of v5.0.0 with those 2 patches for Arch is here: [1].
+
+[1] https://download.opensuse.org/repositories/home:/post-factum/Arch/x86_64/
+
+Hi Stefan,
+
+I applied your series on top of master with io_uring enabled and I no longer experience the issue. Let me know if you need additional testing.
+
+Thank you for fixing this so promptly.
+
+On Tue, May 12, 2020, 16:25 zkrx <email address hidden> wrote:
+
+> Hi Stefan,
+>
+> I applied your series on top of master with io_uring enabled and I no
+> longer experience the issue. Let me know if you need additional testing.
+>
+> Thank you for fixing this so promptly.
+>
+
+That's great! Thanks for your bug report and time investigating this issue.
+
+Stefan
+
+>
+
+
+Thank you Stefan for the fixes. Once these patches land the upstream repo I'll pull it into the Arch package and reenable io_uring.
+
+The fix has been merged:
+https://git.qemu.org/?p=qemu.git;a=commit;h=f2465433b43fb87766d79f42191607dac4aed5b4
+
+
diff --git a/results/classifier/zero-shot/108/device/1880 b/results/classifier/zero-shot/108/device/1880
new file mode 100644
index 00000000..e136f7e3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1880
@@ -0,0 +1,28 @@
+device: 0.930
+boot: 0.875
+graphic: 0.825
+semantic: 0.599
+vnc: 0.550
+socket: 0.541
+network: 0.468
+PID: 0.468
+performance: 0.456
+debug: 0.407
+permissions: 0.308
+files: 0.269
+KVM: 0.175
+other: 0.174
+
+CXL Mem enable error
+Description of problem:
+During the process of booting, the following info indicate that the CXL Mem is not enabled.
+```
+Media not active (-16)
+probe of mem0 failed with error -16
+```
+Steps to reproduce:
+1. Compile Linux kernel v5.18 as shown in the QEMU doc
+2. Run the above-mentioned script
+3. Check the booting script
+Additional information:
+Could you give me some hints of how to operate on the CXL device properly? Thanks a lot.
diff --git a/results/classifier/zero-shot/108/device/1882787 b/results/classifier/zero-shot/108/device/1882787
new file mode 100644
index 00000000..488a45e4
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1882787
@@ -0,0 +1,82 @@
+device: 0.937
+socket: 0.908
+graphic: 0.904
+files: 0.872
+PID: 0.864
+other: 0.840
+performance: 0.824
+network: 0.821
+debug: 0.778
+semantic: 0.771
+boot: 0.765
+permissions: 0.760
+vnc: 0.755
+KVM: 0.580
+
+AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut
+
+There was a change in https://github.com/qemu/qemu/commit/571a8c522e0095239598347ac0add93337c1e0bf#diff-230ab01fa7fb1668a1e9183241115cb0R1852-R1853 (audio/audio.c) which breaks audio output on devices which have multiple software voices on the same hardware voice.
+
+When multiple software voices use the same hardware voice, then setting a volume / mute for any of the software voices, will affect all other software voices, too.
+
+I'm not sure if such a use-case exists in QEMU; however, it does exist in my fork.
+It's also easy to see that this is a bug in the QEMU audio subsystem.
+
+The API (and broken function) for this is:
+
+```
+    void AUD_set_volume_out (SWVoiceOut *sw, int mute, uint8_t lvol, uint8_t rvol)
+```
+
+So this is supposed to modify the SWVoiceOut.
+
+However, if the backend supports `pcm_ops->volume_out` this does not work as expected. It's always as if you had called:
+
+```
+    void AUD_set_volume_out (HWVoiceOut *hw, int mute, uint8_t lvol, uint8_t rvol)
+```
+
+*(Note how this modifies the hardware voice)*
+
+
+In my specific use case, I have 2 outputs (digital and analog audio on AC97), and I want to mute the digital audio output, but I still need to keep the voice activated for timing.
+However, if I mute the digital audio SWVoiceOut, it will also affect the other SWVoiceOut (for analog audio) on the same HWVoiceOut.
+
+---
+
+Old code - if the hardware supports volume changes, it will receive the software voice which should be modified, so changes can be restricted to that one voice:
+
+```
+        HWVoiceOut *hw = sw->hw;
+        [...]
+        if (hw->pcm_ops->ctl_out) {
+            hw->pcm_ops->ctl_out (hw, VOICE_VOLUME, sw);
+        }
+```
+
+New code - the hardware backend will have no way to differentiate software voices; so any change will affect all voices. The volume which was set last on any sw voice will set a global volume / mute for all voices on the hardware backend:
+
+```
+        HWVoiceOut *hw = sw->hw;
+        [...]
+        if (hw->pcm_ops->volume_out) {
+            hw->pcm_ops->volume_out(hw, &sw->vol);
+        }
+```
+
+The old interface was already broken with some (all?) backends, because they ignored the software voice, but at least the design made sense.
+However, the new design is fundamentally broken because it doesn't even tell the backend which voice is supposed to be modified.
+
+---
+
+Bug was introduced in cecc1e79bf9ad9a0e2d3ce513d4f71792a0985f6
+The affected code was touched since then, but still remains in 49ee11555262a256afec592dfed7c5902d5eefd2
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/74
+
+
diff --git a/results/classifier/zero-shot/108/device/1882851 b/results/classifier/zero-shot/108/device/1882851
new file mode 100644
index 00000000..d740340a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1882851
@@ -0,0 +1,507 @@
+device: 0.947
+performance: 0.934
+boot: 0.928
+graphic: 0.928
+KVM: 0.927
+debug: 0.927
+PID: 0.926
+semantic: 0.925
+files: 0.922
+other: 0.909
+vnc: 0.906
+permissions: 0.906
+socket: 0.904
+network: 0.890
+
+QEMU video freezes with "Guest disabled display" (virtio driver)
+
+I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command:
+
+  $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio
+
+and waiting for a screen blank, I get this message:
+
+  Guest disabled display
+
+And nothing happens after that, I can move the mouse or hit any key, and the message is still there.
+
+I can still reboot the VM but that's not optimal.
+
+I can reproduce this with the latest QEMU release (5.0.0) or git master, 
+I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there.
+
+I can't reproduce this with other video drivers (std, qxl).
+
+With std/qxl the screen will blank a bit and then continue as normal.
+
+OK, I found a workaround: sendkey ctrl-alt-f1 from the QEMU console (ctrl alt 2) then I can switch back to X and continue from where I left off.
+
+Strange, that workaround doesn't work anymore.
+
+My bad, the workaround works, it's just a bit tricky.
+
+`xset dpms force off' on the guest is a good way to reproduce it.
+
+Hmm, happens with xorg only.
+Wayland behaves as expected (any mouse/kbd event wakes up the screen).
+Which pretty much implies this is a guest bug.
+
+> Hmm, happens with xorg only.
+
+Nope, I can reproduce it with sway as well (which is another Wayland compositor).
+
+To reproduce it with sway, just do: swaymsg "output * dpms off" and then should you see "Guest disabled display", at that point I'm unable to get back image.
+
+I tried the sendkey ctrl-alt-f2 and then switch back to TTY1 but the "Guest disabled display" remains.
+
+Can you please tell me which compositor you used?
+
+Thanks.
+
+I can't wake up the screen after hitting keys or moving the mouse after turning off the screen with sway.
+
+Gerd: I tried the LTS kernel on Arch Linux (5.4.46-1-lts) and I can't reproduce the bug with this kernel.
+
+It works as expected: `xset dpms force off' triggers the "Guest disabled display" and it disappears after moving the mouse.
+
+Could it be a regression in virtio_gpu?
+
+I guess I'll try the latest linux git and if it's an issue in master, I'll bisect it.
+
+I can reproduce it with current linux git master[1].
+
+1. git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
+OK, I was able to bisect, here is the result:
+
+[diego@arch-zoom linux]$ git bisect bad
+3954ff10e06e4fbc548fc02ff1fcaaac3228fed5 is the first bad commit
+commit 3954ff10e06e4fbc548fc02ff1fcaaac3228fed5
+Author: Gerd Hoffmann <email address hidden>
+Date:   Thu Dec 12 13:53:44 2019 +0100
+
+    drm/virtio: skip set_scanout if framebuffer didn't change
+
+    v2: also check src rect (Chia-I Wu).
+
+    Signed-off-by: Gerd Hoffmann <email address hidden>
+    Reviewed-by: Chia-I Wu <email address hidden>
+    Link: http://patchwork<email address hidden>
+
+ drivers/gpu/drm/virtio/virtgpu_plane.c | 35 ++++++++++++++++++++--------------
+ 1 file changed, 21 insertions(+), 14 deletions(-)
+[diego@arch-zoom linux]$
+
+
+
+
+I just sanity checked, and can confirm the bad commit causes it, and going back one commit makes it work.
+
+When going through a disable/enable cycle without changing the framebuffer
+the optimization added by commit 3954ff10e06e causes the screen stay
+blank.  Add a bool to force an update to fix that.
+
+Cc: <email address hidden>
+Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change")
+Signed-off-by: Gerd Hoffmann <email address hidden>
+---
+ drivers/gpu/drm/virtio/virtgpu_drv.h     | 1 +
+ drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
+ drivers/gpu/drm/virtio/virtgpu_plane.c   | 4 +++-
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
+index 7879ff58236f..6d5410d5dd84 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
+@@ -138,6 +138,7 @@ struct virtio_gpu_output {
+ 	int cur_x;
+ 	int cur_y;
+ 	bool enabled;
++	bool need_update;
+ };
+ #define drm_crtc_to_virtio_gpu_output(x) \
+ 	container_of(x, struct virtio_gpu_output, crtc)
+diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
+index 2b7e6ae65546..44e9c7b874f5 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_display.c
++++ b/drivers/gpu/drm/virtio/virtgpu_display.c
+@@ -99,6 +99,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc,
+ 	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
+ 
+ 	output->enabled = true;
++	output->need_update = true;
+ }
+ 
+ static void virtio_gpu_crtc_atomic_disable(struct drm_crtc *crtc,
+diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
+index 52d24179bcec..5948031a9ce8 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
+@@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+ 	    plane->state->src_w != old_state->src_w ||
+ 	    plane->state->src_h != old_state->src_h ||
+ 	    plane->state->src_x != old_state->src_x ||
+-	    plane->state->src_y != old_state->src_y) {
++	    plane->state->src_y != old_state->src_y ||
++	    output->need_update) {
+ 		DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
+ 			  bo->hw_res_handle,
+ 			  plane->state->crtc_w, plane->state->crtc_h,
+@@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+ 					   plane->state->src_h >> 16,
+ 					   plane->state->src_x >> 16,
+ 					   plane->state->src_y >> 16);
++		output->need_update = false;
+ 	}
+ 
+ 	virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
+-- 
+2.18.4
+
+
+
+Gerd, thanks. I can confirm your patch fixes the problem with X, but Wayland (sway) is still affected.
+
+I tested X and wayland, and while the "Guest disabled display" no longer hangs on X, it still does hangs under wayland.
+
+Should I bisect again?
+
+Sway log after the crash.
+
+It looks like sway requires swayidle to wake up from sleep[1].
+
+This works:
+
+swayidle timeout 2 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"'
+
+1. https://github.com/swaywm/sway/issues/2914
+
+Yeah, I can reproduce the same exact behavior outside of QEMU with sway and it's consistent to what I observed in QEMU.
+
+> Hmm, happens with xorg only.
+
+I think you were right all along about this, sorry.
+
+Thanks for fixing this bug, feel free to close this bug as fixed.
+
+Will the patch make it for 5.8?
+
+When going through a disable/enable cycle without changing the
+framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
+skip set_scanout if framebuffer didn't change") causes the screen stay
+blank.  Add a bool to force an update to fix that.
+
+Cc: <email address hidden>
+Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change")
+Signed-off-by: Gerd Hoffmann <email address hidden>
+---
+ drivers/gpu/drm/virtio/virtgpu_drv.h     | 1 +
+ drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
+ drivers/gpu/drm/virtio/virtgpu_plane.c   | 4 +++-
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
+index 9ff9f4ac0522..7b0c319f23c9 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
+@@ -138,6 +138,7 @@ struct virtio_gpu_output {
+ 	int cur_x;
+ 	int cur_y;
+ 	bool enabled;
++	bool need_update;
+ };
+ #define drm_crtc_to_virtio_gpu_output(x) \
+ 	container_of(x, struct virtio_gpu_output, crtc)
+diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
+index cc7fd957a307..378be5956b30 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_display.c
++++ b/drivers/gpu/drm/virtio/virtgpu_display.c
+@@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc,
+ 	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
+ 
+ 	output->enabled = true;
++	output->need_update = true;
+ }
+ 
+ static void virtio_gpu_crtc_atomic_disable(struct drm_crtc *crtc,
+diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
+index 52d24179bcec..5948031a9ce8 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
+@@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+ 	    plane->state->src_w != old_state->src_w ||
+ 	    plane->state->src_h != old_state->src_h ||
+ 	    plane->state->src_x != old_state->src_x ||
+-	    plane->state->src_y != old_state->src_y) {
++	    plane->state->src_y != old_state->src_y ||
++	    output->need_update) {
+ 		DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
+ 			  bo->hw_res_handle,
+ 			  plane->state->crtc_w, plane->state->crtc_h,
+@@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+ 					   plane->state->src_h >> 16,
+ 					   plane->state->src_x >> 16,
+ 					   plane->state->src_y >> 16);
++		output->need_update = false;
+ 	}
+ 
+ 	virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
+-- 
+2.18.4
+
+
+
+  Hi,
+
+> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
+> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
+> > @@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc,
+> >  	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
+> >  
+> >  	output->enabled = true;
+> > +	output->need_update = true;
+
+> > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+> > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
+> > @@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+> >  	    plane->state->src_w != old_state->src_w ||
+> >  	    plane->state->src_h != old_state->src_h ||
+> >  	    plane->state->src_x != old_state->src_x ||
+> > -	    plane->state->src_y != old_state->src_y) {
+> > +	    plane->state->src_y != old_state->src_y ||
+> > +	    output->need_update) {
+> 
+> Uh instead of hand-rolling what's essentially a drm_crtc_needs_modeset
+> check, why not use that one? atomic helpers try to keep the usual suspects
+> for state transitions already handy, to avoid every driver rolling their
+> own. Or do I miss something here?
+
+Well, the virtio-gpu virtual hardware can't do plane updates and crtc
+updates independant from each other.  So the crtc callbacks handle
+disable only (we don't need a fb for that) and leave the enable to the
+plane update.
+
+I suspect calling drm_atomic_crtc_needs_modeset() in plane update isn't
+going to fly ...
+
+take care,
+  Gerd
+
+
+
+On Mon, Aug 17, 2020 at 11:03:42AM +0200, Gerd Hoffmann wrote:
+>   Hi,
+> 
+> > > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
+> > > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
+> > > @@ -100,6 +100,7 @@ static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc,
+> > >  	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
+> > >  
+> > >  	output->enabled = true;
+> > > +	output->need_update = true;
+> 
+> > > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+> > > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
+> > > @@ -163,7 +163,8 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+> > >  	    plane->state->src_w != old_state->src_w ||
+> > >  	    plane->state->src_h != old_state->src_h ||
+> > >  	    plane->state->src_x != old_state->src_x ||
+> > > -	    plane->state->src_y != old_state->src_y) {
+> > > +	    plane->state->src_y != old_state->src_y ||
+> > > +	    output->need_update) {
+> > 
+> > Uh instead of hand-rolling what's essentially a drm_crtc_needs_modeset
+> > check, why not use that one? atomic helpers try to keep the usual suspects
+> > for state transitions already handy, to avoid every driver rolling their
+> > own. Or do I miss something here?
+> 
+> Well, the virtio-gpu virtual hardware can't do plane updates and crtc
+> updates independant from each other.  So the crtc callbacks handle
+> disable only (we don't need a fb for that) and leave the enable to the
+> plane update.
+> 
+> I suspect calling drm_atomic_crtc_needs_modeset() in plane update isn't
+> going to fly ...
+
+Digged a bit more, seems crtc_state->*_changed is cleared after modeset
+so the following plane update wouldn't see it.  Which I think means
+there is no way around tracking that in need_update.
+
+output->enabled is probably not needed though, seems I can replace that
+by either output->crtc.state->enable or ->active.  Not fully sure which
+one, probably ->active.
+
+take care,
+  Gerd
+
+
+
+When going through a disable/enable cycle without changing the
+framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
+skip set_scanout if framebuffer didn't change") causes the screen stay
+blank.  Add a bool to force an update to fix that.
+
+v2: use drm_atomic_crtc_needs_modeset() (Daniel).
+
+Cc: <email address hidden>
+Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change")
+Signed-off-by: Gerd Hoffmann <email address hidden>
+---
+ drivers/gpu/drm/virtio/virtgpu_drv.h     |  1 +
+ drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++++
+ drivers/gpu/drm/virtio/virtgpu_plane.c   |  4 +++-
+ 3 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
+index 9ff9f4ac0522..4ab1b0ba2925 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
+@@ -138,6 +138,7 @@ struct virtio_gpu_output {
+ 	int cur_x;
+ 	int cur_y;
+ 	bool enabled;
++	bool needs_modeset;
+ };
+ #define drm_crtc_to_virtio_gpu_output(x) \
+ 	container_of(x, struct virtio_gpu_output, crtc)
+diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
+index 2c2742b8d657..6c26b41f4e0d 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_display.c
++++ b/drivers/gpu/drm/virtio/virtgpu_display.c
+@@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc *crtc,
+ static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc,
+ 					 struct drm_crtc_state *old_state)
+ {
++	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
++
++	/*
++	 * virtio-gpu can't do modeset and plane update operations
++	 * independant from each other.  So the actual modeset happens
++	 * in the plane update callback, and here we just check
++	 * whenever we must force the modeset.
++	 */
++	if (drm_atomic_crtc_needs_modeset(crtc->state)) {
++		output->needs_modeset = true;
++	}
+ }
+ 
+ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
+diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
+index 52d24179bcec..65757409d9ed 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
+@@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+ 	    plane->state->src_w != old_state->src_w ||
+ 	    plane->state->src_h != old_state->src_h ||
+ 	    plane->state->src_x != old_state->src_x ||
+-	    plane->state->src_y != old_state->src_y) {
++	    plane->state->src_y != old_state->src_y ||
++	    output->needs_modeset) {
++		output->needs_modeset = false;
+ 		DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
+ 			  bo->hw_res_handle,
+ 			  plane->state->crtc_w, plane->state->crtc_h,
+-- 
+2.18.4
+
+
+
+From: Gerd Hoffmann <email address hidden>
+
+When going through a disable/enable cycle without changing the
+framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
+skip set_scanout if framebuffer didn't change") causes the screen stay
+blank.  Add a bool to force an update to fix that.
+
+v2: use drm_atomic_crtc_needs_modeset() (Daniel).
+
+Cc: <email address hidden>
+Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change")
+Signed-off-by: Gerd Hoffmann <email address hidden>
+Tested-by: Jiri Slaby <email address hidden>
+Tested-by: Diego Viola <email address hidden>
+---
+ drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++++
+ drivers/gpu/drm/virtio/virtgpu_drv.h     |  1 +
+ drivers/gpu/drm/virtio/virtgpu_plane.c   |  4 +++-
+ 3 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
+index af55b334be2f..35b5c80f5d85 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_display.c
++++ b/drivers/gpu/drm/virtio/virtgpu_display.c
+@@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc *crtc,
+ static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc,
+ 					 struct drm_crtc_state *old_state)
+ {
++	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
++
++	/*
++	 * virtio-gpu can't do modeset and plane update operations
++	 * independant from each other.  So the actual modeset happens
++	 * in the plane update callback, and here we just check
++	 * whenever we must force the modeset.
++	 */
++	if (drm_atomic_crtc_needs_modeset(crtc->state)) {
++		output->needs_modeset = true;
++	}
+ }
+ 
+ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
+diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
+index 9ff9f4ac0522..4ab1b0ba2925 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
+@@ -138,6 +138,7 @@ struct virtio_gpu_output {
+ 	int cur_x;
+ 	int cur_y;
+ 	bool enabled;
++	bool needs_modeset;
+ };
+ #define drm_crtc_to_virtio_gpu_output(x) \
+ 	container_of(x, struct virtio_gpu_output, crtc)
+diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
+index 52d24179bcec..65757409d9ed 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
+@@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
+ 	    plane->state->src_w != old_state->src_w ||
+ 	    plane->state->src_h != old_state->src_h ||
+ 	    plane->state->src_x != old_state->src_x ||
+-	    plane->state->src_y != old_state->src_y) {
++	    plane->state->src_y != old_state->src_y ||
++	    output->needs_modeset) {
++		output->needs_modeset = false;
+ 		DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
+ 			  bo->hw_res_handle,
+ 			  plane->state->crtc_w, plane->state->crtc_h,
+-- 
+2.28.0
+
+
+
+On Mon, Aug 24, 2020 at 09:24:40AM +0200, Jiri Slaby wrote:
+> On 18. 08. 20, 9:25, Gerd Hoffmann wrote:
+> > When going through a disable/enable cycle without changing the
+> > framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
+> > skip set_scanout if framebuffer didn't change") causes the screen stay
+> > blank.  Add a bool to force an update to fix that.
+> > 
+> > v2: use drm_atomic_crtc_needs_modeset() (Daniel).
+> > 
+> > Cc: <email address hidden>
+> > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change")
+> > Signed-off-by: Gerd Hoffmann <email address hidden>
+> 
+> Tested-by: Jiri Slaby <email address hidden>
+
+Ping.  Need an ack or an review to merge this.
+
+thanks,
+  Gerd
+
+
+
+This bug is now fixed with Linux 5.9-rc5, thank you.
+
diff --git a/results/classifier/zero-shot/108/device/1888 b/results/classifier/zero-shot/108/device/1888
new file mode 100644
index 00000000..d5f772c0
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1888
@@ -0,0 +1,27 @@
+device: 0.940
+graphic: 0.937
+other: 0.651
+debug: 0.650
+semantic: 0.644
+PID: 0.528
+performance: 0.455
+network: 0.416
+boot: 0.301
+socket: 0.297
+vnc: 0.277
+permissions: 0.224
+KVM: 0.049
+files: 0.048
+
+megasas: Buffer I/O error on dev sda / critical target error, dev sda, sector 0 op 0x0:(READ)
+Description of problem:
+Since QEMU 7.2.0 when using `megasas` device the guest kernel is unable to I/O with the device (Input/output error) also producing errors messages in `dmesg` like these:
+```
+[   18.739344] critical target error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
+[   18.739925] Buffer I/O error on dev sda, logical block 0, async page read
+[   18.740374] Dev sda: unable to read RDB block 0
+```
+
+Relevant options are: `-device megasas -blockdev driver=null-co,read-zeroes=on,node-name=null -device scsi-hd,drive=null` then in guest `modprobe megaraid-sas`. With qcow2 images - errors are the same.
+
+I also tested that the same commands produce no errors on QEMU 6.0.0 - 7.1.0.
diff --git a/results/classifier/zero-shot/108/device/1890160 b/results/classifier/zero-shot/108/device/1890160
new file mode 100644
index 00000000..e7a5a4e7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1890160
@@ -0,0 +1,120 @@
+device: 0.946
+vnc: 0.939
+other: 0.932
+boot: 0.926
+KVM: 0.921
+debug: 0.917
+permissions: 0.917
+graphic: 0.914
+files: 0.911
+semantic: 0.909
+socket: 0.907
+performance: 0.904
+network: 0.893
+PID: 0.890
+
+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
+
+Cc'ing Dmitry as he doesn't have lauchpad account :/
+
+On 8/3/20 4:37 PM, Alexander Bulekov wrote:
+> Public bug reported:
+> 
+> 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
+
+struct Vmxnet3_MiscConf {
+    struct Vmxnet3_DriverInfo driverInfo;
+    __le64        uptFeatures;
+    __le64        ddPA;         /* driver data PA */
+    __le64        queueDescPA;  /* queue descriptor table PA */
+    __le32        ddLen;        /* driver data len */
+    __le32        queueDescLen; /* queue desc. table len in bytes */
+    __le32        mtu;
+    __le16        maxNumRxSG;
+    u8        numTxQueues;
+   ^^^
+     \_________ @0x3e = 0xe1 = 225 queues (max is 8).
+
+    u8        numRxQueues;
+    __le32        reserved[4];
+
+> 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
+> 
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+> 
+
+
+
+Still reproduces with the current version of QEMU. Marking as "Confirmed"
+
+Suggested fix:
+https://<email address hidden>/
+
+Fixed here:
+https://gitlab.com/qemu-project/qemu/-/commit/9010b0c7a9a097590e183
+
diff --git a/results/classifier/zero-shot/108/device/1902306 b/results/classifier/zero-shot/108/device/1902306
new file mode 100644
index 00000000..9d3a860e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1902306
@@ -0,0 +1,58 @@
+device: 0.942
+PID: 0.875
+other: 0.860
+graphic: 0.845
+performance: 0.802
+files: 0.793
+network: 0.765
+permissions: 0.749
+debug: 0.746
+vnc: 0.743
+socket: 0.690
+boot: 0.685
+KVM: 0.630
+semantic: 0.623
+
+Allow setting usb storage device ID parameters
+
+Some stubborn software requires certain VID/PID/Serial to authenticate and refuses to start in emulation. This poses a problem with unsupported programs which often require keeping an ancient hardware praying that the USB stick will not die before the (often defunct) company making it.
+
+Virtualizing such environment is desired. However, QEMU doesn't allow setting VID/PID/Serial/Name of emulated USB devices, but instead uses hardcoded values: https://github.com/qemu/qemu/blob/c99fa56b95a72f6debd50a280561895d078ae020/hw/usb/dev-storage.c#L95
+
+This request (including a patch) was already made in 2015 on the list but never got any response: https://lists.nongnu.org/archive/html/qemu-discuss/2015-07/msg00072.html
+
+
+WDYT of adding such functionality?
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/device/1909418 b/results/classifier/zero-shot/108/device/1909418
new file mode 100644
index 00000000..38844d74
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1909418
@@ -0,0 +1,440 @@
+device: 0.950
+other: 0.934
+KVM: 0.922
+permissions: 0.921
+socket: 0.909
+debug: 0.899
+graphic: 0.897
+performance: 0.891
+semantic: 0.891
+PID: 0.872
+files: 0.864
+vnc: 0.859
+network: 0.856
+boot: 0.854
+
+QEMU: Heap Overflow vulnerability in SDHCI Component
+
+Hello, i want to report qemu vulnerability in SDHCI component, this is integer overflow bug leads to oob read/write in the heap, that can happens in sdhci_do_adma or sdhci_sdma_transfer_multi_blocks.
+
+This is caused when in the middle of unfinished transfer, blksize can change, but the data_count still have the last offset of fifo_buffer from the last transfer. We change blksize to zero, then in the next transfer dma_memory_read/dma_memory_write in the first loop calculate length as blksize-data_count, this leads to integer overflow, because blksize is zero, and data_count can be more than zero.
+
+This bug is recorded in CVE-2020-25085, but the fix is not complete and not fix the root cause of the bug.
+
+Reproducer:
+outl 0xcf8 0x80001010
+outl 0xcfc 0xd7055dba
+outl 0xcf8 0x80001003
+outl 0xcfc 0x86b1d733
+write 0x00 0x1 0x29
+write 0x02 0x1 0x10
+write 0x08 0x1 0x39
+writeb 0xd7055d2b 0x5e
+writel 0xd7055d2c 0xed7d735
+writew 0xd7055d30 0x126e
+writeb 0xd7055d32 0x84
+writel 0xd7055d24 0xd7346e01
+writew 0xd7055d28 0x3bd7
+writeb 0xd7055d2a 0x1
+writeb 0xd7055d05 0x2c
+writew 0xd7055d06 0x5c4
+writeb 0xd7055d0c 0x21
+writew 0xd7055d0e 0x846e
+writel 0xd7055d04 0x260000
+writew 0xd7055d08 0x0
+writeb 0xd7055d0a 0x6d
+writeb 0xd7055d0c 0x31
+clock_step
+EOF
+
+➜  x86_64-softmmu git:(master) ✗ ./qemu-system-x86_64 -m 4G -nodefaults -trace 'sdhci*' -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -qtest stdio -accel qtest
+==410717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 1609122395.789698] OPENED
+qemu-system-x86_64: -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive: warning: bogus if=sd is deprecated, use if=none
+[R +0.037381] outl 0xcf8 0x80001010
+[S +0.037436] OK
+OK
+[R +0.037470] outl 0xcfc 0xd7055dba
+[S +0.037510] OK
+OK
+[R +0.037531] outl 0xcf8 0x80001003
+[S +0.037549] OK
+OK
+[R +0.037571] outl 0xcfc 0x86b1d733
+[S +0.039830] OK
+OK
+[R +0.039882] write 0x00 0x1 0x29
+[S +0.040364] OK
+OK
+[R +0.040401] write 0x02 0x1 0x10
+[S +0.040428] OK
+OK
+[R +0.040449] write 0x08 0x1 0x39
+[S +0.040472] OK
+OK
+[R +0.040491] writeb 0xd7055d2b 0x5e
+[S +0.040530] OK
+OK
+[R +0.040550] writel 0xd7055d2c 0xed7d735
+[S +0.040575] OK
+OK
+[R +0.040594] writew 0xd7055d30 0x126e
+[S +0.040620] OK
+OK
+[R +0.040638] writeb 0xd7055d32 0x84
+[S +0.040658] OK
+OK
+[R +0.040676] writel 0xd7055d24 0xd7346e01
+[S +0.040697] OK
+OK
+[R +0.040715] writew 0xd7055d28 0x3bd7
+[S +0.040738] OK
+OK
+[R +0.040756] writeb 0xd7055d2a 0x1
+[S +0.040779] OK
+OK
+[R +0.040797] writeb 0xd7055d05 0x2c
+[S +0.040819] OK
+OK
+[R +0.040840] writew 0xd7055d06 0x5c4
+[S +0.040862] OK
+OK
+[R +0.040882] writeb 0xd7055d0c 0x21
+[S +0.040907] OK
+OK
+[R +0.040927] writew 0xd7055d0e 0x846e
+[S +0.041026] OK
+OK
+[R +0.041054] writel 0xd7055d04 0x260000
+[S +0.041115] OK
+OK
+[R +0.041139] writew 0xd7055d08 0x0
+=================================================================
+==410717==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000024180 at pc 0x7fe40cb7457d bp 0x7fffa1a7b800 sp 0x7fffa1a7afa8
+WRITE of size 786432 at 0x615000024180 thread T0
+    #0 0x7fe40cb7457c  (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c)
+    #1 0x55f804942120 in flatview_read_continue ../../softmmu/physmem.c:2829
+    #2 0x55f8049423dd in flatview_read ../../softmmu/physmem.c:2862
+    #3 0x55f804942581 in address_space_read_full ../../softmmu/physmem.c:2875
+    #4 0x55f804942800 in address_space_rw ../../softmmu/physmem.c:2903
+    #5 0x55f8038d6a92 in dma_memory_rw_relaxed /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:88
+    #6 0x55f8038d6adf in dma_memory_rw /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:127
+    #7 0x55f8038d6b17 in dma_memory_read /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:145
+    #8 0x55f8038e47d9 in sdhci_do_adma ../../hw/sd/sdhci.c:807
+    #9 0x55f8038e6081 in sdhci_data_transfer ../../hw/sd/sdhci.c:905
+    #10 0x55f8038e694c in sdhci_resume_pending_transfer ../../hw/sd/sdhci.c:962
+    #11 0x55f8038e9227 in sdhci_write ../../hw/sd/sdhci.c:1118
+    #12 0x55f804856869 in memory_region_write_accessor ../../softmmu/memory.c:491
+    #13 0x55f804856cf4 in access_with_adjusted_size ../../softmmu/memory.c:552
+    #14 0x55f804863f28 in memory_region_dispatch_write ../../softmmu/memory.c:1501
+    #15 0x55f8049419ce in flatview_write_continue ../../softmmu/physmem.c:2759
+    #16 0x55f804941da4 in flatview_write ../../softmmu/physmem.c:2799
+    #17 0x55f804942724 in address_space_write ../../softmmu/physmem.c:2891
+    #18 0x55f804a9bee3 in qtest_process_command ../../softmmu/qtest.c:529
+    #19 0x55f804aa0dea in qtest_process_inbuf ../../softmmu/qtest.c:797
+    #20 0x55f804aa0edb in qtest_read ../../softmmu/qtest.c:809
+    #21 0x55f804ffb687 in qemu_chr_be_write_impl ../../chardev/char.c:201
+    #22 0x55f804ffb731 in qemu_chr_be_write ../../chardev/char.c:213
+    #23 0x55f804fe5369 in fd_chr_read ../../chardev/char-fd.c:68
+    #24 0x55f804f9b2dd in qio_channel_fd_source_dispatch ../../io/channel-watch.c:84
+    #25 0x7fe40c548e8d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51e8d)
+    #26 0x55f80540b38e in glib_pollfds_poll ../../util/main-loop.c:221
+    #27 0x55f80540b56f in os_host_main_loop_wait ../../util/main-loop.c:244
+    #28 0x55f80540b871 in main_loop_wait ../../util/main-loop.c:520
+    #29 0x55f80478602b in qemu_main_loop ../../softmmu/runstate.c:720
+    #30 0x55f8038091c9 in main ../../softmmu/main.c:50
+    #31 0x7fe409dc80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
+    #32 0x55f8038090dd in _start (/home/n0p/belajar/qemu/source/qemu/bin/new/qemu-system-x86_64+0x28d10dd)
+
+0x615000024180 is located 0 bytes to the right of 512-byte region [0x615000023f80,0x615000024180)
+allocated by thread T0 here:
+    #0 0x7fe40cbe6dc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
+    #1 0x7fe40c54ed30 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57d30)
+    #2 0x55f8040cd37b in sdhci_pci_realize ../../hw/sd/sdhci-pci.c:36
+    #3 0x55f80411c6f5 in pci_qdev_realize ../../hw/pci/pci.c:2124
+    #4 0x55f804fc7834 in device_set_realized ../../hw/core/qdev.c:761
+    #5 0x55f804f8002c in property_set_bool ../../qom/object.c:2251
+    #6 0x55f804f7a840 in object_property_set ../../qom/object.c:1399
+    #7 0x55f804f83419 in object_property_set_qobject ../../qom/qom-qobject.c:28
+    #8 0x55f804f7ae44 in object_property_set_bool ../../qom/object.c:1466
+    #9 0x55f804fc417a in qdev_realize ../../hw/core/qdev.c:389
+    #10 0x55f803da8bb7 in qdev_device_add ../../softmmu/qdev-monitor.c:665
+    #11 0x55f8047f5408 in device_init_func ../../softmmu/vl.c:1201
+    #12 0x55f8053d3644 in qemu_opts_foreach ../../util/qemu-option.c:1147
+    #13 0x55f8047fc593 in qemu_create_cli_devices ../../softmmu/vl.c:2488
+    #14 0x55f8047fc6fa in qmp_x_exit_preconfig ../../softmmu/vl.c:2527
+    #15 0x55f804801c8e in qemu_init ../../softmmu/vl.c:3534
+    #16 0x55f8038091c4 in main ../../softmmu/main.c:49
+    #17 0x7fe409dc80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c)
+Shadow bytes around the buggy address:
+  0x0c2a7fffc7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c2a7fffc7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c2a7fffc800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c2a7fffc810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c2a7fffc820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+=>0x0c2a7fffc830:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c2a7fffc840: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2a7fffc850: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2a7fffc860: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2a7fffc870: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2a7fffc880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+  Shadow gap:              cc
+==410717==ABORTING
+
+Please don't report security issues as private bugs here, see https://www.qemu.org/contribute/security-process/ for QEMU's security process. Thanks.
+
+This was found by OSS-Fuzz as well. Yankable reproducer:
+
++CC Phil. I know you mentioned you don't have time to fix many of the
+sdhci bugs, but this one seems like a large heap write, and the original
+reporter provided some analysis.
+
+On 210107 0307, Muhammad Ramdhan wrote:
+> ** Information type changed from Private Security to Public Security
+> 
+> -- 
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1909418
+> 
+> Title:
+>   QEMU: Heap Overflow vulnerability in SDHCI Component
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   Hello, i want to report qemu vulnerability in SDHCI component, this is
+>   integer overflow bug leads to oob read/write in the heap, that can
+>   happens in sdhci_do_adma or sdhci_sdma_transfer_multi_blocks.
+> 
+>   This is caused when in the middle of unfinished transfer, blksize can
+>   change, but the data_count still have the last offset of fifo_buffer
+>   from the last transfer. We change blksize to zero, then in the next
+>   transfer dma_memory_read/dma_memory_write in the first loop calculate
+>   length as blksize-data_count, this leads to integer overflow, because
+>   blksize is zero, and data_count can be more than zero.
+> 
+>   This bug is recorded in CVE-2020-25085, but the fix is not complete
+>   and not fix the root cause of the bug.
+>   Reproducer:
+
+Changing this so it is yankable:
+
+cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest \
+-m 512M -nodefaults -device sdhci-pci,sd-spec-version=3 \
+-device sd-card,drive=mydrive \
+-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
+-nographic -qtest stdio
+outl 0xcf8 0x80001010
+outl 0xcfc 0xd7055dba
+outl 0xcf8 0x80001003
+outl 0xcfc 0x86b1d733
+write 0x00 0x1 0x29
+write 0x02 0x1 0x10
+write 0x08 0x1 0x39
+writeb 0xd7055d2b 0x5e
+writel 0xd7055d2c 0xed7d735
+writew 0xd7055d30 0x126e
+writeb 0xd7055d32 0x84
+writel 0xd7055d24 0xd7346e01
+writew 0xd7055d28 0x3bd7
+writeb 0xd7055d2a 0x1
+writeb 0xd7055d05 0x2c
+writew 0xd7055d06 0x5c4
+writeb 0xd7055d0c 0x21
+writew 0xd7055d0e 0x846e
+writel 0xd7055d04 0x260000
+writew 0xd7055d08 0x0
+writeb 0xd7055d0a 0x6d
+writeb 0xd7055d0c 0x31
+clock_step
+EOF
+
+-Alex
+
+> 
+>   ➜  x86_64-softmmu git:(master) ✗ ./qemu-system-x86_64 -m 4G -nodefaults -trace 'sdhci*' -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -qtest stdio -accel qtest
+>   ==410717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+>   [I 1609122395.789698] OPENED
+>   qemu-system-x86_64: -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive: warning: bogus if=sd is deprecated, use if=none
+>   [R +0.037381] outl 0xcf8 0x80001010
+>   [S +0.037436] OK
+>   OK
+>   [R +0.037470] outl 0xcfc 0xd7055dba
+>   [S +0.037510] OK
+>   OK
+>   [R +0.037531] outl 0xcf8 0x80001003
+>   [S +0.037549] OK
+>   OK
+>   [R +0.037571] outl 0xcfc 0x86b1d733
+>   [S +0.039830] OK
+>   OK
+>   [R +0.039882] write 0x00 0x1 0x29
+>   [S +0.040364] OK
+>   OK
+>   [R +0.040401] write 0x02 0x1 0x10
+>   [S +0.040428] OK
+>   OK
+>   [R +0.040449] write 0x08 0x1 0x39
+>   [S +0.040472] OK
+>   OK
+>   [R +0.040491] writeb 0xd7055d2b 0x5e
+>   [S +0.040530] OK
+>   OK
+>   [R +0.040550] writel 0xd7055d2c 0xed7d735
+>   [S +0.040575] OK
+>   OK
+>   [R +0.040594] writew 0xd7055d30 0x126e
+>   [S +0.040620] OK
+>   OK
+>   [R +0.040638] writeb 0xd7055d32 0x84
+>   [S +0.040658] OK
+>   OK
+>   [R +0.040676] writel 0xd7055d24 0xd7346e01
+>   [S +0.040697] OK
+>   OK
+>   [R +0.040715] writew 0xd7055d28 0x3bd7
+>   [S +0.040738] OK
+>   OK
+>   [R +0.040756] writeb 0xd7055d2a 0x1
+>   [S +0.040779] OK
+>   OK
+>   [R +0.040797] writeb 0xd7055d05 0x2c
+>   [S +0.040819] OK
+>   OK
+>   [R +0.040840] writew 0xd7055d06 0x5c4
+>   [S +0.040862] OK
+>   OK
+>   [R +0.040882] writeb 0xd7055d0c 0x21
+>   [S +0.040907] OK
+>   OK
+>   [R +0.040927] writew 0xd7055d0e 0x846e
+>   [S +0.041026] OK
+>   OK
+>   [R +0.041054] writel 0xd7055d04 0x260000
+>   [S +0.041115] OK
+>   OK
+>   [R +0.041139] writew 0xd7055d08 0x0
+>   =================================================================
+>   ==410717==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000024180 at pc 0x7fe40cb7457d bp 0x7fffa1a7b800 sp 0x7fffa1a7afa8
+>   WRITE of size 786432 at 0x615000024180 thread T0
+>       #0 0x7fe40cb7457c  (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c)
+>       #1 0x55f804942120 in flatview_read_continue ../../softmmu/physmem.c:2829
+>       #2 0x55f8049423dd in flatview_read ../../softmmu/physmem.c:2862
+>       #3 0x55f804942581 in address_space_read_full ../../softmmu/physmem.c:2875
+>       #4 0x55f804942800 in address_space_rw ../../softmmu/physmem.c:2903
+>       #5 0x55f8038d6a92 in dma_memory_rw_relaxed /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:88
+>       #6 0x55f8038d6adf in dma_memory_rw /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:127
+>       #7 0x55f8038d6b17 in dma_memory_read /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:145
+>       #8 0x55f8038e47d9 in sdhci_do_adma ../../hw/sd/sdhci.c:807
+>       #9 0x55f8038e6081 in sdhci_data_transfer ../../hw/sd/sdhci.c:905
+>       #10 0x55f8038e694c in sdhci_resume_pending_transfer ../../hw/sd/sdhci.c:962
+>       #11 0x55f8038e9227 in sdhci_write ../../hw/sd/sdhci.c:1118
+>       #12 0x55f804856869 in memory_region_write_accessor ../../softmmu/memory.c:491
+>       #13 0x55f804856cf4 in access_with_adjusted_size ../../softmmu/memory.c:552
+>       #14 0x55f804863f28 in memory_region_dispatch_write ../../softmmu/memory.c:1501
+>       #15 0x55f8049419ce in flatview_write_continue ../../softmmu/physmem.c:2759
+>       #16 0x55f804941da4 in flatview_write ../../softmmu/physmem.c:2799
+>       #17 0x55f804942724 in address_space_write ../../softmmu/physmem.c:2891
+>       #18 0x55f804a9bee3 in qtest_process_command ../../softmmu/qtest.c:529
+>       #19 0x55f804aa0dea in qtest_process_inbuf ../../softmmu/qtest.c:797
+>       #20 0x55f804aa0edb in qtest_read ../../softmmu/qtest.c:809
+>       #21 0x55f804ffb687 in qemu_chr_be_write_impl ../../chardev/char.c:201
+>       #22 0x55f804ffb731 in qemu_chr_be_write ../../chardev/char.c:213
+>       #23 0x55f804fe5369 in fd_chr_read ../../chardev/char-fd.c:68
+>       #24 0x55f804f9b2dd in qio_channel_fd_source_dispatch ../../io/channel-watch.c:84
+>       #25 0x7fe40c548e8d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51e8d)
+>       #26 0x55f80540b38e in glib_pollfds_poll ../../util/main-loop.c:221
+>       #27 0x55f80540b56f in os_host_main_loop_wait ../../util/main-loop.c:244
+>       #28 0x55f80540b871 in main_loop_wait ../../util/main-loop.c:520
+>       #29 0x55f80478602b in qemu_main_loop ../../softmmu/runstate.c:720
+>       #30 0x55f8038091c9 in main ../../softmmu/main.c:50
+>       #31 0x7fe409dc80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
+>       #32 0x55f8038090dd in _start (/home/n0p/belajar/qemu/source/qemu/bin/new/qemu-system-x86_64+0x28d10dd)
+> 
+>   0x615000024180 is located 0 bytes to the right of 512-byte region [0x615000023f80,0x615000024180)
+>   allocated by thread T0 here:
+>       #0 0x7fe40cbe6dc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
+>       #1 0x7fe40c54ed30 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57d30)
+>       #2 0x55f8040cd37b in sdhci_pci_realize ../../hw/sd/sdhci-pci.c:36
+>       #3 0x55f80411c6f5 in pci_qdev_realize ../../hw/pci/pci.c:2124
+>       #4 0x55f804fc7834 in device_set_realized ../../hw/core/qdev.c:761
+>       #5 0x55f804f8002c in property_set_bool ../../qom/object.c:2251
+>       #6 0x55f804f7a840 in object_property_set ../../qom/object.c:1399
+>       #7 0x55f804f83419 in object_property_set_qobject ../../qom/qom-qobject.c:28
+>       #8 0x55f804f7ae44 in object_property_set_bool ../../qom/object.c:1466
+>       #9 0x55f804fc417a in qdev_realize ../../hw/core/qdev.c:389
+>       #10 0x55f803da8bb7 in qdev_device_add ../../softmmu/qdev-monitor.c:665
+>       #11 0x55f8047f5408 in device_init_func ../../softmmu/vl.c:1201
+>       #12 0x55f8053d3644 in qemu_opts_foreach ../../util/qemu-option.c:1147
+>       #13 0x55f8047fc593 in qemu_create_cli_devices ../../softmmu/vl.c:2488
+>       #14 0x55f8047fc6fa in qmp_x_exit_preconfig ../../softmmu/vl.c:2527
+>       #15 0x55f804801c8e in qemu_init ../../softmmu/vl.c:3534
+>       #16 0x55f8038091c4 in main ../../softmmu/main.c:49
+>       #17 0x7fe409dc80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
+> 
+>   SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c)
+>   Shadow bytes around the buggy address:
+>     0x0c2a7fffc7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+>     0x0c2a7fffc7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+>     0x0c2a7fffc800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+>     0x0c2a7fffc810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+>     0x0c2a7fffc820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+>   =>0x0c2a7fffc830:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+>     0x0c2a7fffc840: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+>     0x0c2a7fffc850: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+>     0x0c2a7fffc860: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+>     0x0c2a7fffc870: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+>     0x0c2a7fffc880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+>   Shadow byte legend (one shadow byte represents 8 application bytes):
+>     Addressable:           00
+>     Partially addressable: 01 02 03 04 05 06 07
+>     Heap left redzone:       fa
+>     Freed heap region:       fd
+>     Stack left redzone:      f1
+>     Stack mid redzone:       f2
+>     Stack right redzone:     f3
+>     Stack after return:      f5
+>     Stack use after scope:   f8
+>     Global redzone:          f9
+>     Global init order:       f6
+>     Poisoned by user:        f7
+>     Container overflow:      fc
+>     Array cookie:            ac
+>     Intra object redzone:    bb
+>     ASan internal:           fe
+>     Left alloca redzone:     ca
+>     Right alloca redzone:    cb
+>     Shadow gap:              cc
+>   ==410717==ABORTING
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1909418/+subscriptions
+> 
+
+
+Fixed here:
+https://gitlab.com/qemu-project/qemu/-/commit/cffb446e8fd19a14e1634c
+
diff --git a/results/classifier/zero-shot/108/device/1911797 b/results/classifier/zero-shot/108/device/1911797
new file mode 100644
index 00000000..13ef0a0c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1911797
@@ -0,0 +1,42 @@
+device: 0.921
+network: 0.877
+graphic: 0.873
+performance: 0.856
+semantic: 0.801
+other: 0.737
+socket: 0.602
+vnc: 0.542
+debug: 0.519
+PID: 0.511
+KVM: 0.506
+files: 0.285
+permissions: 0.283
+boot: 0.281
+
+hmp command `hostfwd_remove` does not work on running vm
+
+On a running VM, I ran the following two hmp commands:
+
+"hostfwd_add tcp::43210-:43210" --> WORKS
+'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format'
+
+QEMU version 5.1
+
+Looks like intended behavior:
+
+(qemu) help hostfwd_add
+hostfwd_add [netdev_id] [tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport -- redirect TCP or UDP connections from host to guest (requires -net user)
+(qemu) help hostfwd_remove
+hostfwd_remove [netdev_id] [tcp|udp]:[hostaddr]:hostport -- remove host-to-guest TCP or UDP redirection
+
+
+Not sure I understand. The intended behavior is to remove the ports. It doesn't do that. And it returns 'invalid format'.
+
+(qemu) hostfwd_add tcp::43210-:43210
+(qemu) hostfwd_remove tcp::43210-:43210
+invalid format
+
+My bad. The correct command is this:
+(qemu) hostfwd_remove tcp::43210
+This bug can be closed.
+
diff --git a/results/classifier/zero-shot/108/device/1922102 b/results/classifier/zero-shot/108/device/1922102
new file mode 100644
index 00000000..bfe35d60
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1922102
@@ -0,0 +1,97 @@
+device: 0.948
+network: 0.912
+files: 0.887
+other: 0.848
+PID: 0.811
+permissions: 0.798
+graphic: 0.766
+boot: 0.763
+performance: 0.760
+socket: 0.735
+debug: 0.703
+vnc: 0.700
+KVM: 0.618
+semantic: 0.591
+
+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
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+Ticket has been moved here (thanks, Vladislav!):
+https://gitlab.com/qemu-project/qemu/-/issues/335
+... thus I'm closing this on Launchpad now.
+
diff --git a/results/classifier/zero-shot/108/device/193 b/results/classifier/zero-shot/108/device/193
new file mode 100644
index 00000000..6bccdff6
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/193
@@ -0,0 +1,16 @@
+device: 0.931
+performance: 0.901
+network: 0.810
+PID: 0.798
+graphic: 0.774
+debug: 0.483
+boot: 0.319
+other: 0.148
+permissions: 0.106
+semantic: 0.089
+files: 0.055
+socket: 0.021
+vnc: 0.017
+KVM: 0.001
+
+piix crashes on mips when using multiple cpus
diff --git a/results/classifier/zero-shot/108/device/1945540 b/results/classifier/zero-shot/108/device/1945540
new file mode 100644
index 00000000..704b2dc9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/1945540
@@ -0,0 +1,190 @@
+device: 0.928
+semantic: 0.925
+files: 0.923
+debug: 0.919
+graphic: 0.917
+PID: 0.910
+network: 0.895
+permissions: 0.890
+other: 0.866
+socket: 0.846
+KVM: 0.833
+performance: 0.827
+vnc: 0.798
+boot: 0.621
+
+Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
+
+Host environment
+
+- Operating system: Ubuntu 20.04.3 LTS Desktop
+- OS/kernel version: Linux tower 5.11.0-37-generic #41~20.04.2-Ubuntu
+    SMP Fri Sep 24 09:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
+- Architecture: amd64
+- QEMU flavor: qemu-system-s390x
+- QEMU version: QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.17)
+- QEMU command line: See attached file 'command-line.txt'
+
+Emulated/Virtualized environment
+
+- Operating system: Ubuntu 20.04.3 LTS Server
+- OS/kernel version: Linux s390x-focal 5.4.0-88-generic #99-Ubuntu
+    SMP Thu Sep 23 17:27:44 UTC 2021 s390x s390x s390x GNU/Linux
+- Architecture: s390x
+
+Description of problem
+
+Java crashes as shown below:
+
+$ java --version
+#
+# A fatal error has been detected by the Java Runtime Environment:
+#
+#  SIGILL (0x4) at pc=0x000003ff9f5fe6f4, pid=6789, tid=6818
+#
+# JRE version:  (17.0+35) (build )
+# Java VM: OpenJDK 64-Bit Server VM (17+35-snap, mixed mode, sharing,
+# tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
+# Problematic frame:
+# C  [linux-vdso64.so.1+0x6f8]  __kernel_getcpu+0x8
+#
+# Core dump will be written. Default location: core.6789 (may not
+# exist)
+#
+# An error report file with more information is saved as:
+# /home/ubuntu/src/hs_err_pid6789.log
+#
+#
+Aborted (core dumped)
+
+Steps to reproduce
+
+Run any Java program to reproduce the problem.
+
+Because the 'openjdk' packages in Ubuntu run the 'java' command during installation, they hit the same error and fail to install. As an alternative, you can install the OpenJDK Snap package for the 's390x' architecture as follows:
+
+  $ sudo snap install openjdk
+
+The OpenJDK Snap package has been tested to work on a real IBM/S390 8561 system, namely the IBM LinuxONE III LT1 at Marist College:
+
+  Marist College Installs World’s First IBM LinuxONE III™
+  https://www.marist.edu/-/marist-first-linuxone-iii
+
+Additional information
+
+See the following attached files:
+
+command-line.txt - the command-line used to start the virtual machine
+hs_err_pid6789.log - the log file resulting from 'java --version'
+
+
+
+
+
+I just tried the same s390x virtual machine under QEMU version 6.0.0 in the Ubuntu 21.10 Beta release, and the error still occurs. My system information is shown below:
+
+$ qemu-system-s390x --version
+QEMU emulator version 6.0.0 (Debian 1:6.0+dfsg-2expubuntu1)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+
+$ cat /etc/lsb-release
+DISTRIB_ID=Ubuntu
+DISTRIB_RELEASE=21.10
+DISTRIB_CODENAME=impish
+DISTRIB_DESCRIPTION="Ubuntu Impish Indri (development branch)"
+
+$ uname -a
+Linux ubuntu 5.13.0-16-generic #16-Ubuntu SMP Fri Sep 3 14:53:27 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
+
+
+There were some fixes in QEMU v6.1. Please try that one to see whether it solves your problem, too.
+
+The error still occurs on the same s390x virtual machine with QEMU version 6.1.
+
+After building QEMU 6.1, I started the virtual machine as follows:
+
+  $ ../qemu-6.1.0/build/s390x-softmmu/qemu-system-s390x \
+    -m 2048 -drive if=virtio,file=s390x-focal.qcow2,cache=none
+
+The QEMU 6.1.0 monitor shows:
+
+  (qemu) info version
+  6.1.0
+
+On the guest, I installed the new 'openjdk-17-jre-headless' OpenJDK 17 package in Ubuntu 20.04. Although the installation fails because of this bug, the 'java' command is available after the attempt to install the package.
+
+  $ sudo apt-get install openjdk-17-jre-headless
+
+The error in this bug report still occurs:
+
+  $ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version
+  #
+  # A fatal error has been detected by the Java Runtime Environment:
+  #
+  #  SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884
+  #
+  # JRE version:  (17.0+35) (build )
+  # Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed
+  # mode, sharing, tiered, compressed oops, compressed class ptrs,
+  # serial gc, linux-s390x)
+  # Problematic frame:
+  # C  [linux-vdso64.so.1+0x6f8]  __kernel_getcpu+0x8
+  #
+  # Core dump will be written. Default location: Core dumps may
+  # be processed with "/usr/share/apport/apport %p %s %c %d %P %E"
+  # (or dumping to /home/ubuntu/core.2883)
+  #
+  # An error report file with more information is saved as:
+  # /home/ubuntu/hs_err_pid2883.log
+  #
+  #
+  Aborted (core dumped)
+
+I'll also attach the corresponding log file.
+
+For reference, the guest shows the following CPU information under QEMU 6.1.
+
+  $ lscpu
+  Architecture:                    s390x
+  CPU op-mode(s):                  32-bit, 64-bit
+  Byte Order:                      Big Endian
+  CPU(s):                          1
+  On-line CPU(s) list:             0
+  Thread(s) per core:              1
+  Core(s) per socket:              1
+  Socket(s) per book:              1
+  Book(s) per drawer:              1
+  Drawer(s):                       1
+  NUMA node(s):                    1
+  Vendor ID:                       IBM/S390
+  Machine type:                    3906
+  BogoMIPS:                        13370.00
+  Hypervisor:                      KVM/Linux
+  Hypervisor vendor:               KVM
+  Virtualization type:             full
+  Dispatching mode:                horizontal
+  NUMA node0 CPU(s):               0
+  ...
+
+
+
+
+Now that I can reproduce the problem on the latest QEMU 6.1, I created the following issue with the upstream project:
+
+Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
+https://gitlab.com/qemu-project/qemu/-/issues/655
+
+
+Thank you John,
+emulation on s390x is imperfect at times - the JVM might just use a non emulated instruction or something like that. I've linked your upstream report (thanks) here to that the bug automatically gets updates from there.
+
+Do we already happen to know at which (maybe always the same) instruction sequence this crashes?
+
+For more history on this issue, please see the following Debian bug report created in June 2021:
+
+openjdk-11-jre-headless: running java in qemu s390 gives a SIGILL at C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990417
+
+That report links to a simple C program that can reproduce the error.
+
+
diff --git a/results/classifier/zero-shot/108/device/2021 b/results/classifier/zero-shot/108/device/2021
new file mode 100644
index 00000000..3d3d8669
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2021
@@ -0,0 +1,16 @@
+device: 0.968
+performance: 0.963
+debug: 0.927
+other: 0.905
+graphic: 0.766
+network: 0.723
+PID: 0.698
+vnc: 0.534
+boot: 0.495
+KVM: 0.269
+permissions: 0.231
+socket: 0.141
+semantic: 0.111
+files: 0.034
+
+crashing when trying to read data from sensor though usb
diff --git a/results/classifier/zero-shot/108/device/2033 b/results/classifier/zero-shot/108/device/2033
new file mode 100644
index 00000000..cad09bb9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2033
@@ -0,0 +1,16 @@
+device: 0.945
+performance: 0.717
+network: 0.712
+graphic: 0.611
+debug: 0.403
+semantic: 0.355
+other: 0.168
+boot: 0.167
+vnc: 0.119
+files: 0.093
+permissions: 0.082
+PID: 0.060
+socket: 0.008
+KVM: 0.005
+
+goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL
diff --git a/results/classifier/zero-shot/108/device/204 b/results/classifier/zero-shot/108/device/204
new file mode 100644
index 00000000..a5c041ec
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/204
@@ -0,0 +1,16 @@
+device: 0.937
+performance: 0.698
+graphic: 0.512
+debug: 0.395
+other: 0.252
+vnc: 0.210
+PID: 0.200
+semantic: 0.189
+network: 0.066
+KVM: 0.052
+boot: 0.049
+permissions: 0.038
+socket: 0.017
+files: 0.002
+
+Dos Keypad is not working for numbers - numlock is not working
diff --git a/results/classifier/zero-shot/108/device/2044 b/results/classifier/zero-shot/108/device/2044
new file mode 100644
index 00000000..0e6728df
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2044
@@ -0,0 +1,20 @@
+device: 0.963
+graphic: 0.933
+boot: 0.884
+semantic: 0.596
+debug: 0.583
+files: 0.471
+other: 0.464
+PID: 0.395
+socket: 0.391
+vnc: 0.344
+network: 0.288
+performance: 0.228
+permissions: 0.132
+KVM: 0.007
+
+HP-UX 10.20 doesn't boot on QEMU 8.2.0-rc4
+Description of problem:
+After update QEMU for v8.2.0-rc4 existing HP-UX 10.20 installation doesn't work anymore. I also tried to boot the installation media and SeaBIOS stays in loop.
+Additional information:
+#
diff --git a/results/classifier/zero-shot/108/device/2049 b/results/classifier/zero-shot/108/device/2049
new file mode 100644
index 00000000..173ac5aa
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2049
@@ -0,0 +1,26 @@
+device: 0.926
+graphic: 0.867
+semantic: 0.845
+socket: 0.782
+other: 0.752
+network: 0.710
+debug: 0.641
+vnc: 0.552
+performance: 0.543
+boot: 0.490
+PID: 0.456
+files: 0.417
+permissions: 0.300
+KVM: 0.231
+
+drive-mirror RBD thin
+Description of problem:
+I found that this problem was first discovered in 2014. There was a post 
+[2014 bug description](https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01231.html )、
+[2014 patch](https://patchwork.ozlabs.org/project/qemu-devel/patch/1433747185-16797-2-git-send-email-famz@redhat.com/)
+mentioning this bug. 
+The patch in the post said that this problem had been solved, but after trying and asking, I found that the problem had not been solved.
+Later, I saw this problem in the [2017 bug description](https://forum.proxmox.com/threads/drive-mirror-rbd-thin.33250/#post-613502) forum and it was said that there was a patch to fix it, but it was not.
+I tried the latest qemu version and found that this problem has not been solved.
+Additional information:
+nbd is normal, but rbd is wrong！
diff --git a/results/classifier/zero-shot/108/device/2122 b/results/classifier/zero-shot/108/device/2122
new file mode 100644
index 00000000..41cfb6c9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2122
@@ -0,0 +1,22 @@
+device: 0.947
+graphic: 0.885
+semantic: 0.864
+debug: 0.666
+performance: 0.561
+permissions: 0.531
+network: 0.523
+boot: 0.387
+PID: 0.318
+vnc: 0.276
+socket: 0.229
+files: 0.219
+other: 0.048
+KVM: 0.011
+
+qemu-user-static segfault running ldconfig on host x86_64 with client arm64
+Description of problem:
+qemu segfault
+Steps to reproduce:
+1. download ubuntu jammy arm64 rootfs (I assume any will do)
+2. mount it (with /proc from host so apt is happy)
+3. execute an apt uninstall that triggers libc-bin processing
diff --git a/results/classifier/zero-shot/108/device/2174 b/results/classifier/zero-shot/108/device/2174
new file mode 100644
index 00000000..0243c96d
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2174
@@ -0,0 +1,16 @@
+device: 0.938
+performance: 0.738
+network: 0.595
+graphic: 0.565
+semantic: 0.477
+boot: 0.454
+socket: 0.430
+other: 0.416
+vnc: 0.365
+debug: 0.357
+permissions: 0.318
+PID: 0.167
+files: 0.075
+KVM: 0.009
+
+XenBus machines have almost no hotplug support
diff --git a/results/classifier/zero-shot/108/device/219 b/results/classifier/zero-shot/108/device/219
new file mode 100644
index 00000000..b3f7e424
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/219
@@ -0,0 +1,16 @@
+device: 0.926
+permissions: 0.694
+performance: 0.617
+semantic: 0.393
+graphic: 0.304
+boot: 0.220
+socket: 0.121
+network: 0.084
+files: 0.068
+other: 0.049
+PID: 0.037
+vnc: 0.030
+debug: 0.020
+KVM: 0.002
+
+Request A Port of QEMU to UWP for xbox dev mode
diff --git a/results/classifier/zero-shot/108/device/221 b/results/classifier/zero-shot/108/device/221
new file mode 100644
index 00000000..092b4f4f
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/221
@@ -0,0 +1,16 @@
+device: 0.937
+performance: 0.923
+network: 0.850
+graphic: 0.798
+debug: 0.506
+boot: 0.386
+permissions: 0.261
+semantic: 0.215
+socket: 0.175
+other: 0.164
+PID: 0.085
+files: 0.045
+vnc: 0.022
+KVM: 0.002
+
+piix crashes on mips when accessing acpi-pci-hotplug
diff --git a/results/classifier/zero-shot/108/device/2213 b/results/classifier/zero-shot/108/device/2213
new file mode 100644
index 00000000..634c59c9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2213
@@ -0,0 +1,30 @@
+device: 0.935
+graphic: 0.929
+other: 0.825
+boot: 0.646
+vnc: 0.616
+semantic: 0.588
+performance: 0.585
+debug: 0.546
+permissions: 0.524
+socket: 0.471
+PID: 0.469
+network: 0.346
+files: 0.337
+KVM: 0.031
+
+QEMU fails with duplicate SaveStateEntry when using two legacy virtio input devices
+Description of problem:
+QEMU bails out when it is started with two virtio-input devices running in legacy virtio mode, using two different transports (like PCI and CCW on s390x).
+Steps to reproduce:
+```
+qemu-system-s390x -M s390-ccw-virtio-2.6 -cpu max -nographic -device virtio-multitouch-pci -device virtio-tablet-ccw
+```
+fails with:
+```
+qemu-system-s390x: -device virtio-tablet-ccw: savevm_state_handler_insert: Detected duplicate SaveStateEntry: id=virtio-input, instance_id=0x0
+```
+Additional information:
+The problem does *not* occur if using modern virtio devices (which automatically happens for -M s390-ccw-virtio-2.7 and newer) or if using virtio-input devices with the same transport (e.g. two PCI devices instead of one PCI and one CCW).
+
+Also note that the problem only occurs since QEMU 8.1 since older versions did not check for duplicate SaveStateEntries (see commit caa91b3c44cdb2d2921e25 ).
diff --git a/results/classifier/zero-shot/108/device/224 b/results/classifier/zero-shot/108/device/224
new file mode 100644
index 00000000..e482ddf9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/224
@@ -0,0 +1,16 @@
+device: 0.956
+debug: 0.869
+performance: 0.825
+graphic: 0.732
+other: 0.675
+network: 0.665
+boot: 0.363
+vnc: 0.329
+semantic: 0.297
+permissions: 0.199
+PID: 0.153
+socket: 0.146
+files: 0.024
+KVM: 0.021
+
+Wrong interrupts generated for I.MX6 FEC controller
diff --git a/results/classifier/zero-shot/108/device/2243 b/results/classifier/zero-shot/108/device/2243
new file mode 100644
index 00000000..fa95adb3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2243
@@ -0,0 +1,24 @@
+device: 0.938
+graphic: 0.853
+permissions: 0.530
+socket: 0.525
+semantic: 0.520
+boot: 0.475
+debug: 0.468
+vnc: 0.437
+files: 0.435
+other: 0.399
+PID: 0.397
+network: 0.366
+performance: 0.354
+KVM: 0.199
+
+ES1370 sound card can crash the Windows 2000 and Windows XP guest.
+Description of problem:
+If using ES1370 sound card with Windows 2000 and Windows XP guest, it will crash the Windows 2000 and Windows XP guest. Windows 2000 and Windows XP have built in ES1370 driver.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/2268 b/results/classifier/zero-shot/108/device/2268
new file mode 100644
index 00000000..f0e48439
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2268
@@ -0,0 +1,58 @@
+device: 0.934
+debug: 0.910
+network: 0.900
+PID: 0.896
+permissions: 0.895
+performance: 0.892
+other: 0.885
+boot: 0.883
+files: 0.880
+graphic: 0.855
+socket: 0.826
+semantic: 0.784
+vnc: 0.729
+KVM: 0.556
+
+Out of bounds access in smc91c111_readb()
+Description of problem:
+I detected an out-of-bounds access in smc91c111_readb with my fuzzer.
+
+Stack trace (part):\
+`hw/net/smc91c111.c:607:24: runtime error: index 175 out of bounds for`\
+`type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]')`\
+`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior`\
+`hw/net/smc91c111.c:607:24 in`\
+`AddressSanitizer:DEADLYSIGNAL`\
+`==============================`<wbr>`==============================`<wbr>`=====`\
+`==397944==ERROR: AddressSanitizer: SEGV on unknown address`\
+`0x629000077db4 (pc 0x56272aed3b8d bp 0x7ffd1471f290 sp 0x7ffd1471ea20`\
+`T0)`\
+`==397944==The signal is caused by a READ memory access.`\
+    `#0 0x56272aed3b8d in smc91c111_readb hw/net/smc91c111.c:607:24`\
+    `#1 0x56272aecfd61 in smc91c111_readfn hw/net/smc91c111.c:650:16`\
+    `#2 0x56272d4b228b in memory_region_read_accessor system/memory.c:445:11`\
+    `#3 0x56272d46fb85 in access_with_adjusted_size system/memory.c:573:18`\
+    `#4 0x56272d46c58e in memory_region_dispatch_read1 system/memory.c:1426:16`\
+    `#5 0x56272d46bcd7 in memory_region_dispatch_read system/memory.c:1459:9`\
+    `#6 0x56272d4e8e03 in flatview_read_continue_step system/physmem.c:2794:18`\
+    `#7 0x56272d4e871e in flatview_read_continue system/physmem.c:2835:19`\
+    `#8 0x56272d4e98b8 in flatview_read system/physmem.c:2865:12`\
+    `#9 0x56272d4e9388 in address_space_read_full system/physmem.c:2878:18`\
+    `#10 0x56272d6e7840 in address_space_read include/exec/memory.h:3026:18`\
+`...`\
+Bug analysis: I found s-\>packet_num = 175 at line 599.
+Steps to reproduce:
+Reproducer:\
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\
+mainstone"\
+cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\
+outl 0xcf8 0x80000010\
+outl 0xcfc 0x10000300\
+outl 0xcf8 0x80000004\
+outl 0xcfc 0x07\
+writel 0x1000030c 0x66027cd6\
+writel 0x10000300 0x64af8eda\
+readw 0x10000308\
+EOF
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/results/classifier/zero-shot/108/device/2272 b/results/classifier/zero-shot/108/device/2272
new file mode 100644
index 00000000..c57f284a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2272
@@ -0,0 +1,36 @@
+device: 0.927
+semantic: 0.676
+debug: 0.668
+graphic: 0.653
+PID: 0.622
+boot: 0.553
+vnc: 0.544
+permissions: 0.440
+socket: 0.344
+performance: 0.343
+files: 0.305
+network: 0.225
+KVM: 0.095
+other: 0.088
+
+Memory leak in the virtual device applesmc
+Description of problem:
+In the function _qdev_applesmc_isa_reset_, the device mallocs the _AppleSMCData_ but does not free them, causing a memory leak.
+
+The following log reveals it:
+
+```
+==1029295==ERROR: LeakSanitizer: detected memory leaksDirect leak of 80 byte(s) in 2 object(s) allocated from:
+#0 0x5574dc600a82 in __interceptor_calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 
+#1 0x7f4919b22c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50)
+#2 0x5574dcdb0dfe in qdev_applesmc_isa_reset qemu/hw/misc/applesmc.c:285:5 
+#3 0x5574de30e099 in resettable_phase_hold qemu/hw/core/resettable.c 
+#4 0x5574de2ef753 in bus_reset_child_foreach qemu/hw/core/bus.c:97:13 
+#5 0x5574de30dcfe in resettable_child_foreach qemu/hw/core/resettable.c:96:9 
+#6 0x5574de30dcfe in resettable_phase_hold qemu/hw/core/resettable.c:173:5 
+#7 0x5574de3059b3 in device_reset_child_foreach qemu/hw/core/qdev.c:276:9
+```
+Steps to reproduce:
+1. Build qemu with the sanitizer
+2. Boot the Linux kernel with the above command line.
+3. Stop the qemu process
diff --git a/results/classifier/zero-shot/108/device/2282 b/results/classifier/zero-shot/108/device/2282
new file mode 100644
index 00000000..da0714b3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2282
@@ -0,0 +1,16 @@
+device: 0.950
+graphic: 0.863
+performance: 0.594
+debug: 0.463
+semantic: 0.242
+network: 0.238
+files: 0.234
+other: 0.212
+permissions: 0.124
+vnc: 0.119
+PID: 0.105
+boot: 0.016
+socket: 0.007
+KVM: 0.003
+
+Corrupted output when using Intel Arc GPU with qemu+spice+virgl in headed mode
diff --git a/results/classifier/zero-shot/108/device/2294 b/results/classifier/zero-shot/108/device/2294
new file mode 100644
index 00000000..3e3c98de
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2294
@@ -0,0 +1,16 @@
+device: 0.969
+performance: 0.813
+boot: 0.598
+graphic: 0.506
+debug: 0.348
+semantic: 0.341
+permissions: 0.339
+PID: 0.239
+files: 0.147
+network: 0.105
+socket: 0.096
+vnc: 0.083
+other: 0.020
+KVM: 0.011
+
+x86 microvm machine stuck under Xen accelerator
diff --git a/results/classifier/zero-shot/108/device/2312 b/results/classifier/zero-shot/108/device/2312
new file mode 100644
index 00000000..f0c53eef
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2312
@@ -0,0 +1,59 @@
+device: 0.951
+boot: 0.951
+PID: 0.949
+debug: 0.944
+files: 0.922
+permissions: 0.914
+other: 0.913
+vnc: 0.902
+graphic: 0.901
+performance: 0.891
+semantic: 0.838
+socket: 0.822
+network: 0.759
+KVM: 0.701
+
+hvf_vcpu_exec isv assert with qemu-xhci device
+Description of problem:
+Using the qemu-xhci device with HVF on darwin-aarch64 causes [this assert](https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1920) to fire.
+
+```
+travis@gmachine vms % cat launch.sh
+#!/usr/bin/env bash
+
+~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 \
+    -nographic \
+    -machine virt \
+    -accel hvf \
+    -cpu host \
+    -m 16M \
+    -device qemu-xhci \
+    -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin
+travis@gmachine vms % ./launch.sh
+
+
+U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)
+
+DRAM:  16 MiB (effective 16 EiB)
+Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1920.
+./launch.sh: line 10: 22295 Abort trap: 6           ~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin
+```
+
+This is NixOS' build of u-boot 2024.04. This is also Nixpkgs' build of qemu-9.0.0; by default it contains some patches, but if I remove those and build with the unmodified release tarball there's no change in behavior. Naturally this doesn't happen with TCG and I haven't found any other (non-USB) device to cause this issue.
+Steps to reproduce:
+On a darwin-aarch64 machine with git and nix setup (8.2.2 is latest in Nixpkgs head, the same problem occurs with 9.0.0):
+
+```
+% git clone https://github.com/nixos/nixpkgs
+% cd ./nixpkgs
+% $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios $(nix-build -E 'with import ./default.nix {system = "aarch64-linux";}; ubootQemuAarch64')/u-boot.bin
+
+
+U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)
+
+DRAM:  16 MiB (effective 16 EiB)
+Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1915.
+zsh: abort      $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel 
+```
+Additional information:
+I have not yet tried other u-boot binaries. I suppose it could be u-boots fault? Eyeballing hvf.c this seems to be an unhandled case in the MMIO callback? I'm far out of my element so that could be total nonsense.
diff --git a/results/classifier/zero-shot/108/device/2327 b/results/classifier/zero-shot/108/device/2327
new file mode 100644
index 00000000..dc388bb2
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2327
@@ -0,0 +1,76 @@
+device: 0.948
+graphic: 0.948
+permissions: 0.930
+semantic: 0.929
+debug: 0.929
+other: 0.919
+PID: 0.917
+vnc: 0.910
+boot: 0.907
+performance: 0.906
+socket: 0.873
+KVM: 0.872
+network: 0.848
+files: 0.772
+
+negative shift exponent in cirrus_colorexpand_pattern_transp_0_24()
+Description of problem:
+My fuzzer detected a runtime error in cirrus_colorexpand_pattern_transp_0_24()
+
+The stack trace is:
+
+```
+../hw/display/cirrus_vga_rop2.h:216:23: runtime error: shift exponent -2 is negative
+    #0 0x5589a028c89a in cirrus_colorexpand_pattern_transp_0_24 hw/display/cirrus_vga_rop2.h:216:23
+    #1 0x5589a031e239 in cirrus_bitblt_common_patterncopy hw/display/cirrus_vga.c:689:5
+    #2 0x5589a032735d in cirrus_bitblt_cputovideo_next hw/display/cirrus_vga.c:820:13
+    #3 0x5589a032cde9 in cirrus_linear_write hw/display/cirrus_vga.c:2365:13
+    #4 0x5589a2982823 in memory_region_write_accessor system/memory.c:497:5
+    #5 0x5589a2981f05 in access_with_adjusted_size system/memory.c:573:18
+    #6 0x5589a297fe69 in memory_region_dispatch_write system/memory.c:1521:16
+    #7 0x5589a2a2193e in flatview_write_continue_step system/physmem.c:2749:18
+    #8 0x5589a2a211d4 in flatview_write_continue system/physmem.c:2779:19
+    #9 0x5589a29f9cfb in flatview_write system/physmem.c:2810:12
+    #10 0x5589a29f97c8 in address_space_write system/physmem.c:2930:18
+...
+```
+Steps to reproduce:
+Arguments:\
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\
+q35 -nodefaults -device cirrus-vga -display vnc=localhost:99 -L ../pc-bios/"\
+The base addresses of memory regions:
+
+* cirrus-io, 0x3b0
+* cirrus-low-memory, 0xa0000
+* cirrus-linear-io, 0xe0000000
+* cirrus-bitblt-mmio, 0xe1000000
+* cirrus-mmio, 0xe2000000
+
+Reproducer:
+
+```
+writeb 0xe2000108 0x642a8d58
+writeb 0xe2000117 0x335af91c
+writeb 0xe2000118 0x765861ed
+writeb 0xe200010d 0x7c3af934
+writeb 0xe2000140 0x33f13baf
+clock_step
+writeb 0xe01f0e68 0x6ea3696c
+writeb 0xe13bc720 0x11bb09ba
+readb 0xe2000133
+writeb 0xe033629b 0x80f19dd
+writeb 0xe134bba7 0x1eb198f9
+readb 0xe2000680
+writeb 0xe2000b84 0x3f0591fc
+clock_step
+writeb 0xe003469e 0xdbd627e
+writeb 0xe114f2bc 0x41adfe48
+readb 0xe2000cde
+readb 0xb269d
+writeb 0xe1368066 0x3c9ab77
+readb 0xe12a7fe1
+writeb 0xe0191988 0x7e18b0d1
+EOF
+```
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/results/classifier/zero-shot/108/device/2336 b/results/classifier/zero-shot/108/device/2336
new file mode 100644
index 00000000..6500de82
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2336
@@ -0,0 +1,38 @@
+device: 0.944
+graphic: 0.928
+files: 0.895
+PID: 0.838
+network: 0.804
+performance: 0.778
+semantic: 0.744
+debug: 0.738
+permissions: 0.630
+vnc: 0.607
+socket: 0.599
+boot: 0.555
+other: 0.165
+KVM: 0.107
+
+qemu-x86_64 crash on LoongArch
+Description of problem:
+
+Steps to reproduce:
+1. build a static  hello test on x86_64 machine.
+2. build qemu-x86_64 on LoongArch.
+3. run 'qemu-x86_64 hello 'on LoongArch.
+Additional information:
+1  result
+
+[root@localhost qemu]# ./build/qemu-x86_64 ~/hello  
+Bus error (core dumped)
+
+2  Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 
+
+3  full log with -d in_asm,op,out_asm,strace
+see log.txt
+
+[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt)
+
+[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64)
+
+[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello)
diff --git a/results/classifier/zero-shot/108/device/2348 b/results/classifier/zero-shot/108/device/2348
new file mode 100644
index 00000000..f6e06e38
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2348
@@ -0,0 +1,22 @@
+device: 0.935
+graphic: 0.840
+semantic: 0.717
+performance: 0.700
+boot: 0.679
+debug: 0.656
+permissions: 0.503
+other: 0.474
+PID: 0.429
+vnc: 0.401
+files: 0.286
+socket: 0.099
+network: 0.050
+KVM: 0.040
+
+Grabbing is not possible with menu-mode disabled
+Description of problem:
+When starting a Qemu and bringing it into Focus, I expected Ctrl + Alt + g to enable Input Grab mode. This does not occur when the menu-bar is hidden. It does occur when the menu-bar is visible.
+Steps to reproduce:
+1. Open a QEMU instance in a Arch / KDE host (not fullscreen)
+2. Focus the instance and attempt to enable Input Grabbing (Ctrl + Alt + G)
+3. Observe that Input Grab Mode is not toggled
diff --git a/results/classifier/zero-shot/108/device/2357 b/results/classifier/zero-shot/108/device/2357
new file mode 100644
index 00000000..0ccc278f
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2357
@@ -0,0 +1,33 @@
+device: 0.935
+graphic: 0.916
+performance: 0.851
+network: 0.795
+socket: 0.753
+vnc: 0.701
+PID: 0.694
+debug: 0.669
+files: 0.655
+semantic: 0.553
+boot: 0.402
+permissions: 0.274
+KVM: 0.267
+other: 0.223
+
+assert in dwc2
+Description of problem:
+The following log reveals it:
+
+```
+ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached
+Bail out! ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-aarch64 -display \
+none -machine accel=qtest, -m 512M -machine raspi2b -m 1G -nodefaults \
+-usb -drive file=null-co://,if=none,format=raw,id=disk0 -device \
+usb-storage,port=1,drive=disk0 -qtest stdio
+readl 0x3f980dfb
+EOF
+```
diff --git a/results/classifier/zero-shot/108/device/2438 b/results/classifier/zero-shot/108/device/2438
new file mode 100644
index 00000000..3b553280
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2438
@@ -0,0 +1,16 @@
+device: 0.931
+performance: 0.785
+network: 0.700
+boot: 0.438
+permissions: 0.426
+debug: 0.398
+graphic: 0.390
+semantic: 0.239
+files: 0.234
+vnc: 0.212
+socket: 0.139
+other: 0.082
+PID: 0.042
+KVM: 0.002
+
+QEMU needs compat tweak to build against upstream capstone 6
diff --git a/results/classifier/zero-shot/108/device/2443 b/results/classifier/zero-shot/108/device/2443
new file mode 100644
index 00000000..0d1e62ab
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2443
@@ -0,0 +1,33 @@
+device: 0.987
+PID: 0.715
+network: 0.667
+graphic: 0.581
+vnc: 0.558
+socket: 0.507
+permissions: 0.474
+debug: 0.472
+performance: 0.471
+semantic: 0.469
+files: 0.410
+other: 0.378
+boot: 0.345
+KVM: 0.125
+
+virtio-gpu-gl: "opengl is not available" message is too vague and doesn't suggest how to fix the problem
+Description of problem:
+I finally compiled qemu for Apple Silicon M2 Pro with opengl enabled and virtglrenderer enabled thanks to instruction from homebrew formula,
+but I did it without homebrew nor macports just manually compiling necessary libraries.
+Qemu was compiled succesfully with flags:
+````
+./configure --target-list=aarch64-softmmu,x86_64-softmmu --enable-cocoa  --enable-sdl --enable-virglrenderer --enable-vhost-net   --enable-spice-protocol --enable-tools --enable-opengl --enable-pixman --enable-vmnet
+````
+
+the device is clearly listed:
+````
+name "virtio-gpu-device", bus virtio-bus
+name "virtio-gpu-gl-device", bus virtio-bus
+name "virtio-gpu-gl-pci", bus PCI, alias "virtio-gpu-gl"
+name "virtio-gpu-pci", bus PCI, alias "virtio-gpu"
+````
+
+So why it not working and gives that info while opengl is clearly there and is enabled.
diff --git a/results/classifier/zero-shot/108/device/2454 b/results/classifier/zero-shot/108/device/2454
new file mode 100644
index 00000000..9447103c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2454
@@ -0,0 +1,23 @@
+device: 0.935
+graphic: 0.904
+PID: 0.724
+socket: 0.690
+semantic: 0.685
+performance: 0.662
+debug: 0.628
+KVM: 0.621
+network: 0.490
+files: 0.393
+vnc: 0.261
+boot: 0.183
+other: 0.053
+permissions: 0.016
+
+sd: assertion in sd_read_byte()
+Description of problem:
+The following log reveals it:
+
+```
+ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached
+Bail out! ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached Aborted (core dumped)
+```
diff --git a/results/classifier/zero-shot/108/device/2468 b/results/classifier/zero-shot/108/device/2468
new file mode 100644
index 00000000..74a4db1d
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2468
@@ -0,0 +1,48 @@
+device: 0.929
+debug: 0.836
+graphic: 0.774
+vnc: 0.693
+boot: 0.674
+socket: 0.671
+performance: 0.654
+network: 0.606
+files: 0.504
+semantic: 0.490
+PID: 0.407
+permissions: 0.383
+other: 0.295
+KVM: 0.236
+
+m68k: movec to/from CAAR not emulated?
+Description of problem:
+
+Steps to reproduce:
+1. Start adding a machine for the Motorola MVME147 VME module
+2. Step through the standard ROM for this board (147BUG)
+3. Step until `ff823bf0 4e 7b 18 02     movec      D1,CAAR`
+4. Watch QEMU show a fatal error for an unimplemented control register:
+
+```
+QEMU 9.0.50 monitor - type 'help' for more information
+(qemu) qemu: fatal: Unimplemented control register write 0x802 = 0xffffffff
+
+D0 = ffffffff   A0 = fffe0000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = ffffffff   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = ffff271f   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = ffffffff   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = ffffffff   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = ffffffff   A5 = 00000400   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = ffffffff   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = ffffffff   A7 = 000037dc   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff823bf0   SR = 2714 T:0 I:7 SI X-Z--
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = ffffffff ->A7(ISP) = 000037dc
+VBR = 0xffffffff
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/248 b/results/classifier/zero-shot/108/device/248
new file mode 100644
index 00000000..9d58b6a7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/248
@@ -0,0 +1,16 @@
+device: 0.937
+network: 0.910
+performance: 0.837
+graphic: 0.757
+vnc: 0.584
+PID: 0.469
+semantic: 0.351
+debug: 0.343
+socket: 0.285
+permissions: 0.285
+KVM: 0.239
+boot: 0.216
+files: 0.209
+other: 0.131
+
+Reconnect failed with loopback virtio1.1 server mode test
diff --git a/results/classifier/zero-shot/108/device/251 b/results/classifier/zero-shot/108/device/251
new file mode 100644
index 00000000..c6fe992c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/251
@@ -0,0 +1,16 @@
+device: 0.927
+performance: 0.866
+graphic: 0.682
+semantic: 0.409
+other: 0.169
+debug: 0.127
+socket: 0.112
+vnc: 0.086
+boot: 0.081
+files: 0.077
+permissions: 0.073
+PID: 0.069
+network: 0.039
+KVM: 0.001
+
+Qemu DOS Quake - 640x480 and above resolutions - Unable to load VESA palette in dos prompt and game crashing are not working
diff --git a/results/classifier/zero-shot/108/device/2636 b/results/classifier/zero-shot/108/device/2636
new file mode 100644
index 00000000..4a08385f
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2636
@@ -0,0 +1,16 @@
+device: 0.955
+performance: 0.891
+graphic: 0.625
+files: 0.617
+network: 0.599
+boot: 0.594
+semantic: 0.437
+debug: 0.323
+permissions: 0.194
+other: 0.149
+socket: 0.133
+PID: 0.119
+vnc: 0.104
+KVM: 0.014
+
+ast2600 fails to run u-boot
diff --git a/results/classifier/zero-shot/108/device/2640 b/results/classifier/zero-shot/108/device/2640
new file mode 100644
index 00000000..1c140c78
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2640
@@ -0,0 +1,16 @@
+device: 0.940
+debug: 0.822
+performance: 0.792
+network: 0.752
+graphic: 0.424
+files: 0.300
+boot: 0.288
+permissions: 0.234
+semantic: 0.227
+PID: 0.154
+other: 0.114
+socket: 0.045
+vnc: 0.036
+KVM: 0.003
+
+QEMU twice logging when use SDL.
diff --git a/results/classifier/zero-shot/108/device/2653 b/results/classifier/zero-shot/108/device/2653
new file mode 100644
index 00000000..ddfe2ac6
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2653
@@ -0,0 +1,16 @@
+device: 0.934
+performance: 0.690
+graphic: 0.478
+other: 0.301
+semantic: 0.288
+permissions: 0.241
+boot: 0.202
+vnc: 0.166
+debug: 0.131
+PID: 0.074
+network: 0.062
+files: 0.020
+socket: 0.004
+KVM: 0.001
+
+Intel iGPU sriov
diff --git a/results/classifier/zero-shot/108/device/2654 b/results/classifier/zero-shot/108/device/2654
new file mode 100644
index 00000000..17a20d0d
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2654
@@ -0,0 +1,29 @@
+device: 0.931
+network: 0.912
+boot: 0.838
+graphic: 0.816
+PID: 0.748
+files: 0.714
+socket: 0.664
+vnc: 0.660
+performance: 0.599
+semantic: 0.472
+permissions: 0.441
+debug: 0.437
+other: 0.229
+KVM: 0.026
+
+qemu-system-i386 no longer boots NetBSD
+Description of problem:
+Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD.
+Steps to reproduce:
+```
+wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso
+qemu-system-i386 -cdrom NetBSD-10.0-i386.iso
+```
+
+Expected behavior: Boots into the NetBSD installer
+
+Observed incorrect behavior: Boot hangs with a black screen
+Additional information:
+This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/results/classifier/zero-shot/108/device/2663 b/results/classifier/zero-shot/108/device/2663
new file mode 100644
index 00000000..26ae5167
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2663
@@ -0,0 +1,22 @@
+device: 0.933
+files: 0.821
+other: 0.723
+network: 0.722
+performance: 0.712
+graphic: 0.662
+semantic: 0.641
+debug: 0.588
+socket: 0.547
+vnc: 0.544
+boot: 0.466
+permissions: 0.352
+PID: 0.318
+KVM: 0.151
+
+powerpc: for 6xx,7xx,74xx msr and srr1 are not set correctly on exception
+Description of problem:
+When an exception is raised, qemu does not set bits in SRR1 and MSR correctly.
+
+This causes some operating systems to not work, in particular early little endian ones like Windows NT.
+Additional information:
+The following patch changes the MSR and SRR1 bit settings on exception to what is mentioned in the various user manuals for the 6xx, 7xx and 74xx series (6xx and 7xx are effectively identical, 74xx has some additional changes): [exception_msr.patch](/uploads/aae17dd35f0f0e72b831243fcfd0c416/exception_msr.patch)
diff --git a/results/classifier/zero-shot/108/device/2695 b/results/classifier/zero-shot/108/device/2695
new file mode 100644
index 00000000..cd2223e9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2695
@@ -0,0 +1,18 @@
+device: 0.982
+other: 0.958
+semantic: 0.954
+graphic: 0.912
+socket: 0.677
+debug: 0.639
+network: 0.540
+performance: 0.536
+vnc: 0.533
+boot: 0.433
+permissions: 0.206
+KVM: 0.167
+PID: 0.144
+files: 0.098
+
+how to onboard fw_cfg to other machines
+Additional information:
+Would it be doable for other machines actually? I didn't dig deeper into this device to understand, but I guess it is connected to the VM somehow and it has some memory mapped to the OS?
diff --git a/results/classifier/zero-shot/108/device/2698 b/results/classifier/zero-shot/108/device/2698
new file mode 100644
index 00000000..38b211e7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2698
@@ -0,0 +1,24 @@
+device: 0.929
+graphic: 0.853
+semantic: 0.529
+debug: 0.519
+performance: 0.498
+vnc: 0.367
+boot: 0.344
+PID: 0.196
+network: 0.115
+files: 0.091
+socket: 0.087
+permissions: 0.046
+other: 0.022
+KVM: 0.015
+
+virtualization not working with TCG mode on macOS
+Description of problem:
+TCG is supposed to work with virtualization=on option but it stops without priting anything.
+if I set it to off, I can get to the prompt.
+Steps to reproduce:
+1. Execute the qemu
+2. Hung.
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/2700 b/results/classifier/zero-shot/108/device/2700
new file mode 100644
index 00000000..bc07bf00
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2700
@@ -0,0 +1,23 @@
+device: 0.936
+graphic: 0.912
+boot: 0.903
+semantic: 0.742
+other: 0.692
+debug: 0.361
+vnc: 0.352
+performance: 0.260
+PID: 0.235
+files: 0.198
+permissions: 0.153
+network: 0.120
+socket: 0.117
+KVM: 0.008
+
+Windows 11 24H2 (x64) fails to boot
+Description of problem:
+When trying to boot Windows 11 24H2 (including the installer), the guest will just restart.
+Steps to reproduce:
+1. Download Windows 11 ISO from: https://www.microsoft.com/en-us/software-download/windows11
+2. Run the command above
+Additional information:
+I tested it on an M4 Pro Mac running TCG. Other users have reported the same issue with M3 running TCG and Intel i9 running HVF.
diff --git a/results/classifier/zero-shot/108/device/2707 b/results/classifier/zero-shot/108/device/2707
new file mode 100644
index 00000000..486840c4
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2707
@@ -0,0 +1,25 @@
+device: 0.976
+graphic: 0.901
+performance: 0.709
+PID: 0.659
+debug: 0.632
+network: 0.572
+vnc: 0.455
+semantic: 0.454
+socket: 0.437
+other: 0.336
+boot: 0.234
+permissions: 0.181
+files: 0.116
+KVM: 0.008
+
+virtio-balloon crashes in a object assert when querying stats
+Description of problem:
+Fetch virtio-balloon stats will crash a QEMU crash with assert failures
+Steps to reproduce:
+1. ./qemu-system-x86_64 -device virtio-balloon,id=balloon -qmp qmp.sock
+2. Connect to qmp.sock
+3. Issue  'qom-get path=/machine/peripheral/balloon property=guest-stats'
+4. QEMU go boom!
+Additional information:
+This is a regression caused by commit 0d2eeef77a33315187df8519491a900bde4a3d83, which failed to update `balloon_stat_names` with the new stats names, causing code to try to add a QDict entry with a NULL key.
diff --git a/results/classifier/zero-shot/108/device/2724 b/results/classifier/zero-shot/108/device/2724
new file mode 100644
index 00000000..0ba60f8b
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2724
@@ -0,0 +1,23 @@
+device: 0.935
+graphic: 0.856
+socket: 0.777
+debug: 0.670
+vnc: 0.596
+boot: 0.593
+semantic: 0.510
+network: 0.504
+performance: 0.422
+PID: 0.290
+KVM: 0.267
+files: 0.231
+other: 0.202
+permissions: 0.154
+
+Invalid DRM modifier in ScanoutDMABUF call
+Description of problem:
+`modifier` parameter in `ScanoutDMABUF` callback is always `0xffffffffffffff` (`DRM_FORMAT_RESERVED`)
+Steps to reproduce:
+1. Run QEMU with D-Bus display
+2. Connect D-Bus display client and print modifier
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/2734 b/results/classifier/zero-shot/108/device/2734
new file mode 100644
index 00000000..2b8c2738
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2734
@@ -0,0 +1,39 @@
+device: 0.931
+graphic: 0.835
+socket: 0.799
+performance: 0.784
+network: 0.780
+semantic: 0.670
+vnc: 0.619
+debug: 0.518
+boot: 0.459
+PID: 0.435
+permissions: 0.402
+other: 0.266
+files: 0.185
+KVM: 0.062
+
+many aarch64 machines exit with "fatal: Lockup: can't escalate 3 to HardFault"
+Description of problem:
+`-machine netduino2` and `-machine microbit` and many others dump core
+Steps to reproduce:
+```
+qemu-system-aarch64 -machine netduino2
+qemu-system-aarch64 -machine microbit
+...
+$ for x in microbit netduino2 b-l475e-iot01a emcraft-sf2 fby35-bmc lm3s6965evb lm3s811evb musca-a musca-b1 netduinoplus2 olimex-stm32-h405 stm32vldiscovery
+do qemu-system-aarch64 -machine $x
+done
+```
+and all the `mps2-*` machines all result in 
+```
+qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
+
+R00=00000000 R01=00000000 R02=00000000 R03=00000000
+R04=00000000 R05=00000000 R06=00000000 R07=00000000
+R08=00000000 R09=00000000 R10=00000000 R11=00000000
+R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
+XPSR=40000003 -Z-- A handler
+FPSCR: 00000000
+Aborted (core dumped)
+```
diff --git a/results/classifier/zero-shot/108/device/2741 b/results/classifier/zero-shot/108/device/2741
new file mode 100644
index 00000000..e69952e3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2741
@@ -0,0 +1,76 @@
+device: 0.967
+boot: 0.965
+PID: 0.964
+files: 0.950
+debug: 0.946
+graphic: 0.926
+permissions: 0.921
+performance: 0.903
+semantic: 0.867
+other: 0.826
+vnc: 0.815
+network: 0.802
+socket: 0.787
+KVM: 0.575
+
+qemu-system-ppc no longer boots NetBSD/macppc
+Description of problem:
+Since commit 7419dc5b2b5bcc929d91e8920692041a8f6d1977, qemu no longer boots NetBSD/macppc.
+Steps to reproduce:
+```
+wget https://www.gson.org/bugs/qemu/macppc-20241221/boot.iso.gz
+wget https://www.gson.org/bugs/qemu/macppc-20241221/wd0.img.gz
+gunzip boot.iso.gz
+gunzip wd0.img.gz
+qemu-system-ppc \
+    -m 256 \
+    -nographic \
+    -drive file=wd0.img,format=raw,media=disk,snapshot=on \
+    -drive file=boot.iso,format=raw,media=cdrom,readonly=on,index=2 \
+    -prom-env boot-device=cd:,netbsd-GENERIC \
+    -M mac99 \
+    -prom-env qemu_boot_hack=y
+```
+
+At the "root device:" prompt, enter `wd0a`
+
+At the "dump device" prompt, just press enter
+
+At the "file system" prompt, just press enter
+
+At the "init path" prompt, just press enter
+
+Expected behavior: The guest system boots to a login prompt
+
+Observed behavior: qemu exits with the following error message:
+
+```
+qemu: fatal: Raised an exception without defined vector 94
+
+NIP fdb5d440   LR fdb5dc20 CTR fd62a340 XER 20000000 CPU#0
+MSR 0200d032 HID0 809400a4  HF 02004012 iidx 0 didx 0
+TB 00000000 831919972 DECR 105840
+GPR00 0000000000000125 00000000ffffe8b0 00000000fde90008 0000000000000000
+GPR04 0000000000000000 00000000fdcfebac 00000000fdcfeb48 0000000000000001
+GPR08 0000000000000000 00000000fde90008 00000000ffffe8b0 00000000fdb5dc14
+GPR12 0000000044004482 0000000000000000 00000000fdee0efc 00000000fdef57f0
+GPR16 00000000fdef57c8 0000000000000000 00000000ffffea94 00000000ffffeac8
+GPR20 00000000fdee0f3c 0000000001800114 0000000000000000 0000000000000001
+GPR24 0000000000000000 00000000fdef57e0 0000000000000001 00000000fdb5da2c
+GPR28 00000000ffffe9c0 00000000ffffe8f8 00000000fdcffb4c 00000000fdcfeb48
+CR 24004482  [ E  G  -  -  G  G  L  E  ]     RES 004@ffffffff
+FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPSCR 00000000
+ SRR0 fd62a360  SRR1 0200d032    PVR 000c0209 VRSAVE 00000000
+SPRG0 00c02bc0 SPRG1 44004482  SPRG2 fde90008  SPRG3 00000000
+SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
+ SDR1 00e0001f   DAR cd538000  DSISR 42000000
+Aborted
+```
diff --git a/results/classifier/zero-shot/108/device/2752 b/results/classifier/zero-shot/108/device/2752
new file mode 100644
index 00000000..171698b6
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2752
@@ -0,0 +1,292 @@
+device: 0.939
+debug: 0.919
+graphic: 0.917
+other: 0.912
+socket: 0.903
+semantic: 0.903
+permissions: 0.901
+PID: 0.898
+network: 0.889
+performance: 0.888
+boot: 0.883
+files: 0.825
+vnc: 0.772
+KVM: 0.717
+
+Heap use after free in virtio-crypto with vhost-user backend
+Description of problem:
+An heap-use-after-free happens in virtio-crypto device with vhost-user backend created by a dpdk example program.
+Steps to reproduce:
+1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html)
+```
+wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz
+meson setup -Dexamples=all build
+cd build
+ninja
+meson install
+cd examples
+sudo ./dpdk-vhost_crypto --vdev  'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock
+```
+After setting up the backend, should see something like:
+```
+EAL: Detected CPU lcores: 48
+EAL: Detected NUMA nodes: 2
+EAL: Detected static linkage of DPDK
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: Selected IOVA mode 'PA'
+EAL: VFIO support initialized
+CRYPTODEV: Creating cryptodev crypto_aesni_mb0
+CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8
+IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0
+USER1: Processing on Core 7 started
+VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode
+VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213
+VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded
+```
+
+2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto)
+
+3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root.
+
+4.Run the command below to reproduce UAF. Here, Setting ASAN_OPTIONS=max_malloc_fill_size=0 avoids capturing another unintialized read in vhost_user_backend_init, which happens ealier than the UAF. 
+
+I can reproduce it 7 times in 10 runs, seems to be racing.
+```
+cat << EOF | ASAN_OPTIONS=max_malloc_fill_size=0 \
+./qemu-system-x86_64 --enable-kvm -m 512M \
+-object \
+memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \
+-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \
+socket,id=chardev0,path=/tmp/my-crypto.sock -object \
+cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \
+virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \
+stdio
+outl 0xcf8 0x80001800
+inw 0xcfc
+outl 0xcf8 0x80001814
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x80001814
+inl 0xcfc
+outl 0xcf8 0x80001814
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80001820
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x80001820
+inl 0xcfc
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0004000
+outl 0xcf8 0x80001804
+inw 0xcfc
+outl 0xcf8 0x80001804
+outw 0xcfc 0x7
+outl 0xcf8 0x80001804
+inw 0xcfc
+writeq 0xe0004023 0x5f5f5f5f5f5f0d00
+writeq 0xe0004015 0x10b2d007a210fff
+writeq 0xe0004011 0xb2616007a006425
+writeq 0xe0004011 0x5a5546a2d40b6425
+EOF
+```
+Additional information:
+Here is the information reported by ASAN: 
+```
+==2277232==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000000] OPENED
+qemu-system-x86_64: warning: vhost-user backend supports VHOST_USER_PROTOCOL_F_CONFIG but QEMU does not.
+[R +0.119439] outl 0xcf8 0x80001800
+[S +0.119564] OK
+OK
+[R +0.119607] inw 0xcfc
+[S +0.119667] OK 0x1af4
+OK 0x1af4
+[R +0.119721] outl 0xcf8 0x80001814
+[S +0.119770] OK
+OK
+[R +0.119817] outl 0xcfc 0xffffffff
+[S +0.119889] OK
+OK
+[R +0.119929] outl 0xcf8 0x80001814
+[S +0.119977] OK
+OK
+[R +0.120037] inl 0xcfc
+[S +0.120090] OK 0xfffff000
+OK 0xfffff000
+[R +0.120140] outl 0xcf8 0x80001814
+[S +0.120165] OK
+OK
+[R +0.120193] outl 0xcfc 0xe0000000
+[S +0.120242] OK
+OK
+[R +0.120303] outl 0xcf8 0x80001820
+[S +0.120324] OK
+OK
+[R +0.120343] outl 0xcfc 0xffffffff
+[S +0.120390] OK
+OK
+[R +0.120431] outl 0xcf8 0x80001820
+[S +0.120487] OK
+OK
+[R +0.120541] inl 0xcfc
+[S +0.120578] OK 0xffffc00c
+OK 0xffffc00c
+[R +0.120635] outl 0xcf8 0x80001820
+[S +0.120680] OK
+OK
+[R +0.120747] outl 0xcfc 0xe0004000
+[S +0.120815] OK
+OK
+[R +0.120858] outl 0xcf8 0x80001804
+[S +0.120881] OK
+OK
+[R +0.120930] inw 0xcfc
+[S +0.120975] OK 0x0000
+OK 0x0000
+[R +0.121017] outl 0xcf8 0x80001804
+[S +0.121053] OK
+OK
+[R +0.121081] outw 0xcfc 0x7
+[S +0.132297] OK
+OK
+[R +0.132330] outl 0xcf8 0x80001804
+[S +0.132345] OK
+OK
+[R +0.132357] inw 0xcfc
+[S +0.132373] OK 0x0007
+OK 0x0007
+[R +0.132392] writeq 0xe0004023 0x5f5f5f5f5f5f0d00
+[S +0.132409] OK
+OK
+[R +0.132419] writeq 0xe0004015 0x10b2d007a210fff
+[S +0.132447] OK
+OK
+[R +0.132460] writeq 0xe0004011 0xb2616007a006425
+[S +0.132480] OK
+OK
+[R +0.132489] writeq 0xe0004011 0x5a5546a2d40b6425
+qemu-system-x86_64: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on
+qemu-system-x86_64: vhost_set_mem_table failed: Invalid argument (22)
+qemu-system-x86_64: Failed to write msg. Wrote -1 instead of 52.
+qemu-system-x86_64: vhost_set_vring_addr failed: Invalid argument (22)
+=================================================================
+==2277232==ERROR: AddressSanitizer: heap-use-after-free on address 0x618000000b28 at pc 0x5570e3541a1b bp 0x7fff627ef550 sp 0x7fff627ef548
+READ of size 8 at 0x618000000b28 thread T0
+    #0 0x5570e3541a1a in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33
+    #1 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13
+    #2 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9
+    #3 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13
+    #4 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13
+    #5 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5
+    #6 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9
+    #7 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9
+    #8 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5
+    #9 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18
+    #10 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16
+    #11 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18
+    #12 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19
+    #13 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12
+    #14 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18
+    #15 0x5570e375da7c in qtest_process_command /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:532:13
+    #16 0x5570e375856d in qtest_process_inbuf /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:776:9
+    #17 0x5570e3767b6e in qtest_read /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:788:5
+    #18 0x5570e564cafd in qemu_chr_be_write_impl /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:214:9
+    #19 0x5570e564cbb9 in qemu_chr_be_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:226:9
+    #20 0x5570e5658a35 in fd_chr_read /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fd.c:72:9
+    #21 0x5570e500cf6c in qio_channel_fd_source_dispatch /mnt/Hypervisor/qemu/build/master/fuzz/../io/channel-watch.c:84:12
+    #22 0x7f8fc04adf7d in g_main_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:3337:28
+    #23 0x7f8fc04adf7d in g_main_context_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:4055:7
+    #24 0x5570e5a014e9 in glib_pollfds_poll /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:287:9
+    #25 0x5570e59ffe23 in os_host_main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:310:5
+    #26 0x5570e59ff9ec in main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:589:11
+    #27 0x5570e376f217 in qemu_main_loop /mnt/Hypervisor/qemu/build/master/fuzz/../system/runstate.c:835:9
+    #28 0x5570e5679ecc in qemu_default_main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:37:14
+    #29 0x5570e5679f17 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:48:12
+    #30 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #31 0x5570e18f189d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d)
+
+0x618000000b28 is located 680 bytes inside of 800-byte region [0x618000000880,0x618000000ba0)
+freed by thread T0 here:
+    #0 0x5570e196dde2 in __interceptor_free /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:111:3
+    #1 0x5570e37befc1 in cryptodev_vhost_cleanup /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:45:5
+    #2 0x5570e37ce272 in cryptodev_vhost_user_stop /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:86:9
+    #3 0x5570e37cd728 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:171:9
+    #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #6 0x5570e5646076 in tcp_chr_disconnect_locked /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:482:9
+    #7 0x5570e5632534 in tcp_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:131:17
+    #8 0x5570e564c1f5 in qemu_chr_write_buffer /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:122:15
+    #9 0x5570e564b8a2 in qemu_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:186:11
+    #10 0x5570e5615f82 in qemu_chr_fe_write_all /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:52:12
+    #11 0x5570e49ec22c in vhost_user_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:410:11
+    #12 0x5570e4a0e512 in vhost_user_write_sync /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1141:11
+    #13 0x5570e49f84f9 in vhost_user_set_vring_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1384:12
+    #14 0x5570e3543fcb in vhost_virtqueue_set_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:979:9
+    #15 0x5570e3540a0b in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1321:9
+    #16 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13
+    #17 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9
+    #18 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13
+    #19 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13
+    #20 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5
+    #21 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9
+    #22 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9
+    #23 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5
+    #24 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18
+    #25 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16
+    #26 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18
+    #27 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19
+    #28 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12
+    #29 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18
+
+previously allocated by thread T0 here:
+    #0 0x5570e196e04d in malloc /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
+    #1 0x7f8fc04b3dc8 in g_malloc /home/lmy/glib-2.68.0/_build/../glib/gmem.c:106:13
+    #2 0x5570e37cdca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30
+    #3 0x5570e37cd599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13
+    #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #6 0x5570e5618d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13
+    #7 0x5570e5618674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5
+    #8 0x5570e37cb960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5
+    #9 0x5570e37a4e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9
+    #10 0x5570e4eb0c40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9
+    #11 0x5570e4eb16a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10
+    #12 0x5570e4eb1c74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11
+    #13 0x5570e378882b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13
+    #14 0x5570e378553c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5
+    #15 0x5570e3779efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5
+    #16 0x5570e5679f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5
+    #17 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+
+SUMMARY: AddressSanitizer: heap-use-after-free /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33 in vhost_virtqueue_start
+Shadow bytes around the buggy address:
+  0x0c307fff8110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8130: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+=>0x0c307fff8160: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8170: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c307fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c307fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c307fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c307fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+==2277232==ABORTING
+```
diff --git a/results/classifier/zero-shot/108/device/2801 b/results/classifier/zero-shot/108/device/2801
new file mode 100644
index 00000000..12a2c900
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2801
@@ -0,0 +1,16 @@
+device: 0.987
+performance: 0.915
+boot: 0.824
+network: 0.744
+debug: 0.697
+PID: 0.655
+files: 0.654
+graphic: 0.545
+permissions: 0.466
+other: 0.446
+socket: 0.420
+vnc: 0.289
+semantic: 0.220
+KVM: 0.012
+
+Implement Raspberry PI Zero 2 W.
diff --git a/results/classifier/zero-shot/108/device/2803 b/results/classifier/zero-shot/108/device/2803
new file mode 100644
index 00000000..420da6ae
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2803
@@ -0,0 +1,123 @@
+device: 0.962
+graphic: 0.960
+debug: 0.958
+permissions: 0.955
+other: 0.953
+performance: 0.940
+PID: 0.929
+semantic: 0.918
+socket: 0.914
+boot: 0.897
+KVM: 0.882
+network: 0.871
+vnc: 0.864
+files: 0.856
+
+Assert failure in virtio-net device in address_space_lduw_le_cached
+Description of problem:
+Issue was found by fuzzing. Assert 
+
+```
+qemu/include/exec/memory_ldst_cached.h.inc:30: uint16_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.
+```
+can be triggered with some qtest commands. This is pretty similar to [issue_302](https://gitlab.com/qemu-project/qemu/-/issues/302) and [issue_781](https://gitlab.com/qemu-project/qemu/-/issues/781), but kinda different. In [issue_781](https://gitlab.com/qemu-project/qemu/-/issues/781) there is a comment, that issue was `Possibly fixed by commit 10d35e58 ("virtio-pci: fix queue_enable write").`, but unfortunately it is not - we can still trigger this assert with other set of command-line arguments and qtest commands.
+Steps to reproduce:
+Command:
+
+```
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M q35 -nodefaults -device virtio-net,netdev=net0,packed=on -netdev user,id=net0 -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xc000
+outl 0xcf8 0x80000820
+outl 0xcfc 0xe0004000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x7
+write 0xe0004008 0x1 0x01
+write 0xe000400c 0x1 0x04
+outl 0xc00b 0x01000000
+outl 0xc006 0x38380000
+outl 0xc001 0x00
+outl 0xc00f 0x04000100
+write 0x3839003 0x1 0x01
+EOF
+```
+
+Results in 
+
+```
+[I 0.000000] OPENED
+[R +0.028638] outl 0xcf8 0x80000810
+[S +0.028692] OK
+OK
+[R +0.028705] outl 0xcfc 0xc000
+[S +0.028729] OK
+OK
+[R +0.028738] outl 0xcf8 0x80000820
+[S +0.028748] OK
+OK
+[R +0.028763] outl 0xcfc 0xe0004000
+[S +0.028784] OK
+OK
+[R +0.028800] outl 0xcf8 0x80000804
+[S +0.029483] OK
+OK
+[R +0.029509] outw 0xcfc 0x7
+[S +0.029820] OK
+OK
+[R +0.029833] write 0xe0004008 0x1 0x01
+[S +0.029846] OK
+OK
+[R +0.029853] write 0xe000400c 0x1 0x04
+[S +0.029882] OK
+OK
+[R +0.029894] outl 0xc00b 0x01000000
+[S +0.029909] OK
+OK
+[R +0.029923] outl 0xc006 0x38380000
+[S +0.029938] OK
+OK
+[R +0.029944] outl 0xc001 0x00
+[S +0.029953] OK
+OK
+[R +0.029959] outl 0xc00f 0x04000100
+[S +0.030073] OK
+OK
+[R +0.030091] write 0x3839003 0x1 0x01
+[S +0.030106] OK
+OK
+qemu-system-x86_64: /home/artemiin/Work/original_qemu/include/exec/memory_ldst_cached.h.inc:30: uint16_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.
+```
+Additional information:
+There is a stack trace from libFuzzer output:
+
+```
+#0 0x5555561bcfc1 in __sanitizer_print_stack_trace (qemu/build/qemu-fuzz-x86_64+0xc68fc1) (BuildId: 97b846e788f9dda2a285e5ea004d922c4886a315)
+<some_asert_calls>
+#6 0x7ffff48d4471 in abort stdlib/abort.c:79:7
+#7 0x7ffff48d4394 in __assert_fail_base assert/assert.c:92:3
+#8 0x7ffff48e2eb1 in __assert_fail assert/assert.c:101:3
+#9 0x555557043c41 in address_space_lduw_le_cached qemu/include/exec/memory_ldst_cached.h.inc:30:5
+#10 0x555557043c41 in lduw_le_phys_cached qemu/include/exec/memory_ldst_phys.h.inc:67:12
+#11 0x555557043c41 in virtio_lduw_phys_cached qemu/include/hw/virtio/virtio-access.h:166:12
+#12 0x555557030a78 in vring_avail_ring qemu/build/../hw/virtio/virtio.c:389:12
+#13 0x555557030a78 in virtqueue_get_head qemu/build/../hw/virtio/virtio.c:1043:13
+#14 0x555557030a78 in virtqueue_split_pop qemu/build/../hw/virtio/virtio.c:1540:10
+#15 0x555557030a78 in virtqueue_pop qemu/build/../hw/virtio/virtio.c:1790:16
+#16 0x555556f9aaf9 in virtio_net_flush_tx qemu/build/../hw/net/virtio-net.c:2746:16
+#17 0x555556f9a4dc in virtio_net_tx_bh qemu/build/../hw/net/virtio-net.c:2953:11
+#18 0x5555577152e2 in aio_bh_call qemu/build/../util/async.c:171:5
+#19 0x555557715830 in aio_bh_poll qemu/build/../util/async.c:218:13
+#20 0x5555576ce2d7 in aio_dispatch qemu/build/../util/aio-posix.c:423:5
+#21 0x555557717918 in aio_ctx_dispatch qemu/build/../util/async.c:360:5
+#22 0x7ffff69837a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)
+#23 0x5555577187cd in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9
+#24 0x5555577187cd in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5
+#25 0x5555577187cd in main_loop_wait qemu/build/../util/main-loop.c:589:11
+#26 0x5555571ce309 in flush_events qemu/build/../tests/qtest/fuzz/fuzz.c:50:9
+#27 0x5555571d662b in generic_fuzz qemu/build/../tests/qtest/fuzz/generic_fuzz.c:669:13
+#28 0x5555571ce7de in LLVMFuzzerTestOneInput qemu/build/../tests/qtest/fuzz/fuzz.c:158:5
+<fuzzer_init_calls>
+#35 0x5555560e2510 in _start (qemu/build/qemu-fuzz-x86_64+0xb8e510) (BuildId: 97b846e788f9dda2a285e5ea004d922c4886a315
+```
+
+FYI @mstredhat
diff --git a/results/classifier/zero-shot/108/device/2805 b/results/classifier/zero-shot/108/device/2805
new file mode 100644
index 00000000..28788370
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2805
@@ -0,0 +1,37 @@
+device: 0.940
+socket: 0.913
+files: 0.868
+performance: 0.823
+graphic: 0.768
+semantic: 0.766
+network: 0.764
+debug: 0.717
+boot: 0.715
+vnc: 0.658
+PID: 0.650
+permissions: 0.595
+other: 0.402
+KVM: 0.190
+
+vhost-device-snd does not report correctly the device conf size
+Description of problem:
+The vhost-user-snd frontend is incorrectly reporting the size of the device configuration space, which should be based on the features exposed by the device. For example, the `controls` field in the `virtio_snd_config` structure is optional and should only be included in the configuration size if the `VIRTIO_SND_F_CTLS` feature has been negotiated.  
+
+This issue became apparent after commit `ab0c7fb2`, where `virtio_snd_config` was updated to include the `controls` field. The vhost-user-snd frontend, relying on this structure, started expecting `sizeof(virtio_snd_config)` when communicating with the backend, regardless of whether the `VIRTIO_SND_F_CTLS` feature was negotiated. As a result, any backend reporting a smaller configuration size—for example, one that does not support controls—cannot communicate with the frontend. We observed this problem in the vhost-device-sound rust-vmm device, which we partially fixed [here](https://github.com/rust-vmm/vhost-device/commit/8e7b7109316e1027548bc91cfcbb4b096b032c24).  
+
+This behavior is incorrect because the configuration size should depend on the negotiated features.
+
+I am currently working on patch to fix this.
+Steps to reproduce:
+1. Run vhost-device-sound
+```bash
+ cargo run --bin vhost-device-sound -- --socket=/tmp/vhost-sound.socket --backend=pipewire
+```
+2. Run QEMU with the parameters above
+3. In the guest run:
+```bash
+root@syzkaller:~# aplay /usr/share/sounds/alsa/Front_Left.wav 
+aplay: main:830: audio open error: No such file or directory
+```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/2812 b/results/classifier/zero-shot/108/device/2812
new file mode 100644
index 00000000..50fafdcf
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2812
@@ -0,0 +1,16 @@
+device: 0.920
+boot: 0.762
+performance: 0.618
+graphic: 0.589
+other: 0.506
+debug: 0.411
+PID: 0.360
+vnc: 0.325
+KVM: 0.206
+permissions: 0.117
+semantic: 0.084
+files: 0.045
+network: 0.014
+socket: 0.011
+
+Crash initializing audio device
diff --git a/results/classifier/zero-shot/108/device/283 b/results/classifier/zero-shot/108/device/283
new file mode 100644
index 00000000..5009ffd7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/283
@@ -0,0 +1,16 @@
+device: 0.921
+graphic: 0.535
+semantic: 0.383
+boot: 0.369
+performance: 0.255
+debug: 0.209
+vnc: 0.092
+permissions: 0.085
+other: 0.081
+socket: 0.063
+PID: 0.058
+network: 0.037
+files: 0.011
+KVM: 0.007
+
+TCG memory leak with FreeDOS 'edit'
diff --git a/results/classifier/zero-shot/108/device/2831 b/results/classifier/zero-shot/108/device/2831
new file mode 100644
index 00000000..ff4133f3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2831
@@ -0,0 +1,35 @@
+device: 0.931
+graphic: 0.884
+PID: 0.770
+debug: 0.740
+performance: 0.725
+vnc: 0.704
+other: 0.703
+permissions: 0.632
+network: 0.592
+socket: 0.587
+files: 0.563
+semantic: 0.554
+boot: 0.395
+KVM: 0.110
+
+unable to build on Sequoia 15.3
+Description of problem:
+
+Steps to reproduce:
+1. git clone https://gitlab.com/qemu-project/qemu.git
+2. ../configure --target-list=riscv32-softmmu --enable-debug
+3. make
+
+Error:
+ld: multiple errors: archive member '/' not a mach-o file in '../qemu/build/subprojects/dtc/libfdt/libfdt.a'; archive member '/' not a mach-o file in '../qemu/build/libqemuutil.a'
+Additional information:
+I tried the more detailed "build for macos" instructions 
+./configure --cc=clang-7 --cxx=clang++-7 --host-cc=clang-7 \
+--extra-cflags=-mavx2 \
+--extra-cxxflags="-I/usr/local/opt/llvm/include" \
+--extra-ldflags="-L/usr/local/opt/llvm/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib" \
+--target-list="<list of machines here>"
+
+but this didn't work for any version of clang I tried, giving me the error in all cases:
+ERROR: C compiler "clang-xxx" either does not exist or does not work.
diff --git a/results/classifier/zero-shot/108/device/2841 b/results/classifier/zero-shot/108/device/2841
new file mode 100644
index 00000000..fc46c4c3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2841
@@ -0,0 +1,26 @@
+device: 0.922
+graphic: 0.910
+performance: 0.880
+vnc: 0.640
+semantic: 0.622
+boot: 0.576
+socket: 0.495
+debug: 0.375
+PID: 0.366
+network: 0.304
+other: 0.208
+files: 0.160
+permissions: 0.048
+KVM: 0.003
+
+QEMU is increasing memory swap, the only solution is to reboot after a freeze.
+Description of problem:
+Swap starts increasing suddenly and gets to around  60GB before laptop freezes and “dies”.
+Steps to reproduce:
+Seemingly random, didn’t notice any pattern.. it just started happening more often.
+
+![image__2_](/uploads/70d007253835b2dafe17352f8facf0f8/image__2_.png)
+
+![image__4_](/uploads/0cde47d15ec6f988a0aa46dd4af3f799/im
+
+![image__3_](/uploads/f88a567693807d046e048ac6b3deab5a/image__3_.png)age__4_.png)
diff --git a/results/classifier/zero-shot/108/device/2858 b/results/classifier/zero-shot/108/device/2858
new file mode 100644
index 00000000..2ef7b6bf
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2858
@@ -0,0 +1,16 @@
+device: 0.925
+debug: 0.691
+performance: 0.645
+graphic: 0.306
+permissions: 0.268
+semantic: 0.249
+boot: 0.188
+network: 0.184
+vnc: 0.097
+other: 0.081
+socket: 0.075
+files: 0.038
+PID: 0.012
+KVM: 0.001
+
+QEMU Command Not Working
diff --git a/results/classifier/zero-shot/108/device/2859 b/results/classifier/zero-shot/108/device/2859
new file mode 100644
index 00000000..2ef7b6bf
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2859
@@ -0,0 +1,16 @@
+device: 0.925
+debug: 0.691
+performance: 0.645
+graphic: 0.306
+permissions: 0.268
+semantic: 0.249
+boot: 0.188
+network: 0.184
+vnc: 0.097
+other: 0.081
+socket: 0.075
+files: 0.038
+PID: 0.012
+KVM: 0.001
+
+QEMU Command Not Working
diff --git a/results/classifier/zero-shot/108/device/2885 b/results/classifier/zero-shot/108/device/2885
new file mode 100644
index 00000000..3b335a43
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2885
@@ -0,0 +1,16 @@
+device: 0.948
+performance: 0.906
+other: 0.644
+debug: 0.623
+graphic: 0.568
+semantic: 0.557
+boot: 0.387
+vnc: 0.314
+network: 0.151
+permissions: 0.091
+PID: 0.066
+socket: 0.041
+files: 0.018
+KVM: 0.006
+
+Unable to increase CPU's for existing RISCV VM
diff --git a/results/classifier/zero-shot/108/device/2893 b/results/classifier/zero-shot/108/device/2893
new file mode 100644
index 00000000..f1ef450c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2893
@@ -0,0 +1,27 @@
+device: 0.945
+graphic: 0.927
+boot: 0.783
+performance: 0.694
+semantic: 0.676
+vnc: 0.673
+socket: 0.616
+debug: 0.573
+PID: 0.553
+other: 0.510
+network: 0.459
+permissions: 0.331
+files: 0.276
+KVM: 0.089
+
+with m4 mac mini windows 11 arm 64 iso not booting for installation
+Description of problem:
+Trying to run win11 arm 64 version in m4 mac mini and the ios failed to boot 
+
+i went to the efi shell and tried to boot from there and it just hangs no problem reported 
+
+when i attach the serial to stdio i get the error convertprogress failed to find range errors
+Steps to reproduce:
+1. In m4 mac mini download win11 arm 64 iso from microsoft site
+2. run the above mentioned command and you will see that it does not boot
+
+/label ~"kind::Bug"
diff --git a/results/classifier/zero-shot/108/device/2905 b/results/classifier/zero-shot/108/device/2905
new file mode 100644
index 00000000..9a998b67
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2905
@@ -0,0 +1,39 @@
+device: 0.941
+graphic: 0.933
+debug: 0.914
+socket: 0.898
+performance: 0.862
+vnc: 0.820
+network: 0.735
+semantic: 0.725
+files: 0.720
+permissions: 0.619
+PID: 0.581
+other: 0.494
+boot: 0.379
+KVM: 0.082
+
+Windows Curses Display Infinite Loop
+Description of problem:
+The out-of-the-box `qemu-system-x86_64 -display curses` on Windows loops forever while displaying "VGA Blank Mode" instead of booting like `qemu-system-x86_64` does.
+
+This is caused by an infinite loop in the below simplified code in `curses_refresh` in `ui/curses.c`:
+```
+    int chr;
+    // ...trimmed
+    while (1) {
+        /* while there are any pending key strokes to process */
+        chr = console_getch(&maybe_keycode);
+
+        if (chr == -1) 
+            break;
+    // ...trimmed
+    }
+```
+`console_getch` has return type `wint_t`. However, on Windows, `wint_t` is `unsigned short`. Therefore when `console_getch` returns -1, the -1 value of `unsigned short` will be silently converted into the `int` value 65535. This causes `65535 == -1` to always be false, and the loop will never break. I can send a patch to qemu-devel which retypes `chr` to `wint_t` and replaces occurences of -1 with `WEOF` (an alias for `(wint_t) -1`).
+Steps to reproduce:
+1. Install `qemu-w64-setup-20250326.exe` Windows qemu from https://qemu.weilnetz.de/w64/2025/
+2. Run `./qemu-system-x86_64 -display curses`
+3. "VGA Blank Mode" will appear on the screen forever
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/2913 b/results/classifier/zero-shot/108/device/2913
new file mode 100644
index 00000000..f15a1481
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2913
@@ -0,0 +1,16 @@
+device: 0.921
+performance: 0.824
+graphic: 0.768
+files: 0.591
+permissions: 0.464
+network: 0.462
+debug: 0.425
+other: 0.380
+semantic: 0.353
+boot: 0.333
+PID: 0.315
+socket: 0.205
+vnc: 0.168
+KVM: 0.033
+
+vmapple machine unusable with macOS 15.4
diff --git a/results/classifier/zero-shot/108/device/2923 b/results/classifier/zero-shot/108/device/2923
new file mode 100644
index 00000000..38ce5e31
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2923
@@ -0,0 +1,28 @@
+device: 0.933
+graphic: 0.920
+performance: 0.751
+network: 0.687
+PID: 0.645
+files: 0.596
+other: 0.532
+socket: 0.525
+permissions: 0.515
+semantic: 0.512
+debug: 0.494
+boot: 0.380
+vnc: 0.325
+KVM: 0.232
+
+Audio crackling issue when USB headset is pass thru via usb-host,hostbus=bus,hostaddr=addr
+Description of problem:
+When we pass thru USB headset via usb port pass-thru, and if the headset supports only 44100 Hz sampling rate, we hear the crackling sound.
+
+The headsets which support 48000Hz works fine.
+Steps to reproduce:
+1. Pass the usb device using hostbus,port.
+2. Connect a usb headset like Logitech H340 which supports only 44100Hz sampling rate.
+3. Play any audio file or youtube video, there is constant crackling sound.
+
+This issue is observed irrespective of the guest OS. Both ubuntu and windows guest, exhibit similar problem.
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/2929 b/results/classifier/zero-shot/108/device/2929
new file mode 100644
index 00000000..6faeafac
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2929
@@ -0,0 +1,22 @@
+device: 0.936
+other: 0.770
+network: 0.658
+graphic: 0.598
+socket: 0.533
+files: 0.513
+performance: 0.478
+semantic: 0.434
+vnc: 0.389
+permissions: 0.357
+boot: 0.353
+PID: 0.308
+debug: 0.295
+KVM: 0.086
+
+Ask to extend vhost-user protocol to carry implementation defined error contexts
+Additional information:
+I am working on the Google [crosvm](https://chromium.googlesource.com/crosvm/crosvm/) project, which implements some `vhost-user` clients/servers defined by [this QEMU doc](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html). I am wondering if we could add a protocol feature/protocol header flag bit to allow the payload of the reply to carry detailed implementation defined error contexts?
+
+Specifically, I am working on the `vhost-user-gpu` device, which needs to send some memory mapping request to the frontend(the main process where VCPU lives), so that we can map some GPU memory to the guest. We are trying to diagnose a bug where the frontend can sometimes fail to perform the operation. However, we don't have access to the logs on the main process, so we are left with only very limited information on the `vhost-user-gpu` process. It could be helpful if we could send detailed implementation defined error contexts in the payload of the reply.
+
+I am wondering in order for the upstream QEMU to accept such "spec" change to the `vhost-user` protocol, what the process should be like? Thanks.
diff --git a/results/classifier/zero-shot/108/device/2939 b/results/classifier/zero-shot/108/device/2939
new file mode 100644
index 00000000..f84e3e16
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2939
@@ -0,0 +1,16 @@
+device: 0.928
+semantic: 0.734
+performance: 0.733
+graphic: 0.729
+debug: 0.204
+permissions: 0.160
+other: 0.029
+boot: 0.027
+network: 0.022
+files: 0.022
+PID: 0.008
+socket: 0.008
+vnc: 0.005
+KVM: 0.004
+
+Add m68k board name called Macintosh llci
diff --git a/results/classifier/zero-shot/108/device/2940 b/results/classifier/zero-shot/108/device/2940
new file mode 100644
index 00000000..1faa2ca3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2940
@@ -0,0 +1,16 @@
+device: 0.936
+performance: 0.856
+graphic: 0.544
+boot: 0.533
+debug: 0.463
+network: 0.420
+permissions: 0.241
+semantic: 0.231
+other: 0.203
+PID: 0.156
+files: 0.137
+socket: 0.073
+vnc: 0.056
+KVM: 0.011
+
+Fix i cant boot nextstep os in qemu m68k using next-cube
diff --git a/results/classifier/zero-shot/108/device/296 b/results/classifier/zero-shot/108/device/296
new file mode 100644
index 00000000..24619873
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/296
@@ -0,0 +1,16 @@
+device: 0.922
+other: 0.597
+graphic: 0.586
+performance: 0.498
+semantic: 0.366
+boot: 0.210
+PID: 0.174
+vnc: 0.126
+debug: 0.113
+permissions: 0.108
+network: 0.076
+socket: 0.065
+files: 0.049
+KVM: 0.026
+
+Enabling OpenGL for GUI doesn't work on old laptop
diff --git a/results/classifier/zero-shot/108/device/2968 b/results/classifier/zero-shot/108/device/2968
new file mode 100644
index 00000000..815d0bd5
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/2968
@@ -0,0 +1,37 @@
+device: 0.956
+graphic: 0.943
+socket: 0.819
+PID: 0.819
+debug: 0.762
+permissions: 0.724
+semantic: 0.724
+performance: 0.721
+other: 0.709
+files: 0.697
+vnc: 0.655
+boot: 0.534
+network: 0.474
+KVM: 0.294
+
+Regression: x-igd-opregion=off ignored in VFIO IGD quirk handling
+Description of problem:
+A regression in QEMU’s VFIO IGD initialization causes the `x-igd-opregion=off` parameter to be ignored, resulting in an error when passing through an Intel iGPU SR-IOV Virtual Function (VF) at PCI address `00:02.1`: `qemu-system-x86_64: -device vfio-pci,host=0000:00:02.1,...: Device does not supports IGD OpRegion feature: No such device`
+Automatic detection of IGD-OpRegion assumes any Intel iGPU (including GVT-g) will have it but SR-IOV VFs do not.
+Steps to reproduce:
+1. Configure an Intel iGPU with SR-IOV enabled, creating a VF at `00:02.1`.
+2. Bind the VF to the `vfio-pci` driver:
+```
+    echo 0000:00:02.1 > /sys/bus/pci/drivers/i915/unbind
+    either:
+      echo "8086 4680" > /sys/bus/pci/drivers/vfio-pci/new_id
+    or:
+      echo 0000:00:02.1 > /sys/bus/pci/drivers/vfio-pci/bind
+```
+3. Run QEMU with the command line above, including `-device vfio-pci,host=0000:00:02.1,...,x-igd-opregion=off`.
+Additional information:
+- **Hardware details**:
+  - `00:02.1 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)`
+  - Host motherboard: MSI PRO Z690-A DDR4
+  - CPU: Intel Core i5 12600K
+- **Regression cause**: The issue was introduced by commit 7be29f2f1a3f5b037d27eedbd5df9f441e8c8c16, which changed `vfio_pci_igd_config_quirk` to detect OpRegion automatically, ignoring `vdev->igd_opregion=false`.
+- **Proposed fix**: I have a patch that adds checks for `vdev->igd_opregion` in `vfio_pci_igd_config_quirk` and `vfio_pci_kvmgt_config_quirk`, skipping OpRegion handling when `x-igd-opregion=off`. The patch has been tested, confirming the VM starts without errors. I will submit it to qemu-devel@nongnu.org with a reference to this issue.
diff --git a/results/classifier/zero-shot/108/device/318 b/results/classifier/zero-shot/108/device/318
new file mode 100644
index 00000000..908ddbee
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/318
@@ -0,0 +1,16 @@
+device: 0.937
+graphic: 0.736
+debug: 0.716
+performance: 0.659
+boot: 0.173
+semantic: 0.076
+permissions: 0.076
+vnc: 0.042
+PID: 0.025
+network: 0.024
+other: 0.010
+files: 0.005
+socket: 0.004
+KVM: 0.002
+
+QEMU crash after a QuickBASIC program integer overflow
diff --git a/results/classifier/zero-shot/108/device/319 b/results/classifier/zero-shot/108/device/319
new file mode 100644
index 00000000..bdc98a39
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/319
@@ -0,0 +1,16 @@
+device: 0.955
+network: 0.627
+performance: 0.615
+graphic: 0.569
+boot: 0.471
+other: 0.439
+permissions: 0.392
+debug: 0.356
+socket: 0.331
+semantic: 0.256
+PID: 0.252
+files: 0.210
+vnc: 0.067
+KVM: 0.010
+
+Openjdk11+ fails to install on s390x
diff --git a/results/classifier/zero-shot/108/device/325 b/results/classifier/zero-shot/108/device/325
new file mode 100644
index 00000000..a7d06b0f
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/325
@@ -0,0 +1,16 @@
+device: 0.949
+performance: 0.889
+graphic: 0.643
+network: 0.560
+debug: 0.299
+other: 0.277
+boot: 0.186
+files: 0.091
+vnc: 0.087
+permissions: 0.082
+semantic: 0.077
+socket: 0.069
+PID: 0.046
+KVM: 0.001
+
+Latest QEMU crashes when switching color depth of ReactOS
diff --git a/results/classifier/zero-shot/108/device/331 b/results/classifier/zero-shot/108/device/331
new file mode 100644
index 00000000..278bf8b9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/331
@@ -0,0 +1,16 @@
+device: 0.955
+network: 0.894
+debug: 0.601
+graphic: 0.466
+performance: 0.420
+semantic: 0.229
+other: 0.189
+permissions: 0.178
+boot: 0.100
+PID: 0.073
+vnc: 0.070
+socket: 0.042
+files: 0.026
+KVM: 0.014
+
+Incorrect feature negotiation for vhost-vdpa netdevice
diff --git a/results/classifier/zero-shot/108/device/346 b/results/classifier/zero-shot/108/device/346
new file mode 100644
index 00000000..aaa9ccf2
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/346
@@ -0,0 +1,16 @@
+device: 0.938
+performance: 0.788
+other: 0.605
+graphic: 0.548
+network: 0.499
+permissions: 0.472
+semantic: 0.333
+boot: 0.301
+debug: 0.293
+files: 0.153
+socket: 0.135
+vnc: 0.092
+PID: 0.086
+KVM: 0.024
+
+Guest refuses to accept keyboard input when accelerated with WHPX
diff --git a/results/classifier/zero-shot/108/device/405 b/results/classifier/zero-shot/108/device/405
new file mode 100644
index 00000000..e8f818b3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/405
@@ -0,0 +1,16 @@
+device: 0.935
+performance: 0.758
+network: 0.524
+graphic: 0.507
+debug: 0.453
+boot: 0.173
+semantic: 0.128
+vnc: 0.048
+other: 0.044
+KVM: 0.031
+PID: 0.022
+socket: 0.021
+permissions: 0.009
+files: 0.009
+
+Assertion failure in e1000e_intrmgr_on_throttling_timer
diff --git a/results/classifier/zero-shot/108/device/406 b/results/classifier/zero-shot/108/device/406
new file mode 100644
index 00000000..04a4342d
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/406
@@ -0,0 +1,16 @@
+device: 0.986
+permissions: 0.968
+network: 0.968
+PID: 0.610
+performance: 0.583
+semantic: 0.469
+KVM: 0.437
+vnc: 0.415
+graphic: 0.407
+debug: 0.382
+socket: 0.326
+other: 0.313
+boot: 0.306
+files: 0.211
+
+vhost-user net device sends SET_VRING_ENABLE before feature negotiation
diff --git a/results/classifier/zero-shot/108/device/422 b/results/classifier/zero-shot/108/device/422
new file mode 100644
index 00000000..50263867
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/422
@@ -0,0 +1,16 @@
+device: 0.927
+performance: 0.748
+network: 0.579
+debug: 0.494
+graphic: 0.331
+boot: 0.313
+semantic: 0.274
+permissions: 0.269
+vnc: 0.201
+socket: 0.175
+other: 0.141
+files: 0.110
+PID: 0.034
+KVM: 0.009
+
+Unable to execute MIPS MSA code due to illegal instruction
diff --git a/results/classifier/zero-shot/108/device/42226390 b/results/classifier/zero-shot/108/device/42226390
new file mode 100644
index 00000000..b9c7459c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/42226390
@@ -0,0 +1,197 @@
+device: 0.951
+boot: 0.943
+debug: 0.942
+graphic: 0.942
+permissions: 0.936
+performance: 0.927
+semantic: 0.924
+PID: 0.914
+KVM: 0.905
+network: 0.894
+other: 0.894
+socket: 0.882
+files: 0.878
+vnc: 0.853
+
+[BUG] AArch64 boot hang with -icount and -smp >1 (iothread locking issue?)
+
+Hello,
+
+I am encountering one or more bugs when using -icount and -smp >1 that I am
+attempting to sort out. My current theory is that it is an iothread locking
+issue.
+
+I am using a command-line like the following where $kernel is a recent upstream
+AArch64 Linux kernel Image (I can provide a binary if that would be helpful -
+let me know how is best to post):
+
+        qemu-system-aarch64 \
+                -M virt -cpu cortex-a57 -m 1G \
+                -nographic \
+                -smp 2 \
+                -icount 0 \
+                -kernel $kernel
+
+For any/all of the symptoms described below, they seem to disappear when I
+either remove `-icount 0` or change smp to `-smp 1`. In other words, it is the
+combination of `-smp >1` and `-icount` which triggers what I'm seeing.
+
+I am seeing two different (but seemingly related) behaviors. The first (and
+what I originally started debugging) shows up as a boot hang. When booting
+using the above command after Peter's "icount: Take iothread lock when running
+QEMU timers" patch [1], The kernel boots for a while and then hangs after:
+
+>
+...snip...
+>
+[    0.010764] Serial: AMBA PL011 UART driver
+>
+[    0.016334] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 13, base_baud
+>
+= 0) is a PL011 rev1
+>
+[    0.016907] printk: console [ttyAMA0] enabled
+>
+[    0.017624] KASLR enabled
+>
+[    0.031986] HugeTLB: registered 16.0 GiB page size, pre-allocated 0 pages
+>
+[    0.031986] HugeTLB: 16320 KiB vmemmap can be freed for a 16.0 GiB page
+>
+[    0.031986] HugeTLB: registered 512 MiB page size, pre-allocated 0 pages
+>
+[    0.031986] HugeTLB: 448 KiB vmemmap can be freed for a 512 MiB page
+>
+[    0.031986] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
+>
+[    0.031986] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
+When it hangs here, I drop into QEMU's console, attach to the gdbserver, and it
+always reports that it is at address 0xffff800008dc42e8 (as shown below from an
+objdump of the vmlinux). I note this is in the middle of messing with timer
+system registers - which makes me suspect we're attempting to take the iothread
+lock when its already held:
+
+>
+ffff800008dc42b8 <arch_timer_set_next_event_virt>:
+>
+ffff800008dc42b8:       d503201f        nop
+>
+ffff800008dc42bc:       d503201f        nop
+>
+ffff800008dc42c0:       d503233f        paciasp
+>
+ffff800008dc42c4:       d53be321        mrs     x1, cntv_ctl_el0
+>
+ffff800008dc42c8:       32000021        orr     w1, w1, #0x1
+>
+ffff800008dc42cc:       d5033fdf        isb
+>
+ffff800008dc42d0:       d53be042        mrs     x2, cntvct_el0
+>
+ffff800008dc42d4:       ca020043        eor     x3, x2, x2
+>
+ffff800008dc42d8:       8b2363e3        add     x3, sp, x3
+>
+ffff800008dc42dc:       f940007f        ldr     xzr, [x3]
+>
+ffff800008dc42e0:       8b020000        add     x0, x0, x2
+>
+ffff800008dc42e4:       d51be340        msr     cntv_cval_el0, x0
+>
+* ffff800008dc42e8:       927ef820        and     x0, x1, #0xfffffffffffffffd
+>
+ffff800008dc42ec:       d51be320        msr     cntv_ctl_el0, x0
+>
+ffff800008dc42f0:       d5033fdf        isb
+>
+ffff800008dc42f4:       52800000        mov     w0, #0x0
+>
+// #0
+>
+ffff800008dc42f8:       d50323bf        autiasp
+>
+ffff800008dc42fc:       d65f03c0        ret
+The second behavior is that prior to Peter's "icount: Take iothread lock when
+running QEMU timers" patch [1], I observe the following message (same command
+as above):
+
+>
+ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed:
+>
+(qemu_mutex_iothread_locked())
+>
+Aborted (core dumped)
+This is the same behavior described in Gitlab issue 1130 [0] and addressed by
+[1]. I bisected the appearance of this assertion, and found it was introduced
+by Pavel's "replay: rewrite async event handling" commit [2]. Commits prior to
+that one boot successfully (neither assertions nor hangs) with `-icount 0 -smp
+2`.
+
+I've looked over these two commits ([1], [2]), but it is not obvious to me
+how/why they might be interacting to produce the boot hangs I'm seeing and
+I welcome any help investigating further.
+
+Thanks!
+
+-Aaron Lindsay
+
+[0] -
+https://gitlab.com/qemu-project/qemu/-/issues/1130
+[1] -
+https://gitlab.com/qemu-project/qemu/-/commit/c7f26ded6d5065e4116f630f6a490b55f6c5f58e
+[2] -
+https://gitlab.com/qemu-project/qemu/-/commit/60618e2d77691e44bb78e23b2b0cf07b5c405e56
+
+On Fri, 21 Oct 2022 at 16:48, Aaron Lindsay
+<aaron@os.amperecomputing.com> wrote:
+>
+>
+Hello,
+>
+>
+I am encountering one or more bugs when using -icount and -smp >1 that I am
+>
+attempting to sort out. My current theory is that it is an iothread locking
+>
+issue.
+Weird coincidence, that is a bug that's been in the tree for months
+but was only reported to me earlier this week. Try reverting
+commit a82fd5a4ec24d923ff1e -- that should fix it.
+CAFEAcA_i8x00hD-4XX18ySLNbCB6ds1-DSazVb4yDnF8skjd9A@mail.gmail.com
+/">https://lore.kernel.org/qemu-devel/
+CAFEAcA_i8x00hD-4XX18ySLNbCB6ds1-DSazVb4yDnF8skjd9A@mail.gmail.com
+/
+has the explanation.
+
+thanks
+-- PMM
+
+On Oct 21 17:00, Peter Maydell wrote:
+>
+On Fri, 21 Oct 2022 at 16:48, Aaron Lindsay
+>
+<aaron@os.amperecomputing.com> wrote:
+>
+>
+>
+> Hello,
+>
+>
+>
+> I am encountering one or more bugs when using -icount and -smp >1 that I am
+>
+> attempting to sort out. My current theory is that it is an iothread locking
+>
+> issue.
+>
+>
+Weird coincidence, that is a bug that's been in the tree for months
+>
+but was only reported to me earlier this week. Try reverting
+>
+commit a82fd5a4ec24d923ff1e -- that should fix it.
+I can confirm that reverting a82fd5a4ec24d923ff1e fixes it for me.
+Thanks for the help and fast response!
+
+-Aaron
+
diff --git a/results/classifier/zero-shot/108/device/431 b/results/classifier/zero-shot/108/device/431
new file mode 100644
index 00000000..f427c2e7
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/431
@@ -0,0 +1,16 @@
+device: 0.920
+debug: 0.659
+performance: 0.631
+other: 0.534
+socket: 0.519
+graphic: 0.495
+semantic: 0.406
+network: 0.374
+vnc: 0.274
+boot: 0.262
+PID: 0.195
+permissions: 0.056
+files: 0.041
+KVM: 0.004
+
+USB passthrough in Windows Host non functional
diff --git a/results/classifier/zero-shot/108/device/448 b/results/classifier/zero-shot/108/device/448
new file mode 100644
index 00000000..8b6b0250
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/448
@@ -0,0 +1,16 @@
+device: 0.970
+debug: 0.748
+graphic: 0.745
+network: 0.655
+PID: 0.600
+files: 0.474
+boot: 0.444
+performance: 0.384
+other: 0.303
+vnc: 0.290
+semantic: 0.270
+permissions: 0.216
+socket: 0.072
+KVM: 0.001
+
+raspi0 machine leads to kernel panic of latest raspberry pi os kernel
diff --git a/results/classifier/zero-shot/108/device/468 b/results/classifier/zero-shot/108/device/468
new file mode 100644
index 00000000..f9738166
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/468
@@ -0,0 +1,16 @@
+device: 0.963
+performance: 0.679
+boot: 0.576
+graphic: 0.454
+network: 0.444
+semantic: 0.216
+debug: 0.144
+permissions: 0.095
+PID: 0.077
+socket: 0.070
+other: 0.068
+vnc: 0.030
+KVM: 0.028
+files: 0.025
+
+Zynq7000 UART clock reset initialization
diff --git a/results/classifier/zero-shot/108/device/477 b/results/classifier/zero-shot/108/device/477
new file mode 100644
index 00000000..58efd86c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/477
@@ -0,0 +1,27 @@
+device: 0.924
+graphic: 0.897
+boot: 0.893
+debug: 0.888
+KVM: 0.853
+performance: 0.701
+semantic: 0.643
+PID: 0.587
+vnc: 0.486
+other: 0.416
+permissions: 0.393
+network: 0.365
+files: 0.269
+socket: 0.120
+
+Nested kvm-svm does not work since f5cc5a5c16
+Description of problem:
+Nested SVM virtualization seems to not work. I bisected this to f5cc5a5c16.
+Steps to reproduce:
+1. Boot up a Linux guest such as the Debian Live CD with -accel kvm -cpu host
+2. ```dmesg | grep kvm; ls /dev/kvm```; # Shows that KVM is disabled within the guest
+Additional information:
+Details about my AMD host:
+```
+model name      : AMD Ryzen 5 2600 Six-Core Processor
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
+```
diff --git a/results/classifier/zero-shot/108/device/487 b/results/classifier/zero-shot/108/device/487
new file mode 100644
index 00000000..7e63f041
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/487
@@ -0,0 +1,16 @@
+device: 0.927
+other: 0.903
+performance: 0.803
+permissions: 0.757
+semantic: 0.539
+network: 0.518
+graphic: 0.493
+debug: 0.353
+files: 0.274
+KVM: 0.104
+boot: 0.104
+socket: 0.078
+PID: 0.040
+vnc: 0.020
+
+sdhci: out of bounds read on sd->sd_status
diff --git a/results/classifier/zero-shot/108/device/503 b/results/classifier/zero-shot/108/device/503
new file mode 100644
index 00000000..c128a053
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/503
@@ -0,0 +1,16 @@
+device: 0.941
+debug: 0.665
+graphic: 0.584
+performance: 0.481
+files: 0.287
+boot: 0.237
+network: 0.183
+semantic: 0.146
+permissions: 0.092
+vnc: 0.048
+PID: 0.030
+socket: 0.030
+other: 0.014
+KVM: 0.001
+
+QEMU aarch64 Segmentation fault on Mac OSX, machine raspi3
diff --git a/results/classifier/zero-shot/108/device/51 b/results/classifier/zero-shot/108/device/51
new file mode 100644
index 00000000..f63ed87a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/51
@@ -0,0 +1,16 @@
+device: 0.976
+performance: 0.748
+graphic: 0.729
+debug: 0.494
+network: 0.414
+boot: 0.401
+other: 0.361
+permissions: 0.277
+semantic: 0.195
+PID: 0.088
+vnc: 0.035
+files: 0.030
+KVM: 0.012
+socket: 0.012
+
+Linux kernel oops on Malta board while accessing pflash
diff --git a/results/classifier/zero-shot/108/device/513 b/results/classifier/zero-shot/108/device/513
new file mode 100644
index 00000000..f25104d0
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/513
@@ -0,0 +1,16 @@
+device: 0.977
+performance: 0.721
+network: 0.659
+graphic: 0.574
+debug: 0.400
+boot: 0.311
+semantic: 0.219
+files: 0.214
+permissions: 0.191
+other: 0.135
+socket: 0.082
+PID: 0.063
+vnc: 0.058
+KVM: 0.001
+
+Qemu/WHPX fails on applying UEFI firmware with -pflash
diff --git a/results/classifier/zero-shot/108/device/529 b/results/classifier/zero-shot/108/device/529
new file mode 100644
index 00000000..61491e8a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/529
@@ -0,0 +1,19 @@
+device: 0.926
+graphic: 0.905
+socket: 0.727
+semantic: 0.654
+performance: 0.540
+files: 0.500
+other: 0.494
+boot: 0.390
+network: 0.270
+PID: 0.193
+debug: 0.164
+vnc: 0.132
+permissions: 0.064
+KVM: 0.001
+
+qemu-system-riscv64 hard lockup on non-stdio serial output
+Additional information:
+u-boot pre-compiled firmware: (directory contains all git revisions, build flags, etc)
+https://github.com/haiku/firmware/tree/master/u-boot/riscv64/qemu
diff --git a/results/classifier/zero-shot/108/device/54 b/results/classifier/zero-shot/108/device/54
new file mode 100644
index 00000000..9a108220
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/54
@@ -0,0 +1,16 @@
+device: 0.956
+network: 0.774
+performance: 0.646
+graphic: 0.553
+boot: 0.482
+debug: 0.368
+permissions: 0.268
+semantic: 0.184
+socket: 0.082
+vnc: 0.081
+other: 0.079
+files: 0.064
+PID: 0.021
+KVM: 0.005
+
+Attaching SD-Card to specific SD-Bus Sabrelite (ARM)
diff --git a/results/classifier/zero-shot/108/device/55 b/results/classifier/zero-shot/108/device/55
new file mode 100644
index 00000000..52fcd32a
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/55
@@ -0,0 +1,16 @@
+device: 0.922
+network: 0.681
+performance: 0.507
+graphic: 0.482
+debug: 0.406
+permissions: 0.331
+files: 0.270
+other: 0.242
+boot: 0.237
+semantic: 0.236
+PID: 0.048
+socket: 0.031
+vnc: 0.013
+KVM: 0.008
+
+Can't install Windows 7 with q35 (SATA)
diff --git a/results/classifier/zero-shot/108/device/554 b/results/classifier/zero-shot/108/device/554
new file mode 100644
index 00000000..f48040fc
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/554
@@ -0,0 +1,16 @@
+device: 0.922
+other: 0.653
+performance: 0.563
+graphic: 0.516
+permissions: 0.248
+files: 0.164
+semantic: 0.161
+boot: 0.149
+PID: 0.116
+debug: 0.109
+KVM: 0.083
+network: 0.073
+vnc: 0.052
+socket: 0.001
+
+q35 machine type cdrom device not discovered by freedos
diff --git a/results/classifier/zero-shot/108/device/558 b/results/classifier/zero-shot/108/device/558
new file mode 100644
index 00000000..4cce9543
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/558
@@ -0,0 +1,72 @@
+device: 0.987
+graphic: 0.949
+performance: 0.910
+semantic: 0.720
+vnc: 0.667
+KVM: 0.626
+network: 0.613
+boot: 0.587
+socket: 0.585
+PID: 0.578
+permissions: 0.546
+debug: 0.328
+other: 0.288
+files: 0.230
+
+gtk UI interprets double/triple click as button release
+Description of problem:
+When using the GTK interface clicking rapidly in a down-up-down pattern, the final "down" event is erroneously followed by an immediate "up" event and the mouse device in the guest reports the pressed button as no longer being held.
+Steps to reproduce:
+1. Start a VM using the GTK interface.
+2. Open a tool to examine guest mouse input events, such as `xev` or `yutani-test`
+3. Click twice with any button, without releasing on the second click.
+4. Observe erroneous 'up' event in guest.
+5. Move the mouse while keeping the button pressed.
+6. Observe the guest reports the button is not held.
+Additional information:
+GTK 3 sends an additional `GDK_2BUTTON_PRESS` event after the initial `GDK_BUTTON_PRESS` event, which QEMU is misinterpreting as a release event. I confirmed this with the addition of some logging of `button->type` in `gd_button_event`:
+
+```
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4 # = PRESS
+button = 1, type = 5 # = 2BUTTON_PRESS
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+```
+
+```diff
+diff --git a/ui/gtk.c b/ui/gtk.c
+index cfb0728d1f..b9979f0e11 100644
+--- a/ui/gtk.c
++++ b/ui/gtk.c
+@@ -925,6 +925,13 @@ static gboolean gd_button_event(GtkWidget *widget, GdkEventButton *button,
+         return TRUE;
+     }
+ 
++    /* ignore additional events for double- and triple- press, as they are
++     * sent to us after a regular press event; otherwise we will misinterpret
++     * these as release events and eat the button! */
++    if (button->type == GDK_2BUTTON_PRESS || button->type == GDK_3BUTTON_PRESS) {
++        return TRUE;
++    }
++
+     qemu_input_queue_btn(vc->gfx.dcl.con, btn,
+                          button->type == GDK_BUTTON_PRESS);
+     qemu_input_event_sync();
+```
diff --git a/results/classifier/zero-shot/108/device/569 b/results/classifier/zero-shot/108/device/569
new file mode 100644
index 00000000..55c5b474
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/569
@@ -0,0 +1,16 @@
+device: 0.938
+debug: 0.882
+performance: 0.754
+graphic: 0.469
+semantic: 0.412
+network: 0.386
+files: 0.376
+other: 0.326
+permissions: 0.234
+vnc: 0.185
+boot: 0.174
+PID: 0.073
+socket: 0.051
+KVM: 0.005
+
+ESP SCSI adapter not working with DOS ASPI drivers
diff --git a/results/classifier/zero-shot/108/device/617 b/results/classifier/zero-shot/108/device/617
new file mode 100644
index 00000000..b8b38fae
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/617
@@ -0,0 +1,41 @@
+device: 0.935
+graphic: 0.913
+performance: 0.903
+socket: 0.818
+semantic: 0.804
+vnc: 0.797
+boot: 0.707
+network: 0.702
+PID: 0.692
+other: 0.654
+debug: 0.643
+permissions: 0.630
+files: 0.345
+KVM: 0.323
+
+USB passthrough with Conbee 2 failing after upgrade to Fedora 34 / Libvirt 7.0.0
+Description of problem:
+Hi,
+
+I upgraded recently from Fedora 32 to 34.
+
+For a little under a year, I've been running reliably a Home Assistant instance with Deconz add-on in a VM, with a Conbee 2 zigbee gateway in USB passthrough, controlling about 15 devices (door/window sensors, thermometers, leak sensors and push buttons).
+
+It has worked flawlessly but stopped working after upgrading Fedora. The Conbee shows up on the Linux guest but the serial can't be read by the Deconz application and it just does not work, the app can't get past the device connection screen.
+
+This is the state of what works and what doesn't:
+
+- Home Assistant Linux VM: NOK
+- Ubuntu Linux 20.04 VM: NOK
+- Windows 10 VM: NOK
+- Windows 10 physical machine: OK, can connect and pair a door sensor
+
+All running the latest Deconz app.
+
+The fact that the physical Windows machine works excludes a bricked device. I used the physical Windows to upgrade the Conbee 2 firmware with no improvement. 
+
+This does not seem to be an isolated issue: https://old.reddit.com/r/homeassistant/comments/o04sgw/conbee_ii_usb_passthrough_with_libvirt_660/
+
+Apologies if this has already been reported. Let me know what kind of logs you might want.
+
+Thanks!
diff --git a/results/classifier/zero-shot/108/device/63 b/results/classifier/zero-shot/108/device/63
new file mode 100644
index 00000000..644e94e8
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/63
@@ -0,0 +1,16 @@
+device: 0.948
+performance: 0.870
+graphic: 0.528
+network: 0.464
+debug: 0.300
+socket: 0.208
+other: 0.147
+PID: 0.131
+semantic: 0.125
+permissions: 0.065
+boot: 0.056
+files: 0.040
+vnc: 0.026
+KVM: 0.007
+
+Illegal delay slot code causes abort on mips64
diff --git a/results/classifier/zero-shot/108/device/651 b/results/classifier/zero-shot/108/device/651
new file mode 100644
index 00000000..8db54036
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/651
@@ -0,0 +1,16 @@
+device: 0.935
+boot: 0.823
+debug: 0.649
+performance: 0.617
+PID: 0.554
+graphic: 0.528
+permissions: 0.473
+files: 0.346
+vnc: 0.263
+semantic: 0.211
+socket: 0.143
+network: 0.020
+other: 0.007
+KVM: 0.007
+
+powerpc: Starting machine ref405ep fails with "Could not load PowerPC BIOS 'ppc405_rom.bin'"
diff --git a/results/classifier/zero-shot/108/device/663 b/results/classifier/zero-shot/108/device/663
new file mode 100644
index 00000000..29bb0317
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/663
@@ -0,0 +1,26 @@
+device: 0.927
+graphic: 0.842
+files: 0.830
+socket: 0.811
+debug: 0.660
+vnc: 0.657
+network: 0.576
+PID: 0.477
+permissions: 0.452
+boot: 0.443
+semantic: 0.427
+performance: 0.348
+other: 0.097
+KVM: 0.019
+
+Assertion `r->req.aiocb == NULL' in am53c974 emulator
+Description of problem:
+
+Steps to reproduce:
+```
+1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers
+2.make -j12
+3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img
+```
+Additional information:
+#
diff --git a/results/classifier/zero-shot/108/device/667 b/results/classifier/zero-shot/108/device/667
new file mode 100644
index 00000000..561fc55e
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/667
@@ -0,0 +1,16 @@
+device: 0.983
+performance: 0.776
+graphic: 0.402
+semantic: 0.384
+files: 0.354
+permissions: 0.308
+boot: 0.229
+debug: 0.156
+network: 0.149
+vnc: 0.082
+PID: 0.076
+other: 0.062
+socket: 0.003
+KVM: 0.002
+
+Wacom EMR pen pressure support
diff --git a/results/classifier/zero-shot/108/device/678 b/results/classifier/zero-shot/108/device/678
new file mode 100644
index 00000000..32fa92ee
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/678
@@ -0,0 +1,62 @@
+device: 0.972
+socket: 0.928
+performance: 0.924
+vnc: 0.883
+boot: 0.857
+network: 0.847
+PID: 0.842
+KVM: 0.803
+debug: 0.792
+other: 0.792
+graphic: 0.760
+files: 0.720
+permissions: 0.713
+semantic: 0.623
+
+eject (monitor command) not work for blockdev cdrom
+Description of problem:
+cdrom1 device work fine, all files reads, but when i whant to eject CD-ROM disk from device by telnet monitor, it not work.
+Steps to reproduce:
+1. Connect to monitor with
+```
+telnet 127.0.0.1 9100
+(QEMU 5.2.0 monitor - type 'help' for more information)
+```
+
+2. Show block devices
+```
+info block
+cdrom1-format: /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only)
+    Attached to:      cdrom1
+    Removable device: not locked, tray closed
+    Cache mode:       writeback
+```
+
+3. Send eject commands
+```
+eject cdrom1
+Error: Device 'cdrom1' not found
+eject cdrom1-format
+Error: Device 'cdrom1-format' not found
+eject cdrom1-storage
+Error: Device 'cdrom1-storage' not found
+```
+Additional information:
+When i run qemu with next lines (replace -blockdev to -drive):
+```
+-device ide-cd,bus=ide.1,drive=cdrom1,id=idecd1,bootindex=2
+-drive if=none,id=cdrom1,media=cdrom,readonly=on,file="/mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso"
+```
+
+eject cdrom1 command work fine
+
+```
+info block
+cdrom1 (#block133): /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only)
+    Attached to:      idecd1
+    Removable device: not locked, tray closed
+    Cache mode:       writeback
+eject cdrom1
+```
+
+Also i found a similar bug description on this link https://bugs.launchpad.net/qemu/+bug/1799766
diff --git a/results/classifier/zero-shot/108/device/68 b/results/classifier/zero-shot/108/device/68
new file mode 100644
index 00000000..8ad16aa8
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/68
@@ -0,0 +1,16 @@
+device: 0.978
+other: 0.644
+performance: 0.614
+graphic: 0.495
+semantic: 0.440
+permissions: 0.438
+debug: 0.260
+boot: 0.208
+PID: 0.086
+network: 0.075
+vnc: 0.038
+files: 0.025
+socket: 0.013
+KVM: 0.001
+
+Solaris can't be powered off with ACPI shutdown/poweroff
diff --git a/results/classifier/zero-shot/108/device/71 b/results/classifier/zero-shot/108/device/71
new file mode 100644
index 00000000..dad0e4e3
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/71
@@ -0,0 +1,16 @@
+device: 0.936
+performance: 0.856
+network: 0.579
+graphic: 0.556
+PID: 0.500
+boot: 0.487
+permissions: 0.468
+vnc: 0.445
+debug: 0.405
+other: 0.364
+semantic: 0.358
+files: 0.348
+socket: 0.195
+KVM: 0.136
+
+AC97 can allocate ~500MB of host RAM
diff --git a/results/classifier/zero-shot/108/device/723460 b/results/classifier/zero-shot/108/device/723460
new file mode 100644
index 00000000..21f1f442
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/723460
@@ -0,0 +1,70 @@
+device: 0.933
+other: 0.882
+boot: 0.820
+performance: 0.808
+permissions: 0.798
+semantic: 0.796
+files: 0.787
+PID: 0.782
+graphic: 0.781
+socket: 0.749
+network: 0.678
+vnc: 0.616
+KVM: 0.565
+debug: 0.522
+
+qemu on linux doesn't boot for winxp install via usb
+
+hi guys,
+I try to install windows xp via qemu. I can only boot from usb and somehow it is my problem.
+I run a Winxp/xubuntu10.04 Dualboot-system with some virtual drives in windows ( till letter f:? ).
+at qemu I created an image from 30Gigabytes and entered this command from the imagefile's directory :
+
+"sudo qemu-system-x86_64 -localtime -usbdevice -hda /dev/sdb -m 384 -boot d winxp.img"
+
+the answer is :
+
+"qemu-system-x86_64: -boot d: drive with bus=0, unit=0 (index=0) exists"
+
+I had to set the usb-stick in the fstab file with this command :
+
+"UUID=X	/media/usb	vfat	rw,users,noauto,umask=000	0	0"
+
+anybody experienced the same problem?
+
+I would appreciate any kind of help
+
+greetz
+
+On Tue, Feb 22, 2011 at 11:49 PM, dankoe <email address hidden> wrote:
+> Public bug reported:
+>
+> hi guys,
+> I try to install windows xp via qemu. I can only boot from usb and somehow it is my problem.
+> I run a Winxp/xubuntu10.04 Dualboot-system with some virtual drives in windows ( till letter f:? ).
+> at qemu I created an image from 30Gigabytes and entered this command from the imagefile's directory :
+>
+> "sudo qemu-system-x86_64 -localtime -usbdevice -hda /dev/sdb -m 384
+> -boot d winxp.img"
+>
+> the answer is :
+>
+> "qemu-system-x86_64: -boot d: drive with bus=0, unit=0 (index=0) exists"
+
+Why are you using "-boot d"?  'd' is the first CD-ROM and you have not
+given any -cdrom ISO image.
+
+Stefan
+
+
+hey stefan,
+
+I didn't find any manual for installing via usb,
+but I tried various letters till "g".
+what letter would you suggest?
+
+on my usb drive I have a linux bootable xp partition.
+or should I try to boot from a virtual drive via .iso image?
+
+thank you
+
diff --git a/results/classifier/zero-shot/108/device/743 b/results/classifier/zero-shot/108/device/743
new file mode 100644
index 00000000..ddc6a8af
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/743
@@ -0,0 +1,26 @@
+device: 0.944
+performance: 0.893
+graphic: 0.835
+semantic: 0.813
+boot: 0.701
+debug: 0.599
+PID: 0.565
+vnc: 0.564
+socket: 0.559
+permissions: 0.555
+network: 0.546
+files: 0.522
+other: 0.292
+KVM: 0.024
+
+aarch64: Number of SMP CPUS exceeds max CPUs supported by machine (10 > 8) for M1 Pro/Max
+Description of problem:
+Trying to launch QEMU with more than 8 cores gives the following error:
+
+`qemu-system-aarch64: Number of SMP CPUs requested (10) exceeds max CPUs supported by machine 'mach-virt' (8)`
+
+Apple M1 Pro can have up to 10 cores while M1 Max only has 10 cores.
+Steps to reproduce:
+1. Install QEMU via homebrew (or MacPorts or from source)
+2. Run `qemu-system-aarch64 -machine virt,highmem=off -accel hvf -cpu cortex-a72 -smp 10`
+3. Get error, QEMU doesn't start
diff --git a/results/classifier/zero-shot/108/device/752 b/results/classifier/zero-shot/108/device/752
new file mode 100644
index 00000000..0e3b4c25
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/752
@@ -0,0 +1,28 @@
+device: 0.930
+graphic: 0.821
+debug: 0.664
+performance: 0.643
+semantic: 0.638
+vnc: 0.503
+PID: 0.465
+permissions: 0.370
+socket: 0.368
+boot: 0.346
+other: 0.331
+network: 0.248
+files: 0.053
+KVM: 0.032
+
+vmmouse device gets attached twice, one without i8042 associated
+Description of problem:
+I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too.
+
+[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is:
+
+* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time
+* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler
+* obviously, a crash because ISAKBDDevice should never be null
+Steps to reproduce:
+1. Load VMware mouse driver
+2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading)
+3. Crash
diff --git a/results/classifier/zero-shot/108/device/776 b/results/classifier/zero-shot/108/device/776
new file mode 100644
index 00000000..a20d5b24
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/776
@@ -0,0 +1,40 @@
+device: 0.980
+graphic: 0.956
+performance: 0.945
+debug: 0.923
+vnc: 0.921
+files: 0.908
+PID: 0.886
+permissions: 0.884
+semantic: 0.869
+socket: 0.865
+boot: 0.797
+network: 0.781
+other: 0.747
+KVM: 0.719
+
+Windows guest fails to start on 6.1.0 - opengl is not available
+Description of problem:
+I've created a Windows 10 guest with virt-manager. The VM started successfully with qemu 6.0.0-3. After upgrading to 6.1.0
+it fails with the following error:
+
+```
+2021-12-14T19:11:52.884272Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.885199Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.885852Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.886485Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.887098Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.887773Z qemu-system-x86_64: warning: This feature depends on other features that were not requested: CPUID.8000000AH:EDX.svme-addr-chk [bit 28]
+2021-12-14T19:11:52.912523Z qemu-system-x86_64: -device virtio-vga-gl,id=video0,max_outputs=1,bus=pcie.0,addr=0x1: opengl is not available
+2021-12-14 19:11:53.109+0000: shutting down, reason=failed
+```
+
+Upgrading to 6.2.0.rc4 did not fix it. Downgrading to 6.0.0-3 made it work again. This makes it clear to me that the bug was introduce in qemu > 6.0.0 and seems to be not fix by now.
+
+I was able to start the guest on 6.1.0 by disabling 3D acceleration.
+Steps to reproduce:
+1. Create Windows 10 guest VM
+2. Start with qemu 6.0.0 -> Works
+3. Start with qemu 6.1.0 -> Broken
+Additional information:
+People on Reddit mention the same characteristic of this bug -> https://www.reddit.com/r/Fedora/comments/qqw3sq/qemu_video_virtio_opengl_not_available_after/
diff --git a/results/classifier/zero-shot/108/device/784 b/results/classifier/zero-shot/108/device/784
new file mode 100644
index 00000000..5e1d0888
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/784
@@ -0,0 +1,28 @@
+device: 0.952
+graphic: 0.951
+KVM: 0.936
+performance: 0.910
+vnc: 0.879
+other: 0.800
+PID: 0.778
+permissions: 0.774
+network: 0.773
+semantic: 0.759
+debug: 0.713
+boot: 0.701
+socket: 0.606
+files: 0.599
+
+max_hostmem does not work with virtio-vga-gl
+Description of problem:
+With property `max_hostmem=1000`, I hope the virgl VGA device can have 1GB video memory. But, after the VM starts, the command `glxinfo -B` returns "Video memory: 0MB", which I think means the virgl VGA does not obtain any video memory, or `max_hostmem=1000` does not work with `virtio-vga-gl`. Is it a bug or virgl has other property parameter to specify video memory?
+Steps to reproduce:
+1. Build qemu using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
+```
+2. Install Red Hat Enterprise Linux 8.5 in qemu
+3. Run qemu using the above command line.
+4. Type `glxinfo -B` in VM terminal
+Additional information:
+![image](/uploads/c0bfb7a336493387ee90ffe7e6209dfe/image.png)
diff --git a/results/classifier/zero-shot/108/device/788 b/results/classifier/zero-shot/108/device/788
new file mode 100644
index 00000000..e4cc0e91
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/788
@@ -0,0 +1,16 @@
+device: 0.926
+network: 0.882
+performance: 0.847
+files: 0.649
+vnc: 0.613
+debug: 0.554
+socket: 0.537
+permissions: 0.502
+boot: 0.466
+other: 0.302
+graphic: 0.266
+semantic: 0.263
+KVM: 0.220
+PID: 0.114
+
+FEAT_PAuth trapping behaviour incorrectly emulated on Secure-EL0/1 with Secure-EL2 disabled
diff --git a/results/classifier/zero-shot/108/device/791 b/results/classifier/zero-shot/108/device/791
new file mode 100644
index 00000000..e2e52642
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/791
@@ -0,0 +1,16 @@
+device: 0.942
+performance: 0.811
+network: 0.743
+debug: 0.705
+boot: 0.467
+vnc: 0.457
+other: 0.442
+graphic: 0.413
+semantic: 0.367
+socket: 0.194
+permissions: 0.122
+PID: 0.055
+files: 0.025
+KVM: 0.001
+
+unable to execute QEMU command - SGX VM using libvirtd
diff --git a/results/classifier/zero-shot/108/device/800 b/results/classifier/zero-shot/108/device/800
new file mode 100644
index 00000000..021c035c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/800
@@ -0,0 +1,40 @@
+device: 0.952
+graphic: 0.916
+PID: 0.740
+semantic: 0.683
+performance: 0.679
+debug: 0.652
+vnc: 0.630
+files: 0.622
+permissions: 0.481
+boot: 0.464
+socket: 0.418
+network: 0.381
+other: 0.151
+KVM: 0.134
+
+Cannot write to MTP Devices in Qemu 6.0.0+
+Description of problem:
+QEMU versions above 6.0.0 are no longer able to write to MTP devices, the kernel prints a warning which is unique to versions above 6.0.0:
+```
+usb-mtp: file monitoring init failed: File monitoring not available on this platform is just warning
+```
+Steps to reproduce:
+1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0
+2. Mount the MTP device using something:
+   ```
+   mkdir mtpDevice && jmtpfs mtpDevice
+   ```
+3. Try to write to the mtp device:
+   ```
+   touch mtpDevice/test
+   ```
+4. Observe that you will get an input/output error when trying to write to the device, like this:
+   ```
+   vm-test-run-mtp> client: must succeed: /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh >&2
+   vm-test-run-mtp> client # Device 0 (VID=46f4 and PID=0004) is a QEMU Virtual MTP.
+   vm-test-run-mtp> client # qemu-system-x86_64: usb-mtp: file monitoring init failed: File monitoring not available on this platform
+   vm-test-run-mtp> client # /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh: line 4: phone/tmp/testFile: Input/output error
+   ```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/801 b/results/classifier/zero-shot/108/device/801
new file mode 100644
index 00000000..02435a66
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/801
@@ -0,0 +1,27 @@
+device: 0.929
+PID: 0.805
+graphic: 0.787
+files: 0.724
+debug: 0.708
+vnc: 0.682
+permissions: 0.604
+performance: 0.560
+semantic: 0.554
+socket: 0.522
+network: 0.464
+KVM: 0.446
+boot: 0.434
+other: 0.124
+
+QEMU test build failure with --enable-modules
+Description of problem:
+
+Steps to reproduce:
+1. ./configure --target-list=x86_64-softmmu --enable-kvm --enable-modules
+2.  make -j8 check-qtest-x86_64 V=1  
+ 
+ - A problem happens "qemu-system-x86_64: -accel qtest: invalid accelerator qtest" 
+ - The file accel-qtest-x86_64.so is not built
+ - This problem happens since 69c4c5c1c47f5dac140eb6485c5281a9f145dcf3 Mon Sep 17 00:00:00 2001
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/804 b/results/classifier/zero-shot/108/device/804
new file mode 100644
index 00000000..905cf30c
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/804
@@ -0,0 +1,24 @@
+device: 0.929
+graphic: 0.712
+network: 0.711
+performance: 0.703
+debug: 0.608
+semantic: 0.519
+PID: 0.368
+boot: 0.325
+permissions: 0.270
+socket: 0.249
+files: 0.223
+KVM: 0.197
+vnc: 0.150
+other: 0.075
+
+savevm - QXL preventing save
+Description of problem:
+Attempting to savevm with a QXL VGA device attached causes the error "pre-save failed: qxl" to appear.
+Steps to reproduce:
+1. Start a QEMU instance with a QXL device
+2. Attempt to savevm
+3. See error
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/808 b/results/classifier/zero-shot/108/device/808
new file mode 100644
index 00000000..0bc743fd
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/808
@@ -0,0 +1,33 @@
+device: 0.963
+graphic: 0.930
+boot: 0.898
+KVM: 0.888
+semantic: 0.826
+performance: 0.818
+vnc: 0.796
+PID: 0.752
+files: 0.698
+network: 0.682
+permissions: 0.658
+socket: 0.638
+other: 0.495
+debug: 0.443
+
+virtio-scsi in Windows guests cause QEMU to abort/crash
+Description of problem:
+* Attempting to load the virtio-scsi drivers in a Windows guest causes the VM to abort/crash.
+Steps to reproduce:
+* `qemu-system-x86_64 -accel kvm -m 4G -device virtio-scsi-pci,id=scsi0 -drive media=cdrom,file=windows7-x64.iso -drive media=cdrom,file=virtio-win-0.1.173.iso`
+ * Boot the installer ISO, click through all the menus to eventually get to Custom Install
+ * In "Where do you want to install" click Load driver
+ * Browse E: drive and pick the first amd64/w7 folder
+ * Should show "Red Had VirtIO SCSI pass-through controller"
+ * Click Next
+ * Abort/crash
+
+Same thing happens with VM's that used to work already running the virtio-scsi drivers. When they boot the VM aborts.
+Additional information:
+```
+qemu-system-x86_64: ../accel/kvm/kvm-all.c:1760: kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
+Aborted (core dumped)
+```
diff --git a/results/classifier/zero-shot/108/device/823733 b/results/classifier/zero-shot/108/device/823733
new file mode 100644
index 00000000..4c5b08d8
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/823733
@@ -0,0 +1,163 @@
+device: 0.942
+KVM: 0.928
+debug: 0.926
+permissions: 0.918
+graphic: 0.913
+PID: 0.911
+other: 0.904
+vnc: 0.901
+network: 0.895
+semantic: 0.882
+performance: 0.879
+boot: 0.861
+files: 0.851
+socket: 0.844
+
+Solaris can't be powered off with ACPI shutdown/poweroff
+
+Thank you forgive my poor English.
+
+It seems KVM can’t poweroff solairs 10 or sloalrs 11 VM.
+I have created solaris 10 and 11 as usual. Everything in VM is running OK, but finally I use shell command ‘poweroff’ or ‘init 5’, the solaris VM (both 10 & 11) system could’t be poweroff but with promoting me the message: perss any key to reboot …..  ,I pressed any key in vnc client, solaris VM reboot immediately. Endless reboot loop above.
+
+the solaris 10 & 11 from oracle iso file name :
+sol-10-u9-ga-x86-dvd.iso
+sol-11-exp-201011-text-x86.iso
+
+the solaris 10 & 11 from oracle iso file name :
+sol-10-u9-ga-x86-dvd.iso
+sol-11-exp-201011-text-x86.iso
+
+1. On my real physical machine,the solaris can be poweroff
+2. On vmware ,the solaris can be poweroff
+3. On my real physical machine,I have try to disbale the ACPI opiton in BOIS, then the solaris can't be poweroff,Like the problem I have described above
+so ,I doubt the KVM has a little problem in ACPI 
+
+I have try the suggestion as follows, but I can’t solve the problem.
+7.2 Solaris reboot all the time on grub menu
+•	Run through the installer as usual 
+•	On completion and reboot, the VM will perpetually reboot. "Stop" the VM. 
+•	Start it up again, and immediately open a vnc console and select the Safe Boot from the options screen 
+•	When prompted if you want to try and recover the boot block, say yes 
+•	You should now have a Bourne terminal with your existing filesystem mounted on /a 
+•	Run /a/usr/bin/bash (my preferred shell) 
+•	export TERM=xterm 
+•	vi /a/boot/grub/menu.1st (editing the bootloader on your mounted filesystem), to add "kernel/unix" to the kernel options for the non-safe-mode boot. Ex : 
+Config File : /a/boot/grub/menu.lst 
+kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS kernel/unix
+
+According to KVM requirements, I collected the following information:
+CPU model name
+model name      : Intel(R) Xeon(R) CPU           X3450  @ 2.67GHz
+
+kvm -version
+QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3), Copyright (c) 2003-2008 Fabrice Bellard
+
+Host kernel version
+Ubuntu 10.04.1 LTS   2.6.32-25-server 
+
+What host kernel arch you are using (i386 or x86_64)
+X86_64
+
+Guest OS
+Solaris 10 and Solaris 11，both can not shutdown
+
+The qemu command line you are using to start the guest 
+
+First, I used the command line as follows:
+kvm -m 1024 -drive file=solaris10.img,cache=writeback -net nic -net user -nographic -vnc :1
+then I try to use -no-kvm-irqchip or -no-kvm ,but the problem also appears!
+
+Secondly, have created and run solaris 10&11 by using Virsh, still solaris can't be poweroff, the XML file content is :
+<domain type='kvm'>
+    <name>solairs</name>
+    <uuid>85badf15-244d-4719-a2da-8c3de064137d</uuid>
+    <memory>1677721</memory>
+    <currentMemory>1677721</currentMemory>
+    <vcpu>1</vcpu>
+    <os>
+    <type arch='i686' machine='pc-0.12'>hvm</type>
+      <boot dev='hd'/>
+   </os>
+   <features>
+    <acpi/>
+    <apic/>
+   </features>
+  <clock offset='utc'/>
+   <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+   <on_crash>destroy</on_crash>
+   <devices>
+     <emulator>/usr/bin/kvm</emulator>
+     <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='writeback'/>
+       <source file='/opt/GuestOS/solaris10.img'/>
+       <target dev='hda' bus='ide'/>
+     </disk>
+    <interface type='bridge'>
+      <mac address='00:0c:29:d0:36:c3'/>
+      <source bridge='br1'/>
+      <target dev='vnet0'/>
+     </interface>
+     <input type='mouse' bus='ps2'/>
+     <graphics type='vnc' port='5901' autoport='no' keymap='en-us'/>
+    <video>
+      <model type='vga' vram='65536' heads='1'/>
+    </video>
+  </devices>
+  <seclabel type='dynamic' model='apparmor'>
+    <label>libvirt-f36f5289-692e-6f1c-fe71-c6ed19453e2f</label>
+    <imagelabel>libvirt-f36f5289-692e-6f1c-fe71-c6ed19453e2f</imagelabel>
+  </seclabel>
+ </domain>
+
+
+
+
+
+
+
+
+
+Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)?
+
+I just ran into the same issue on Arch with qemu 2.9.0 and as well Ubuntu qemu 2.8.something. Solaris 11 on powerdown shuts down to the point where it prompts you that it's now safe to power off the VM, works fine in vmware or virtualbox.
+In a packer build at this point you just fail as the VM did not power down in time.
+
+
+I can reproduce the issue with modern illumos distributions like OpenIndiana 2017.10 on Linux KVM host with QEMU 2.10.1 (illumos is OpenSolaris OS/Net - i.e. "the kernel" - heir, roughly equal to Solaris 11).
+
+It's still the case illumos will shut down on other hypervizors e.g. VirtualBox. I raised the question on #illumos IRC chat and an illumos developer replied it might be a shortage in illumos that "it's not playing nice with some ACPI emulation bugs".
+
+This bug was reported almost 9 years ago and still nobody take care about it...
+
+# kvm -version
+QEMU emulator version 4.1.1 (pve-qemu-kvm_4.1.1)
+Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
+
+# more /etc/os-release 
+PRETTY_NAME="Debian GNU/Linux 10 (buster)"
+NAME="Debian GNU/Linux"
+VERSION_ID="10"
+VERSION="10 (buster)"
+VERSION_CODENAME=buster
+ID=debian
+HOME_URL="https://www.debian.org/"
+SUPPORT_URL="https://www.debian.org/support"
+BUG_REPORT_URL="https://bugs.debian.org/"
+
+Guest OS: Solaris 11.4 
+
+# /usr/sbin/qm shutdown 101
+VM quit/powerdown failed - got timeout
+
+# /usr/sbin/qm reboot 101
+VM quit/powerdown failed - got timeout
+
+Not able to shutdown/reboot Solaris 11
+
+
+This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets now closed in Launchpad. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/68
+
diff --git a/results/classifier/zero-shot/108/device/837 b/results/classifier/zero-shot/108/device/837
new file mode 100644
index 00000000..744bcd62
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/837
@@ -0,0 +1,45 @@
+device: 0.946
+performance: 0.931
+graphic: 0.919
+files: 0.864
+debug: 0.815
+semantic: 0.776
+PID: 0.758
+permissions: 0.728
+network: 0.707
+boot: 0.693
+vnc: 0.638
+socket: 0.595
+other: 0.481
+KVM: 0.074
+
+x86 user: icebp/int1 raises wrong signal
+Description of problem:
+This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`.
+
+Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`.
+
+This also happens on an AArch64 host.
+```
+$ ./icebp
+Trace/breakpoint trap
+$ qemu-x86_64 ./icebp
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction
+```
+Steps to reproduce:
+1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386
+```
+    .globl _start
+_start:
+    .byte  0xF1 // gas doesn't assemble this instruction opcode but it disassembles it
+#ifdef __x86_64__
+    mov    $60, %eax
+    syscall
+#else
+    mov    $1, %eax
+    int    $0x80
+#endif 
+```
+2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message
+3. Run on qemu-user. Notice how it raises `SIGILL`.
diff --git a/results/classifier/zero-shot/108/device/879 b/results/classifier/zero-shot/108/device/879
new file mode 100644
index 00000000..9e21b889
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/879
@@ -0,0 +1,18 @@
+device: 0.947
+other: 0.749
+performance: 0.581
+boot: 0.510
+network: 0.418
+graphic: 0.380
+semantic: 0.320
+debug: 0.246
+KVM: 0.197
+permissions: 0.183
+PID: 0.180
+vnc: 0.139
+files: 0.072
+socket: 0.049
+
+Microphone support for Macbooks
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/896 b/results/classifier/zero-shot/108/device/896
new file mode 100644
index 00000000..61f2bb80
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/896
@@ -0,0 +1,16 @@
+device: 0.935
+network: 0.799
+graphic: 0.693
+performance: 0.617
+other: 0.332
+debug: 0.290
+permissions: 0.249
+boot: 0.196
+semantic: 0.117
+files: 0.088
+PID: 0.075
+vnc: 0.067
+socket: 0.061
+KVM: 0.017
+
+tcg/arm emits UNPREDICTABLE LDRD insn
diff --git a/results/classifier/zero-shot/108/device/897 b/results/classifier/zero-shot/108/device/897
new file mode 100644
index 00000000..a6e8b5fe
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/897
@@ -0,0 +1,16 @@
+device: 0.935
+performance: 0.911
+graphic: 0.822
+network: 0.553
+debug: 0.430
+semantic: 0.331
+boot: 0.157
+other: 0.111
+permissions: 0.102
+files: 0.097
+socket: 0.084
+PID: 0.078
+vnc: 0.042
+KVM: 0.007
+
+Warning with "qemu-s390x -cpu max"
diff --git a/results/classifier/zero-shot/108/device/901 b/results/classifier/zero-shot/108/device/901
new file mode 100644
index 00000000..2223efbb
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/901
@@ -0,0 +1,25 @@
+device: 0.940
+KVM: 0.888
+graphic: 0.884
+PID: 0.560
+vnc: 0.516
+debug: 0.492
+performance: 0.431
+semantic: 0.407
+permissions: 0.337
+other: 0.326
+boot: 0.325
+files: 0.285
+socket: 0.221
+network: 0.078
+
+Bad screen behavior with adaptive sync
+Description of problem:
+KDE Wayland has freesync automatically enabled for full screen applications[[1]](https://wiki.archlinux.org/title/Variable_refresh_rate#Wayland_configuration). When using a VM in full screen mode, the screen starts having a strange behavior, like "blinking". I've tried windows 10, Linux Mint, MX Linux and Ubuntu 21.10.
+The problem disappears if using Xorg or disabling freesync trough KDE settings.
+Steps to reproduce:
+1. On KDE Wayland, check if freesync is activated in settings> screen> adaptive synchronization 
+2. Launch any vm in fuul screen mode
+3. Observe the screen
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/device/902 b/results/classifier/zero-shot/108/device/902
new file mode 100644
index 00000000..8c8b52ff
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/902
@@ -0,0 +1,16 @@
+device: 0.961
+boot: 0.881
+graphic: 0.412
+performance: 0.399
+semantic: 0.248
+other: 0.113
+network: 0.102
+PID: 0.092
+socket: 0.071
+files: 0.071
+permissions: 0.069
+debug: 0.065
+vnc: 0.024
+KVM: 0.002
+
+BootLinuxS390X test failing due to a TCG bug
diff --git a/results/classifier/zero-shot/108/device/924 b/results/classifier/zero-shot/108/device/924
new file mode 100644
index 00000000..9d898605
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/924
@@ -0,0 +1,16 @@
+device: 0.933
+performance: 0.889
+network: 0.746
+graphic: 0.616
+semantic: 0.335
+debug: 0.335
+boot: 0.267
+permissions: 0.254
+vnc: 0.124
+socket: 0.113
+other: 0.109
+files: 0.084
+PID: 0.069
+KVM: 0.001
+
+AHCI IRQ lost running Fedora on SBSA-ref
diff --git a/results/classifier/zero-shot/108/device/98 b/results/classifier/zero-shot/108/device/98
new file mode 100644
index 00000000..dc8637d9
--- /dev/null
+++ b/results/classifier/zero-shot/108/device/98
@@ -0,0 +1,16 @@
+device: 0.934
+graphic: 0.931
+performance: 0.450
+debug: 0.315
+semantic: 0.233
+vnc: 0.113
+boot: 0.088
+PID: 0.059
+other: 0.057
+permissions: 0.021
+socket: 0.020
+network: 0.010
+files: 0.010
+KVM: 0.004
+
+Curses Keyboard Broken On OS X
-- 
cgit v1.2.3