diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/67 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/670 | 25 | ||||
| -rw-r--r-- | results/classifier/108/other/670769 | 316 | ||||
| -rw-r--r-- | results/classifier/108/other/672 | 18 | ||||
| -rw-r--r-- | results/classifier/108/other/672934 | 97 | ||||
| -rw-r--r-- | results/classifier/108/other/673009 | 155 | ||||
| -rw-r--r-- | results/classifier/108/other/674 | 29 | ||||
| -rw-r--r-- | results/classifier/108/other/676934 | 33 | ||||
| -rw-r--r-- | results/classifier/108/other/677 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/678363 | 35 | ||||
| -rw-r--r-- | results/classifier/108/other/679 | 16 |
11 files changed, 756 insertions, 0 deletions
diff --git a/results/classifier/108/other/67 b/results/classifier/108/other/67 new file mode 100644 index 00000000..d805250a --- /dev/null +++ b/results/classifier/108/other/67 @@ -0,0 +1,16 @@ +device: 0.748 +graphic: 0.621 +performance: 0.503 +other: 0.176 +semantic: 0.144 +boot: 0.093 +network: 0.081 +debug: 0.067 +permissions: 0.031 +files: 0.012 +vnc: 0.005 +socket: 0.003 +PID: 0.003 +KVM: 0.002 + +incomplete emulation of fstenv under TCG diff --git a/results/classifier/108/other/670 b/results/classifier/108/other/670 new file mode 100644 index 00000000..65438550 --- /dev/null +++ b/results/classifier/108/other/670 @@ -0,0 +1,25 @@ +boot: 0.811 +performance: 0.793 +device: 0.780 +other: 0.740 +graphic: 0.723 +semantic: 0.608 +files: 0.572 +socket: 0.513 +debug: 0.503 +PID: 0.493 +vnc: 0.483 +permissions: 0.475 +network: 0.446 +KVM: 0.031 + +qemu x86_64 for microsoft windows hangs when booting a Debian Live 11.1 iso file +Description of problem: +qemu displays the boot screen from the live linux iso and starts the boot, but no more display is performed even when waiting for approximately 30 minutes +Steps to reproduce: +1. Get hold of a Live Linux iso from Debian 11.1 +2. Set up the Microsoft Windows version of qemu from https://qemu.weilnetz.de/ +3. Attempt to boot the Live Linux iso +Additional information: +I also tested older versions of QEMU from the Weilnetz web site. 6.0.0 and 5.2.0 are bad; 5.1.0 and older are good. I then tested the same command line ( no acceleration ) under Linux Tumbleweed 20211014 with qemu 6.1.0 and the iso booted successfully. I have not tried with isos from distributions other than Debian 11.1 . So there is a bug with the Microsoft Windows-specific code in qemu. +If you need the specific Live Linux that I was using, let me know and I will get it to you somehow. It is several GB in size so I cannot upload it anywhere conveniently. diff --git a/results/classifier/108/other/670769 b/results/classifier/108/other/670769 new file mode 100644 index 00000000..06c80ff3 --- /dev/null +++ b/results/classifier/108/other/670769 @@ -0,0 +1,316 @@ +other: 0.945 +performance: 0.939 +graphic: 0.936 +device: 0.935 +permissions: 0.932 +debug: 0.924 +semantic: 0.923 +socket: 0.912 +files: 0.906 +PID: 0.906 +boot: 0.874 +network: 0.858 +KVM: 0.847 +vnc: 0.828 + +CDROM size not updated when changing image files + +I'm using qemu 13.0 with a plain Linux kernel using the ata_piix driver as the guest, and an initrd that starts a shell. When changing the image in the monitor and reading from the CDROM in the guest, the size is not updated. I'm using LInux 2.6.32.24 +as the host and I've tested 2.6.32.24, 2.6.35, and 2.6.36 as guests. Both host and guest are 64-bit. Here is the command used to start the guest using the initrd: + +./x86_64-softmmu/qemu-system-x86_64 -cdrom /spare2/cd1.img -kernel /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu core2duo + +Additional info on this bug can be found here: http://marc.info/?l=kvm&m=128746013906820&w=2. Note: this is how I discovered +the bug, using 32-bit Slackware install CDs. + +I'm attaching the initrd I used in my tests: I created two different-sized fake CDROM images by dd'ing from /dev/zero. In my tests, +cd1.img is smaller that cd2.img. In the monitor I executed 'change ide1-cd0 /spare2/cd2.img' to load the new image. I checked +the size by cat'ing /sys/block/sr0/size in the guest after reading the CDROM. Reading the CDROM was done by typing +'dd if=/dev/sr0 of=/dev/null bs=512 count=3' + + + +Please note that until this bug is fixed, one cannot successfully install a guest OS from a set of CD-ROMS where the first disk image is smaller than subsequent ones. + + +On 10.11.2010, at 04:17, Alex Davis wrote: + +> Please note that until this bug is fixed, one cannot successfully +> install a guest OS from a set of CD-ROMS where the first disk image is +> smaller than subsequent ones. +> +> -- +> CDROM size not updated when changing image files +> https://bugs.launchpad.net/bugs/670769 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> +> Bug description: +> I'm using qemu 13.0 with a plain Linux kernel using the ata_piix driver as the guest, and an initrd that starts a shell. When changing the image in the monitor and reading from the CDROM in the guest, the size is not updated. I'm using LInux 2.6.32.24 +> as the host and I've tested 2.6.32.24, 2.6.35, and 2.6.36 as guests. Both host and guest are 64-bit. Here is the command used to start the guest using the initrd: +> +> ./x86_64-softmmu/qemu-system-x86_64 -cdrom /spare2/cd1.img -kernel /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu core2duo +> +> Additional info on this bug can be found here: http://marc.info/?l=kvm&m=128746013906820&w=2. Note: this is how I discovered +> the bug, using 32-bit Slackware install CDs. +> +> I'm attaching the initrd I used in my tests: I created two different-sized fake CDROM images by dd'ing from /dev/zero. In my tests, +> cd1.img is smaller that cd2.img. In the monitor I executed 'change ide1-cd0 /spare2/cd2.img' to load the new image. I checked +> the size by cat'ing /sys/block/sr0/size in the guest after reading the CDROM. Reading the CDROM was done by typing +> 'dd if=/dev/sr0 of=/dev/null bs=512 count=3' + +Just to clarify, the contents of the image do change, but the reported size does not? + +Alex + + +I code, therefore I am + + +--- On Tue, 11/9/10, agraf <email address hidden> wrote: + +> From: agraf <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 670769] Re: CDROM size not updated when changing image files +> To: <email address hidden> +> Date: Tuesday, November 9, 2010, 10:47 PM +> +> On 10.11.2010, at 04:17, Alex Davis wrote: +> +> > Please note that until this bug is fixed, one cannot +> successfully +> > install a guest OS from a set of CD-ROMS where the +> first disk image is +> > smaller than subsequent ones. +> > +> > -- +> > CDROM size not updated when changing image files +> > https://bugs.launchpad.net/bugs/670769 +> > You received this bug notification because you are a +> member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > +> > Status in QEMU: New +> > +> > Bug description: +> > I'm using qemu 13.0 with a plain Linux kernel using +> the ata_piix driver as the guest, and an initrd that starts +> a shell. When changing the image in the monitor and reading +> from the CDROM in the guest, the size is not updated. I'm +> using LInux 2.6.32.24 +> > as the host and I've tested 2.6.32.24, 2.6.35, and +> 2.6.36 as guests. Both host and guest are 64-bit. Here +> is the command used to start the guest using the initrd: +> > +> > ./x86_64-softmmu/qemu-system-x86_64 -cdrom +> /spare2/cd1.img -kernel +> /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd +> /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu +> core2duo +> > +> > Additional info on this bug can be found here: http://marc.info/?l=kvm&m=128746013906820&w=2. Note: +> this is how I discovered +> > the bug, using 32-bit Slackware install CDs. +> > +> > I'm attaching the initrd I used in my tests: I created +> two different-sized fake CDROM images by dd'ing from +> /dev/zero. In my tests, +> > cd1.img is smaller that cd2.img. In the monitor I +> executed 'change ide1-cd0 /spare2/cd2.img' to load the new +> image. I checked +> > the size by cat'ing /sys/block/sr0/size in the guest +> after reading the CDROM. Reading the CDROM was done by +> typing +> > 'dd if=/dev/sr0 of=/dev/null bs=512 count=3' +> +> Just to clarify, the contents of the image do change, but +> the reported +> size does not? +Correct? + + + + + + +On 10.11.2010, at 13:55, Alex Davis wrote: + +> --- On Tue, 11/9/10, agraf <email address hidden> wrote: +> +>> From: agraf <email address hidden> +>> Subject: Re: [Qemu-devel] [Bug 670769] Re: CDROM size not updated when changing image files +>> To: <email address hidden> +>> Date: Tuesday, November 9, 2010, 10:47 PM +>> +>> On 10.11.2010, at 04:17, Alex Davis wrote: +>> +>>> Please note that until this bug is fixed, one cannot +>> successfully +>>> install a guest OS from a set of CD-ROMS where the +>> first disk image is +>>> smaller than subsequent ones. +>>> +>>> -- +>>> CDROM size not updated when changing image files +>>> https://bugs.launchpad.net/bugs/670769 +>>> You received this bug notification because you are a +>> member of qemu- +>>> devel-ml, which is subscribed to QEMU. +>>> +>>> Status in QEMU: New +>>> +>>> Bug description: +>>> I'm using qemu 13.0 with a plain Linux kernel using +>> the ata_piix driver as the guest, and an initrd that starts +>> a shell. When changing the image in the monitor and reading +>> from the CDROM in the guest, the size is not updated. I'm +>> using LInux 2.6.32.24 +>>> as the host and I've tested 2.6.32.24, 2.6.35, and +>> 2.6.36 as guests. Both host and guest are 64-bit. Here +>> is the command used to start the guest using the initrd: +>>> +>>> ./x86_64-softmmu/qemu-system-x86_64 -cdrom +>> /spare2/cd1.img -kernel +>> /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd +>> /spare2/initrd.img -append 'root=/dev/ram0 rw' -cpu +>> core2duo +>>> +>>> Additional info on this bug can be found here: http://marc.info/?l=kvm&m=128746013906820&w=2. Note: +>> this is how I discovered +>>> the bug, using 32-bit Slackware install CDs. +>>> +>>> I'm attaching the initrd I used in my tests: I created +>> two different-sized fake CDROM images by dd'ing from +>> /dev/zero. In my tests, +>>> cd1.img is smaller that cd2.img. In the monitor I +>> executed 'change ide1-cd0 /spare2/cd2.img' to load the new +>> image. I checked +>>> the size by cat'ing /sys/block/sr0/size in the guest +>> after reading the CDROM. Reading the CDROM was done by +>> typing +>>> 'dd if=/dev/sr0 of=/dev/null bs=512 count=3' +>> +>> Just to clarify, the contents of the image do change, but +>> the reported +>> size does not? +> Correct? + +Sounds like a missing change event to the guest to me. + +Kevin, are you aware of this bug? + + +Alex + + + +I code, therefore I am + + +--- On Wed, 11/10/10, agraf <email address hidden> wrote: + +> From: agraf <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 670769] Re: CDROM size not updated when changing image files +> To: <email address hidden> +> Date: Wednesday, November 10, 2010, 8:11 AM +> +> On 10.11.2010, at 13:55, Alex Davis wrote: +> +> > --- On Tue, 11/9/10, agraf <email address hidden> +> wrote: +> > +> >> From: agraf <email address hidden> +> >> Subject: Re: [Qemu-devel] [Bug 670769] Re: CDROM +> size not updated when changing image files +> >> To: <email address hidden> +> >> Date: Tuesday, November 9, 2010, 10:47 PM +> >> +> >> On 10.11.2010, at 04:17, Alex Davis wrote: +> >> +> >>> Please note that until this bug is fixed, one +> cannot +> >> successfully +> >>> install a guest OS from a set of CD-ROMS where +> the +> >> first disk image is +> >>> smaller than subsequent ones. +> >>> +> >>> -- +> >>> CDROM size not updated when changing image +> files +> >>> https://bugs.launchpad.net/bugs/670769 +> >>> You received this bug notification because you +> are a +> >> member of qemu- +> >>> devel-ml, which is subscribed to QEMU. +> >>> +> >>> Status in QEMU: New +> >>> +> >>> Bug description: +> >>> I'm using qemu 13.0 with a plain Linux kernel +> using +> >> the ata_piix driver as the guest, and an initrd +> that starts +> >> a shell. When changing the image in the monitor +> and reading +> >> from the CDROM in the guest, the size is not +> updated. I'm +> >> using LInux 2.6.32.24 +> >>> as the host and I've tested 2.6.32.24, 2.6.35, +> and +> >> 2.6.36 as guests. Both host and guest are +> 64-bit. Here +> >> is the command used to start the guest using the +> initrd: +> >>> +> >>> ./x86_64-softmmu/qemu-system-x86_64 -cdrom +> >> /spare2/cd1.img -kernel +> >> +> /sources/linux-2.6.32.24-test/arch/x86/boot/bzImage -initrd +> >> /spare2/initrd.img -append 'root=/dev/ram0 rw' +> -cpu +> >> core2duo +> >>> +> >>> Additional info on this bug can be found here: +> http://marc.info/?l=kvm&m=128746013906820&w=2. Note: +> >> this is how I discovered +> >>> the bug, using 32-bit Slackware install CDs. +> >>> +> >>> I'm attaching the initrd I used in my tests: I +> created +> >> two different-sized fake CDROM images by dd'ing +> from +> >> /dev/zero. In my tests, +> >>> cd1.img is smaller that cd2.img. In the +> monitor I +> >> executed 'change ide1-cd0 /spare2/cd2.img' to load +> the new +> >> image. I checked +> >>> the size by cat'ing /sys/block/sr0/size in the +> guest +> >> after reading the CDROM. Reading the CDROM was +> done by +> >> typing +> >>> 'dd if=/dev/sr0 of=/dev/null bs=512 count=3' +> >> +> >> Just to clarify, the contents of the image do +> change, but +> >> the reported +> >> size does not? +> > Correct? +> +> Sounds like a missing change event to the guest to me. +> +> Kevin, are you aware of this bug? +> +I looks like change event is being sent, but it's being eaten by the +error recovery in the guest. + + + + +Looking through 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/672 b/results/classifier/108/other/672 new file mode 100644 index 00000000..306a4c0a --- /dev/null +++ b/results/classifier/108/other/672 @@ -0,0 +1,18 @@ +performance: 0.847 +device: 0.560 +other: 0.245 +boot: 0.140 +semantic: 0.097 +PID: 0.072 +network: 0.068 +debug: 0.058 +permissions: 0.048 +socket: 0.047 +graphic: 0.037 +files: 0.029 +vnc: 0.007 +KVM: 0.002 + +Slow emulation of mac99 (PowerPC G4) due to being single-threaded. +Additional information: +None diff --git a/results/classifier/108/other/672934 b/results/classifier/108/other/672934 new file mode 100644 index 00000000..95563915 --- /dev/null +++ b/results/classifier/108/other/672934 @@ -0,0 +1,97 @@ +permissions: 0.640 +PID: 0.606 +other: 0.600 +semantic: 0.571 +debug: 0.562 +boot: 0.527 +network: 0.513 +device: 0.482 +performance: 0.481 +files: 0.445 +vnc: 0.410 +KVM: 0.404 +socket: 0.392 +graphic: 0.291 + +FPU incorrect on Mac OS X + +I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I work for a university and the affected guest OS is our own research OS. I believe I found a bug in QEMU's FPU emulation, which only triggers on the Mac. You can reproduce the problem by booting the attached ISO image. + +Investigating the problem, I found that the lua interpreter in our loader component (called "ned") internally uses doubles to represent all lua-numbers. These doubles are showing completely wrong values on QEMU/Mac, resulting in the lua code not processing properly. + +I also attached a patch which fixes the problem for me. The attached ZIP-file also contains "before" and "after" screenshots. Note that booting the ISO on a real machine or on a Linux-QEMU always shows the correct "after" behavior. Only QEMU on the Mac exhibits the wrong "before" behavior without my patch. The patch might break other systems setting the CONFIG_BSD flag, so maybe the preprocessor should check for __APPLE__ instead to make the fix Mac-only. + + + + + + + + + + + +Looks like the ISO from comment #4 (thanks for attaching that one!) shows the correct behavior with up to date QEMU 2.7. Also, the affected softfloat code has been completely reworked in between (e.g. with commit cf67c6bad56d43e6d60), so I assume this has been fixed sometimes in the past years. + +I can confirm that recent QEMU works fine. Sorry, I forgot about this bug and did not update it. + + +On Sep 12, 2016, at 5:03 PM, <email address hidden> wrote: + +> Looks like the ISO from comment #4 (thanks for attaching that one!) +> shows the correct behavior with up to date QEMU 2.7. Also, the +> affected +> softfloat code has been completely reworked in between (e.g. with +> commit +> cf67c6bad56d43e6d60), so I assume this has been fixed sometimes in the +> past years. +> +> ** Changed in: qemu +> Status: New => Fix Released +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/672934 +> +> Title: +> FPU incorrect on Mac OS X +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I +> work for a university and the affected guest OS is our own research +> OS. I believe I found a bug in QEMU's FPU emulation, which only +> triggers on the Mac. You can reproduce the problem by booting the +> attached ISO image. +> +> Investigating the problem, I found that the lua interpreter in our +> loader component (called "ned") internally uses doubles to represent +> all lua-numbers. These doubles are showing completely wrong +> values on +> QEMU/Mac, resulting in the lua code not processing properly. +> +> I also attached a patch which fixes the problem for me. The attached +> ZIP-file also contains "before" and "after" screenshots. Note that +> booting the ISO on a real machine or on a Linux-QEMU always shows +> the +> correct "after" behavior. Only QEMU on the Mac exhibits the wrong +> "before" behavior without my patch. The patch might break other +> systems setting the CONFIG_BSD flag, so maybe the preprocessor +> should +> check for __APPLE__ instead to make the fix Mac-only. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/672934/+subscriptions +> + +I have always suspected a FPU bug with qemu-system-ppc. Apple's audio +processing code uses floating point code a lot. As a possible result +the playback of audio on a Mac OS guest is very poor. Is this a +problem with certain floating point instructions? Also could you send +me the patch. I would like to test it. Thanks. + +The patch is linked in my comment #5 above. However, the issue discussed here does not affect PPC, neither as the guest or host platform, so I’m not sure the patch applies to your problem. + diff --git a/results/classifier/108/other/673009 b/results/classifier/108/other/673009 new file mode 100644 index 00000000..2f3fc7e6 --- /dev/null +++ b/results/classifier/108/other/673009 @@ -0,0 +1,155 @@ +graphic: 0.841 +other: 0.813 +KVM: 0.803 +vnc: 0.721 +semantic: 0.712 +performance: 0.712 +debug: 0.675 +permissions: 0.659 +device: 0.656 +PID: 0.640 +boot: 0.622 +socket: 0.583 +files: 0.547 +network: 0.546 + +Latest git crashes in if_start with netBSD guest + +The latest version in git (cfd07e7abb1ef39373cd4ce312b015d61b9eea8d) crashes when running a NetBSD guest + +Host OS: Debian Linux/x86_64 5.0 +C Compiler: 4.4.5 +Guest OS:NetBSD/i386 5.0.2 +Command Line: +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: d33ea50a958b2e050d2b28e5f17e3b55e91c6d74 + +*** glibc detected *** /home/njh/src/qemu/i386-softmmu/qemu: free(): invalid pointer: 0x00000000025bd290 *** +======= Backtrace: ========= +/lib/libc.so.6(+0x71ad6)[0x7f15dfe0bad6] +/home/njh/src/qemu/i386-softmmu/qemu[0x492ff3] +/home/njh/src/qemu/i386-softmmu/qemu[0x494082] +/home/njh/src/qemu/i386-softmmu/qemu[0x49b38e] +/home/njh/src/qemu/i386-softmmu/qemu[0x49710a] +/home/njh/src/qemu/i386-softmmu/qemu[0x4947c7] +/home/njh/src/qemu/i386-softmmu/qemu[0x5181cc] +/home/njh/src/qemu/i386-softmmu/qemu[0x518c67] +/lib/libc.so.6(__libc_start_main+0xfd)[0x7f15dfdb8c4d] +/home/njh/src/qemu/i386-softmmu/qemu[0x407699] +======= Memory map: ======== +00400000-006a1000 r-xp 00000000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008a0000-008c4000 rw-p 002a0000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008c4000-010ae000 rw-p 00000000 00:00 0 +010ae000-010af000 rwxp 00000000 00:00 0 +010af000-010c7000 rw-p 00000000 00:00 0 +023a8000-024ab000 rw-p 00000000 00:00 0 +024ab000-024bb000 rw-p 00000000 00:00 0 +024bb000-025d5000 rw-p 00000000 00:00 0 +40a6f000-42a6f000 rwxp 00000000 00:00 0 +7f15d292b000-7f15d2941000 r-xp 00000000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2941000-7f15d2b40000 ---p 00016000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b40000-7f15d2b41000 rw-p 00015000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b41000-7f15d2b46000 r-xp 00000000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2b46000-7f15d2d45000 ---p 00005000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d45000-7f15d2d46000 rw-p 00004000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d46000-7f15d2d4f000 r-xp 00000000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2d4f000-7f15d2f4f000 ---p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f4f000-7f15d2f50000 rw-p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f50000-7f15d2f9d000 rw-p 00000000 00:00 0 +7f15d3025000-7f15d319a000 r--p 00000000 08:03 298138 /usr/lib/locale/locale-archive +7f15d319a000-7f15d31a2000 r-xp 00000000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d31a2000-7f15d33a1000 ---p 00008000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a1000-7f15d33a2000 rw-p 00007000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a2000-7f15d33ab000 r-xp 00000000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d33ab000-7f15d35ab000 ---p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ab000-7f15d35ac000 rw-p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ac000-7f15d35bd000 r-xp 00000000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d35bd000-7f15d37bd000 ---p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37bd000-7f15d37be000 rw-p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37d2000-7f15d37d3000 ---p 00000000 00:00 0 +7f15d37d3000-7f15d3c36000 rw-p 00000000 00:00 0 +7f15d3c49000-7f15d3d63000 rw-s 00000000 00:04 2195492 /SYSV00000000 (deleted) +7f15d3d63000-7f15d3d64000 rw-p 00000000 00:00 0 +7f15d3d64000-7f15d4564000 rw-p 00000000 00:00 0 +7f15d4564000-7f15d4566000 rw-p 00000000 00:00 0 +7f15d4566000-7f15dc566000 rw-p 00000000 00:00 0 +7f15dc566000-7f15dc567000 rw-p 00000000 00:00 0 +7f15dc567000-7f15dc568000 ---p 00000000 00:00 0 +7f15dc568000-7f15de76a000 rw-p 00000000 00:00 0 +7f15de76a000-7f15de76f000 r-xp 00000000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de76f000-7f15de96e000 ---p 00005000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96e000-7f15de96f000 rw-p 00004000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96f000-7f15de971000 r-xp 00000000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15de971000-7f15deb71000 ---p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb71000-7f15deb72000 rw-p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb72000-7f15deb91000 r-xp 00000000 08:03 134345 /lib/libx86.so.1 +7f15deb91000-7f15ded91000 ---p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded91000-7f15ded93000 rw-p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded93000-7f15ded94000 rw-p 00000000 00:00 0 +7f15ded94000-7f15dedb0000 r-xp 00000000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15dedb0000-7f15defaf000 ---p 0001c000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defaf000-7f15defb0000 rw-p 0001b000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defb0000-7f15deffd000 r-xp 00000000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15deffd000-7f15df1fc000 ---p 0004d000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df1fc000-7f15df205000 rw-p 0004c000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df205000-7f15df20e000 rw-p 00000000 00:00 0 +7f15df20e000-7f15df224000 r-xp 00000000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df224000-7f15df423000 ---p 00016000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df423000-7f15df425000 rw-p 00015000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df425000-7f15df42e000 r-xp 00000000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df42e000-7f15df62e000 ---p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62e000-7f15df62f000 rw-p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62f000-7f15df6ae000 r-xp 00000000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df6ae000-7f15df8ad000 ---p 0007f000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8ad000-7f15df8b1000 rw-p 0007e000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8b1000-7f15df98f000 r-xp 00000000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15df98f000-7f15dfb8e000 ---p 000de000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb8e000-7f15dfb96000 rw-p 000dd000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb96000-7f15dfb98000 r-xp 00000000 08:03 163705 /lib/libdl-2.11.2.so +7f15dfb98000-7f15dfd98000 ---p 00002000 08:03 163705 /lib/libdl-2.11.2.so + +GDB output: + +Thread 3 (Thread 3756): +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 +#1 0x00007f15e182a0e9 in _L_lock_953 () from /lib/libpthread.so.0 +#2 0x00007f15e1829f0b in __pthread_mutex_lock (mutex=0x10690c0) at pthread_mutex_lock.c:61 +#3 0x00000000004914f9 in qemu_mutex_lock (mutex=0x10690c0) at qemu-thread.c:50 +#4 0x0000000000408c4c in qemu_mutex_lock_iothread () at /home/njh/src/qemu/cpus.c:737 +#5 0x000000000041af8e in kvm_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/kvm-all.c:878 +#6 0x00000000004a7885 in cpu_x86_exec (env1=<value optimized out>) at /home/njh/src/qemu/cpu-exec.c:338 +#7 0x00000000004086e8 in qemu_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/cpus.c:896 +#8 0x00000000004099e4 in kvm_cpu_thread_fn (arg=<value optimized out>) at /home/njh/src/qemu/cpus.c:613 +#9 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#10 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#11 0x0000000000000000 in ?? () + +Thread 2 (Thread 3757): +#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211 +#1 0x000000000042ca0b in cond_timedwait (unused=<value optimized out>) at posix-aio-compat.c:104 +#2 aio_thread (unused=<value optimized out>) at posix-aio-compat.c:325 +#3 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#4 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#5 0x0000000000000000 in ?? () +Current language: auto +The current source language is "auto; currently asm". + +Thread 1 (Thread 3755): +#0 0x00007f15dfdcc165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 +#1 0x00007f15dfdcef70 in *__GI_abort () at abort.c:92 +#2 0x00007f15dfe0227b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 +#3 0x00007f15dfe0bad6 in malloc_printerr (action=3, str=0x7f15dfebfb75 "free(): invalid pointer", ptr=<value optimized out>) at malloc.c:6267 +#4 0x0000000000492ff3 in if_start (slirp=0x23aa400) at slirp/if.c:205 +#5 0x0000000000494082 in ip_output (so=<value optimized out>, m0=0x25d3ff0) at slirp/ip_output.c:160 +#6 0x000000000049b38e in udp_output (so=0xeab, m=0xeab, addr=<value optimized out>) at slirp/udp.c:299 +#7 0x000000000049710a in sorecvfrom (so=0x2529380) at slirp/socket.c:527 +#8 0x00000000004947c7 in slirp_select_poll (readfds=0x7fff99a79390, writefds=<value optimized out>, xfds=0x7fff99a79290, select_error=<value optimized out>) + at slirp/slirp.c:542 +#9 0x00000000005181cc in main_loop_wait (nonblocking=<value optimized out>) at /home/njh/src/qemu/vl.c:1266 +#10 0x0000000000518c67 in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:1309 +#11 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:2999 + +I assume this problem has been fixed nowadays ... or can you still somehow reproduce it with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/674 b/results/classifier/108/other/674 new file mode 100644 index 00000000..3018c034 --- /dev/null +++ b/results/classifier/108/other/674 @@ -0,0 +1,29 @@ +graphic: 0.853 +device: 0.791 +boot: 0.712 +socket: 0.702 +PID: 0.672 +files: 0.663 +performance: 0.632 +KVM: 0.608 +debug: 0.604 +vnc: 0.598 +semantic: 0.596 +permissions: 0.536 +network: 0.486 +other: 0.271 + +Windows 7 fails with blue screen when KVM is enabled. +Description of problem: +The problem appeared immediately after a full system update of Arch Linux (The first for several months). Windows 7 images that had been running normally would fail with a blue screen and Error 0x7E immediately after displaying "Starting Windows". The same error would occur with a Windows 7 installation image, as in the command line above. When the "-enable-kvm" option was removed Windows would run normally but slowly. An old Clonezilla image booted without apparent problems. + +The final line on the blue screen reads: +*** STOP: 0x0000007E (0xC0000005,0x8BA3CA36,0x85186AA0,0x85186680) + +After getting the problem with the Arch package I cloned the source and built the latest version, getting the same error. However, when I build version 5.2.95 (v6.0.0-rc5-dirty) I found that this would run my existing Windows images (qcow2) and the installation ISO image. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/108/other/676934 b/results/classifier/108/other/676934 new file mode 100644 index 00000000..2c4ad77c --- /dev/null +++ b/results/classifier/108/other/676934 @@ -0,0 +1,33 @@ +network: 0.812 +socket: 0.755 +device: 0.684 +graphic: 0.502 +other: 0.501 +semantic: 0.455 +performance: 0.319 +PID: 0.308 +boot: 0.300 +permissions: 0.293 +vnc: 0.242 +debug: 0.198 +files: 0.085 +KVM: 0.056 + +Ability to use -net socket with unix sockets + +It would be a nice feature (simplifying access control for example) to be able to do something like: + +qemu -net socket,listen=unix:/tmp/qemunet +qemu -net socket,connect=unix:/tmp/qemunet + +For now one has to use TCP connections even for guests running on the same host, which involves setting up iptables to restrict access. + +Aren't these at different levels of the stack? Network devices deal in packets not connections. It sounds like you want to use something like vsock which provides a virtual socket device to the guest. + +This is just about connecting the NIC backends for 2 QEMUs together using a UNIX socket, instead of the current TCP/UDP socket. It should be fairly trivial to support i would expect. Though ideally we'd port the netdev socket backend to use QIOChannel too + + +This is an automated cleanup. This bug report got closed because it +is a duplicate. + + diff --git a/results/classifier/108/other/677 b/results/classifier/108/other/677 new file mode 100644 index 00000000..d85f194a --- /dev/null +++ b/results/classifier/108/other/677 @@ -0,0 +1,16 @@ +performance: 0.872 +device: 0.867 +graphic: 0.681 +debug: 0.422 +boot: 0.347 +permissions: 0.112 +network: 0.100 +semantic: 0.097 +PID: 0.093 +other: 0.089 +vnc: 0.026 +socket: 0.005 +files: 0.003 +KVM: 0.002 + +Qemu crashes when trying to load kernel inside of WSL2 diff --git a/results/classifier/108/other/678363 b/results/classifier/108/other/678363 new file mode 100644 index 00000000..d08c9024 --- /dev/null +++ b/results/classifier/108/other/678363 @@ -0,0 +1,35 @@ +graphic: 0.858 +device: 0.748 +performance: 0.721 +other: 0.635 +semantic: 0.596 +network: 0.316 +permissions: 0.296 +socket: 0.224 +boot: 0.197 +vnc: 0.176 +PID: 0.174 +debug: 0.140 +files: 0.101 +KVM: 0.043 + +Swapping caps lock and control causes qemu confusion + +Running Fedora14 [host], I have caps-lock and control swapped over in my keyboard preferences. + +Qemu doesn't cope very well with this; running an OS inside Qemu (again fedora, suspect that it doesn't matter): + +The physical caps-lock key [which the host uses as control] toggles caps-lock on both press and release. + +The physical control key [which the host uses as caps-lock], acts as both a caps-lock and control key. + +Qemu should either respect my keyboard layout or else ignore it completely. + +Which interface is this? + +I suspect this behaves differently in GTK/SDL/... + +Also it seems to WorkForMe(tm) mostly. qemu tends to ignore the layout completely so installing same keymap in host and guest gives consistent result, and other configurations give inconsistent but correct result. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/679 b/results/classifier/108/other/679 new file mode 100644 index 00000000..f0d955a7 --- /dev/null +++ b/results/classifier/108/other/679 @@ -0,0 +1,16 @@ +device: 0.908 +performance: 0.809 +network: 0.630 +graphic: 0.610 +debug: 0.473 +boot: 0.216 +semantic: 0.200 +socket: 0.148 +PID: 0.134 +permissions: 0.106 +files: 0.100 +other: 0.047 +vnc: 0.024 +KVM: 0.002 + +powerpc/e500: QEMU freeze without any output when kernel size is a bit big |