add new results

5 files changed, 475 insertions, 0 deletions

diff --git a/results/classifier/111/network/1196727 b/results/classifier/111/network/1196727
new file mode 100644
index 000000000..a8f7462f9
--- /dev/null
+++ b/results/classifier/111/network/1196727
@@ -0,0 +1,176 @@
+network: 0.108
+socket: 0.088
+permissions: 0.087
+device: 0.085
+other: 0.084
+PID: 0.079
+debug: 0.078
+semantic: 0.073
+vnc: 0.068
+boot: 0.058
+files: 0.053
+performance: 0.049
+graphic: 0.046
+KVM: 0.042
+network: 0.519
+debug: 0.296
+PID: 0.043
+other: 0.025
+files: 0.025
+socket: 0.024
+device: 0.015
+semantic: 0.012
+performance: 0.012
+KVM: 0.009
+graphic: 0.006
+boot: 0.006
+vnc: 0.005
+permissions: 0.004
+
+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/111/network/1633508 b/results/classifier/111/network/1633508
new file mode 100644
index 000000000..91a95c680
--- /dev/null
+++ b/results/classifier/111/network/1633508
@@ -0,0 +1,79 @@
+network: 0.165
+device: 0.125
+PID: 0.112
+other: 0.111
+semantic: 0.100
+socket: 0.071
+permissions: 0.055
+vnc: 0.052
+files: 0.046
+performance: 0.045
+boot: 0.044
+debug: 0.037
+graphic: 0.024
+KVM: 0.013
+network: 0.771
+debug: 0.047
+device: 0.032
+PID: 0.028
+other: 0.020
+files: 0.020
+socket: 0.014
+semantic: 0.013
+boot: 0.013
+performance: 0.011
+KVM: 0.010
+graphic: 0.009
+permissions: 0.007
+vnc: 0.006
+
+libvirt cannot hot insert interfaces to qemu
+
+When attempting to hot insert an interface using Ubuntu 16.04.1, I get the following
+$ virsh attach-interface --domain gluster1 --type direct \
+>         --source test0 --model virtio \
+>         --mac 2a:b6:b0:dc:c7:c4 --config --live
+error: Failed to attach interface
+error: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS
+
+test0 exists:
+$ ip link show test0
+35: test0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
+    link/ether aa:8c:65:2e:79:61 brd ff:ff:ff:ff:ff:ff
+
+Just in case I did it wrong with direct, I did network
+$ virsh net-list
+ Name                 State      Autostart     Persistent
+----------------------------------------------------------
+ default              active     yes           yes
+ mgmtnet0             active     yes           yes
+
+$ virsh attach-interface --domain gluster1 --type network \
+>         --source default --model virtio \
+>         --mac 2a:b6:b0:dc:c7:c4 --config --live
+error: Failed to attach interface
+error: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS
+
+
+This seems to be an old bug, but is still present.  Other relevant information:
+$ qemu-system-x86_64 --version
+QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.5), Copyright (c) 2003-2008 Fabrice Bellard
+$ virsh -v
+1.3.1
+
+This looks like a libvirt bug at a first glance. Have you tried to report it to the libvirt project? (See https://libvirt.org/bugs.html ) ... also, can you re-create the bug with the very latest upstream version of libvirt and qemu, or does it only occur with an (older?) version of Ubuntu?
+
+That seems to be the Libvirt of Ubuntu in Xenial.
+
+In the past similar issues were uncommon configs or changed behavior on updates that triggered apparmor or SELinux protection.
+
+=> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1747442
+=> https://bugzilla.redhat.com/show_bug.cgi?id=731243
+
+It could as well be some variant of bug 1677398.
+
+If you are still affected by this, could you check:
+1. if it also happens on newer libvirt versions e.g. do a trial run in the most recent Ubuntu
+2. if it does could you check dmesg in your setup for related apparmor denials?
+
+
diff --git a/results/classifier/111/network/1791680 b/results/classifier/111/network/1791680
new file mode 100644
index 000000000..56a069ea5
--- /dev/null
+++ b/results/classifier/111/network/1791680
@@ -0,0 +1,104 @@
+network: 0.104
+semantic: 0.103
+permissions: 0.093
+debug: 0.088
+other: 0.084
+PID: 0.083
+device: 0.075
+files: 0.069
+boot: 0.058
+performance: 0.054
+graphic: 0.052
+socket: 0.052
+vnc: 0.051
+KVM: 0.034
+network: 0.799
+debug: 0.056
+PID: 0.023
+boot: 0.021
+device: 0.019
+files: 0.016
+socket: 0.016
+other: 0.015
+semantic: 0.008
+graphic: 0.007
+performance: 0.006
+KVM: 0.006
+permissions: 0.004
+vnc: 0.004
+
+network bridge does not work
+
+hi there
+
+the network bridge does not seem to work described as here: https://en.wikibooks.org/wiki/QEMU/Networking
+
+When i add that parameters in a 192.168.80.x subnet, my emulated raspbian ARM gets the IP 10.0.2.15.... While all other computers get 192.168.80.x
+
+The command i use is:
+
+
+qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000,mac=52:54:00:12:34:56 &
+
+
+Does not build up a network bridge to 192.168.80.x...
+
+The host system i use is win10 x64 v1803
+
+Best regards,
+Jan
+
+J:\Tools\qemu>qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qe
+mu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000,
+mac=52:54:00:12:34:56
+WARNING: Image format was not specified for '2018-09-03_stretch_inkl_phalcon.img' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+
+         Specify the 'raw' format explicitly to remove the restrictions.
+dsound: Could not initialize DirectSoundCapture
+dsound: Reason: No sound driver is available for use, or the given GUID is not a valid DirectSound device ID
+qemu-system-arm.exe: warning: nic e1000.0 has no peer
+
+
+10.0.2.15 is neither a ip in our dhcp range nor an apipa address - strange
+
+but google is pingable, so i have internet.
+
+must be nat, right??
+
+Yes, looks like nat - 10.10.2.15 is not pingable from 192.168.80.x but vice versa... 
+
+but wqhat they write here is not nat: "If no network options are specified, QEMU will default to emulating a single Intel e1000 PCI card with a user-mode network stack that bridges to the host's network. The following three command lines are equivalent:"
+
+And i think my params are right?
+
+...  -net nic -net user -device e1000,mac=52:54:00:12:34:56 &
+
+That comment about e1000 is only true for qemu-system-i386. For ARM machines, there are other default NICs. You should also not mix "-net" and "-device", see https://www.qemu.org/2018/05/31/nic-parameter/ for some details. And concerning NAT, yes the "user" backend is using NAT, see https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 for details about that.
+
+OK thx.
+
+"The -device option can only be used for pluggable NICs. Boards (e.g. embedded boards) which feature an on-board NIC cannot be configured with -device yet, so -net nic,netdev=<id> must be used here instead."
+
+when i only use "-net nic", i get an apipa address
+
+what do i need for netdev id? n1 as described in your links does not work. messsage: "netdev 'n1' not found"
+
+currently, only one nic adapter is enabled on my win10 host: the ethernet controller.
+
+the other 2, 1x internal wlan and 1x usb wlan is disabled..
+
+"That comment about e1000 is only true for qemu-system-i386. For ARM machines, there are other default NICs."
+
+but why im able to ping google with that config??
+
+"-nic tap,model=e1000"
+
+-> "Device 'tap' colud not be found
+
+incompatible with windows, right? so i need a linux machine with ethx??
+
+https://bugs.launchpad.net/qemu/+bug/1404278
+
+problem solved! :-)
+
diff --git a/results/classifier/111/network/495566 b/results/classifier/111/network/495566
new file mode 100644
index 000000000..e503d1409
--- /dev/null
+++ b/results/classifier/111/network/495566
@@ -0,0 +1,61 @@
+network: 0.174
+semantic: 0.167
+other: 0.101
+device: 0.100
+graphic: 0.081
+PID: 0.059
+performance: 0.051
+socket: 0.045
+vnc: 0.045
+files: 0.043
+debug: 0.042
+permissions: 0.036
+boot: 0.035
+KVM: 0.021
+network: 0.870
+debug: 0.040
+other: 0.013
+device: 0.012
+boot: 0.011
+files: 0.010
+PID: 0.008
+semantic: 0.008
+socket: 0.007
+KVM: 0.005
+vnc: 0.005
+performance: 0.004
+graphic: 0.004
+permissions: 0.003
+
+qemu network adapter initialization fails when using macaddr=<multicast MAC-address>
+
+Not sure if ultra-strange, nondocumented feature in qemu (or linux kernel) or really bug: Network card initialization fails if first byte of mac address  is not 00. The problem occurs at least with model=pcnet/rtl8139, in both cases the network adapter is not usable.
+
+How to reproduce:
+
+* Take standard  initrd/kernel (tested with hardy)
+
+* Start qemu (cmd see below) and enter "modprobe pcnet32" at prompt:
+qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=00:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount
+
+You will see "pcnet32 ... at 0x..., 00:22:33:44:55:66
+
+* Do same with mac address 11:22:33:44:55:66
+qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=11:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount
+
+You will see "pcnet32 ... at 0x..., 00:00:00:00:00:00
+
+The network adapter is non-functional, "ip link set eth0 up" does not report error, but does not work (indicates at least some linux kernel influence)
+
+With the rtl8139 adapter, mac-address in guest is correct, but adapter does not work either (indicates qemu influence)
+
+Tested other mac addrs, seems that the first byte has to be even. Would it make sense to issue a warning if a user requests a mac address with an odd first byte? What is the special meaning of the bit 0?
+
+That bit indicates whether the address is a multicast or unicast address.  A network card cannot have a multicast address.
+
+It would make sense to do sanity checking for this.
+
+A check for multicast MAC addresses has been introduced by this commit here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d60b20cf2ae6644b051
+So I think we can close this ticket now.
+
diff --git a/results/classifier/111/network/62179944 b/results/classifier/111/network/62179944
new file mode 100644
index 000000000..288d5c97d
--- /dev/null
+++ b/results/classifier/111/network/62179944
@@ -0,0 +1,55 @@
+network: 0.405
+device: 0.090
+graphic: 0.073
+other: 0.072
+boot: 0.058
+files: 0.057
+semantic: 0.049
+PID: 0.043
+socket: 0.036
+vnc: 0.031
+performance: 0.026
+debug: 0.025
+permissions: 0.023
+KVM: 0.012
+network: 0.777
+debug: 0.180
+files: 0.007
+socket: 0.006
+device: 0.005
+PID: 0.005
+other: 0.004
+semantic: 0.004
+KVM: 0.002
+performance: 0.002
+boot: 0.002
+vnc: 0.002
+graphic: 0.002
+permissions: 0.001
+
+[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 ?
+