diff options
Diffstat (limited to 'results/classifier/zero-shot/108/network')
65 files changed, 2275 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/network/05479587 b/results/classifier/zero-shot/108/network/05479587 new file mode 100644 index 000000000..0e1b70686 --- /dev/null +++ b/results/classifier/zero-shot/108/network/05479587 @@ -0,0 +1,93 @@ +network: 0.963 +semantic: 0.866 +device: 0.811 +socket: 0.716 +performance: 0.669 +PID: 0.618 +permissions: 0.584 +graphic: 0.576 +boot: 0.474 +vnc: 0.464 +files: 0.395 +KVM: 0.374 +debug: 0.314 +other: 0.200 + +[Qemu-devel] [BUG] network qga : windows os lost ip address of the network card in some cases + +We think this problem coulde be solevd in qga modulesãcan anybody give some +advice ? + + +[BUG] network : windows os lost ip address of the network card in some cases + +we found this problem for a long time ãFor example, if we has three network +card in virtual xml file ï¼such as "network connection 1" / "network connection +2"/"network connection 3" ã + +Echo network card has own ip address ï¼such as 192.168.1.1 / 2.1 /3.1 , when +delete the first card ï¼reboot the windows virtual os, then this problem +happened ! + + + + +we found that the sencond network card will replace the first one , then the +ip address of "network connection 2 " become 192.168.1.1 ã + + +Our third party users began to complain about this bug ãAll the business of the +second ip lost !!! + +I mean both of windows and linux has this bug , we solve this bug in linux +throught bonding netcrad pci and mac address ã + +There is no good solution on windows os . thera are ? we implemented a plan to +resumption of IP by QGA. Is there a better way ? + + + + + + + + +åå§é®ä»¶ + + + +å件人ï¼å°¹ä½ä¸º10144574 +æ¶ä»¶äººï¼ address@hidden +æ¥ æ ï¼2017å¹´04æ14æ¥ 16:46 +主 é¢ ï¼[BUG] network : windows os lost ip address of the network card in some +cases + + + + + + +we found this problem for a long time ãFor example, if we has three network +card in virtual xml file ï¼such as "network connection 1" / "network connection +2"/"network connection 3" ã + +Echo network card has own ip address ï¼such as 192.168.1.1 / 2.1 /3.1 , when +delete the first card ï¼reboot the windows virtual os, then this problem +happened ! + + + + +we found that the sencond network card will replace the first one , then the +ip address of "network connection 2 " become 192.168.1.1 ã + + +Our third party users began to complain about this bug ãAll the business of the +second ip lost !!! + +I mean both of windows and linux has this bug , we solve this bug in linux +throught bonding netcrad pci and mac address ã + +There is no good solution on windows os . thera are ? we implemented a plan to +resumption of IP by QGA. Is there a better way ? + diff --git a/results/classifier/zero-shot/108/network/1054180 b/results/classifier/zero-shot/108/network/1054180 new file mode 100644 index 000000000..c509c1559 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1054180 @@ -0,0 +1,38 @@ +network: 0.951 +performance: 0.869 +graphic: 0.835 +device: 0.778 +files: 0.728 +vnc: 0.641 +semantic: 0.558 +socket: 0.476 +other: 0.370 +PID: 0.332 +debug: 0.312 +boot: 0.263 +permissions: 0.176 +KVM: 0.155 + +DNS activity in slirp (user networking) mode quickly depletes file descriptors and crashes qemu + +Hi, we have encountered quite some trouble with filedescriptor depletion of the qemu process. We have figured out that it can be demonstrated easily by doing a lot of DNS queries inside the VM -- in our real world scenario this is caused by running centos network install with a fast mirror. + +This situation is further problematic because qemu can't handle fd depletion very well: +1) if ulimit is 1024 then qemu hangs in infinite loop whenever it tries to open the 1025th fd +2) setting ulimit >1024 does not help that much because qemu uses select and max. fd set size is 1024 per default => qemu crashes because of buffer overflow in select() +3) setting ulimit > 1024 AND recompiling with large enough fd set size AND disabling gcc's fortify source seems to work, but that's really just a hot-fix + +The problem can be replicated quite easily by running something like + +while :; do echo >/dev/udp/10.0.2.3/53; done + +inside a Linux VM -- crash comes very soon. + +This problem is present in current qemu (1.2.0) and in earlier as well. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9 or a release candidate of 2.10)? + +Also could you please provide the exact command line that you use to start QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/1196727 b/results/classifier/zero-shot/108/network/1196727 new file mode 100644 index 000000000..df52ce011 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1196727 @@ -0,0 +1,162 @@ +network: 0.961 +permissions: 0.958 +socket: 0.953 +debug: 0.949 +other: 0.938 +device: 0.937 +performance: 0.937 +semantic: 0.931 +PID: 0.926 +graphic: 0.925 +boot: 0.915 +vnc: 0.904 +files: 0.903 +KVM: 0.796 + +SLIRP on Windows 7 64-bit host or is it me? + + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 +gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + +I'm new to Windows 7 64-bit as a host for QEMU (previously I was running QEMU on Windows XP with no issues) so it could be me, now on Windows 7 SLIRP only works for me connecting internally from the host to the guest via SLIRP redirect, but any outbound requests from the guest to the Internet are failing with the following: + +if_start... +m_get... + m = 61f7bd40 +ip_input... + m = 61f7bd40 + m_len = 48 +tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 +tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error +icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 +m_get... + m = 61f7b6c0 +ip_output... + so = 0 + m0 = 61f7b6c0 +if_output... + so = 0 + ifm = 61f7b6c0 +if_start... +arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 +m_free... + m = 61f7b6c0 +tcp_close... + tp = 377840 +m_free... + m = 0 +m_free... + m = 61f7bd40 + +Am I doing something wrong with my Windows host configuration or is this a bug in SLIRP only on W64 and not W32? + +I confirmed it wasn't my host, I successfully ran a test on the same host with a 32-bit QEMU build and SLIRP works fine, for 1.6.0-rc3 as well. + +It could be my x86_64-w64-mingw32-gcc compiler version, I tested 4.8 and 4.7, maybe they're too new? Is there a specific gcc version known to work? I can build a new cross-compiler if need be. + +The reason I want the 64-bit build to work is to raise the guest memory. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +Hi, you can close this ticket. I can't remember what I did to get it working. + +Sent from Yahoo Mail on Android + + On Thu, Jul 20, 2017 at 8:16 AM, Thomas Huth<email address hidden> wrote: Triaging old bug tickets ... can you still reproduce this problem with +the latest version of QEMU (currently v2.9.0)? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1196727 + +Title: + SLIRP on Windows 7 64-bit host or is it me? + +Status in QEMU: + Incomplete + +Bug description: + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 + gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + + I'm new to Windows 7 64-bit as a host for QEMU (previously I was + running QEMU on Windows XP with no issues) so it could be me, now on + Windows 7 SLIRP only works for me connecting internally from the host + to the guest via SLIRP redirect, but any outbound requests from the + guest to the Internet are failing with the following: + + if_start... + m_get... + m = 61f7bd40 + ip_input... + m = 61f7bd40 + m_len = 48 + tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 + tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error + icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 + m_get... + m = 61f7b6c0 + ip_output... + so = 0 + m0 = 61f7b6c0 + if_output... + so = 0 + ifm = 61f7b6c0 + if_start... + arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 + m_free... + m = 61f7b6c0 + tcp_close... + tp = 377840 + m_free... + m = 0 + m_free... + m = 61f7bd40 + + Am I doing something wrong with my Windows host configuration or is + this a bug in SLIRP only on W64 and not W32? + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1196727/+subscriptions + + +OK, thanks for your answer - so I'm closing the ticket now + diff --git a/results/classifier/zero-shot/108/network/1279 b/results/classifier/zero-shot/108/network/1279 new file mode 100644 index 000000000..5affdffd0 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1279 @@ -0,0 +1,23 @@ +network: 0.990 +device: 0.860 +graphic: 0.690 +vnc: 0.532 +semantic: 0.344 +debug: 0.279 +socket: 0.265 +KVM: 0.242 +boot: 0.234 +PID: 0.190 +performance: 0.183 +other: 0.144 +permissions: 0.113 +files: 0.061 + +please assist resolving windows networking issue +Description of problem: +After Installation of Windows, for Intel E1000 , Realtek and VirtIO, Windows shows "Error Code 56: Windows is Still Setting Up the Class Configuration For This Device" in device manager and Network won't work +Steps to reproduce: +Install Windows 10 VM on Proxmox 7.2 with virtual hardware Version 6.1 +You get the error code above. When using virtio nic , during installation of the kvm-qemu-virtio driver/agent package, the installer get's stuck and finally fails. + +If you downgrade to virtual hardware 5.1 , the problem goes away. diff --git a/results/classifier/zero-shot/108/network/1286 b/results/classifier/zero-shot/108/network/1286 new file mode 100644 index 000000000..dda980886 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1286 @@ -0,0 +1,16 @@ +network: 0.923 +device: 0.826 +semantic: 0.709 +PID: 0.558 +other: 0.554 +permissions: 0.510 +performance: 0.407 +files: 0.387 +boot: 0.313 +vnc: 0.246 +debug: 0.209 +graphic: 0.196 +socket: 0.102 +KVM: 0.074 + +netdev tftp option docs don't mention that the TFTP server is read-only diff --git a/results/classifier/zero-shot/108/network/1297781 b/results/classifier/zero-shot/108/network/1297781 new file mode 100644 index 000000000..fa9c30aba --- /dev/null +++ b/results/classifier/zero-shot/108/network/1297781 @@ -0,0 +1,28 @@ +network: 0.940 +device: 0.876 +files: 0.779 +boot: 0.708 +performance: 0.664 +vnc: 0.637 +graphic: 0.544 +PID: 0.540 +other: 0.539 +semantic: 0.440 +socket: 0.432 +debug: 0.420 +permissions: 0.364 +KVM: 0.334 + +Network device cannot communicate with host machine + +I know this used to work but it doesnt work any more using qemu 1.4.2 on fedora 19 everything works fine +except when i add a NIC sharing the main interface from the host (not the virtual network) + +the hosts ip is 10.0.0.4, the router is 10.0.0.1 so when i boot my virtual machine it gets an ip from the router no problem +i get on the internet fine, and i can connect (ping,ftp, samba whatever) to all the computers on the network except the host +10.0.0.4 i can't ping it, i cant do anything to it, but i can connect to all the other computers on the network and i know i used to be able to do this because thats how i shared files between the host and windows guest, with samba... but now i can't browse the host computer because it can't communicate... please help. + +Triaging old bug tickets ... How did you start QEMU here? Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/1299 b/results/classifier/zero-shot/108/network/1299 new file mode 100644 index 000000000..ed649f045 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1299 @@ -0,0 +1,39 @@ +network: 0.973 +other: 0.891 +graphic: 0.862 +device: 0.852 +files: 0.817 +semantic: 0.816 +performance: 0.810 +permissions: 0.742 +vnc: 0.619 +socket: 0.614 +debug: 0.569 +PID: 0.553 +boot: 0.489 +KVM: 0.356 + +User networking with an SMB Share while not running as root +Description of problem: +When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED. + +This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now. +Steps to reproduce: +1. Start a VM with a SMB share attached to it +2. Create a test file to upload `touch test-file.txt` +3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt' +Additional information: +QEMU has been using Samba for it's SMB shares for quite some time now. +But in the 4.17.x release a bug has appeared in the MacOS Build of Samba. + +I've filed a bug with Samba, and suggested a fix for it. +https://bugzilla.samba.org/show_bug.cgi?id=15215 + +The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly. +But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case. + +Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner. + +As a side note, on Linux this bug does not appear to exist as of yet. +The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install). +But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation. diff --git a/results/classifier/zero-shot/108/network/1451 b/results/classifier/zero-shot/108/network/1451 new file mode 100644 index 000000000..d1dfce7e1 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1451 @@ -0,0 +1,16 @@ +network: 0.978 +vnc: 0.949 +device: 0.895 +performance: 0.827 +boot: 0.601 +debug: 0.583 +graphic: 0.517 +socket: 0.515 +PID: 0.453 +KVM: 0.311 +semantic: 0.224 +other: 0.135 +permissions: 0.106 +files: 0.089 + +Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed. diff --git a/results/classifier/zero-shot/108/network/1482 b/results/classifier/zero-shot/108/network/1482 new file mode 100644 index 000000000..9c307ae69 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1482 @@ -0,0 +1,30 @@ +network: 0.986 +graphic: 0.762 +device: 0.604 +semantic: 0.527 +boot: 0.506 +performance: 0.480 +PID: 0.466 +files: 0.421 +permissions: 0.392 +vnc: 0.320 +other: 0.291 +debug: 0.287 +socket: 0.216 +KVM: 0.074 + +Network failed in qemu-7.2.0 +Description of problem: +After I created and installed Ubuntu 20.04 img in qemu virtual machine from Ubuntu 20.04 iso, I found that the network could not work normally, the network settings wasn't right yet. +Steps to reproduce: +1. Download the source code of qemu-7.2.0 using command "wget https://download.qemu.org/qemu-7.2.0.tar.xz"; +2. Untar using command "tar Jxvf qemu-7.2.0.tar.xz"; +3. Configure with command "./configure --target-list=x86_64-softmmu" under root of qemu source code; +4. Build with command "make"; +5. Install with command "make install" or "sudo make install"; +5. Create image with command "qemu-img create -f qcow2 Ubuntu2004.img 40G"; +5. Launch and install guest with ubuntu 20.04 iso using command "qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -boot once=d -cdrom ../iso_images/Ubuntu-20.04.5-desktop-amd.iso -drive file=./Ubuntu2004.img -device ac97"; +6. After system installed, launch guest with command "qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -drive file=./Ubuntu2004.img -device ac97" +Additional information: +1. When I used qemu version 7.1.0, that is qemu-7.1.0, and go through the same steps above, then the network worked normally, and the network setting was right. +2. Windows images from Windows iso(s) had the same phenomenon. diff --git a/results/classifier/zero-shot/108/network/1543163 b/results/classifier/zero-shot/108/network/1543163 new file mode 100644 index 000000000..1bd06ee3f --- /dev/null +++ b/results/classifier/zero-shot/108/network/1543163 @@ -0,0 +1,81 @@ +network: 0.967 +device: 0.964 +performance: 0.957 +PID: 0.954 +socket: 0.953 +boot: 0.953 +graphic: 0.944 +KVM: 0.940 +vnc: 0.938 +debug: 0.935 +other: 0.919 +permissions: 0.916 +files: 0.906 +semantic: 0.892 + +VMs unable to boot from network with e1000 since 2.2 + +With KVM/QEMU version 1.4, using e1000 NIC, virtual machines boot from network alright; they get an IP from DHCP server (machine A), then connect to Microsoft System Center (machine B) and proceed to boot into Windows PE, install images etc. + +However, with versions at least 2.2 and 2.5, using same NIC, virtual machines fail to boot from network; they still get an IP from A, but then fail "contacting B using gateway (0.0.0.0). Different NICs do not help except for i82551, which however causes problems further down the road (presumably because there is no driver for that card in PE (based on Windows 7/8/10)). + +Note that actual physical machines work. + +Wireshark reveals this: + +QEMU 1.4 + Intel e1000 +********************** +1) client sends DHCP discover +2) machine A answers, offers an IP, gateway and itself as next server +3) machine B answers, offers no IP, but gateway and itself as next server +4) client requests the IP +5) machine A ACKs +6) client sends unicast request for ??? to B +7) B offers (unicast) a boot file (some .com) +8) client sends another unicast request for ??? to B +9) B again offers the boot file +(then they chat a bit, B offers another file, client downloads some stuff via TFTP etc.) + + +QEMU 2.2/2.5 + Intel e1000 +************************** +1) client sends DHCP discover +2) machine A answers, offers an IP, gateway and itself as next server +3) machine B answers, offers no IP, but gateway and itself as next server +4) client requests the IP +5) machine A ACKs +6) client sends _broadcast_ request for ??? to B +7) B offers (likewise broadcast) a boot file +8) client sends another request, this time unicast and claims "Client IP address = 0.0.0.0" +(and it basically hangs) + + +So, since some time after 1.4, QEMUlated machines with otherwise trusty e1000 can no longer boot from network and it might be due to different behaviour. + +Probably the same issue in different scenario: DHCP server is running on the host machine (VMs use virtual NICs connected to a bridge) and is also configured to do PXE, which works, but only when VMs are launched in BIOS mode. When launched in UEFI mode using Tianocore, they fail. Now the interesting bit is again provided by Wireshark: + + +BIOS mode +********* +1) VM sends DHCP discover, flag 0x0000 (Unicast) +2) DHCP replies with an offer, also 0x0000 (Unicast) +3) normal process continues + + +UEFI MODE +******** +1) VM sends DHCP discover, flag 0x8000 (Broadcast) +2) DHCP replies with an offer, also 0x8000 (Broadcast) +3) VM ignores the offer +4) goto 1) + +The UEFI PXE issue was caused by a typo in DHCP server config file; the server then did not send DHCP option, if I remember correctly, 67. +Nevertheless, that inspired me and I will further investigate the original issue with SCCM and focus on DHCP options. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I have 3.10 and I managed to boot with e1000 at least in BIOS mode. I am not sure about UEFI mode, because I get no output on "screen" for whatever, perhaps unrelated reason. +Anyway, I think we may close it for now. + +Ok, thanks for checking. Closing now. + diff --git a/results/classifier/zero-shot/108/network/1569988 b/results/classifier/zero-shot/108/network/1569988 new file mode 100644 index 000000000..199a9fcbb --- /dev/null +++ b/results/classifier/zero-shot/108/network/1569988 @@ -0,0 +1,73 @@ +network: 0.930 +device: 0.926 +PID: 0.887 +other: 0.884 +vnc: 0.884 +graphic: 0.883 +socket: 0.861 +semantic: 0.852 +debug: 0.842 +permissions: 0.827 +performance: 0.795 +files: 0.765 +boot: 0.743 +KVM: 0.647 + +[2.6] user network broken reaching foreign servers on Win64 + +Both on master and, starting with 2016-03-22 builds from http://qemu.weilnetz.de/w64/, user mode network can't reach foreign servers. For example, wget http://mifritscher resolves the DNS, but then the message "network target couldn't be reached" occures. 2016-03-03 works fine. I suspect the IPv6 changes. My connection is IPv4 only. + +I tested via knoppix 7.6. The command line is + +qemu-system-x86_64.exe -m 512 -k de --cdrom c:\Users\michaelfritscher\Downloads\linux\KNOPPIX_V7.4.2DVD-2014-09-28-DE.iso -netdev user,id=mynet0,restrict=n -device e1000,netdev=mynet0 + +Under Linux, it is working fine. + +Another thing: if I disable ipv6, ipv4 runs still in sort of a timeout before writing Network is unreachable (ENETUNREACH), while ipv6 says this without delay (which is ok/good) + + +It looks like this commit caused the regression: + +$ git bisect bad +c619644067f98098dcdbc951e2dda79e97560afa is the first bad commit +commit c619644067f98098dcdbc951e2dda79e97560afa +Author: Daniel P. Berrange <email address hidden> +Date: Mon Mar 7 11:19:18 2016 +0000 + + osdep: fix socket_error() to work with Mingw64 + + +Here is a patch which fixes the problem. + +diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c +index 2027a75..696867f 100644 +--- a/slirp/tcp_input.c ++++ b/slirp/tcp_input.c +@@ -587,7 +587,7 @@ findso: + + if ((tcp_fconnect(so, so->so_ffamily) == -1) && + #if defined(_WIN32) +- socket_error() != WSAEWOULDBLOCK ++ socket_error() != EAGAIN + #else + (errno != EINPROGRESS) && (errno != EWOULDBLOCK) + #endif + + +Latest QEMU needs a slightly different patch: + +diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c +index 5433e7f..3be2d2f 100644 +--- a/slirp/tcp_input.c ++++ b/slirp/tcp_input.c +@@ -659,6 +659,7 @@ findso: + } + + if ((tcp_fconnect(so, so->so_ffamily) == -1) && ++ socket_error() != EAGAIN && + (errno != EINPROGRESS) && (errno != EWOULDBLOCK) + ) { + uint8_t code; + +Fixed since v2.6.0-rc3 release. + diff --git a/results/classifier/zero-shot/108/network/1574327 b/results/classifier/zero-shot/108/network/1574327 new file mode 100644 index 000000000..186949ef7 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1574327 @@ -0,0 +1,35 @@ +network: 0.940 +device: 0.849 +performance: 0.842 +graphic: 0.732 +vnc: 0.612 +semantic: 0.571 +files: 0.539 +permissions: 0.514 +socket: 0.504 +boot: 0.469 +PID: 0.457 +debug: 0.379 +other: 0.244 +KVM: 0.139 + +qemu-system-x86_64 -net nic,model=help outputs to stderr instead of std + +qemu-system-x86_64 -net nic,model=help + +output comes to stderr instead of std + + +qemu-system-x86_64 -net nic,model=help -> stdout +qemu-system-x86_64 -machine help -> stdout +qemu-system-x86_64 -cpu help -> stdout + +as of https://github.com/qemu/qemu/blob/044d65525f6ac2093042ae18dbf8c1300b5c1c18/net/net.c#L831 + +I run qemu 2.5 on x86_64 + +kind regards + +Finally fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7b71e03af98fd7b5e1 + diff --git a/results/classifier/zero-shot/108/network/1604303 b/results/classifier/zero-shot/108/network/1604303 new file mode 100644 index 000000000..321264051 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1604303 @@ -0,0 +1,35 @@ +network: 0.963 +KVM: 0.959 +device: 0.898 +graphic: 0.843 +boot: 0.657 +socket: 0.650 +PID: 0.613 +vnc: 0.603 +files: 0.564 +semantic: 0.553 +other: 0.536 +performance: 0.511 +permissions: 0.489 +debug: 0.315 + +Solaris on KVM/QEMU: WARNING rtls0: Failure resetting PHY + +When running Solaris (both version 10 and 11) on a QEMU/KVM virtual host, the Solaris guest displays this warning just after starting the system: +WARNING rtls0: Failure resetting PHY. + +Although the networking seems to work fine. + +I have this network device model selected for the Solaris guest: rtl8139 + +See also: +http://www.linux-kvm.org/page/Guest_Support_Status#UNIX_Family:_Solaris.2FOpenSolaris + +version: qemu-system-x86.x86_64 2:2.6.0-5.fc24 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/1656927 b/results/classifier/zero-shot/108/network/1656927 new file mode 100644 index 000000000..a72147b96 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1656927 @@ -0,0 +1,37 @@ +network: 0.955 +vnc: 0.654 +device: 0.646 +socket: 0.602 +performance: 0.574 +KVM: 0.556 +graphic: 0.435 +files: 0.434 +PID: 0.385 +semantic: 0.349 +permissions: 0.312 +other: 0.272 +debug: 0.224 +boot: 0.222 + +Network (TCP) access regression + +Starting a VM with + +/usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winp +ro.qcow,index=0,media=disk,format=qcow2 -m 4096 -vga vmware -vnc :3 -k en-us -device rtl8139,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfw +d=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemonize + +in 2.5.1, all works fine + +in any version after 2.5.1.1, the network terminate TCP connections after a certain period . + +To reproduce, starts an app that use always connected TCP sockets (I am using Metatrader 4), let it run a an hour, the app does not realize the TCP is out of order but the TCP connection is closed by QEMU + +in 2.5.1.x, Metatrader works perfectly + +Thank you for your help + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/1662 b/results/classifier/zero-shot/108/network/1662 new file mode 100644 index 000000000..36116cf96 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1662 @@ -0,0 +1,50 @@ +network: 0.989 +performance: 0.984 +vnc: 0.965 +socket: 0.961 +device: 0.945 +PID: 0.945 +debug: 0.943 +graphic: 0.943 +boot: 0.889 +files: 0.850 +permissions: 0.594 +semantic: 0.554 +KVM: 0.440 +other: 0.199 + +qemu-system-loongarch64 start Loongnix system coredump +Description of problem: + +Steps to reproduce: +1. build qemu: + ./configure --prefix=/usr --disable-werror --disable-gtk --target-list="loongarch64-softmmu"\ + --enable-debug + make -j32 +2. get bios and qcow2: + wget https://mirrors.wsyu.edu.cn/loongarch/archlinux/images/QEMU_EFI_7.2.fd + wget http://pkg.loongnix.cn/loongnix/isos/Loongnix-20.4/Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 +3. start Loongnix + ./build/qemu-system-loongarch64 \ + -m 8G \ + -cpu la464 \ + -machine virt \ + -smp 16 \ + -bios ./QEMU_EFI_7.2.fd \ + -serial stdio \ + -device virtio-gpu-pci \ + -net nic -net user \ + -device nec-usb-xhci,id=xhci,addr=0x1b \ + -device usb-tablet,id=tablet,bus=xhci.0,port=1 \ + -device usb-kbd,id=keyboard,bus=xhci.0,port=2 \ + -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 + +4. VNC connect +5. use the system + login loongson/Loongson20 +6. qemu coredump + + qemu-system-loongarch64: /root/work/qemu/include/tcg/tcg.h:675: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. +./start-loongnix.sh: line 13: 40242 Aborted (core dumped) ./build/qemu-system-loongarch64 -m 8G -cpu la464 -machine virt -smp 16 -bios ./QEMU_EFI_7.2.fd -serial stdio -device virtio-gpu-pci -net nic -net user -device nec-usb-xhci,id=xhci,addr=0x1b -device usb-tablet,id=tablet,bus=xhci.0,port=1 -device usb-kbd,id=keyboard,bus=xhci.0,port=2 -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 +Additional information: + diff --git a/results/classifier/zero-shot/108/network/1719689 b/results/classifier/zero-shot/108/network/1719689 new file mode 100644 index 000000000..a99603064 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1719689 @@ -0,0 +1,36 @@ +network: 0.975 +other: 0.764 +graphic: 0.723 +boot: 0.690 +vnc: 0.593 +device: 0.579 +socket: 0.574 +semantic: 0.423 +debug: 0.417 +PID: 0.401 +performance: 0.377 +permissions: 0.358 +KVM: 0.274 +files: 0.202 + +[feature request] add flag to treat warnings as errors + +Since booting could potentially take a lot of time and warnings are likely to indicate that something is wrong, it would be useful to have a command line flag which would abort the boot if there are any warnings. + +An example might be network configuration. The following output most likely indicates that there is something the user has to fix before starting and being able to use the guest os. + +Warning: hub port hub0port0 has no peer +Warning: vlan 0 with no nics +Warning: netdev hub0port0 has no peer +Warning: requested NIC (anonymous, model vitrio-net-device) was not created (not supported by this machine?) + +Ideally, there would be an option the user could pass which would cause qemu to print these warnings then exit, rather than boot the kernel. + +Alternatively, or additionally, a dry run option would be helpful for the same purpose: making sure qemu get to the booting the kernel stage with everything in working order so that you do not have to wait for the kernel to boot and then shut down while debugging things like networking (things which can be debugged (at least partially) without booting, or trying to boot, the guest os). + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/1732 b/results/classifier/zero-shot/108/network/1732 new file mode 100644 index 000000000..050f3812e --- /dev/null +++ b/results/classifier/zero-shot/108/network/1732 @@ -0,0 +1,18 @@ +network: 0.988 +graphic: 0.925 +semantic: 0.904 +other: 0.827 +performance: 0.809 +device: 0.767 +debug: 0.747 +PID: 0.564 +socket: 0.508 +vnc: 0.480 +boot: 0.349 +permissions: 0.219 +KVM: 0.204 +files: 0.041 + +Is there a way to disconnect the network of guest? +Description of problem: +When guest is running,I wan to disconnect the network(not detach the net),which should keep disconnect after migrate or restart if we not reconnect it againt. Whether qemu has some ways to do it? diff --git a/results/classifier/zero-shot/108/network/1783 b/results/classifier/zero-shot/108/network/1783 new file mode 100644 index 000000000..49b389da5 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1783 @@ -0,0 +1,18 @@ +network: 0.989 +graphic: 0.758 +other: 0.679 +device: 0.635 +boot: 0.442 +vnc: 0.417 +semantic: 0.405 +permissions: 0.235 +debug: 0.203 +PID: 0.177 +KVM: 0.084 +socket: 0.066 +performance: 0.063 +files: 0.028 + +Emulate Breakout Network Connections +Additional information: +This functionality is required to model/QA real-world implementations for datacenter fabrics in virtual environments. Break-out cabling is how port density is achieved in practice on modern optical fabrics. diff --git a/results/classifier/zero-shot/108/network/1832281 b/results/classifier/zero-shot/108/network/1832281 new file mode 100644 index 000000000..b78ea4581 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1832281 @@ -0,0 +1,99 @@ +network: 0.989 +socket: 0.987 +vnc: 0.985 +device: 0.979 +performance: 0.965 +debug: 0.952 +other: 0.950 +files: 0.933 +graphic: 0.931 +permissions: 0.929 +PID: 0.926 +semantic: 0.879 +boot: 0.868 +KVM: 0.714 + +tcg bug master / 4.0.0 v8 operation >>> and |= + +vm guest is linux, executed with tcg +running this Node.js snippet leads to + +$ node +> a = undefined +undefined +> a >>> 0 +4294967295 + +host node +$ node +> a = undefined +undefined +> a >>> 0 +0 + +same with |= + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> let buffer +undefined +> buffer |= 0 +0 + +vm with tcg: + +$ ./out/Release/node --version +v12.4.0 +./out/Release/node -e "let buffer; buffer |= 0; console.log(buffer);" +-1 + + +vm guest is debian x86_64 latest release +vm guest is started with ./x86_64-softmmu/qemu-system-x86_64 -vnc :0 -cdrom debian-9.9.0-amd64-netinst.iso -m 4G -smp cores=6,threads=1,sockets=1 -nic user,hostfwd=tcp:ipv4addr:2233-:22 -cpu qemu64 debian.img + +git tag v4.0.0 and master, commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf, for building qemu-system-x86_64 was used. + +Node.js as compiled on the vm guest (v12.4.0 / master) + + +see also +https://github.com/nodejs/node/issues/19348#issuecomment-500465502 + +I need further assistance to track down the cause of the bug. + +Kind regards +Manuel + +This might be the same underlying problem as LP:1815423 which also mentions some issues with Javascript calculations involving arithmetic operations on a js "undefined" value. That bug has a C-only reproduce case so is probably a good place to start for anybody interesting in investigating and fixing it. + + +https://<email address hidden>/ is a patch which I think probably fixes this bug -- could you test it? (I don't have an x86 vm with node.js in it to test with.) + +Hi Peter, + +I will try the tag and report back. + +result: + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> a = undefined +undefined +> a >>> 0 +0 +> let buffer +undefined +> buffer |= 0 +0 + + +Thanks for the patch :-) + +Thanks a lot for testing it! + + +Patch had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1e8a98b53867f61da9c + diff --git a/results/classifier/zero-shot/108/network/1861875 b/results/classifier/zero-shot/108/network/1861875 new file mode 100644 index 000000000..6fbd98599 --- /dev/null +++ b/results/classifier/zero-shot/108/network/1861875 @@ -0,0 +1,50 @@ +network: 0.926 +device: 0.774 +performance: 0.707 +graphic: 0.688 +other: 0.676 +PID: 0.658 +vnc: 0.577 +semantic: 0.574 +socket: 0.563 +files: 0.520 +permissions: 0.477 +debug: 0.448 +boot: 0.411 +KVM: 0.340 + +VDE networking barely working + +Running qemu with a vde_switch and slirpvde: + + vde_switch -F -sock /tmp/qemu_vde_switch -M /tmp/qemu_vde_mgmt + slirpvde -s /tmp/qemu_vde_switch -dhcp + qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none -nodefaults -accel hax -net nic,macaddr=52:54:00:0e:e0:61,model=virtio -net vde,sock=/tmp/qemu_vde_switch -device virtio-rng-pci -drive file=worker.qcow2,if=virtio -drive file=cloud-init.iso,format=raw,if=virtio + +There is some network connectivity, ping and curl work, but bigger transfers like apt-get update break with the following errors printed in the output of vde_switch: + + vde_switch: send_sockaddr port 2: No buffer space available + vde_switch: send_sockaddr port 2: No buffer space available + vde_switch: send_sockaddr port 2: No buffer space available + +I've tried to change the MTU size and model of the adapter inside of the VM, but nothing worked. + +OS: macOS 10.15.2 +qemu: 4.2.0 +vde2 (vde_switch / slirpvde): 2.3.2 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/1881 b/results/classifier/zero-shot/108/network/1881 new file mode 100644 index 000000000..ec8d734ea --- /dev/null +++ b/results/classifier/zero-shot/108/network/1881 @@ -0,0 +1,30 @@ +network: 0.981 +socket: 0.980 +graphic: 0.904 +device: 0.894 +PID: 0.888 +performance: 0.822 +permissions: 0.821 +vnc: 0.806 +files: 0.723 +debug: 0.707 +semantic: 0.657 +boot: 0.517 +other: 0.401 +KVM: 0.215 + +netdev-socket test_stream_unix() is unreliable +Description of problem: +test_stream_unix is unreliable and causes random CI job failures such as this one: +https://gitlab.com/qemu-project/qemu/-/jobs/5020899550 + +``` +576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") ERROR +576/839 qemu:qtest+qtest-sh4 / qtest-sh4/netdev-socket ERROR 62.85s killed by signal 6 SIGABRT +>>> MALLOC_PERTURB_=249 QTEST_QEMU_BINARY=./qemu-system-sh4 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img /home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/tests/qtest/netdev-socket --tap -k +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +** +ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") +(test program exited with status code -6) +``` diff --git a/results/classifier/zero-shot/108/network/190 b/results/classifier/zero-shot/108/network/190 new file mode 100644 index 000000000..7f0714933 --- /dev/null +++ b/results/classifier/zero-shot/108/network/190 @@ -0,0 +1,16 @@ +network: 0.942 +device: 0.914 +debug: 0.851 +performance: 0.770 +socket: 0.683 +semantic: 0.637 +graphic: 0.525 +other: 0.483 +vnc: 0.346 +files: 0.227 +permissions: 0.166 +boot: 0.155 +PID: 0.148 +KVM: 0.019 + +'set_link net0 off' not working with e1000e driver diff --git a/results/classifier/zero-shot/108/network/198 b/results/classifier/zero-shot/108/network/198 new file mode 100644 index 000000000..d3d5b94e0 --- /dev/null +++ b/results/classifier/zero-shot/108/network/198 @@ -0,0 +1,16 @@ +network: 0.930 +device: 0.906 +performance: 0.753 +graphic: 0.448 +other: 0.423 +semantic: 0.366 +debug: 0.252 +boot: 0.208 +permissions: 0.168 +KVM: 0.096 +vnc: 0.051 +PID: 0.044 +files: 0.038 +socket: 0.023 + +USB Ethernet device (RNDIS) does not work on several tested operating systems diff --git a/results/classifier/zero-shot/108/network/2019 b/results/classifier/zero-shot/108/network/2019 new file mode 100644 index 000000000..82568aa57 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2019 @@ -0,0 +1,41 @@ +network: 0.953 +socket: 0.884 +boot: 0.784 +graphic: 0.702 +PID: 0.603 +other: 0.563 +device: 0.554 +files: 0.536 +semantic: 0.513 +performance: 0.454 +debug: 0.410 +permissions: 0.343 +vnc: 0.230 +KVM: 0.209 + +Additional network device is not recognized on windows guest vm +Description of problem: +I have a problem for using Windows 2019/2022 guest vm as QEMU. +When I add a network device more online, it isn't work and recognized. +There is an error occurs at the Device Manager. + + + +I added network device with this qmp command +``` +'{ "execute": "chardev-add", "arguments":{"id":"charnet_35", "backend": { "type" : "socket", "data" : { "addr" : { "type" : "unix", "data" : {"path" : "/tmp/17115.1''"}}, "server" : true, "wait" : false }}}}' | nc -U $socket -N +'{ "execute": "netdev_add", "arguments":{"type":"vhost-user", "id":"'hostnet_35", "chardev":"charnet_35", "queues":2 }}' | nc -U $socket -N +'{ "execute" : "device_add", "arguments" : {"driver" : "virtio-net-pci", "mq":"on" ,"vectors":6, "netdev":"hostnet_35", "id":"dpdk_35", "mac":"F2:20:AF:40:12:65", "bus" : "bridge", "addr" : "0x8", "page-per-vq": "on", "rx_queue_size" : 1024, "tx_queue_size": 1024, "mrg_rxbuf" : "on", "disable-legacy": "on", "disable-modern" : "off" , "host_mtu" : 1500, "csum" : "on", "guest_csum" : "on", "host_tso4" : "on", "host_tso6" : "on"}}' | nc -U $socket -N +``` + +But, I can check recognized additional Network device after Windows guest vm rebooted. +Steps to reproduce: +1. Boot Windows 2019/2022 guest vm +2. Add chardev, netdev, device more with qmp command as hotplug +3. Check Network device recognition on the guest os +Additional information: +- I'm using hardware vDPA offloading with mellanox NIC card. +And When I use tap device instead vhost-user at the netdev, I don't have any problem. That error does not occured + +- And second, when I disable the first NIC, The additional NIC is recognized. + diff --git a/results/classifier/zero-shot/108/network/2024 b/results/classifier/zero-shot/108/network/2024 new file mode 100644 index 000000000..234149917 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2024 @@ -0,0 +1,45 @@ +network: 0.968 +debug: 0.967 +boot: 0.958 +files: 0.943 +device: 0.912 +PID: 0.899 +graphic: 0.832 +vnc: 0.780 +performance: 0.764 +socket: 0.746 +permissions: 0.701 +semantic: 0.701 +other: 0.680 +KVM: 0.520 + +IPv6 DHCPv6 DUID-UUID Generation Issue with iPXE on QEMU 8.1.2 and SMBIOS 3.0 +Description of problem: +I'm creating this ticket in both projects affected as I'm unsure which side needs to resolve it. I discovered this bug after upgrading Proxmox to version 8.1. I use iPXE to boot in IPv6 and retrieve the configuration from a web server. I have a DHCPv6 and SLAAC server configured. + +In this configuration, iPXE is unable to generate the necessary DUID-UUID for IPv6. If I revert to the previous QEMU version (using the machine: pc-i440fx-8.0 option in Proxmox), I have no issues. The only difference I notice and understand is the switch to SMBIOS 3.0, which is 64 bits, compared to SMBIOS 2.8, which is 32 bits. It appears to be the same issue with Libvirt. By default, it uses pc-q35-8.1, and I encounter the bug. However, if I switch to pc-q35-8.0, the problem is resolved. + +I've included two sets of information in the first part. The first one is from my local computer using libvirt, making it easier to reproduce the bug. The second set is from my production environment. + +Here's the iPXE trace: + +```plaintext +iPXE> ifconf --configurator ipv6 +Configuring [ipv6] (net0 66:b5:3e:97:7d:4e)... +DHCPv6 net0 could not create DUID-UUID: No such file or directory (https://ipxe.org/2d0c203b) +No such file or directory (https://ipxe.org/2d0c203b) +``` +Steps to reproduce: +1. Create a PXE ISO with IPv6 debug options: + 1. Clone the iPXE repository with the following command: + * `git clone https://github.com/ipxe/ipxe` + 2. Navigate to the src directory: + * `cd ipxe/src` + 3. Build the iPXE ISO with IPv6 debug options using the following command: + * `DEBUG='dhcpv6,neighbour' make bin/ipxe.iso` +2. Set up a Libvirt network with DHCPv6 enabled (example configuration provided in the next section). +3. Create a virtual machine with the generated iPXE ISO and the network configured for IPv6. +4. Press `Ctrl+B` to access the iPXE shell. +5. Execute the command `ifconf --configurator ipv6` in the iPXE shell. +Additional information: +# diff --git a/results/classifier/zero-shot/108/network/2109 b/results/classifier/zero-shot/108/network/2109 new file mode 100644 index 000000000..e34571dc7 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2109 @@ -0,0 +1,16 @@ +network: 0.968 +device: 0.865 +vnc: 0.608 +boot: 0.514 +graphic: 0.379 +performance: 0.312 +socket: 0.222 +debug: 0.217 +PID: 0.172 +semantic: 0.103 +files: 0.094 +other: 0.058 +permissions: 0.020 +KVM: 0.001 + +NetBSD VM fails to install due to missing py311-expat package diff --git a/results/classifier/zero-shot/108/network/2178 b/results/classifier/zero-shot/108/network/2178 new file mode 100644 index 000000000..0ae57d066 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2178 @@ -0,0 +1,32 @@ +network: 0.989 +device: 0.933 +other: 0.916 +graphic: 0.900 +performance: 0.876 +semantic: 0.725 +boot: 0.660 +permissions: 0.596 +PID: 0.563 +socket: 0.489 +debug: 0.451 +vnc: 0.365 +files: 0.143 +KVM: 0.041 + +USB passthrough on Apple Silicon is unusable +Description of problem: +I can't get USB passthrough to work sufficiently well with wifi modems such as the RTL8187L or Atheros AR 9271. + +I only use the VM as a router since the host OS doesn't have drivers for any external wifi modems. This is a setup I've used flawlessly many times in the past with other VMs on x86 platforms for many years, but with ARM it's been one fail after another. Parallels does work with the exact same host and guest, but fails in the networking area (plus it's expensive and overkill for something this simple). I mention this because I know the guest drivers work 100% with a different VM. +Steps to reproduce: +1. Run any Linux on QEMU on any Apple Silicon mac +2. Attempt to use a Atheros AR 9271 USB device +3. Various fails including + a) USB device not showing up (lsusb) + b) device shows up and Linux attempts to attach driver, but fails (lsmod shows driver loaded but no interface listed on iwconfig) + c) interface shows up (never got the Atheros this far, but RealTek does) but the interface is slow, corrupts data, etc. + d) after re-attaching several times it will eventually stop attaching at all requiring a MacOS system reboot, which is really annoying for my workflow. + +It's basically non-functional for me. Atheros is 100% non-functional and RealTek 10% works (well enough to *sometimes* connect to the AP, but usually craps the bed if you try to do anything as simple as run a dhcp client to fetch the IP). + +If anyone knows of any other Linux ARM on Mac ARM vm solutions that allow USB passthrough please let me know. Unfortunately, VirtualBox os currently not one of them. diff --git a/results/classifier/zero-shot/108/network/2409 b/results/classifier/zero-shot/108/network/2409 new file mode 100644 index 000000000..a6de31583 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2409 @@ -0,0 +1,16 @@ +network: 0.981 +device: 0.968 +performance: 0.945 +graphic: 0.767 +semantic: 0.531 +vnc: 0.490 +PID: 0.369 +debug: 0.244 +boot: 0.233 +other: 0.107 +permissions: 0.104 +KVM: 0.096 +files: 0.022 +socket: 0.009 + +High CPU usage on network traffic on Apple laptops diff --git a/results/classifier/zero-shot/108/network/2459 b/results/classifier/zero-shot/108/network/2459 new file mode 100644 index 000000000..dec15a4cd --- /dev/null +++ b/results/classifier/zero-shot/108/network/2459 @@ -0,0 +1,16 @@ +network: 0.942 +graphic: 0.479 +semantic: 0.289 +device: 0.205 +debug: 0.155 +performance: 0.154 +socket: 0.110 +other: 0.109 +vnc: 0.098 +PID: 0.029 +permissions: 0.028 +boot: 0.025 +files: 0.004 +KVM: 0.003 + +Qemu in termux network bug diff --git a/results/classifier/zero-shot/108/network/2494 b/results/classifier/zero-shot/108/network/2494 new file mode 100644 index 000000000..32b0bc0a5 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2494 @@ -0,0 +1,16 @@ +network: 0.956 +other: 0.788 +device: 0.781 +performance: 0.731 +KVM: 0.685 +vnc: 0.658 +PID: 0.603 +debug: 0.476 +semantic: 0.447 +graphic: 0.410 +boot: 0.381 +socket: 0.352 +permissions: 0.287 +files: 0.107 + +Isolated network between VMs not visible to the host diff --git a/results/classifier/zero-shot/108/network/2514 b/results/classifier/zero-shot/108/network/2514 new file mode 100644 index 000000000..4de26e44a --- /dev/null +++ b/results/classifier/zero-shot/108/network/2514 @@ -0,0 +1,16 @@ +network: 0.981 +other: 0.825 +performance: 0.726 +vnc: 0.593 +debug: 0.590 +device: 0.556 +graphic: 0.498 +socket: 0.458 +semantic: 0.408 +PID: 0.407 +boot: 0.364 +KVM: 0.323 +permissions: 0.266 +files: 0.215 + +network unreachable to esxi 8 guest diff --git a/results/classifier/zero-shot/108/network/2528 b/results/classifier/zero-shot/108/network/2528 new file mode 100644 index 000000000..8345c8ec0 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2528 @@ -0,0 +1,24 @@ +network: 0.940 +device: 0.797 +graphic: 0.597 +debug: 0.518 +vnc: 0.402 +performance: 0.355 +socket: 0.327 +files: 0.322 +semantic: 0.311 +boot: 0.309 +PID: 0.122 +other: 0.077 +KVM: 0.059 +permissions: 0.014 + +nbd: CVE-2024-7409 fix is incomplete +Description of problem: +Patch will hit list soon, but opening issue here since if this misses 9.1, we would need to allocate a second CVE for having an incomplete fix (a remaining use-after-free) in the code originally proposed for CVE-2024-7409. +Steps to reproduce: +1. stress test of attempting repeated 'qemu-nbd --list' in parallel with repeated 'nbd-server-start/nbd-server-stop' loops in a qemu process revealed a use-after-free SEGV of nbd_server->listener +2. +3. +Additional information: + diff --git a/results/classifier/zero-shot/108/network/2623 b/results/classifier/zero-shot/108/network/2623 new file mode 100644 index 000000000..8547cfed8 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2623 @@ -0,0 +1,16 @@ +network: 0.951 +performance: 0.902 +device: 0.869 +debug: 0.577 +other: 0.450 +semantic: 0.435 +boot: 0.364 +graphic: 0.232 +socket: 0.209 +vnc: 0.191 +KVM: 0.097 +permissions: 0.084 +PID: 0.055 +files: 0.022 + +Timeout waiting for ARP/RARP packets diff --git a/results/classifier/zero-shot/108/network/2668 b/results/classifier/zero-shot/108/network/2668 new file mode 100644 index 000000000..9ac657d89 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2668 @@ -0,0 +1,18 @@ +network: 0.943 +vnc: 0.915 +device: 0.909 +socket: 0.762 +other: 0.759 +files: 0.738 +graphic: 0.658 +performance: 0.653 +boot: 0.628 +semantic: 0.606 +permissions: 0.561 +PID: 0.544 +debug: 0.504 +KVM: 0.237 + +h.264 encoding/compression support +Additional information: +noVNC now support h.264 decoding. diff --git a/results/classifier/zero-shot/108/network/2685 b/results/classifier/zero-shot/108/network/2685 new file mode 100644 index 000000000..fa07b3e82 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2685 @@ -0,0 +1,16 @@ +network: 0.926 +device: 0.769 +performance: 0.745 +debug: 0.403 +graphic: 0.383 +semantic: 0.279 +boot: 0.270 +permissions: 0.213 +PID: 0.208 +vnc: 0.172 +other: 0.140 +files: 0.119 +socket: 0.099 +KVM: 0.011 + +Netbsd 10.0 AMD64 as host fails in tcg? diff --git a/results/classifier/zero-shot/108/network/2688 b/results/classifier/zero-shot/108/network/2688 new file mode 100644 index 000000000..3c2bd46ab --- /dev/null +++ b/results/classifier/zero-shot/108/network/2688 @@ -0,0 +1,16 @@ +network: 0.956 +device: 0.742 +performance: 0.713 +vnc: 0.635 +PID: 0.542 +debug: 0.517 +KVM: 0.413 +semantic: 0.403 +socket: 0.393 +files: 0.374 +graphic: 0.367 +boot: 0.357 +other: 0.299 +permissions: 0.101 + +Add `disable_host_loopback` for network user backend diff --git a/results/classifier/zero-shot/108/network/2745 b/results/classifier/zero-shot/108/network/2745 new file mode 100644 index 000000000..794286135 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2745 @@ -0,0 +1,41 @@ +network: 0.922 +graphic: 0.715 +performance: 0.708 +other: 0.660 +device: 0.652 +permissions: 0.622 +PID: 0.611 +semantic: 0.543 +socket: 0.535 +boot: 0.330 +debug: 0.317 +files: 0.305 +KVM: 0.293 +vnc: 0.281 + +Qemu should send RARP for vhostuser regardless of whether virtio supports GUEST_ANNOUNCE +Description of problem: +When virtio reports to qemu that GUEST_ANNOUNCE is supported, qemu will not send RARP. The assumption, I think, is that guest kernel will do whatever is needed to announce the guest. The problem with this assumption is that 1) kernel won't send RARPs; 2) for IPv4 and IPv6 it will send GARPs and NAs; 3) for interfaces with no IP addresses, I think it won't send anything at all. + +RARPs are useful because they allow to notify regardless of IP configuration. I've [asked](https://issues.redhat.com/browse/RHEL-71919]) RHEL kernel folks to consider issuing RARPs from the guest kernel, but it won't happen overnight, and regardless, it's not a complete solution since we cannot expect all guests running a patched kernel with such feature. + +RARP packets are also often expected by underlying network components. For example, OVN controller has a special "activation-strategy=rarp" configuration that makes OVN wait for a RARP from destination chassis on live migration, and only then unblock traffic for the port. Since RARP is not issed by Qemu nor virtio-net, the OVN port is never unblocked (until its configuration is reset by CMS). + +I think what should be done from Qemu side is to send RARP for vhostuser ports regardless of whether virtio supports GUEST_ANNOUNCE. I **think** this can be achieved by removing this code: + +``` + /* If guest supports GUEST_ANNOUNCE do nothing */ + if (virtio_has_feature(dev->acked_features, VIRTIO_NET_F_GUEST_ANNOUNCE)) { + return 0; + } +``` +Steps to reproduce: +1. Start a VM with vhostuser* port and fresh virtio guest driver. +2. Live migrate it. +3. Observe that RARP is not sent from the migrated port. GARP (or NA for IPv6) is sent instead. +Additional information: +Some external bugs that may be relevant: + +- RHEL kernel request to send RARPs from virtio: https://issues.redhat.com/browse/RHEL-71919 (won't fix the issue for older unpatched kernels) +- Request for OVN to handle GARPs and NAs: https://issues.redhat.com/browse/FDP-1042 (won't solve for unaddressed ports!) +- An attempt to work around the issue in OpenStack Neutron OVN env by disabling activation strategy: https://issues.redhat.com/browse/OSPRH-12571 (not a great long term solution) diff --git a/results/classifier/zero-shot/108/network/2756 b/results/classifier/zero-shot/108/network/2756 new file mode 100644 index 000000000..b31173f55 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2756 @@ -0,0 +1,57 @@ +network: 0.991 +device: 0.984 +socket: 0.975 +graphic: 0.954 +vnc: 0.933 +performance: 0.929 +debug: 0.919 +KVM: 0.911 +boot: 0.843 +PID: 0.819 +permissions: 0.807 +semantic: 0.742 +other: 0.484 +files: 0.395 + +Unexpected port id 2909357808 for device virtio-serial0.0 +Description of problem: +when the VM runs for a period of time.qemu log always print the error：“Unexpected port id 2909357808 for device virtio-serial0.0”.And the spice connet display black screen.Restart the vm,it recovery. my channel is 16,Normally it will always output port less than 16,but when error it report a lage port. why it get a lage port "2909357808",Is there a data overflow? +Steps to reproduce: +1.The VM runs for a period of time + +2.report the error: "Unexpected port id 2909357808 for device virtio-serial0.0". + +3.restart to recovery. +Additional information: +qemu log: + +when vm is ok: +``` +virtio serial port 16 send control message event = 1, value = 1 +virtio serial port 0 send control message event = 1, value = 1 +virtio serial port '1' handle control message event = 3, value = 1 +virtio serial port '2' handle control message event = 3, value = 1 +virtio serial port 2 send control message event = 6, value = 1 +virtio serial port '3' handle control message event = 3, value = 1 +virtio serial port 3 send control message event = 6, value = 1 +virtio serial port '4' handle control message event = 3, value = 1 +virtio serial port 4 send control message event = 6, value = 1 +``` + + +when error: + +``` +2024-11-07T07:19:50.969383Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:19:50.969706Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +2024-11-07T07:20:00.944495Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:20:00.950544Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +2024-11-07T07:20:47.923564Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:20:47.924422Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +``` diff --git a/results/classifier/zero-shot/108/network/2758 b/results/classifier/zero-shot/108/network/2758 new file mode 100644 index 000000000..e4d188df3 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2758 @@ -0,0 +1,38 @@ +network: 0.972 +device: 0.808 +graphic: 0.741 +vnc: 0.587 +socket: 0.557 +semantic: 0.419 +performance: 0.341 +boot: 0.341 +debug: 0.330 +KVM: 0.303 +PID: 0.298 +files: 0.294 +other: 0.084 +permissions: 0.044 + +Out-of-bounds access smc91c111_readb() +Description of problem: +An out-of-bounds bug was triggered by my fuzzer. + +It looks like the code doesn't have boundary checks for `data`'s access. + +The error is `hw/net/smc91c111.c:605:24: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')` + +It's likely that the line 457 also needs a check. +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +writew 0x4e00000c 0x46084a4a +writel 0x4e00000c 0x5c022fcc +clock_step +writel 0x4e000004 0x2fffa1b1 +clock_step +readl 0x4e000008 +EOF +``` +Additional information: + diff --git a/results/classifier/zero-shot/108/network/2767 b/results/classifier/zero-shot/108/network/2767 new file mode 100644 index 000000000..5908a8cec --- /dev/null +++ b/results/classifier/zero-shot/108/network/2767 @@ -0,0 +1,52 @@ +network: 0.925 +socket: 0.894 +device: 0.723 +PID: 0.701 +graphic: 0.642 +performance: 0.611 +vnc: 0.532 +debug: 0.406 +files: 0.355 +permissions: 0.333 +boot: 0.323 +semantic: 0.250 +other: 0.246 +KVM: 0.213 + +sigfaul on netdev stream +Description of problem: +qemu sigfault if use netdev socket and hubport +Steps to reproduce: +1. Preconfigure network interface on /etc/network/interface or try connect from qemu server port another qemu process or other softvare (gnuradio, etc) +``` +auto qt-test0 +iface qt-test0 + address 192.168.10.1/30 + mtu 16384 + pre-up ip tuntap add $IFACE mode tap + post-down ip link del dev $IFACE +``` +2. Run qemu from the cmdline +Additional information: +``` +(gdb) bt +#0 0x0000555555b547d0 in object_get_class () +#1 0x0000555555b9d44c in qio_channel_writev () +#2 0x000055555598295c in ?? () +#3 0x000055555597cf67 in ?? () +#4 0x0000555555980eb9 in qemu_net_queue_send_iov () +#5 0x000055555597b8e4 in ?? () +#6 0x000055555597ce32 in ?? () +#7 0x0000555555980df5 in qemu_net_queue_send () +#8 0x000055555598fb52 in ?? () +#9 0x0000555555d26755 in ?? () +#10 0x0000555555d270d2 in aio_dispatch () +#11 0x0000555555d3f5ef in ?? () +#12 0x00007ffff70f100e in ?? () from /usr/lib/libglib-2.0.so.0 +#13 0x00007ffff70f4988 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#14 0x0000555555d40f69 in main_loop_wait () +#15 0x000055555592fc83 in qemu_main_loop () +#16 0x0000555555c7c817 in qemu_default_main () +#17 0x00007ffff7f9a496 in libc_start_main_stage2 (main=0x5555556cc0f0 <main>, argc=12, argv=0x7fffffffebd8) at src/env/__libc_start_main.c:95 +#18 0x00005555556cd0d8 in _start () +``` diff --git a/results/classifier/zero-shot/108/network/2780 b/results/classifier/zero-shot/108/network/2780 new file mode 100644 index 000000000..00c44a2c0 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2780 @@ -0,0 +1,32 @@ +network: 0.981 +device: 0.910 +graphic: 0.906 +performance: 0.770 +socket: 0.573 +vnc: 0.510 +debug: 0.472 +files: 0.458 +semantic: 0.420 +PID: 0.389 +boot: 0.272 +KVM: 0.190 +permissions: 0.164 +other: 0.108 + +Out-of-bounds access in smc91c111_receive() +Description of problem: +An out-of-bounds access happens at hw/net/smc91c111.c:705. + +`hw/net/smc91c111.c:705:5: runtime error: index -1 out of bounds for type 'int[4]'` +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +writew 0x4e000005 0x227 +writel 0x4e00000b 0x25ab1f2 +writew 0x4e000000 0xaa6c +clock_step +EOF +``` +Additional information: + diff --git a/results/classifier/zero-shot/108/network/2829 b/results/classifier/zero-shot/108/network/2829 new file mode 100644 index 000000000..0d8044653 --- /dev/null +++ b/results/classifier/zero-shot/108/network/2829 @@ -0,0 +1,36 @@ +network: 0.939 +device: 0.833 +PID: 0.822 +socket: 0.798 +graphic: 0.760 +vnc: 0.759 +permissions: 0.746 +performance: 0.703 +files: 0.697 +semantic: 0.691 +other: 0.652 +debug: 0.565 +boot: 0.454 +KVM: 0.181 + +SMB sharing on FIPS enabled hosts with Samba broken +Description of problem: +Similar to #2593 , newer security features on GNU+Linux host OSes are continuing +to break communication with guests running older OSes. + +QEMU executes the `smbd` process in [slirp.c](net/slirp.c) to facilitate the SMB +sharing between guest and host. + +The host `smbd` process links in GnuTLS for authentication ciphers and algorithm +primitives. When `smbd` processes SMB requests from these older OS's SMB implementations, +it errors out with error lines: + +`Failed to setup SPNEGO negTokenInit request` + +`Failed to start SPNEGO handler for negprot OID list!` +Steps to reproduce: +1. Access a GNU+Linux machine with GnuTLS library in FIPS mode which `smbd` links against +2. Run `qemu-system-*` with an older guest OS with a `smb` share to host +3. See errors in `/tmp/qemu.smb*/log.smbd` +Additional information: +# diff --git a/results/classifier/zero-shot/108/network/2872 b/results/classifier/zero-shot/108/network/2872 new file mode 100644 index 000000000..95ef15dcb --- /dev/null +++ b/results/classifier/zero-shot/108/network/2872 @@ -0,0 +1,16 @@ +network: 0.945 +device: 0.884 +socket: 0.651 +vnc: 0.490 +semantic: 0.487 +boot: 0.434 +performance: 0.426 +graphic: 0.357 +files: 0.357 +debug: 0.352 +PID: 0.303 +KVM: 0.261 +other: 0.202 +permissions: 0.117 + +hw/net: Parameter 'driver' expects a pluggable device type diff --git a/results/classifier/zero-shot/108/network/2884 b/results/classifier/zero-shot/108/network/2884 new file mode 100644 index 000000000..bc87a2f0b --- /dev/null +++ b/results/classifier/zero-shot/108/network/2884 @@ -0,0 +1,50 @@ +network: 0.982 +device: 0.908 +graphic: 0.843 +KVM: 0.809 +socket: 0.772 +other: 0.681 +PID: 0.657 +vnc: 0.630 +files: 0.617 +permissions: 0.594 +performance: 0.559 +semantic: 0.528 +debug: 0.491 +boot: 0.408 + +Questions about vfio-pci +Description of problem: +When I use VFIO-PCI to pass through an hns3 device and load the driver to the VM to enable the hns3 network port, there is a possibility that the failure occurs. +Steps to reproduce: +1. Start the VM and load the hns3 driver. +2. enable net port + + `ifconfig eth0 10.10.10.10/24 up` +3. ping host + + `ping 10.10.10.11 -c 3` +Additional information: +I have the following findings: + +1. The problem can be reproduced in different kernel versions and QEMU versions. +2. The problem does not recur when the number of vCPUs is 1. +3. It is irrelevant to the GIC version. + +the hns3 relately logic: + +{width="394" height="285"} + +If the VM has two vCPUs, "ifconfig eth0 10.10.10.10/24 up" command performs two sequential enable_irq operations(vector_num=2). The enable_irq will trap into KVM for interrupt configuration and exit to QEMU for PCI device emulation. When emulating interrupt enabling in QEMU, vfio\_\[intx/msi/msix\]\_enable calls vfio_disable_interrupts to disable all interrupts on the vdev. + +{width="455" height="266"} + +vfio_disable_interrupts in QEMU calls the kernel vfio driver interface vfio_pci_set_irqs_ioctl + +{width="404" height="127"} + +dump stack as above. and then its_irq_domain_deactivate will call its_send_discard to discard the interrupt on the device. + +If an interrupt is handled after the first enable_irq but the second enable_irq discards it, this inconsistency leads to network port enablement failures. + +It puzzles me. why does the vfio-pci disable all interrupts of the device before enabling irqs? diff --git a/results/classifier/zero-shot/108/network/2951 b/results/classifier/zero-shot/108/network/2951 new file mode 100644 index 000000000..9da85465a --- /dev/null +++ b/results/classifier/zero-shot/108/network/2951 @@ -0,0 +1,36 @@ +network: 0.935 +graphic: 0.840 +device: 0.838 +vnc: 0.799 +performance: 0.755 +socket: 0.693 +files: 0.689 +other: 0.646 +boot: 0.561 +semantic: 0.529 +permissions: 0.501 +PID: 0.493 +debug: 0.413 +KVM: 0.277 + +First byte of USB NIC is hardcoded to 0x40 +Description of problem: +Incus recently added support for USB attached network interfaces. +As with any network device, we generate a MAC address (using our MAC OUI) and allow the user to override that to a value of their choice. + +That's when we noticed that no matter what MAC address we set, the resulting MAC always has the prefix swapped to "40:". Looking into the code, this is done on purpose here: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/dev-network.c?ref_type=heads#L1386 + +Unfortunately there is no comment in the code or in any of the commits touching that code as far as why that is. + +We've also looked at the libvirt code handling those devices and that code seems to also assume that a user provided MAC will be correctly passed through to the guest, no mention of the odd prefix override. + +This is a bit concerning as there are valid IEEE OUI with the "40:" prefix. +So this means that QEMU may be generating collisions with actual physical MAC addresses... + +For a few months now, I've been applying this small patch to my own Incus packages (which bundle QEMU) and haven't heard or seen any obvious issue from the change. + +https://github.com/zabbly/incus/blob/daily/patches/qemu-0001-usb-net-mac.patch + +Does anyone know why this hardcoded MAC address prefix exists? diff --git a/results/classifier/zero-shot/108/network/299 b/results/classifier/zero-shot/108/network/299 new file mode 100644 index 000000000..2b7d1976e --- /dev/null +++ b/results/classifier/zero-shot/108/network/299 @@ -0,0 +1,16 @@ +network: 0.957 +device: 0.790 +graphic: 0.599 +semantic: 0.409 +performance: 0.374 +debug: 0.367 +other: 0.296 +boot: 0.185 +PID: 0.160 +vnc: 0.141 +permissions: 0.105 +files: 0.062 +socket: 0.026 +KVM: 0.007 + +Tulip NIC not working on OpenBSD/hppa (and more) diff --git a/results/classifier/zero-shot/108/network/308 b/results/classifier/zero-shot/108/network/308 new file mode 100644 index 000000000..5472599b5 --- /dev/null +++ b/results/classifier/zero-shot/108/network/308 @@ -0,0 +1,16 @@ +network: 0.947 +device: 0.785 +performance: 0.738 +graphic: 0.394 +debug: 0.331 +boot: 0.300 +PID: 0.213 +permissions: 0.185 +semantic: 0.162 +other: 0.081 +files: 0.056 +socket: 0.027 +vnc: 0.018 +KVM: 0.005 + +QEMU: net: vmxnet: integer overflow may crash guest diff --git a/results/classifier/zero-shot/108/network/335 b/results/classifier/zero-shot/108/network/335 new file mode 100644 index 000000000..26540c268 --- /dev/null +++ b/results/classifier/zero-shot/108/network/335 @@ -0,0 +1,16 @@ +network: 0.975 +device: 0.858 +graphic: 0.663 +performance: 0.558 +debug: 0.441 +PID: 0.336 +vnc: 0.234 +other: 0.149 +socket: 0.134 +boot: 0.124 +semantic: 0.090 +KVM: 0.085 +files: 0.055 +permissions: 0.023 + +Broken tap networking on macOS host diff --git a/results/classifier/zero-shot/108/network/377 b/results/classifier/zero-shot/108/network/377 new file mode 100644 index 000000000..5b6e856b0 --- /dev/null +++ b/results/classifier/zero-shot/108/network/377 @@ -0,0 +1,16 @@ +network: 0.947 +device: 0.563 +socket: 0.497 +graphic: 0.469 +other: 0.426 +PID: 0.353 +vnc: 0.340 +performance: 0.328 +semantic: 0.324 +boot: 0.284 +KVM: 0.266 +permissions: 0.207 +debug: 0.203 +files: 0.179 + +Indentation should be done with spaces, not with TABs, in the net subsystem diff --git a/results/classifier/zero-shot/108/network/428 b/results/classifier/zero-shot/108/network/428 new file mode 100644 index 000000000..654233215 --- /dev/null +++ b/results/classifier/zero-shot/108/network/428 @@ -0,0 +1,16 @@ +network: 0.962 +performance: 0.933 +device: 0.852 +graphic: 0.468 +semantic: 0.301 +boot: 0.215 +vnc: 0.212 +PID: 0.160 +socket: 0.108 +permissions: 0.084 +debug: 0.066 +files: 0.009 +other: 0.006 +KVM: 0.001 + +Windows: Very low network throughput with tap-netdev & virtio-serial diff --git a/results/classifier/zero-shot/108/network/460 b/results/classifier/zero-shot/108/network/460 new file mode 100644 index 000000000..8ec120977 --- /dev/null +++ b/results/classifier/zero-shot/108/network/460 @@ -0,0 +1,16 @@ +network: 0.952 +device: 0.940 +performance: 0.729 +debug: 0.552 +graphic: 0.389 +socket: 0.372 +boot: 0.260 +PID: 0.214 +semantic: 0.170 +files: 0.071 +permissions: 0.046 +vnc: 0.044 +KVM: 0.019 +other: 0.013 + +vmxnet3: Assertion failure in eth_setup_ip4_fragmentation diff --git a/results/classifier/zero-shot/108/network/465 b/results/classifier/zero-shot/108/network/465 new file mode 100644 index 000000000..60ad9a611 --- /dev/null +++ b/results/classifier/zero-shot/108/network/465 @@ -0,0 +1,22 @@ +network: 0.980 +device: 0.806 +vnc: 0.759 +graphic: 0.649 +semantic: 0.562 +socket: 0.502 +other: 0.428 +permissions: 0.373 +files: 0.370 +PID: 0.337 +boot: 0.305 +performance: 0.303 +KVM: 0.138 +debug: 0.064 + +Support network virtualization for Macos Big Sur+ +Additional information: +The following implementation are already submitted as a patch and they seem to work well on my mbp 2019 Big Sur. The only prob is that the qemu-system command should be run as root. + +[https://patchwork.kernel.org/project/qemu-devel/list/?series=502533](https://patchwork.kernel.org/project/qemu-devel/list/?series=502533) + +[https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/](https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/) diff --git a/results/classifier/zero-shot/108/network/485250 b/results/classifier/zero-shot/108/network/485250 new file mode 100644 index 000000000..50c4cc154 --- /dev/null +++ b/results/classifier/zero-shot/108/network/485250 @@ -0,0 +1,48 @@ +network: 0.966 +semantic: 0.944 +device: 0.935 +performance: 0.929 +boot: 0.907 +graphic: 0.904 +other: 0.891 +files: 0.870 +vnc: 0.865 +permissions: 0.864 +socket: 0.825 +debug: 0.799 +PID: 0.779 +KVM: 0.655 + +nic e1000 network interface does not work with 32-bit windows 2003r2 with sp2 + +nic e1000 network interface does not work with win2k3r2 32bit + +e1000 driver in win2k3r2 32bit seems to be broken. The interface is able to +receive ip from the dhcp server, but not able to ping it from any linux guest or +host, but was able to ping it from windows guest. + +Running network test, netperf, between the windows guest fails with the message +"netperf: receive_response: no response received. errno 104 counter 0" + +cmdline used: +/usr/local/bin/qemu-system-x86_64 -drive file=win2003r2sp2-32.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:04,model=e1000 -net tap,vlan=0,script=/home/yogi/qemu-ifup -m 2048 -enable-kvm -usbdevice tablet -vnc :1 + +uname -a +Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +Distro: fedora 11 + +Thx +yogi + +Maybe you can try the e1000 drivers from Intel's site. You could also try using the stadard Qemu mac prefix of 52:54 (the first bit of the mac has a special meaning). + +I can reproduce this in qemu-kvm 0.12.50. + +Most likely a problem with the e1000 driver in QEMU. Funny thing is the guest seems to be able to obtain it's IP address via DHCP, then stops communicating. + + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/network/580 b/results/classifier/zero-shot/108/network/580 new file mode 100644 index 000000000..54302fcd0 --- /dev/null +++ b/results/classifier/zero-shot/108/network/580 @@ -0,0 +1,32 @@ +network: 0.995 +graphic: 0.991 +performance: 0.945 +device: 0.926 +PID: 0.898 +socket: 0.893 +debug: 0.883 +files: 0.853 +semantic: 0.814 +vnc: 0.765 +permissions: 0.764 +boot: 0.694 +other: 0.693 +KVM: 0.509 + +access internet from guest +Description of problem: +I can ssh back to host using ssh 10.0.2.2. +Also I can login to guest from host using ssh riscv@localhost -p 3333. +However, +I could not get internet access from the guest os system, such as: +``` +[riscv@fedora-riscv ~]$ wget www.google.com +--2019-12-15 05:53:04-- http://www.google.com/ +Resolving www.google.com (www.google.com)... 216.58.194.164, 2607:f8b0:4005:804::2004 +Connecting to www.google.com (www.google.com)|216.58.194.164|:80... failed: Connection refused. +Connecting to www.google.com (www.google.com)|2607:f8b0:4005:804::2004|:80... failed: Network is unreachable. +``` +Therefore, I could not use dnf to install packages. +Any help will be appreciated. +Additional information: + diff --git a/results/classifier/zero-shot/108/network/593 b/results/classifier/zero-shot/108/network/593 new file mode 100644 index 000000000..6272cd61b --- /dev/null +++ b/results/classifier/zero-shot/108/network/593 @@ -0,0 +1,22 @@ +network: 0.973 +device: 0.920 +graphic: 0.760 +vnc: 0.551 +performance: 0.498 +other: 0.495 +socket: 0.477 +files: 0.452 +semantic: 0.450 +boot: 0.405 +PID: 0.389 +debug: 0.302 +permissions: 0.292 +KVM: 0.175 + +USB ECM network device does not work under XHCI +Description of problem: +No data is ever received by the USB ECM network device when it is attached to an XHCI controller. (USB 1.0 controllers work OK.) +Additional information: +There are some patches it appears were submitted to the GitHub mirror that resolve the problem (I tested them applied to git master, and confirmed they work): https://github.com/qemu/qemu/pull/100 + +I guess they never were submitted to the mailing list, or somehow got missed? diff --git a/results/classifier/zero-shot/108/network/605 b/results/classifier/zero-shot/108/network/605 new file mode 100644 index 000000000..894e3807f --- /dev/null +++ b/results/classifier/zero-shot/108/network/605 @@ -0,0 +1,30 @@ +network: 0.992 +graphic: 0.986 +boot: 0.973 +device: 0.949 +debug: 0.895 +vnc: 0.889 +performance: 0.873 +files: 0.816 +PID: 0.781 +semantic: 0.638 +socket: 0.616 +permissions: 0.474 +KVM: 0.235 +other: 0.215 + +QEMU crashes when receiving network connection on NetBSD +Description of problem: +After booting the VM, connecting to the TCP port 2222 of the host immediately crashes the VM and qemu prints: + +** +Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) +Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) +Steps to reproduce: +1. start VM as indicated +2. telnet localhost 2222 +3. crash +Additional information: +** +Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) +Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) diff --git a/results/classifier/zero-shot/108/network/62179944 b/results/classifier/zero-shot/108/network/62179944 new file mode 100644 index 000000000..912debb49 --- /dev/null +++ b/results/classifier/zero-shot/108/network/62179944 @@ -0,0 +1,41 @@ +network: 0.966 +graphic: 0.907 +device: 0.818 +performance: 0.636 +socket: 0.608 +boot: 0.567 +files: 0.565 +other: 0.519 +PID: 0.504 +vnc: 0.498 +semantic: 0.454 +permissions: 0.403 +debug: 0.400 +KVM: 0.153 + +[Qemu-devel] [BUG] network : windows os lost ip address of the network card in some cases + +we found this problem for a long time ãFor example, if we has three network +card in virtual xml file ï¼such as "network connection 1" / "network connection +2"/"network connection 3" ã + +Echo network card has own ip address ï¼such as 192.168.1.1 / 2.1 /3.1 , when +delete the first card ï¼reboot the windows virtual os, then this problem +happened ! + + + + +we found that the sencond network card will replace the first one , then the +ip address of "network connection 2 " become 192.168.1.1 ã + + +Our third party users began to complain about this bug ãAll the business of the +second ip lost !!! + +I mean both of windows and linux has this bug , we solve this bug in linux +throught bonding netcrad pci and mac address ã + +There is no good solution on windows os . thera are ? we implemented a plan to +resumption of IP by QGA. Is there a better way ? + diff --git a/results/classifier/zero-shot/108/network/641118 b/results/classifier/zero-shot/108/network/641118 new file mode 100644 index 000000000..3cc9cf0df --- /dev/null +++ b/results/classifier/zero-shot/108/network/641118 @@ -0,0 +1,32 @@ +network: 0.989 +device: 0.805 +boot: 0.802 +vnc: 0.734 +graphic: 0.724 +socket: 0.679 +semantic: 0.670 +performance: 0.600 +PID: 0.548 +permissions: 0.533 +other: 0.418 +debug: 0.402 +files: 0.386 +KVM: 0.324 + +NetBSD guest only supports network without ACPI + +Git commit: abdfd9500e07fab7d6ffd4385fa30a065c329a39 +Host: Linux 64bit Debian +Guest: NetBSD5.0.2/i386 + +Networking works only when ACPI is disabled in the guest. Without it the network card (wm0) is not detected. + +Boot: qemu -hda netbsd5.0.2-i386 -boot c -enable-kvm +Configure: --enable-linux-aio --enable-io-thread --enable-kvm + +Can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays? + +I've just tried, and it is OK using NetBSD7 as the guest. I no longer have NetBSD5 so I am unable to check if the problem still exists on that. + +OK, thanks for checking! ... so let's close this bug. + diff --git a/results/classifier/zero-shot/108/network/741 b/results/classifier/zero-shot/108/network/741 new file mode 100644 index 000000000..5fdaee67c --- /dev/null +++ b/results/classifier/zero-shot/108/network/741 @@ -0,0 +1,16 @@ +network: 0.925 +semantic: 0.403 +performance: 0.373 +permissions: 0.221 +graphic: 0.145 +socket: 0.103 +vnc: 0.067 +device: 0.057 +KVM: 0.048 +files: 0.046 +PID: 0.034 +debug: 0.024 +boot: 0.012 +other: 0.003 + +Document "net/net.h" API diff --git a/results/classifier/zero-shot/108/network/774 b/results/classifier/zero-shot/108/network/774 new file mode 100644 index 000000000..931b1e400 --- /dev/null +++ b/results/classifier/zero-shot/108/network/774 @@ -0,0 +1,30 @@ +network: 0.976 +device: 0.971 +graphic: 0.958 +boot: 0.932 +vnc: 0.807 +other: 0.764 +semantic: 0.757 +performance: 0.741 +socket: 0.705 +PID: 0.578 +files: 0.471 +debug: 0.458 +permissions: 0.355 +KVM: 0.050 + +Win(PE) NIC issue with pc-q35-6.1 +Description of problem: +When booting WinPE (via PXE via WDS) on a `pc-q35-6.1` machine, the NIC will not initialize. + +What I got with `pnputil.exe /enum-devices /class net` is `Device has problem: 56 0x38 (CM_PROB_NEED_CLASS_CONFIG)` See: [CM_PROB_NEED_CLASS_CONFIG](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cm-prob-need-class-config) + +I'm using virt manager and I've tried both `e1000e` and `virtio` network adapters (virtio with drivers injected into the image of course). Both yield the aforementioned error and `ipconfig` remains empty. This is an obscure problem - I haven't checked if a normal windows install behaves the same way, but it might be unique to winpe. + +However, with `pc-q35-5.2`, the NIC initializes without a problem. +Steps to reproduce: +1. Create `pc-q35-6.1` based vm in virt manager with default settings (network bridged to network bridge) +2. PXE boot Windows Setup +3. Observe hang (observe errors with console `SHIFT+F10`) +Additional information: + diff --git a/results/classifier/zero-shot/108/network/807 b/results/classifier/zero-shot/108/network/807 new file mode 100644 index 000000000..5ffbfb9cb --- /dev/null +++ b/results/classifier/zero-shot/108/network/807 @@ -0,0 +1,33 @@ +network: 0.941 +graphic: 0.934 +other: 0.924 +performance: 0.866 +device: 0.823 +socket: 0.805 +semantic: 0.796 +vnc: 0.723 +permissions: 0.546 +debug: 0.389 +PID: 0.332 +KVM: 0.322 +boot: 0.251 +files: 0.153 + +TigerVNC client to built-in VNC server causes VM to crash/freeze +Description of problem: +Connecting to the built-in VNC server via TigerVNC upon disconnect the whole VM process freezes/crashes. The process continues to exist but does not respond to any network connection and the monitor socket is dead too. Killing it with TERM doesn't work. + +Using tigervnc-viewer 1.10.1+dfsg-3 (Ubuntu 20.04) with default options like `vncviwer localhost:0` +Steps to reproduce: +* `qemu-system-x86_64 -vnc 127.0.0.1:0` + * Connect to built-in VNC server via TigerVNC + * Keep the VNC connection open and wait some period of time (usually 5-10 minutes is enough though sometimes hours) then disconnect/reconnect VNC. If the reconnect succeeds then wait again for a period of time then disconnect and try again until failure. Often just connecting and disconnecting to the VNC once is enough to make the VM eventually crash/freeze even if running only in the background but this is less reproducible. + * Observe VM is no longer responsive to anything + +If TigerVNC is never connected/disconnected from the VM then this doesn't happen. +Additional information: +Note due to the nature of this issue it might be hard to reproduce for unknown reasons. The VM always eventually freezes though. The qemu process has no output when it freezes. + +As far as I can tell connecting to the built-in VNC server via `gvncviwer` seems to be OK and doesn't cause an issue (?). I'm not sure about other VNC clients (eg. TurboVNC). + +I am connecting to the VNC server from a completely different machine than the host via SSH port redirection (the host is headless). Not sure if that matters. diff --git a/results/classifier/zero-shot/108/network/894037 b/results/classifier/zero-shot/108/network/894037 new file mode 100644 index 000000000..5aefa0b00 --- /dev/null +++ b/results/classifier/zero-shot/108/network/894037 @@ -0,0 +1,127 @@ +semantic: 0.928 +network: 0.928 +PID: 0.922 +graphic: 0.918 +other: 0.916 +device: 0.910 +performance: 0.909 +debug: 0.905 +boot: 0.897 +vnc: 0.890 +permissions: 0.877 +socket: 0.851 +KVM: 0.843 +files: 0.799 + +With VNC, "-usbdevice tablet" no longer makes mouse pointers line up + +I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. + +Here's how I'm booting WinXP: + +qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & + +The Windows install hasn't changed, only qemu. + +I'm running this version of QEMU: + +QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard + +I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. + +Also observed on Fedora 16, qemu-kvm-0.15.1-3.fc16.x86_64 +https://bugzilla.redhat.com/show_bug.cgi?id=754149 + + +Also observed on Ubuntu, extra/qemu-kvm 0.15.0-2 +https://bugs.launchpad.net/qemu/+bug/894037 + + +This bug isn't getting any attention, but it's a total show-stopper for me. It priority should be raised to Critical. I cannot use any of my VMs at all. Please help! + +Thanks. + + +On Mon, Dec 19, 2011 at 3:23 PM, Timothy Miller <email address hidden> wrote: +> This bug isn't getting any attention, but it's a total show-stopper for +> me. It priority should be raised to Critical. I cannot use any of my +> VMs at all. Please help! + +Have you checked that the guest operating system is using the USB +tablet as the mouse input? If it is falling back to the PS/2 mouse +then you will not get synced mouse pointers. + +Stefan + + +That's easier said than done, because it's pretty unusable. And as I said, the OS didn't change. QEMU got updated, and then it broke. So if it was or wasn't using the tablet before, then it still is or isn't now. Either way, it used to work. + +I'll see what I can figure out about what it thinks its input device is. + +Ok, I'm seeing two devices that Windows XP doesn't recognize. One is "QEMU USB Tablet", and the other is "VGA Controller (VGA Compatible)". It doesn't appear to have drivers for these. + +Both of these used to work just fine. I'm not sure why it's complaining about either one, since things were fine before. Did identifying information about these devices change over an update? Is there a way to get back the old behavior from QEMU? + + +Can you please upgrade to 1.0 and see if that fixes the problem. The following patch should fix your problem (and is present in 1.0): + +commit 21635e121ae0f0ab7874152a7c2f96e9d8cd642f +Author: Gerd Hoffmann <email address hidden> +Date: Tue Aug 9 12:35:57 2011 +0200 + + usb/hid: add hid_pointer_activate, use it + + HID reorganziation broke the usb tablet in windows xp. The reason is + that xp activates idle before it starts polling, which creates a + chicken-and-egg issue: We don't call hid_pointer_poll because there are + no pending events. We don't get any events because the activation code + in hid_pointer_poll is never executed and thus all pointer events are + routed to the PS/2 mouse by qemu. + + Fix this by creating a hid_pointer_activate function and call it from + usb-hid when the guest sets the idle state. + + Signed-off-by: Gerd Hoffmann <email address hidden> + + +Windows XP does not have a VESA compatible driver by default. -std vga therefore won't work out of the box for Windows XP. This is not a regression, this has always been the case. + +This is strange. On a lark, I right-clicked the unknown tablet device and told Windows to find a driver for it. It told me it couldn't find a better one than what I already had, and then it appeared as a HID-compliant device. Now it works fine! + +I'm thinking that what has happened is that some characteristic (name? PCI ID?) of the tablet device changed, and Windows XP doesn't automatically adapt to the "new hardware", but if you fiddle with it, Windows will decide to attach the right driver. + +It works fine for me now, but that doesn't completely invalidate the bug. At the very least, the bug is that this change wasn't documented well. I tried googling for this, but I found nothing relevant. + + +Is qemu 1.0 headed for fedora-rawhide any time soon? I only see qemu-0.15.1-3.fc17 available... + +From the Qemu Monitor, try looking at "info mice" +I'm not exactly sure ho to access the Qemu Monitor from VNC. You might have +to start qemu with additional parameters: -monitor +telnet:localhost:12341,server,nowait +then use "telnet localhost 12341" to access the monitor... + +On Monday 19 December 2011 18:54:19 Timothy Miller wrote: +> That's easier said than done, because it's pretty unusable. And as I +> said, the OS didn't change. QEMU got updated, and then it broke. So if +> it was or wasn't using the tablet before, then it still is or isn't now. +> Either way, it used to work. +> +> I'll see what I can figure out about what it thinks its input device is. + + +From VNC, you access the monitor via Ctrl-Alt-2 and Ctrl-Alt-1. It works the same. + +"info mice" gives me: +* Mouse #1: QEMU USB Tablet (absolute) + Mouse #0: QEMU PS/2 Mouse + +As for Windows and VESA, I'm not sure what it's doing, but I can select all sorts of resolutions, like 1440x900. The default adaptor in the past (cirrus?) was much more limited. It must be doing some kind of BIOS thunking, but I bet it would be more efficient to have a VESA driver, no? + + +According to comment #6 this has been fixed in version 1.0 ... is there still something left to do here? + +There hasn't been a reply to my question in the last comment within +months, so I assume nobody cares about this anymore. So I'm closing this +ticket now... + diff --git a/results/classifier/zero-shot/108/network/899 b/results/classifier/zero-shot/108/network/899 new file mode 100644 index 000000000..77c6dc27b --- /dev/null +++ b/results/classifier/zero-shot/108/network/899 @@ -0,0 +1,29 @@ +network: 0.983 +graphic: 0.982 +boot: 0.945 +device: 0.942 +performance: 0.906 +vnc: 0.891 +semantic: 0.862 +permissions: 0.773 +files: 0.715 +PID: 0.655 +socket: 0.654 +debug: 0.637 +KVM: 0.223 +other: 0.207 + +HVF: Ubuntu Server fails to boot Linux 5.4.0-104 +Description of problem: +On macOS with HVF, when Ubuntu Server updates the Linux kernel to 5.4.0-104, it no longer boots and gets stuck at `EFI stub: Exiting boot services and installing virtual address map...`. This is not the case with QEMU 6.0.0 (with @agraf's HVF patches applied). + +It seems like 5.4.0-104 is the culprit because 5.4.0-100 boots fine. +Steps to reproduce: +1. Download Ubuntu Server 20.04 ARM64 ISO: https://ubuntu.com/download/server/arm +2. Run the above QEMU command (make sure networking is disabled so Ubuntu installer does not auto-upgrade the kernel) +3. Install Ubuntu with the default settings and reboot +4. It will not reboot (expected) so Ctrl+C and restart the command adding `-device virtio-net-pci,netdev=net0 -netdev user,id=net0` to the end to get networking +5. Boot into Ubuntu and install 5.4.0-104 kernel: `sudo apt install linux-image-5.4.0-104-generic` +6. Reboot and it will get stuck at `EFI stub: Exiting boot services and installing virtual address map...` +Additional information: + diff --git a/results/classifier/zero-shot/108/network/912 b/results/classifier/zero-shot/108/network/912 new file mode 100644 index 000000000..861bdae68 --- /dev/null +++ b/results/classifier/zero-shot/108/network/912 @@ -0,0 +1,16 @@ +network: 0.940 +device: 0.909 +performance: 0.644 +permissions: 0.642 +other: 0.527 +debug: 0.481 +semantic: 0.464 +graphic: 0.358 +files: 0.307 +PID: 0.289 +vnc: 0.243 +boot: 0.232 +socket: 0.178 +KVM: 0.003 + +Cannot access RHEL8_s390x installed OS using SSH from host OS network diff --git a/results/classifier/zero-shot/108/network/976 b/results/classifier/zero-shot/108/network/976 new file mode 100644 index 000000000..10f6a200b --- /dev/null +++ b/results/classifier/zero-shot/108/network/976 @@ -0,0 +1,16 @@ +network: 0.935 +performance: 0.808 +device: 0.734 +graphic: 0.612 +debug: 0.483 +semantic: 0.224 +files: 0.221 +permissions: 0.178 +vnc: 0.118 +other: 0.082 +boot: 0.080 +socket: 0.034 +PID: 0.017 +KVM: 0.003 + +Qemu - Bridge direct network connection not working |