gitlab scraper: download in toml and text format

1 files changed, 19 insertions, 0 deletions

diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/597 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/597
new file mode 100644
index 000000000..78f396b52
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/597
@@ -0,0 +1,19 @@
+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...