diff options
Diffstat (limited to 'gitlab/issues/target_sparc/host_missing/accel_missing')
35 files changed, 1216 insertions, 0 deletions
diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1058.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1058.toml new file mode 100644 index 00000000..3b96b143 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1058.toml @@ -0,0 +1,18 @@ +id = 1058 +title = "NetBSD Sparc 8.2 OS doesn't seem to accept keyboard input (-nographic)" +state = "opened" +created_at = "2022-06-02T21:41:34.929Z" +closed_at = "n/a" +labels = ["device:input", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1058" +host-os = "RHEL 8.6" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.0.50 (v7.0.0-1253-g2417cbd591)" +guest-os = "NetBSD" +guest-arch = "sparc" +description = """The NetBSD appears to boot to the login prompt successfully, but when the login prompt appears, the system doesn't appear to recognize keyboard input and so I cannot login (I can't seem to boot into single user mode for the same reason). I can see the characters being typed on the terminal, but pressing the Enter key to submit input results in nothing. + +I've confirmed that this is an issue with NetBSD because I also attempted to spin up a Solaris 8 VM and a Solaris 2.6 VM with the `-nographic` flag turned on, and I was able to log in and interact with both of those virtual machines.""" +reproduce = """1. Use RHEL 8.6 as the base OS (**Update:** I've discovered that this error occurs under a different host OS too (Ubuntu 20.04 LTS in my case) +2. Start the NetBSD VM running the command as specified above""" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1127.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1127.toml new file mode 100644 index 00000000..bc1aae42 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1127.toml @@ -0,0 +1,137 @@ +id = 1127 +title = "Various problems with running SunOS 4.1.4" +state = "closed" +created_at = "2022-07-29T19:02:10.492Z" +closed_at = "2022-09-02T20:31:03.436Z" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1127" +host-os = "FreeBSD" +host-arch = "amd64 (x86-64)" +qemu-version = "QEMU emulator version 7.0.90 (v7.1.0-rc0-3-g3e4abe2c92-dirty) (QEMU 7.0.0 release has the same issues)" +guest-os = "SunOS 4" +guest-arch = "SPARC" +description = """Yes, I know, SunOS 4.1.4 is ancient, but I happened to find an original Solaris 1.1.2/SunOS 4.1.4 installation CD, and nostalgia got the better of me. + +It used to be possible to run SunOS 4.1.4 in QEMU 5.0.0, but starting with 6.0.0, whenever you try to boot, you see the following whenever SunOS tries to access a SCSI disk: + +``` +ok boot disk +Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: +root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0:a fstype 4.2 +Boot: vmunix +Size: 1548288+463688+225704 bytes +SuperSPARC: PAC ENABLED +SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994 +Copyright (c) 1983-1993, Sun Microsystems, Inc. +cpu = SUNW,SPARCstation-20 +mod0 = TI,TMS390Z50 (mid = 8) +mem = 523836K (0x1ff8f000) +avail mem = 510947328 +cpu0 at Mbus 0x8 0x240000 +entering uniprocessor mode +Ethernet address = 52:54:0:12:34:56 +espdma0 at SBus slot f 0x400000 +esp0 at SBus slot f 0x800000 pri 4 (onboard) +esp0: data transfer overrun + State=DATA Last State=DATA_DONE + Latched stat=0x11<XZERO,IO> intr=0x10<BUS> fifo 0x0 + last msg out: EXTENDED; last msg in: COMMAND COMPLETE + DMA csr=0xa4240030<FLSH,INTEN> + addr=fff00034 last=fff00010 last_count=24 + Cmd dump for Target 3 Lun 0: + cdb=[ 0x12 0x0 0x0 0x0 0x24 0x0 ] + pkt_state 0xf<XFER,CMD,SEL,ARB> pkt_flags 0x9 pkt_statistics 0x0 + cmd_flags=0x5 cmd_timeout 0 + Mapped Dma Space: + Base = 0x10 Count = 0x24 + Transfer History: + Base = 0x10 Count = 0x24 + current phase 0x26=DATAIN stat=0x11 0x24 + current phase 0x1=CMD_START stat=0x12 0x12 + current phase 0x60=SELECT_SNDMSG stat=0x7 0x3 0x0 + current phase 0x23=SYNCHOUT stat=0x7 0x19 0xf + current phase 0xb=CMD_CMPLT stat=0x7 0x0 + current phase 0x27=STATUS stat=0x7 0x0 + current phase 0xb=CMD_CMPLT stat=0x13 + current phase 0x80=SEL_NO_ATN stat=0x0 0x3 0x0 + current phase 0x1=CMD_START stat=0x0 0x0 0x80 + current phase 0x1c=RESET stat=0x0 0x1f +``` + +This causes SunOS to ignore the disk, and later it tries to boot via ethernet instead. + +After some digging, I *think* I tracked down the problem. + +This commit seems to be what did it: + +commit 799d90d818ba38997e9f5de2163bbfc96256ac0b +Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> +Date: Thu Mar 4 22:10:58 2021 +0000 + + esp: transition to message out phase after SATN and stop command + + The SCSI bus should remain in the message out phase after the SATN and stop + command rather than transitioning to the command phase. A new ESPState variable + cmdbuf_cdb_offset is added which stores the offset of the CDB from the start + of cmdbuf when accumulating extended message out phase data. + + Currently any extended message out data is discarded in do_cmd() before the CDB + is processed in do_busid_cmd(). + + Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> + Reviewed-by: Laurent Vivier <laurent@vivier.eu> + Message-Id: <20210304221103.6369-38-mark.cave-ayland@ilande.co.uk> + +I determined this by rummaging through the changes to the esp.c driver between 5.0.0 and 6.0.0 until I stumbled across this one. I can make the problem go away with this simple change: + +``` +--- esp.c.orig 2022-04-19 12:10:27.000000000 -0700 ++++ esp.c 2022-07-25 19:57:06.602665000 -0700 +@@ -433,7 +433,7 @@ + trace_esp_handle_satn_stop(fifo8_num_used(&s->cmdfifo)); + s->do_cmd = 1; + s->cmdfifo_cdb_offset = 1; +- s->rregs[ESP_RSTAT] = STAT_MO; ++ s->rregs[ESP_RSTAT] = STAT_TC | STAT_CD /*STAT_MO*/; + s->rregs[ESP_RINTR] |= INTR_BS | INTR_FC; + s->rregs[ESP_RSEQ] = SEQ_MO; + esp_raise_irq(s); +``` + +NOTE: I am not sure if this is a proper fix, as I don't know enough about SCSI or the esp controller. All I know is putting this back the way it was makes SunOS happy again. Unfortunately it may also break something else, so somebody more knowledgeable than I should investigate further. + +If you're worried that reproducing this will be difficult, don't be. I prepared detailed instructions, scripts and all the images you should need to create a virtual SunOS disk and install the OS on it. This includes the OpenProm images and installation ISO. + +You can find everything here (consult readme.txt for details): + +http://people.freebsd.org/~wpaul/sunos-qemu + +The quick install option is very simple. Once you finish writing the OS to the disk and try to boot off it the first time, you should encounter the error above. + +But wait, there's more. + +SunOS 4 has this quirk where it only works with CD-ROM drives that report a block size of 512 bytes, instead of the default of 2048. Now, I realize that just recently, there was a change committed that allows the guest to change the block size with the MODE SELECT command. However this doesn't seem to be good enough for SunOS (I tried it, it still hates the drive). Note that scsi-disk.c hard codes the block size for CD-ROMs to 2058 in scsi_cd_realize(). What would be really nice is if was possible to override this from the command line, and that addresses the problem quite nicely. + +At the same URL above, I also provided a small patch to scsi-disk.c which implements this feature. This allows the user to set the initial block size with logical_block_size=512 when specifying the device parameters. The qemu_sparc5.sh and qemu_sparc20.sh scripts show an example of this. + +One more thing: I wanted to simulate a SPARCstation 20, but I found that SunOS 4 would panic when I tried to boot it with this configuration, even if I used the correct SS20 OpenProm image. The problem here has to do with the SUNW,DBRIe device. QEMU doesn't simulate this device, but it creates dummy resources for it, including a PROM space. The problem is that this space is empty. This causes the OpenProm to create a node with an empty "name" property, which is a condition the SunOS kernel doesn't expect. The result is that the kernel tries to dereference a NULL pointer and panics. (The OpenProm code itself seems to let it slide.) + +To work around this, I patched the sun4m.c code to create the SUNW,DBRIe device such that its PROM space can actually be populated with an FCode image, and I created a simple one with a valid name property so that the kernel doesn't panic. SunOS complains later that it can't find the audio device because it's not actually implemented, but at least it doesn't crash. + +I don't know how this would actually be addressed in QEMU proper since the existing FCode images that QEMU uses come from OpenBios. + +Finally, one thing I haven't figured out is that using the -smp flag with SunOS 4 never seems to work. The OpenProms and the SunOS kernel only ever seem to detect one CPU. I am not that broken up about this though, because SunOS 4 never really did SMP very well to begin with.""" +reproduce = """Download all the files at: + +http://people.freebsd.org/~wpaul/sunos-qemu + +You can download just: + +http://people.freebsd.org/~wpaul/sunos-qemu/sunos-qemu.tar.gz + +if you want everything in one shot. + +Read the readme.txt file. This will walk you through trying to create a bootable SunOS system. You should apply the CD-ROM patch to scsi-disk.c and use the qemu_sparc5.sh script initially. This should allow you to install the miniroot from the CD image onto the virtual hard drive, but it will fail booting due to the esp controller problem. The qemu_sparc20.sh script will only boot successfully if you apply the sun4m.c patch and copy QEMU,dbri.bin to the QEMU firmware directory.""" +additional = """I'm not planning to provide a pull request for any of this. As I said, I'm not sure if my fixes are necessarily correct (especially the esp.c one). I'm satisfied that they work for me, but I want to leave it to the appropriate maintainers do decide how to best deal with these things. + +I would be happy to answer questions and test candidate fixes though.""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1132.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1132.toml new file mode 100644 index 00000000..13b958e0 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1132.toml @@ -0,0 +1,123 @@ +id = 1132 +title = "[SPARC/Leon3] Application compiled by RCC 1.2 won't start" +state = "closed" +created_at = "2022-07-30T18:22:09.328Z" +closed_at = "2022-08-09T02:41:17.248Z" +labels = ["target: sparc", "workflow::In Progress"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1132" +host-os = "Windows 10" +host-arch = "SPARC" +qemu-version = "7.0.50 (v7.0.0-11902-g1d935f4a02-dirty)" +guest-os = "n/a" +guest-arch = "SPARC" +description = """Even simple "hello world" application compiled by Gaisler RCC 1.2 compiler ("space-certified" GCC 4.4.6 with RTEMS OS) for Leon3 CPU won't start on QEMU - QEMU silently exits before getting into `Init`. + +In real hardware it works. + +(I know that the GCC 4.4.6 is quite ancient now, usage of this toolchain is forced)""" +reproduce = """Steps provided for Windows system, but I suspect it works exactly the same in Linux system. + +1. Get `sparc-rtems-4.10-gcc-4.4.6-1.2.25-mingw` GCC from here: https://www.gaisler.com/anonftp/rcc/rcc-1.2/1.2.25/ +2. Unpack it to `c:\\opt` (it doesn't work from other directories. `/opt` for Linux) +3. Create simple "Hello world" RTEMS application. +4. Run it by `qemu-system-sparc -machine leon3_generic -nographic -monitor null -serial stdio -m 64M -kernel fail.elf` +5. Result is exiting before getting into `Init`. + +Simple example attached (with ELF). It should print `It works. Exiting.` and exit. + +[leon3-rcc-start-fail.zip](/uploads/69d79dcc496e86bb07d5c69212d94ced/leon3-rcc-start-fail.zip)""" +additional = """Log: + +``` +... + +---------------- +IN: ambapp_for_each_dev +0x40005430: clr %o0 ! 0x0 +0x40005434: ret +0x40005438: restore %g0, %o0, %o0 + +---------------- +IN: amba_initialize +0x40003aa8: cmp %o0, 0 +0x40003aac: be 0x40003b4c +0x40003ab0: nop + +---------------- +IN: amba_initialize +0x40003b4c: mov 1, %g1 +0x40003b50: ta 0 + + 1: Trap Instruction (v=80) +pc: 40003b50 npc: 40003b54 +%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000 +%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0 +%l0-7: 40025800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +%i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 43fffec0 40002b78 +psr: f3400fe5 (icc: -Z-- SPE: SPE) wim: 00000002 +fsr: 00000000 y: ffffffff + +---------------- +IN: +0x40003a18: cmp %g1, 3 +0x40003a1c: bne 0x40003a34 +0x40003a20: and %i0, 0xf00, %l4 + +---------------- +IN: +0x40003a34: ta 0 + + 2: Trap Instruction (v=80) +pc: 40003a34 npc: 40003a38 +%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000 +%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470 +%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800 +%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0 +psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002 +fsr: 00000000 y: ffffffff + + 3: Trap Instruction (v=80) +pc: 40003a34 npc: 40003a38 +%g0-7: 00000000 00000001 00000000 00000000 00000000 00000000 400007c0 00000000 +%o0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe00 40005470 +%l0-7: f3400fc4 40003b50 40003b54 00000080 00000000 40026ab8 00000000 fffff800 +%i0-7: 00000000 00000034 00000001 0000000d 40004b04 00000000 43fffe60 40003aa0 +psr: f3900fc4 (icc: N--C SPE: SP-) wim: 00000002 +fsr: 00000000 y: ffffffff + +// repeating until sudden and quiet exit from QEMU +``` + +After digging it seems that target code requires byte access to GRLIB APB PNP registers that is not implemented in QEMU now. +Adding code supporting byte access seems to help. + +The quick patch is: + +``` +--- a/hw/misc/grlib_ahb_apb_pnp.c ++++ b/hw/misc/grlib_ahb_apb_pnp.c +@@ -249,6 +249,11 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size) + val = apb_pnp->regs[offset >> 2]; + trace_grlib_apb_pnp_read(offset, val); + ++ if (size == 1) { ++ val >>= (24 - (offset & 3) * 8); ++ val &= 0x0ff; ++ } ++ + return val; + } + +@@ -263,7 +268,7 @@ static const MemoryRegionOps grlib_apb_pnp_ops = { + .write = grlib_apb_pnp_write, + .endianness = DEVICE_BIG_ENDIAN, + .impl = { +- .min_access_size = 4, ++ .min_access_size = 1, + .max_access_size = 4, + }, + }; + +``` + +The custom compiled QEMU with this patch is used in project for over half a year and it works fine, but I don't know if it is a proper fix.""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1163.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1163.toml new file mode 100644 index 00000000..b6d4f52c --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1163.toml @@ -0,0 +1,21 @@ +id = 1163 +title = "qemu doesn't boot Solaris 2.2" +state = "opened" +created_at = "2022-08-16T23:39:20.942Z" +closed_at = "n/a" +labels = ["target: sparc", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1163" +host-os = "macOS and Linux" +host-arch = "SPARC" +qemu-version = "(7.0, 4.2.1)" +guest-os = "Solaris" +guest-arch = "SPARC" +description = """Booting from the CDROM hangs""" +reproduce = """1. Run the command line above with a fresh disk image +2. The console contains: +``` +Trying cdrom:d... +(is ? +``` +3. No further progress""" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1166.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1166.toml new file mode 100644 index 00000000..a2c7cc92 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1166.toml @@ -0,0 +1,35 @@ +id = 1166 +title = "Solaris 2.6 panic when debugging with gdb" +state = "closed" +created_at = "2022-08-19T13:16:09.746Z" +closed_at = "2024-04-14T12:07:21.904Z" +labels = ["Closed::Fixed", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1166" +host-os = "macOS 10.15" +host-arch = "x86-64" +qemu-version = "7.0.0" +guest-os = "Solaris 2.6" +guest-arch = "SPARC" +description = """Running gdb with a breakpoint that gets hit triggers a panic: +``` +non parity synchronous error ctx=fa va=ef7d97c pa=c1a47c +``` + +One time I got of the following messages as well +``` +processor level 12 onboard interrupt not serviced +processor level 12 onboard interrupt not serviced +... +```""" +reproduce = """1. Install Solaris 2.6 using https://learn.adafruit.com/build-your-own-sparc-with-qemu-and-solaris?view=all +2. Install https://archive.org/details/sun26gnu +3. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gdb-6.8-sol26-sparc-local.gz +4. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gcc-2.95.3-sol26-sparc-local.gz +5. Build a simple hello world program with debugging information +6. +``` +gdb ./hello +(gdb) break main +(gdb) run +```""" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1394.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1394.toml new file mode 100644 index 00000000..c0ef72f4 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1394.toml @@ -0,0 +1,69 @@ +id = 1394 +title = "Byte-swapping issue in getresuid on qemu-user-sparc64" +state = "closed" +created_at = "2022-12-25T13:24:39.830Z" +closed_at = "2023-03-31T11:59:20.559Z" +labels = ["TestCase", "linux-user", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1394" +host-os = "Debian bookworm/sid" +host-arch = "x86_64" +qemu-version = "qemu-sparc64 version 7.1.0 (Debian 1:7.1+dfsg-2+b3)" +guest-os = "Debian sid" +guest-arch = "sparc64" +description = """When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed. + +For example, the UID 0x000003e8 (1000) becomes 0x03e80000.""" +reproduce = """A minimal test case looks like this: +```c +#define _GNU_SOURCE +#include <stdio.h> +#include <sys/types.h> +#include <pwd.h> +#include <unistd.h> + +int main(int argc, char **argv) { +\tstruct passwd *pw = getpwuid(geteuid()); +\tif (pw == NULL) { +\t\tperror("getpwuid failure"); +\t\treturn 1; +\t} +\tprintf("getpwuid()->pw_uid=0x%08x\\n", pw->pw_uid); + +\tuid_t ruid = 0, euid = 0, suid = 0; +\tif (getresuid(&ruid, &euid, &suid) != 0) { +\t\tperror("getresuid failure"); +\t\treturn 1; +\t} +\tprintf("getresuid()->suid=0x%08x\\n", suid); + +\treturn 0; +} +``` + +Compile and run with: +``` +$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c +$ sudo chroot sid-sparc64 +[chroot] $ qemu-sparc64-static ./test +``` + +Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`): +``` +$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c +$ qemu-sparc64-static ./test +``` + +Expected output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x000003e8 +``` + +Actual output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x03e80000 +```""" +additional = """I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu.""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1564.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1564.toml new file mode 100644 index 00000000..68f0df5f --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1564.toml @@ -0,0 +1,78 @@ +id = 1564 +title = "stat64 on sparc64 failed to get correct major/minor dev" +state = "opened" +created_at = "2023-03-28T11:33:28.707Z" +closed_at = "n/a" +labels = ["linux-user", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1564" +host-os = "Slackware 15.0" +host-arch = "x86" +qemu-version = "7.2.91" +guest-os = "Slackware 14.2" +guest-arch = "sparc64" +description = """The reported device major/minor is not correct, e.g: stat /dev/zero: +Reported: Device type: 0,10500000 +Correct : Device type: 1,5""" +reproduce = """1. "stat /dev/zero" or "ls -l /dev/zero"""" +additional = """The problem is a missing padding into target_stat64 struct related to sparc64. Here patch to solve the issue (it also fixes some incorrect variables size): + +``` +--- qemu-20230327/linux-user/syscall_defs.h\t2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/linux-user/syscall_defs.h.new\t2023-03-27 21:43:25.615115126 +0200 +@@ -1450,7 +1450,7 @@ struct target_stat { + \tunsigned int\tst_dev; + \tabi_ulong\tst_ino; + \tunsigned int\tst_mode; +-\tunsigned int\tst_nlink; ++\tshort int\tst_nlink; + \tunsigned int\tst_uid; + \tunsigned int\tst_gid; + \tunsigned int\tst_rdev; +@@ -1465,8 +1465,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +-\tunsigned char\t__pad0[6]; +-\tunsigned short\tst_dev; ++\tuint64_t\tst_dev; + + \tuint64_t\tst_ino; + \tuint64_t\tst_nlink; +@@ -1476,14 +1475,13 @@ struct target_stat64 { + \tunsigned int\tst_uid; + \tunsigned int\tst_gid; + +-\tunsigned char\t__pad2[6]; +-\tunsigned short\tst_rdev; ++\tunsigned int\t__pad0; ++\tuint64_t\tst_rdev; + + int64_t\t\tst_size; + \tint64_t\t\tst_blksize; + +-\tunsigned char\t__pad4[4]; +-\tunsigned int\tst_blocks; ++\tint64_t\t\tst_blocks; + + \tabi_ulong\ttarget_st_atime; + \tabi_ulong\ttarget_st_atime_nsec; +@@ -1522,8 +1520,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +-\tunsigned char\t__pad0[6]; +-\tunsigned short\tst_dev; ++\tuint64_t st_dev; + + \tuint64_t st_ino; + +@@ -1533,8 +1530,7 @@ struct target_stat64 { + \tunsigned int\tst_uid; + \tunsigned int\tst_gid; + +-\tunsigned char\t__pad2[6]; +-\tunsigned short\tst_rdev; ++\tuint64_t st_rdev; + + \tunsigned char\t__pad3[8]; +```""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1609.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1609.toml new file mode 100644 index 00000000..5adc1116 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1609.toml @@ -0,0 +1,27 @@ +id = 1609 +title = "SPARC emulation: userspace program run from gdb crashes OS running in emulator" +state = "closed" +created_at = "2023-04-19T11:26:24.004Z" +closed_at = "2024-04-14T12:07:21.890Z" +labels = ["Closed::Fixed", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1609" +host-os = "Ubuntu 22.10" +host-arch = "x86-64" +qemu-version = "QEMU emulator version 7.0.0 (Debian 1:7.0+dfsg-7ubuntu2.2)" +guest-os = "SUN Solaris" +guest-arch = "SPARC" +description = """SPARC emulation: userspace program run from gdb crashes OS running in emulator""" +reproduce = """As a user (not root!): +1. as -Q n -K PIC -b -L mandelbrot.s +2. ld -m a.out -o test +3. gdb ./test +4. run + +`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz).""" +additional = """[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s) + +screenshot: https://imgur.com/a/JD51DJA + +It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system. + +~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz)""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1745.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1745.toml new file mode 100644 index 00000000..905fbf43 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1745.toml @@ -0,0 +1,77 @@ +id = 1745 +title = "qemu-system-sparc64 v8.0.2 failed to read the file system." +state = "closed" +created_at = "2023-07-03T06:40:17.253Z" +closed_at = "2023-07-06T02:54:16.318Z" +labels = ["target: sparc", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1745" +host-os = "Ubuntu 20.04.6 LTS" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 8.0.2" +guest-os = "OpenBoot 4.20.0" +guest-arch = "sparc64" +description = "n/a" +reproduce = """1. Run qemu-system-sparc64 with the following command line. + `qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2` +2. The system will report a issue "Could not open option rom 'pflash0': No such file or directory" +3. Then, enter the boot command on the boot loader. +4. The command failed with following message. +``` +Boot device: vdisk File and args: +Bad magic number in disk label +Can't open disk label package + +Can't open boot device +```""" +additional = """``` +$ qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2 +Could not open option rom 'pflash0': No such file or directory +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +Bad magic number in disk label +Can't open disk label package + +Can't open boot device + +ok +``` + +It works fine with the previous qemu-system-sparc64 version. + +``` +$ qemu-7.2.3/build/qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54. +FCode UFS Reader 1.12 00/07/17 15:48:16. +Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot +Loading: /platform/sun4v/ufsboot +SunOS Release 5.10 Version Generic_118822-23 64-bit +Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Hostname: unknown + +unknown console login: +```""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1807.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1807.toml new file mode 100644 index 00000000..547a6ebf --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1807.toml @@ -0,0 +1,34 @@ +id = 1807 +title = "sparc64 always segfaults doesn't work on Ubuntu 23.04" +state = "closed" +created_at = "2023-08-03T21:30:22.072Z" +closed_at = "2023-08-06T03:24:16.447Z" +labels = ["Closed::Invalid", "linux-user", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1807" +host-os = "Ubuntu 23.04" +host-arch = "x86_64" +qemu-version = "7.2" +guest-os = "n/a" +guest-arch = "n/a" +description = """It segfaults when it tries to use 'printf' or 'puts' to print to the screen.""" +reproduce = """Do the following at the command line + +``` +$ sparc64-linux-gnu-g++ --version +sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +$ echo -e "#include <stdio.h> \\n int main(void) { puts(\\"Hello World\\"); }" > test.cpp +$ sparc64-linux-gnu-g++ -o test test.cpp -static +$ qemu-sparc64-static --version +qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +$ qemu-sparc64-static ./test +Segmentation fault (core dumped) +$ qemu-sparc-static ./test +qemu-sparc-static: ./test: Invalid ELF image for this architecture +$ qemu-sparc32plus-static ./test +qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture +```""" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/1901.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/1901.toml new file mode 100644 index 00000000..198b1b3f --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/1901.toml @@ -0,0 +1,27 @@ +id = 1901 +title = "qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction" +state = "closed" +created_at = "2023-09-22T19:14:54.496Z" +closed_at = "2024-05-06T22:29:26.400Z" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1901" +host-os = "Gentoo GNU/Linux" +host-arch = "ppc64le" +qemu-version = "qemu-sparc64 version 8.1.50 (v8.1.0-951-gb55e4b9c05); also observed in 8.0.4 release" +guest-os = "N/A" +guest-arch = "SPARC (v9 w/ VIS)" +description = """Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications.""" +reproduce = """1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results.""" +additional = """[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c)""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2015.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2015.toml new file mode 100644 index 00000000..ee01d403 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2015.toml @@ -0,0 +1,35 @@ +id = 2015 +title = "qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5" +state = "opened" +created_at = "2023-12-03T11:33:07.047Z" +closed_at = "n/a" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2015" +host-os = "Windows 10 22H2" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 8.1.91 (v8.2.0-rc1-12040-g59b55cb373)" +guest-os = "Solaris 8 with Sun PROM" +guest-arch = "sparc" +description = """Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error.""" +reproduce = """1. Launch qemu with command line above +2. Sun PROM tries to boot from the network and shows `Tiemout waiting for ARP/RARP packet` messages +3. Interrupt network boot entering `sendkey stop-a` in qemu monitor (`compat_monitor0`) +4. Back in Sun PROM, boot from cdrom: `boot cdrom:d` +5. Solaris 8 starts booting +6. qemu exits with fatal error + +```plaintext +qemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f0041298 npc: f004129c +%g0-7: 00000000 f02441a8 04400fc2 000001e2 00000027 f0243b88 00000000 f0244020 +%o0-7: ffff8000 00008000 00000f00 044000c1 f0258518 ffeec000 fbe3a4b8 f0041be4 +%l0-7: 04400fc1 f0041c78 f0041c7c 00000002 0000010f 00000002 0000002a fbe39f78 +%i0-7: ffff8000 00008000 00000f00 044000c2 00000000 ffeec000 fbe3a020 f0041be4 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00000000 y: 00000000 +```""" +additional = """""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2017.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2017.toml new file mode 100644 index 00000000..506d4085 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2017.toml @@ -0,0 +1,25 @@ +id = 2017 +title = "Qemu 8.1-8.2 Sparc Now Timeout Boot Failing with Sun Bios" +state = "opened" +created_at = "2023-12-03T17:57:57.723Z" +closed_at = "n/a" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2017" +host-os = "Devuan Beowulf" +host-arch = "amd64" +qemu-version = "8.1, 8.2, and current" +guest-os = "Solaris 2.4+" +guest-arch = "sparc model SS-5 and SS-20" +description = """Boot with original Sun bios never reaches the ok prompt. You get a series of ongoing network boot attempts with the message "Timeout waiting for ARP/RARP package." + +On earlier versions of Qemu up to and including 8.0, you could use the original firmware in the combinations below on Sparc model SS-5 and SS-20 machines. + +Note: Model SS-5 needs the cpu set to "TI MicroSparc II" or "TI MicroSparc IIep." Model SS-20 needs the cpu set to "TI SuperSparc 50" or "TI SuperSparc 60."""" +reproduce = """1. Use Qemu 8.1, 8.2, or current +2. Run above command line using original sun bios +3. See result below + +""" +additional = """Glad to test further and give checksums in bios files if needed. Have real hardware for the Sparcstation 5. Default lance card on qemu is active with usermode networking. + +Sun bios helps for booting some older versions of Solaris and is generally nice to have for testing.""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2059.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2059.toml new file mode 100644 index 00000000..0b42ac85 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2059.toml @@ -0,0 +1,31 @@ +id = 2059 +title = "Solaris 2.6.5 panic when trying to debug a binary with Sun Workshop V5n1, or V6n1 debugger" +state = "closed" +created_at = "2023-12-28T08:23:00.133Z" +closed_at = "2024-04-14T12:07:21.921Z" +labels = ["Closed::Fixed", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2059" +host-os = "Linux" +host-arch = "x86-64/AMD64" +qemu-version = "8.0.5, 8.2.0rc4, master 8.2.50 (v8.2.0-196-g7425b6277f)" +guest-os = "Solaris 2.6.5" +guest-arch = "Sun4m" +description = """Following [this guide](https://www.gekk.info/articles/solaris26.htm), and similarly to issue #1166, the guest panics when one tries to debug a binary with the debugger provided in [Sun Workshop V5n1](https://archive.org/details/sunworkshopforsolaris2vol5num1_704546810revb), and in [Sun Workshop v6n1](https://archive.org/details/devpro_v6n1) as well. +The Sun Workshop is EOL, available at the archive, with free non-expiring demo licenses [made available](https://archive.org/details/suncomp-lic) by Sun before the Oracle acquisition. +The guest was patched with the latest available patches included [in this cluster](https://archive.org/details/sun26gnu). +The following information was collected when debugging bunzip2, but any binary panics the guest. +``` +panic: Non-parity synchronous error: ctx=54 va=ef7cbc44 pa=e0a8c44 +syncing filesystems... 15 done +NOTICE: zs3:ring buffer overflow +```""" +reproduce = """1. Start the Sun Workshop (SUNWspro/bin/workshop), go to the Debugger in the menu +2. Debug/New Program, load any binary, place a breakpoint in main or wherever +3. Execute, guest kernel panic""" +additional = """This happens with the Fujitsu MB86904 specified as CPU, and without specifying a cpu, using the default for the SS-5. + + + +Explicitly setting the TI MicroSparc I and setting memory to 32M seems to start the debugger, the guest still panics, but a bit further down the line + +""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2141.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2141.toml new file mode 100644 index 00000000..5ae33762 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2141.toml @@ -0,0 +1,32 @@ +id = 2141 +title = "Output of \"-cpu help\" for sparc does not clearly indicate the valid input for \"-cpu\" option." +state = "closed" +created_at = "2024-02-01T00:13:33.887Z" +closed_at = "2024-05-06T19:58:15.224Z" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2141" +host-os = "Any" +host-arch = "Any" +qemu-version = "8.2.50" +guest-os = "- OS/kernel version:" +guest-arch = "## Description of problem" +description = """The output of the "-cpu help" does not indicate clearly what the input to a "-cpu" command can be.""" +reproduce = """1. ./qemu-system-sparc -cpu help""" +additional = """``` +% ./qemu-system-sparc -cpu help +Sparc Fujitsu MB86904 IU 04000000 FPU 00080000 MMU 04000000 NWINS 8 +Sparc Fujitsu MB86907 IU 05000000 FPU 00080000 MMU 05000000 NWINS 8 +Sparc TI MicroSparc I IU 41000000 FPU 00080000 MMU 41000000 NWINS 7 -fsmuld +Sparc TI MicroSparc II IU 42000000 FPU 00080000 MMU 02000000 NWINS 8 +Sparc TI MicroSparc IIep IU 42000000 FPU 00080000 MMU 04000000 NWINS 8 +Sparc TI SuperSparc 40 IU 41000000 FPU 00000000 MMU 00000800 NWINS 8 +Sparc TI SuperSparc 50 IU 40000000 FPU 00000000 MMU 01000800 NWINS 8 +Sparc TI SuperSparc 51 IU 40000000 FPU 00000000 MMU 01000000 NWINS 8 +Sparc TI SuperSparc 60 IU 40000000 FPU 00000000 MMU 01000800 NWINS 8 +Sparc TI SuperSparc 61 IU 44000000 FPU 00000000 MMU 01000000 NWINS 8 +Sparc TI SuperSparc II IU 40000000 FPU 00000000 MMU 08000000 NWINS 8 +Sparc LEON2 IU f2000000 FPU 00080000 MMU f2000000 NWINS 8 +Sparc LEON3 IU f3000000 FPU 00080000 MMU f3000000 NWINS 8 +``` +It's unclear from this output whether an appropriate choice for a -cpu option is +"Sparc Fujitsu MB86904", "Sparc Fujitsu MB86904", "Fujitsu MB86904", "MB86904", or even something else like "FJI, MB86904"""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2143.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2143.toml new file mode 100644 index 00000000..9338ee70 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2143.toml @@ -0,0 +1,46 @@ +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 +```""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/216.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/216.toml new file mode 100644 index 00000000..93605518 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/216.toml @@ -0,0 +1,15 @@ +id = 216 +title = "qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with \"panic - kernel: no nucleus hblk8 to allocate\"" +state = "opened" +created_at = "2021-05-08T05:37:30.642Z" +closed_at = "n/a" +labels = ["Launchpad", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/216" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2163.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2163.toml new file mode 100644 index 00000000..2e458dd8 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2163.toml @@ -0,0 +1,15 @@ +id = 2163 +title = "Move architecture specific interruption code around SPARC CPUs from hw/sparc/ to target/sparc/" +state = "opened" +created_at = "2024-02-13T12:59:21.079Z" +closed_at = "n/a" +labels = ["Bite Sized", "kind::Task", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2163" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2281.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2281.toml new file mode 100644 index 00000000..06513204 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2281.toml @@ -0,0 +1,19 @@ +id = 2281 +title = "[bugfix incl.] Solaris Debuggers Panic OS with \"Nonparity Synchronous Error\"" +state = "closed" +created_at = "2024-04-11T05:24:00.912Z" +closed_at = "2024-04-14T12:07:21.905Z" +labels = ["Closed::Fixed", "Stable::to backport", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2281" +host-os = "Windows 11 Pro 23H2 (using MSYS2 Mingw64)" +host-arch = "x86_64" +qemu-version = "8.2.92 (v9.0.0-rc2-27-gce64e6224a-dirty)" +guest-os = "Solaris 9" +guest-arch = "sparc" +description = """General use of a debugger (mdb, adb, gdb), such as single-stepping, causing a breakpoint to trigger, and/or simply running a program will cause a kernel panic of "Nonparity Synchronous Error" on many versions of Solaris / SunOS. + +This a well reported issue. + +#""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2319.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2319.toml new file mode 100644 index 00000000..a901029e --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2319.toml @@ -0,0 +1,29 @@ +id = 2319 +title = "SPARC32-bit SDIV of negative divisor gives wrong result" +state = "closed" +created_at = "2024-04-30T01:02:36.888Z" +closed_at = "2024-06-23T12:33:26.420Z" +labels = ["target: sparc", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2319" +host-os = "- any -" +host-arch = "- QEMU flavor:" +qemu-version = "9.0.00" +guest-os = "- OS/kernel version:" +guest-arch = "SPARC" +description = """SDIV of negative divisor gives wrong result because of typo in helper_sdiv(). This is true for QEMU 9.0.0 and earlier. + +Place -1 in the Y register and -128 in another reg, then -120 in another register and do SDIV into a result register, instead of the proper value of 1 for the result, the incorrect value of 0 is produced. + +There is a typo in target/sparc/helper.c that causes the divisor to be consider unsigned, this patch fixes it: + +\\*\\*\\* helper.c.ori Tue Apr 23 16:23:45 2024 --- helper.c Mon Apr 29 20:14:07 2024 + +--- + +\\*\\*\\* 121,127 \\*\\*\\*\\* return (uint32_t)(b32 \\< 0 ? INT32_MAX : INT32_MIN) | (-1ull \\<\\< 32); } + +! a64 /= b; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \\< 0 ? INT32_MIN : INT32_MAX) | (-1ull \\<\\< 32); --- 121,127 ---- return (uint32_t)(b32 \\< 0 ? INT32_MAX : INT32_MIN) | (-1ull \\<\\< 32); } + +! a64 /= b32; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \\< 0 ? INT32_MIN : INT32_MAX) | (-1ull \\<\\< 32);""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2340.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2340.toml new file mode 100644 index 00000000..92388988 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2340.toml @@ -0,0 +1,43 @@ +id = 2340 +title = "SPARC fp operation INVALID trap hangs on offending instruction." +state = "closed" +created_at = "2024-05-09T18:06:23.731Z" +closed_at = "2024-09-13T14:08:37.007Z" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2340" +host-os = "FreeBSD" +host-arch = "amd64" +qemu-version = "9.0.0" +guest-os = "SunOS (Solaris)" +guest-arch = "SPARC32 (SS-5)" +description = """An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE. However, instead, the program seems to hang on the offending instruction, never moving forward. + +This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result . The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap. However, the program simply hangs on the FDTOI instruction instead of receiving the signal. + +It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail? + +`#include <ieeefp.h>` + +`main()` + +`{` + + `double val;` + + `int i;` + + `fpsetmask(FP_X_INV);` + + `val = 1000000000000003.0; /* Number that is too large for int */` + + `printf("val is %f\\n", val);` + + `i = val;` + + `printf("i is %d\\n", i);` + +`}`""" +reproduce = """1. Enable IEEE iNValid operation traps in the TEM in the FSR. +2. Generate an instruction that causes an iNValid trap +3. Instruction hangs, no SIGFPE is generated""" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2518.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2518.toml new file mode 100644 index 00000000..1d73f151 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2518.toml @@ -0,0 +1,22 @@ +id = 2518 +title = "Incorrect vertical mouse leaps on qemu-system-sparc" +state = "closed" +created_at = "2024-08-19T16:48:44.791Z" +closed_at = "2024-09-16T10:21:30.334Z" +labels = ["device:input", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2518" +host-os = "Ubuntu 22.04" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 9.0.2" +guest-os = "Solaris 2.5.6 (sparc)" +guest-arch = "sparc" +description = """In openwin (i.e. X) if you turn the scrollwheel on the mouse 1 click the cursor jumps almost all of the way down the screen. Similarly, just pressing the scroll wheel (middle click) multiple times will sometimes produce similar behavior but the cursor doesn't jump as far.""" +reproduce = """- Boot Solaris and log in +- capture the mouse by clicking on the screen +- position the mouse cursor near the top of the screen (just so you can see how far it jumps) +- click the scroll wheel up or down one click and observe the cursor jump downward""" +additional = """The issue is independent of which graphic display is used -- sdl, gtk and vnc all do the same thing. Debugging so far suggests that the problem is related to the fact that `sunmouse_event` in `escc.c` is sending a flood of duplicate events in response to the mouse scroll action. My surmise is that this is causing one byte to be dropped from the 5 byte mouse protocol expected by the Solaris kernel and that it is interpreting a sync byte as a vertical motion byte. + +`sunmouse_event` should not send events with only `dz` non-zero and no button changes. The Mouse Systems Corp spec for the the Sun mouse says that it never sends duplicate events (i.e. an event is produced only if there is non-zero `dx` or `dy` or there has been a button state change), and the mouse protocol has no support for `dz` events. + +I will propose a patch shortly to enforce this (and which has seemingly fixed the problem).""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2534.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2534.toml new file mode 100644 index 00000000..b863ecfb --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2534.toml @@ -0,0 +1,18 @@ +id = 2534 +title = "Solaris cannot be power offed with system_powerdown on qemu-system-sparc" +state = "opened" +created_at = "2024-08-24T18:36:22.024Z" +closed_at = "n/a" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2534" +host-os = "Ubuntu 24.04" +host-arch = "x86_64" +qemu-version = "8.2.2 (Debian 1:8.2.2+ds-0ubuntu1.2)" +guest-os = "Solaris 2.6" +guest-arch = "SPARC/sun4m" +description = """When a `system_powerdown` is done in the QEMU Monitor, nothing happens. Also happens with `qemu-system-sparc.exe` version 9.1.0-rc3, that is, it's not fixed in newer versions. Looking at [sun4m.c](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/sparc/sun4m.c#L451) code, it registers a system_powerdown handler, but it's not working.""" +reproduce = """1. Start the machine with the command line above and wait for the complete OS initialization +2. Open the machine monitor +3. Do a `system_powerdown` command +4. Nothing will happen""" +additional = """""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/255.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/255.toml new file mode 100644 index 00000000..2acf5143 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/255.toml @@ -0,0 +1,15 @@ +id = 255 +title = "Build on sparc64 fails with \"undefined reference to `fdt_check_full'\"" +state = "closed" +created_at = "2021-05-10T18:59:21.760Z" +closed_at = "2021-09-06T13:36:46.343Z" +labels = ["Build System", "Launchpad", "target: sparc", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/255" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/260.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/260.toml new file mode 100644 index 00000000..d5108843 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/260.toml @@ -0,0 +1,15 @@ +id = 260 +title = "qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso" +state = "opened" +created_at = "2021-05-11T05:34:46.748Z" +closed_at = "n/a" +labels = ["Launchpad", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/260" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2618.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2618.toml new file mode 100644 index 00000000..0136ce46 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2618.toml @@ -0,0 +1,15 @@ +id = 2618 +title = "INTEGER_OVERFLOW in sparc.c" +state = "opened" +created_at = "2024-10-14T08:34:34.670Z" +closed_at = "n/a" +labels = ["Bite Sized", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2618" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2620.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2620.toml new file mode 100644 index 00000000..1e91cada --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2620.toml @@ -0,0 +1,17 @@ +id = 2620 +title = "Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc" +state = "opened" +created_at = "2024-10-15T02:18:57.930Z" +closed_at = "n/a" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2620" +host-os = "- OS/kernel version:" +host-arch = "- QEMU flavor:" +qemu-version = "- QEMU command line:" +guest-os = "- OS/kernel version:" +guest-arch = "## Description of problem" +description = """""" +reproduce = """1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO. Works on real Sparcstation 5, 10, or 20 +2.Start OS install +3.""" +additional = """""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2674.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2674.toml new file mode 100644 index 00000000..313c071e --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2674.toml @@ -0,0 +1,32 @@ +id = 2674 +title = "NextSTEP 3.3 for Sparc graphical glitches" +state = "opened" +created_at = "2024-11-13T13:15:55.115Z" +closed_at = "n/a" +labels = ["device:graphics", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2674" +host-os = "Slackware 15.0" +host-arch = "x86" +qemu-version = "qemu-system-sparc --version" +guest-os = "NextSTEP 3.3 for RISC" +guest-arch = "SPARC" +description = """It installs/boot by using complex boot syntax and taskset -c 0 under Linux + +see end of https://gitlab.com/qemu-project/qemu/-/issues/2620#note_2207999780 + +But after it installs I see some gfx corruption""" +reproduce = """1. install NEXTSTEP 3.3 for RISC computers +2. Boot to desktop (may need ctrl-c to skip some services at startup) +3. Select Info and watch for Workspace Manager info window to appear. +4. Move this window to the right - it corrupts!""" +additional = """Bug also exist if I boot qemu with -g 1024x768x24 + +Moving window vertically (up/down) does not corrupt it +Moving any window around corrupt it. + +Resizing and scrolling inside say Terminal emulators work. + +There was 86Box issue around one FPU instruction that looked a bit like this, +is there way to check fpu emulation? + +""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2723.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2723.toml new file mode 100644 index 00000000..b620b025 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2723.toml @@ -0,0 +1,33 @@ +id = 2723 +title = "qemu-system-sparc: nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled" +state = "closed" +created_at = "2024-12-14T02:29:15.300Z" +closed_at = "2024-12-31T15:42:41.393Z" +labels = ["target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2723" +host-os = "Ubuntu 24.04.1 LTS" +host-arch = "x86_64" +qemu-version = "9.2.0" +guest-os = "Solaris 1.1.2 (SunOS 4.1.4)" +guest-arch = "Sparc" +description = """It boots into the BIOS. I connect to the monitor on port 4444, and send "sendkey stop-a", and then in the main window (VNC session) I enter "boot disk1:d". It starts to load vmunix, and then crashes with:- + ``` +nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f00053dc npc: f00053e0 +%g0-7: 00000000 f00ee048 00000000 ffef0000 ffef9b6c f00e1000 00000000 ffefebc4 +%o0-7: 00008000 00008000 000000e0 feff8008 00001ff0 00000068 f00d7490 f0005c98 +%l0-7: 04800fc1 f0005d14 f0005d18 00000002 0000010f 00000002 00000007 f00d6f50 +%i0-7: 00008000 00008000 00000005 feff8008 00000000 00000000 f00d6ff8 f0005c98 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00080000 y: 00000000 + +Aborted (core dumped) + ```""" +reproduce = "n/a" +additional = """md5sums (both files can be found online) +ede0690b3cb3d2abb6bddd8136912106 Solaris1_1_2.iso +6364e9a6f5368e2ecc4e9c1d915a93ae ss5.bin""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/2736.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/2736.toml new file mode 100644 index 00000000..67b8b52b --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/2736.toml @@ -0,0 +1,18 @@ +id = 2736 +title = "assert_fail in vmstate_load_state (icount related)" +state = "opened" +created_at = "2024-12-20T16:09:56.292Z" +closed_at = "n/a" +labels = ["Migration", "icount", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2736" +host-os = "Ubuntu 24.04.1 LTS" +host-arch = "x86_64" +qemu-version = "v9.2.0-206-g83aaec1d5a-dirty" +guest-os = "SunOS 4.1.4" +guest-arch = "sun4m" +description = """qemu crashes with an assert failure.""" +reproduce = """- Run qemu-system-sparc with "-i count auto -rtc clock=vm" + - Create a snapshot. Exit qemu. + - Run qemu-system-sparc without "-i count auto -rtc clock-vm" + - Try to load the snapshot via the monitor""" +additional = """[gdb.out](/uploads/d08539ce9eb6b599918513e279f13453/gdb.out)""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/293.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/293.toml new file mode 100644 index 00000000..a9426389 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/293.toml @@ -0,0 +1,15 @@ +id = 293 +title = "Qemu SPARC64 Panics on Sun Solaris 5.8 - BOP_ALLOC failed" +state = "opened" +created_at = "2021-05-14T10:06:20.336Z" +closed_at = "n/a" +labels = ["Launchpad", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/293" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/421.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/421.toml new file mode 100644 index 00000000..fa7efac9 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/421.toml @@ -0,0 +1,15 @@ +id = 421 +title = "Please clarify what network card is available with qemu-system-sparc64" +state = "opened" +created_at = "2021-06-16T09:21:39.042Z" +closed_at = "n/a" +labels = ["Documentation", "Networking", "kind::Bug", "target: sparc", "workflow::Confirmed"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/421" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/499.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/499.toml new file mode 100644 index 00000000..51ff8fc1 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/499.toml @@ -0,0 +1,15 @@ +id = 499 +title = "booting a linux guest with qemu-system-sparc with icount enabled hangs" +state = "closed" +created_at = "2021-07-24T13:47:57.048Z" +closed_at = "2021-07-27T09:55:20.799Z" +labels = ["Closed::Fixed", "kind::Bug", "target: sparc"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/499" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/597.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/597.toml new file mode 100644 index 00000000..75300393 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/597.toml @@ -0,0 +1,27 @@ +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...""" diff --git a/gitlab/issues/target_sparc/host_missing/accel_missing/958.toml b/gitlab/issues/target_sparc/host_missing/accel_missing/958.toml new file mode 100644 index 00000000..94813348 --- /dev/null +++ b/gitlab/issues/target_sparc/host_missing/accel_missing/958.toml @@ -0,0 +1,23 @@ +id = 958 +title = "qemu-system-sparc crashes on floppy access" +state = "closed" +created_at = "2022-04-03T09:41:26.039Z" +closed_at = "2022-06-12T03:48:44.781Z" +labels = ["target: sparc", "workflow::In Progress"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/958" +host-os = "Debian 11" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 6.2.91 (v7.0.0-rc1-36-g27fc9f365d)" +guest-os = "NetBSD" +guest-arch = "sparc" +description = """qemu-system-sparc crashes when accessing the emulated floppy drive of the guest system.""" +reproduce = """1. wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/sparc/installation/bootfs/boot.fs.gz +2. gunzip boot.fs.gz +3. qemu-system-sparc -nographic boot.fs +4. Select option "3) floppy" +5. qemu-systems-sparc crashes with the messages: +``` + Ejecting floppy disk + Segmentation fault (core dumped) +```""" +additional = "n/a" |