diff options
Diffstat (limited to 'gitlab/issues/target_sparc/host_missing/accel_missing/597.toml')
| -rw-r--r-- | gitlab/issues/target_sparc/host_missing/accel_missing/597.toml | 27 |
1 files changed, 0 insertions, 27 deletions
diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/597.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/597.toml deleted file mode 100644 index 75300393c..000000000 --- a/gitlab/issues/target_sparc/host_missing/accel_missing/597.toml +++ /dev/null @@ -1,27 +0,0 @@ -id = 597 -title = "sunhme sometimes causes the VM to hang forever" -state = "opened" -created_at = "2021-09-03T19:11:43.767Z" -closed_at = "n/a" -labels = ["target: sparc"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/597" -host-os = "Debian 11" -host-arch = "x86_64" -qemu-version = "6.1.0" -guest-os = "Debian ports/sid" -guest-arch = "sparc64" -description = """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.""" -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 = """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...""" |