diff options
Diffstat (limited to 'results/classifier/118/performance/597')
| -rw-r--r-- | results/classifier/118/performance/597 | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/results/classifier/118/performance/597 b/results/classifier/118/performance/597 new file mode 100644 index 00000000..920d7906 --- /dev/null +++ b/results/classifier/118/performance/597 @@ -0,0 +1,49 @@ +performance: 0.931 +virtual: 0.876 +device: 0.815 +graphic: 0.769 +network: 0.682 +hypervisor: 0.660 +mistranslation: 0.570 +boot: 0.550 +semantic: 0.540 +register: 0.533 +PID: 0.513 +kernel: 0.492 +architecture: 0.487 +socket: 0.471 +arm: 0.425 +user-level: 0.398 +vnc: 0.388 +i386: 0.378 +VMM: 0.368 +debug: 0.348 +ppc: 0.345 +TCG: 0.317 +x86: 0.311 +permissions: 0.302 +peripherals: 0.286 +risc-v: 0.272 +KVM: 0.232 +files: 0.183 +assembly: 0.055 + +sunhme sometimes causes the VM to hang forever +Description of problem: +When using sunhme, sometimes on receiving traffic (and doing disk IO?) it will get slower and slower until it becomes entirely unresponsive, which does not happen on the real hardware I have sitting next to me (Sun Netra T1, running the same OS+kernel, though not the same image) + +virtio-net-pci does not, so far, demonstrate the problem, and neither does just sending a lot of traffic out over the sunhme interface, so it appears to require receiving or some more complex interaction. + +It doesn't always happen immediately, it sometimes takes a couple of tries with the command, but when it does, it's gone. + +Output logged to console below. +Steps to reproduce: +1. Log into VM (rich/omgqemu) +2. sudo apt clean;sudo apt update; +3. If it doesn't lock up the VM, repeat step 2 a few times. +Additional information: +Disk image can be found [here](https://www.dropbox.com/s/0oosyf7xej44v9n/sunhme_repro_disk.tgz?dl=0) (tarred in the hope that it does something reasonable with sparseness) + +Console output can be found [here](https://www.dropbox.com/s/t1wxx41vzv8p3l6/sunhme%20sadness.txt?dl=0) + +Ah yes, [the initrd and vmlinux](https://www.dropbox.com/s/t7i4gs7poqaeanz/oops_boot.tgz?dl=0) would help, wouldn't they, though I imagine the ones in the VM itself would boot... |