add 18th iteration of classifier

1 files changed, 62 insertions, 0 deletions

diff --git a/results/classifier/118/none/495566 b/results/classifier/118/none/495566
new file mode 100644
index 00000000..6d151b26
--- /dev/null
+++ b/results/classifier/118/none/495566
@@ -0,0 +1,62 @@
+network: 0.758
+graphic: 0.640
+kernel: 0.626
+device: 0.597
+semantic: 0.569
+peripherals: 0.475
+performance: 0.445
+ppc: 0.417
+PID: 0.413
+vnc: 0.403
+architecture: 0.365
+register: 0.353
+user-level: 0.348
+socket: 0.340
+VMM: 0.292
+boot: 0.262
+arm: 0.254
+debug: 0.228
+files: 0.214
+TCG: 0.212
+virtual: 0.206
+permissions: 0.190
+x86: 0.185
+hypervisor: 0.145
+i386: 0.145
+KVM: 0.136
+mistranslation: 0.136
+risc-v: 0.133
+assembly: 0.084
+
+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.
+