diff options
Diffstat (limited to 'gitlab/issues_text/target_mips/host_missing')
37 files changed, 683 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/1126 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/1126 new file mode 100644 index 000000000..5aaac6908 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/1126 @@ -0,0 +1,8 @@ +qemu-system-mipsel freezes for nanoMIPS in the semihosting mode +Description of problem: +In the current git master branch (SHA: 7b17a1a8) there is a problem with qemu-system-mipsel when trying to execute a simple hello.elf program in the semihosting mode for the nanoMIPS architecture. I.e. after executing the following command the terminal freezes: + ``` + $ ./qemu-system-mipsel -cpu I7200 -semihosting -nographic -kernel hello.elf + ``` +hello.elf file is generated using the nanoMIPS GNU Toolchain (https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases). +The program regularly terminates with QEMU emulator version 6.0.1. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/2193 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2193 new file mode 100644 index 000000000..9ba7d2b3d --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2193 @@ -0,0 +1,30 @@ +qemu-system-mips64el 70 times slower than qemu -ppc64, -riscv64, -s390x +Description of problem: +I installed Debian 12 inside a `qemu-system-mips64el` virtual machine. The performances are awfully slow, roughly 70 times slower than other qemu targets on the same host, namely ppc64, riscv64, s390x. + +The idea is to recompile and test an open source project on various platforms. + +Using a command such as `time make path/to/bin/file.o`, I compiled one single source file on the host and within qemu for various targets. The same source file, inside the same project, is used in all cases. + +The results are shown below (the "x" number between parentheses is the time factor compared to the compilation on the host). + +- Host (native): 0m1.316s +- qemu-system-ppc64: 0m31.622s (x24) +- qemu-system-riscv64: 0m40.691s (x31) +- qemu-system-s390x: 0m43.459s (x33) +- qemu-system-mips64el: 48m33.587s (x2214) + +The compilation of the same source is 24 to 33 times slower on the first three emulated targets, compared to the same compilation on the host, which is understandable. However, the same compilation on the mips64el target is 2214 time slower than the host, roughly 70 times slower than other emulated targets. + +Why do we have such a tremendous difference between qemu mips64el and other targets? +Additional information: +For reference, here are the other qemu to boot the other targets. Guest OS are Debian 12 or Ubuntu 22. +``` +qemu-system-ppc64 -smp 8 -m 8192 -nographic ... +qemu-system-riscv64 -machine virt -smp 8 -m 8192 -nographic ... +qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic ... +``` + +The other targets use `-smp 8` while qemu-system-mips64el does not support smp. However, the test compiles one single source file and does not (or marginally) use more than one CPU. + +Arguably, each compilation addresses a different target, uses a different backend, and the compilation time is not necessarily identical. OK, but 70 times slower seems way too much for this. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/244 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/244 new file mode 100644 index 000000000..943aea126 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/244 @@ -0,0 +1 @@ +MIPS MT dvpe does not regard VPEConf0.MVP diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/2470 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2470 new file mode 100644 index 000000000..7b640d03b --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/2470 @@ -0,0 +1,31 @@ +qemu-system-mipsel regression, Linux generated with Buildroot does not boot anymore +Description of problem: +Buildroot Toolchain Builders try to release a new version. See a message from Thomas Petazzoni with the remaining issues: +https://lore.kernel.org/buildroot/20240730223542.273693e5@windsurf/T/#u + +All toolchains generate a system that fails to boot: + +Run /sbin/init as init process +process '/bin/busybox' started with executable stack +Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 + +The interesting thing is that those images boot fine with Qemu v8.2.6, +but they fail to boot with Qemu v9.0.2. + +I tracked it down to this commit: +commit 4e999bf4197ae3dc58b7092260f98146920a7469 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Sun Jan 28 15:58:52 2024 +1000 + + target/mips: Pass ptw_mmu_idx down from mips_cpu_tlb_fill + + Rather than adjust env->hflags so that the value computed + by cpu_mmu_index() changes, compute the mmu_idx that we + want directly and pass it down. + + Introduce symbolic constants for MMU_{KERNEL,ERL}_IDX. + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + +Unfortunately just reverting this commit in 9.0.2 does not help, Qemu segfaults on Linux Kernel boot then. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/422 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/422 new file mode 100644 index 000000000..594067236 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/422 @@ -0,0 +1 @@ +Unable to execute MIPS MSA code due to illegal instruction diff --git a/gitlab/issues_text/target_mips/host_missing/accel_TCG/94 b/gitlab/issues_text/target_mips/host_missing/accel_TCG/94 new file mode 100644 index 000000000..96c08c489 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_TCG/94 @@ -0,0 +1 @@ +MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/115 b/gitlab/issues_text/target_mips/host_missing/accel_missing/115 new file mode 100644 index 000000000..b91769771 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/115 @@ -0,0 +1 @@ +shmat fails on 32-to-64 setup diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1238 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1238 new file mode 100644 index 000000000..ca4b5702a --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1238 @@ -0,0 +1,119 @@ +qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related? +Description of problem: +- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is +> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument` +- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9 +- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box) +- The problem seems to be limited to n32 (both big and little endian) + +Here's a run with strace functionality enabled: + +``` +dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin' +3216 brk(NULL) = 0x40032000 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000 +3216 uname(0x3fffebb0) = 0 +3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0 +3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4c4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0 +3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000 +3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000 +3216 munmap(0x3f786000,40960) = 0 +3216 munmap(0x3f7b1000,20880) = 0 +3216 mprotect(0x3f797000,98304,PROT_NONE) = 0 +3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4b4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0 +3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000 +3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000 +3216 munmap(0x3f75f000,4096) = 0 +3216 munmap(0x3f781000,57600) = 0 +3216 mprotect(0x3f764000,110592,PROT_NONE) = 0 +3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4a4,512) = 512 +3216 pread64(3,1073734640,32,34504,1065377824,0) = 32 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0 +3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000 +3216 munmap(0x3f569000,28672) = 0 +3216 munmap(0x3f757000,33440) = 0 +3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0 +3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000 +3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000 +3216 close(3) = 0 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 set_thread_area(0x3f570580) = 0 +3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216 +3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented) +3216 Unknown syscall 6331 +3216 mprotect(0x3f74b000,16384,PROT_READ) = 0 +3216 mprotect(0x3f77f000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7af000,4096,PROT_READ) = 0 +3216 mprotect(0x4002e000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0 +3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0 +3216 munmap(0x3f7b7000,11294) = 0 +3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4 +3216 brk(NULL) = 0x40032000 +3216 brk(0x40053000) = 0x40053000 +3216 brk(0x40054000) = 0x40054000 +3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0 +3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000 +3216 close(3) = 0 +3216 geteuid() = 0 +3216 umask(0) = 18 +3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3 +3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 unlinkat(3,"troff",0) = 0 +3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4 +3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5 +3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported) +3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 lseek(4,0,SEEK_DATA) = 0 +3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument) +3216 lseek(4,0,SEEK_HOLE) = 716800 +3216 lseek(4,0,SEEK_SET) = 0 +3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000 +3216 read(4,0x3f348000,131072) = 131072 +3216 write(5,0x3f348000,122880) = 122880 +3216 read(4,0x3f348000,131072) = 131072 +3216 lseek(5,12288,SEEK_CUR) = 135168 +3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument) +3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6 +3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0 +3216 read(6,0x400333a0,4096) = 2998 +3216 read(6,0x400333a0,4096) = 0 +3216 close(6) = 0 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc888,18)/usr/bin/install: = 18 +3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc428,18): Invalid argument = 18 +3216 write(2,0x3fffc858,1) + = 1 +3216 close(5) = 0 +3216 close(4) = 0 +3216 munmap(0x3f347000,139264) = 0 +3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek) +3216 close(0) = 0 +3216 close(1) = 0 +3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # +``` + +More information and debugging on request. Any advice is appreciated. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1251 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1251 new file mode 100644 index 000000000..fbed7e7d2 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1251 @@ -0,0 +1,15 @@ +Octeon Instruction BBIT Bug +Steps to reproduce: +1. Compile 64bit binary for Octeon with Octeon instructions +`mips64-octeon-linux-gnu-gcc -o hello hello.c` +2. Run with `qemu-mips64` +`qemu-mips64 -cpu Octeon68XX hello` +3. Get the output below: +``` +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Additional information: +I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. + +[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1531 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1531 new file mode 100644 index 000000000..17aeb6b1c --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1531 @@ -0,0 +1,15 @@ +MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 +Description of problem: +Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. +Steps to reproduce: +1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) +2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) +3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 +4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts +Additional information: +The pre-built binary and its output file are attached as test.tar.gz +[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) + +Please note, that standalone cross-compiler for MIPS downloaded from the site +(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) +comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1624 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1624 new file mode 100644 index 000000000..8446e0cde --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1624 @@ -0,0 +1,23 @@ +8.0.0: Crash when emulating MIPS executable +Description of problem: +A change to QEMU introduced within the 6.0.0 development cycle causes MIPS executable to crash. +Similar problem occurred within the same time-frame for Aarch64 executables, but was fixed. +Patches in QEMU causing both Aarch64 and MIPS occurrences are identified and attached below. +Steps to reproduce: +1. Download attached core_test.zip archive. +2. Run pre-built MIPS executable with QEMU. +3. Observe the crash somewhere in tdelete. +4. Source for the test is here: https://github.com/VectorChief/QuadRay-engine +5. The binaries were built with GCC 9.4 cross-compilers using slightly modified makefiles (-ggdb3) for gdb-multiarch +6. Building on Ubuntu 22.04 and Ubuntu 23.04 also reproduces the problem, so it's not OS or compiler specific. +Additional information: +Archive with pre-built binaries: [core_test.zip](/uploads/529833c6f83aeec253df647a94868f8a/core_test.zip) + +Patch breaking Aarch64: [qemu_arm_br.diff](/uploads/476321e40a551e964be41a8bfda96613/qemu_arm_br.diff) +commit 8fe35e0444be88de4e3ab80a2a0e210a1f6d663d + +Patch fixing Aarch64: [qemu_arm_fix.diff](/uploads/2db3892d6839e9a4dfaf427359d6f004/qemu_arm_fix.diff) +commit ae30e86661b0f48562cd95918d37cbeec5d02262 + +Patch breaking MIPS: [qemu_mips_br.diff](/uploads/0a482e61c1245e5783364db845a55dfa/qemu_mips_br.diff) +commit 96e5b4c7584d623f6cdcb0083829c19141b2b130 diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1639 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1639 new file mode 100644 index 000000000..0a33a72fd --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1639 @@ -0,0 +1 @@ +No supported machine for loongson-3A4000 mips64el diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1660 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1660 new file mode 100644 index 000000000..7bc0c1c22 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1660 @@ -0,0 +1 @@ +tests/avocado/linux_ssh_mips_malta.py references mips image URLs that doesn't exist any more diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1722 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1722 new file mode 100644 index 000000000..55d170b80 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1722 @@ -0,0 +1,87 @@ +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include <stdio.h> + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1806 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1806 new file mode 100644 index 000000000..f18433425 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1806 @@ -0,0 +1,5 @@ +Tests: YAMON binaries unavailable +Description of problem: +The [tests for MIPS](https://gitlab.com/qemu-project/qemu/-/blame/master/tests/avocado/machine_mips_malta.py#L127) download the YAMON firmware binaries, however that link does not exist anymore. It appears that it may have [moved to ](https://www.mips.com/develop/tools/boot-loaders/)mips.com (or maybe that's where it came from?), which states "To support existing users of these, and the QEMU project, YAMON is now available under the GPL License." However those links are also dead. I've not been able to find the referenced binaries or source anywhere. @philmd, do you happen to have a copy you can upload? Alternatively, I've found the 2.16 source [here](https://github.com/binsgit/mips-yamon). + +Another alternative would be to use U-boot, which is easy to get a hold of and would work for this test (just getting to a prompt, although I've had issues with it being able to access an IDE drive). I haven't found prebuilt binaries for MIPS and u-boot though. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1922 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1922 new file mode 100644 index 000000000..cce0db52c --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1922 @@ -0,0 +1,20 @@ +loongson3-virt machine fails to bring up secondary CPUs +Description of problem: +When booting Debian netboot on `loongson3-virt` machine with SMP, cores other than number 0 fail to come up. Boot without SMP is successful. + +I provided the details of the first combination I tested, but I have also tested on an x86_64 host, as well as with Debian 11 (kernel `5.10.0-22-loongson-3`) on both hosts, with the same results. +Steps to reproduce: +1. `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/vmlinuz-6.1.0-10-loongson-3` +2. `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/initrd.gz` +3. `qemu-system-mips64el -M loongson3-virt -kernel vmlinuz-6.1.0-10-loongson-3 -initrd initrd.gz -append "console=ttyS0" -serial stdio -smp 2` +Additional information: +Boot is successful when removing `-smp 2` from command line. With it present, the following error is in `dmesg` (extends to all other CPUs when a larger SMP value is passed): +``` +[ 2.248229] rcu: Hierarchical SRCU implementation. +[ 2.248446] rcu: Max phase no-delay instances is 1000. +[ 2.647997] smp: Bringing up secondary CPUs ... +[ 2.749706] Booting CPU#1... +[ 7.093229] CPU1: failed to start +[ 7.096508] smp: Brought up 1 node, 1 CPU +``` +The boot eventually stalls after this. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/193 b/gitlab/issues_text/target_mips/host_missing/accel_missing/193 new file mode 100644 index 000000000..a19fcdc52 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/193 @@ -0,0 +1 @@ +piix crashes on mips when using multiple cpus diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/1987 b/gitlab/issues_text/target_mips/host_missing/accel_missing/1987 new file mode 100644 index 000000000..4c9169869 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/1987 @@ -0,0 +1,48 @@ +snapshot: main thread hangs for a while after 'loadvm' +Description of problem: +When I was testing qemu snapshots, I found that after the `loadvm` command, the virtual machine would often get stuck for a while, and it can **resume execution after I enter some characters into the terminal**, this is weird because my guest system doesn't need to accept input. + +After some debugging, I found that the guest kernel is executing a `wait` instruction in `__r4k_wait()`. + +And I found that the main thread usually does not sleep at `qemu_poll_ns()` during normal execution, but after `loadvm`, the timeout is set to a large value (related to the interval time of snapshot operations), causes the main thread to get stuck on 'qemu_poll_ns()'. + +After some analysis, I think it is because save/load_snapshot() does not handle timers related to QEMU_CLOCK_VIRTUAL well, such as `mips_timer_cb()`, resulting in incorrect value when calculating timeout. +Steps to reproduce: +1. Start emulation and connect monitor +2. `savevm` and wait for a moment +3. `loadvm` +Additional information: +Stack backtrace of the guest kernel: +``` +► 0 0x80104d40 __r4k_wait+32 + 1 0x80143cc4 cpu_startup_entry+284 + 2 0x80143cc4 cpu_startup_entry+284 + 3 0x80143cc4 cpu_startup_entry+284 + 4 0x80633fe0 kernel_init + 5 0x80825cb8 start_kernel+1072 +``` + +Stack backtrace of the main thread: +``` +0 0x7ffff74f0a96 ppoll+166 +1 0x555555ea4786 qemu_poll_ns+221 +2 0x555555e9fea7 os_host_main_loop_wait+93 +3 0x555555e9ffd6 main_loop_wait+187 +4 0x555555a644fd qemu_main_loop+46 +5 0x5555557d2b6a qemu_default_main+17 +6 0x5555557d2ba9 main+45 +7 0x7ffff7402083 __libc_start_main+243 +``` + +Stack backtrace of the vCPU thread: +``` +#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556550848) at ../sysdeps/nptl/futex-internal.h:183 +#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555564d0860 <qemu_global_mutex>, cond=0x555556550820) at pthread_cond_wait.c:508 +#2 __pthread_cond_wait (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>) at pthread_cond_wait.c:647 +#3 0x0000555555e85602 in qemu_cond_wait_impl (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>, file=0x5555560122ab "../system/cpus.c", line=431) at ../util/qemu-thread-posix.c:225 +#4 0x0000555555a5618f in qemu_wait_io_event (cpu=0x555556825200) at ../system/cpus.c:431 +#5 0x0000555555c8bcf1 in mttcg_cpu_thread_fn (arg=0x555556825200) at ../accel/tcg/tcg-accel-ops-mttcg.c:118 +#6 0x0000555555e85e50 in qemu_thread_start (args=0x555556550860) at ../util/qemu-thread-posix.c:541 +#7 0x00007ffff75d8609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#8 0x00007ffff74fd133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/2013 b/gitlab/issues_text/target_mips/host_missing/accel_missing/2013 new file mode 100644 index 000000000..795869ef4 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/2013 @@ -0,0 +1,78 @@ +The avocado test replay_kernel.py:ReplayKernelNormal.test_mips64el_malta is unreliable +Description of problem: +This test keeps hanging on CI +Steps to reproduce: +Run the test on GitLab's CI infrastructure and it will hang on replay. Examples: https://gitlab.com/stsquad/qemu/-/jobs/5664260736 +Additional information: +Excerpt from log: + +``` +18:02:49 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +18:02:49 DEBUG| Opening console file +18:02:49 DEBUG| Opening console socket +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpuset +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpu +18:02:49 DEBUG| [ 0.000000] Linux version 2.6.32-5-5kc-malta (Debian 2.6.32-48) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Feb 15 21:38:11 UTC 2013 +18:02:49 DEBUG| [ 0.000000] +18:02:49 DEBUG| [ 0.000000] LINUX started... +18:02:49 DEBUG| [ 0.000000] bootconsole [early0] enabled +18:02:49 DEBUG| [ 0.000000] CPU revision is: 000182a0 (MIPS 20Kc) +18:02:49 DEBUG| [ 0.000000] FPU revision is: 000f8200 +18:02:49 DEBUG| [ 0.000000] Checking for the multiply/shift bug... no. +18:02:49 DEBUG| [ 0.000000] Checking for the daddiu bug... no. +18:02:49 DEBUG| [ 0.000000] Determined physical RAM map: +18:02:49 DEBUG| [ 0.000000] memory: 0000000000001000 @ 0000000000000000 (reserved) +18:02:49 DEBUG| [ 0.000000] memory: 00000000000ef000 @ 0000000000001000 (ROM data) +18:02:49 DEBUG| [ 0.000000] memory: 0000000000659000 @ 00000000000f0000 (reserved) +18:02:49 DEBUG| [ 0.000000] memory: 00000000078b7000 @ 0000000000749000 (usable) +18:02:49 DEBUG| [ 0.000000] Wasting 104440 bytes for tracking 1865 unused pages +18:02:49 DEBUG| [ 0.000000] Initrd not found or empty - disabling initrd +18:02:49 DEBUG| [ 0.000000] Zone PFN ranges: +18:02:49 DEBUG| [ 0.000000] DMA 0x00000000 -> 0x00001000 +18:02:49 DEBUG| [ 0.000000] Normal 0x00001000 -> 0x00008000 +18:02:49 DEBUG| [ 0.000000] Movable zone start PFN for each node +18:02:49 DEBUG| [ 0.000000] early_node_map[1] active PFN ranges +18:02:49 DEBUG| [ 0.000000] 0: 0x00000000 -> 0x00008000 +18:02:49 DEBUG| [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32320 +18:02:49 DEBUG| [ 0.000000] Kernel command line: printk.time=1 panic=-1 console=ttyS0 +18:02:49 DEBUG| Shutting down VM appliance; timeout=30 +18:02:49 DEBUG| Attempting graceful termination +18:02:49 DEBUG| Closing console file +18:02:49 DEBUG| Closing console socket +18:02:49 DEBUG| Politely asking QEMU to terminate +... + +18:02:49 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +18:02:49 DEBUG| Opening console file +18:02:49 DEBUG| Opening console socket +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpuset +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpu +18:02:49 DEBUG| [ 0.000000] Linux version 2.6.32-5-5kc-malta (Debian 2.6.32-48) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Feb 15 21:38:11 UTC 2013 +18:02:49 DEBUG| [ 0.000000] +18:02:49 DEBUG| [ 0.000000] LINUX started... +18:02:49 DEBUG| [ 0.000000] bootconsole [early0] enabled +18:02:49 DEBUG| [ 0.000000] CPU revision is: 000182a0 (MIPS 20Kc) +18:02:49 DEBUG| [ 0.000000] FPU revision is: 000f8200 +18:02:49 DEBUG| [ 0.000000] Checking for the multiply/shift bug... no. +18:02:49 DEBUG| [ 0.000000] Checking for the daddiu bug... no. +18:02:49 DEBUG| [ 0.000000] Determined physical RAM map: +18:02:49 DEBUG| [ 0.000000] memory: 0000000000001000 @ 0000000000000000 (reserved) +18:02:49 DEBUG| [ 0.000000] memory: 00000000000ef000 @ 0000000000001000 (ROM data) +18:02:49 DEBUG| [ 0.000000] memory: 0000000000659000 @ 00000000000f0000 (reserved) +18:02:49 DEBUG| [ 0.000000] m +18:04:48 ERROR| +18:04:48 ERROR| Reproduced traceback from: /builds/stsquad/qemu/build/pyvenv/lib/python3.10/site-packages/avocado/core/test.py:770 +18:04:48 ERROR| Traceback (most recent call last): +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 147, in test_mips64el_malta +18:04:48 ERROR| self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5) +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 78, in run_rr +18:04:48 ERROR| t2 = self.run_vm(kernel_path, kernel_command_line, console_pattern, +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 61, in run_vm +18:04:48 ERROR| self.wait_for_console_pattern(console_pattern, vm) +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/boot_linux_console.py", line 52, in wait_for_console_pattern +18:04:48 ERROR| wait_for_console_pattern(self, success_message, +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 199, in wait_for_console_pattern +18:04:48 ERROR| _console_interaction(test, success_message, failure_message, None, vm=vm) +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 148, in _console_interaction +18:04:48 ERROR| msg = console.readline().decode().strip() +``` diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/221 b/gitlab/issues_text/target_mips/host_missing/accel_missing/221 new file mode 100644 index 000000000..ff3502686 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/221 @@ -0,0 +1 @@ +piix crashes on mips when accessing acpi-pci-hotplug diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/240 b/gitlab/issues_text/target_mips/host_missing/accel_missing/240 new file mode 100644 index 000000000..7a98ed356 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/240 @@ -0,0 +1 @@ +qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/241 b/gitlab/issues_text/target_mips/host_missing/accel_missing/241 new file mode 100644 index 000000000..960eac644 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/241 @@ -0,0 +1 @@ +Please refactor linux-user/mips/cpu_loop.c diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/2464 b/gitlab/issues_text/target_mips/host_missing/accel_missing/2464 new file mode 100644 index 000000000..dfed795a5 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/2464 @@ -0,0 +1,11 @@ +"rc4030: invalid read at 0xf0-0xf8" shows up, then NT MIPS bluescreens +Description of problem: +The problem is fairly nondescript, but it seems to be a chipset regression that popped up between QEMU 8 and QEMU 9. I had a Windows NT 4 VM that I tried booting in the latest QEMU update after a while of not using it, and it just flat-out refused to do that, outputting the ``INACCESSIBLE_BOOT_DEVICE`` error. Any attempt to boot from the hard drive or reinstall the OS from the CD image would return the same bluescreen, and would show the very message shown in the title in the process log. +Steps to reproduce: +1. Download a Windows NT 3.5x/4.0 ISO. +2. Create a disk image ≤2GB in size. +3. Enter the command above. +4. Go through the preparatory setup, as described in [here](https://computernewb.com/wiki/QEMU/Guests/Windows_NT_3.x-4.0_(MIPS)). (ignore the networking switches, or replace ``dp83932`` with ``ne2k_isa``) +5. Launch the installer by running ``cd:\mips\setupldr``. +Additional information: + diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/2826 b/gitlab/issues_text/target_mips/host_missing/accel_missing/2826 new file mode 100644 index 000000000..9277b6a89 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/2826 @@ -0,0 +1,9 @@ +The host PCI bridge disappeared on the big endian MIPS Malta machine +Description of problem: +The tests/avocado/linux_ssh_mips_malta.py test currently fails for the big endian machines. It tries to check for the PCI host bridge with ``lspci -d 11ab:4620``, but that does not show the expected output anymore -- it looks like the host bridge cannot be correctly discovered by the guest Linux kernel anymore. +Steps to reproduce: +1. Get the kernel and disk image from https://people.debian.org/~aurel32/qemu/mips/ +2. Boot the guest as described above. +3. lspci -d 11ab:4620 +Additional information: +This used to work fine before commit 145e2198d749ec09a405f1607a9932499b76f1eb , so this rework likely introduced the bug. Looking at the code that got removed there, I could see an additional check ``phb->config_reg & 0x00fff800`` that is not present in the new code anymore, so the space for the host bridge itself likely should not get swapped. Reverting 3d85c7c15fc7ce986cf1a8e73da1217228f35685 and 145e2198d749ec09a405f1607a9932499b76f1eb seems to fix the problem (at least on little endian hosts). diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/44 b/gitlab/issues_text/target_mips/host_missing/accel_missing/44 new file mode 100644 index 000000000..3ff831496 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/44 @@ -0,0 +1 @@ +QEMU aborts when specifying additional isa-vga devices diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/51 b/gitlab/issues_text/target_mips/host_missing/accel_missing/51 new file mode 100644 index 000000000..81c051be9 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/51 @@ -0,0 +1 @@ +Linux kernel oops on Malta board while accessing pflash diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/571 b/gitlab/issues_text/target_mips/host_missing/accel_missing/571 new file mode 100644 index 000000000..c01150f3e --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/571 @@ -0,0 +1 @@ +maybe-uninitialized warning in mips cpu_loop() diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/602 b/gitlab/issues_text/target_mips/host_missing/accel_missing/602 new file mode 100644 index 000000000..0360e8cbd --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/602 @@ -0,0 +1,13 @@ +Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation +Description of problem: +In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests. E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI. +Steps to reproduce: +1. https://cirrus-ci.com/task/5914289870471168 +Additional information: +The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014). + +The fix is something like: + +``` +__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno); +``` diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/63 b/gitlab/issues_text/target_mips/host_missing/accel_missing/63 new file mode 100644 index 000000000..350121de2 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/63 @@ -0,0 +1 @@ +Illegal delay slot code causes abort on mips64 diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/644 b/gitlab/issues_text/target_mips/host_missing/accel_missing/644 new file mode 100644 index 000000000..827842949 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/644 @@ -0,0 +1,9 @@ +generic loader does not do virtual to physical address translation when loading MIPS ELF +Description of problem: + +Steps to reproduce: +1.build two ELFs, whose virtual address is at kseg0<p> +2.load one ELF with generic loader "-device loader,file=test1.elf", the other ELF with "-kernel test2.elf"<p> +3.generic loader loads test1.elf without doing address translation, while mipssim load_kernel will do that with cpu_mips_kseg0_to_phys<p> +Additional information: +generic_loader_realize calls load_elf_as with the argument translate_fn=NULL. Maybe, we can set translate_fn when elf_machine is EM_MIPS. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/694 b/gitlab/issues_text/target_mips/host_missing/accel_missing/694 new file mode 100644 index 000000000..76c81c95d --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/694 @@ -0,0 +1 @@ +Crash using MIPS I7200 CPU with non-nanoMIPS ELF diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/695 b/gitlab/issues_text/target_mips/host_missing/accel_missing/695 new file mode 100644 index 000000000..0504be483 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/695 @@ -0,0 +1 @@ +MIPS: nanomips p32 ABI not supported diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/758 b/gitlab/issues_text/target_mips/host_missing/accel_missing/758 new file mode 100644 index 000000000..d3db7f695 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/758 @@ -0,0 +1,46 @@ +[Cross compilation] qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Description of problem: +On the X86 platform, chroot to the latest MIP environment, download the source package, install the dependency, and then compile. It is found that the variation is in error + +Grab logs with GDB on the real machine + +Thread 1 "bash" received signal SIGSEGV, Segmentation fault. +0x00007f094429c656 in code_gen_buffer () +(gdb) bt +#0 0x00007f094429c656 in code_gen_buffer () +#1 0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353 +#2 0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812 +#3 cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970 +#4 0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78 +#5 0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910 +(gdb) thread apply all bt + +Thread 2 (LWP 26312): +#0 0x0000000000766a19 in syscall () +#1 0x000000000058ee0a in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at ./include/qemu/trace-events:29 +#2 qemu_event_wait (ev=ev@entry=0xd44e68 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:480 +#3 0x000000000059690a in call_rcu_thread (opaque=opaque@entry=0x0) at ./b/user-static/thread.h:258 +#4 0x000000000058dc29 in qemu_thread_start (args=<optimized out>) at ../../util/qemu-thread-posix.c:541 +#5 0x00000000006e665e in start_thread (arg=0x7f094c9a3640) at pthread_create.c:463 +#6 0x000000000076836f in clone () + +Thread 1 (LWP 26310): +#0 0x00007f094429c656 in code_gen_buffer () +#1 0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353 +#2 0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812 +#3 cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970 +#4 0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78 +#5 0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910 +(gdb) +``` +Steps to reproduce: +``` +1.Minimum environment for building MIPS platform on +2.On X86 platform sudo chroot . +3.cd build +4.apt source adwaita-icon-theme +5.cd adwaita-icon-theme-3.30.1 +6.debuild -b +``` +Additional information: + diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/843 b/gitlab/issues_text/target_mips/host_missing/accel_missing/843 new file mode 100644 index 000000000..2efc00ca1 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/843 @@ -0,0 +1,3 @@ +qemu-binfmt-conf causes duplicate magic mips headers when installing all patterns +Description of problem: +The magic/mask patterns are the same for mips[el] and nipsn32[el] diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/909 b/gitlab/issues_text/target_mips/host_missing/accel_missing/909 new file mode 100644 index 000000000..96c0b3c1a --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/909 @@ -0,0 +1,11 @@ +qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries +Description of problem: +**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.** + +Trying to chroot into a mips n32 installation fails with +``` +/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data +``` +however, bash, libc.so.6, and qemu all exist and have the proper abi + +The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware. diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/939 b/gitlab/issues_text/target_mips/host_missing/accel_missing/939 new file mode 100644 index 000000000..a5e40ca31 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/939 @@ -0,0 +1,75 @@ +qemu-mipsn32el user mode emulator allocates pointers beyond upper memory limit +Description of problem: +In qemu-based N32 mips chroots (both BE and LE), I became aware of memory-intensive programs segfaulting, apparently at random. tar, gcc, but only in specific situations. Watching the strace output of gcc, I got the impression that it happens when memory beyond 2Gbyte is allocated. (mips n32 and o32 uses only 31 bit of a pointer, I've been told, so this is somewhat expected, but a segfault is nevertheless wrong.) + +So, I used the following test program, statically linked: +``` +#include <stdlib.h> +#include <stdio.h> +#include <string.h> + +int main() { + + char *pointer; + int i; + + for (i=1; i<301; i++) { + + printf("Allocation %i : ", i); + pointer = malloc(20480000 * sizeof(char)); + + printf(" pointer is %p, ", pointer); + + if (! pointer) { + printf("malloc failed\n"); + exit(0); + }; + + memset(pointer, 0xDB, 20480000); + printf(" filled\n"); + } +}; +``` + +With mips3 n32 I get the following output: +``` +pinacolada ~ # file /var/lib/machines/mips64el-n32/root/memtest +/var/lib/machines/mips64el-n32/root/memtest: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mipsn32el /var/lib/machines/mips64el-n32/root/memtest +Allocation 1 : pointer is 0x40802010, filled +Allocation 2 : pointer is 0x41b8b010, filled +Allocation 3 : pointer is 0x42f14010, filled +[...] +Allocation 51 : pointer is 0x7d8c4010, filled +Allocation 52 : pointer is 0x7ec4d010, filled +qemu: unhandled CPU exception 0x15 - aborting +pc=0x0000000010021944 HI=0x0000000000000004 LO=0x00000000100218f0 ds 02ea 00000000100218f0 0 +GPR00: r0 0000000000000000 at 0000000000000001 v0 000000007ffd6010 v1 0000000026f77200 +GPR04: a0 000000007ffd6010 a1 dbdbdbdbdbdbdbdb a2 0000000001388000 a3 0000000001388000 +GPR08: t0 0000000025252525 t1 0000000025252525 t2 ffffffffffffffff t3 000000001006c369 +GPR12: t4 000000001006c368 t5 0000000000000000 t6 0000000000000000 t7 0000000000000010 +GPR16: s0 0000000000000001 s1 00000000407ffd54 s2 000000001009b270 s3 0000000000000000 +GPR20: s4 0000000010000760 s5 00000000407ffd5c s6 0000000000000000 s7 0000000000000000 +GPR24: t8 0000000000000000 t9 00000000100218f0 k0 0000000000000000 k1 0000000000000000 +GPR28: gp 00000000100a7320 sp 00000000407ffbf0 s8 00000000407ffbf0 ra 0000000010000854 +CP0 Status 0x24800010 Cause 0x00000000 EPC 0x0000000000000000 + Config0 0x80004482 Config1 0xbe61309b LLAddr 0x0000000000000000 + Config2 0x80000000 Config3 0x00000000 + Config4 0x00000000 Config5 0x00000000 +** +ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +``` + +For mips2 o32 I get the more correct looking output +``` +pinacolada ~ # file /var/lib/machines/mips-o32/root/memtest +/var/lib/machines/mips-o32/root/memtest: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mips /var/lib/machines/mips-o32/root/memtest +Allocation 1 : pointer is 0x3ec76008, filled +Allocation 2 : pointer is 0x3d8ed008, filled +Allocation 3 : pointer is 0x3c564008, filled +[...] +Allocation 104 : pointer is 0x4082c008, filled +Allocation 105 : pointer is (nil), malloc failed +``` diff --git a/gitlab/issues_text/target_mips/host_missing/accel_missing/995 b/gitlab/issues_text/target_mips/host_missing/accel_missing/995 new file mode 100644 index 000000000..0c3bbd994 --- /dev/null +++ b/gitlab/issues_text/target_mips/host_missing/accel_missing/995 @@ -0,0 +1,11 @@ +Segfault when saving VM snapshot via QEMU monitor on MIPS and MIPSEL +Description of problem: +When entering the QEMU monitor using Ctrl-A then C, and running the savevm QEMU command, the emulator hangs for a while and then exits with a segfault. This occurs on MIPS and MIPSEL system emulators using the same command line arguments. ARM32, aarch64 and x86_64 emulators don't seem to have this problem. I haven't tested it on any other architectures as I don't have kernel or drive images for them. `qemu-img` seems to work fine with the QCOW2 images used for this test, I was able to create and load offline snapshots from them. The images were created from raw EXT2 filesystem images produced by Buildroot, using `qemu-img convert`. +Steps to reproduce: +1. Start the QEMU system emulator for MIPS/MIPSEL with the given command line. +2. Enter the QEMU monitor with Ctrl-A, C. +3. Run `savevm <vm name>`. +Additional information: +I tried logging what QEMU was doing with the `-D ./log.txt` command line option, but the produced log file was empty. + +If you need me to send you the kernel image files and QCOW2 images used, I would be happy to do so. |