diff options
Diffstat (limited to 'results/classifier/deepseek-r1:14b/output/kernel')
54 files changed, 1314 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1007 b/results/classifier/deepseek-r1:14b/output/kernel/1007 new file mode 100644 index 00000000..83851d53 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1007 @@ -0,0 +1,2 @@ + +qemu-user: add execveat syscall support diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1033494 b/results/classifier/deepseek-r1:14b/output/kernel/1033494 new file mode 100644 index 00000000..d1e0ca51 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1033494 @@ -0,0 +1,11 @@ + +qemu-system-x86_64 segfaults with kernel 3.5.0 + +qemu-kvm 1.1.1 stable is running fine for me with RHEL 6 2.6.32 based kernel. + +But with 3.5.0 kernel qemu-system-x86_64 segfaults while i'm trying to install ubuntu 12.04 server reproducable. + +You find three backtraces here: +http://pastebin.com/raw.php?i=xCy2pEcP + +Stefan \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1042388 b/results/classifier/deepseek-r1:14b/output/kernel/1042388 new file mode 100644 index 00000000..6d8c191e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1042388 @@ -0,0 +1,15 @@ + +qemu: Unsupported syscall: 257 (timer_create) + +Running qemu-arm-static for git HEAD. When I try to install ghc from debian into my arm chroot I get: + +Setting up ghc (7.4.1-4) ... +qemu: Unsupported syscall: 257 +ghc: timer_create: Function not implemented +qemu: Unsupported syscall: 257 +ghc-pkg: timer_create: Function not implemented +dpkg: error processing ghc (--configure): + subprocess installed post-installation script returned error exit status 1 +Errors were encountered while processing: + ghc +E: Sub-process /usr/bin/dpkg returned an error code (1) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1147 b/results/classifier/deepseek-r1:14b/output/kernel/1147 new file mode 100644 index 00000000..60a009f2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1147 @@ -0,0 +1,10 @@ + +x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu) +Description of problem: +Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.` + +No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above. + +Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi. + +These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit). diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1207686 b/results/classifier/deepseek-r1:14b/output/kernel/1207686 new file mode 100644 index 00000000..69f5138d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1207686 @@ -0,0 +1,29 @@ + +qemu-1.4.0 and onwards, linux kernel 3.2.x, heavy I/O leads to kernel_hung_tasks_timout_secs message and unresponsive qemu-process + +Hi, + +after some testing I tried to narrow down a problem, which was initially reported by some users. +Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. + +All using some flavour of linux-3.2.x kernel. + +Tried e.g. under Ubuntu an upgrade to "Linux 3.8.0-27-generic x86_64" which solves the problem. +Problem could be triggert with some workload ala: + +spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat +and in parallel do some apt-get install/remove/whatever. + +That results in a somewhat stuck qemu-session with the bad "kernel_hung_task..." messages. + +A typical command-line is as follows: + +/usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable-kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu-server/760.vnc,password -qmp unix:/var/run/qemu-server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc + +no "system_reset", "sendkey ctrl-alt-delete" or "q" in monitoring-session is accepted, need to hard-kill the process. + +Please give any advice on what to do for tracing/debugging, because the number of tickets here are raising, and noone knows, what users are doing inside their VM. + +Kind regards, + +Oliver Francke. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1281 b/results/classifier/deepseek-r1:14b/output/kernel/1281 new file mode 100644 index 00000000..66b4bd87 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1281 @@ -0,0 +1,2 @@ + +xv6 kernel problem in single step mode diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1290 b/results/classifier/deepseek-r1:14b/output/kernel/1290 new file mode 100644 index 00000000..4d4f7667 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1290 @@ -0,0 +1,2 @@ + +IO alignment probing delivers incorrect results on Linux when used with e.g. dm-crypt diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1290370 b/results/classifier/deepseek-r1:14b/output/kernel/1290370 new file mode 100644 index 00000000..d62e3457 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1290370 @@ -0,0 +1,31 @@ + +FreeBSD 9.2 shell crashes when run with -smp 4 option + +This is a bug that i have noticed in qemu 1.7.50 as well as 1.1.50. It was the latter that forced me to clone the repository to check if this is the case with the resent version as well . The latest commit on which the bug is found is f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git + +configured with target list i386-softmmu +and then +make + +OS: FreeBSD 9.2 Text Install ISO +Installed it to a qcow2 format image. + +./i386-softmmu/qemu-system-i386 -hda <bsd-image> -m 2G -smp 4 -net nic -net user -monitor stdio + +(boot into multi-user mode)->(login to root account) + +I have the filebench benchmark installed on the image and when i run it the default root shell (csh) crashes with the error. +[pid xxxx (csh) sigreturn eflag = 0xXXXX] +Here is the piece of kernel code that is getting executed (i think) http://svnweb.freebsd.org/base/release/9.2.0/sys/i386/i386/machdep.c?view=markup#l1095 + +Here is a related bug +https://www.virtualbox.org/ticket/458 + +The crash happens randomly. It is not just related with filebench. +Here are a few scenarios: +* When i run fileserver workload of filebench +* After i issue the shutdown -h now shutdown -r now commands +* Issuing mount -t linprocfs proc /proc + +Moreover it is not guaranteed that the above scenarios will reproduce it (reliably). +Basically after running some commands and getting the CPU and the kernel worked up i think. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1292 b/results/classifier/deepseek-r1:14b/output/kernel/1292 new file mode 100644 index 00000000..ce20bee0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1292 @@ -0,0 +1,4 @@ + +Default jemalloc config doesn't work on Asahi Linux +Description of problem: +M1 Macs use 16KB pages, jemalloc builds with 4KB page by default. diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1383857 b/results/classifier/deepseek-r1:14b/output/kernel/1383857 new file mode 100644 index 00000000..783332a6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1383857 @@ -0,0 +1,18 @@ + +aarch64: virtio disks don't show up in guest (neither blk nor scsi) + +kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) +qemu from git today + +When I create a guest with virtio-scsi disks, they don't show up inside the guest. +Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are +no messages about disks, and of course nothing else works. + +Really long command line (generated by libvirt): + +HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none TMPDIR=/home/rjones/d/libguestfs/tmp /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib/guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-reboot -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-serial0 -usb -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -serial unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -msg timestamp=on + +There are no kernel messages about the disks, they just are not seen. + +Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a +qemu bug, but I've no idea where to report those. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1450881 b/results/classifier/deepseek-r1:14b/output/kernel/1450881 new file mode 100644 index 00000000..de310b33 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1450881 @@ -0,0 +1,26 @@ + +qemu-system-sparc MUTEX_HELD assert and libC lock errors + +Here I am cross-posting a comment I made on Artyom's blog. Atar responded that he "fixed these issues for some customers". I hoped that opening a bug to the opensource project might help develop the solution for the public domain. + +I now have a mostly-working Solaris 6 emulation, with great thanks to the valuable information in Artyom's blog, brezular.com, and the QEMU/Solaris 4.14 wikibook. + +setup detail; +QEMU (present git snapshot, reports --version 2.2.92) +-M SS-20, openboot/proprietary prom + +# uname -a +SunOS emu0 5.6 Generic_105181-33 sun4m sparc SUNW,SPARCstation-20 + +I continue to have a problem, which I have found others posted in blog comments, but have not seen a resolution yet. + +# /etc/init.d/init.dmi start +Run-time error, libC: +Trying to release a lock that was not acquired in this thread +(repeat above 1x) +Abort - core dumped + +as well as: +Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, line 766 + +which prints to the console periodically when "dmispd" is running. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1503 b/results/classifier/deepseek-r1:14b/output/kernel/1503 new file mode 100644 index 00000000..ac757f65 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1503 @@ -0,0 +1,51 @@ + +Writing to readonly memory should call cpu_transaction_failed +Description of problem: +Currently if a guest writes to ROM memory on a system that doesn't have some other form of memory protection enabled, QEMU will silently ignore the write (https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L2432). Instead, it should call cpu_transaction_failed (similar to what happens when a MMIO operation fails in `io_writex` and other places). For CPUs that don't care, it'll continue to be ignored, but for other CPUs the user will get a warning (with `-d guest_errors`) or an exception as appropriate. +Steps to reproduce: +N/A +Additional information: +The documentation for do_transaction_failed says: + +``` +@do_transaction_failed: Callback for handling failed memory transactions +(ie bus faults or external aborts; not MMU faults) +``` + +which seems reasonably well suited for this case. Here's an overview of what different CPUs currently do if do_transaction_failed is called: + +alpha_cpu_do_transaction_failed: + +* raises a EXCP_MCHK + +arm_cpu_do_transaction_failed: + +* raises ARMFault_SyncExternal with EXCP_DATA_ABORT + +loongarch_cpu_do_transaction_failed: + +* raises EXCCODE_ADEM + +m68k_cpu_transaction_failed: + +* raises EXCP_ACCESS (M68040 only) + +mb_cpu_transaction_failed: + +* raises EXCP_HW_EXCP with ESR_EC_DATA_BUS + +mips_cpu_do_transaction_failed: + +* raises EXCP_DBE (data bus error) + +riscv_cpu_do_transaction_failed: + +* raises RISCV_EXCP_STORE_AMO_ACCESS_FAULT + +sparc_cpu_do_transaction_failed: + +* raises an MMU fault + +xtensa_cpu_do_transaction_failed + +* raises LOAD_STORE_PIF_ADDR_ERROR_CAUSE diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1591611 b/results/classifier/deepseek-r1:14b/output/kernel/1591611 new file mode 100644 index 00000000..0838cb55 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1591611 @@ -0,0 +1,24 @@ + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1670175 b/results/classifier/deepseek-r1:14b/output/kernel/1670175 new file mode 100644 index 00000000..9ae854b7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1670175 @@ -0,0 +1,63 @@ + +qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate" + +> qemu-system-sparc64 -m 1024 -cdrom Downloads/tribblix-sparc-0m16.iso -boot d -nographic +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Loaded 7120 bytes +entry point is 0x4000 +Evaluating FCode... +Evaluating FCode... +Ignoring failed claim for va 10a96a0 memsz 19! +Ignoring failed claim for va 1000000 memsz d1fb6! +Ignoring failed claim for va 1402000 memsz 32518! +Ignoring failed claim for va 1800000 memsz 52ac8! +SunOS Release 5.11 Version tribblix-m16 64-bit +Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. +could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught +interpret \ ident "%Z%%M% %I% %E% SMI" +\ Copyright 2005 Sun Microsystems, Inc. All rights reserved. +\ Use is subject to license terms. +\ +\ CDDL HEADER START +\ +\ The contents of this file are subject to the terms of the +\ Common Development and Distribution License, Version 1.0 only +\ (the "License"). You may not use this file except in compliance +\ with the License. +\ +\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE +\ or http://www.opensolaris.org/os/licensing. +\ See the License for +WARNING: add_spec: No major number for sf +panic - kernel: no nucleus hblk8 to allocate +EXIT + +QEMU keeps running (CPU is on 100 % all the time), I can interact with the prompt: + +0 > boot +Not a Linux kernel image +Not a bootable ELF image +Not a bootable a.out image + +Loading FCode image... +Unhandled Exception 0x0000000000000018 +PC = 0x00000000ffd25310 NPC = 0x00000000ffd25314 +Stopping execution + +> qemu-system-sparc64 -version +QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) + +from https://build.opensuse.org/package/show/Virtualization:Staging/qemu on openSUSE Leap 42.2. + +ISO: http://pkgs.tribblix.org/iso/tribblix-sparc-0m16.iso. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1696353 b/results/classifier/deepseek-r1:14b/output/kernel/1696353 new file mode 100644 index 00000000..c5609e1a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1696353 @@ -0,0 +1,36 @@ + +golang binaries fail to start under linux-user + +With current master golang binaries fail when run under linux-user, for example: + +[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x45f879, 0x9) + /usr/lib/golang/src/runtime/panic.go:566 +0x78 +runtime.newosproc(0x1092c000, 0x1093bfe0) + /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 +runtime.newm(0x4ae1e8, 0x0) + /usr/lib/golang/src/runtime/proc.go:1572 +0x12c +runtime.main.func1() + /usr/lib/golang/src/runtime/proc.go:126 +0x24 +runtime.systemstack(0x5ef900) + /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 +runtime.mstart() + /usr/lib/golang/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 +runtime.main() + /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac +runtime.goexit() + /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 + +The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: + +https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 + +The attached patch allows golang binaries to start under linux-user. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/172 b/results/classifier/deepseek-r1:14b/output/kernel/172 new file mode 100644 index 00000000..7d7255e6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/172 @@ -0,0 +1,2 @@ + +qemu seems to lack support for pid namespace. diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1751674 b/results/classifier/deepseek-r1:14b/output/kernel/1751674 new file mode 100644 index 00000000..12636ab7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1751674 @@ -0,0 +1,16 @@ + +qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers + +Qemu segfaults trying to generate a VM memory dump: + +$ QEMU_AUDIO_DRV=none qemu-git-src/arm-softmmu/qemu-system-arm -M vexpress-a9 -smp 4 -m 1024 -machine secure=off,dump-guest-core=on -kernel linux-4.9.75/arch/arm/boot/zImage -append "root=/dev/mmcblk0 rw rootfstype=ext4 mem=1024M net.ifnames=0 console=ttyAMA0" -dtb vexpress-v2p-ca9.dtb -sd armv7-hd.qcow2 -netdev tap,ifname=tap_armv7,script=no,downscript=no,id=net0 -device virtio-net-device,mac=00:DE:AD:BE:FF:02,netdev=net0 -monitor stdio -serial vc -loadvm SS0 +QEMU 2.11.50 monitor - type 'help' for more information +(qemu) pmemsave 0 0x3FFFFFFF memory.dmp +Segmentation fault (core dumped) + +$ git rev-parse HEAD +b384cd95eb9c6f73ad84ed1bb0717a26e29cc78f + +It's the second time I try to submit this bug, I think last time it failed because the attached core dump size (400M compressed). Have a look if you can get that file, otherwise I will try to update this ticket once it's created: + +(Error ID: OOPS-65553b72bc14be693eb1e37814ff9267) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1754372 b/results/classifier/deepseek-r1:14b/output/kernel/1754372 new file mode 100644 index 00000000..86fd39c3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1754372 @@ -0,0 +1,10 @@ + +Set MIPS MSA in ELF Auxiliary Vectors + +The MIPS MSA feature is currently not set in the ELF auxiliary vector. + +That is, querying the AT_HWCAP key of the ELF auxiliary vectors for a MIPS CPU that has the MSA feature should return a value that has the second bit [0] set. + +From [0], `HWCAP_MIPS_MSA` is defined to `1 << 1`. + +[0]: https://github.com/torvalds/linux/blob/master/arch/mips/include/uapi/asm/hwcap.h \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1782300 b/results/classifier/deepseek-r1:14b/output/kernel/1782300 new file mode 100644 index 00000000..66979a6a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1782300 @@ -0,0 +1,97 @@ + +COLO unable to failover to secondary VM + +I test COLO feature on my host following docs/COLO-FT.txt in qemu folder, but fail to failover to secondary VM. +Is there any mistake in my execution steps? + +Execution environment: +QEMU v2.12.0-rc4 +OS: Ubuntu 16.04.3 LTS +Kernel: Linux 4.4.35 +Secondary VM IP: noted as "a.b.c.d" + +Execution steps: +# Primary +${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -m 512M \ + -smp 2 \ + -qmp stdio \ + -vnc :7 \ + -name primary \ + -device piix3-usb-uhci \ + -device usb-tablet \ + -netdev tap,id=tap0,vhost=off \ + -device virtio-net-pci,id=net-pci0,netdev=tap0 \ + -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ + children.0.file.filename=${IMG_PATH},\ + children.0.driver=raw -S + +# Secondary +${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -m 512M \ + -smp 2 \ + -qmp stdio \ + -vnc :8 \ + -name secondary \ + -device piix3-usb-uhci \ + -device usb-tablet \ + -netdev tap,id=tap1,vhost=off \ + -device virtio-net-pci,id=net-pci0,netdev=tap1 \ + -drive if=none,id=secondary-disk0,file.filename=${IMG_PATH},driver=raw,node-name=node0 \ + -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ + file.driver=qcow2,top-id=active-disk0,\ + file.file.filename=$ACTIVE_DISK,\ + file.backing.driver=qcow2,\ + file.backing.file.filename=$HIDDEN_DISK,\ + file.backing.backing=secondary-disk0 \ + -incoming tcp:0:8888 + +# Enter into Secondary: +{'execute':'qmp_capabilities'} +{ 'execute': 'nbd-server-start', + 'arguments': {'addr': {'type': 'inet', 'data': {'host': 'a.b.c.d', 'port': '8889'} } } +} +{'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', 'writable': true } } + +# Enter into Primary: +{'execute':'qmp_capabilities'} +{'execute': 'human-monitor-command', + 'arguments': { + 'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=a.b.c.d,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0' + } +} +{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 'node': 'nbd_client0' } } +{ 'execute': 'migrate-set-capabilities', + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:a.b.c.d:8888' } } + +# To test failover +Primary +{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'primary-disk0', 'child': 'children.1'}} +{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del nbd_client0'}} + +Secondary +{ 'execute': 'nbd-server-stop' } + +Stop Primary +Send ^C signal to terminate PVM. + +Secondary +{ "execute": "x-colo-lost-heartbeat" } + + +# Result: +Primary (Use ^C to terminate) +qemu-system-x86_64: Can't receive COLO message: Input/output error +qemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1531815575, "microseconds": 997696}, "event": "SHUTDOWN", "data": {"guest":false}} + +Secondary +{ 'execute': 'nbd-server-stop' } +{"return": {}} +{ "execute": "x-colo-lost-heartbeat" } +{"return": {}} +qemu-system-x86_64: Can't receive COLO message: Input/output error +Segmentation fault \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1805256 b/results/classifier/deepseek-r1:14b/output/kernel/1805256 new file mode 100644 index 00000000..149bd551 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1805256 @@ -0,0 +1,27 @@ + +qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images + +On the HiSilicon D06 system - a 96 core NUMA arm64 box - qemu-img frequently hangs (~50% of the time) with this command: + +qemu-img convert -f qcow2 -O qcow2 /tmp/cloudimg /tmp/cloudimg2 + +Where "cloudimg" is a standard qcow2 Ubuntu cloud image. This qcow2->qcow2 conversion happens to be something uvtool does every time it fetches images. + +Once hung, attaching gdb gives the following backtrace: + +(gdb) bt +#0 0x0000ffffae4f8154 in __GI_ppoll (fds=0xaaaae8a67dc0, nfds=187650274213760, + timeout=<optimized out>, timeout@entry=0x0, sigmask=0xffffc123b950) + at ../sysdeps/unix/sysv/linux/ppoll.c:39 +#1 0x0000aaaabbefaf00 in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, + __fds=<optimized out>) at /usr/include/aarch64-linux-gnu/bits/poll2.h:77 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, + timeout=timeout@entry=-1) at util/qemu-timer.c:322 +#3 0x0000aaaabbefbf80 in os_host_main_loop_wait (timeout=-1) + at util/main-loop.c:233 +#4 main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:497 +#5 0x0000aaaabbe2aa30 in convert_do_copy (s=0xffffc123bb58) at qemu-img.c:1980 +#6 img_convert (argc=<optimized out>, argv=<optimized out>) at qemu-img.c:2456 +#7 0x0000aaaabbe2333c in main (argc=7, argv=<optimized out>) at qemu-img.c:4975 + +Reproduced w/ latest QEMU git (@ 53744e0a182) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1813045 b/results/classifier/deepseek-r1:14b/output/kernel/1813045 new file mode 100644 index 00000000..b265cdc5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1813045 @@ -0,0 +1,17 @@ + +qemu-ga fsfreeze crashes the kernel + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +I believe this is the culprit: + +/dev/loop0 /tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0 +/dev/loop0 /var/tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1827871 b/results/classifier/deepseek-r1:14b/output/kernel/1827871 new file mode 100644 index 00000000..da1e22b2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1827871 @@ -0,0 +1,44 @@ + +Race condition when rebooting with the TCG backend + +Reporting this as present in QEMU 3.1.0, although I don't see any commit in current git master (a6ae23831b05a11880b40f7d58e332c45a6b04f7) that would suggest this issue is fixed. + + $ uname -a + Linux boole 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 GNU/Linux + $ qemu -version + QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7) + Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Here's an excerpt from the code which handles reboot requests in SeaBIOS 1.12, located in src/fw/shadow.c: + + // Request a QEMU system reset. Do the reset in this function as + // the BIOS code was overwritten above and not all BIOS + // functionality may be available. + + // Attempt PCI style reset + outb(0x02, PORT_PCI_REBOOT); + outb(0x06, PORT_PCI_REBOOT); + + // Next try triple faulting the CPU to force a reset + asm volatile("int3"); + +This compiles to the following: + + (qemu) x/10i 0xf1993 + 0x000f1993: b0 02 movb $2, %al + 0x000f1995: ee outb %al, %dx + 0x000f1996: b0 06 movb $6, %al + 0x000f1998: ee outb %al, %dx + 0x000f1999: cc int3 + 0x000f199a: 80 3d 0d 53 0f 00 08 cmpb $8, 0xf530d + 0x000f19a1: 75 52 jne 0xf19f5 + 0x000f19a3: a1 10 53 0f 00 movl 0xf5310, %eax + 0x000f19a8: 8b 15 14 53 0f 00 movl 0xf5314, %edx + 0x000f19ae: 89 c3 movl %eax, %ebx + +Now, with the TCG backend, upon reaching the second outb instruction, the thread executing JIT-ed opcodes invokes qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). This signals another thread to reset the guest CPU registers to their initial state. However, the execution thread is *not* stopped, which means it will keep executing already-translated instructions in the TCG buffer. In particular, the bootstrap value of the EIP register will be overwritten. On my machine, this usually results in the guest CPU finding itself in real mode, CS base 0xffff0000, EIP 0x0000199e, which in real mode disassembles to this: + + (qemu) xp/1i 0xf199e + 0x000f199e: 0f 00 08 strw 0(%bx, %si) + +This instruction triggers a #UD exception, and given that SeaBIOS handles #UD by immediately returning, it manifests as the guest locking up with 100% CPU usage every other reboot. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1867786 b/results/classifier/deepseek-r1:14b/output/kernel/1867786 new file mode 100644 index 00000000..fabaa868 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1867786 @@ -0,0 +1,28 @@ + +Qemu PPC64 freezes with multi-core CPU + +I installed Debian 10 on a Qemu PPC64 VM running with the following flags: + +qemu-system-ppc64 \ + -nographic -nodefaults -monitor pty -serial stdio \ + -M pseries -cpu POWER9 -smp cores=4,threads=1 -m 4G \ + -drive file=debian-ppc64el-qemu.qcow2,format=qcow2,if=virtio \ + -netdev user,id=network01,$ports -device rtl8139,netdev=network01 \ + + +Within a couple minutes on any operation (could be a Go application or simply changing the hostname with hostnamectl, the VM freezes and prints this on the console: + +``` +root@debian:~# [ 950.428255] rcu: INFO: rcu_sched self-detected stall on CPU +[ 950.428453] rcu: 3-....: (5318 ticks this GP) idle=8e2/1/0x4000000000000004 softirq=5957/5960 fqs=2544 +[ 976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462] + +Message from syslogd@debian at Mar 17 11:35:24 ... + kernel:[ 976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462] +[ 980.110018] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 3-... } 5276 jiffies s: 93 root: 0x8/. +[ 980.111177] rcu: blocking rcu_node structures: +[ 1013.442268] rcu: INFO: rcu_sched self-detected stall on CPU +[ 1013.442365] rcu: 3-....: (21071 ticks this GP) idle=8e2/1/0x4000000000000004 softirq=5957/5960 fqs=9342 +``` + +If I change to 1 core on the command line, I haven't seen these freezes. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1872847 b/results/classifier/deepseek-r1:14b/output/kernel/1872847 new file mode 100644 index 00000000..0bd8ee0d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1872847 @@ -0,0 +1,23 @@ + +qemu-alpha linux-user breaks python3.6 + +Running on Gentoo Linux in a chroot environment: +# python3 -c 'import selectors; selectors.DefaultSelector()' +Traceback (most recent call last): + File "<string>", line 1, in <module> + File "/usr/lib/python3.7/selectors.py", line 349, in __init__ + self._selector = self._selector_cls() +OSError: [Errno 22] Invalid argument + +However, on real hardware, with the same binaries there is no exception. + +This impacts whole python3 based Gentoo ebuild system (package management), and renders linux user mode alpha emulation in chroot environment building useless, more or less. + +The used systems: +# qemu-alpha --version +qemu-alpha version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +# uname -a +Linux blackbird 5.4.28-gentoo-blackbird-06 #2 SMP Sat Apr 4 13:13:10 CEST 2020 x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux +(chroot)# python3 --version +Python 3.7.7 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1876568 b/results/classifier/deepseek-r1:14b/output/kernel/1876568 new file mode 100644 index 00000000..452a2634 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1876568 @@ -0,0 +1,18 @@ + +"semtimedop" implementation missing in qemu? + +I was trying to do an ARMv6 cross compile with qemu-user-static when I ran into this: + +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/326884620#L1596 + +I was close to giving up when I found the following: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36 + +Most important comment may be this one: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36#issuecomment-610626796 + +> The "correct" way to fix this does seem to be to implement semtimedop in qemu. + +I don't know how much involved the people, discussing there, are in the qemu development but I thought it may be a good idea to bring this to your attention. If this is already fixed (I haven't found any bug about "semtimedop"), then please just close this one and tell me in which version the fix will be included. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1878413 b/results/classifier/deepseek-r1:14b/output/kernel/1878413 new file mode 100644 index 00000000..18f37282 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1878413 @@ -0,0 +1,16 @@ + +/proc/sys/fs/binfmt_misc/ empty even though binfmt_misc is loaded + +_apksigner_ uses binfmt to execute via _jarwrapper_, since it is a JAR. We have a test suite that relies on _apksigner_ working. It was running fine in Ubuntu/bionic. Since it was pegged to LTS, it got upgraded to Ubuntu/focal and it stopped working. This is likely because /proc/sys/fs/binfmt_misc/ is totally empty. The "binfmt_misc" kernel module shows as loaded: + +$ grep binfmt /proc/modules +binfmt_misc 20480 1 - Live 0xffffffffc0452000 + +This relies on binfmt support in gitlab.com's CI runner setup, based on Docker. binfmt works in containers there, for example on Ubuntu/bionic: +https://gitlab.com/fdroid/fdroidserver/-/jobs/516857857 + +Something in Ubuntu/focal broke this when running focal in the container on the same Docker host runners: +https://gitlab.com/fdroid/fdroidserver/-/jobs/547148092 + +Debian's ci.debian.net lxc runners also have a similar problem, it might be related: +https://salsa.debian.org/ci-team/debian-ci-config/-/issues/1 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1884425 b/results/classifier/deepseek-r1:14b/output/kernel/1884425 new file mode 100644 index 00000000..14e9c98f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1884425 @@ -0,0 +1,12 @@ + +MIPS64EL emu hangs at reboot + +QEMU Release version: 5.0.50 (v5.0.0-1411-g26bf4a2921-dirty) + +Full command line: qemu-system-mips64el -hda nt4svr.qcow2 -M magnum -L . -global ds1225y.filename=nvram -global ds1225y.size=8200 -net nic -net user -cdrom en_winnt_4.0_svr.iso + +Host machine: Windows 10 1909 64-bit, QEMU running under WSL with the latest Kali distro and the latest Xming. + +Guest machine: MIPS64EL Magnum machine, no OS needs to be installed to reproduce - just change some stuff in the Setup program and try to exit + +Note: Custom ROM with Windows NT support used, NTPROM.RAW used from http://hpoussineau.free.fr/qemu/firmware/magnum-4000/setup.zip \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1887306 b/results/classifier/deepseek-r1:14b/output/kernel/1887306 new file mode 100644 index 00000000..0ea9a50c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1887306 @@ -0,0 +1,56 @@ + +qemu-user deadlocks when forked in a multithreaded process + +The following program (also attached) deadlocks when run under QEMU user on Linux. + +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> + +#define NUM_THREADS 100 +#define NUM_FORKS 10 + +pthread_barrier_t barrier; + +void *t(void *arg) { + for (int i = 0; i < NUM_FORKS; i++) { + pid_t pid = fork(); + if (pid < 0) + abort(); + if (!pid) + _exit(0); + if (waitpid(pid, NULL, 0) < 0) + abort(); + } + //pthread_barrier_wait(&barrier); + return NULL; +} + +int main(void) { + pthread_barrier_init(&barrier, NULL, NUM_THREADS); + pthread_t ts[NUM_THREADS]; + for (size_t i = 0; i < NUM_THREADS; i++) { + if (pthread_create(&ts[i], NULL, t, NULL)) + abort(); + } + for (size_t i = 0; i < NUM_THREADS; i++) { + pthread_join(ts[i], NULL); + } + printf("Done: %d\n", getpid()); + return 0; +} + +To reproduce: +$ gcc test.c -pthread +$ while qemu-x86_64 ./a.out; do :; done + +(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). + +Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. + +I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. + +Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1907938 b/results/classifier/deepseek-r1:14b/output/kernel/1907938 new file mode 100644 index 00000000..6afbe445 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1907938 @@ -0,0 +1,73 @@ + +[OSS-Fuzz] Issue 28524 virtio-blk: ASSERT: !s->dataplane_started + + affects qemu + +=== Reproducer === + +cat << EOF |./qemu-system-i386 -display none -m 512M -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw -qtest stdio +outl 0xcf8 0x8000181f +outl 0xcfc 0xa044d79 +outl 0xcf8 0x80001802 +outl 0xcf8 0x80001804 +outl 0xcfc 0xb9045dff +outl 0xcf8 0x8000180e +outl 0xcfc 0xfb9465a +outl 0xf85 0x9e1ea5c2 +write 0x9f002 0x1 0x04 +write 0x9f004 0x1 0x04 +write 0x9e040 0x1 0x04 +write 0x9e043 0x1 0x01 +write 0x9e048 0x1 0x10 +write 0x9e04c 0x1 0x01 +write 0x9e04e 0x1 0x6e +write 0x1000004 0x1 0x01 +write 0x9e6e3 0x1 0x01 +write 0x9e6eb 0x1 0x04 +write 0x9e6ec 0x1 0x6e +write 0x9f006 0x1 0x04 +write 0x9f008 0x1 0x04 +write 0x9f00a 0x1 0x04 +outl 0xf8f 0xc +EOF + +=== Stack Trace === + +qemu-fuzz-i386: ../hw/block/virtio-blk.c:917: void virtio_blk_reset(VirtIODevice *): Assertion `!s->dataplane_started' failed. +==702068== ERROR: libFuzzer: deadly signal +#0 0x55bd6fc9f311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311) +#1 0x55bd6fbe83d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8) +#2 0x55bd6fbce413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413) +#3 0x7ff5241b813f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f) +#4 0x7ff523feddb0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 +#5 0x7ff523feddb0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7ff523fd7536 in abort stdlib/abort.c:79:7 +#7 0x7ff523fd740e in __assert_fail_base assert/assert.c:92:3 +#8 0x7ff523fe65b1 in __assert_fail assert/assert.c:101:3 +#9 0x55bd7116c435 in virtio_blk_reset hw/block/virtio-blk.c:917:5 +#10 0x55bd710c94a2 in virtio_reset hw/virtio/virtio.c:2001:9 +#11 0x55bd6ff0e0a5 in virtio_pci_reset hw/virtio/virtio-pci.c:1886:5 +#12 0x55bd6ff10686 in virtio_ioport_write hw/virtio/virtio-pci.c:339:13 +#13 0x55bd6ff10686 in virtio_pci_config_write hw/virtio/virtio-pci.c:456:9 +#14 0x55bd713fd025 in memory_region_write_accessor softmmu/memory.c:491:5 +#15 0x55bd713fca93 in access_with_adjusted_size softmmu/memory.c:552:18 +#16 0x55bd713fc2f0 in memory_region_dispatch_write softmmu/memory.c +#17 0x55bd70e4bf36 in flatview_write_continue softmmu/physmem.c:2759:23 +#18 0x55bd70e41bbb in flatview_write softmmu/physmem.c:2799:14 +#19 0x55bd70e41bbb in address_space_write softmmu/physmem.c:2891:18 +#20 0x55bd71153462 in cpu_outl softmmu/ioport.c:80:5 +#21 0x55bd712d586e in qtest_process_command softmmu/qtest.c:483:13 +#22 0x55bd712d35bf in qtest_process_inbuf softmmu/qtest.c:797:9 +#23 0x55bd712d3315 in qtest_server_inproc_recv softmmu/qtest.c:904:9 +#24 0x55bd71910df8 in qtest_sendf tests/qtest/libqtest.c:438:5 +#25 0x55bd71911fae in qtest_out tests/qtest/libqtest.c:952:5 +#26 0x55bd71911fae in qtest_outl tests/qtest/libqtest.c:968:5 +#27 0x55bd6fcd1aa2 in op_out tests/qtest/fuzz/generic_fuzz.c:395:13 +#28 0x55bd6fcd04e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17 +#29 0x55bd6fcc9723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5 + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28524 + diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1914849 b/results/classifier/deepseek-r1:14b/output/kernel/1914849 new file mode 100644 index 00000000..f1561ecd --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1914849 @@ -0,0 +1,55 @@ + +mprotect fails after MacOS 11.2 on arm mac + +I got the following error when I ran qemu on arm mac(MacOS 11.2). + +``` +$ ./qemu-system-x86_64 +qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied +** +ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +[1] 34898 abort ./qemu-system-x86_64 +``` + +I tested the same version of qemu on intel mac(MacOS 11.2), but it works fine. + +And my friend told me that they did not have this error with MacOS 11.1. + +So, I think it is CPU architecture or an OS version dependent error. + + +Environment: + +Qemu commit id: d0dddab40e472ba62b5f43f11cc7dba085dabe71 +OS: MacOS 11.2(20D64) +Hardware: MacBook Air (M1, 2020) + + +How to build: + +``` +mkdir build/ +cd build/ +../configure --target-list=aarch64-softmmu,x86_64-softmmu +make +``` + + +How to reproduce: + +``` +./qemu-system-x86_64 +``` + + +Error message: + +``` +$ ./qemu-system-x86_64 +qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied +** +ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) +[1] 34898 abort ./qemu-system-x86_64 +``` \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1939179 b/results/classifier/deepseek-r1:14b/output/kernel/1939179 new file mode 100644 index 00000000..31905b27 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1939179 @@ -0,0 +1,22 @@ + +qemu-ga fsfreeze crashes the kernel + +Hello, + +Still required your attention, duplicate from: +https://bugs.launchpad.net/bugs/1807073 +https://bugs.launchpad.net/bugs/1813045 + +We use mainly Cloudlinux, Debian and Centos. +We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot. +The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening: + +When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: +1) freeze loopback fs + ---> send async reqs to loopback thread +2) freeze main fs +3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. + +Moreover, a lot of Proxmox users are complaining about the issue as well: +https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/ +https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/ \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/1946 b/results/classifier/deepseek-r1:14b/output/kernel/1946 new file mode 100644 index 00000000..367e5e97 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/1946 @@ -0,0 +1,29 @@ + +High CPU Load after QEMU 8.1.1 +Description of problem: +Since the update there is a massive CPU load and this affects the CPU load of the router. +The VMs are partially for about 3min sporadically not accessible. +The VMs themselves were not adjusted and I have in the console. + +Using the VMM, I was able to see the message recorded below. + +`watchdog:_ BUG: soft lockup - CPU#0 stuck for 21s! [swapper/0:0]` + +I will also add some data like a XML file of a VM. +Additional information: + +[webproxy.log](/uploads/1d428f4c59b2397b9343a62dd8c4bce2/webproxy.log) + +[webproxy.xml](/uploads/04221c88956c49d76b4896dd8f6fd1f0/webproxy.xml) +[Host_Kernel.log](/uploads/f145bf599bf2003b89c17daaabb07143/Host_Kernel.log) + +Unfortunately I can't revert to the old QEMU version in the router OS but in the current state all my VM are not really 100% usable anymore. + +I would be very grateful if you could take a look at my case. + +many thanks in advance. + + + + +Paul diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2060 b/results/classifier/deepseek-r1:14b/output/kernel/2060 new file mode 100644 index 00000000..f398bb33 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2060 @@ -0,0 +1,4 @@ + +memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set +Additional information: +i'm using pve-qemu-kvm 8.1.2-6 on 6.5.11-7-pve kernel diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2170 b/results/classifier/deepseek-r1:14b/output/kernel/2170 new file mode 100644 index 00000000..0bd02c8a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2170 @@ -0,0 +1,45 @@ + +qemu-x86_64 crashes when the application calls pthread_getattr_np() +Description of problem: +QEMU user emulation crashes with this program: +``` +#define _GNU_SOURCE +#include <stdio.h> +#include <pthread.h> + +int main() +{ + pthread_attr_t attr; + int error = pthread_getattr_np(pthread_self(), &attr); + + printf("%d\n", error); + return 0; +} +``` +Steps to reproduce: +1. Compile the program above +2. Run QEMU +Additional information: +QEMU crashes with: +``` +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault (core dumped) + +``` + +In gdb I get this backtrace: +``` +#0 0x0000555555627d6d in open_self_maps_2 (opaque=0x7fffffffc020, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000055555560ce67 in walk_memory_regions (priv=priv@entry=0x7fffffffc020, fn=fn@entry=0x555555627d30 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x0000555555628b3a in open_self_maps_1 (smaps=<optimized out>, fd=<optimized out>, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x0000555555631e24 in do_guest_openat (cpu_env=cpu_env@entry=0x55555583ae20, dirfd=dirfd@entry=-100, fname=fname@entry=0x2aaaab496eb4 "/proc/self/maps", flags=524288, mode=mode@entry=0, safe=safe@entry=true) at ../linux-user/syscall.c:8381 +#5 0x0000555555638f71 in do_syscall1 (cpu_env=cpu_env@entry=0x55555583ae20, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=46912506523316, arg3=arg3@entry=524288, arg4=arg4@entry=0, arg5=<optimized out>, arg6=<optimized out>, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x000055555563b659 in do_syscall (cpu_env=cpu_env@entry=0x55555583ae20, num=257, arg1=4294967196, arg2=46912506523316, arg3=524288, arg4=0, arg5=8, arg6=1, arg7=0, arg8=0) at ../linux-user/syscall.c:13658 +#7 0x000055555558db19 in cpu_loop (env=env@entry=0x55555583ae20) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x00005555555898d8 in main (argc=<optimized out>, argv=0x7fffffffdd38, envp=<optimized out>) at ../linux-user/main.c:1012 + +``` + +This bug was introduced in the rewrite of `open_self_maps` in 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb. +The current master (5767815218efd3cbfd409505ed824d5f356044ae) is still affected. diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2281 b/results/classifier/deepseek-r1:14b/output/kernel/2281 new file mode 100644 index 00000000..493189a5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2281 @@ -0,0 +1,8 @@ + +[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/results/classifier/deepseek-r1:14b/output/kernel/2284 b/results/classifier/deepseek-r1:14b/output/kernel/2284 new file mode 100644 index 00000000..7986ac71 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2284 @@ -0,0 +1,2 @@ + +sunxi avocado tests: kernel no longer available on armbian diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2384 b/results/classifier/deepseek-r1:14b/output/kernel/2384 new file mode 100644 index 00000000..a9ae4822 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2384 @@ -0,0 +1,27 @@ + +Crash on QEMU 7.2.11 with imx6ul arm cpu cortex-a7 when trying to mount rootfs +Description of problem: +trying to run qemu 7.2.11 for NXP mcimx6ul-evk machine, We get a kernel panic trying to mount the rootfs. +... +[ 7.401206] No soundcards found. +[ 7.500010] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. +[ 7.504607] VFS: Mounted root (vfat filesystem) on device 179:1. +[ 7.511987] devtmpfs: error mounting -2 +[ 7.612562] Freeing unused kernel image (initmem) memory: 1024K +[ 7.638370] Run /sbin/init as init process +[ 7.638829] with arguments: +[ 7.639016] /sbin/init +[ 7.639247] earlyprintk +[ 7.639429] noresume +... +[ 7.657347] Kernel panic - not syncing: No working init found. + +The full log is attached.[qemu_imx6ul_kernel_panic_info.txt](/uploads/c4075a3de7894c18050bf53c32bb18a7/qemu_imx6ul_kernel_panic_info.txt) +Steps to reproduce: +1. download and build qemu 7.2.11 +2. download LF_v6.1.55-2.2.1_images_IMX6UL7D.zip from NXP containing kernel, dtb, rootfs, ...etc binaries +3. To use diskimage as ‘sd’ card , we need to shrink .wic image we got from NXP to fit in 4GB : +./qemu-img resize --shrink imx-image-full.wic 4G +4. invoke the command to run qemu described above. +Additional information: +Any help would be appreciated, if it's not the right forum please advise, thank you. diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2560 b/results/classifier/deepseek-r1:14b/output/kernel/2560 new file mode 100644 index 00000000..5064fce4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2560 @@ -0,0 +1,106 @@ + +Go garbage collector crashes when using qemu-x86_64 on an aarch64 host +Description of problem: +Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something? + +The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`. + +Output from Go when it crashes: + +``` +$ sudo chroot . go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0xa95b29?, 0x797b1e2a383c?}) + runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c +runtime.(*lfstack).push(0x0?, 0xc0005041c0?) + runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45 +runtime.(*spanSetBlockAlloc).free(...) + runtime/mspanset.go:322 +runtime.(*spanSet).reset(0xf46980) + runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219 +runtime.finishsweep_m() + runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd +runtime.gcStart.func2() + runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f +runtime.systemstack(0x0) + runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a +```` +Steps to reproduce: +0. Use an aarch64 host system! + +1. Set up binfmt to use qemu-x86_64: + +``` +$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 +enabled +interpreter /usr/bin/qemu-x86_64 +flags: OCF +offset 0 +magic 7f454c4602010100000000000000000002003e00 +mask fffffffffffefe00fffffffffffffffffeffffff +``` + +2. Download/extract x86_64 rootfs: + +``` +$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz +``` + +3. Create example app in the x86_64 rootfs: + +``` +package main + +func main() { +} +``` + +4. Build using chroot: + +``` +$ sudo chroot /path/to/x86_64/rootfs apk add go +$ sudo chroot /path/to/x86_64/rootfs go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push +... +``` + +5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU: + +``` +$ sudo chroot . env GOGC=off go build main.go +# might have to mount /dev to build successfully, but Go doesn't panic! +``` +Additional information: +I've bisected this exact crash/failure to: + +``` +commit 2952b642a555207748dd961fcbfdc48f198eebb6 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Feb 13 10:20:27 2024 -1000 + + linux-user: Split out do_munmap + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +Though a different crash starts happening at the commit before that one: + +``` +commit ad87d26e6bb13257409f412224c862fc54025e8b +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jan 2 12:57:55 2024 +1100 + + linux-user: Do early mmap placement only for reserved_va + + For reserved_va, place all non-fixed maps then proceed + as for MAP_FIXED. + + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +FYI @rth7680 diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2657 b/results/classifier/deepseek-r1:14b/output/kernel/2657 new file mode 100644 index 00000000..4d4bf815 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2657 @@ -0,0 +1,12 @@ + +Kernel crashed when installing OpenServer 6 D2M2a +Description of problem: +The kernel crashed when finishing installation. +Steps to reproduce: +1. Download OpenServer6D2M2a-DVD.iso for free from Xinuos website(a free account is needed, but the registation is easy to be done) +2. Create new virtual hard drive +3. Boot the installation ISO +4. Install with all default settings and all packages, evaluate license is okay. +5. Boom! +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2770 b/results/classifier/deepseek-r1:14b/output/kernel/2770 new file mode 100644 index 00000000..6ba04395 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2770 @@ -0,0 +1,15 @@ + +Build failure due to missing keyctl_pkey_encrypt +Description of problem: + +Steps to reproduce: +1. git checkout v7.2.0 +2. ./configure --target-list=arm-softmmu;make +3. ../backends/cryptodev-lkcf.c: In function ‘cryptodev_lkcf_execute_task’: +../backends/cryptodev-lkcf.c:358:19: error: implicit declaration of function ‘keyctl_pkey_encrypt’; did you mean ‘keyctl_reject’? [-Werror=implicit-function-declaration] + ret = keyctl_pkey_encrypt(key_id, op_desc, + ^~~~~~~~~~~~~~~~~~~ + keyctl_reject +../backends/cryptodev-lkcf.c:358:19: error: nested extern declaration of ‘keyctl_pkey_encrypt’ [-Werror=nested-externs] +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2846 b/results/classifier/deepseek-r1:14b/output/kernel/2846 new file mode 100644 index 00000000..c8756401 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2846 @@ -0,0 +1,2 @@ + +linux-user hangs if fd_trans_lock is held during fork diff --git a/results/classifier/deepseek-r1:14b/output/kernel/2978 b/results/classifier/deepseek-r1:14b/output/kernel/2978 new file mode 100644 index 00000000..8b9c7c7e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/2978 @@ -0,0 +1,24 @@ + +Qemu assertion issue +Description of problem: +This issue is **not caused by my OS**, as it runs perfectly under VMware and other emulators. + +However, when using QEMU, the emulator sometimes randomly **crashes or aborts** during boot or early execution. The crash is **inconsistent** — sometimes it runs, sometimes it fails immediately. + +QEMU fails with an **assertion failure** in `qemu_mutex_lock_iothread_impl` +Steps to reproduce: +Unfortunately, I do not know exactly what causes this issue. It may be specific to my system or configuration. + +1. +2. +Additional information: +Qemu stdout: + +``` +ERROR:system/cpus.c:504:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) Bail out! ERROR:system/cpus.c:504:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) ./run: line 3: 3544 Aborted (core dumped) +``` + +Command line: +``` + qemu-system-x86_64 -debugcon file:OxizeOS.log -drive file=output/OxizeOS.hdd,format=raw -serial stdio +``` diff --git a/results/classifier/deepseek-r1:14b/output/kernel/448 b/results/classifier/deepseek-r1:14b/output/kernel/448 new file mode 100644 index 00000000..5da652ab --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/448 @@ -0,0 +1,2 @@ + +raspi0 machine leads to kernel panic of latest raspberry pi os kernel diff --git a/results/classifier/deepseek-r1:14b/output/kernel/496 b/results/classifier/deepseek-r1:14b/output/kernel/496 new file mode 100644 index 00000000..c3338b91 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/496 @@ -0,0 +1,14 @@ + +qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed +Description of problem: +When I use qemu-system-aarch64 start a Debian(ARM64) on a mips64el host(ARM64 and X86_64 host don't have this bug), I get a bug as follows: + + +`qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed` + + +The crash code is in ../accel/tcg/cpu-exec.c:681, the code in qemu v5.2.0 as follows: + + +``` +# diff --git a/results/classifier/deepseek-r1:14b/output/kernel/546458 b/results/classifier/deepseek-r1:14b/output/kernel/546458 new file mode 100644 index 00000000..e267b04d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/546458 @@ -0,0 +1,48 @@ + +kernel NULL pointer in -virtual (-server) kernel + +When stress testing eucalyptus we have run into this oops inside VMs +[ 82.907577] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358^M +[ 82.908842] IP: [<ffffffff813982e8>] sym_int_sir+0x2a8/0x750^M +[ 82.909773] PGD 0 ^M +[ 82.910110] Thread overran stack, or stack corrupted^M +[ 82.910870] Oops: 0000 [#1] SMP ^M +[ 82.911407] last sysfs file: /sys/devices/virtual/block/ram9/uevent^M + +We launched 18 instances, 2 of them failed this way. The instances run with 192M of memory. With 6 VM launches on a single node all at the same time the host is under heavy load. + +This occurred in 20100323 lucid x86_64 uec-image instance. + +ProblemType: Bug +AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory +AplayDevices: Error: [Errno 2] No such file or directory +Architecture: amd64 +ArecordDevices: Error: [Errno 2] No such file or directory +CurrentDmesg: + +Date: Wed Mar 24 22:06:32 2010 +DistroRelease: Ubuntu 10.04 +Frequency: Once a day. +Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +MachineType: Bochs Bochs +Package: linux-image-2.6.32-16-virtual 2.6.32-16.25 +PciMultimedia: + +ProcCmdLine: root=/dev/sda1 console=ttyS0 +ProcEnviron: + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: User Name 2.6.32-16.25-server +Regression: No +Reproducible: No +SourcePackage: linux +TestedUpstream: No +Uname: Linux 2.6.32-16-server x86_64 +dmi.bios.date: 01/01/2007 +dmi.bios.vendor: Bochs +dmi.bios.version: Bochs +dmi.chassis.type: 1 +dmi.chassis.vendor: Bochs +dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: +dmi.product.name: Bochs +dmi.sys.vendor: Bochs \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/61 b/results/classifier/deepseek-r1:14b/output/kernel/61 new file mode 100644 index 00000000..a3d3e667 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/61 @@ -0,0 +1,2 @@ + +qemu-system-arm segfaults while servicing SYS_HEAPINFO diff --git a/results/classifier/deepseek-r1:14b/output/kernel/690 b/results/classifier/deepseek-r1:14b/output/kernel/690 new file mode 100644 index 00000000..18828678 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/690 @@ -0,0 +1,20 @@ + +32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error) +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago. + +Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters. + +The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value: +``` +[0 ... 53248] - No error at all +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted +``` +Steps to reproduce: +1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz) +2. `$ make # will build the docker container` +3. `$ make run # will enter the container` +4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh` +Additional information: +A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748 diff --git a/results/classifier/deepseek-r1:14b/output/kernel/812398 b/results/classifier/deepseek-r1:14b/output/kernel/812398 new file mode 100644 index 00000000..03b5cb4e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/812398 @@ -0,0 +1,12 @@ + +powerpc 7450 MMU initialization broken + +The 7540 family of PPCs' MMU can update TLBs using hardware search (like a 604 or 7400) but also using a software algorithm. The mechanism used is defined by HID0[STEN]. + +By default (CPU reset) HID0 is set to 0x80000000 (BTW; another small bug, qemu doesn't set the hardwired MSB), hence +the software-table lookup feature is *disabled*. However, the default (and immutable) 'mmu_model' for this CPU family is POWERC_MMU_SOFT_74XX which choses the soft TLB replacement scheme. + +To fix this: + +1) the initial mmu_model for the 7450 family (includes 7441, 7445, 7451, 7455, 7457, 7447, 7448) should be: POWERPC_MMU_32B +2) when HID0[STEN] is written then the mmu_model should be changed accordingly (I'm not familiar enough with the qemu internal state to judge if any cached state would have to be updated). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/842 b/results/classifier/deepseek-r1:14b/output/kernel/842 new file mode 100644 index 00000000..07bf66f3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/842 @@ -0,0 +1,14 @@ + +ppc64: hard lockup / hang in Linux kernel v5.17-rc1 +Description of problem: +The kernel deterministically triggers a hard lockup / hang under QEMU since v5.17-rc1 (upgrading from v5.16). + +Bisecting points to the kernel's [0faf20a1ad16](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0faf20a1ad1647c0fc0f5a367c71e5e84deaf899) ("powerpc/64s/interrupt: Don't enable MSR[EE] in irq handlers unless perf is in use"). Reverting it on top of v5.17-rc1 fixes the issue. + +Reported to [linuxppc-dev](https://lore.kernel.org/linuxppc-dev/CANiq72n_FmDx=r-o9J8gYc6LpwRL5EGmhM6Xzwv27Xc7h1TNDw@mail.gmail.com/). Confirmed. Suspected QEMU modeling issue by Cédric Le Goater. +Steps to reproduce: +1. Build kernel v5.17-rc1 or commit 0faf20a1ad16 for ppc64le with the attached config (either GCC or Clang). +2. Run it under QEMU with at least `-smp 2`. +Additional information: +[qemu-and-dmesg.log](/uploads/7cb5ce1cb70e06262800c16f4c800157/qemu-and-dmesg.log) +[kernel.config](/uploads/327e9cec48a731abc9e44cb40db67de9/kernel.config) diff --git a/results/classifier/deepseek-r1:14b/output/kernel/854 b/results/classifier/deepseek-r1:14b/output/kernel/854 new file mode 100644 index 00000000..343ee854 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/854 @@ -0,0 +1,63 @@ + +rsync to ext4-fs on dynamic expanding qcow2 fails +Description of problem: +Firstly, this issue does not seem to happen when the virtual-disk is dd-raw-img or fixed qcow2 (preallocation=falloc). The guest-kernel has multiple tracebacks during rsync to dst folder on ext4-fs on qcow2. +I ctrl-C-ed the rsync process after the first traceback, which happened after copying around 52 GiB. +On a previous run, wherein I had let it continue, somewhere near the end, around 83 GiB, dmesg would bloat with a zillion trace-backs and stall. The sha256sum verify seems to have succeeded for all files copied so far and correctly gives error "Failed open or read" on subsequent files that were not copied. +In this test, the partial-rsync completed files were not corrupted. However, as qemu's disk emulation allocates blocks, qemu may be inducing paging-bugs into the guest-kernel. Paging issues like these may also lead to corruption. The guest-kernel should see the same full emulated disk regardless of whether qemu provided a fixed disk, dynamic disk, or even a different type of virtual-disk-format. The guest-vm should not detect/perceive any difference between them. + +There may be upcoming trouble round the 5.17 corner. + +It is beyond me to figure out if this is due to +* qemu-6.2 block code +* guest-kernel ( kernel-5.17 folio/page management or ntfs3 driver or something else ) + +It may be necessary to ascertain if this is a new bug on account of qemu not being ready for folio type page-management or a bug in upstream kernel.org. My apologies in advance if it turns out that this is not a qemu bug. + +There there does seem to be some problem with qemu dealing with expanding virtual disks, with bugs that show up only if the underlying virtual-disk is dynamic and expanding. + +I just think that storage/block-code should be made rock solid with a much higher priority than adding new features. +If storage code is undependable, then qemu/vm cannot be used, and there is no point in any other feature. qcow2 in particular is the qemu's native virtual-disk format. + +I had to stop testing on Issue #727 , Issue #814 , on account of what I thought was a bug in 5.15 kernels. I filed the bug as "fs/ntfs3: page_cache_ra_unbounded on rsync from ntfs3 to ext4" https://bugzilla.kernel.org/show_bug.cgi?id=215460 . I assume that bug is different because it happens even on raw image. + +setup is as follows: +- Host: Fedora-35 with kernel-5.17.0-0.rc2.83.fc35.x86_64 self-built from srpm ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910212 ) +- Guest: Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso with 5.17.0-0.rc2.83.fc36.x86_64 ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910892 ) +- qemu: 6.2.0 (qemu-6.2.0-2.fc35.1) self-built from srpm ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1897713 ) +- hda: qcow2(dyn) with ext4 and also 4 combinations of raw_img/fixed_qcow2 with ext4/ntfs3 +- hdb: vhdx, ntfs3 (pre-prepared sgdata https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 ) + +qcow2 image is created as follows: +``` +[root@sirius ~]# qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 +Formatting '/mnt/a16/gkpics01.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=99723771904 lazy_refcounts=off refcount_bits=16 +``` + +qemu command is as follows: +``` +[root@sirius ~]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso" -hda "/mnt/a16/gkpics01.raw" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" +``` +Steps to reproduce: +1. Inside booted vm, use gdisk to partition /dev/sda1 if necessary +2. ```dmesg -w (in another pty)``` +3. ```mkfs.ext4 /dev/sda1 -L fs_gkpics001``` +4. ```mkdir /mnt/a /mnt/b``` +5. ```mount -t ext4 /dev/sda1 /mnt/a``` +6. ```mount -t ntfs3 /dev/sdb2 /mnt/b``` +7. rsync testdata: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo "$sdate" ; date )``` +8. ```umount /mnt/a ; ``` +9. ```mount -t ext4 /dev/sda1 /mnt/a``` +10. verify: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/a/photos001 ; sha256sum -c ./find.CHECKSUM --quiet ; echo "$sdate" ; date )``` +11. ```umount /mnt/a ; umount /mnt/b;``` +Additional information: +**Test attempts** +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ext4 with vhdx/ntfs3/sgdata +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ntfs3 with vhdx/ntfs3/sgdata +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ext4 with vhdx/ntfs3/sgdata +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ntfs3 with vhdx/ntfs3/sgdata +- Bug **does** happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/**qcow2(dyn)**/ext4 with vhdx/ntfs3/sgdata +- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ExFat with ntfs3/sgdata +- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ntfs3 with ntfs3/sgdata + +Also filed a linux-kernel bug titled "during rsync, vm guest kernel trace arising from memcg_kmem_charge_page alloc_pages" https://bugzilla.kernel.org/show_bug.cgi?id=215563 diff --git a/results/classifier/deepseek-r1:14b/output/kernel/864 b/results/classifier/deepseek-r1:14b/output/kernel/864 new file mode 100644 index 00000000..ca986b2a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/864 @@ -0,0 +1,16 @@ + +HVF virtual counter diverges from CLOCK_VIRTUAL when the host sleeps +Description of problem: +HVF's virtual counter diverges from `CLOCK_VIRTUAL` when the host sleeps and causes the inconsistency between Linux's system counter and everything else. + +HVF's virtual counter apparently relies on something similar to `mach_absolute_time`, which stops when the host sleeps and resumes after it wakes up. However, `CLOCK_VIRTUAL` is implemented with `mach_continuous_time`, which continues even while the host sleeps. Linux uses the virtual counter as the source of the system counter and sees inconsistencies between the system counter and the other devices. +Steps to reproduce: +1. Launch Fedora. +2. Compare the time shown at the top of the guest display and one at the top of the host display. The difference should be less than 2 minutes. +3. Let the host sleep for 3 minutes. +4. Compare the times again. The difference is now greater than 2 minutes. +Additional information: +Here are solutions I've came up with so far. There are trade-offs but any of them should be better than the current situation. I'm happy to implement one if the maintainers have decided which one is the best or figure out a superior alternative. +- Implement `cpus_get_virtual_clock` of `AccelOpsClass` with `mach_absolute_time`. It would make HVF inconsistent with the other accelerators. Linux also expects the virtual clock is "continuous" and it leaves the divergence from the real time. +- Request XNU `HOST_NOTIFY_CALENDAR_CHANGE` to update the virtual clock with the continuous time. The interface is undocumented. +- Use `IORegisterForSystemPower` to update the virtual clock with the continuous time. It is undocumented that the interface handles every cases where `mach_absolute_time` and `mach_continuous_time`, but it actually does if I read XNU's source code correctly. diff --git a/results/classifier/deepseek-r1:14b/output/kernel/891002 b/results/classifier/deepseek-r1:14b/output/kernel/891002 new file mode 100644 index 00000000..38678057 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/891002 @@ -0,0 +1,5 @@ + +windows mingw compiled qemu-system-x86_64 crash on startup + +qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +$3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/kernel/943 b/results/classifier/deepseek-r1:14b/output/kernel/943 new file mode 100644 index 00000000..5282de82 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/943 @@ -0,0 +1,2 @@ + +Calling get-fsinfo on a virtual machine does not include ZFS (zfsonlinux, debian guest tested) volumes diff --git a/results/classifier/deepseek-r1:14b/output/kernel/95 b/results/classifier/deepseek-r1:14b/output/kernel/95 new file mode 100644 index 00000000..9a670b7c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/kernel/95 @@ -0,0 +1,2 @@ + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) |