From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 19:39:53 +0200 Subject: restructure results --- results/classifier/118/device/1014 | 33 --- results/classifier/118/device/1016 | 33 --- results/classifier/118/device/1017793 | 38 ---- results/classifier/118/device/1021 | 39 ---- results/classifier/118/device/1024 | 40 ---- results/classifier/118/device/1033 | 57 ------ results/classifier/118/device/1034980 | 52 ----- results/classifier/118/device/1038070 | 149 -------------- results/classifier/118/device/1049 | 31 --- results/classifier/118/device/1050823 | 52 ----- results/classifier/118/device/107 | 31 --- results/classifier/118/device/1072 | 54 ----- results/classifier/118/device/1077 | 31 --- results/classifier/118/device/1080 | 31 --- results/classifier/118/device/1083 | 31 --- results/classifier/118/device/1088 | 31 --- results/classifier/118/device/1090558 | 44 ---- results/classifier/118/device/1090602 | 48 ----- results/classifier/118/device/1103903 | 73 ------- results/classifier/118/device/1106 | 39 ---- results/classifier/118/device/1108 | 31 --- results/classifier/118/device/112 | 31 --- results/classifier/118/device/1124 | 31 --- results/classifier/118/device/1133 | 40 ---- results/classifier/118/device/1134 | 33 --- results/classifier/118/device/1140 | 31 --- results/classifier/118/device/1142 | 76 ------- results/classifier/118/device/115 | 31 --- results/classifier/118/device/1155677 | 57 ------ results/classifier/118/device/116 | 31 --- results/classifier/118/device/117 | 31 --- results/classifier/118/device/1171 | 33 --- results/classifier/118/device/118 | 31 --- results/classifier/118/device/1181354 | 40 ---- results/classifier/118/device/1187 | 31 --- results/classifier/118/device/1187529 | 47 ----- results/classifier/118/device/119 | 31 --- results/classifier/118/device/1191 | 39 ---- results/classifier/118/device/1196 | 42 ---- results/classifier/118/device/1198350 | 82 -------- results/classifier/118/device/1208 | 39 ---- results/classifier/118/device/1210 | 38 ---- results/classifier/118/device/1211 | 37 ---- results/classifier/118/device/1221 | 59 ------ results/classifier/118/device/1225 | 31 --- results/classifier/118/device/1226 | 55 ----- results/classifier/118/device/1230 | 53 ----- results/classifier/118/device/1237 | 31 --- results/classifier/118/device/1244 | 75 ------- results/classifier/118/device/1246 | 31 --- results/classifier/118/device/1248469 | 38 ---- results/classifier/118/device/1256826 | 46 ----- results/classifier/118/device/1262 | 31 --- results/classifier/118/device/1266 | 31 --- results/classifier/118/device/1273 | 31 --- results/classifier/118/device/1275 | 39 ---- results/classifier/118/device/1280521 | 38 ---- results/classifier/118/device/1282 | 33 --- results/classifier/118/device/1284 | 44 ---- results/classifier/118/device/1290 | 31 --- results/classifier/118/device/1292 | 33 --- results/classifier/118/device/1293 | 31 --- results/classifier/118/device/1300 | 41 ---- results/classifier/118/device/1302 | 47 ----- results/classifier/118/device/1305 | 44 ---- results/classifier/118/device/131 | 31 --- results/classifier/118/device/1315 | 31 --- results/classifier/118/device/1318 | 49 ----- results/classifier/118/device/132 | 31 --- results/classifier/118/device/1332234 | 87 -------- results/classifier/118/device/1334397 | 45 ----- results/classifier/118/device/1335 | 31 --- results/classifier/118/device/1342 | 54 ----- results/classifier/118/device/1346 | 65 ------ results/classifier/118/device/1354 | 31 --- results/classifier/118/device/1363 | 33 --- results/classifier/118/device/1367 | 35 ---- results/classifier/118/device/1369 | 31 --- results/classifier/118/device/137 | 31 --- results/classifier/118/device/1377163 | 52 ----- results/classifier/118/device/1384 | 31 --- results/classifier/118/device/1386478 | 40 ---- results/classifier/118/device/1391 | 58 ------ results/classifier/118/device/1406 | 31 --- results/classifier/118/device/1413 | 52 ----- results/classifier/118/device/1416 | 35 ---- results/classifier/118/device/1432 | 54 ----- results/classifier/118/device/1445633 | 49 ----- results/classifier/118/device/145 | 31 --- results/classifier/118/device/1450 | 31 --- results/classifier/118/device/1450891 | 61 ------ results/classifier/118/device/1453025 | 50 ----- results/classifier/118/device/1456 | 41 ---- results/classifier/118/device/1457 | 31 --- results/classifier/118/device/1466 | 37 ---- results/classifier/118/device/1476 | 31 --- results/classifier/118/device/1476800 | 39 ---- results/classifier/118/device/148 | 31 --- results/classifier/118/device/1481 | 31 --- results/classifier/118/device/1483 | 31 --- results/classifier/118/device/1485010 | 41 ---- results/classifier/118/device/149 | 31 --- results/classifier/118/device/1491 | 31 --- results/classifier/118/device/150 | 31 --- results/classifier/118/device/1502 | 31 --- results/classifier/118/device/1507 | 67 ------- results/classifier/118/device/1512 | 31 --- results/classifier/118/device/1513234 | 46 ----- results/classifier/118/device/1515 | 48 ----- results/classifier/118/device/1519 | 42 ---- results/classifier/118/device/1521 | 31 --- results/classifier/118/device/1524637 | 48 ----- results/classifier/118/device/1527 | 33 --- results/classifier/118/device/153 | 31 --- results/classifier/118/device/1533848 | 36 ---- results/classifier/118/device/1538 | 31 --- results/classifier/118/device/1539 | 33 --- results/classifier/118/device/1542 | 43 ---- results/classifier/118/device/1548471 | 42 ---- results/classifier/118/device/1553760 | 38 ---- results/classifier/118/device/1563 | 33 --- results/classifier/118/device/1564 | 100 ---------- results/classifier/118/device/1572 | 31 --- results/classifier/118/device/1577937 | 61 ------ results/classifier/118/device/1578 | 33 --- results/classifier/118/device/158 | 31 --- results/classifier/118/device/1581308 | 55 ----- results/classifier/118/device/1581976 | 52 ----- results/classifier/118/device/1582 | 31 --- results/classifier/118/device/1590796 | 77 ------- results/classifier/118/device/1592590 | 52 ----- results/classifier/118/device/1602 | 37 ---- results/classifier/118/device/1603785 | 48 ----- results/classifier/118/device/1610 | 31 --- results/classifier/118/device/1616 | 31 --- results/classifier/118/device/1622 | 31 --- results/classifier/118/device/1635695 | 43 ---- results/classifier/118/device/1643 | 31 --- results/classifier/118/device/1651 | 31 --- results/classifier/118/device/1655 | 31 --- results/classifier/118/device/1656710 | 44 ---- results/classifier/118/device/1660035 | 68 ------- results/classifier/118/device/1661 | 41 ---- results/classifier/118/device/1663 | 64 ------ results/classifier/118/device/1665 | 31 --- results/classifier/118/device/1672 | 38 ---- results/classifier/118/device/1675549 | 49 ----- results/classifier/118/device/1690 | 33 --- results/classifier/118/device/1699628 | 52 ----- results/classifier/118/device/171 | 31 --- results/classifier/118/device/1712 | 39 ---- results/classifier/118/device/1712818 | 101 ---------- results/classifier/118/device/1726733 | 44 ---- results/classifier/118/device/173 | 31 --- results/classifier/118/device/1731347 | 73 ------- results/classifier/118/device/1732981 | 50 ----- results/classifier/118/device/1733 | 33 --- results/classifier/118/device/1735653 | 79 -------- results/classifier/118/device/1737882 | 38 ---- results/classifier/118/device/1738771 | 53 ----- results/classifier/118/device/174 | 31 --- results/classifier/118/device/1744654 | 37 ---- results/classifier/118/device/1748 | 86 -------- results/classifier/118/device/1749 | 50 ----- results/classifier/118/device/175 | 31 --- results/classifier/118/device/1754 | 46 ----- results/classifier/118/device/1754597 | 65 ------ results/classifier/118/device/1759 | 40 ---- results/classifier/118/device/1759492 | 51 ----- results/classifier/118/device/1761 | 31 --- results/classifier/118/device/1767 | 33 --- results/classifier/118/device/1769 | 31 --- results/classifier/118/device/1769067 | 42 ---- results/classifier/118/device/1773 | 39 ---- results/classifier/118/device/1776 | 31 --- results/classifier/118/device/1777232 | 46 ----- results/classifier/118/device/1777235 | 46 ----- results/classifier/118/device/1780815 | 43 ---- results/classifier/118/device/1793 | 65 ------ results/classifier/118/device/1794 | 57 ------ results/classifier/118/device/1794187 | 60 ------ results/classifier/118/device/1794939 | 68 ------- results/classifier/118/device/1797 | 33 --- results/classifier/118/device/1798 | 31 --- results/classifier/118/device/1800088 | 43 ---- results/classifier/118/device/1805697 | 89 --------- results/classifier/118/device/181 | 31 --- results/classifier/118/device/1811758 | 54 ----- results/classifier/118/device/1813307 | 60 ------ results/classifier/118/device/1815445 | 50 ----- results/classifier/118/device/182 | 31 --- results/classifier/118/device/1821131 | 64 ------ results/classifier/118/device/1821884 | 59 ------ results/classifier/118/device/1824853 | 110 ---------- results/classifier/118/device/1831477 | 51 ----- results/classifier/118/device/1839 | 71 ------- results/classifier/118/device/184 | 31 --- results/classifier/118/device/1843 | 45 ----- results/classifier/118/device/1844644 | 40 ---- results/classifier/118/device/1847 | 31 --- results/classifier/118/device/1853 | 31 --- results/classifier/118/device/1853898 | 70 ------- results/classifier/118/device/1854878 | 78 -------- results/classifier/118/device/1859 | 38 ---- results/classifier/118/device/1861458 | 60 ------ results/classifier/118/device/1864 | 51 ----- results/classifier/118/device/1866792 | 108 ---------- results/classifier/118/device/187 | 31 --- results/classifier/118/device/1871005 | 51 ----- results/classifier/118/device/1874486 | 144 -------------- results/classifier/118/device/1875080 | 54 ----- results/classifier/118/device/1880 | 43 ---- results/classifier/118/device/1882787 | 97 --------- results/classifier/118/device/1887 | 39 ---- results/classifier/118/device/1888 | 42 ---- results/classifier/118/device/1898 | 62 ------ results/classifier/118/device/1901068 | 75 ------- results/classifier/118/device/1902262 | 83 -------- results/classifier/118/device/1902306 | 73 ------- results/classifier/118/device/1904490 | 87 -------- results/classifier/118/device/1911188 | 85 -------- results/classifier/118/device/1922102 | 112 ----------- results/classifier/118/device/1922252 | 54 ----- results/classifier/118/device/1925094 | 68 ------- results/classifier/118/device/1926995 | 55 ----- results/classifier/118/device/1927408 | 87 -------- results/classifier/118/device/1933 | 71 ------- results/classifier/118/device/1935 | 35 ---- results/classifier/118/device/1959 | 31 --- results/classifier/118/device/1961 | 31 --- results/classifier/118/device/1969 | 31 --- results/classifier/118/device/1973 | 31 --- results/classifier/118/device/1979 | 61 ------ results/classifier/118/device/1980 | 43 ---- results/classifier/118/device/1984 | 31 --- results/classifier/118/device/2002 | 33 --- results/classifier/118/device/2008 | 42 ---- results/classifier/118/device/2018 | 48 ----- results/classifier/118/device/2020 | 41 ---- results/classifier/118/device/2021 | 31 --- results/classifier/118/device/2026 | 38 ---- results/classifier/118/device/2028 | 31 --- results/classifier/118/device/203 | 31 --- results/classifier/118/device/2033 | 31 --- results/classifier/118/device/2039 | 41 ---- results/classifier/118/device/204 | 31 --- results/classifier/118/device/2044 | 35 ---- results/classifier/118/device/2048 | 31 --- results/classifier/118/device/2049 | 41 ---- results/classifier/118/device/2055 | 37 ---- results/classifier/118/device/2067 | 31 --- results/classifier/118/device/2086 | 45 ----- results/classifier/118/device/2087 | 58 ------ results/classifier/118/device/2091 | 33 --- results/classifier/118/device/2093 | 33 --- results/classifier/118/device/2122 | 37 ---- results/classifier/118/device/2125 | 44 ---- results/classifier/118/device/2132 | 41 ---- results/classifier/118/device/2156 | 45 ----- results/classifier/118/device/2158 | 39 ---- results/classifier/118/device/2161 | 31 --- results/classifier/118/device/2164 | 37 ---- results/classifier/118/device/217 | 31 --- results/classifier/118/device/2174 | 31 --- results/classifier/118/device/2179 | 81 -------- results/classifier/118/device/219 | 31 --- results/classifier/118/device/2192 | 31 --- results/classifier/118/device/220 | 31 --- results/classifier/118/device/2201 | 41 ---- results/classifier/118/device/221 | 31 --- results/classifier/118/device/2213 | 45 ----- results/classifier/118/device/2215 | 31 --- results/classifier/118/device/2218 | 42 ---- results/classifier/118/device/2222 | 31 --- results/classifier/118/device/224 | 31 --- results/classifier/118/device/2243 | 39 ---- results/classifier/118/device/225 | 31 --- results/classifier/118/device/2268 | 73 ------- results/classifier/118/device/2275 | 39 ---- results/classifier/118/device/2282 | 31 --- results/classifier/118/device/2285 | 31 --- results/classifier/118/device/2306 | 31 --- results/classifier/118/device/2314 | 46 ----- results/classifier/118/device/2317 | 68 ------- results/classifier/118/device/232 | 31 --- results/classifier/118/device/2329 | 31 --- results/classifier/118/device/233 | 31 --- results/classifier/118/device/2336 | 53 ----- results/classifier/118/device/2348 | 37 ---- results/classifier/118/device/2351 | 45 ----- results/classifier/118/device/2357 | 48 ----- results/classifier/118/device/2362 | 93 --------- results/classifier/118/device/2370 | 41 ---- results/classifier/118/device/240 | 31 --- results/classifier/118/device/2406 | 37 ---- results/classifier/118/device/2416 | 69 ------- results/classifier/118/device/243 | 31 --- results/classifier/118/device/2438 | 31 --- results/classifier/118/device/2443 | 48 ----- results/classifier/118/device/2454 | 38 ---- results/classifier/118/device/2465 | 31 --- results/classifier/118/device/2468 | 63 ------ results/classifier/118/device/2471 | 31 --- results/classifier/118/device/2475 | 31 --- results/classifier/118/device/2477 | 31 --- results/classifier/118/device/248 | 31 --- results/classifier/118/device/2480 | 59 ------ results/classifier/118/device/2508 | 31 --- results/classifier/118/device/251 | 31 --- results/classifier/118/device/2516 | 31 --- results/classifier/118/device/2533 | 31 --- results/classifier/118/device/2535 | 31 --- results/classifier/118/device/2539 | 31 --- results/classifier/118/device/254 | 31 --- results/classifier/118/device/2544 | 31 --- results/classifier/118/device/2547 | 33 --- results/classifier/118/device/259 | 31 --- results/classifier/118/device/261 | 31 --- results/classifier/118/device/2615 | 40 ---- results/classifier/118/device/262 | 31 --- results/classifier/118/device/2636 | 31 --- results/classifier/118/device/2640 | 31 --- results/classifier/118/device/2653 | 31 --- results/classifier/118/device/2654 | 44 ---- results/classifier/118/device/2659 | 31 --- results/classifier/118/device/2663 | 37 ---- results/classifier/118/device/2664 | 39 ---- results/classifier/118/device/2666 | 52 ----- results/classifier/118/device/2679 | 31 --- results/classifier/118/device/2681 | 31 --- results/classifier/118/device/269 | 31 --- results/classifier/118/device/2693 | 36 ---- results/classifier/118/device/2695 | 33 --- results/classifier/118/device/2696 | 42 ---- results/classifier/118/device/2698 | 39 ---- results/classifier/118/device/2700 | 38 ---- results/classifier/118/device/2703 | 70 ------- results/classifier/118/device/2707 | 40 ---- results/classifier/118/device/2711 | 31 --- results/classifier/118/device/2714 | 37 ---- results/classifier/118/device/2716 | 37 ---- results/classifier/118/device/2724 | 38 ---- results/classifier/118/device/2726 | 31 --- results/classifier/118/device/273 | 31 --- results/classifier/118/device/2733 | 42 ---- results/classifier/118/device/2734 | 54 ----- results/classifier/118/device/2735 | 40 ---- results/classifier/118/device/2743 | 33 --- results/classifier/118/device/2752 | 307 ---------------------------- results/classifier/118/device/2765 | 31 --- results/classifier/118/device/2777 | 89 --------- results/classifier/118/device/2796 | 37 ---- results/classifier/118/device/2801 | 31 --- results/classifier/118/device/2804 | 31 --- results/classifier/118/device/2805 | 52 ----- results/classifier/118/device/2812 | 31 --- results/classifier/118/device/283 | 31 --- results/classifier/118/device/2831 | 50 ----- results/classifier/118/device/2841 | 41 ---- results/classifier/118/device/2846 | 31 --- results/classifier/118/device/2847 | 31 --- results/classifier/118/device/2858 | 31 --- results/classifier/118/device/2859 | 31 --- results/classifier/118/device/2869 | 33 --- results/classifier/118/device/2881 | 40 ---- results/classifier/118/device/2885 | 31 --- results/classifier/118/device/2886 | 45 ----- results/classifier/118/device/289 | 31 --- results/classifier/118/device/2893 | 42 ---- results/classifier/118/device/290 | 31 --- results/classifier/118/device/2902 | 41 ---- results/classifier/118/device/2904 | 41 ---- results/classifier/118/device/2905 | 54 ----- results/classifier/118/device/2907 | 31 --- results/classifier/118/device/2912 | 43 ---- results/classifier/118/device/2918 | 31 --- results/classifier/118/device/2919 | 43 ---- results/classifier/118/device/2923 | 43 ---- results/classifier/118/device/2929 | 37 ---- results/classifier/118/device/293 | 31 --- results/classifier/118/device/2930 | 31 --- results/classifier/118/device/2939 | 31 --- results/classifier/118/device/2940 | 31 --- results/classifier/118/device/2941 | 31 --- results/classifier/118/device/2955 | 31 --- results/classifier/118/device/296 | 31 --- results/classifier/118/device/2968 | 52 ----- results/classifier/118/device/305 | 31 --- results/classifier/118/device/307 | 31 --- results/classifier/118/device/318 | 31 --- results/classifier/118/device/319 | 31 --- results/classifier/118/device/320 | 31 --- results/classifier/118/device/322 | 31 --- results/classifier/118/device/325 | 31 --- results/classifier/118/device/328 | 31 --- results/classifier/118/device/329 | 31 --- results/classifier/118/device/331 | 31 --- results/classifier/118/device/334 | 31 --- results/classifier/118/device/338 | 31 --- results/classifier/118/device/340 | 31 --- results/classifier/118/device/346 | 31 --- results/classifier/118/device/349 | 31 --- results/classifier/118/device/357 | 31 --- results/classifier/118/device/380 | 31 --- results/classifier/118/device/383 | 31 --- results/classifier/118/device/386 | 31 --- results/classifier/118/device/399 | 31 --- results/classifier/118/device/402 | 31 --- results/classifier/118/device/405 | 31 --- results/classifier/118/device/406 | 31 --- results/classifier/118/device/410 | 31 --- results/classifier/118/device/422 | 31 --- results/classifier/118/device/423 | 31 --- results/classifier/118/device/429 | 31 --- results/classifier/118/device/431 | 31 --- results/classifier/118/device/437 | 31 --- results/classifier/118/device/441 | 31 --- results/classifier/118/device/448 | 31 --- results/classifier/118/device/46 | 31 --- results/classifier/118/device/461 | 31 --- results/classifier/118/device/464 | 31 --- results/classifier/118/device/468 | 31 --- results/classifier/118/device/469 | 31 --- results/classifier/118/device/479 | 42 ---- results/classifier/118/device/48 | 31 --- results/classifier/118/device/481 | 31 --- results/classifier/118/device/482 | 31 --- results/classifier/118/device/487 | 31 --- results/classifier/118/device/49 | 31 --- results/classifier/118/device/501 | 31 --- results/classifier/118/device/502 | 31 --- results/classifier/118/device/503 | 31 --- results/classifier/118/device/506 | 31 --- results/classifier/118/device/51 | 31 --- results/classifier/118/device/511 | 31 --- results/classifier/118/device/513 | 31 --- results/classifier/118/device/518 | 31 --- results/classifier/118/device/529 | 34 ---- results/classifier/118/device/535 | 31 --- results/classifier/118/device/537 | 31 --- results/classifier/118/device/538 | 31 --- results/classifier/118/device/54 | 31 --- results/classifier/118/device/540 | 31 --- results/classifier/118/device/542 | 31 --- results/classifier/118/device/55 | 31 --- results/classifier/118/device/554 | 31 --- results/classifier/118/device/558 | 87 -------- results/classifier/118/device/560 | 31 --- results/classifier/118/device/565 | 31 --- results/classifier/118/device/567 | 31 --- results/classifier/118/device/57 | 31 --- results/classifier/118/device/571 | 31 --- results/classifier/118/device/573 | 31 --- results/classifier/118/device/586 | 31 --- results/classifier/118/device/588693 | 41 ---- results/classifier/118/device/590 | 31 --- results/classifier/118/device/604 | 31 --- results/classifier/118/device/608 | 31 --- results/classifier/118/device/617 | 56 ------ results/classifier/118/device/623852 | 353 --------------------------------- results/classifier/118/device/628082 | 46 ----- results/classifier/118/device/63 | 31 --- results/classifier/118/device/635 | 58 ------ results/classifier/118/device/63565653 | 74 ------- results/classifier/118/device/637 | 34 ---- results/classifier/118/device/64 | 31 --- results/classifier/118/device/644 | 39 ---- results/classifier/118/device/646 | 48 ----- results/classifier/118/device/648 | 31 --- results/classifier/118/device/650 | 54 ----- results/classifier/118/device/66 | 31 --- results/classifier/118/device/663 | 41 ---- results/classifier/118/device/666 | 37 ---- results/classifier/118/device/667 | 31 --- results/classifier/118/device/667791 | 74 ------- results/classifier/118/device/678 | 77 ------- results/classifier/118/device/68 | 31 --- results/classifier/118/device/684 | 31 --- results/classifier/118/device/69 | 31 --- results/classifier/118/device/699 | 31 --- results/classifier/118/device/700 | 31 --- results/classifier/118/device/71 | 31 --- results/classifier/118/device/723460 | 85 -------- results/classifier/118/device/74 | 31 --- results/classifier/118/device/743 | 41 ---- results/classifier/118/device/749 | 31 --- results/classifier/118/device/75 | 31 --- results/classifier/118/device/757 | 31 --- results/classifier/118/device/76 | 31 --- results/classifier/118/device/767 | 33 --- results/classifier/118/device/770 | 31 --- results/classifier/118/device/775 | 34 ---- results/classifier/118/device/782 | 35 ---- results/classifier/118/device/784 | 43 ---- results/classifier/118/device/785 | 31 --- results/classifier/118/device/786208 | 45 ----- results/classifier/118/device/786209 | 45 ----- results/classifier/118/device/788 | 31 --- results/classifier/118/device/79 | 31 --- results/classifier/118/device/791 | 31 --- results/classifier/118/device/795 | 31 --- results/classifier/118/device/796 | 47 ----- results/classifier/118/device/801 | 42 ---- results/classifier/118/device/804 | 39 ---- results/classifier/118/device/805 | 44 ---- results/classifier/118/device/808 | 48 ----- results/classifier/118/device/832 | 43 ---- results/classifier/118/device/837 | 60 ------ results/classifier/118/device/84 | 31 --- results/classifier/118/device/842290 | 47 ----- results/classifier/118/device/843 | 33 --- results/classifier/118/device/873 | 31 --- results/classifier/118/device/873460 | 62 ------ results/classifier/118/device/877498 | 92 --------- results/classifier/118/device/879 | 33 --- results/classifier/118/device/887 | 31 --- results/classifier/118/device/889 | 31 --- results/classifier/118/device/896 | 31 --- results/classifier/118/device/897 | 31 --- results/classifier/118/device/902 | 31 --- results/classifier/118/device/91 | 31 --- results/classifier/118/device/924 | 31 --- results/classifier/118/device/94 | 31 --- results/classifier/118/device/942 | 31 --- results/classifier/118/device/96 | 31 --- results/classifier/118/device/972 | 31 --- results/classifier/118/device/975 | 68 ------- results/classifier/118/device/977 | 31 --- results/classifier/118/device/978 | 31 --- results/classifier/118/device/985288 | 40 ---- results/classifier/118/device/989504 | 58 ------ results/classifier/118/device/991 | 36 ---- results/classifier/118/device/994 | 35 ---- 533 files changed, 22586 deletions(-) delete mode 100644 results/classifier/118/device/1014 delete mode 100644 results/classifier/118/device/1016 delete mode 100644 results/classifier/118/device/1017793 delete mode 100644 results/classifier/118/device/1021 delete mode 100644 results/classifier/118/device/1024 delete mode 100644 results/classifier/118/device/1033 delete mode 100644 results/classifier/118/device/1034980 delete mode 100644 results/classifier/118/device/1038070 delete mode 100644 results/classifier/118/device/1049 delete mode 100644 results/classifier/118/device/1050823 delete mode 100644 results/classifier/118/device/107 delete mode 100644 results/classifier/118/device/1072 delete mode 100644 results/classifier/118/device/1077 delete mode 100644 results/classifier/118/device/1080 delete mode 100644 results/classifier/118/device/1083 delete mode 100644 results/classifier/118/device/1088 delete mode 100644 results/classifier/118/device/1090558 delete mode 100644 results/classifier/118/device/1090602 delete mode 100644 results/classifier/118/device/1103903 delete mode 100644 results/classifier/118/device/1106 delete mode 100644 results/classifier/118/device/1108 delete mode 100644 results/classifier/118/device/112 delete mode 100644 results/classifier/118/device/1124 delete mode 100644 results/classifier/118/device/1133 delete mode 100644 results/classifier/118/device/1134 delete mode 100644 results/classifier/118/device/1140 delete mode 100644 results/classifier/118/device/1142 delete mode 100644 results/classifier/118/device/115 delete mode 100644 results/classifier/118/device/1155677 delete mode 100644 results/classifier/118/device/116 delete mode 100644 results/classifier/118/device/117 delete mode 100644 results/classifier/118/device/1171 delete mode 100644 results/classifier/118/device/118 delete mode 100644 results/classifier/118/device/1181354 delete mode 100644 results/classifier/118/device/1187 delete mode 100644 results/classifier/118/device/1187529 delete mode 100644 results/classifier/118/device/119 delete mode 100644 results/classifier/118/device/1191 delete mode 100644 results/classifier/118/device/1196 delete mode 100644 results/classifier/118/device/1198350 delete mode 100644 results/classifier/118/device/1208 delete mode 100644 results/classifier/118/device/1210 delete mode 100644 results/classifier/118/device/1211 delete mode 100644 results/classifier/118/device/1221 delete mode 100644 results/classifier/118/device/1225 delete mode 100644 results/classifier/118/device/1226 delete mode 100644 results/classifier/118/device/1230 delete mode 100644 results/classifier/118/device/1237 delete mode 100644 results/classifier/118/device/1244 delete mode 100644 results/classifier/118/device/1246 delete mode 100644 results/classifier/118/device/1248469 delete mode 100644 results/classifier/118/device/1256826 delete mode 100644 results/classifier/118/device/1262 delete mode 100644 results/classifier/118/device/1266 delete mode 100644 results/classifier/118/device/1273 delete mode 100644 results/classifier/118/device/1275 delete mode 100644 results/classifier/118/device/1280521 delete mode 100644 results/classifier/118/device/1282 delete mode 100644 results/classifier/118/device/1284 delete mode 100644 results/classifier/118/device/1290 delete mode 100644 results/classifier/118/device/1292 delete mode 100644 results/classifier/118/device/1293 delete mode 100644 results/classifier/118/device/1300 delete mode 100644 results/classifier/118/device/1302 delete mode 100644 results/classifier/118/device/1305 delete mode 100644 results/classifier/118/device/131 delete mode 100644 results/classifier/118/device/1315 delete mode 100644 results/classifier/118/device/1318 delete mode 100644 results/classifier/118/device/132 delete mode 100644 results/classifier/118/device/1332234 delete mode 100644 results/classifier/118/device/1334397 delete mode 100644 results/classifier/118/device/1335 delete mode 100644 results/classifier/118/device/1342 delete mode 100644 results/classifier/118/device/1346 delete mode 100644 results/classifier/118/device/1354 delete mode 100644 results/classifier/118/device/1363 delete mode 100644 results/classifier/118/device/1367 delete mode 100644 results/classifier/118/device/1369 delete mode 100644 results/classifier/118/device/137 delete mode 100644 results/classifier/118/device/1377163 delete mode 100644 results/classifier/118/device/1384 delete mode 100644 results/classifier/118/device/1386478 delete mode 100644 results/classifier/118/device/1391 delete mode 100644 results/classifier/118/device/1406 delete mode 100644 results/classifier/118/device/1413 delete mode 100644 results/classifier/118/device/1416 delete mode 100644 results/classifier/118/device/1432 delete mode 100644 results/classifier/118/device/1445633 delete mode 100644 results/classifier/118/device/145 delete mode 100644 results/classifier/118/device/1450 delete mode 100644 results/classifier/118/device/1450891 delete mode 100644 results/classifier/118/device/1453025 delete mode 100644 results/classifier/118/device/1456 delete mode 100644 results/classifier/118/device/1457 delete mode 100644 results/classifier/118/device/1466 delete mode 100644 results/classifier/118/device/1476 delete mode 100644 results/classifier/118/device/1476800 delete mode 100644 results/classifier/118/device/148 delete mode 100644 results/classifier/118/device/1481 delete mode 100644 results/classifier/118/device/1483 delete mode 100644 results/classifier/118/device/1485010 delete mode 100644 results/classifier/118/device/149 delete mode 100644 results/classifier/118/device/1491 delete mode 100644 results/classifier/118/device/150 delete mode 100644 results/classifier/118/device/1502 delete mode 100644 results/classifier/118/device/1507 delete mode 100644 results/classifier/118/device/1512 delete mode 100644 results/classifier/118/device/1513234 delete mode 100644 results/classifier/118/device/1515 delete mode 100644 results/classifier/118/device/1519 delete mode 100644 results/classifier/118/device/1521 delete mode 100644 results/classifier/118/device/1524637 delete mode 100644 results/classifier/118/device/1527 delete mode 100644 results/classifier/118/device/153 delete mode 100644 results/classifier/118/device/1533848 delete mode 100644 results/classifier/118/device/1538 delete mode 100644 results/classifier/118/device/1539 delete mode 100644 results/classifier/118/device/1542 delete mode 100644 results/classifier/118/device/1548471 delete mode 100644 results/classifier/118/device/1553760 delete mode 100644 results/classifier/118/device/1563 delete mode 100644 results/classifier/118/device/1564 delete mode 100644 results/classifier/118/device/1572 delete mode 100644 results/classifier/118/device/1577937 delete mode 100644 results/classifier/118/device/1578 delete mode 100644 results/classifier/118/device/158 delete mode 100644 results/classifier/118/device/1581308 delete mode 100644 results/classifier/118/device/1581976 delete mode 100644 results/classifier/118/device/1582 delete mode 100644 results/classifier/118/device/1590796 delete mode 100644 results/classifier/118/device/1592590 delete mode 100644 results/classifier/118/device/1602 delete mode 100644 results/classifier/118/device/1603785 delete mode 100644 results/classifier/118/device/1610 delete mode 100644 results/classifier/118/device/1616 delete mode 100644 results/classifier/118/device/1622 delete mode 100644 results/classifier/118/device/1635695 delete mode 100644 results/classifier/118/device/1643 delete mode 100644 results/classifier/118/device/1651 delete mode 100644 results/classifier/118/device/1655 delete mode 100644 results/classifier/118/device/1656710 delete mode 100644 results/classifier/118/device/1660035 delete mode 100644 results/classifier/118/device/1661 delete mode 100644 results/classifier/118/device/1663 delete mode 100644 results/classifier/118/device/1665 delete mode 100644 results/classifier/118/device/1672 delete mode 100644 results/classifier/118/device/1675549 delete mode 100644 results/classifier/118/device/1690 delete mode 100644 results/classifier/118/device/1699628 delete mode 100644 results/classifier/118/device/171 delete mode 100644 results/classifier/118/device/1712 delete mode 100644 results/classifier/118/device/1712818 delete mode 100644 results/classifier/118/device/1726733 delete mode 100644 results/classifier/118/device/173 delete mode 100644 results/classifier/118/device/1731347 delete mode 100644 results/classifier/118/device/1732981 delete mode 100644 results/classifier/118/device/1733 delete mode 100644 results/classifier/118/device/1735653 delete mode 100644 results/classifier/118/device/1737882 delete mode 100644 results/classifier/118/device/1738771 delete mode 100644 results/classifier/118/device/174 delete mode 100644 results/classifier/118/device/1744654 delete mode 100644 results/classifier/118/device/1748 delete mode 100644 results/classifier/118/device/1749 delete mode 100644 results/classifier/118/device/175 delete mode 100644 results/classifier/118/device/1754 delete mode 100644 results/classifier/118/device/1754597 delete mode 100644 results/classifier/118/device/1759 delete mode 100644 results/classifier/118/device/1759492 delete mode 100644 results/classifier/118/device/1761 delete mode 100644 results/classifier/118/device/1767 delete mode 100644 results/classifier/118/device/1769 delete mode 100644 results/classifier/118/device/1769067 delete mode 100644 results/classifier/118/device/1773 delete mode 100644 results/classifier/118/device/1776 delete mode 100644 results/classifier/118/device/1777232 delete mode 100644 results/classifier/118/device/1777235 delete mode 100644 results/classifier/118/device/1780815 delete mode 100644 results/classifier/118/device/1793 delete mode 100644 results/classifier/118/device/1794 delete mode 100644 results/classifier/118/device/1794187 delete mode 100644 results/classifier/118/device/1794939 delete mode 100644 results/classifier/118/device/1797 delete mode 100644 results/classifier/118/device/1798 delete mode 100644 results/classifier/118/device/1800088 delete mode 100644 results/classifier/118/device/1805697 delete mode 100644 results/classifier/118/device/181 delete mode 100644 results/classifier/118/device/1811758 delete mode 100644 results/classifier/118/device/1813307 delete mode 100644 results/classifier/118/device/1815445 delete mode 100644 results/classifier/118/device/182 delete mode 100644 results/classifier/118/device/1821131 delete mode 100644 results/classifier/118/device/1821884 delete mode 100644 results/classifier/118/device/1824853 delete mode 100644 results/classifier/118/device/1831477 delete mode 100644 results/classifier/118/device/1839 delete mode 100644 results/classifier/118/device/184 delete mode 100644 results/classifier/118/device/1843 delete mode 100644 results/classifier/118/device/1844644 delete mode 100644 results/classifier/118/device/1847 delete mode 100644 results/classifier/118/device/1853 delete mode 100644 results/classifier/118/device/1853898 delete mode 100644 results/classifier/118/device/1854878 delete mode 100644 results/classifier/118/device/1859 delete mode 100644 results/classifier/118/device/1861458 delete mode 100644 results/classifier/118/device/1864 delete mode 100644 results/classifier/118/device/1866792 delete mode 100644 results/classifier/118/device/187 delete mode 100644 results/classifier/118/device/1871005 delete mode 100644 results/classifier/118/device/1874486 delete mode 100644 results/classifier/118/device/1875080 delete mode 100644 results/classifier/118/device/1880 delete mode 100644 results/classifier/118/device/1882787 delete mode 100644 results/classifier/118/device/1887 delete mode 100644 results/classifier/118/device/1888 delete mode 100644 results/classifier/118/device/1898 delete mode 100644 results/classifier/118/device/1901068 delete mode 100644 results/classifier/118/device/1902262 delete mode 100644 results/classifier/118/device/1902306 delete mode 100644 results/classifier/118/device/1904490 delete mode 100644 results/classifier/118/device/1911188 delete mode 100644 results/classifier/118/device/1922102 delete mode 100644 results/classifier/118/device/1922252 delete mode 100644 results/classifier/118/device/1925094 delete mode 100644 results/classifier/118/device/1926995 delete mode 100644 results/classifier/118/device/1927408 delete mode 100644 results/classifier/118/device/1933 delete mode 100644 results/classifier/118/device/1935 delete mode 100644 results/classifier/118/device/1959 delete mode 100644 results/classifier/118/device/1961 delete mode 100644 results/classifier/118/device/1969 delete mode 100644 results/classifier/118/device/1973 delete mode 100644 results/classifier/118/device/1979 delete mode 100644 results/classifier/118/device/1980 delete mode 100644 results/classifier/118/device/1984 delete mode 100644 results/classifier/118/device/2002 delete mode 100644 results/classifier/118/device/2008 delete mode 100644 results/classifier/118/device/2018 delete mode 100644 results/classifier/118/device/2020 delete mode 100644 results/classifier/118/device/2021 delete mode 100644 results/classifier/118/device/2026 delete mode 100644 results/classifier/118/device/2028 delete mode 100644 results/classifier/118/device/203 delete mode 100644 results/classifier/118/device/2033 delete mode 100644 results/classifier/118/device/2039 delete mode 100644 results/classifier/118/device/204 delete mode 100644 results/classifier/118/device/2044 delete mode 100644 results/classifier/118/device/2048 delete mode 100644 results/classifier/118/device/2049 delete mode 100644 results/classifier/118/device/2055 delete mode 100644 results/classifier/118/device/2067 delete mode 100644 results/classifier/118/device/2086 delete mode 100644 results/classifier/118/device/2087 delete mode 100644 results/classifier/118/device/2091 delete mode 100644 results/classifier/118/device/2093 delete mode 100644 results/classifier/118/device/2122 delete mode 100644 results/classifier/118/device/2125 delete mode 100644 results/classifier/118/device/2132 delete mode 100644 results/classifier/118/device/2156 delete mode 100644 results/classifier/118/device/2158 delete mode 100644 results/classifier/118/device/2161 delete mode 100644 results/classifier/118/device/2164 delete mode 100644 results/classifier/118/device/217 delete mode 100644 results/classifier/118/device/2174 delete mode 100644 results/classifier/118/device/2179 delete mode 100644 results/classifier/118/device/219 delete mode 100644 results/classifier/118/device/2192 delete mode 100644 results/classifier/118/device/220 delete mode 100644 results/classifier/118/device/2201 delete mode 100644 results/classifier/118/device/221 delete mode 100644 results/classifier/118/device/2213 delete mode 100644 results/classifier/118/device/2215 delete mode 100644 results/classifier/118/device/2218 delete mode 100644 results/classifier/118/device/2222 delete mode 100644 results/classifier/118/device/224 delete mode 100644 results/classifier/118/device/2243 delete mode 100644 results/classifier/118/device/225 delete mode 100644 results/classifier/118/device/2268 delete mode 100644 results/classifier/118/device/2275 delete mode 100644 results/classifier/118/device/2282 delete mode 100644 results/classifier/118/device/2285 delete mode 100644 results/classifier/118/device/2306 delete mode 100644 results/classifier/118/device/2314 delete mode 100644 results/classifier/118/device/2317 delete mode 100644 results/classifier/118/device/232 delete mode 100644 results/classifier/118/device/2329 delete mode 100644 results/classifier/118/device/233 delete mode 100644 results/classifier/118/device/2336 delete mode 100644 results/classifier/118/device/2348 delete mode 100644 results/classifier/118/device/2351 delete mode 100644 results/classifier/118/device/2357 delete mode 100644 results/classifier/118/device/2362 delete mode 100644 results/classifier/118/device/2370 delete mode 100644 results/classifier/118/device/240 delete mode 100644 results/classifier/118/device/2406 delete mode 100644 results/classifier/118/device/2416 delete mode 100644 results/classifier/118/device/243 delete mode 100644 results/classifier/118/device/2438 delete mode 100644 results/classifier/118/device/2443 delete mode 100644 results/classifier/118/device/2454 delete mode 100644 results/classifier/118/device/2465 delete mode 100644 results/classifier/118/device/2468 delete mode 100644 results/classifier/118/device/2471 delete mode 100644 results/classifier/118/device/2475 delete mode 100644 results/classifier/118/device/2477 delete mode 100644 results/classifier/118/device/248 delete mode 100644 results/classifier/118/device/2480 delete mode 100644 results/classifier/118/device/2508 delete mode 100644 results/classifier/118/device/251 delete mode 100644 results/classifier/118/device/2516 delete mode 100644 results/classifier/118/device/2533 delete mode 100644 results/classifier/118/device/2535 delete mode 100644 results/classifier/118/device/2539 delete mode 100644 results/classifier/118/device/254 delete mode 100644 results/classifier/118/device/2544 delete mode 100644 results/classifier/118/device/2547 delete mode 100644 results/classifier/118/device/259 delete mode 100644 results/classifier/118/device/261 delete mode 100644 results/classifier/118/device/2615 delete mode 100644 results/classifier/118/device/262 delete mode 100644 results/classifier/118/device/2636 delete mode 100644 results/classifier/118/device/2640 delete mode 100644 results/classifier/118/device/2653 delete mode 100644 results/classifier/118/device/2654 delete mode 100644 results/classifier/118/device/2659 delete mode 100644 results/classifier/118/device/2663 delete mode 100644 results/classifier/118/device/2664 delete mode 100644 results/classifier/118/device/2666 delete mode 100644 results/classifier/118/device/2679 delete mode 100644 results/classifier/118/device/2681 delete mode 100644 results/classifier/118/device/269 delete mode 100644 results/classifier/118/device/2693 delete mode 100644 results/classifier/118/device/2695 delete mode 100644 results/classifier/118/device/2696 delete mode 100644 results/classifier/118/device/2698 delete mode 100644 results/classifier/118/device/2700 delete mode 100644 results/classifier/118/device/2703 delete mode 100644 results/classifier/118/device/2707 delete mode 100644 results/classifier/118/device/2711 delete mode 100644 results/classifier/118/device/2714 delete mode 100644 results/classifier/118/device/2716 delete mode 100644 results/classifier/118/device/2724 delete mode 100644 results/classifier/118/device/2726 delete mode 100644 results/classifier/118/device/273 delete mode 100644 results/classifier/118/device/2733 delete mode 100644 results/classifier/118/device/2734 delete mode 100644 results/classifier/118/device/2735 delete mode 100644 results/classifier/118/device/2743 delete mode 100644 results/classifier/118/device/2752 delete mode 100644 results/classifier/118/device/2765 delete mode 100644 results/classifier/118/device/2777 delete mode 100644 results/classifier/118/device/2796 delete mode 100644 results/classifier/118/device/2801 delete mode 100644 results/classifier/118/device/2804 delete mode 100644 results/classifier/118/device/2805 delete mode 100644 results/classifier/118/device/2812 delete mode 100644 results/classifier/118/device/283 delete mode 100644 results/classifier/118/device/2831 delete mode 100644 results/classifier/118/device/2841 delete mode 100644 results/classifier/118/device/2846 delete mode 100644 results/classifier/118/device/2847 delete mode 100644 results/classifier/118/device/2858 delete mode 100644 results/classifier/118/device/2859 delete mode 100644 results/classifier/118/device/2869 delete mode 100644 results/classifier/118/device/2881 delete mode 100644 results/classifier/118/device/2885 delete mode 100644 results/classifier/118/device/2886 delete mode 100644 results/classifier/118/device/289 delete mode 100644 results/classifier/118/device/2893 delete mode 100644 results/classifier/118/device/290 delete mode 100644 results/classifier/118/device/2902 delete mode 100644 results/classifier/118/device/2904 delete mode 100644 results/classifier/118/device/2905 delete mode 100644 results/classifier/118/device/2907 delete mode 100644 results/classifier/118/device/2912 delete mode 100644 results/classifier/118/device/2918 delete mode 100644 results/classifier/118/device/2919 delete mode 100644 results/classifier/118/device/2923 delete mode 100644 results/classifier/118/device/2929 delete mode 100644 results/classifier/118/device/293 delete mode 100644 results/classifier/118/device/2930 delete mode 100644 results/classifier/118/device/2939 delete mode 100644 results/classifier/118/device/2940 delete mode 100644 results/classifier/118/device/2941 delete mode 100644 results/classifier/118/device/2955 delete mode 100644 results/classifier/118/device/296 delete mode 100644 results/classifier/118/device/2968 delete mode 100644 results/classifier/118/device/305 delete mode 100644 results/classifier/118/device/307 delete mode 100644 results/classifier/118/device/318 delete mode 100644 results/classifier/118/device/319 delete mode 100644 results/classifier/118/device/320 delete mode 100644 results/classifier/118/device/322 delete mode 100644 results/classifier/118/device/325 delete mode 100644 results/classifier/118/device/328 delete mode 100644 results/classifier/118/device/329 delete mode 100644 results/classifier/118/device/331 delete mode 100644 results/classifier/118/device/334 delete mode 100644 results/classifier/118/device/338 delete mode 100644 results/classifier/118/device/340 delete mode 100644 results/classifier/118/device/346 delete mode 100644 results/classifier/118/device/349 delete mode 100644 results/classifier/118/device/357 delete mode 100644 results/classifier/118/device/380 delete mode 100644 results/classifier/118/device/383 delete mode 100644 results/classifier/118/device/386 delete mode 100644 results/classifier/118/device/399 delete mode 100644 results/classifier/118/device/402 delete mode 100644 results/classifier/118/device/405 delete mode 100644 results/classifier/118/device/406 delete mode 100644 results/classifier/118/device/410 delete mode 100644 results/classifier/118/device/422 delete mode 100644 results/classifier/118/device/423 delete mode 100644 results/classifier/118/device/429 delete mode 100644 results/classifier/118/device/431 delete mode 100644 results/classifier/118/device/437 delete mode 100644 results/classifier/118/device/441 delete mode 100644 results/classifier/118/device/448 delete mode 100644 results/classifier/118/device/46 delete mode 100644 results/classifier/118/device/461 delete mode 100644 results/classifier/118/device/464 delete mode 100644 results/classifier/118/device/468 delete mode 100644 results/classifier/118/device/469 delete mode 100644 results/classifier/118/device/479 delete mode 100644 results/classifier/118/device/48 delete mode 100644 results/classifier/118/device/481 delete mode 100644 results/classifier/118/device/482 delete mode 100644 results/classifier/118/device/487 delete mode 100644 results/classifier/118/device/49 delete mode 100644 results/classifier/118/device/501 delete mode 100644 results/classifier/118/device/502 delete mode 100644 results/classifier/118/device/503 delete mode 100644 results/classifier/118/device/506 delete mode 100644 results/classifier/118/device/51 delete mode 100644 results/classifier/118/device/511 delete mode 100644 results/classifier/118/device/513 delete mode 100644 results/classifier/118/device/518 delete mode 100644 results/classifier/118/device/529 delete mode 100644 results/classifier/118/device/535 delete mode 100644 results/classifier/118/device/537 delete mode 100644 results/classifier/118/device/538 delete mode 100644 results/classifier/118/device/54 delete mode 100644 results/classifier/118/device/540 delete mode 100644 results/classifier/118/device/542 delete mode 100644 results/classifier/118/device/55 delete mode 100644 results/classifier/118/device/554 delete mode 100644 results/classifier/118/device/558 delete mode 100644 results/classifier/118/device/560 delete mode 100644 results/classifier/118/device/565 delete mode 100644 results/classifier/118/device/567 delete mode 100644 results/classifier/118/device/57 delete mode 100644 results/classifier/118/device/571 delete mode 100644 results/classifier/118/device/573 delete mode 100644 results/classifier/118/device/586 delete mode 100644 results/classifier/118/device/588693 delete mode 100644 results/classifier/118/device/590 delete mode 100644 results/classifier/118/device/604 delete mode 100644 results/classifier/118/device/608 delete mode 100644 results/classifier/118/device/617 delete mode 100644 results/classifier/118/device/623852 delete mode 100644 results/classifier/118/device/628082 delete mode 100644 results/classifier/118/device/63 delete mode 100644 results/classifier/118/device/635 delete mode 100644 results/classifier/118/device/63565653 delete mode 100644 results/classifier/118/device/637 delete mode 100644 results/classifier/118/device/64 delete mode 100644 results/classifier/118/device/644 delete mode 100644 results/classifier/118/device/646 delete mode 100644 results/classifier/118/device/648 delete mode 100644 results/classifier/118/device/650 delete mode 100644 results/classifier/118/device/66 delete mode 100644 results/classifier/118/device/663 delete mode 100644 results/classifier/118/device/666 delete mode 100644 results/classifier/118/device/667 delete mode 100644 results/classifier/118/device/667791 delete mode 100644 results/classifier/118/device/678 delete mode 100644 results/classifier/118/device/68 delete mode 100644 results/classifier/118/device/684 delete mode 100644 results/classifier/118/device/69 delete mode 100644 results/classifier/118/device/699 delete mode 100644 results/classifier/118/device/700 delete mode 100644 results/classifier/118/device/71 delete mode 100644 results/classifier/118/device/723460 delete mode 100644 results/classifier/118/device/74 delete mode 100644 results/classifier/118/device/743 delete mode 100644 results/classifier/118/device/749 delete mode 100644 results/classifier/118/device/75 delete mode 100644 results/classifier/118/device/757 delete mode 100644 results/classifier/118/device/76 delete mode 100644 results/classifier/118/device/767 delete mode 100644 results/classifier/118/device/770 delete mode 100644 results/classifier/118/device/775 delete mode 100644 results/classifier/118/device/782 delete mode 100644 results/classifier/118/device/784 delete mode 100644 results/classifier/118/device/785 delete mode 100644 results/classifier/118/device/786208 delete mode 100644 results/classifier/118/device/786209 delete mode 100644 results/classifier/118/device/788 delete mode 100644 results/classifier/118/device/79 delete mode 100644 results/classifier/118/device/791 delete mode 100644 results/classifier/118/device/795 delete mode 100644 results/classifier/118/device/796 delete mode 100644 results/classifier/118/device/801 delete mode 100644 results/classifier/118/device/804 delete mode 100644 results/classifier/118/device/805 delete mode 100644 results/classifier/118/device/808 delete mode 100644 results/classifier/118/device/832 delete mode 100644 results/classifier/118/device/837 delete mode 100644 results/classifier/118/device/84 delete mode 100644 results/classifier/118/device/842290 delete mode 100644 results/classifier/118/device/843 delete mode 100644 results/classifier/118/device/873 delete mode 100644 results/classifier/118/device/873460 delete mode 100644 results/classifier/118/device/877498 delete mode 100644 results/classifier/118/device/879 delete mode 100644 results/classifier/118/device/887 delete mode 100644 results/classifier/118/device/889 delete mode 100644 results/classifier/118/device/896 delete mode 100644 results/classifier/118/device/897 delete mode 100644 results/classifier/118/device/902 delete mode 100644 results/classifier/118/device/91 delete mode 100644 results/classifier/118/device/924 delete mode 100644 results/classifier/118/device/94 delete mode 100644 results/classifier/118/device/942 delete mode 100644 results/classifier/118/device/96 delete mode 100644 results/classifier/118/device/972 delete mode 100644 results/classifier/118/device/975 delete mode 100644 results/classifier/118/device/977 delete mode 100644 results/classifier/118/device/978 delete mode 100644 results/classifier/118/device/985288 delete mode 100644 results/classifier/118/device/989504 delete mode 100644 results/classifier/118/device/991 delete mode 100644 results/classifier/118/device/994 (limited to 'results/classifier/118/device') diff --git a/results/classifier/118/device/1014 b/results/classifier/118/device/1014 deleted file mode 100644 index a4139805..00000000 --- a/results/classifier/118/device/1014 +++ /dev/null @@ -1,33 +0,0 @@ -device: 0.896 -mistranslation: 0.611 -assembly: 0.575 -arm: 0.560 -network: 0.557 -architecture: 0.508 -semantic: 0.506 -kernel: 0.504 -debug: 0.429 -graphic: 0.400 -hypervisor: 0.356 -peripherals: 0.343 -boot: 0.340 -ppc: 0.277 -i386: 0.235 -TCG: 0.232 -KVM: 0.225 -user-level: 0.213 -PID: 0.211 -risc-v: 0.210 -permissions: 0.205 -x86: 0.185 -performance: 0.182 -VMM: 0.179 -socket: 0.157 -vnc: 0.138 -virtual: 0.122 -register: 0.099 -files: 0.013 - -Make -chardev, -serial and others accept stderr like they accept stdio -Additional information: -It's not clear what should happen when the guest tries to read from (instead of write to) the character device. On the other hand, I don't think the specific behavior matters very much. diff --git a/results/classifier/118/device/1016 b/results/classifier/118/device/1016 deleted file mode 100644 index b746531b..00000000 --- a/results/classifier/118/device/1016 +++ /dev/null @@ -1,33 +0,0 @@ -device: 0.830 -assembly: 0.790 -architecture: 0.670 -network: 0.592 -arm: 0.515 -graphic: 0.447 -semantic: 0.337 -socket: 0.296 -performance: 0.295 -virtual: 0.279 -register: 0.277 -ppc: 0.237 -boot: 0.232 -vnc: 0.164 -risc-v: 0.146 -mistranslation: 0.123 -debug: 0.091 -permissions: 0.087 -hypervisor: 0.070 -VMM: 0.069 -PID: 0.063 -i386: 0.063 -kernel: 0.062 -TCG: 0.044 -x86: 0.027 -files: 0.020 -user-level: 0.013 -peripherals: 0.012 -KVM: 0.002 - -In-process sandboxing of the majority of QEMU via WebAssembly or similar -Additional information: -This would be in addition to other sandboxes, such as sVirt. diff --git a/results/classifier/118/device/1017793 b/results/classifier/118/device/1017793 deleted file mode 100644 index 35509814..00000000 --- a/results/classifier/118/device/1017793 +++ /dev/null @@ -1,38 +0,0 @@ -device: 0.816 -graphic: 0.787 -architecture: 0.759 -semantic: 0.650 -mistranslation: 0.574 -risc-v: 0.569 -socket: 0.556 -network: 0.533 -peripherals: 0.506 -vnc: 0.477 -performance: 0.454 -register: 0.426 -PID: 0.381 -kernel: 0.378 -permissions: 0.364 -debug: 0.336 -boot: 0.333 -hypervisor: 0.326 -virtual: 0.326 -user-level: 0.304 -arm: 0.278 -ppc: 0.269 -files: 0.246 -TCG: 0.226 -VMM: 0.224 -assembly: 0.205 -KVM: 0.027 -x86: 0.020 -i386: 0.008 - -S3 Trio64V+ support - -Is it possible to add S3 Trio emulation to QEMU at all? Since 0.12.3 the Cirrus Logic seems no longer working properly (bad font render/corrupted video). Also, S3 is a widely supported device on many OSes and architectures, which will give more compatibility for QEMU. - -Thanks! - -Sorry, seems like nobody got interested in adding S3 emulation to QEMU within the last 6 years, so this is very unlikely going to happen. Thus I'm closing this bug ticket now. - diff --git a/results/classifier/118/device/1021 b/results/classifier/118/device/1021 deleted file mode 100644 index 5d6b4920..00000000 --- a/results/classifier/118/device/1021 +++ /dev/null @@ -1,39 +0,0 @@ -device: 0.874 -KVM: 0.687 -boot: 0.657 -debug: 0.651 -architecture: 0.638 -graphic: 0.508 -vnc: 0.503 -socket: 0.493 -network: 0.470 -performance: 0.445 -register: 0.443 -risc-v: 0.421 -hypervisor: 0.392 -virtual: 0.348 -kernel: 0.335 -peripherals: 0.322 -x86: 0.318 -i386: 0.307 -arm: 0.304 -ppc: 0.300 -permissions: 0.271 -semantic: 0.269 -TCG: 0.263 -PID: 0.238 -VMM: 0.146 -files: 0.104 -mistranslation: 0.100 -user-level: 0.067 -assembly: 0.062 - -nVMX: QEMU does not clear nVMX state through KVM(L0) when guest(L2) trigger a reboot event through I/O-Port(0xCF9) -Description of problem: -# -Steps to reproduce: -Guest(L2) write 0xCF9 to trigger a platform reboot. - -# -Additional information: - diff --git a/results/classifier/118/device/1024 b/results/classifier/118/device/1024 deleted file mode 100644 index bdff3e3c..00000000 --- a/results/classifier/118/device/1024 +++ /dev/null @@ -1,40 +0,0 @@ -device: 0.935 -graphic: 0.916 -architecture: 0.846 -files: 0.778 -register: 0.728 -debug: 0.726 -performance: 0.710 -network: 0.704 -PID: 0.695 -socket: 0.692 -vnc: 0.671 -boot: 0.627 -semantic: 0.626 -kernel: 0.602 -mistranslation: 0.540 -risc-v: 0.533 -permissions: 0.529 -ppc: 0.469 -user-level: 0.447 -arm: 0.446 -peripherals: 0.437 -TCG: 0.367 -VMM: 0.351 -assembly: 0.348 -hypervisor: 0.255 -i386: 0.148 -virtual: 0.117 -x86: 0.103 -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/118/device/1033 b/results/classifier/118/device/1033 deleted file mode 100644 index 96229de6..00000000 --- a/results/classifier/118/device/1033 +++ /dev/null @@ -1,57 +0,0 @@ -architecture: 0.972 -device: 0.962 -graphic: 0.936 -semantic: 0.894 -debug: 0.835 -PID: 0.807 -arm: 0.780 -ppc: 0.765 -user-level: 0.689 -performance: 0.681 -peripherals: 0.616 -register: 0.604 -network: 0.590 -risc-v: 0.568 -kernel: 0.515 -files: 0.492 -mistranslation: 0.449 -vnc: 0.435 -hypervisor: 0.423 -permissions: 0.410 -socket: 0.386 -VMM: 0.298 -virtual: 0.294 -i386: 0.246 -x86: 0.205 -boot: 0.199 -TCG: 0.186 -assembly: 0.138 -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 -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/118/device/1034980 b/results/classifier/118/device/1034980 deleted file mode 100644 index a972fdeb..00000000 --- a/results/classifier/118/device/1034980 +++ /dev/null @@ -1,52 +0,0 @@ -device: 0.923 -graphic: 0.892 -ppc: 0.891 -architecture: 0.839 -peripherals: 0.825 -register: 0.804 -socket: 0.802 -PID: 0.770 -performance: 0.754 -network: 0.727 -vnc: 0.701 -permissions: 0.649 -mistranslation: 0.641 -files: 0.577 -risc-v: 0.566 -semantic: 0.564 -boot: 0.551 -arm: 0.517 -kernel: 0.500 -VMM: 0.473 -debug: 0.472 -virtual: 0.424 -hypervisor: 0.398 -user-level: 0.386 -TCG: 0.313 -i386: 0.182 -KVM: 0.142 -assembly: 0.118 -x86: 0.074 - -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/118/device/1038070 b/results/classifier/118/device/1038070 deleted file mode 100644 index 8f364fcb..00000000 --- a/results/classifier/118/device/1038070 +++ /dev/null @@ -1,149 +0,0 @@ -arm: 0.935 -device: 0.932 -permissions: 0.929 -assembly: 0.927 -PID: 0.920 -semantic: 0.920 -register: 0.915 -risc-v: 0.910 -architecture: 0.899 -performance: 0.898 -KVM: 0.897 -graphic: 0.896 -hypervisor: 0.890 -mistranslation: 0.883 -user-level: 0.880 -debug: 0.872 -ppc: 0.864 -VMM: 0.858 -virtual: 0.851 -x86: 0.849 -boot: 0.848 -vnc: 0.844 -files: 0.844 -kernel: 0.837 -TCG: 0.827 -network: 0.825 -socket: 0.824 -peripherals: 0.817 -i386: 0.635 - -> qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore - -Linux Distro: Gentoo - -Smartcard Activkey doesn't work anymore. I use it without problem till version -qemu-kvm-1.0.1. - -Follow a log extraction: -2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : -internal error Process exited while reading console log output: char device -redirected to /dev/pts/40 -ccid-card-emulated: failed to initialize vcard -qemu-system-x86_64: -device -ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device -'ccid-card-emulated' could not be initialized - -2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : -internal error Process exited while reading console log output: char device -redirected to /dev/pts/40 -ccid-card-emulated: failed to initialize vcard -qemu-system-x86_64: -device -ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device -'ccid-card-emulated' could not be initialized - -If you need any other info please tell me. - -I've tried with git version with same problem. - -On Fri, Aug 17, 2012 at 12:50:14PM -0000, linuxale wrote: -> Public bug reported: -> -> Linux Distro: Gentoo -> -> Smartcard Activkey doesn't work anymore. I use it without problem till version -> qemu-kvm-1.0.1. -> -> Follow a log extraction: -> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : -> internal error Process exited while reading console log output: char device -> redirected to /dev/pts/40 -> ccid-card-emulated: failed to initialize vcard -> qemu-system-x86_64: -device -> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device -> 'ccid-card-emulated' could not be initialized -> -> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : -> internal error Process exited while reading console log output: char device -> redirected to /dev/pts/40 -> ccid-card-emulated: failed to initialize vcard -> qemu-system-x86_64: -device -> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device -> 'ccid-card-emulated' could not be initialized -> -> If you need any other info please tell me. - -I've tried 1.1.1 and current upstream with a Windows 7 guest and the -device seems to show up and function properly in both cases. - -One way that I *can* reproduce the error is by running your command-line -with an NSS database at some place other than the default search path -(/etc/pki/nssdb in 1.1 and upstream). I don't think this has changed -since 1.0, but maybe something changed on the distro side? - -Can you try reproducing by compiling from upstream source? - -> -> I've tried with git version with same problem. -> -> ** Affects: qemu -> Importance: Undecided -> Status: New -> -> -- -> You received this bug notification because you are a member of qemu- -> devel-ml, which is subscribed to QEMU. -> https://bugs.launchpad.net/bugs/1038070 -> -> Title: -> > qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore -> -> Status in QEMU: -> New -> -> Bug description: -> Linux Distro: Gentoo -> -> Smartcard Activkey doesn't work anymore. I use it without problem till version -> qemu-kvm-1.0.1. -> -> Follow a log extraction: -> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 : -> internal error Process exited while reading console log output: char device -> redirected to /dev/pts/40 -> ccid-card-emulated: failed to initialize vcard -> qemu-system-x86_64: -device -> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device -> 'ccid-card-emulated' could not be initialized -> -> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 : -> internal error Process exited while reading console log output: char device -> redirected to /dev/pts/40 -> ccid-card-emulated: failed to initialize vcard -> qemu-system-x86_64: -device -> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device -> 'ccid-card-emulated' could not be initialized -> -> If you need any other info please tell me. -> -> I've tried with git version with same problem. -> -> To manage notifications about this bug go to: -> https://bugs.launchpad.net/qemu/+bug/1038070/+subscriptions -> - - -Have you ever tried to reproduce this with the upstream QEMU version? - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/118/device/1049 b/results/classifier/118/device/1049 deleted file mode 100644 index 5d6d320e..00000000 --- a/results/classifier/118/device/1049 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.915 -performance: 0.695 -VMM: 0.535 -vnc: 0.531 -architecture: 0.524 -TCG: 0.521 -risc-v: 0.464 -network: 0.448 -PID: 0.443 -arm: 0.387 -i386: 0.380 -ppc: 0.377 -KVM: 0.350 -mistranslation: 0.325 -x86: 0.318 -peripherals: 0.298 -socket: 0.288 -graphic: 0.286 -hypervisor: 0.273 -debug: 0.237 -virtual: 0.236 -semantic: 0.224 -assembly: 0.210 -boot: 0.197 -permissions: 0.184 -user-level: 0.158 -register: 0.143 -kernel: 0.130 -files: 0.117 - -Have DeviceRealize return boolean indicating error diff --git a/results/classifier/118/device/1050823 b/results/classifier/118/device/1050823 deleted file mode 100644 index ad1f6767..00000000 --- a/results/classifier/118/device/1050823 +++ /dev/null @@ -1,52 +0,0 @@ -device: 0.952 -network: 0.934 -ppc: 0.900 -socket: 0.885 -graphic: 0.821 -peripherals: 0.786 -vnc: 0.779 -PID: 0.766 -debug: 0.700 -semantic: 0.680 -register: 0.651 -kernel: 0.631 -files: 0.630 -KVM: 0.614 -architecture: 0.613 -boot: 0.570 -performance: 0.528 -arm: 0.494 -mistranslation: 0.484 -user-level: 0.438 -risc-v: 0.425 -permissions: 0.369 -TCG: 0.348 -VMM: 0.348 -i386: 0.338 -x86: 0.316 -hypervisor: 0.218 -virtual: 0.198 -assembly: 0.103 - -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/118/device/107 b/results/classifier/118/device/107 deleted file mode 100644 index 7a82b3fd..00000000 --- a/results/classifier/118/device/107 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.845 -graphic: 0.747 -performance: 0.596 -virtual: 0.485 -network: 0.435 -hypervisor: 0.416 -VMM: 0.394 -architecture: 0.369 -mistranslation: 0.368 -debug: 0.333 -semantic: 0.297 -vnc: 0.261 -permissions: 0.248 -register: 0.222 -i386: 0.199 -ppc: 0.197 -user-level: 0.153 -arm: 0.143 -PID: 0.142 -x86: 0.138 -boot: 0.131 -assembly: 0.113 -TCG: 0.109 -files: 0.109 -kernel: 0.095 -risc-v: 0.076 -socket: 0.057 -peripherals: 0.029 -KVM: 0.013 - -qemu-img fixed vhd issues diff --git a/results/classifier/118/device/1072 b/results/classifier/118/device/1072 deleted file mode 100644 index 5e99353c..00000000 --- a/results/classifier/118/device/1072 +++ /dev/null @@ -1,54 +0,0 @@ -device: 0.903 -graphic: 0.836 -performance: 0.834 -architecture: 0.826 -debug: 0.813 -files: 0.775 -PID: 0.659 -kernel: 0.655 -network: 0.650 -socket: 0.634 -semantic: 0.634 -arm: 0.630 -register: 0.625 -x86: 0.595 -peripherals: 0.589 -permissions: 0.575 -vnc: 0.572 -hypervisor: 0.559 -ppc: 0.553 -i386: 0.489 -TCG: 0.479 -risc-v: 0.471 -user-level: 0.449 -VMM: 0.419 -virtual: 0.339 -boot: 0.328 -KVM: 0.313 -mistranslation: 0.301 -assembly: 0.207 - -different behavior when remote debugger is used -Description of problem: -I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: - -1. Is this intended behavior? -1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) -1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. - -The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) -The preprocessed code is as follows: - if (((((st.st_mode)) & 0170000) == (0020000))) - -I then compared two different approaches to run Qemu: - -1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR -1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). - -Thanks! -Steps to reproduce: -1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) -2. -3. -Additional information: - diff --git a/results/classifier/118/device/1077 b/results/classifier/118/device/1077 deleted file mode 100644 index ba21bdab..00000000 --- a/results/classifier/118/device/1077 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.948 -network: 0.890 -performance: 0.843 -hypervisor: 0.841 -architecture: 0.757 -debug: 0.568 -graphic: 0.534 -virtual: 0.523 -register: 0.521 -semantic: 0.430 -arm: 0.410 -socket: 0.380 -files: 0.353 -peripherals: 0.349 -vnc: 0.340 -permissions: 0.307 -boot: 0.293 -mistranslation: 0.290 -user-level: 0.284 -risc-v: 0.255 -ppc: 0.254 -PID: 0.233 -assembly: 0.183 -kernel: 0.059 -i386: 0.054 -TCG: 0.052 -VMM: 0.041 -x86: 0.016 -KVM: 0.006 - -Qemu - Can't connect to ESXi guest diff --git a/results/classifier/118/device/1080 b/results/classifier/118/device/1080 deleted file mode 100644 index 602c46b1..00000000 --- a/results/classifier/118/device/1080 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.827 -performance: 0.642 -user-level: 0.519 -graphic: 0.475 -architecture: 0.473 -network: 0.454 -semantic: 0.445 -arm: 0.374 -peripherals: 0.330 -PID: 0.318 -ppc: 0.307 -permissions: 0.300 -register: 0.269 -hypervisor: 0.248 -debug: 0.248 -files: 0.244 -kernel: 0.241 -mistranslation: 0.240 -virtual: 0.209 -risc-v: 0.155 -vnc: 0.148 -i386: 0.125 -boot: 0.109 -assembly: 0.103 -TCG: 0.096 -socket: 0.088 -x86: 0.082 -VMM: 0.035 -KVM: 0.002 - -Qemu build fails on Ubuntu diff --git a/results/classifier/118/device/1083 b/results/classifier/118/device/1083 deleted file mode 100644 index 6133eac6..00000000 --- a/results/classifier/118/device/1083 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.881 -architecture: 0.843 -performance: 0.587 -semantic: 0.496 -virtual: 0.463 -mistranslation: 0.431 -graphic: 0.358 -register: 0.355 -boot: 0.311 -arm: 0.279 -kernel: 0.215 -ppc: 0.194 -network: 0.182 -PID: 0.181 -permissions: 0.137 -user-level: 0.122 -files: 0.117 -assembly: 0.107 -debug: 0.101 -vnc: 0.094 -socket: 0.089 -risc-v: 0.077 -x86: 0.076 -hypervisor: 0.068 -VMM: 0.019 -i386: 0.018 -peripherals: 0.010 -TCG: 0.008 -KVM: 0.002 - -Qemu on Windows - Emulate 64Bit CPU diff --git a/results/classifier/118/device/1088 b/results/classifier/118/device/1088 deleted file mode 100644 index 98489a51..00000000 --- a/results/classifier/118/device/1088 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.820 -network: 0.813 -architecture: 0.770 -socket: 0.690 -arm: 0.630 -performance: 0.615 -peripherals: 0.532 -files: 0.518 -boot: 0.486 -debug: 0.475 -vnc: 0.470 -hypervisor: 0.452 -PID: 0.437 -graphic: 0.410 -register: 0.405 -permissions: 0.401 -kernel: 0.397 -risc-v: 0.361 -ppc: 0.348 -VMM: 0.290 -semantic: 0.286 -TCG: 0.263 -assembly: 0.227 -x86: 0.218 -i386: 0.207 -virtual: 0.189 -user-level: 0.129 -mistranslation: 0.083 -KVM: 0.007 - -QEMU 7.0.0 fails to build with linker that does not support --dynamic-list diff --git a/results/classifier/118/device/1090558 b/results/classifier/118/device/1090558 deleted file mode 100644 index 1b3b989e..00000000 --- a/results/classifier/118/device/1090558 +++ /dev/null @@ -1,44 +0,0 @@ -device: 0.815 -socket: 0.807 -vnc: 0.780 -network: 0.752 -ppc: 0.731 -architecture: 0.685 -register: 0.683 -kernel: 0.676 -graphic: 0.670 -arm: 0.666 -risc-v: 0.587 -files: 0.568 -boot: 0.509 -semantic: 0.472 -mistranslation: 0.455 -debug: 0.452 -TCG: 0.421 -performance: 0.408 -i386: 0.389 -x86: 0.365 -PID: 0.327 -permissions: 0.309 -user-level: 0.297 -VMM: 0.247 -assembly: 0.205 -virtual: 0.194 -peripherals: 0.192 -hypervisor: 0.156 -KVM: 0.026 - -hw/mc146818: error reading RTC_HOURS_ALARM - -get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly. - -- Bit 7 must be masked before conversion from BCD. -- Care must be taken to check the don't care condition before masking. -- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done in convert_hour()). - -Seen in commit e376a788ae130454ad5e797f60cb70d0308babb6. - -The problem is obviously there, but I tried pretty hard to make it fail and couldn't so it seems latent. If you can, please provide a patch to tests/rtc-test.c that shows the bug. - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/118/device/1090602 b/results/classifier/118/device/1090602 deleted file mode 100644 index 5c239beb..00000000 --- a/results/classifier/118/device/1090602 +++ /dev/null @@ -1,48 +0,0 @@ -device: 0.919 -graphic: 0.780 -network: 0.658 -socket: 0.637 -files: 0.623 -semantic: 0.617 -register: 0.605 -permissions: 0.594 -mistranslation: 0.589 -architecture: 0.564 -performance: 0.556 -risc-v: 0.553 -vnc: 0.549 -debug: 0.525 -peripherals: 0.525 -i386: 0.523 -PID: 0.505 -VMM: 0.489 -ppc: 0.485 -x86: 0.473 -hypervisor: 0.467 -kernel: 0.439 -boot: 0.430 -user-level: 0.427 -arm: 0.409 -KVM: 0.408 -TCG: 0.385 -assembly: 0.374 -virtual: 0.286 - -RFE: Allow specifying usb-host device by serial number - -Currently you can pass through a host USB device to the guest like - - -device usb-host,vendorid=0x1234,productid=0x5678 - -Which is all well and good, but has problems if you are trying to assign to identical USB devices to the same guest. - -It would be useful if there was an additional option that allow matching against the device's serial number, which should allow differentiating between two devices with the same product+vendor. - -This was originally filed at https://bugzilla.redhat.com/show_bug.cgi?id=640332 - -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/118/device/1103903 b/results/classifier/118/device/1103903 deleted file mode 100644 index 6c567e91..00000000 --- a/results/classifier/118/device/1103903 +++ /dev/null @@ -1,73 +0,0 @@ -device: 0.842 -mistranslation: 0.832 -files: 0.830 -PID: 0.812 -virtual: 0.795 -vnc: 0.742 -kernel: 0.741 -register: 0.701 -socket: 0.701 -performance: 0.692 -network: 0.662 -x86: 0.635 -arm: 0.629 -VMM: 0.626 -ppc: 0.619 -permissions: 0.592 -architecture: 0.588 -hypervisor: 0.583 -semantic: 0.575 -graphic: 0.572 -TCG: 0.514 -i386: 0.514 -peripherals: 0.513 -boot: 0.485 -risc-v: 0.474 -user-level: 0.409 -debug: 0.401 -KVM: 0.378 -assembly: 0.340 - -drive_mirror on a resized image creates file with wrong size - -Repro steps: - -qemu-img create -f qcow2 base 32M -qemu-img create -f qcow2 -o backing_file=base disk -qemu-img resize /home/vishvananda/disk 64M -qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio -QEMU 1.3.0 monitor - type 'help' for more information -(qemu) drive_mirror vda test -Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off - -the file is 32M instead of 64M: - -qemu-img info test -image: test -file format: qcow2 -virtual size: 32M (33554432 bytes) -disk size: 196K -cluster_size: 65536 -backing file: base -backing file format: qcow2 - -Workaround is to precreate the new file of the proper size and pass -n - -qemu-img create -f qcow2 base 32M -qemu-img create -f qcow2 -o backing_file=base disk -qemu-img resize /home/vishvananda/disk 64M -qemu-img create -f qcow2 -o backing_file=base test 64M -qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio -QEMU 1.3.0 monitor - type 'help' for more information -(qemu) drive_mirror vda test -n - - - -reformatted patch and submitted upstream: - -http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg04584.html - -Patch has been included here: -http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8689907266b649b757c220 -... so I think it should be OK to close this bug ticket now. - diff --git a/results/classifier/118/device/1106 b/results/classifier/118/device/1106 deleted file mode 100644 index bc16b672..00000000 --- a/results/classifier/118/device/1106 +++ /dev/null @@ -1,39 +0,0 @@ -device: 0.889 -graphic: 0.884 -peripherals: 0.706 -register: 0.654 -performance: 0.640 -semantic: 0.623 -mistranslation: 0.480 -arm: 0.470 -VMM: 0.434 -architecture: 0.429 -i386: 0.421 -vnc: 0.396 -ppc: 0.395 -x86: 0.392 -TCG: 0.390 -PID: 0.381 -network: 0.372 -risc-v: 0.343 -permissions: 0.308 -debug: 0.296 -socket: 0.287 -KVM: 0.282 -kernel: 0.267 -boot: 0.260 -user-level: 0.218 -files: 0.181 -hypervisor: 0.142 -virtual: 0.141 -assembly: 0.040 - -undefined address access cause failure -Description of problem: -Hi, -I used serial device as below: -qemu/hw/char/serial.c -It defines only support 8 registers address space(offset 0x00-0x32). And in guest os, the hardware is synopsys dw_apb_uart which is compatible with 16550. -when it access low 8 registers, it works ok. but it may access high address(0x8c) which serial.c not defined, then fail occur. - -Is there anyway to handle this, access address which device not defined, expect it no handle, but not cause system crash. like read is zero and write ignore. diff --git a/results/classifier/118/device/1108 b/results/classifier/118/device/1108 deleted file mode 100644 index 7aae7917..00000000 --- a/results/classifier/118/device/1108 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.867 -performance: 0.601 -arm: 0.554 -network: 0.486 -graphic: 0.388 -boot: 0.377 -architecture: 0.282 -vnc: 0.245 -PID: 0.235 -ppc: 0.213 -risc-v: 0.211 -i386: 0.203 -x86: 0.200 -semantic: 0.189 -debug: 0.186 -TCG: 0.150 -socket: 0.135 -KVM: 0.126 -user-level: 0.122 -peripherals: 0.096 -virtual: 0.083 -register: 0.068 -mistranslation: 0.064 -VMM: 0.063 -hypervisor: 0.058 -kernel: 0.047 -assembly: 0.034 -permissions: 0.025 -files: 0.008 - -D-Bus display does fails to build if libgdm is not detected diff --git a/results/classifier/118/device/112 b/results/classifier/118/device/112 deleted file mode 100644 index 7e0370d0..00000000 --- a/results/classifier/118/device/112 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.937 -network: 0.804 -architecture: 0.773 -performance: 0.723 -peripherals: 0.492 -debug: 0.319 -assembly: 0.289 -graphic: 0.284 -socket: 0.260 -semantic: 0.236 -boot: 0.231 -files: 0.205 -register: 0.186 -arm: 0.169 -risc-v: 0.131 -user-level: 0.126 -hypervisor: 0.122 -mistranslation: 0.114 -permissions: 0.112 -virtual: 0.101 -PID: 0.101 -kernel: 0.077 -VMM: 0.052 -x86: 0.045 -TCG: 0.044 -KVM: 0.027 -ppc: 0.025 -vnc: 0.016 -i386: 0.004 - -setting unsupported timeout for i6300esb watchdog causes hw reset diff --git a/results/classifier/118/device/1124 b/results/classifier/118/device/1124 deleted file mode 100644 index 7c3ba993..00000000 --- a/results/classifier/118/device/1124 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.916 -architecture: 0.846 -network: 0.780 -performance: 0.767 -ppc: 0.759 -debug: 0.726 -peripherals: 0.657 -graphic: 0.650 -arm: 0.591 -hypervisor: 0.535 -mistranslation: 0.313 -register: 0.292 -semantic: 0.290 -permissions: 0.268 -user-level: 0.232 -files: 0.194 -boot: 0.151 -virtual: 0.150 -PID: 0.120 -vnc: 0.083 -kernel: 0.083 -VMM: 0.078 -assembly: 0.070 -socket: 0.065 -risc-v: 0.042 -TCG: 0.035 -x86: 0.035 -i386: 0.007 -KVM: 0.003 - -AIX 5 not working with qemu-system-ppc64 diff --git a/results/classifier/118/device/1133 b/results/classifier/118/device/1133 deleted file mode 100644 index 1b9c7e78..00000000 --- a/results/classifier/118/device/1133 +++ /dev/null @@ -1,40 +0,0 @@ -device: 0.877 -debug: 0.622 -graphic: 0.592 -performance: 0.556 -register: 0.532 -ppc: 0.454 -socket: 0.410 -vnc: 0.376 -files: 0.364 -boot: 0.347 -network: 0.338 -semantic: 0.334 -mistranslation: 0.288 -risc-v: 0.247 -user-level: 0.244 -VMM: 0.229 -PID: 0.215 -architecture: 0.215 -permissions: 0.171 -peripherals: 0.145 -arm: 0.122 -virtual: 0.119 -assembly: 0.118 -TCG: 0.107 -i386: 0.090 -kernel: 0.019 -hypervisor: 0.012 -KVM: 0.005 -x86: 0.003 - -unused memory filled with 0x00 instead of 0xFF -Description of problem: -Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem? - -Refer to -https://bugs.launchpad.net/qemu/+bug/1180923 -Steps to reproduce: -1. -2. -3. diff --git a/results/classifier/118/device/1134 b/results/classifier/118/device/1134 deleted file mode 100644 index a0ca5446..00000000 --- a/results/classifier/118/device/1134 +++ /dev/null @@ -1,33 +0,0 @@ -device: 0.936 -mistranslation: 0.750 -peripherals: 0.740 -semantic: 0.554 -graphic: 0.418 -boot: 0.293 -performance: 0.233 -permissions: 0.165 -register: 0.157 -debug: 0.152 -vnc: 0.106 -virtual: 0.085 -ppc: 0.084 -network: 0.083 -architecture: 0.068 -arm: 0.060 -user-level: 0.040 -files: 0.037 -assembly: 0.032 -risc-v: 0.027 -VMM: 0.027 -i386: 0.017 -x86: 0.013 -socket: 0.009 -TCG: 0.008 -hypervisor: 0.008 -PID: 0.007 -kernel: 0.006 -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/118/device/1140 b/results/classifier/118/device/1140 deleted file mode 100644 index 66a372aa..00000000 --- a/results/classifier/118/device/1140 +++ /dev/null @@ -1,31 +0,0 @@ -architecture: 0.971 -device: 0.952 -performance: 0.944 -graphic: 0.853 -arm: 0.840 -permissions: 0.603 -risc-v: 0.568 -ppc: 0.449 -semantic: 0.384 -debug: 0.358 -PID: 0.305 -mistranslation: 0.291 -user-level: 0.285 -TCG: 0.253 -boot: 0.217 -VMM: 0.208 -vnc: 0.189 -register: 0.181 -hypervisor: 0.161 -virtual: 0.106 -assembly: 0.034 -network: 0.016 -files: 0.011 -kernel: 0.002 -i386: 0.001 -socket: 0.001 -KVM: 0.001 -x86: 0.001 -peripherals: 0.000 - -High CPU usage on AMD after migrating guests diff --git a/results/classifier/118/device/1142 b/results/classifier/118/device/1142 deleted file mode 100644 index 19990a0c..00000000 --- a/results/classifier/118/device/1142 +++ /dev/null @@ -1,76 +0,0 @@ -device: 0.885 -boot: 0.849 -kernel: 0.825 -i386: 0.805 -files: 0.803 -ppc: 0.795 -socket: 0.793 -architecture: 0.758 -graphic: 0.745 -register: 0.740 -vnc: 0.704 -performance: 0.703 -permissions: 0.681 -PID: 0.655 -risc-v: 0.626 -network: 0.618 -semantic: 0.577 -debug: 0.519 -hypervisor: 0.516 -KVM: 0.504 -arm: 0.500 -virtual: 0.498 -VMM: 0.487 -TCG: 0.469 -mistranslation: 0.441 -peripherals: 0.408 -x86: 0.404 -assembly: 0.398 -user-level: 0.216 - -Measurements fail with direct kernel boot for AMD SEV confidential virtualization with 7.1 machine type -Description of problem: -When booting the QEMU with the 'kernel-hashes:true' property set for 'sev-guest' confidential virtualization, the contents of the `-kernel` file are measured by the firmware. - -A remote tenant can then validate the measurement against its expected contents to see if the boot was trustworthy. - -With the pc-q35-7.1 machine type the measurement always fails to validate against expected state. - -Making the following code change - -``` -diff --git a/hw/i386/pc.c b/hw/i386/pc.c -index 7280c02ce3..3a4bf5cba3 100644 ---- a/hw/i386/pc.c -+++ b/hw/i386/pc.c -@@ -1899,6 +1899,8 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) - pcmc->rsdp_in_ram = true; - pcmc->smbios_defaults = true; - pcmc->smbios_uuid_encoded = true; -+ pcmc->legacy_no_rng_seed = true; -+ - pcmc->gigabyte_align = true; - pcmc->has_reserved_memory = true; - pcmc->kvmclock_enabled = true; -``` - -results in successfully validating the measurement. - -THis is not surprising, the RNG seed patch introduced in - -``` -commit 67f7e426e53833a5db75b0d813e8d537b8a75bd2 -Author: Jason A. Donenfeld -Date: Thu Jul 21 14:56:36 2022 +0200 - - hw/i386: pass RNG seed via setup_data entry -``` - -intentionally modifies the contents of the kernel image before passing it to the firmware, to inject a random seed. This will ensure the boot measuremnts are different every time. - -This RNG seed functionality must NOT be used when AMD SEV is active. -Steps to reproduce: -1. Create an AMD SEV guest with kernel-hashes=true and pc-q35-7.1 machine type -2. Attempt to validate the boot measurement -Additional information: - diff --git a/results/classifier/118/device/115 b/results/classifier/118/device/115 deleted file mode 100644 index 28abdc17..00000000 --- a/results/classifier/118/device/115 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.845 -performance: 0.781 -network: 0.733 -arm: 0.729 -architecture: 0.566 -graphic: 0.543 -risc-v: 0.495 -debug: 0.462 -files: 0.441 -VMM: 0.439 -ppc: 0.433 -TCG: 0.361 -boot: 0.347 -PID: 0.341 -register: 0.339 -peripherals: 0.335 -mistranslation: 0.255 -vnc: 0.248 -kernel: 0.232 -permissions: 0.224 -socket: 0.194 -assembly: 0.192 -semantic: 0.176 -virtual: 0.164 -hypervisor: 0.148 -x86: 0.097 -KVM: 0.073 -user-level: 0.059 -i386: 0.047 - -shmat fails on 32-to-64 setup diff --git a/results/classifier/118/device/1155677 b/results/classifier/118/device/1155677 deleted file mode 100644 index 10360955..00000000 --- a/results/classifier/118/device/1155677 +++ /dev/null @@ -1,57 +0,0 @@ -device: 0.816 -graphic: 0.723 -x86: 0.692 -performance: 0.635 -architecture: 0.615 -peripherals: 0.595 -semantic: 0.577 -network: 0.576 -debug: 0.508 -mistranslation: 0.457 -register: 0.456 -PID: 0.455 -virtual: 0.444 -kernel: 0.433 -boot: 0.428 -permissions: 0.417 -hypervisor: 0.415 -user-level: 0.373 -ppc: 0.369 -socket: 0.331 -vnc: 0.313 -arm: 0.306 -i386: 0.298 -VMM: 0.213 -risc-v: 0.202 -assembly: 0.185 -TCG: 0.164 -KVM: 0.087 -files: 0.041 - -snapshot=on fails with non file-based storage - -The snapshot=on option doesn't work with an nbd block device: - -/usr/bin/qemu-system-x86_64 \ -[...] - -device virtio-scsi-pci,id=scsi \ - -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none \ - -device scsi-hd,drive=hd0 \ -[...] - -gives the error: - -qemu-system-x86_64: -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none: could not open disk image nbd:localhost:61930: No such file or directory - -If you remove the snapshot=on flag, it works (although that of course means that the block device is writable which we don't want). - -Previously reported here: - - http://permalink.gmane.org/gmane.comp.emulators.qemu/148390 - -and I can confirm this still happens in qemu 1.4.0. - -Triaging old bug tickets... I think this has likely been fixed in 2013 ... or can you still reproduce this issue with the latest version of QEMU? Could we close this ticket nowadays? - -Let's close this. libguestfs doesn't use snapshot=on any longer. - diff --git a/results/classifier/118/device/116 b/results/classifier/118/device/116 deleted file mode 100644 index 4cbe74ad..00000000 --- a/results/classifier/118/device/116 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.929 -architecture: 0.757 -performance: 0.742 -graphic: 0.627 -network: 0.522 -debug: 0.457 -peripherals: 0.456 -arm: 0.380 -boot: 0.355 -semantic: 0.224 -permissions: 0.223 -user-level: 0.132 -mistranslation: 0.130 -register: 0.106 -PID: 0.089 -kernel: 0.087 -socket: 0.078 -risc-v: 0.076 -ppc: 0.061 -virtual: 0.059 -TCG: 0.054 -hypervisor: 0.053 -vnc: 0.040 -VMM: 0.038 -i386: 0.022 -assembly: 0.021 -files: 0.020 -x86: 0.005 -KVM: 0.001 - -qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974 diff --git a/results/classifier/118/device/117 b/results/classifier/118/device/117 deleted file mode 100644 index 10b2fd60..00000000 --- a/results/classifier/118/device/117 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.808 -network: 0.765 -architecture: 0.683 -files: 0.652 -vnc: 0.551 -arm: 0.527 -boot: 0.512 -TCG: 0.482 -kernel: 0.457 -VMM: 0.341 -risc-v: 0.318 -debug: 0.309 -graphic: 0.276 -PID: 0.253 -performance: 0.246 -register: 0.200 -semantic: 0.148 -permissions: 0.147 -ppc: 0.101 -socket: 0.077 -mistranslation: 0.067 -KVM: 0.046 -virtual: 0.023 -i386: 0.019 -x86: 0.009 -user-level: 0.008 -peripherals: 0.008 -assembly: 0.005 -hypervisor: 0.001 - -nested 9p filesystem with security_model=mapped-xattr diff --git a/results/classifier/118/device/1171 b/results/classifier/118/device/1171 deleted file mode 100644 index 24416193..00000000 --- a/results/classifier/118/device/1171 +++ /dev/null @@ -1,33 +0,0 @@ -device: 0.893 -network: 0.707 -i386: 0.533 -graphic: 0.528 -x86: 0.509 -hypervisor: 0.429 -architecture: 0.391 -boot: 0.357 -semantic: 0.293 -PID: 0.237 -virtual: 0.234 -ppc: 0.210 -debug: 0.192 -peripherals: 0.157 -register: 0.151 -socket: 0.150 -mistranslation: 0.096 -user-level: 0.088 -vnc: 0.086 -files: 0.066 -performance: 0.063 -assembly: 0.060 -VMM: 0.055 -permissions: 0.051 -TCG: 0.045 -risc-v: 0.043 -arm: 0.010 -kernel: 0.005 -KVM: 0.003 - -tulip: DMA reentrancy issue leads to stack overflow (CVE-2022-2962) -Description of problem: -A DMA reentrancy issue was found in the tulip emulation. When tulip reads or writes to rx/tx descriptor ( tulip_desc_read/write ) or copies rx/tx frame(tulip_copy_rx_bytes / tulip_copy_tx_buffers), it doesn't check whether the destination address is its own MMIO address. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host. diff --git a/results/classifier/118/device/118 b/results/classifier/118/device/118 deleted file mode 100644 index 4f6ced4a..00000000 --- a/results/classifier/118/device/118 +++ /dev/null @@ -1,31 +0,0 @@ -mistranslation: 0.966 -device: 0.938 -peripherals: 0.928 -debug: 0.816 -network: 0.706 -performance: 0.663 -architecture: 0.662 -arm: 0.659 -socket: 0.648 -boot: 0.551 -graphic: 0.524 -risc-v: 0.519 -register: 0.383 -VMM: 0.370 -vnc: 0.327 -ppc: 0.324 -permissions: 0.322 -TCG: 0.316 -PID: 0.312 -virtual: 0.247 -semantic: 0.214 -kernel: 0.154 -user-level: 0.082 -files: 0.060 -assembly: 0.056 -i386: 0.055 -KVM: 0.040 -hypervisor: 0.032 -x86: 0.006 - -USB device 1.1 not correctly passedthru from Linux host to Windows guest diff --git a/results/classifier/118/device/1181354 b/results/classifier/118/device/1181354 deleted file mode 100644 index 061bdfd7..00000000 --- a/results/classifier/118/device/1181354 +++ /dev/null @@ -1,40 +0,0 @@ -device: 0.815 -architecture: 0.728 -graphic: 0.725 -performance: 0.721 -vnc: 0.648 -debug: 0.598 -ppc: 0.551 -user-level: 0.532 -semantic: 0.522 -risc-v: 0.515 -network: 0.499 -boot: 0.440 -socket: 0.438 -files: 0.414 -PID: 0.409 -register: 0.408 -arm: 0.392 -peripherals: 0.258 -permissions: 0.241 -VMM: 0.240 -kernel: 0.191 -mistranslation: 0.172 -TCG: 0.158 -virtual: 0.136 -i386: 0.125 -x86: 0.077 -hypervisor: 0.072 -assembly: 0.030 -KVM: 0.005 - -assert failed in scsi-bus.c line 1539 in SCSI_XFER_NONE - -Every time I format a SCSI hard disk (on ID 0) with Windows NT or DOS, QEMU crashes with an assertion failure on scsi-bus.c, any help? - -this happens from 1.3.0 to the latest git release. - -Does this problem still occur with the latest version of QEMU (currently it's 2.7.0)? If so, can you please post the exact assertion message, and if possible a stack trace (taken with gdb)? Thanks! - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/118/device/1187 b/results/classifier/118/device/1187 deleted file mode 100644 index fc1b55b3..00000000 --- a/results/classifier/118/device/1187 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.862 -performance: 0.823 -network: 0.743 -architecture: 0.617 -kernel: 0.559 -arm: 0.450 -user-level: 0.421 -TCG: 0.398 -risc-v: 0.393 -graphic: 0.370 -peripherals: 0.357 -ppc: 0.349 -VMM: 0.339 -vnc: 0.335 -semantic: 0.275 -mistranslation: 0.242 -register: 0.203 -boot: 0.203 -permissions: 0.195 -debug: 0.191 -PID: 0.179 -files: 0.151 -socket: 0.132 -KVM: 0.070 -hypervisor: 0.054 -virtual: 0.052 -assembly: 0.030 -i386: 0.020 -x86: 0.003 - -can not handler real-time signal (signal number > 30) by sigqueue on linux user mode diff --git a/results/classifier/118/device/1187529 b/results/classifier/118/device/1187529 deleted file mode 100644 index ed81c897..00000000 --- a/results/classifier/118/device/1187529 +++ /dev/null @@ -1,47 +0,0 @@ -device: 0.915 -KVM: 0.892 -peripherals: 0.859 -x86: 0.847 -graphic: 0.703 -vnc: 0.668 -architecture: 0.636 -ppc: 0.573 -performance: 0.572 -semantic: 0.445 -network: 0.416 -mistranslation: 0.404 -boot: 0.377 -PID: 0.343 -socket: 0.336 -files: 0.308 -register: 0.293 -virtual: 0.251 -permissions: 0.246 -kernel: 0.243 -i386: 0.232 -hypervisor: 0.217 -risc-v: 0.186 -TCG: 0.185 -assembly: 0.171 -VMM: 0.171 -user-level: 0.153 -arm: 0.105 -debug: 0.102 - -Devices on PCI bridge stop working when live-migrated - -qemu version: 1.4.50 (0ca5aa4f4c4a8bcc73988dd52a536241d35e5223) -host: x86_64, Linux 3.6.10 (Fedora 17) -client: x86_64 Centos 6.3 (doesn't matter, really) - -If a device, e.g. an lsi53c895a, is on a pci-bridge, after migration, the device stops working (e.g., commands like "poweroff" -get an Input/Output error. Fails under either xen or kvm. If "top" was running, some cpus go to ~100% wait. - -Sample KVM invocation line: -qemu-system-x86_64 -machine type=pc,accel=kvm -m 4096 -device pci-bridgemsi=on,chassis_nr=1,id=pciBridge1.0,addr=0x11.0 -device lsi53c895a,id=sas,bus=pciBridge1.0,addr=0x1.0x0 -drive if=none,id=disk0,file=/path/to/disk/image -device scsi-disk,bus=sas.0,scsi-id=0,drive=disk0 -vnc 127.0.0.1:0,to=99 -serial pty -boot order=cda -smp 4,maxcpus=4 -monitor vc - -Triaging 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/118/device/119 b/results/classifier/118/device/119 deleted file mode 100644 index 596e964c..00000000 --- a/results/classifier/118/device/119 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.926 -mistranslation: 0.806 -performance: 0.696 -semantic: 0.627 -graphic: 0.565 -architecture: 0.495 -hypervisor: 0.415 -user-level: 0.339 -permissions: 0.220 -network: 0.219 -peripherals: 0.140 -boot: 0.137 -assembly: 0.134 -socket: 0.122 -debug: 0.109 -virtual: 0.074 -register: 0.064 -arm: 0.057 -TCG: 0.043 -VMM: 0.037 -PID: 0.034 -i386: 0.031 -files: 0.029 -ppc: 0.029 -vnc: 0.022 -x86: 0.017 -KVM: 0.013 -kernel: 0.010 -risc-v: 0.008 - -USB assert failure on hcd-uhci.c diff --git a/results/classifier/118/device/1191 b/results/classifier/118/device/1191 deleted file mode 100644 index ff2c76da..00000000 --- a/results/classifier/118/device/1191 +++ /dev/null @@ -1,39 +0,0 @@ -device: 0.930 -graphic: 0.867 -boot: 0.835 -performance: 0.685 -mistranslation: 0.667 -debug: 0.469 -arm: 0.464 -semantic: 0.446 -register: 0.417 -PID: 0.410 -risc-v: 0.359 -vnc: 0.279 -ppc: 0.272 -socket: 0.266 -permissions: 0.245 -kernel: 0.166 -files: 0.148 -TCG: 0.145 -network: 0.144 -architecture: 0.142 -VMM: 0.099 -i386: 0.089 -x86: 0.078 -KVM: 0.070 -hypervisor: 0.062 -peripherals: 0.058 -user-level: 0.054 -virtual: 0.052 -assembly: 0.010 - -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/118/device/1196 b/results/classifier/118/device/1196 deleted file mode 100644 index 2979716c..00000000 --- a/results/classifier/118/device/1196 +++ /dev/null @@ -1,42 +0,0 @@ -device: 0.882 -graphic: 0.870 -ppc: 0.828 -vnc: 0.763 -network: 0.676 -PID: 0.675 -risc-v: 0.630 -peripherals: 0.595 -VMM: 0.561 -performance: 0.559 -register: 0.490 -boot: 0.444 -TCG: 0.416 -semantic: 0.416 -arm: 0.399 -socket: 0.384 -kernel: 0.355 -debug: 0.332 -hypervisor: 0.318 -KVM: 0.297 -mistranslation: 0.292 -files: 0.271 -architecture: 0.264 -i386: 0.257 -permissions: 0.250 -x86: 0.155 -virtual: 0.094 -assembly: 0.083 -user-level: 0.050 - -Guest could not enable pci AtomicOp requests for passthrough device -Description of problem: -Guest could not enable pci AtomicOp requests for passthrough device. - -sudo setpci -v -d *:706t 8c.b=40 // enable pci AtomicOp requests bit in the guest os. - -Host could not see the bit by command "sudo lspci -vvv -s 03:00.0". -Steps to reproduce: -1. sudo setpci -v -d *:706t 8c.b=40 // in the guest os -2. sudo lspci -vvv -s 03:00.0 // in the host os -Additional information: - diff --git a/results/classifier/118/device/1198350 b/results/classifier/118/device/1198350 deleted file mode 100644 index 11e8fd22..00000000 --- a/results/classifier/118/device/1198350 +++ /dev/null @@ -1,82 +0,0 @@ -device: 0.943 -boot: 0.911 -kernel: 0.878 -user-level: 0.876 -graphic: 0.861 -virtual: 0.857 -socket: 0.835 -semantic: 0.830 -architecture: 0.828 -peripherals: 0.827 -mistranslation: 0.824 -PID: 0.815 -VMM: 0.802 -network: 0.798 -i386: 0.797 -files: 0.793 -hypervisor: 0.766 -assembly: 0.762 -performance: 0.760 -register: 0.759 -vnc: 0.746 -debug: 0.714 -permissions: 0.711 -ppc: 0.675 -x86: 0.646 -arm: 0.591 -risc-v: 0.555 -KVM: 0.510 -TCG: 0.491 - -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/118/device/1208 b/results/classifier/118/device/1208 deleted file mode 100644 index e1149079..00000000 --- a/results/classifier/118/device/1208 +++ /dev/null @@ -1,39 +0,0 @@ -device: 0.953 -ppc: 0.923 -semantic: 0.649 -graphic: 0.544 -PID: 0.414 -register: 0.393 -arm: 0.300 -files: 0.299 -boot: 0.296 -mistranslation: 0.286 -architecture: 0.278 -debug: 0.222 -performance: 0.148 -VMM: 0.141 -vnc: 0.133 -socket: 0.131 -peripherals: 0.126 -virtual: 0.118 -user-level: 0.110 -permissions: 0.102 -network: 0.075 -assembly: 0.044 -TCG: 0.037 -i386: 0.036 -risc-v: 0.031 -kernel: 0.015 -x86: 0.006 -hypervisor: 0.003 -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/118/device/1210 b/results/classifier/118/device/1210 deleted file mode 100644 index aac64918..00000000 --- a/results/classifier/118/device/1210 +++ /dev/null @@ -1,38 +0,0 @@ -device: 0.859 -graphic: 0.816 -performance: 0.667 -files: 0.644 -semantic: 0.605 -network: 0.536 -debug: 0.464 -architecture: 0.436 -permissions: 0.316 -boot: 0.311 -ppc: 0.226 -peripherals: 0.224 -arm: 0.211 -user-level: 0.198 -mistranslation: 0.195 -PID: 0.176 -hypervisor: 0.169 -risc-v: 0.135 -vnc: 0.097 -i386: 0.093 -kernel: 0.091 -virtual: 0.076 -TCG: 0.069 -VMM: 0.066 -socket: 0.059 -x86: 0.057 -register: 0.043 -KVM: 0.034 -assembly: 0.005 - -qemu segfaults on PNG screendump -Description of problem: -Attempting to produce a screendump via the monitor in the PNG format leads to a segmentation fault (but the screen dump is produced correctly). -Steps to reproduce: -1. Launch QEMU -2. Go to the monitoring screen () -3. execute the command: `screendump /tmp/dump.png -f png` -4. observe the crash (segfault) diff --git a/results/classifier/118/device/1211 b/results/classifier/118/device/1211 deleted file mode 100644 index 25de8c90..00000000 --- a/results/classifier/118/device/1211 +++ /dev/null @@ -1,37 +0,0 @@ -device: 0.854 -graphic: 0.562 -risc-v: 0.527 -peripherals: 0.379 -debug: 0.375 -boot: 0.229 -semantic: 0.184 -user-level: 0.136 -PID: 0.109 -arm: 0.100 -files: 0.089 -register: 0.077 -x86: 0.057 -architecture: 0.045 -vnc: 0.038 -network: 0.029 -mistranslation: 0.024 -performance: 0.022 -ppc: 0.021 -i386: 0.019 -socket: 0.018 -assembly: 0.012 -virtual: 0.012 -permissions: 0.012 -kernel: 0.011 -KVM: 0.010 -VMM: 0.009 -hypervisor: 0.007 -TCG: 0.006 - -Bad fonts in "cirrus" VGA card. -Description of problem: -Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file. -Steps to reproduce: -Similar to #988. -Additional information: - diff --git a/results/classifier/118/device/1221 b/results/classifier/118/device/1221 deleted file mode 100644 index 5266c193..00000000 --- a/results/classifier/118/device/1221 +++ /dev/null @@ -1,59 +0,0 @@ -device: 0.965 -network: 0.907 -hypervisor: 0.899 -performance: 0.891 -architecture: 0.890 -ppc: 0.879 -kernel: 0.876 -files: 0.866 -mistranslation: 0.862 -KVM: 0.861 -vnc: 0.858 -x86: 0.852 -PID: 0.852 -virtual: 0.841 -peripherals: 0.827 -assembly: 0.826 -VMM: 0.824 -socket: 0.816 -risc-v: 0.805 -TCG: 0.798 -register: 0.788 -permissions: 0.771 -i386: 0.769 -semantic: 0.757 -graphic: 0.748 -arm: 0.691 -debug: 0.605 -boot: 0.577 -user-level: 0.311 - -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/118/device/1225 b/results/classifier/118/device/1225 deleted file mode 100644 index 452d4ae7..00000000 --- a/results/classifier/118/device/1225 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.950 -performance: 0.783 -architecture: 0.760 -mistranslation: 0.714 -network: 0.677 -socket: 0.665 -user-level: 0.661 -files: 0.652 -semantic: 0.648 -risc-v: 0.648 -register: 0.645 -arm: 0.619 -debug: 0.612 -peripherals: 0.577 -graphic: 0.563 -ppc: 0.540 -permissions: 0.537 -PID: 0.451 -vnc: 0.440 -hypervisor: 0.406 -assembly: 0.397 -VMM: 0.391 -virtual: 0.380 -TCG: 0.321 -kernel: 0.273 -boot: 0.172 -KVM: 0.078 -i386: 0.064 -x86: 0.047 - -Can't update to Windows 11 22H2 diff --git a/results/classifier/118/device/1226 b/results/classifier/118/device/1226 deleted file mode 100644 index 677f1819..00000000 --- a/results/classifier/118/device/1226 +++ /dev/null @@ -1,55 +0,0 @@ -device: 0.847 -graphic: 0.818 -boot: 0.697 -PID: 0.620 -files: 0.513 -ppc: 0.397 -peripherals: 0.345 -performance: 0.339 -virtual: 0.335 -architecture: 0.327 -semantic: 0.325 -socket: 0.252 -risc-v: 0.227 -hypervisor: 0.207 -vnc: 0.206 -kernel: 0.205 -mistranslation: 0.168 -register: 0.160 -TCG: 0.152 -x86: 0.148 -debug: 0.148 -VMM: 0.125 -arm: 0.123 -KVM: 0.096 -assembly: 0.085 -network: 0.081 -i386: 0.080 -user-level: 0.034 -permissions: 0.020 - -wheel-axis=false does not get applied at hardware init stage -Description of problem: -`-device virtio-tablet,id=touch0,wheel-axis=false` does not get applied at initalization stage, causing android to see it and treat the device as a pointer instead of a tablet. it seems to look for the prop at init stage, I have verified that this is an issue by fixing it with a quick hack below. ~~setting `-device virtio-tablet,id=touch0,wheel-axis=true` will still work fine and cause android to pick it up as a pointer again~~ - - -EDIT: It does not seem to work actually. if set when the default is set to false -Steps to reproduce: -1. Boot android based VM -2. test an app that forces touch only over pointer -Additional information: -``` -diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c -index a7a244a95d..3175f9c7d5 100644 ---- a/hw/input/virtio-input-hid.c -+++ b/hw/input/virtio-input-hid.c -@@ -477,7 +477,7 @@ static struct virtio_input_config virtio_tablet_config_v2[] = { - }; - - static Property virtio_tablet_properties[] = { -- DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true), -+ DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, false), - DEFINE_PROP_END_OF_LIST(), - }; - -``` diff --git a/results/classifier/118/device/1230 b/results/classifier/118/device/1230 deleted file mode 100644 index 62a81fb1..00000000 --- a/results/classifier/118/device/1230 +++ /dev/null @@ -1,53 +0,0 @@ -device: 0.859 -graphic: 0.786 -PID: 0.781 -architecture: 0.778 -socket: 0.765 -network: 0.747 -vnc: 0.746 -ppc: 0.742 -semantic: 0.732 -TCG: 0.729 -arm: 0.682 -VMM: 0.669 -performance: 0.659 -kernel: 0.652 -x86: 0.603 -files: 0.603 -register: 0.595 -permissions: 0.582 -i386: 0.566 -hypervisor: 0.554 -risc-v: 0.531 -mistranslation: 0.527 -debug: 0.509 -boot: 0.480 -KVM: 0.469 -peripherals: 0.431 -assembly: 0.366 -virtual: 0.319 -user-level: 0.236 - -qtest-aarch64/migration-test non-deterministic test failure -Description of problem: -The test suite fails: -``` -Summary of Failures: - - 32/619 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test ERROR 161.19s killed by signal 6 SIGABRT - - -Ok: 552 -Expected Fail: 0 -Fail: 1 -Unexpected Pass: 0 -Skipped: 66 -Timeout: 0 - -Full log written to /tmp/guix-build-qemu-7.1.0.drv-0/qemu-7.1.0/b/qemu/meson-logs/testlog.txt -make: *** [Makefile.mtest:25: do-meson-check] Error 1 -``` - -See the full build log below. -Additional information: -[qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz](/uploads/6d7f0da152193213a7fe694e2d535879/qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz) diff --git a/results/classifier/118/device/1237 b/results/classifier/118/device/1237 deleted file mode 100644 index a282e0d9..00000000 --- a/results/classifier/118/device/1237 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.934 -KVM: 0.898 -performance: 0.787 -network: 0.663 -debug: 0.640 -peripherals: 0.553 -graphic: 0.549 -VMM: 0.430 -arm: 0.411 -PID: 0.400 -kernel: 0.351 -i386: 0.294 -ppc: 0.271 -x86: 0.269 -semantic: 0.244 -register: 0.241 -TCG: 0.236 -boot: 0.230 -mistranslation: 0.195 -vnc: 0.157 -permissions: 0.123 -risc-v: 0.121 -files: 0.099 -architecture: 0.039 -socket: 0.038 -virtual: 0.033 -user-level: 0.027 -hypervisor: 0.026 -assembly: 0.009 - -after OS upgrade usb-redir connection broken during migration and qemu-kvm: terminating on signal 15 diff --git a/results/classifier/118/device/1244 b/results/classifier/118/device/1244 deleted file mode 100644 index 4b4518f6..00000000 --- a/results/classifier/118/device/1244 +++ /dev/null @@ -1,75 +0,0 @@ -device: 0.910 -debug: 0.908 -graphic: 0.907 -vnc: 0.877 -PID: 0.864 -architecture: 0.839 -arm: 0.835 -files: 0.834 -socket: 0.826 -network: 0.813 -TCG: 0.768 -ppc: 0.767 -register: 0.765 -assembly: 0.737 -i386: 0.722 -VMM: 0.697 -peripherals: 0.691 -semantic: 0.646 -risc-v: 0.604 -permissions: 0.599 -performance: 0.592 -virtual: 0.584 -hypervisor: 0.534 -x86: 0.511 -boot: 0.467 -user-level: 0.467 -kernel: 0.352 -mistranslation: 0.317 -KVM: 0.062 - -macOS 12.x ld: warning: -undefined dynamic_lookup may not work with chained fixups -Description of problem: -Not sure if this is a serious or negligible problem and if it has any significant runtime implications but reporting it anyway: - -``` -$ ld -v -@(#)PROGRAM:ld PROJECT:ld64-819.6 -BUILD 14:58:44 Aug 5 2022 -configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em -LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29) -TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) - -$ ninja -C build -ninja: Entering directory `build' -[314/2946] Linking static target libevent-loop-base.a -warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libevent-loop-base.a the table of contents is empty (no object file members in the library define global symbols) -[2044/2946] Generating qemu-system-aarch64 with a custom command -qemu-system-aarch64.tmp: replacing existing signature -[2584/2946] Linking target tests/plugin/libempty.dylib -ld: warning: -undefined dynamic_lookup may not work with chained fixups -[2585/2946] Linking target tests/plugin/libbb.dylib -ld: warning: -undefined dynamic_lookup may not work with chained fixups -[2588/2946] Linking target tests/plugin/libinsn.dylib -ld: warning: -undefined dynamic_lookup may not work with chained fixups -[2589/2946] Linking target tests/plugin/libmem.dylib -ld: warning: -undefined dynamic_lookup may not work with chained fixups -[2592/2946] Linking target tests/plugin/libsyscall.dylib -ld: warning: -undefined dynamic_lookup may not work with chained fixups -[2946/2946] Linking target tests/qtest/test-arm-mptimer -``` - -I saw a similar discussions in Bazel building system, CPython, and Ruby: -- https://github.com/bazelbuild/bazel/issues/16413 -- https://github.com/python/cpython/issues/97524 -- https://github.com/ruby/ruby/pull/6193 -- https://issues.guix.gnu.org/issue/57849 -Steps to reproduce: -1. ` ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-cocoa --enable-plugins` (note that target list is not that important in this case though) -2. `ninja -C build` -3. Observe the warnings -Additional information: -See "New Features" subsection under "Linking" section for chained fixup -https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes for more information: - -> All programs and dylibs built with a deployment target of macOS 12 or iOS 15 or later now use the chained fixups format. This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. (49851380) diff --git a/results/classifier/118/device/1246 b/results/classifier/118/device/1246 deleted file mode 100644 index ef2553d9..00000000 --- a/results/classifier/118/device/1246 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.894 -files: 0.839 -performance: 0.686 -network: 0.660 -kernel: 0.608 -mistranslation: 0.608 -VMM: 0.601 -semantic: 0.570 -arm: 0.543 -architecture: 0.523 -hypervisor: 0.513 -peripherals: 0.506 -graphic: 0.479 -TCG: 0.473 -register: 0.446 -permissions: 0.442 -vnc: 0.428 -ppc: 0.391 -socket: 0.386 -PID: 0.384 -user-level: 0.378 -risc-v: 0.359 -virtual: 0.357 -debug: 0.341 -boot: 0.291 -KVM: 0.242 -assembly: 0.197 -x86: 0.053 -i386: 0.010 - -Win11_22H2_English_x64.iso won't boot diff --git a/results/classifier/118/device/1248469 b/results/classifier/118/device/1248469 deleted file mode 100644 index c43d4c0b..00000000 --- a/results/classifier/118/device/1248469 +++ /dev/null @@ -1,38 +0,0 @@ -device: 0.957 -boot: 0.918 -architecture: 0.833 -performance: 0.794 -network: 0.715 -peripherals: 0.706 -graphic: 0.610 -permissions: 0.599 -socket: 0.588 -register: 0.481 -semantic: 0.436 -hypervisor: 0.427 -arm: 0.414 -files: 0.408 -kernel: 0.385 -debug: 0.345 -ppc: 0.344 -vnc: 0.314 -PID: 0.265 -mistranslation: 0.210 -VMM: 0.196 -user-level: 0.192 -risc-v: 0.158 -TCG: 0.119 -virtual: 0.098 -assembly: 0.082 -x86: 0.037 -KVM: 0.015 -i386: 0.008 - -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/118/device/1256826 b/results/classifier/118/device/1256826 deleted file mode 100644 index 94f4ccb8..00000000 --- a/results/classifier/118/device/1256826 +++ /dev/null @@ -1,46 +0,0 @@ -device: 0.836 -graphic: 0.816 -PID: 0.704 -semantic: 0.669 -architecture: 0.669 -performance: 0.621 -kernel: 0.591 -network: 0.548 -mistranslation: 0.505 -ppc: 0.495 -files: 0.478 -debug: 0.452 -vnc: 0.439 -boot: 0.415 -socket: 0.385 -peripherals: 0.356 -arm: 0.349 -virtual: 0.348 -user-level: 0.312 -risc-v: 0.283 -register: 0.283 -x86: 0.271 -VMM: 0.265 -hypervisor: 0.263 -KVM: 0.235 -permissions: 0.232 -TCG: 0.182 -assembly: 0.135 -i386: 0.090 - -INT instruction bug in WindowsXP - -This bug is in -no-kvm mode. - -In windowsXP at IDT entry 2&8 is Task gate - -when application use INT 2 or INT 8 it will cause blue screen in XP. - -I found it should cause #GP not generate hw interrupt. - -also I check this bug with -enable-kvm and works correctly. - -Which QEMU version did you use here? Can you still reproduce this problem with the latest version of QEMU (currently 2.8)? - -[Expired for QEMU because there has been no activity for 60 days.] - diff --git a/results/classifier/118/device/1262 b/results/classifier/118/device/1262 deleted file mode 100644 index 503ec59f..00000000 --- a/results/classifier/118/device/1262 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.817 -network: 0.766 -performance: 0.712 -graphic: 0.394 -boot: 0.342 -arm: 0.317 -architecture: 0.299 -semantic: 0.275 -vnc: 0.269 -debug: 0.269 -risc-v: 0.260 -permissions: 0.230 -ppc: 0.198 -hypervisor: 0.176 -mistranslation: 0.151 -register: 0.150 -VMM: 0.145 -TCG: 0.118 -kernel: 0.116 -PID: 0.106 -virtual: 0.101 -user-level: 0.083 -files: 0.075 -i386: 0.062 -x86: 0.047 -peripherals: 0.036 -assembly: 0.036 -socket: 0.020 -KVM: 0.003 - -avocado test framework fails to report when QEMU exits unexpectedly diff --git a/results/classifier/118/device/1266 b/results/classifier/118/device/1266 deleted file mode 100644 index 3a291c5e..00000000 --- a/results/classifier/118/device/1266 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.890 -performance: 0.789 -architecture: 0.456 -arm: 0.428 -graphic: 0.398 -network: 0.362 -boot: 0.318 -semantic: 0.301 -ppc: 0.291 -VMM: 0.289 -hypervisor: 0.272 -permissions: 0.268 -TCG: 0.227 -debug: 0.224 -vnc: 0.219 -i386: 0.151 -register: 0.149 -peripherals: 0.130 -files: 0.103 -user-level: 0.098 -virtual: 0.089 -mistranslation: 0.079 -assembly: 0.076 -PID: 0.062 -risc-v: 0.057 -socket: 0.042 -x86: 0.028 -kernel: 0.028 -KVM: 0.024 - -Assert in resettable_phase_enter through virtio-scsi diff --git a/results/classifier/118/device/1273 b/results/classifier/118/device/1273 deleted file mode 100644 index f333ce73..00000000 --- a/results/classifier/118/device/1273 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.897 -debug: 0.589 -mistranslation: 0.355 -graphic: 0.318 -performance: 0.306 -network: 0.221 -hypervisor: 0.200 -ppc: 0.170 -vnc: 0.149 -user-level: 0.140 -i386: 0.138 -semantic: 0.129 -register: 0.111 -risc-v: 0.095 -arm: 0.083 -boot: 0.078 -virtual: 0.075 -architecture: 0.041 -permissions: 0.035 -peripherals: 0.035 -PID: 0.035 -socket: 0.029 -assembly: 0.017 -TCG: 0.008 -kernel: 0.007 -files: 0.007 -VMM: 0.006 -x86: 0.004 -KVM: 0.001 - -QEMU log problem diff --git a/results/classifier/118/device/1275 b/results/classifier/118/device/1275 deleted file mode 100644 index 88201c32..00000000 --- a/results/classifier/118/device/1275 +++ /dev/null @@ -1,39 +0,0 @@ -device: 0.884 -graphic: 0.700 -performance: 0.613 -vnc: 0.535 -network: 0.535 -debug: 0.468 -arm: 0.467 -socket: 0.373 -architecture: 0.367 -VMM: 0.332 -PID: 0.329 -files: 0.264 -register: 0.243 -kernel: 0.236 -peripherals: 0.195 -semantic: 0.193 -virtual: 0.146 -risc-v: 0.140 -boot: 0.127 -mistranslation: 0.115 -TCG: 0.108 -ppc: 0.103 -user-level: 0.092 -permissions: 0.086 -hypervisor: 0.073 -x86: 0.060 -i386: 0.051 -assembly: 0.010 -KVM: 0.001 - -javac command stuck forever in qemu vm which does not use hardware virtualization -Description of problem: - -Steps to reproduce: -1. -2. -3. -Additional information: - diff --git a/results/classifier/118/device/1280521 b/results/classifier/118/device/1280521 deleted file mode 100644 index d7b5b13f..00000000 --- a/results/classifier/118/device/1280521 +++ /dev/null @@ -1,38 +0,0 @@ -device: 0.824 -boot: 0.753 -network: 0.748 -graphic: 0.675 -ppc: 0.671 -socket: 0.461 -mistranslation: 0.461 -register: 0.433 -performance: 0.418 -arm: 0.410 -semantic: 0.368 -risc-v: 0.344 -vnc: 0.343 -architecture: 0.297 -peripherals: 0.250 -user-level: 0.191 -permissions: 0.180 -debug: 0.135 -hypervisor: 0.135 -virtual: 0.094 -files: 0.071 -x86: 0.068 -kernel: 0.053 -i386: 0.047 -assembly: 0.036 -KVM: 0.035 -PID: 0.032 -TCG: 0.031 -VMM: 0.007 - -Plan 9 can't use GUI well emulating a RTL8139 card - -The OS Plan 9 from Bell Labs runs fine in QEMU/KVM for the most part buy is unable to boot its GUI when emulating a RTL8139 WiFi card. I hear someone was able to get it working under a Windows XP host but I can't seem to do it under a Gentoo host. If you have any idea what may be doing this I would love to hear it. - -Looking through old bug tickets... is this still an 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/118/device/1282 b/results/classifier/118/device/1282 deleted file mode 100644 index ccf880a7..00000000 --- a/results/classifier/118/device/1282 +++ /dev/null @@ -1,33 +0,0 @@ -device: 0.962 -architecture: 0.927 -graphic: 0.866 -network: 0.855 -semantic: 0.545 -boot: 0.502 -socket: 0.476 -i386: 0.423 -debug: 0.375 -assembly: 0.365 -performance: 0.360 -x86: 0.291 -PID: 0.246 -ppc: 0.213 -files: 0.202 -VMM: 0.158 -risc-v: 0.129 -TCG: 0.118 -peripherals: 0.095 -register: 0.092 -permissions: 0.089 -user-level: 0.083 -virtual: 0.074 -vnc: 0.043 -mistranslation: 0.043 -kernel: 0.015 -arm: 0.014 -hypervisor: 0.005 -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/118/device/1284 b/results/classifier/118/device/1284 deleted file mode 100644 index 048fc8be..00000000 --- a/results/classifier/118/device/1284 +++ /dev/null @@ -1,44 +0,0 @@ -device: 0.946 -graphic: 0.919 -architecture: 0.623 -debug: 0.620 -semantic: 0.551 -peripherals: 0.530 -mistranslation: 0.428 -boot: 0.295 -arm: 0.281 -user-level: 0.279 -PID: 0.225 -permissions: 0.194 -register: 0.183 -performance: 0.181 -risc-v: 0.157 -ppc: 0.145 -network: 0.136 -socket: 0.102 -vnc: 0.088 -files: 0.081 -hypervisor: 0.067 -TCG: 0.061 -VMM: 0.054 -virtual: 0.038 -kernel: 0.032 -x86: 0.027 -assembly: 0.019 -i386: 0.018 -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/118/device/1290 b/results/classifier/118/device/1290 deleted file mode 100644 index c9394bb8..00000000 --- a/results/classifier/118/device/1290 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.836 -performance: 0.764 -network: 0.725 -mistranslation: 0.591 -arm: 0.560 -kernel: 0.513 -TCG: 0.447 -ppc: 0.446 -boot: 0.437 -register: 0.386 -socket: 0.311 -graphic: 0.309 -debug: 0.306 -PID: 0.305 -architecture: 0.280 -vnc: 0.239 -permissions: 0.232 -risc-v: 0.223 -VMM: 0.222 -semantic: 0.197 -files: 0.175 -user-level: 0.142 -KVM: 0.057 -virtual: 0.052 -i386: 0.046 -hypervisor: 0.045 -peripherals: 0.012 -assembly: 0.007 -x86: 0.003 - -IO alignment probing delivers incorrect results on Linux when used with e.g. dm-crypt diff --git a/results/classifier/118/device/1292 b/results/classifier/118/device/1292 deleted file mode 100644 index 056c105f..00000000 --- a/results/classifier/118/device/1292 +++ /dev/null @@ -1,33 +0,0 @@ -device: 0.909 -graphic: 0.882 -architecture: 0.788 -network: 0.543 -performance: 0.482 -semantic: 0.450 -arm: 0.428 -boot: 0.422 -debug: 0.397 -register: 0.372 -mistranslation: 0.345 -PID: 0.269 -files: 0.251 -socket: 0.227 -risc-v: 0.156 -peripherals: 0.123 -virtual: 0.116 -vnc: 0.110 -hypervisor: 0.109 -permissions: 0.108 -ppc: 0.090 -i386: 0.079 -kernel: 0.075 -user-level: 0.074 -VMM: 0.054 -assembly: 0.032 -x86: 0.030 -TCG: 0.023 -KVM: 0.003 - -Default jemalloc config doesn't work on Asahi Linux -Description of problem: -M1 Macs use 16KB pages, jemalloc builds with 4KB page by default. diff --git a/results/classifier/118/device/1293 b/results/classifier/118/device/1293 deleted file mode 100644 index dd1e4215..00000000 --- a/results/classifier/118/device/1293 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.897 -performance: 0.610 -network: 0.508 -semantic: 0.496 -boot: 0.416 -graphic: 0.327 -permissions: 0.313 -architecture: 0.308 -arm: 0.301 -mistranslation: 0.300 -kernel: 0.286 -files: 0.285 -register: 0.256 -debug: 0.195 -hypervisor: 0.191 -socket: 0.158 -peripherals: 0.113 -ppc: 0.094 -vnc: 0.092 -i386: 0.056 -TCG: 0.048 -virtual: 0.045 -assembly: 0.044 -user-level: 0.036 -PID: 0.031 -risc-v: 0.030 -VMM: 0.020 -x86: 0.017 -KVM: 0.017 - -Trusted Firmware stopped booting on SBSA-ref diff --git a/results/classifier/118/device/1300 b/results/classifier/118/device/1300 deleted file mode 100644 index 65f60756..00000000 --- a/results/classifier/118/device/1300 +++ /dev/null @@ -1,41 +0,0 @@ -device: 0.961 -x86: 0.950 -graphic: 0.940 -VMM: 0.915 -peripherals: 0.890 -network: 0.880 -files: 0.868 -vnc: 0.859 -socket: 0.807 -semantic: 0.804 -PID: 0.793 -kernel: 0.740 -debug: 0.736 -architecture: 0.697 -boot: 0.693 -TCG: 0.681 -permissions: 0.666 -ppc: 0.654 -hypervisor: 0.643 -register: 0.639 -arm: 0.589 -virtual: 0.562 -risc-v: 0.553 -assembly: 0.552 -i386: 0.499 -user-level: 0.390 -performance: 0.348 -mistranslation: 0.251 -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/118/device/1302 b/results/classifier/118/device/1302 deleted file mode 100644 index 301f8add..00000000 --- a/results/classifier/118/device/1302 +++ /dev/null @@ -1,47 +0,0 @@ -device: 0.832 -graphic: 0.750 -socket: 0.719 -performance: 0.705 -x86: 0.679 -kernel: 0.667 -hypervisor: 0.618 -semantic: 0.584 -PID: 0.556 -network: 0.536 -ppc: 0.521 -architecture: 0.519 -vnc: 0.498 -risc-v: 0.465 -arm: 0.443 -debug: 0.440 -mistranslation: 0.439 -files: 0.418 -boot: 0.417 -register: 0.391 -i386: 0.388 -peripherals: 0.341 -TCG: 0.339 -permissions: 0.327 -KVM: 0.304 -VMM: 0.273 -assembly: 0.256 -virtual: 0.182 -user-level: 0.172 - -Per-thread logging flag must be made immutable -Description of problem: -The problem is that the code assumes it isn't possible to switch from global logging to per-thread logging and vice-versa per design, but it lags appropriate checks to enforce it. Enabling or disabling per-thread logging at runtime from the monitor causes unexpected results. -Steps to reproduce: -Enabling per-thread logging at runtime: - -1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d` -2. Enable per-thread logging from the HMP monitor : `(qemu) log tid` -3. Fails with `Filename template with '%d' required for 'tid'` even though such a template was passed with `-D`. - -Disabling per-thread logging at runtime: - -1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d -d tid,cpu_reset` -2. Disable per-thread logging from the HMP monitor: `(qemu) log cpu_reset` -3. QEMU creates a log file with a bogus `qemu.log.%d` name. -Additional information: -[Series](https://patchew.org/QEMU/20221104120059.678470-1-groug@kaod.org/) posted and already reviewed by @rth7680 . diff --git a/results/classifier/118/device/1305 b/results/classifier/118/device/1305 deleted file mode 100644 index 05d9a169..00000000 --- a/results/classifier/118/device/1305 +++ /dev/null @@ -1,44 +0,0 @@ -device: 0.924 -socket: 0.922 -virtual: 0.847 -network: 0.813 -architecture: 0.804 -vnc: 0.798 -performance: 0.779 -graphic: 0.761 -hypervisor: 0.758 -semantic: 0.725 -peripherals: 0.712 -mistranslation: 0.669 -PID: 0.655 -VMM: 0.655 -register: 0.646 -kernel: 0.615 -risc-v: 0.613 -permissions: 0.602 -debug: 0.595 -boot: 0.557 -assembly: 0.530 -arm: 0.476 -TCG: 0.474 -user-level: 0.470 -KVM: 0.452 -ppc: 0.443 -files: 0.442 -i386: 0.439 -x86: 0.382 - -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/118/device/131 b/results/classifier/118/device/131 deleted file mode 100644 index fe49c9df..00000000 --- a/results/classifier/118/device/131 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.862 -performance: 0.818 -architecture: 0.620 -arm: 0.521 -network: 0.451 -graphic: 0.446 -semantic: 0.343 -register: 0.214 -socket: 0.177 -files: 0.174 -risc-v: 0.170 -debug: 0.168 -boot: 0.166 -hypervisor: 0.142 -peripherals: 0.142 -ppc: 0.139 -mistranslation: 0.138 -user-level: 0.097 -virtual: 0.086 -PID: 0.078 -vnc: 0.067 -permissions: 0.033 -assembly: 0.019 -TCG: 0.015 -i386: 0.012 -x86: 0.012 -kernel: 0.006 -VMM: 0.004 -KVM: 0.000 - -QEMU's default msrs handling causes Windows 10 64 bit to crash diff --git a/results/classifier/118/device/1315 b/results/classifier/118/device/1315 deleted file mode 100644 index df9d0f0a..00000000 --- a/results/classifier/118/device/1315 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.874 -network: 0.863 -architecture: 0.657 -performance: 0.598 -hypervisor: 0.546 -debug: 0.512 -graphic: 0.438 -VMM: 0.431 -virtual: 0.355 -arm: 0.308 -assembly: 0.269 -ppc: 0.255 -semantic: 0.254 -peripherals: 0.200 -PID: 0.180 -mistranslation: 0.171 -permissions: 0.162 -x86: 0.122 -TCG: 0.121 -boot: 0.115 -i386: 0.110 -risc-v: 0.103 -user-level: 0.101 -socket: 0.091 -vnc: 0.085 -register: 0.075 -KVM: 0.066 -files: 0.014 -kernel: 0.009 - -Assertion failure in vmxnet3_activate_device diff --git a/results/classifier/118/device/1318 b/results/classifier/118/device/1318 deleted file mode 100644 index aee574a8..00000000 --- a/results/classifier/118/device/1318 +++ /dev/null @@ -1,49 +0,0 @@ -x86: 0.956 -device: 0.945 -peripherals: 0.914 -graphic: 0.910 -architecture: 0.874 -network: 0.865 -hypervisor: 0.861 -kernel: 0.813 -PID: 0.801 -performance: 0.796 -socket: 0.766 -ppc: 0.759 -virtual: 0.748 -permissions: 0.700 -register: 0.679 -semantic: 0.655 -vnc: 0.647 -debug: 0.575 -assembly: 0.569 -risc-v: 0.533 -VMM: 0.507 -arm: 0.454 -TCG: 0.440 -KVM: 0.409 -boot: 0.403 -i386: 0.399 -user-level: 0.383 -files: 0.341 -mistranslation: 0.287 - -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/118/device/132 b/results/classifier/118/device/132 deleted file mode 100644 index ab19415a..00000000 --- a/results/classifier/118/device/132 +++ /dev/null @@ -1,31 +0,0 @@ -device: 0.923 -architecture: 0.847 -debug: 0.825 -virtual: 0.758 -register: 0.735 -assembly: 0.510 -arm: 0.469 -kernel: 0.418 -graphic: 0.417 -x86: 0.412 -performance: 0.400 -i386: 0.344 -mistranslation: 0.304 -hypervisor: 0.301 -semantic: 0.300 -network: 0.235 -peripherals: 0.216 -risc-v: 0.214 -boot: 0.210 -VMM: 0.199 -ppc: 0.182 -user-level: 0.059 -vnc: 0.042 -permissions: 0.036 -PID: 0.035 -TCG: 0.014 -socket: 0.006 -files: 0.006 -KVM: 0.004 - -AVX instruction VMOVDQU implementation error for YMM registers diff --git a/results/classifier/118/device/1332234 b/results/classifier/118/device/1332234 deleted file mode 100644 index 5ad6be08..00000000 --- a/results/classifier/118/device/1332234 +++ /dev/null @@ -1,87 +0,0 @@ -device: 0.945 -semantic: 0.903 -user-level: 0.870 -graphic: 0.838 -mistranslation: 0.825 -permissions: 0.821 -ppc: 0.801 -PID: 0.795 -architecture: 0.760 -hypervisor: 0.710 -register: 0.703 -assembly: 0.701 -vnc: 0.693 -performance: 0.692 -x86: 0.680 -kernel: 0.670 -socket: 0.659 -risc-v: 0.654 -boot: 0.643 -files: 0.639 -network: 0.621 -VMM: 0.582 -KVM: 0.555 -i386: 0.539 -peripherals: 0.523 -TCG: 0.518 -arm: 0.498 -debug: 0.462 -virtual: 0.190 - -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