gitlab scraper: download in toml and text format

1 files changed, 0 insertions, 46 deletions

diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2143.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2143.toml
deleted file mode 100644
index 9338ee70..00000000
--- a/gitlab/issues/target_sparc/host_missing/accel_missing/2143.toml
+++ /dev/null
@@ -1,46 +0,0 @@
-id = 2143
-title = "ladr_match can cause bus error due to unaligned fetch"
-state = "closed"
-created_at = "2024-02-01T03:51:06.350Z"
-closed_at = "2024-03-12T16:28:31.326Z"
-labels = ["kind::Bug", "target: sparc", "workflow::Patch available"]
-url = "https://gitlab.com/qemu-project/qemu/-/issues/2143"
-host-os = "Solaris 11"
-host-arch = "SPARC"
-qemu-version = "8.2.50 (v8.2.0-887-g11be70677c-dirty)"
-guest-os = "SunOS"
-guest-arch = "SPARC"
-description = """On a SPARC host system, which does not support unaligned fetches, QEMU sometimes takes a bus error in ladr_match."""
-reproduce = """1. (see QEMU command line above)
-2. let the system boot
-3."""
-additional = """Problem is a hack in ladr_match - hw/net/pcnet.c:635 (present since 2006!):
-
-```
-Core was generated by `./qemu-system-sparc -rtc base=utc,clock=host -vga cg3 -g 1024x768x8 -machine SS'.
-Program terminated with signal SIGKILL, Killed.
-#0  0xffffffff7ec3b178 in ladr_match (size=110, buf=0xffffffff7ffee972 "33", s=0x808f2a20) at ../hw/net/pcnet.c:634
-634         if ((*(hdr->ether_dhost)&0x01) &&
-[Current thread is 632 (LWP    1        )]
-(gdb) list
-629     }
-630     
-631     static inline int ladr_match(PCNetState *s, const uint8_t *buf, int size)
-632     {
-633         struct qemu_ether_header *hdr = (void *)buf;
-634         if ((*(hdr->ether_dhost)&0x01) &&
-635             ((uint64_t *)&s->csr[8])[0] != 0LL) {
-636             uint8_t ladr[8] = {
-637                 s->csr[8] & 0xff, s->csr[8] >> 8,
-638                 s->csr[9] & 0xff, s->csr[9] >> 8,
-(gdb) print &s->csr[8]
-$1 = (uint16_t *) 0x808f4a7c
-```
-The address of s->csr[8], in this case, is on a 4-byte boundary not an 8-byte boundary, so the hack to test for 8 bytes (4 x 16-bit words) being 0 by casting the address up to a pointer to uint64_t and dereferencing it fails.
-
-The data does not seem to be allocated with a deterministic alignment, this failure does not always occur.
-
-A solution to avoid alignment errors could be to test
-```
-  (s->csr[8] | s->csr[9] | s->csr[10] | s->csr[11]) != 0
-```"""