diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-05-30 16:52:07 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-05-30 16:52:17 +0200 |
| commit | 9260319e7411ff8281700a532caa436f40120ec4 (patch) | |
| tree | 2f6bfe5f3458dd49d328d3a9eb508595450adec0 /gitlab/issues_text/target_sparc | |
| parent | 225caa38269323af1bfc2daadff5ec8bd930747f (diff) | |
| download | qemu-analysis-9260319e7411ff8281700a532caa436f40120ec4.tar.gz qemu-analysis-9260319e7411ff8281700a532caa436f40120ec4.zip | |
gitlab scraper: download in toml and text format
Diffstat (limited to 'gitlab/issues_text/target_sparc')
45 files changed, 1869 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 new file mode 100644 index 000000000..971b0ce1c --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 @@ -0,0 +1,33 @@ +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 new file mode 100644 index 000000000..9e7869cf2 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 @@ -0,0 +1,107 @@ +sparc: SIGILL stepping over `std` in gdb +Description of problem: +Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not. + +My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix. + +This problem was experienced while testing some shell-spawning assembly: +``` +-bash-4.3$ cat test.s +.section ".text" +.global main +main: + sethi %hi(0x2f626800), %l6 + or %l6, 0x16e, %l6 ! 0x2f62696e + sethi %hi(0x2f6b7000), %l7 + or %l7, 0x368, %l7 ! 0x2f6b7368 + and %sp, %sp, %o0 + add %sp, 0xc, %o1 + xor %o2, %o2, %o2 + add %sp, 0x14, %sp + std %l6, [ %sp + -20 ] + clr [ %sp + -12 ] + st %sp, [ %sp + -8 ] + clr [ %sp + -4 ] + mov 0x3b, %g1 + ta 8 + xor %o7, %o7, %o0 + mov 1, %g1 + ta 8 +``` + +``` +-bash-4.3$ gcc test.s -o test +-bash-4.3$ ./test +$ echo HELLO +HELLO +$ exit +``` + +As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs +``` +-bash-4.3$ gdb test +GNU gdb (GDB) 7.4.1 +[...] +(gdb) disas main +Dump of assembler code for function main: + 0x0001061c <+0>: sethi %hi(0x2f626800), %l6 + 0x00010620 <+4>: or %l6, 0x16e, %l6 ! 0x2f62696e + 0x00010624 <+8>: sethi %hi(0x2f6b7000), %l7 + 0x00010628 <+12>: or %l7, 0x368, %l7 ! 0x2f6b7368 + 0x0001062c <+16>: and %sp, %sp, %o0 + 0x00010630 <+20>: add %sp, 0xc, %o1 + 0x00010634 <+24>: xor %o2, %o2, %o2 + 0x00010638 <+28>: add %sp, 0x14, %sp + 0x0001063c <+32>: std %l6, [ %sp + -20 ] + 0x00010640 <+36>: clr [ %sp + -12 ] + 0x00010644 <+40>: st %sp, [ %sp + -8 ] + 0x00010648 <+44>: clr [ %sp + -4 ] + 0x0001064c <+48>: mov 0x3b, %g1 + 0x00010650 <+52>: ta 8 + 0x00010654 <+56>: xor %o7, %o7, %o0 + 0x00010658 <+60>: mov 1, %g1 + 0x0001065c <+64>: ta 8 +End of assembler dump. +(gdb) b main +Breakpoint 1 at 0x1061c +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) si +0x00010620 in main () +(gdb) +0x00010624 in main () +[...] +Program received signal SIGILL, Illegal instruction. +0x0001063c in main () +``` + +However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve, +but then complains about memory accesses that I've never seen before. +``` +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +0xef783af4 in _rt_boot () from /usr/lib/ld.so.1 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +$ +``` + +It does eventually get a shell though. + +On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb. diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 new file mode 100644 index 000000000..1e1d8be99 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 @@ -0,0 +1,60 @@ +qemu-system-sparc64 sometimes generates endless loops +Description of problem: +Sometimes emulation "stops" in a busy loop hogging 1 cpu completely. +gdb says: + +``` +0x00007d5805460ac5 in code_gen_buffer () +(gdb) info thread + Id Target Id Frame +* 1 LWP 9166 of process 12669 "" 0x00007d5805460ac5 in code_gen_buffer () + 2 LWP 19293 of process 12669 "" 0x00007d584680803a in ____sigtimedwait50 + () from /usr/lib/libc.so.12 + 3 LWP 20202 of process 12669 "" 0x00007d58468249ba in ___lwp_park60 () + from /usr/lib/libc.so.12 + 4 LWP 12669 of process 12669 "" 0x00007d58467b72ca in _sys___pollts50 () + from /usr/lib/libc.so.12 +(gdb) up +#1 0x00000000007b3a0f in cpu_tb_exec (cpu=cpu@entry=0x7d58041ac680, + itb=<optimized out>, tb_exit=tb_exit@entry=0x7d58037ffde8) + at ../accel/tcg/cpu-exec.c:458 +458 ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr); + +(gdb) down +#0 0x00007d5805460ac5 in code_gen_buffer () +(gdb) x/16i $pc +=> 0x7d5805460ac5 <code_gen_buffer+19401368>: mov %r15,0x68(%rbp) + 0x7d5805460ac9 <code_gen_buffer+19401372>: xor %r12,%r14 + 0x7d5805460acc <code_gen_buffer+19401375>: mov %r14,0x80(%rbp) + 0x7d5805460ad3 <code_gen_buffer+19401382>: mov %r12,%rbx + 0x7d5805460ad6 <code_gen_buffer+19401385>: mov %rbx,0x70(%rbp) + 0x7d5805460ada <code_gen_buffer+19401389>: mov %r12,0x78(%rbp) + 0x7d5805460ade <code_gen_buffer+19401393>: mov %r14,%r12 + 0x7d5805460ae1 <code_gen_buffer+19401396>: shr $0x20,%r12 + 0x7d5805460ae5 <code_gen_buffer+19401400>: and $0x1,%r12d + 0x7d5805460ae9 <code_gen_buffer+19401404>: dec %r12 + 0x7d5805460aec <code_gen_buffer+19401407>: and %rbx,%r12 + 0x7d5805460aef <code_gen_buffer+19401410>: mov %r12d,%ebx + 0x7d5805460af2 <code_gen_buffer+19401413>: movb $0x1,-0x4(%rbp) + 0x7d5805460af6 <code_gen_buffer+19401417>: cmp %r13,%rbx + 0x7d5805460af9 <code_gen_buffer+19401420>: + je 0x7d5805460b20 <code_gen_buffer+19401459> + 0x7d5805460aff <code_gen_buffer+19401426>: + jmp 0x7d5805460b04 <code_gen_buffer+19401431> +(gdb) list +453 if (qemu_loglevel_mask(CPU_LOG_TB_CPU | CPU_LOG_EXEC)) { +454 log_cpu_exec(log_pc(cpu, itb), cpu, itb); +455 } +456 +457 qemu_thread_jit_execute(); +458 ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr); +459 cpu->neg.can_do_io = true; +460 qemu_plugin_disable_mem_helpers(cpu); +461 /* +462 * TODO: Delay swapping back to the read-write region of the TB +``` +Steps to reproduce: +Unfortunately I have not been able to find a way to reliably reproduce this. +Happens "often" to me, but not always. + +If you have any idea (like: what traces to enable) how to debug this I'll try to gather more information diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 new file mode 100644 index 000000000..f6b025c39 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 @@ -0,0 +1,134 @@ +internal assertion failure in sparc64 codegen: translate.c:5695:sparc_tr_insn_start: code should not be reached +Description of problem: +qemu crashes with internal assertion: + +ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached +Steps to reproduce: +1. boot emulated NetBSD/sparc64 system +2. cd /usr/tests && atf-run|atf-report + +not 100% reproducable, but happens often +Additional information: +last output: +``` +IN: +0x4102ce80: sethi %hi(0x29e0000), %g1 +0x4102ce84: b,a 0x40d78220 + +---------------- +IN: +0x41029fc0: sethi %hi(0x1e30000), %g1 +0x41029fc4: b,a 0x40e9ccc0 + +---------------- +IN: +0x4102b5e0: sethi %hi(0x23b8000), %g1 +0x4102b5e4: b,a 0x40e9dc20 + +---------------- +IN: +0x4102a6e0: sethi %hi(0x1ff8000), %g1 +0x4102a6e4: b,a 0x40e9cbc0 + +---------------- +IN: +0x410230e0: sethi %hi(0x278000), %g1 +0x410230e4: b,a 0x40e25d60 + +---------------- +IN: +0x41026920: sethi %hi(0x1088000), %g1 +0x41026924: b,a 0x40d77da0 + +---------------- +IN: +0x41024140: sethi %hi(0x690000), %g1 +0x41024144: b,a 0x40e25f00 + +---------------- +IN: +0x00245c20: sethi %hi(0xc8000), %g1 +0x00245c24: sethi %hi(0x40d77c00), %g1 +0x00245c28: jmp %g1 + 0x1a0 ! 0x40d77da0 +0x00245c2c: nop + +---------------- +IN: +0x00245ba0: sethi %hi(0xa8000), %g1 +0x00245ba4: b,a %xcc, 0x245920 + +---------------- +IN: +0x00245ba0: sethi %hi(0xa8000), %g1 +0x00245ba4: sethi %hi(0x40d76c00), %g1 +0x00245ba8: jmp %g1 + 0x80 ! 0x40d76c80 +0x00245bac: nop + +---------------- +IN: +0x00245e60: sethi %hi(0x158000), %g1 +0x00245e64: b,a %xcc, 0x245920 + +---------------- +IN: +0x00245e60: sethi %hi(0x158000), %g1 +0x00245e64: sethi %hi(0x40d76400), %g1 +0x00245e68: jmp %g1 + 0x260 ! 0x40d76660 +0x00245e6c: nop + +---------------- +IN: +0x002465a0: sethi %hi(0x328000), %g1 +0x002465a4: sethi %hi(0x40d69000), %g1 +0x002465a8: jmp %g1 + 0x198 ! 0x40d69198 +0x002465ac: nop + +** +ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached +``` + +gdb says: +``` +#0 0x000079343d6ebbfa in _lwp_kill () from /usr/lib/libc.so.12 +#1 0x000079343d6f7034 in abort () + at /home/martin/current/src/lib/libc/stdlib/abort.c:74 +#2 0x000079343e06a03a in g_assertion_message[cold] () + from /usr/pkg/lib/libglib-2.0.so.0 +#3 0x000079343e03c719 in g_assertion_message_expr () + from /usr/pkg/lib/libglib-2.0.so.0 +#4 0x0000000000a23345 in sparc_tr_insn_start (dcbase=<optimized out>, + cs=<optimized out>) at ../target/sparc/translate.c:5695 +#5 0x0000000000aa932f in translator_loop (cpu=cpu@entry=0x7933fac3be40, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, + host_pc=host_pc@entry=0x7933f52a58f7, + ops=ops@entry=0xfac3c0 <sparc_tr_ops>, db=db@entry=0x7933fa5d3b80) + at ../accel/tcg/translator.c:152 +#6 0x0000000000a368ca in gen_intermediate_code (cs=cs@entry=0x7933fac3be40, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, + host_pc=host_pc@entry=0x7933f52a58f7) at ../target/sparc/translate.c:5816 +#7 0x0000000000aa7e90 in setjmp_gen_code (env=env@entry=0x7933fac3e5e0, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + pc=pc@entry=1206519, host_pc=0x7933f52a58f7, + max_insns=max_insns@entry=0x7933fa5d3d44, ti=<optimized out>) + at ../accel/tcg/translate-all.c:278 +#8 0x0000000000aa835d in tb_gen_code (cpu=cpu@entry=0x7933fac3be40, + pc=pc@entry=1206519, cs_base=cs_base@entry=1206523, flags=2181038080, + cflags=cflags@entry=-16777216) at ../accel/tcg/translate-all.c:358 +#9 0x0000000000aa135b in cpu_exec_loop (cpu=cpu@entry=0x7933fac3be40, + sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:993 +#10 0x0000000000aa1788 in cpu_exec_setjmp (cpu=cpu@entry=0x7933fac3be40, + sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:1039 +#11 0x0000000000aa1f8d in cpu_exec (cpu=cpu@entry=0x7933fac3be40) + at ../accel/tcg/cpu-exec.c:1065 +#12 0x0000000000abb53d in tcg_cpu_exec (cpu=cpu@entry=0x7933fac3be40) + at ../accel/tcg/tcg-accel-ops.c:78 +#13 0x0000000000abb6ae in mttcg_cpu_thread_fn (arg=arg@entry=0x7933fac3be40) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#14 0x0000000000c7f750 in qemu_thread_start (args=0x79343aef7520) + at ../util/qemu-thread-posix.c:541 +#15 0x000079343d98c145 in pthread__create_tramp (cookie=0x79343c583000) + at /home/martin/current/src/lib/libpthread/pthread.c:595 +#16 0x000079343d5d1310 in ?? () from /usr/lib/libc.so.12 +``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 new file mode 100644 index 000000000..c77e9a5f8 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 @@ -0,0 +1,26 @@ +Sparc: fdtox/fqtox instructions incorrectly select destination register +Description of problem: +This bug report is mostly for informational purposes as I will be posting a fix for the bug. + +The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. +Steps to reproduce: +1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) +2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` +3. Run the test program using `qemu-sparc64-static ./test_program` +4. Expected output is 60. Prints 0 instead. +Additional information: +Test program to test the issue: + +```c +#include <stdio.h> + +int main(int argc, char** argv) { + long long truncated = 0; + __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); + __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); + printf("%lld\n", truncated); + return 0; +} +``` + +The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 new file mode 100644 index 000000000..30fa29364 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 @@ -0,0 +1,27 @@ +on single core Raspberry Pi, qemu-system-sparc appears to hang in bios +Description of problem: +I suspect it to be a race condition related to running on the slow single core Raspberry Pi, as I haven't managed to reproduce on x86 even when using taskset to tie qemu to a single core. + +The problem occurs about 4 out of 5 runs on qemu 5.2 (raspbian bullseye) and so far 100% of the time on qemu 6.1. + +About five seconds after start the sparc bios gets as far as `ttya initialized` and then appears to hang indefinitely. + +Instead, it should continue after about 3 more seconds with: +``` +Probing Memory Bank #0 32 Megabytes +Probing Memory Bank #1 Nothing there +Probing Memory Bank #2 Nothing there +Probing Memory Bank #3 Nothing there +``` + +See below for workaround. +Steps to reproduce: +1. Need a single core Raspberry Pi running raspbian, such as Raspberry Pi 1 or Zero +2. Download ss5.bin from https://github.com/andarazoroflove/sparc/raw/master/ss5.bin +3. Run the command: +``` +qemu-system-sparc -m 32 -bios ss5.bin -nographic +``` +After about 5 seconds of output it hangs at `ttya initialized` +Additional information: +## diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 new file mode 100644 index 000000000..38a2e4c28 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 @@ -0,0 +1,30 @@ +rdhpr %htstate unimplemented in translator +Description of problem: +I accidentally mixed up a copy of T1 and T2 sun4v firmwares and was able to trigger the following TCG assert ``tcg_reg_alloc_mov: Assertion `ts->val_type == TEMP_VAL_REG' failed.`` upon boot. + +Having discovered my mistake I was expecting the guest to crash at some point but without triggering an +assert. +Steps to reproduce: +1. Download the attached file bug.tar.gz and extract it + +2. Apply the following diff to update the UART address for the T2 firmware + +``` +diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c +index ccad2c43a3..7af64bd50f 100644 +--- a/hw/sparc64/niagara.c ++++ b/hw/sparc64/niagara.c +@@ -51,7 +51,7 @@ typedef struct NiagaraBoardState { + + #define NIAGARA_PARTITION_RAM_BASE 0x80000000ULL + +-#define NIAGARA_UART_BASE 0x1f10000000ULL ++#define NIAGARA_UART_BASE 0xfff0c2c000ULL + + #define NIAGARA_NVRAM_BASE 0x1f11000000ULL + #define NIAGARA_NVRAM_SIZE 0x2000 +``` + +3. Run `./qemu-system-sparc64 -M niagara -L ./bug/ -m 256 -nographic` +Additional information: + diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1058 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1058 new file mode 100644 index 000000000..ee8d189e5 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1058 @@ -0,0 +1,8 @@ +NetBSD Sparc 8.2 OS doesn't seem to accept keyboard input (-nographic) +Description of problem: +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. +Steps to 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 diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1127 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1127 new file mode 100644 index 000000000..918d9737d --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1127 @@ -0,0 +1,129 @@ +Various problems with running SunOS 4.1.4 +Description of problem: +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. +Steps to 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 information: +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_text/target_sparc/host_missing/accel_missing/1132 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1132 new file mode 100644 index 000000000..9bea199fa --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1132 @@ -0,0 +1,115 @@ +[SPARC/Leon3] Application compiled by RCC 1.2 won't start +Description of problem: +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) +Steps to 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 information: +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_text/target_sparc/host_missing/accel_missing/1163 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1163 new file mode 100644 index 000000000..8a1640fbd --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1163 @@ -0,0 +1,11 @@ +qemu doesn't boot Solaris 2.2 +Description of problem: +Booting from the CDROM hangs +Steps to reproduce: +1. Run the command line above with a fresh disk image +2. The console contains: +``` +Trying cdrom:d... +(is ? +``` +3. No further progress diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1166 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1166 new file mode 100644 index 000000000..9e82affae --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1166 @@ -0,0 +1,25 @@ +Solaris 2.6 panic when debugging with gdb +Description of problem: +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 +... +``` +Steps to 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 +``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1394 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1394 new file mode 100644 index 000000000..d27361e1b --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1394 @@ -0,0 +1,61 @@ +Byte-swapping issue in getresuid on qemu-user-sparc64 +Description of problem: +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. +Steps to 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) { + struct passwd *pw = getpwuid(geteuid()); + if (pw == NULL) { + perror("getpwuid failure"); + return 1; + } + printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid); + + uid_t ruid = 0, euid = 0, suid = 0; + if (getresuid(&ruid, &euid, &suid) != 0) { + perror("getresuid failure"); + return 1; + } + printf("getresuid()->suid=0x%08x\n", suid); + + return 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 information: +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_text/target_sparc/host_missing/accel_missing/1564 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1564 new file mode 100644 index 000000000..b25f81c3b --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1564 @@ -0,0 +1,70 @@ +stat64 on sparc64 failed to get correct major/minor dev +Description of problem: +The reported device major/minor is not correct, e.g: stat /dev/zero: +Reported: Device type: 0,10500000 +Correct : Device type: 1,5 +Steps to reproduce: +1. "stat /dev/zero" or "ls -l /dev/zero" +Additional information: +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 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/linux-user/syscall_defs.h.new 2023-03-27 21:43:25.615115126 +0200 +@@ -1450,7 +1450,7 @@ struct target_stat { + unsigned int st_dev; + abi_ulong st_ino; + unsigned int st_mode; +- unsigned int st_nlink; ++ short int st_nlink; + unsigned int st_uid; + unsigned int st_gid; + unsigned int st_rdev; +@@ -1465,8 +1465,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +- unsigned char __pad0[6]; +- unsigned short st_dev; ++ uint64_t st_dev; + + uint64_t st_ino; + uint64_t st_nlink; +@@ -1476,14 +1475,13 @@ struct target_stat64 { + unsigned int st_uid; + unsigned int st_gid; + +- unsigned char __pad2[6]; +- unsigned short st_rdev; ++ unsigned int __pad0; ++ uint64_t st_rdev; + + int64_t st_size; + int64_t st_blksize; + +- unsigned char __pad4[4]; +- unsigned int st_blocks; ++ int64_t st_blocks; + + abi_ulong target_st_atime; + abi_ulong target_st_atime_nsec; +@@ -1522,8 +1520,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +- unsigned char __pad0[6]; +- unsigned short st_dev; ++ uint64_t st_dev; + + uint64_t st_ino; + +@@ -1533,8 +1530,7 @@ struct target_stat64 { + unsigned int st_uid; + unsigned int st_gid; + +- unsigned char __pad2[6]; +- unsigned short st_rdev; ++ uint64_t st_rdev; + + unsigned char __pad3[8]; +``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1609 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1609 new file mode 100644 index 000000000..612f56dce --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1609 @@ -0,0 +1,19 @@ +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Description of problem: +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Steps to 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 information: +[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_text/target_sparc/host_missing/accel_missing/1745 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1745 new file mode 100644 index 000000000..cdf769383 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1745 @@ -0,0 +1,67 @@ +qemu-system-sparc64 v8.0.2 failed to read the file system. +Steps to 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 information: +``` +$ 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_text/target_sparc/host_missing/accel_missing/1807 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1807 new file mode 100644 index 000000000..566a9a0b5 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1807 @@ -0,0 +1,24 @@ +sparc64 always segfaults doesn't work on Ubuntu 23.04 +Description of problem: +It segfaults when it tries to use 'printf' or 'puts' to print to the screen. +Steps to 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 +``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/1901 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1901 new file mode 100644 index 000000000..5fa434b55 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/1901 @@ -0,0 +1,19 @@ +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +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. +Steps to 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 information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2015 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2015 new file mode 100644 index 000000000..e1e85e0b9 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2015 @@ -0,0 +1,27 @@ +qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5 +Description of problem: +Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error. +Steps to 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 information: + diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2017 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2017 new file mode 100644 index 000000000..fe30b1edb --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2017 @@ -0,0 +1,17 @@ +Qemu 8.1-8.2 Sparc Now Timeout Boot Failing with Sun Bios +Description of problem: +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." +Steps to reproduce: +1. Use Qemu 8.1, 8.2, or current +2. Run above command line using original sun bios +3. See result below + + +Additional information: +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_text/target_sparc/host_missing/accel_missing/2059 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2059 new file mode 100644 index 000000000..76a6bf553 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2059 @@ -0,0 +1,23 @@ +Solaris 2.6.5 panic when trying to debug a binary with Sun Workshop V5n1, or V6n1 debugger +Description of problem: +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 +``` +Steps to 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 information: +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_text/target_sparc/host_missing/accel_missing/2141 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2141 new file mode 100644 index 000000000..b01a6796c --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2141 @@ -0,0 +1,24 @@ +Output of "-cpu help" for sparc does not clearly indicate the valid input for "-cpu" option. +Description of problem: +The output of the "-cpu help" does not indicate clearly what the input to a "-cpu" command can be. +Steps to reproduce: +1. ./qemu-system-sparc -cpu help +Additional information: +``` +% ./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_text/target_sparc/host_missing/accel_missing/2143 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2143 new file mode 100644 index 000000000..7ea2ab9be --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2143 @@ -0,0 +1,38 @@ +ladr_match can cause bus error due to unaligned fetch +Description of problem: +On a SPARC host system, which does not support unaligned fetches, QEMU sometimes takes a bus error in ladr_match. +Steps to reproduce: +1. (see QEMU command line above) +2. let the system boot +3. +Additional information: +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_text/target_sparc/host_missing/accel_missing/216 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/216 new file mode 100644 index 000000000..b9c649293 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/216 @@ -0,0 +1 @@ +qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate" diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2163 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2163 new file mode 100644 index 000000000..18c48d145 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2163 @@ -0,0 +1 @@ +Move architecture specific interruption code around SPARC CPUs from hw/sparc/ to target/sparc/ diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2281 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2281 new file mode 100644 index 000000000..14006e852 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2281 @@ -0,0 +1,7 @@ +[bugfix incl.] Solaris Debuggers Panic OS with "Nonparity Synchronous Error" +Description of problem: +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. + +# diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2319 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2319 new file mode 100644 index 000000000..0ed686382 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2319 @@ -0,0 +1,17 @@ +SPARC32-bit SDIV of negative divisor gives wrong result +Description of problem: +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); diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 new file mode 100644 index 000000000..f668e6619 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 @@ -0,0 +1,33 @@ +SPARC fp operation INVALID trap hangs on offending instruction. +Description of problem: +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);` + +`}` +Steps to 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 diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2518 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2518 new file mode 100644 index 000000000..ace94a5d1 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2518 @@ -0,0 +1,14 @@ +Incorrect vertical mouse leaps on qemu-system-sparc +Description of problem: +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. +Steps to 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 information: +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_text/target_sparc/host_missing/accel_missing/2534 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2534 new file mode 100644 index 000000000..34b6c9b2e --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2534 @@ -0,0 +1,10 @@ +Solaris cannot be power offed with system_powerdown on qemu-system-sparc +Description of problem: +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. +Steps to 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 information: + diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/255 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/255 new file mode 100644 index 000000000..ba1d551e9 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/255 @@ -0,0 +1 @@ +Build on sparc64 fails with "undefined reference to `fdt_check_full'" diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/260 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/260 new file mode 100644 index 000000000..76d3a20c7 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/260 @@ -0,0 +1 @@ +qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2618 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2618 new file mode 100644 index 000000000..ed596fe75 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2618 @@ -0,0 +1 @@ +INTEGER_OVERFLOW in sparc.c diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2620 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2620 new file mode 100644 index 000000000..e0abc4f2f --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2620 @@ -0,0 +1,9 @@ +Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc +Description of problem: + +Steps to 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 information: + diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2674 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2674 new file mode 100644 index 000000000..c120e8e16 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2674 @@ -0,0 +1,24 @@ +NextSTEP 3.3 for Sparc graphical glitches +Description of problem: +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 +Steps to 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 information: +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_text/target_sparc/host_missing/accel_missing/2723 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2723 new file mode 100644 index 000000000..cef92a2c1 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2723 @@ -0,0 +1,23 @@ +qemu-system-sparc: nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled +Description of problem: +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) + ``` +Additional information: +md5sums (both files can be found online) +ede0690b3cb3d2abb6bddd8136912106 Solaris1_1_2.iso +6364e9a6f5368e2ecc4e9c1d915a93ae ss5.bin diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2736 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2736 new file mode 100644 index 000000000..4aaf2a2ab --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2736 @@ -0,0 +1,10 @@ +assert_fail in vmstate_load_state (icount related) +Description of problem: +qemu crashes with an assert failure. +Steps to 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 information: +[gdb.out](/uploads/d08539ce9eb6b599918513e279f13453/gdb.out) diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/293 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/293 new file mode 100644 index 000000000..d938058e0 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/293 @@ -0,0 +1 @@ +Qemu SPARC64 Panics on Sun Solaris 5.8 - BOP_ALLOC failed diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/421 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/421 new file mode 100644 index 000000000..fb961ae86 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/421 @@ -0,0 +1 @@ +Please clarify what network card is available with qemu-system-sparc64 diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/499 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/499 new file mode 100644 index 000000000..a7454919c --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/499 @@ -0,0 +1 @@ +booting a linux guest with qemu-system-sparc with icount enabled hangs 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... diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/958 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/958 new file mode 100644 index 000000000..309b9d7c0 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/958 @@ -0,0 +1,13 @@ +qemu-system-sparc crashes on floppy access +Description of problem: +qemu-system-sparc crashes when accessing the emulated floppy drive of the guest system. +Steps to 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) +``` diff --git a/gitlab/issues_text/target_sparc/host_x86/accel_TCG/1927 b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/1927 new file mode 100644 index 000000000..35bae5686 --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/1927 @@ -0,0 +1,524 @@ +SPARC64 pci-bridge kernel panic +Description of problem: +Kernel panics when a PCI bridge is added. +I wanted to install a number of PCI devices, but never got enough slots from the default PCI bus (pciB, pciA is not open at all). +So, I added a PCI bridge, but the kernel panics during boot: +``` +OpenBIOS for Sparc64 +Cannot manage 'PCI-to-PCI bridge' PCI device type 'pci': + 1b36 1 (6 4 0) +Cannot manage 'misc communication device' PCI device type '<NULL>': + 1af4 1003 (7 80 0) +Cannot manage 'undefined' PCI device type '<NULL>': + 1af4 1005 (0 ff 0) +Cannot manage 'undefined' PCI device type '<NULL>': + 1af4 1009 (0 2 0) +Cannot manage 'SCSI bus controller' PCI device type 'scsi': + 1af4 1004 (1 0 0) +Configuration device id QEMU version 1 machine id 0 +kernel phys 404000 virt 40004000 size 0x11f9290 +kernel cmdline root=/dev/sda rw log_buf_len=8M mitigations=off ktest.dir=/repos/janpieter/ktest ktest.env=/tmp/build-test-kernel-YOUlNpfwIz/env crashkernel=128M console=earlyprom0 loglevel=15 irqpoll kasan.fault=panic +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Mar 7 2023 22:22 + Type 'help' for detailed information +[sparc64] Kernel already loaded + +PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01' +PROMLIB: Root node compatible: sun4u +Linux version 6.5.0-ktest-02812-g4d2faeb4fb58 (janpieter@linuxserver) (sparc64-linux-gnu-gcc (Gentoo 11.3.0 p4) 11.3.0, GNU ld (Gentoo 2.41 p2) 2.41.0) #10 SMP Mon Oct 9 15:55:57 CEST 2023 +printk: bootconsole [earlyprom0] enabled +ARCH: SUN4U +Ethernet address: 52:54:00:12:34:57 +MM: PAGE_OFFSET is 0xfffff80000000000 (max_phys_bits == 40) +MM: VMALLOC [0x0000000100000000 --> 0x0000060000000000] +MM: VMEMMAP [0x0000060000000000 --> 0x00000c0000000000] +Kernel: Using 5 locked TLB entries for main kernel image. +Remapping the kernel... +done. +OF stdout device is: /pci@1fe,0/pci@1,1/ebus@1/su +PROM: Built device tree with 66340 bytes of memory. +Top of RAM: 0x7fe80000, Total RAM: 0x7fe80000 +Memory hole size: 0MB +Allocated 16384 bytes for kernel page tables. +Zone ranges: + Normal [mem 0x0000000000000000-0x000000007fe7ffff] +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000000000-0x000000007fe7ffff] +Initmem setup node 0 [mem 0x0000000000000000-0x000000007fe7ffff] +On node 0, zone Normal: 192 pages in unavailable ranges +Booting Linux... +CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus] +CPU CAPS: [vis] +percpu: Embedded 16 pages/cpu s93992 r8192 d28888 u4194304 +pcpu-alloc: s93992 r8192 d28888 u4194304 alloc=1*4194304 +pcpu-alloc: [0] 0 +Kernel command line: root=/dev/sda rw log_buf_len=8M mitigations=off ktest.dir=/repos/janpieter/ktest ktest.env=/tmp/build-test-kernel-YOUlNpfwIz/env crashkernel=128M console=earlyprom0 loglevel=15 irqpoll kasan.fault=panic +Misrouted IRQ fixup and polling support enabled +This may significantly impact system performance +Unknown kernel command line parameters "crashkernel=128M", will be passed to user space. +printk: log_buf_len: 8388608 bytes +printk: early log buf free: 128952(98%) +Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes, linear) +Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes, linear) +Sorting __ex_table... +Built 1 zonelists, mobility grouping on. Total pages: 259905 +mem auto-init: stack:off, heap alloc:off, heap free:off +Memory: 2020416K/2095616K available (6609K kernel code, 7566K rwdata, 1640K rodata, 560K init, 1980K bss, 75200K reserved, 0K cma-reserved) +SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +ftrace: allocating 21433 entries in 42 pages +ftrace: allocated 42 pages with 3 groups +trace event string verifier disabled +rcu: Hierarchical RCU implementation. +rcu: RCU event tracing is enabled. +rcu: RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=1. + Rude variant of Tasks RCU enabled. +rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 +NR_IRQS: 2048, nr_irqs: 2048, preallocated irqs: 1 +rcu: srcu_init: Setting srcu_struct sizes based on contention. +clocksource: tick: mask: 0xffffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns +clocksource: mult[a000000] shift[24] +clockevent: mult[1999999a] shift[32] +Console: colour dummy device 80x25 +Calibrating delay using timer specific routine.. 201.35 BogoMIPS (lpj=402700) +pid_max: default: 32768 minimum: 301 +Mount-cache hash table entries: 4096 (order: 2, 32768 bytes, linear) +Mountpoint-cache hash table entries: 4096 (order: 2, 32768 bytes, linear) +RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +rcu: Hierarchical SRCU implementation. +rcu: Max phase no-delay instances is 1000. +smp: Bringing up secondary CPUs ... +smp: Brought up 1 node, 1 CPU +devtmpfs: initialized +device: 'platform': device_add +bus: 'platform': registered +bus: 'cpu': registered +device: 'cpu': device_add +bus: 'container': registered +device: 'container': device_add +Performance events: No support for PMU type 'ultra12' +bus: 'workqueue': registered +device: 'workqueue': device_add +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +futex hash table entries: 256 (order: 1, 16384 bytes, linear) +bus: 'virtio': registered +NET: Registered PF_NETLINK/PF_ROUTE protocol family +device: 'root': device_add +bus: 'platform': add device root +device: 'ffe1c220': device_add +bus: 'platform': add device ffe1c220 +device: 'ffe1c348': device_add +bus: 'platform': add device ffe1c348 +device: 'ffe26eb0': device_add +bus: 'platform': add device ffe26eb0 +device: 'ffe1c600': device_add +bus: 'platform': add device ffe1c600 +device: 'ffe1c6e0': device_add +bus: 'platform': add device ffe1c6e0 +device: 'ffe1c820': device_add +bus: 'platform': add device ffe1c820 +device: 'ffe1c948': device_add +bus: 'platform': add device ffe1c948 +device: 'ffe26978': device_add +bus: 'platform': add device ffe26978 +device: 'ffe289d0': device_add +bus: 'platform': add device ffe289d0 +device: 'ffe28c20': device_add +bus: 'platform': add device ffe28c20 +device: 'ffe2d168': device_add +bus: 'platform': add device ffe2d168 +device: 'ffe2d780': device_add +bus: 'platform': add device ffe2d780 +device: 'ffe2dd10': device_add +bus: 'platform': add device ffe2dd10 +device: 'ffe2e2a8': device_add +bus: 'platform': add device ffe2e2a8 +device: 'ffe2ba78': device_add +bus: 'platform': add device ffe2ba78 +device: 'ffe2bbd8': device_add +bus: 'platform': add device ffe2bbd8 +device: 'ffe2e478': device_add +bus: 'platform': add device ffe2e478 +device: 'ffe2ef68': device_add +bus: 'platform': add device ffe2ef68 +device: 'ffe2f8d0': device_add +bus: 'platform': add device ffe2f8d0 +device: 'ffe302d0': device_add +bus: 'platform': add device ffe302d0 +device: 'ffe30448': device_add +bus: 'platform': add device ffe30448 +device: 'ffe305f0': device_add +bus: 'platform': add device ffe305f0 +device: 'ffe30b40': device_add +bus: 'platform': add device ffe30b40 +device: 'ffe30ea8': device_add +bus: 'platform': add device ffe30ea8 +device: 'ffe310e8': device_add +bus: 'platform': add device ffe310e8 +device: 'ffe31470': device_add +bus: 'platform': add device ffe31470 +device: 'ffe31990': device_add +bus: 'platform': add device ffe31990 +device: 'ffe31e50': device_add +bus: 'platform': add device ffe31e50 +device: 'ffe323e8': device_add +bus: 'platform': add device ffe323e8 +device: 'ffe32c80': device_add +bus: 'platform': add device ffe32c80 +device: 'ffe332b8': device_add +bus: 'platform': add device ffe332b8 +device: 'ffe33a68': device_add +bus: 'platform': add device ffe33a68 +device: 'ffe33f58': device_add +bus: 'platform': add device ffe33f58 +device: 'ffe34448': device_add +bus: 'platform': add device ffe34448 +device: 'ffe34940': device_add +bus: 'platform': add device ffe34940 +device: 'ffe34f58': device_add +bus: 'platform': add device ffe34f58 +device class 'bdi': registering +device class 'pci_bus': registering +bus: 'pci': registered +bus: 'pci_express': registered +device class 'tty': registering +device class 'vtconsole': registering +device: 'vtcon0': device_add +bus: 'serial': registered +device class 'iommu': registering +device class 'devlink': registering +device class 'dma': registering +bus: 'serial-base': registered +bus: 'serial-base': add driver ctrl +bus: 'serial-base': add driver port +device: 'cpu0': device_add +bus: 'cpu': add device cpu0 +bus: 'platform': add driver psycho +bus: 'platform': add driver sabre +bus: 'platform': __driver_probe_device: matched device ffe2e478 with driver sabre +bus: 'platform': really_probe: probing driver sabre with device ffe2e478 +pci@1f,0: PCI IO [io 0x1fe02000000-0x1fe02ffffff] offset 1fe02000000 +pci@1f,0: PCI MEM [mem 0x1ff00000000-0x1ffefffffff] offset 1ff00000000 +pci@1f,0: SABRE PCI Bus Module ver[0:0] +PCI: Scanning PBM /pci@1f,0 +device: 'pci0000:00': device_add +device: '0000:00': device_add +sabre ffe2e478: PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [io 0x1fe02000000-0x1fe02ffffff] (bus address [0x0000-0xffffff]) +pci_bus 0000:00: root bus resource [mem 0x1ff00000000-0x1ffefffffff] (bus address [0x00000000-0xefffffff]) +pci_bus 0000:00: root bus resource [bus 00-03] +pci 0000:00:01.1: [108e:5000] type 01 class 0x060400 +device: '0000:00:01.1': device_add +bus: 'pci': add device 0000:00:01.1 +pci_bus 0000:01: extended config space not accessible +device: '0000:01': device_add +pci 0000:01:01.0: [108e:1000] type 00 class 0x068000 +pci 0000:01:01.0: reg 0x10: [mem 0x1ff20000000-0x1ff20ffffff] +pci 0000:01:01.0: reg 0x14: [io 0x1fe02000000-0x1fe02007fff] +device: '0000:01:01.0': device_add +bus: 'pci': add device 0000:01:01.0 +pci 0000:01:03.0: enabling bus mastering +pci 0000:01:03.0: [1095:0646] type 00 class 0x01018f +pci 0000:01:03.0: reg 0x10: [io 0x1fe02008000-0x1fe02008007] +pci 0000:01:03.0: reg 0x14: [io 0x1fe02008080-0x1fe02008083] +pci 0000:01:03.0: reg 0x18: [io 0x1fe02008100-0x1fe02008107] +pci 0000:01:03.0: reg 0x1c: [io 0x1fe02008180-0x1fe02008183] +pci 0000:01:03.0: reg 0x20: [io 0x1fe02008200-0x1fe0200820f] +device: '0000:01:03.0': device_add +bus: 'pci': add device 0000:01:03.0 +pci 0000:00:01.0: [108e:5000] type 01 class 0x060400 +device: '0000:00:01.0': device_add +bus: 'pci': add device 0000:00:01.0 +pci_bus 0000:02: extended config space not accessible +device: '0000:02': device_add +pci 0000:02:00.0: [1af4:1000] type 00 class 0x020000 +pci 0000:02:00.0: reg 0x10: [io 0x1fe02800000-0x1fe0280001f] +pci 0000:02:00.0: reg 0x20: [mem 0x1ff60000000-0x1ff60003fff 64bit pref] +device: '0000:02:00.0': device_add +bus: 'pci': add device 0000:02:00.0 +pci 0000:02:01.0: [1b36:0001] type 00 class 0x060400 +pci 0000:02:01.0: reg 0x10: [mem 0x1ff60080000-0x1ff600800ff 64bit] +device: '0000:02:01.0': device_add +bus: 'pci': add device 0000:02:01.0 +pci 0000:02:02.0: [1af4:1004] type 00 class 0x010000 +pci 0000:02:02.0: reg 0x10: [io 0x1fe02802000-0x1fe0280203f] +pci 0000:02:02.0: reg 0x20: [mem 0x1ff60200000-0x1ff60203fff 64bit pref] +device: '0000:02:02.0': device_add +bus: 'pci': add device 0000:02:02.0 +driver: 'sabre': driver_bound: bound to device 'ffe2e478' +bus: 'platform': really_probe: bound device ffe2e478 to driver sabre +bus: 'platform': add driver schizo +bus: 'platform': add driver pci_sun4v +bus: 'platform': add driver fire +device: 'writeback': device_add +bus: 'workqueue': add device writeback +device class 'block': registering +device class 'misc': registering +iommu: Default domain type: Passthrough +device class 'scsi_host': registering +bus: 'scsi': registered +device class 'scsi_device': registering +SCSI subsystem initialized +device class 'input': registering +device class 'rtc': registering +device class 'pps': registering +pps_core: LinuxPPS API ver. 1 registered +pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +device class 'ptp': registering +PTP clock support registered +device class 'net': registering +device: 'lo': device_add +bus: 'platform': add driver rtc +bus: 'platform': add driver mostek +bus: 'platform': __driver_probe_device: matched device ffe302d0 with driver mostek +bus: 'platform': really_probe: probing driver mostek with device ffe302d0 +/pci@1f,0/pci@1,1/ebus@1/eeprom@14,2000: Mostek regs at 0x1fe02002000 +Registering platform device 'rtc-m48t59.0'. Parent at platform +device: 'rtc-m48t59.0': device_add +bus: 'platform': add device rtc-m48t59.0 +driver: 'mostek': driver_bound: bound to device 'ffe302d0' +bus: 'platform': really_probe: bound device ffe302d0 to driver mostek +bus: 'platform': add driver bq4802 +bus: 'platform': add driver fhc +bus: 'platform': add driver clock_board +bus: 'platform': add driver auxio +clocksource: Switched to clocksource tick +device class 'mem': registering +device: 'null': device_add +device: 'zero': device_add +device: 'full': device_add +device: 'random': device_add +device: 'urandom': device_add +device: 'kmsg': device_add +device: 'tty': device_add +device: 'console': device_add +device: 'tty0': device_add +device class 'vc': registering +device: 'vcs': device_add +device: 'vcsu': device_add +device: 'vcsa': device_add +device: 'vcs1': device_add +device: 'vcsu1': device_add +device: 'vcsa1': device_add +device: 'tty1': device_add +device: 'tty2': device_add +device: 'tty3': device_add +device: 'tty4': device_add +device: 'tty5': device_add +device: 'tty6': device_add +device: 'tty7': device_add +device: 'tty8': device_add +device: 'tty9': device_add +device: 'tty10': device_add +device: 'tty11': device_add +device: 'tty12': device_add +device: 'tty13': device_add +device: 'tty14': device_add +device: 'tty15': device_add +device: 'tty16': device_add +device: 'tty17': device_add +device: 'tty18': device_add +device: 'tty19': device_add +device: 'tty20': device_add +device: 'tty21': device_add +device: 'tty22': device_add +device: 'tty23': device_add +device: 'tty24': device_add +device: 'tty25': device_add +device: 'tty26': device_add +device: 'tty27': device_add +device: 'tty28': device_add +device: 'tty29': device_add +device: 'tty30': device_add +device: 'tty31': device_add +device: 'tty32': device_add +device: 'tty33': device_add +device: 'tty34': device_add +device: 'tty35': device_add +device: 'tty36': device_add +device: 'tty37': device_add +device: 'tty38': device_add +device: 'tty39': device_add +device: 'tty40': device_add +device: 'tty41': device_add +device: 'tty42': device_add +device: 'tty43': device_add +device: 'tty44': device_add +device: 'tty45': device_add +device: 'tty46': device_add +device: 'tty47': device_add +device: 'tty48': device_add +device: 'tty49': device_add +device: 'tty50': device_add +device: 'tty51': device_add +device: 'tty52': device_add +device: 'tty53': device_add +device: 'tty54': device_add +device: 'tty55': device_add +device: 'tty56': device_add +device: 'tty57': device_add +device: 'tty58': device_add +device: 'tty59': device_add +device: 'tty60': device_add +device: 'tty61': device_add +device: 'tty62': device_add +device: 'tty63': device_add +device: 'hw_random': device_add +NET: Registered PF_INET protocol family +IP idents hash table entries: 32768 (order: 5, 262144 bytes, linear) +tcp_listen_portaddr_hash hash table entries: 1024 (order: 1, 16384 bytes, linear) +Table-perturb hash table entries: 65536 (order: 5, 262144 bytes, linear) +TCP established hash table entries: 16384 (order: 4, 131072 bytes, linear) +TCP bind hash table entries: 16384 (order: 6, 524288 bytes, linear) +TCP: Hash tables configured (established 16384 bind 16384) +UDP hash table entries: 1024 (order: 2, 32768 bytes, linear) +UDP-Lite hash table entries: 1024 (order: 2, 32768 bytes, linear) +NET: Registered PF_UNIX/PF_LOCAL protocol family +PCI: CLS 0 bytes, default 64 +bus: 'platform': add driver power +bus: 'platform': __driver_probe_device: matched device ffe30448 with driver power +bus: 'platform': really_probe: probing driver power with device ffe30448 +power: Control reg at 1fe02007240 +driver: 'power': driver_bound: bound to device 'ffe30448' +bus: 'platform': really_probe: bound device ffe30448 to driver power +device: 'mdesc': device_add +bus: 'clocksource': registered +device: 'clocksource': device_add +device: 'clocksource0': device_add +bus: 'clocksource': add device clocksource0 +bus: 'platform': add driver alarmtimer +bus: 'clockevents': registered +device: 'clockevents': device_add +device: 'clockevent0': device_add +bus: 'clockevents': add device clockevent0 +bus: 'event_source': registered +device: 'uprobe': device_add +bus: 'event_source': add device uprobe +device: 'kprobe': device_add +bus: 'event_source': add device kprobe +device: 'tracepoint': device_add +bus: 'event_source': add device tracepoint +device: 'software': device_add +bus: 'event_source': add device software +workingset: timestamp_bits=62 max_order=18 bucket_order=0 +9p: Installing v9fs 9p2000 file system support +device class 'bsg': registering +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) +bus: 'platform': add driver simple-pm-bus +bus: 'pci_express': add driver pciehp +pciehp: pcie_port_service_register = 0 +bus: 'pci': add driver pcieport +bus: 'pci': __driver_probe_device: matched device 0000:00:01.1 with driver pcieport +bus: 'pci': really_probe: probing driver pcieport with device 0000:00:01.1 +pcieport 0000:00:01.1: runtime IRQ mapping not provided by arch +pcieport: probe of 0000:00:01.1 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:00:01.0 with driver pcieport +bus: 'pci': really_probe: probing driver pcieport with device 0000:00:01.0 +pcieport 0000:00:01.0: runtime IRQ mapping not provided by arch +pcieport: probe of 0000:00:01.0 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:02:01.0 with driver pcieport +bus: 'pci': really_probe: probing driver pcieport with device 0000:02:01.0 +pcieport 0000:02:01.0: runtime IRQ mapping not provided by arch +pcieport: probe of 0000:02:01.0 rejects match -19 +bus: 'pci': add driver shpchp +bus: 'pci': __driver_probe_device: matched device 0000:00:01.1 with driver shpchp +bus: 'pci': really_probe: probing driver shpchp with device 0000:00:01.1 +shpchp 0000:00:01.1: runtime IRQ mapping not provided by arch +shpchp: probe of 0000:00:01.1 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:00:01.0 with driver shpchp +bus: 'pci': really_probe: probing driver shpchp with device 0000:00:01.0 +shpchp 0000:00:01.0: runtime IRQ mapping not provided by arch +shpchp: probe of 0000:00:01.0 rejects match -19 +bus: 'pci': __driver_probe_device: matched device 0000:02:01.0 with driver shpchp +bus: 'pci': really_probe: probing driver shpchp with device 0000:02:01.0 +shpchp 0000:02:01.0: runtime IRQ mapping not provided by arch +shpchp 0000:02:01.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 +shpchp 0000:02:01.0: Can't get msi for the hotplug controller +shpchp 0000:02:01.0: Use INTx for the hotplug controller +Unable to handle kernel NULL pointer dereference +tsk->{mm,active_mm}->context = 0000000000000000 +tsk->{mm,active_mm}->pgd = fffff80000402000 + \|/ ____ \|/ + "@'/ .. \`@" + /_| \__/ |_\ + \__U_/ +swapper/0(1): Oops [#1] +CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-ktest-02812-g4d2faeb4fb58 #10 +TSTATE: 0000004411001601 TPC: 00000000007e5f98 TNPC: 00000000007e5fbc Y: 00000000 Not tainted +TPC: <shpc_init+0x638/0x900> +g0: fffff8000228ca18 g1: 0000000000000000 g2: 0000000000001f00 g3: 0000000000000000 +g4: fffff80002148000 g5: fffff8007e410000 g6: fffff800021a4000 g7: 0000000000000001 +o0: 0000000000000000 o1: 00000000007e4da0 o2: 0000000000000000 o3: 0000000000000000 +o4: 0000000000b9b950 o5: 0000000000000000 sp: fffff800021a6b01 ret_pc: 00000000007e607c +RPC: <shpc_init+0x71c/0x900> +l0: 00000000015ef800 l1: 00000000ff1f7fff l2: 0000000000b78440 l3: 0000000000b9c6b0 +l4: 000000000000001f l5: 000000007f000000 l6: fffff80002553280 l7: fffff800022f7680 +i0: fffff8000254ea00 i1: fffff800021f6000 i2: 00000000015ef800 i3: 0000000000000000 +i4: 0000000000b9b800 i5: 0000000000000000 i6: fffff800021a6bc1 i7: 00000000007e29f0 +I7: <shpc_probe+0x70/0x3a0> +Call Trace: +[<00000000007e29f0>] shpc_probe+0x70/0x3a0 +[<00000000007c5bf8>] pci_device_probe+0x78/0x100 +[<0000000000a6b70c>] really_probe+0x16c/0x41c +[<0000000000a6ba68>] __driver_probe_device.part.0+0xac/0xc0 +[<0000000000846b28>] driver_probe_device+0x88/0x120 +[<0000000000846d64>] __driver_attach+0x84/0x1c0 +[<0000000000844bb4>] bus_for_each_dev+0x54/0xc0 +[<000000000084659c>] driver_attach+0x1c/0x40 +[<0000000000845e24>] bus_add_driver+0xe4/0x1e0 +[<0000000000847cfc>] driver_register+0x7c/0x140 +[<00000000007c5028>] __pci_register_driver+0x48/0x60 +[<0000000001398e64>] shpcd_init+0x18/0x68 +[<0000000000427c90>] do_one_initcall+0x30/0x240 +[<000000000137eea4>] kernel_init_freeable+0x1d4/0x22c +[<0000000000a6d824>] kernel_init+0x1c/0x138 +[<00000000004060c8>] ret_from_fork+0x1c/0x2c +Disabling lock debugging due to kernel taint +Caller[00000000007e29f0]: shpc_probe+0x70/0x3a0 +Caller[00000000007c5bf8]: pci_device_probe+0x78/0x100 +Caller[0000000000a6b70c]: really_probe+0x16c/0x41c +Caller[0000000000a6ba68]: __driver_probe_device.part.0+0xac/0xc0 +Caller[0000000000846b28]: driver_probe_device+0x88/0x120 +Caller[0000000000846d64]: __driver_attach+0x84/0x1c0 +Caller[0000000000844bb4]: bus_for_each_dev+0x54/0xc0 +Caller[000000000084659c]: driver_attach+0x1c/0x40 +Caller[0000000000845e24]: bus_add_driver+0xe4/0x1e0 +Caller[0000000000847cfc]: driver_register+0x7c/0x140 +Caller[00000000007c5028]: __pci_register_driver+0x48/0x60 +Caller[0000000001398e64]: shpcd_init+0x18/0x68 +Caller[0000000000427c90]: do_one_initcall+0x30/0x240 +Caller[000000000137eea4]: kernel_init_freeable+0x1d4/0x22c +Caller[0000000000a6d824]: kernel_init+0x1c/0x138 +Caller[00000000004060c8]: ret_from_fork+0x1c/0x2c +Caller[0000000000000000]: 0x0 +Instruction DUMP: + c20c2219 + 80a06000 + 0240000a +<d628e0da> + d25e2048 + 15002e71 + 11002de1 + 960ae0ff + 9412a3a0 + +Kernel panic - not syncing: Fatal exception +Press Stop-A (L1-A) from sun keyboard or send break +twice on console to return to the boot prom +---[ end Kernel panic - not syncing: Fatal exception ]--- +qemu-system-sparc64: terminating on signal 2 + +``` +Steps to reproduce: +1. compile a sparc64 kernel (config file included) +2. add a config where a pci-bridge is installed in slot 1,2 or 3 (virtio-slot-pci takes the first slot) +3. create a empty file using fallocate +Additional information: +attached: tar.xz file: +- linux arch/sparc64/boot/image (uncompressed) as vmlinuz +- linux .config file as config +- linux modules in the lib directory + +[sparckernelinfo.tar.xz](/uploads/55f1475c5c811cd56d1374386e8f9e6e/sparckernelinfo.tar.xz) diff --git a/gitlab/issues_text/target_sparc/host_x86/accel_TCG/2133 b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/2133 new file mode 100644 index 000000000..f0733823e --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_x86/accel_TCG/2133 @@ -0,0 +1,55 @@ +Debian sparc64 works on hardware, segfaults in qemu +Description of problem: + +Steps to reproduce: +1. Start the installer normally (boot cdrom), use guided all disk partition, change ext4 to btrfs for / +2. Installer always segfaults at the same place while installing base system step: + +``` +Jan 28 09:17:48 debootstrap: Setting up mawk (1.3.4.20200120-3.1) ... +Jan 28 09:17:49 debootstrap: update-alternatives: +Jan 28 09:17:49 debootstrap: using /usr/bin/mawk to provide /usr/bin/awk (awk) i +n auto mode +Jan 28 09:17:49 debootstrap: +Jan 28 09:17:54 debootstrap: Selecting previously unselected package debconf. +Jan 28 09:17:54 debootstrap: (Reading database ... 1459 files and directories cu +rrently installed.) +Jan 28 09:17:54 debootstrap: Preparing to unpack .../debconf_1.5.82_all.deb ... +Jan 28 09:17:54 debootstrap: Unpacking debconf (1.5.82) ... +Jan 28 09:17:55 kernel: [ 2994.426867] dpkg-deb[12709]: segfault at ffffffffffff +ffff ip fffff80100a1c3ec (rpc 0000000000000030) sp fffff80102402041 error 1 in l +iblzma.so.5.4.1[fffff80100a00000+2a000] +Jan 28 09:17:55 debootstrap: dpkg-deb: error: <decompress> subprocess was killed + by signal (Segmentation fault) +Jan 28 09:17:56 debootstrap: dpkg: error processing archive /var/cache/apt/archi +ves/debconf_1.5.82_all.deb (--install): +Jan 28 09:17:56 debootstrap: dpkg-deb --fsys-tarfile subprocess returned error +exit status 2 +Jan 28 09:17:57 debootstrap: Errors were encountered while processing: +Jan 28 09:17:57 debootstrap: /var/cache/apt/archives/debconf_1.5.82_all.deb +Jan 28 09:18:10 base-installer: error: exiting on error base-installer/debootstr + + +cd /target/var/cache/apt/archives +# ar x debconf_1.5.82_all.deb +/target/var/cache/apt/archives # unxz data.tar.xz +/target/var/cache/apt/archives # unxz control.tar.xz +``` +another try, to ext2 fs: +``` +Jan 28 10:31:16 debootstrap: Preparing to unpack .../dpkg_1.21.21_sparc64.deb .. +. +Jan 28 10:31:16 debootstrap: Unpacking dpkg (1.21.21) over (1.21.21) ... +Jan 28 10:31:23 kernel: [ 7402.528016] dpkg-deb[20720]: segfault at 7240015 ip f +ffff8010091def4 (rpc 000000006e17c498) sp fffff80103124041 error 1 in liblzma.so +.5.4.1[fffff80100900000+2a000] +Jan 28 10:31:23 debootstrap: dpkg-deb: error: <decompress> subprocess was killed + by signal (Segmentation fault) +Jan 28 10:31:24 debootstrap: dpkg: error processing archive /var/cache/apt/archi +ves/dpkg_1.21.21_sparc64.deb (--install): +Jan 28 10:31:24 debootstrap: cannot copy extracted data for './usr/share/doc/dp +kg/changelog.gz' to '/usr/share/doc/dpkg/changelog.gz.dpkg-new': unexpected end +of file or stream +``` +Additional information: +All times i've tried under Ubuntu qemu or latest build for Windows it segfaults unpacking package, and i believe it's a misleading error message, since very same ISO installs normally on Sun Fire T1000 machine (sun4v). I've tried also booting FreeBSD-12.4-RELEASE-sparc64-disc1.iso which dies shortly after booting the kernel, but i am more interested in Debian, since it was verified to work on a real hardware. BTW i was able to unpack specified file with "ar x" within installer. diff --git a/gitlab/issues_text/target_sparc/host_x86/accel_missing/1942 b/gitlab/issues_text/target_sparc/host_x86/accel_missing/1942 new file mode 100644 index 000000000..d6979724a --- /dev/null +++ b/gitlab/issues_text/target_sparc/host_x86/accel_missing/1942 @@ -0,0 +1,9 @@ +GCC segfault (ICE) while building in qemu-user sparc64 +Steps to reproduce: +1. Follow Qemu-user [documentation](https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot) for Sparc64 +2. Attempt to build libpaper: `emerge -v app-text/libpaper-2.1.0:0/2` + +Resulting compilation will fail with an internal compilation error. +Additional information: +This can be tested by trying to [compile](/uploads/ba4585ea75fa157a34bf8f3ffb64bded/H1NM.i) with `gcc -mcpu=ultrasparc -O2 -c` instead of building the entire libpaper package. +Here is the [output.](/uploads/30a154eb602caa5a8b1bd82a6271d6d8/output.txt) |