diff options
Diffstat (limited to '')
22 files changed, 1398 insertions, 0 deletions
diff --git a/results/classifier/108/other/109 b/results/classifier/108/other/109 new file mode 100644 index 00000000..95d5e2e4 --- /dev/null +++ b/results/classifier/108/other/109 @@ -0,0 +1,16 @@ +device: 0.687 +network: 0.509 +permissions: 0.488 +performance: 0.450 +semantic: 0.372 +KVM: 0.369 +PID: 0.362 +boot: 0.307 +vnc: 0.270 +files: 0.224 +socket: 0.211 +debug: 0.204 +other: 0.201 +graphic: 0.153 + +Make Uninstall Rule Requested diff --git a/results/classifier/108/other/1090 b/results/classifier/108/other/1090 new file mode 100644 index 00000000..6b5cda01 --- /dev/null +++ b/results/classifier/108/other/1090 @@ -0,0 +1,30 @@ +socket: 0.913 +device: 0.830 +graphic: 0.742 +network: 0.565 +PID: 0.471 +debug: 0.436 +semantic: 0.298 +performance: 0.168 +boot: 0.144 +KVM: 0.101 +vnc: 0.065 +other: 0.058 +permissions: 0.050 +files: 0.008 + +can't create rocker device because setting device array properties on the command line is broken +Description of problem: +it does not accept the prop_array parameter: + +``` +qemu-system-x86_64 -enable-kvm -m 1g -cpu host -netdev socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0 +qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found +``` +Steps to reproduce: +1. just run the command +Additional information: +the latest qemu i find working is 6.1.1... if you start a fedora vm and `dnf install kernel-modules-internal` then the rocker ports appear and work properly... + +thanks, +cs diff --git a/results/classifier/108/other/1090558 b/results/classifier/108/other/1090558 new file mode 100644 index 00000000..8c0073e2 --- /dev/null +++ b/results/classifier/108/other/1090558 @@ -0,0 +1,29 @@ +device: 0.815 +socket: 0.807 +vnc: 0.780 +network: 0.752 +graphic: 0.670 +files: 0.568 +boot: 0.509 +semantic: 0.472 +debug: 0.452 +performance: 0.408 +PID: 0.327 +permissions: 0.309 +other: 0.282 +KVM: 0.026 + +hw/mc146818: error reading RTC_HOURS_ALARM + +get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly. + +- Bit 7 must be masked before conversion from BCD. +- Care must be taken to check the don't care condition before masking. +- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done in convert_hour()). + +Seen in commit e376a788ae130454ad5e797f60cb70d0308babb6. + +The problem is obviously there, but I tried pretty hard to make it fail and couldn't so it seems latent. If you can, please provide a patch to tests/rtc-test.c that shows the bug. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1090602 b/results/classifier/108/other/1090602 new file mode 100644 index 00000000..5cf75852 --- /dev/null +++ b/results/classifier/108/other/1090602 @@ -0,0 +1,33 @@ +device: 0.919 +graphic: 0.780 +network: 0.658 +other: 0.649 +socket: 0.637 +files: 0.623 +semantic: 0.617 +permissions: 0.594 +performance: 0.556 +vnc: 0.549 +debug: 0.525 +PID: 0.505 +boot: 0.430 +KVM: 0.408 + +RFE: Allow specifying usb-host device by serial number + +Currently you can pass through a host USB device to the guest like + + -device usb-host,vendorid=0x1234,productid=0x5678 + +Which is all well and good, but has problems if you are trying to assign to identical USB devices to the same guest. + +It would be useful if there was an additional option that allow matching against the device's serial number, which should allow differentiating between two devices with the same product+vendor. + +This was originally filed at https://bugzilla.redhat.com/show_bug.cgi?id=640332 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1090604 b/results/classifier/108/other/1090604 new file mode 100644 index 00000000..2af7ed92 --- /dev/null +++ b/results/classifier/108/other/1090604 @@ -0,0 +1,39 @@ +device: 0.638 +other: 0.603 +network: 0.495 +semantic: 0.495 +graphic: 0.489 +socket: 0.470 +vnc: 0.432 +permissions: 0.406 +performance: 0.374 +files: 0.352 +boot: 0.297 +PID: 0.259 +debug: 0.222 +KVM: 0.190 + +RFE: Implement support for SMBIOS Type 41 structures + +This was originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=669955 + +""" +Please extend the existing support for SMBIOS in qemu to add a capability to provide "Onboard Devices Extended Information" (Type 41). Not only is this replacing one of the existing types, but it also provides a mapping between devices and physical system chassis locations. But there is no physical chassis! Right. However, this doesn't mean you don't want to tell the guest OS which virtual (e.g. network) interface is which. You can do that, if you implement this extension that is already going into real hardware, and likely other VMs too. + +See also page 117 of the v2.7 of the SMBIOS spec. + +FWIW, VMware ESX and Workstation expose their PCI NICs in the PCI IRQ Routing Table. Kind of odd the first time you see it with biosdevname, as your NIC becomes pci3#1, but that's "correct" from a BIOS perspective. :-) +""" + +Hello, I'm intersted in this bug fix and have some free time. maybe I can do this bug-fix. + +I have sent a first patch around this: https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09391.html + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/91 + + diff --git a/results/classifier/108/other/1090615 b/results/classifier/108/other/1090615 new file mode 100644 index 00000000..d363fa41 --- /dev/null +++ b/results/classifier/108/other/1090615 @@ -0,0 +1,45 @@ +graphic: 0.903 +device: 0.857 +semantic: 0.732 +other: 0.721 +vnc: 0.710 +network: 0.677 +PID: 0.631 +files: 0.568 +performance: 0.558 +socket: 0.517 +boot: 0.447 +debug: 0.386 +permissions: 0.279 +KVM: 0.019 + + RFE: More info in qemu-img info/check + +Originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=861375 + +""" +qemu-img info currently give me info like this: + +image: /home/alex/.local/share/gnome-boxes/images/Fedora 16 +file format: qcow2 +virtual size: 11G (11794287616 bytes) +disk size: 4.5G +cluster_size: 65536 + +In order to figure out the "health" of an image there is some more information I would like: + +in-use disk size - I.e the subset of disk size that is not marked as unused due to e.g. TRIM operations + +amount of compressed clusters. I.e. "is it useful to re-compress the image". + +Fragmentation estimation. + +This would be useful to both sysadmins in general and for automated things like +what we want to do in gnome-boxes: +https://bugzilla.gnome.org/show_bug.cgi?id=685032 +""" + +As mentioned in the original report, qemu-img check currently has fragmentation stats, but only for QED. + +qemu-img check has reported allocated clusters, compressed clusters and fragmentation for qcow2 images since February 2013 (QEMU 1.5). + diff --git a/results/classifier/108/other/1090726 b/results/classifier/108/other/1090726 new file mode 100644 index 00000000..21dd8dea --- /dev/null +++ b/results/classifier/108/other/1090726 @@ -0,0 +1,70 @@ +other: 0.621 +graphic: 0.591 +permissions: 0.523 +device: 0.454 +semantic: 0.443 +PID: 0.442 +KVM: 0.441 +debug: 0.398 +performance: 0.396 +vnc: 0.393 +socket: 0.387 +files: 0.376 +boot: 0.361 +network: 0.344 + +qemu does not generate guest cpu topology properly + +Adding the option + +-smp 12,sockets=2,cores=6,threads=1 + +exposes + + +Machine (12GB) + Socket #0 + L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0) + L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1) + L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2) + L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3) + L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4) + L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5) + L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6) + L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7) + Socket #1 + L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8) + L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9) + L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10) + L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11) + + +Rather than: + +Machine (12GB) + Socket #0 + L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0) + L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1) + L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2) + L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3) + L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4) + L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5) + Socket #1 + L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6) + L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7) + L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8) + L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9) + L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10) + L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11) + + +Here is a cpuid dump from inside the guest and dump from more recent version of cpuid, in which you can see a bit more detail. The later contains data for a single CPU, because the others are the same. + +Reproducible on qemu 1.0 and 1.2. with guest os Fedora 17, Debian 6, Debian Squeeze and Windows 2008 R2. + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1090837 b/results/classifier/108/other/1090837 new file mode 100644 index 00000000..2ebf2162 --- /dev/null +++ b/results/classifier/108/other/1090837 @@ -0,0 +1,53 @@ +other: 0.714 +debug: 0.690 +device: 0.683 +semantic: 0.642 +permissions: 0.615 +performance: 0.531 +PID: 0.513 +socket: 0.502 +graphic: 0.499 +vnc: 0.493 +network: 0.474 +boot: 0.388 +files: 0.374 +KVM: 0.283 + +Error in building Qemu-1.3.0 on Solaris 10 + +While trying to build Qemu on Oracle Solaris 10 (SPARC processor), I encountered the following error in the configure step: + +./configure --prefix=/usr/local/ --install=/usr/ucb/install +./configure: bad substitution +./configure: !: not found +./configure: !: not found +./configure: !: not found +./configure: !: not found +./configure: !: not found +./configure: curl-config: not found +./configure: curl-config: not found + +As the following bug report says: https://bugs.launchpad.net/qemu/+bug/636315, "sh" is hard-coded in the script. Can't the script be modified to accept a $SHELL argument to make use of bash or other shell during configure and make step? + +Are you using /bin/sh (broken) or /usr/xpg4/bin/sh (should work)? + +If I invoke /usr/xpg4/bin/sh from bash and then start the build process, will it be OK/ Or do I need to add /usr/xpg4/bin/sh to PATH? Does the patch mentioned in the referred bug need to be applied? + +Just using $SHELL inside configure would be insufficient if run via Solaris' sh. +Using `bash ./configure ...` should've worked for v1.2 without patches, didn't test v1.3 on Sol10 yet. + +Whether the DTrace support scripts fully work on Solaris 10 is another issue. + +Until tomorrow, I can't report back as the Solaris 10 system is in my workplace. What I tried was to trigger ./configure from bash shell which produced the log above and aborted. As the title already says, I tried to build Qemu 1.3.0. + +P.S. If I already use bash shell to invoke the script, do I need to `bash ./configure ...` any more? + +Yes, if you execute `./configure ...` the shell will execute the shebang line inside the script, which says /bin/sh and happens to be a really ancient version for backwards compatibility on Solaris. + +I did the following and it was a success: + +1. Added sh to path to override default /usr/bin/sh: PATH=/usr/xpg4/bin/sh:$PATH +2. From bash: sh ./configure + +Closing, as there is a work-around according to comment #6 + diff --git a/results/classifier/108/other/1091 b/results/classifier/108/other/1091 new file mode 100644 index 00000000..5a2fc67b --- /dev/null +++ b/results/classifier/108/other/1091 @@ -0,0 +1,28 @@ +device: 0.883 +graphic: 0.824 +performance: 0.652 +vnc: 0.407 +debug: 0.397 +semantic: 0.354 +PID: 0.334 +boot: 0.271 +permissions: 0.201 +KVM: 0.187 +network: 0.181 +files: 0.158 +socket: 0.122 +other: 0.097 + +qemu-system-x86_64 hard crashes when using `--accel hvf` on intel Mac +Description of problem: +The QEMU process hard crashes after a few minutes. The only message is: + +``` +vmx_write_mem: mmu_gva_to_gpa ffff990489fa0000 failed +``` +Steps to reproduce: +1. Run QEMU with the above commandline +2. Do something to keep the VM busy - running `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` reliably crashes it for me +3. Wait a 3-5 minutes +Additional information: + diff --git a/results/classifier/108/other/1092 b/results/classifier/108/other/1092 new file mode 100644 index 00000000..10e6ebc9 --- /dev/null +++ b/results/classifier/108/other/1092 @@ -0,0 +1,29 @@ +device: 0.801 +graphic: 0.636 +files: 0.616 +semantic: 0.492 +network: 0.383 +other: 0.340 +vnc: 0.339 +boot: 0.313 +socket: 0.296 +PID: 0.178 +debug: 0.164 +permissions: 0.137 +performance: 0.133 +KVM: 0.030 + +PPC: `sraw` instructions does not set `ca` and `ca32` flags. +Description of problem: +The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to +[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should. +Additional information: +This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`). + +**sraw** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914 + +**srawi** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924 diff --git a/results/classifier/108/other/1093 b/results/classifier/108/other/1093 new file mode 100644 index 00000000..0712206e --- /dev/null +++ b/results/classifier/108/other/1093 @@ -0,0 +1,48 @@ +graphic: 0.780 +device: 0.675 +performance: 0.656 +files: 0.642 +vnc: 0.406 +network: 0.394 +semantic: 0.378 +socket: 0.365 +other: 0.316 +permissions: 0.306 +PID: 0.291 +boot: 0.281 +debug: 0.210 +KVM: 0.113 + +RISC-V: signal frame is misaligned in signal handlers +Description of problem: +`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan. +Steps to reproduce: +1. Create a C file with the following contents: +```c +#include <signal.h> +#include <stdio.h> + +void handler(int sig, siginfo_t *info, void *context) { + printf("signal occurred, info: %p, context: %p\n", info, context); +} + +int main() { + struct sigaction act; + act.sa_flags = SA_SIGINFO; + act.sa_sigaction = handler; + sigaction(SIGINT, &act, NULL); + + // Deliberately misalign the stack + asm volatile ("addi sp, sp, -4"); + + while(1); + // Unreachable +} +``` +2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`. +3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned: +``` +signal occurred, info: 0x400080025c, context: 0x40008002dc +``` +Additional information: +This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15. diff --git a/results/classifier/108/other/1093691 b/results/classifier/108/other/1093691 new file mode 100644 index 00000000..095f2675 --- /dev/null +++ b/results/classifier/108/other/1093691 @@ -0,0 +1,88 @@ +graphic: 0.699 +other: 0.661 +semantic: 0.596 +files: 0.566 +network: 0.565 +permissions: 0.543 +performance: 0.525 +PID: 0.511 +boot: 0.501 +socket: 0.492 +device: 0.492 +KVM: 0.485 +debug: 0.485 +vnc: 0.378 + +QEMU build fails on OpenBSD/mips64 + +Building QEMU 1.2.1 on OpenBSD/mips64 fails as follows although I believe QEMU was also broken with 1.1.x as well.. + +cc -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/slirp -I. -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1 -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/fpu -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg - +I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/mips -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmis +sing-prototypes -fno-strict-aliasing -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -DTIME_MAX=INT_MAX -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wf +ormat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/usr/obj/ports/qemu-1 +.2.1/qemu-1.2.1/target-i386 -DNEED_CPU_H -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/gli +b-2.0/include -I/usr/local/include -MMD -MP -MT tcg/tcg.o -MF tcg/tcg.d -O2 -pipe -c -o tcg/tcg.o /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c +In file included from /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c:50: +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_div_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: (Each undeclared identifier is reported only once +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: for each function it appears in.) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1231: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_rem_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1248: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1250: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_divu_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1267: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1269: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_remu_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1286: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1288: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext8s_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1526: error: 'TCG_TARGET_HAS_ext8s_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext16s_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1536: error: 'TCG_TARGET_HAS_ext16s_i64' undeclared (first use in this function) +... + +Attached is the full build log. + + + +On Wed, Dec 26, 2012 at 09:55:38AM -0800, Richard Henderson wrote: +> On 12/25/2012 01:12 PM, Brad Smith wrote: +> > Public bug reported: +> > +> > Building QEMU 1.2.1 on OpenBSD/mips64 fails as follows although I +> > believe QEMU was also broken with 1.1.x as well.. +> ... +> > In file included from /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c:50: +> > /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_div_i64': +> > /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +> +> The tcg/mips target only supports mips32. +> +> In order to build on mips64 you'll need to use the interpreter backend, +> configurable with --enable-tcg-interpreter. +> +> We could be more clever and enable this by default for mips64... + +Strange. It was building with older releases and I'm fairly certain what +was built actually ran Ok. Looking at the MIPS TCG code it looks as if +there is some code in there to deal with 32-bit vs 64-bit MIPS. + +Anyway, if the MIPS TCG code does not officially support 64-bit MIPS +then the build infrastructure should be fixed to not shoot people in +the feet trying to build QEMU. The 32-bit SPARC support needs to be +fixed too. + +-- +This message has been scanned for viruses and +dangerous content by MailScanner, and is +believed to be clean. + + + +Triaging old bug tickets ... does this problem still persist with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1094564 b/results/classifier/108/other/1094564 new file mode 100644 index 00000000..99d724b2 --- /dev/null +++ b/results/classifier/108/other/1094564 @@ -0,0 +1,369 @@ +debug: 0.866 +permissions: 0.845 +semantic: 0.818 +graphic: 0.806 +performance: 0.792 +boot: 0.784 +other: 0.778 +network: 0.775 +device: 0.766 +PID: 0.754 +files: 0.715 +vnc: 0.712 +socket: 0.665 +KVM: 0.521 + +images used as scsi disks not readable (qemu-system-arm, macos 10.8) + +Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my disk, I get as far as mounting root and then get SCSI errors with 1.3.0 and the current origin/master. git bisect says the issue is + +commit f563a5d7a820424756f358e747238f03e866838a +Merge: a273652 aee0bf7 +Author: Paolo Bonzini <email address hidden> +Date: Wed Oct 31 10:42:51 2012 +0100 + + Merge remote-tracking branch 'origin/master' into threadpool + + Signed-off-by: Paolo Bonzini <email address hidden> + + +I am using: +qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 + +Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: +CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu + +I duplicated this as well. I tried both the qemu-system-arm available in macports and also from homebrew with the same results. Host system is also 10.8 "mountain lion". + +My boot command: qemu-system-arm -kernel kernel/zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1" -hda pifi-4g.img -redir tcp:5022::22 + +I'm running QEMU emulator version 1.4.1 on OS X 10.8.3 +Interestingly, this exact same boot command works perfectly on my Ubuntu virtual (in virtualbox) running QEMU emulator version 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) + +So the bug would seem to either be specific to OS X or to the 1.4.1 release. + +See the attached screenshot to see what happens in the boot process. + +I managed to capture a little more info about this bug by passing -drive file='myharddrive.img'. The kernel panic is happening in the sym53c8xx driver. See the attached screenshot for detail. + +I can also attach the kernel that I'm using if needed. Just let me know. + + +I suspect this may be because we were defaulting to a broken coroutine backend (a bug fixed with commit 7c2acc7). Can you retry with the current 1.5 release candidate? (source download available at http://wiki.qemu.org/Download) + + +Hi Peter, + +Thanks, that made an improvement. Now I'm just stuck in a loop of the kernel resetting the scsi bus :) + +(see attachment) + +And the same QEMU/kernel/image works fine on a Linux host? + +If you can provide the files I need to reproduce I might be able to take a look at it. (If it did the same thing on linux host that would be higher priority for me, so if you can cross-check that would be helpful.) + + +I just compiled 1.5.0-rc1 on my Linux host with the same configure/compiler flags and duplicated the error (see screenshot). The configure flags are: +./configure --disable-guest-agent --disable-bsd-user --enable-sdl --target-list="arm-linux-user armeb-linux-user arm-softmmu" + +As before, it goes into an infinite loop of reseting the scsi controller for each (emulated) channel. Note that the Ubuntu provided qemu-system-arm works perfectly. They are using 1.4.0 with a rather large number of patches ( I did a `dpkg source qemu` to examine the Ubuntu build setup). + +Looking through the Ubuntu patches, this one looks like a likely fix: +dpkg-source: info: applying patches-arm-1.4.0/0002-hw-sd-Expose-sd_reset-as-public-function.patch + +Please find a zip of my raspberrypi image (hda) and the kernel that I built from https://github.com/raspberrypi/linux.git +at https://www.dropbox.com/sh/mbz8jh4fcjvdj4m/Gh3bKFyJyC + +I included the boot command in a txt file in the tarball. + +cheers, +Joss + + + +It's very unlikely to be the patch you mention, since that's for SD card emulation and you're not using SD card emulation. It's probably just a regression between 1.4 and 1.5, and I'm fairly sure it's in some changes I made to the versatilepb PCI controller model -- I will investigate. + + +Ah, I interpreted it to mean "scsi disk" instead of SD card :) + +I'll leave this to the experts. Thanks so much for looking into this and please let me know if I can be of further assistance. + +-Joss + +Hi Peter, + +Thanks so much for the patch and including me on the thread. I can confirm that it did fix the problem running on a Linux host, but the OS X bug cited by myself and the OP still remains elusive. It's rather puzzling as I pulled from HEAD and built using the same options on both. I've gotten a bit better with the qemu options now, so I will paste the console output here instead of doing yet another screenshot :) As you can see, it's still getting a fatal exception in the interrupt code. Do you know of a kernel version that would be better behaved than the 3.6.11+ from the "raspberrypi/linux" repo on github? Could I provide a core file that would help? + +Thanks again for your efforts. +Joss + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +phoenix:RaspberryPi mysfitt$ qemu-system-arm -kernel kernel/zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 console=ttyAMA0" -redir tcp:5022::22 -bt hci,null -global versatile_pci.broken-irq-mapping=1 pifi-4g.img +Uncompressing Linux... done, booting the kernel. +Booting Linux on physical CPU 0 +Linux version 3.6.11+ (root@jossibox) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #1 Fri May 10 16:46:40 EDT 2013 +CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d +CPU: VIPT aliasing data cache, unknown instruction cache +Machine: ARM-Versatile PB +Memory policy: ECC disabled, Data cache writeback +sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 +Kernel command line: root=/dev/sda2 panic=1 console=ttyAMA0 +PID hash table entries: 1024 (order: 0, 4096 bytes) +Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) +Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) +Memory: 256MB = 256MB total +Memory: 255388k/255388k available, 6756k reserved, 0K highmem +Virtual kernel memory layout: + vector : 0xffff0000 - 0xffff1000 ( 4 kB) + fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) + vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) + lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) + modules : 0xbf000000 - 0xc0000000 ( 16 MB) + .text : 0xc0008000 - 0xc03f6458 (4026 kB) + .init : 0xc03f7000 - 0xc04162bc ( 125 kB) + .data : 0xc0418000 - 0xc043fb60 ( 159 kB) + .bss : 0xc043fb84 - 0xc045abb0 ( 109 kB) +NR_IRQS:192 +VIC @f1140000: id 0x00041190, vendor 0x41 +FPGA IRQ chip 0 "SIC" @ f1003000, 21 irqs +Console: colour dummy device 80x30 +Calibrating delay loop... 626.68 BogoMIPS (lpj=3133440) +pid_max: default: 32768 minimum: 301 +Mount-cache hash table entries: 512 +CPU: Testing write buffer coherency: ok +Setting up static identity map for 0x305ce0 - 0x305d3c +devtmpfs: initialized +NET: Registered protocol family 16 +DMA: preallocated 256 KiB pool for atomic coherent allocations +Serial: AMBA PL011 UART driver +dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 12) is a PL011 rev1 +console [ttyAMA0] enabled +dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 13) is a PL011 rev1 +dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 14) is a PL011 rev1 +fpga:09: ttyAMA3 at MMIO 0x10009000 (irq = 38) is a PL011 rev1 +PCI core found (slot 11) +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [io 0x0000-0xffff] +pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff] +pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff pref] +pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] +PCI: bus0: Fast back to back transfers disabled +pci 0000:00:0c.0: BAR 2: assigned [mem 0x50000000-0x50001fff] +pci 0000:00:0c.0: BAR 1: assigned [mem 0x50002000-0x500023ff] +pci 0000:00:0c.0: BAR 0: can't assign io (size 0x100) +bio: create slab <bio-0> at 0 +vgaarb: loaded +SCSI subsystem initialized +Switching to clocksource timer3 +NET: Registered protocol family 2 +TCP established hash table entries: 8192 (order: 4, 65536 bytes) +TCP bind hash table entries: 8192 (order: 3, 32768 bytes) +TCP: Hash tables configured (established 8192 bind 8192) +TCP: reno registered +UDP hash table entries: 256 (order: 0, 4096 bytes) +UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) +NET: Registered protocol family 1 +RPC: Registered named UNIX socket transport module. +RPC: Registered udp transport module. +RPC: Registered tcp transport module. +RPC: Registered tcp NFSv4.1 backchannel transport module. +NetWinder Floating Point Emulator V0.97 (double precision) +Installing knfsd (copyright (C) 1996 <email address hidden>). +jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. +ROMFS MTD (C) 2007 Red Hat, Inc. +fuse init (API version 7.20) +msgmni has been set to 498 +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) +io scheduler noop registered +io scheduler deadline registered +io scheduler cfq registered (default) +clcd-pl11x dev:20: PL110 rev0 at 0x10120000 +clcd-pl11x dev:20: Versatile hardware, VGA display +Console: switching to colour frame buffer device 80x30 +brd: module loaded +PCI: enabling device 0000:00:0c.0 (0100 -> 0102) +sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 27 +sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking +sym0: SCSI BUS has been reset. +scsi0 : sym-2.2.3 +sym0: unknown interrupt(s) ignored, ISTAT=0x5 DSTAT=0x80 SIST=0x0 +scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 1.4. PQ: 0 ANSI: 5 +scsi target0:0:0: tagged command queuing enabled, command queue depth 16. +scsi target0:0:0: Beginning Domain Validation +scsi target0:0:0: Domain Validation skipping write tests +scsi target0:0:0: Ending Domain Validation +scsi 0:0:2:0: CD-ROM QEMU QEMU CD-ROM 1.4. PQ: 0 ANSI: 5 +scsi target0:0:2: tagged command queuing enabled, command queue depth 16. +scsi target0:0:2: Beginning Domain Validation +scsi target0:0:2: Domain Validation skipping write tests +scsi target0:0:2: Ending Domain Validation +sr0: scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray +cdrom: Uniform CD-ROM driver Revision: 3.20 +sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB) +sd 0:0:0:0: [sda] Write Protect is off +sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +physmap platform flash device: 04000000 at 34000000 +physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 +Intel/Sharp Extended Query Table at 0x0031 +Using buffer write method + sda: sda1 sda2 sda3 sda4 +smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <email address hidden> +eth0: SMC91C11xFD (rev 1) at d09ca000 IRQ 25 [nowait] +eth0: Ethernet addr: 52:54:00:12:34:56 +sd 0:0:0:0: [sda] Attached SCSI disk +mousedev: PS/2 mouse device common for all mice +TCP: cubic registered +NET: Registered protocol family 17 +VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 +input: AT Raw Set 2 keyboard as /devices/fpga:06/serio0/input/input0 +input: ImExPS/2 Generic Explorer Mouse as /devices/fpga:07/serio1/input/input1 +EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240) +EXT2-fs (sda2): error: couldn't mount because of unsupported optional features (240) +EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) +VFS: Mounted root (ext4 filesystem) readonly on device 8:2. +devtmpfs: mounted +Freeing init memory: 124K +sd 0:0:0:0: [sda] ABORT operation started +scsi target0:0:0: control msgout: + 80 20 51 d. +sd 0:0:0:0: ABORT operation complete. +Unable to handle kernel NULL pointer dereference at virtual address 00000358 +pgd = c0004000 +[00000358] *pgd=00000000 +Internal error: Oops: 5 [#1] ARM +Modules linked in: +CPU: 0 Not tainted (3.6.11+ #1) +PC is at sym_interrupt+0x7c8/0x1b88 +LR is at sym53c8xx_intr+0x40/0x7c +pc : [<c02193a0>] lr : [<c0214e0c>] psr: 80000193 +sp : c0419e30 ip : cf844800 fp : 00000001 +r10: cf935400 r9 : c043fb00 r8 : d0804084 +r7 : 00000012 r6 : c045588c r5 : 00000000 r4 : d0804000 +r3 : 00000008 r2 : 0000000d r1 : 00000000 r0 : 00000000 +Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel +Control: 00c5387d Table: 0fb40008 DAC: 00000017 +Process swapper (pid: 0, stack limit = 0xc0418268) +Stack: (0xc0419e30 to 0xc041a000) +9e20: 1be06241 00000000 00000001 00200200 +9e40: cf997af0 c004256c cf997ac0 cf844800 c0427898 c043fae4 c0418000 00000100 +9e60: c0419e7c cf9cbca0 c045587c 00000000 00000000 0000001b c043fb00 c0428e54 +9e80: 00000001 c0214e0c 00000001 00000080 0000001b cf9cbca0 0000001b c0054620 +9ea0: c0445420 c0419ec0 00000000 c0428e54 0000001b 00000000 c043fee8 00000000 +9ec0: cf997ac0 c0307e44 c0419f74 c00547a8 c0428e54 c0056860 c04321e8 c0053fe4 +9ee0: 000000c0 c001470c c043fee8 c0419f10 00000000 c00084f8 c003f840 20000013 +9f00: ffffffff c0419f44 c04223d8 c00134c0 00000000 00000000 00000002 cfb20c8c +9f20: cfb20c60 cf997ac0 00000001 c0427898 c04223d8 cf997ac0 c0307e44 c0419f74 +9f40: 00000000 c0419f58 c030536c c003f840 20000013 ffffffff 00000000 00000000 +9f60: c0427898 c0418000 c0427898 c04223d8 c0419fa4 c030536c c04230c0 cfb20c60 +9f80: c0423348 c0418000 c0418000 c043fc68 c0418000 c04230c0 410fb767 c0423348 +9fa0: 00000000 c0014a18 c0425fbc c04200d0 ffffffff c04123fc c065b880 00004008 +9fc0: 00410e7c c03f771c ffffffff ffffffff c03f728c 00000000 00000000 c04123fc +9fe0: 00000000 00c5387d c042004c c04123f8 c04230b4 00008040 00000000 00000000 +[<c02193a0>] (sym_interrupt+0x7c8/0x1b88) from [<c0214e0c>] (sym53c8xx_intr+0x40/0x7c) +[<c0214e0c>] (sym53c8xx_intr+0x40/0x7c) from [<c0054620>] (handle_irq_event_percpu+0x50/0x1b0) +[<c0054620>] (handle_irq_event_percpu+0x50/0x1b0) from [<c00547a8>] (handle_irq_event+0x28/0x38) +[<c00547a8>] (handle_irq_event+0x28/0x38) from [<c0056860>] (handle_level_irq+0x80/0xd4) +[<c0056860>] (handle_level_irq+0x80/0xd4) from [<c0053fe4>] (generic_handle_irq+0x24/0x38) +[<c0053fe4>] (generic_handle_irq+0x24/0x38) from [<c001470c>] (handle_IRQ+0x30/0x84) +[<c001470c>] (handle_IRQ+0x30/0x84) from [<c00084f8>] (vic_handle_irq+0x58/0x98) +[<c00084f8>] (vic_handle_irq+0x58/0x98) from [<c00134c0>] (__irq_svc+0x40/0x54) +Exception stack(0xc0419f10 to 0xc0419f58) +9f00: 00000000 00000000 00000002 cfb20c8c +9f20: cfb20c60 cf997ac0 00000001 c0427898 c04223d8 cf997ac0 c0307e44 c0419f74 +9f40: 00000000 c0419f58 c030536c c003f840 20000013 ffffffff +[<c00134c0>] (__irq_svc+0x40/0x54) from [<c003f840>] (finish_task_switch.constprop.68+0x78/0xec) +[<c003f840>] (finish_task_switch.constprop.68+0x78/0xec) from [<c030536c>] (__schedule+0x1a0/0x3bc) +[<c030536c>] (__schedule+0x1a0/0x3bc) from [<c0014a18>] (cpu_idle+0xa4/0xc0) +[<c0014a18>] (cpu_idle+0xa4/0xc0) from [<c03f771c>] (start_kernel+0x26c/0x2bc) +Code: e5d42540 e3a03008 e5c43540 e5842550 (e5951358) +---[ end trace 25ce2cfc77dea57b ]--- +Kernel panic - not syncing: Fatal exception in interrupt + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +On May 14, 2013, at 6:58 AM, Peter Maydell <email address hidden> wrote: + +> It's very unlikely to be the patch you mention, since that's for SD card +> emulation and you're not using SD card emulation. It's probably just a +> regression between 1.4 and 1.5, and I'm fairly sure it's in some changes +> I made to the versatilepb PCI controller model -- I will investigate. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1094564 +> +> Title: +> images used as scsi disks not readable (qemu-system-arm, macos 10.8) +> +> Status in The MacPorts Project: +> New +> Status in QEMU: +> New +> +> Bug description: +> Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my +> disk, I get as far as mounting root and then get SCSI errors with +> 1.3.0 and the current origin/master. git bisect says the issue is +> +> commit f563a5d7a820424756f358e747238f03e866838a +> Merge: a273652 aee0bf7 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Oct 31 10:42:51 2012 +0100 +> +> Merge remote-tracking branch 'origin/master' into threadpool +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> +> I am using: +> qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 +> +> Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: +> CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/macports/+bug/1094564/+subscriptions + + + +On 15 May 2013 19:02, Joss Reeves <email address hidden> wrote: +> Thanks so much for the patch and including me on the thread. I can +> confirm that it did fix the problem running on a Linux host, but the OS +> X bug cited by myself and the OP still remains elusive. It's rather +> puzzling as I pulled from HEAD and built using the same options on both. + +QEMU itself actually hangs in my tests (the main loop is waiting +to lock the iothread but it never does; the cpu thread seems to +be stuck trying to do a bdrv_aio_cancel for the scsi device model). +This should never happen, regardless of what the guest does... + +I suspect that if you configure on linux with --with-coroutine=sigaltstack +you might then find they both behave the same (MacOSX can't do the +ucontext coroutines we default to on linux). OTOH it might also +involve some of MacOSX's slightly different signal behaviour. + +I'll continue to prod, though past experience is that MacOSX +gdb is weirdly broken and things behave differently when run +under it, which doesn't help :-( + +-- PMM + + +On 15 May 2013 21:18, Peter Maydell <email address hidden> wrote: +> I suspect that if you configure on linux with --with-coroutine=sigaltstack +> you might then find they both behave the same (MacOSX can't do the +> ucontext coroutines we default to on linux). + +They don't, so it's a MacOSX specific issue of some kind. +PS: you don't need "-global versatile_pci.broken-irq-mapping=1" +in the command line because we do correctly autodetect and +handle your kernel now. + +thanks +-- PMM + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + diff --git a/results/classifier/108/other/1095 b/results/classifier/108/other/1095 new file mode 100644 index 00000000..5cb2cbc5 --- /dev/null +++ b/results/classifier/108/other/1095 @@ -0,0 +1,16 @@ +other: 0.833 +network: 0.767 +device: 0.685 +semantic: 0.675 +boot: 0.378 +performance: 0.377 +graphic: 0.358 +vnc: 0.324 +socket: 0.323 +KVM: 0.293 +permissions: 0.239 +PID: 0.238 +files: 0.125 +debug: 0.120 + +[QUESTION] What IF.... diff --git a/results/classifier/108/other/1095531 b/results/classifier/108/other/1095531 new file mode 100644 index 00000000..8101766a --- /dev/null +++ b/results/classifier/108/other/1095531 @@ -0,0 +1,170 @@ +other: 0.724 +permissions: 0.723 +semantic: 0.674 +graphic: 0.655 +debug: 0.645 +device: 0.639 +performance: 0.638 +KVM: 0.579 +PID: 0.556 +vnc: 0.552 +files: 0.542 +boot: 0.518 +socket: 0.508 +network: 0.409 + +sparc32plus (and others?) has x86 code generation errors on 64bit hosts + +On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode. + +-------------- +IN: +0x0000000040804aa8: st %i0, [ %fp + 0x44 ] + +OP: + ---- 0x40804aa8 + ld_i64 tmp1,regwptr,$0xb0 + mov_i64 tmp0,tmp1 + movi_i64 tmp2,$0x44 + add_i64 tmp0,tmp0,tmp2 + ld_i64 tmp2,regwptr,$0x80 + ext32u_i64 tmp0,tmp0 + qemu_st32 tmp2,tmp0,$0x0 + +OUT: [size=345] +0x6032d7f0: mov 0x40(%r14),%rbp +0x6032d7f4: mov 0xb0(%rbp),%rbx +0x6032d7fb: add $0x44,%rbx +0x6032d7ff: mov 0x80(%rbp),%rbp +0x6032d806: mov %ebx,%ebx <- bug +0x6032d808: mov %ebp,%edi +0x6032d80a: bswap %edi +0x6032d80c: mov %edi,(%rbx) + +-------------- +IN: +0x0000000040804aec: add %l7, %o7, %l7 +0x0000000040804af0: ld [ %l7 ], %g2 + +OP: + ---- 0x40804aec + ld_i64 tmp1,regwptr,$0x78 + ld_i64 tmp2,regwptr,$0x38 + add_i64 tmp0,tmp1,tmp2 + st_i64 tmp0,regwptr,$0x78 + + ---- 0x40804af0 + ld_i64 tmp1,regwptr,$0x78 + mov_i64 tmp0,tmp1 + ext32u_i64 tmp0,tmp0 + qemu_ld32u g2,tmp0,$0x0 + +OUT: [size=395] +0x6032da80: mov 0x40(%r14),%rbp +0x6032da84: mov 0x78(%rbp),%rbx +0x6032da88: mov 0x38(%rbp),%r12 +0x6032da8c: add %r12,%rbx +0x6032da8f: mov %rbx,0x78(%rbp) +0x6032da93: mov 0x78(%rbp),%rbx +0x6032da97: mov %ebx,%ebx <- bug +0x6032da99: mov (%rbx),%ebx + +In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable. + +I forgot to add, this is on the latest master branch as of this post. I am doing a static compile with debug enabled. My test is doing a chroot of a sparc system built from debootstrap. + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +I no longer have a setup to test this so I can only say to close it. + +On Jul 11, 2017 4:15 PM, "Thomas Huth" <email address hidden> wrote: + +> Can you still reproduce this problem wit the latest release of QEMU +> (currently version 2.9.0), or could we close this bug nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1095531 +> +> Title: +> sparc32plus (and others?) has x86 code generation errors on 64bit +> hosts +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> On 64bit hosts, the load and store functions compile improperly. The +> issue is the call to gen_address_mask() under the ld and st functions +> in target-sparc/translate.c. Below are some snips from the log file. +> Doing a gdb debug, this results in constant access violation errors +> which I do not see when debugging qemu in powerpc mode. +> +> -------------- +> IN: +> 0x0000000040804aa8: st %i0, [ %fp + 0x44 ] +> +> OP: +> ---- 0x40804aa8 +> ld_i64 tmp1,regwptr,$0xb0 +> mov_i64 tmp0,tmp1 +> movi_i64 tmp2,$0x44 +> add_i64 tmp0,tmp0,tmp2 +> ld_i64 tmp2,regwptr,$0x80 +> ext32u_i64 tmp0,tmp0 +> qemu_st32 tmp2,tmp0,$0x0 +> +> OUT: [size=345] +> 0x6032d7f0: mov 0x40(%r14),%rbp +> 0x6032d7f4: mov 0xb0(%rbp),%rbx +> 0x6032d7fb: add $0x44,%rbx +> 0x6032d7ff: mov 0x80(%rbp),%rbp +> 0x6032d806: mov %ebx,%ebx <- bug +> 0x6032d808: mov %ebp,%edi +> 0x6032d80a: bswap %edi +> 0x6032d80c: mov %edi,(%rbx) +> +> -------------- +> IN: +> 0x0000000040804aec: add %l7, %o7, %l7 +> 0x0000000040804af0: ld [ %l7 ], %g2 +> +> OP: +> ---- 0x40804aec +> ld_i64 tmp1,regwptr,$0x78 +> ld_i64 tmp2,regwptr,$0x38 +> add_i64 tmp0,tmp1,tmp2 +> st_i64 tmp0,regwptr,$0x78 +> +> ---- 0x40804af0 +> ld_i64 tmp1,regwptr,$0x78 +> mov_i64 tmp0,tmp1 +> ext32u_i64 tmp0,tmp0 +> qemu_ld32u g2,tmp0,$0x0 +> +> OUT: [size=395] +> 0x6032da80: mov 0x40(%r14),%rbp +> 0x6032da84: mov 0x78(%rbp),%rbx +> 0x6032da88: mov 0x38(%rbp),%r12 +> 0x6032da8c: add %r12,%rbx +> 0x6032da8f: mov %rbx,0x78(%rbp) +> 0x6032da93: mov 0x78(%rbp),%rbx +> 0x6032da97: mov %ebx,%ebx <- bug +> 0x6032da99: mov (%rbx),%ebx +> +> In 64bit mode, doing a 32bit operation will result in the top 32bit's +> being zero'd. I attempted to simply disable the call to +> gen_address_mask() but that did not fix the issue and actually caused +> the sparc32plus I was testing to become unusable. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1095531/+subscriptions +> + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1095857 b/results/classifier/108/other/1095857 new file mode 100644 index 00000000..07c66ba8 --- /dev/null +++ b/results/classifier/108/other/1095857 @@ -0,0 +1,31 @@ +graphic: 0.736 +device: 0.679 +performance: 0.570 +other: 0.555 +semantic: 0.442 +debug: 0.408 +network: 0.323 +socket: 0.242 +boot: 0.214 +vnc: 0.198 +permissions: 0.167 +PID: 0.156 +files: 0.154 +KVM: 0.114 + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +end up executing as + +mov eax,[r15] + +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. + +You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1096 b/results/classifier/108/other/1096 new file mode 100644 index 00000000..f1a1e320 --- /dev/null +++ b/results/classifier/108/other/1096 @@ -0,0 +1,16 @@ +graphic: 0.861 +device: 0.805 +performance: 0.580 +network: 0.576 +other: 0.534 +vnc: 0.524 +files: 0.477 +permissions: 0.419 +boot: 0.408 +semantic: 0.362 +socket: 0.226 +debug: 0.210 +PID: 0.171 +KVM: 0.030 + +New warning with GCC 13 diff --git a/results/classifier/108/other/1096713 b/results/classifier/108/other/1096713 new file mode 100644 index 00000000..c3b3058b --- /dev/null +++ b/results/classifier/108/other/1096713 @@ -0,0 +1,28 @@ +graphic: 0.893 +device: 0.866 +performance: 0.655 +semantic: 0.625 +debug: 0.600 +network: 0.567 +PID: 0.566 +other: 0.520 +socket: 0.493 +vnc: 0.453 +permissions: 0.387 +boot: 0.382 +files: 0.373 +KVM: 0.093 + +qemu 1.3.0: Windows XP crashes when reconizing the USB keyboard + +I'm trying to use the usb tablet and the usb keyboard as follows: +./qemu-system-i386 -device pci-ohci -device usb-tablet -device usb-kbd +or +./qemu-system-i386 -device ich9-usb-ehci1 -device ich9-usb-uhci1 -device usb-tablet -device ich9-usb-uhci2 -device usb-kbd + +While Windows XP works fine if I only use the tablet but not the keyboard, it crashed with a BSOD when I use both keyboard and tablet. It crashed during the detection of the keyboard. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1096714 b/results/classifier/108/other/1096714 new file mode 100644 index 00000000..a7af6e54 --- /dev/null +++ b/results/classifier/108/other/1096714 @@ -0,0 +1,49 @@ +other: 0.850 +boot: 0.822 +device: 0.809 +PID: 0.718 +graphic: 0.702 +performance: 0.586 +semantic: 0.493 +files: 0.481 +vnc: 0.458 +network: 0.435 +socket: 0.401 +permissions: 0.381 +KVM: 0.341 +debug: 0.289 + +qemu 1.3.0: usb devices shouldn't have same vendor/product ID and same serial + +Boot Windows XP with +./qemu-system-i386 -device pci-ohci -device usb-tablet +and then with +./qemu-system-i386 -device pci-ohci -device usb-kbd + +and you will notice, that the usb keyboard is not detected. In fact, Windows XP detects the usb tablet and loads the driver for the tablet instead of the driver for the keyboard. + +The problem seems to be, that vendor and product ID and even the seriel of both the usb tablet and the usb keyboard are the same as an lsusb reveiles. Hence, Windows XP doesn't detect when you replace the tablet by a keyboard and vice versa. I didn't check other USB devices, but it seems a bad idea to me to have devices with the same vendor/product Id. I'm not aware, whether it is sufficient to change the seriel numbers of the devices. + +This is a problem with ancient Linux distributions that match vendor-product in Xorg.conf as well. + +This bug is more than 4 years old. Why did I even bother writing it? Is the problem still there in recent qemu versions? + +Hi Sven, + Hmm you do have a point - I wonder if this is fixed on windows by commit 5319dc7 from Gerd in November 2013 that added 'msos-desc' compat properties; but I see your point about having the same IDs + +(ccing in Gerd) + +Try "-device usb-tablet,serial=1234" + +I see no option in Xorg.conf to match serial. Maybe there is. It is mostly undocumented, especially for some random ancient X11 snapshot the distro has. + +That said the VM happens to be configured in such a way it works - keyboard and mouse are in same order on USB bus and in Xorg.conf + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/92 + + diff --git a/results/classifier/108/other/1097 b/results/classifier/108/other/1097 new file mode 100644 index 00000000..1539dd7b --- /dev/null +++ b/results/classifier/108/other/1097 @@ -0,0 +1,16 @@ +device: 0.742 +debug: 0.564 +graphic: 0.544 +performance: 0.414 +semantic: 0.284 +other: 0.262 +permissions: 0.252 +network: 0.250 +boot: 0.210 +PID: 0.166 +files: 0.134 +vnc: 0.075 +socket: 0.022 +KVM: 0.014 + +linux-user build broken on 32-bit ppc diff --git a/results/classifier/108/other/1098729 b/results/classifier/108/other/1098729 new file mode 100644 index 00000000..366460da --- /dev/null +++ b/results/classifier/108/other/1098729 @@ -0,0 +1,179 @@ +permissions: 0.785 +debug: 0.685 +PID: 0.660 +device: 0.653 +boot: 0.646 +vnc: 0.643 +performance: 0.636 +semantic: 0.636 +graphic: 0.631 +other: 0.591 +KVM: 0.563 +socket: 0.558 +files: 0.532 +network: 0.446 + +qemu-user-static for armhf: segfault in threaded code + + +Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian. + +The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot. + +Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs. + +As an example, I've grabbed the threads demo program here: + + https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c + +and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest): + + gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex + +When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever. + +However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output: + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + Thread 0 did 0 to 100000: mysum=100000.000000 global sum=200000.000000 + TCG temporary leak before f6731ca0 + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371: + tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed. + + + (armhf) $ ./dotprod_mutex + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault + + (armhf) $ ./dotprod_mutex + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519: + tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed. + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault + +I can also comple a purely static version of the test program in the armhf chroot using: + + gcc -Wall -static -pthread dotprod_mutex.c -o dotprod-mutex-static + +and then run it simply using: + + qemu-arm-static dotprod-mutex-static + +which fails just like it does in the chroot. + +Begining to think this is memory corruption because of the number of different failure modes. In addition to the crashes in the initial report I have also seen the following: + + + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + + More temporaries freed than allocated! + TCG temporary leak before 0001d1dc + + qemu-arm-static: /home/erikd/Git/qemu-pthread-hacking/tcg/tcg.c:1888: tcg_reg_alloc_op: + Assertion `ts->val_type == 1' failed. + + /home/erikd/Git/qemu-pthread-hacking/tcg/tcg.c:149: tcg fatal error + + +What's the best way to debug the qemu user space emulation? I read this: + + http://wiki.qemu.org/Documentation/Debugging + +but that seems to mainly refer to the qemu machine emulation. + +I added -ggdb to QEMU_CFLAGS in config-host.mak so it builds with debug symbols but gdb still doesn't provide any useful information beyond the following: + + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [New Thread 0x7ffefdb6b700 (LWP 11210)] + [New Thread 0x7ffefdaf5700 (LWP 11211)] + [New Thread 0x7ffefda7f700 (LWP 11212)] + [New Thread 0x7ffefda09700 (LWP 11213)] + [New Thread 0x7ffefd993700 (LWP 11214)] + + Program received signal SIGSEGV, Segmentation fault. + [Switching to Thread 0x7ffefdaf5700 (LWP 11211)] + 0x0000000060363b58 in static_code_gen_buffer () + (gdb) bt + #0 0x0000000060363b58 in static_code_gen_buffer () + #1 0x00000000f50ba518 in ?? () + #2 0x00000000624a9360 in ?? () + #3 0x00007ffefdaf4b80 in ?? () + #4 0x326cebdf4a8e4700 in ?? () + #5 0x00007ffe00000000 in ?? () + #6 0x0000000000000000 in ?? () + +and valgrind doesn't help either. + +Yes, multithreaded guests are liable to crash; where they work they generally work more by luck than design. There is some discussion in LP:668799 of one of the known problems (whose symptoms are usually crashes or hangs). + + +At the top of function cpu_unlink_tb() in translate-all.c: + + /* FIXME: TB unchaining isn't SMP safe. For now just ignore the + problem and hope the cpu will stop of its own accord. For userspace + emulation this often isn't actually as bad as it sounds. Often + signals are used primarily to interrupt blocking syscalls. */ + + +The class of bugs exemplified by the symptoms described here are those where the multithreaded guest program causes QEMU to misbehave because we are sharing the code-translation globals (eg the generated code buffer) between multiple threads and they trod on each others' toes. + +(The race described in the comment in cpu_unlink_tb() has been fixed under LP:668799.) + +I also experimented the bug. +It may SIGSEGV or hang. Or it may work, very rarely. + +But I cannot reproduce it at all if change my app to stay on a single CPU: + +int +main(int argc, char * argv[] ) +{ + +#ifdef QEMU + cpu_set_t cpuSet; + CPU_ZERO(&cpuSet); + CPU_SET(0,&cpuSet); + if (sched_setaffinity(getpid(), sizeof(cpu_set_t), &cpuSet) !=0) + cerr << "sched_setaffinity failed" << endl; +#endif /* QEMU */ + +./build/buildd/qemu-linaro-1.5.0-2013.06/tcg/tcg.c:149: tcg fatal error +/build/buildd/qemu-linaro-1.5.0-2013.06/tcg/tcg.c:149: tcg fatal error + +same for me + +Same problem for me when executing msgmerge in qemu-arm-static. + +https://launchpadlibrarian.net/181070813/buildlog_ubuntu-utopic-armhf.hedgewars_0.9.21~alpha~7716~ubuntu14.10.1_FAILEDTOBUILD.txt.gz + +this started happening after the new deploy of trusty in buildds + +Also happening when manually built from the 2.1.2 release codebase. In my case it impacts the llvm-3.5.0 "make check" testsuite running an an armhf-emulated chroot--it immediately gets SIGSEGV and SIGILL as soon as it starts running tests. + +I cannot make dotprod_mutex.c to crash with the current master (git 8ffe756d). I've tried both linux-arm and linux-arm-static, the latter running under chroot. + +I've tried on three different machines, and have tested with different thread counts: 4, 10, 16, 64 (one of the machines has 64 cores). +I completed 1000 successive runs on each. + +Can you please retest on the current master? I certainly could trigger the bug on the qemu-arm-static that is packaged with Ubuntu 14.04, so it is possible that since then changes in qemu have at least made it harder to trigger the bug. + + + +I can confirm that building QEMU 2.5.0 from source, all the multi-thread issues seem to be fixed. + +Specifically, the mentioned dotprod_mutex.c example, even when modified to use 100 threads, is always running in the qemu-arm User mode emulator. + +Tested in Ubuntu 14.04 x86_64, with all the updates installed. + +Note that instead the QEMU 2.0.0 from the Ubuntu 14.04 repository is having issues even when using workarounds like running it with "taskset 0x1" to force the execution to a single CPU. + + + +We think we've fixed the multithreading issues in QEMU linux-user (in particular the test case that started this bug report works). If there are still problems with a QEMU version later than 2.10, please open fresh bug reports for specific guest programs that fail, giving detailed how-to-reproduce instructions. + + diff --git a/results/classifier/108/other/1099 b/results/classifier/108/other/1099 new file mode 100644 index 00000000..384be8db --- /dev/null +++ b/results/classifier/108/other/1099 @@ -0,0 +1,16 @@ +device: 0.692 +network: 0.551 +files: 0.540 +performance: 0.515 +PID: 0.448 +boot: 0.416 +debug: 0.383 +socket: 0.369 +permissions: 0.331 +other: 0.232 +vnc: 0.205 +graphic: 0.199 +semantic: 0.137 +KVM: 0.127 + +zlib: Concurrent modification is unsafe |