diff options
Diffstat (limited to 'results/classifier/108/boot')
34 files changed, 2558 insertions, 0 deletions
diff --git a/results/classifier/108/boot/1021649 b/results/classifier/108/boot/1021649 new file mode 100644 index 000000000..df38b61e8 --- /dev/null +++ b/results/classifier/108/boot/1021649 @@ -0,0 +1,127 @@ +boot: 0.928 +debug: 0.912 +device: 0.909 +vnc: 0.894 +PID: 0.894 +other: 0.890 +graphic: 0.888 +performance: 0.887 +socket: 0.859 +semantic: 0.857 +permissions: 0.845 +network: 0.834 +files: 0.828 +KVM: 0.827 + +qemu 1.1.0 waits for a keypress at boot + +qemu 1.1.0 waits for a keypress at boot. Please don't ever do this. + +Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard. + +Removing -nographic fixes the problem. + +Using virtio-scsi instead of virtio-blk fixes the problem. + + + +Also affects upstream qemu from git. + +Using -device sga fixes the problem, but also means I cannot see what it's trying to wait for. + +I don't see this problem. Are you sure you're not using the bios from Fedora? Perhaps it's configured incorrectly. + +Yes, I tested it again and it does look like it's loading a Fedora ROM. Dammit ... + +This is a bit more interesting. I've got a bugreport in debian about the same thing, and verified it in debian qemu-kvm package - indeed, with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without an extra keypress, but only when kernel_irqchip is enabled. Ie, the following requires keypress: + + qemu -machine pc,accel=kvm,kernel_irqchip=on -nographics + qemu-kvm -nographics + +and the following does not: + + qemu -machine pc,accel=kvm -nographics + qemu-kvm -no-kvm-irqchip -nographics + +Thanks, + +/mjt + + +Well that's very interesting because one of the patches we have added in Fedora is: + +http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=0001-qemu-kvm-Add-missing-default-machine-options.patch;h=e785a708d0bf0861c2f0f1777b8cc477d12fe145;hb=HEAD + +when the guest is waiting for the keypress, it is sitting in KVM_RUN ioctl and eating 100% CPU. When enabling Seabios debugging, the last lines before the stall is this: + +Returned 57344 bytes of ZoneHigh +e820 map has 7 items: + 0: 0000000000000000 - 000000000009dc00 = 1 RAM + 1: 000000000009dc00 - 00000000000a0000 = 2 RESERVED + 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED + 3: 0000000000100000 - 000000001fffe000 = 1 RAM + 4: 000000001fffe000 - 0000000020000000 = 2 RESERVED + 5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED + 6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED +enter handle_19: + NULL +Booting from Hard Disk... +_ + + +So far it only happens when "booting" from a VIRTIO hard disk. With IDE disk it boots fine. + +So, in order for it to actually stall, + + qemu -machine pc,accel=kvm,kernel_irqchip=on -drive file=foo,if=virtio -nographics + +is needed. + +Thanks, + +/mjt + + +Jamie Heilman (the debian bug #680719 reporter) bisected this issue to this commit: + +7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit +commit 7c7db75576bd5a31508208f153c5aada64b2c8df +Author: Stefano Stabellini <email address hidden> +Date: Fri Apr 13 19:35:04 2012 +0100 + + main_loop_wait: block indefinitely + + - remove qemu_calculate_timeout; + + - explicitly size timeout to uint32_t; + + - introduce slirp_update_timeout; + + - pass NULL as timeout argument to select in case timeout is the maximum + value; + + Signed-off-by: Stefano Stabellini <email address hidden> + Acked-by: Paul Brook <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + + +I encountered the same thing and created a patch that fixes the problem for me. + +This is not a real fix. All i have done is the following: +- Clone the repo. +- Get a reverse diff for the commit in question "git diff 7c7db75..4ffd16f >foo1.patch". +- Try to apply this on master "patch <foo1.patch" and skip all files that could not be found. +- And finally do a "git diff >remove-7c7db75.patch" + +As i am a gentoo user i applied this patch within my ebuild and + +This is definitely a wrong way to "fix" this issue. + +The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828 fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to the select() arguments), but I and Avi disagreed on whether ioeventfd=off works. :) + +Jamie/Richard/Georg, can you test your respective reproducers without any patch but with -global virtio-blk-pci.ioeventfd=off? + +Can this issue still be reproduced with the latest version of QEMU, or can we close this bug nowadays? + +No this refers to a very old version of qemu. This bug should be closed. + diff --git a/results/classifier/108/boot/1055090 b/results/classifier/108/boot/1055090 new file mode 100644 index 000000000..d1ede0117 --- /dev/null +++ b/results/classifier/108/boot/1055090 @@ -0,0 +1,41 @@ +boot: 0.930 +device: 0.754 +PID: 0.716 +network: 0.672 +performance: 0.602 +socket: 0.585 +files: 0.564 +semantic: 0.556 +vnc: 0.541 +debug: 0.527 +graphic: 0.515 +permissions: 0.396 +other: 0.334 +KVM: 0.055 + +esp error: NetBSD/sparc on qemu-system-sparc + +On qemu-1.2.0's qemu-system-sparc, NetBSD/sparc (32bit) 5.1.2 and 6.0_RC2 generates the following NetBSD's errors. + +esp0: !TC on DATA XFER [intr 18, stat 82, step 4] prevphase 2, resid 0 +esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0 + +On qemu-0.15.1's qemu-system-sparc, NetBSD/sparc 5.1.2 and 6.0_RC2 works fine. + +To reproduce with NetBSD/sparc 6.0_RC2, run + +% qemu-system-sparc -M SS-20 -m 265M -hda NetBSD-sparc-6.0_RC2.qed -nographic -cdrom NetBSD-6.0_RC2-sparc.iso -boot d + +and try to install NetBSD. You can get above errors when newfs command is invoked. +I can reporduce this problem on NetBSD/i386 (32bit) and NetBSD/amd64(64bit; x86_64) host OSes. + +NetBSD-6.0_RC2-sparc.iso is here, +ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0_RC2/images/NetBSD-6.0_RC2-sparc.iso + +NetBSD-sparc-6.0_RC2.qed is created with +% qemu-img create -f qed NetBSD-sparc-6.0_RC2.qed 3G + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU (and NetBSD)? 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/boot/1119281 b/results/classifier/108/boot/1119281 new file mode 100644 index 000000000..db23ae6d1 --- /dev/null +++ b/results/classifier/108/boot/1119281 @@ -0,0 +1,828 @@ +boot: 0.962 +semantic: 0.950 +other: 0.948 +device: 0.944 +network: 0.940 +PID: 0.940 +permissions: 0.939 +socket: 0.935 +files: 0.916 +graphic: 0.913 +performance: 0.906 +debug: 0.895 +KVM: 0.890 +vnc: 0.888 + +The virtio network device breaks UuidCreateSequential() + +UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue. + +Here is the software I have tested this with: + * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) + * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. + + +Here is how to test for this issue: +* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. + +* Boot the guest and copy the uuidtest.exe file (see attachement) to it + +* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below: + + Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 + +* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0. + + UuidCreateSequential() returned 0 + uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} + Got a version 1 UUID + The UUID does not contain a non-multicast MAC address + +* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be. + +* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address. + + +(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +(2) Best do it with a single card to avoid confusion over which is the primary one. +(3) If the first byte of the address is odd then this is a multicast address. + https://en.wikipedia.org/wiki/MAC_address#Address_details + + + +On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote: +> Public bug reported: +> +> UuidCreateSequential() usually creates version 1 UUIDs (1) which means +> they contain the main network card's MAC address. However when using a +> virtio network card and driver the UUIDs contain random data instead of +> the guest's MAC address. Changing the network card to either the default +> rtl8139 one or the e1000 one fixes the issue. + +CCing Yan and Vadim, who work on the virtio-win drivers. + +> +> Here is the software I have tested this with: +> * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) +> * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ +> * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. +> +> +> Here is how to test for this issue: +> * Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. +> +> * Boot the guest and copy the uuidtest.exe file (see attachement) to it +> +> * On the command line, type 'ipconfig /all'. Give you the correct +> network card's MAC address on a line like the one below: +> +> Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 +> +> * Run uuidtest.exe. It will show the VM returning a UUID with the wrong +> MAC address, and quite possibly even a multicast MAC address! (3). In +> the example below 'f75292c62787' should have been the MAC address. Note +> that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY +> for virtio cards but that on Windows 7 it returns 0. +> +> UuidCreateSequential() returned 0 +> uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} +> Got a version 1 UUID +> The UUID does not contain a non-multicast MAC address +> +> * Reboot and notice uuidtest.exe now reports a different value where the +> MAC address should be. +> +> * Shut down the VM and switch the network card to rtl8139, install the +> drivers, run uuidtest.exe and notice that the last group of digits +> finally contains the correct MAC address. +> +> +> (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +> (2) Best do it with a single card to avoid confusion over which is the primary one. +> (3) If the first byte of the address is odd then this is a multicast address. +> https://en.wikipedia.org/wiki/MAC_address#Address_details +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "Test executable and source" +> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2 + + +On Mon, Feb 11, 2013 at 11:13 AM, Stefan Hajnoczi <email address hidden>wrote: + +> On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote: +> > Public bug reported: +> > +> > UuidCreateSequential() usually creates version 1 UUIDs (1) which means +> > they contain the main network card's MAC address. However when using a +> > virtio network card and driver the UUIDs contain random data instead of +> > the guest's MAC address. Changing the network card to either the default +> > rtl8139 one or the e1000 one fixes the issue. +> +> CCing Yan and Vadim, who work on the virtio-win drivers. +> +> > +> > Here is the software I have tested this with: +> > * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and +> Experimental respectively) +> > * The 0.1-49 and 0.1-52 Windows virtio drivers from +> https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ +> > * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. +> > +> > +> > Here is how to test for this issue: +> > * Set up a Windows guest with a single network card(2), a virtio one and +> install the corresponding driver. +> > +> > * Boot the guest and copy the uuidtest.exe file (see attachement) to it +> > +> > * On the command line, type 'ipconfig /all'. Give you the correct +> > network card's MAC address on a line like the one below: +> > +> > Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 +> > +> > * Run uuidtest.exe. It will show the VM returning a UUID with the wrong +> > MAC address, and quite possibly even a multicast MAC address! (3). In +> > the example below 'f75292c62787' should have been the MAC address. Note +> > that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY +> > for virtio cards but that on Windows 7 it returns 0. +> > +> > UuidCreateSequential() returned 0 +> > uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} +> > Got a version 1 UUID +> > The UUID does not contain a non-multicast MAC address +> > +> > * Reboot and notice uuidtest.exe now reports a different value where the +> > MAC address should be. +> > +> > * Shut down the VM and switch the network card to rtl8139, install the +> > drivers, run uuidtest.exe and notice that the last group of digits +> > finally contains the correct MAC address. +> > +> > +> > (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +> > (2) Best do it with a single card to avoid confusion over which is the +> primary one. +> > (3) If the first byte of the address is odd then this is a multicast +> address. +> > https://en.wikipedia.org/wiki/MAC_address#Address_details +> > +> > ** Affects: qemu +> > Importance: Undecided +> > Status: New +> > +> > ** Attachment added: "Test executable and source" +> > +> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2 +> + + +I did a quick check for this issue. First off all +while UuidCreateSequential should use mac address, there is no indication +that it must do it. And as we don't have source code for Rpcrt4.lib it is +hard to estimated what should be the exact behavior of this function (I can +use reactos source code - but we cannot count on it). +What I see from our debug trace that there are no OID calls to NIC while +using this function to get our current or permanent MAC address. And we +know that those OIDs work well: a. because you see correct MAC using +ipconfig of getmac (also is verified by Red Hat QE during manual functional +tests). b. We pass WHQL tests that set valid and invalid mac addresses +automatically and tests for correct behavior. So UuidCreateSequential +either takes this value from somewhere in registry or generates it by some +other mean. + +I can try and assume how it should work using ReactOS code. +From reactos UuidCreateSequential: +http://doxygen.reactos.org/df/def/rpcdce_8h_a884acec185f2f0a999a8375cd04f61c9.html +It will use GetAdaptersInfo. I ran the code in the MS documentation +http://msdn.microsoft.com/en-us/library/windows/desktop/aa365917(v=vs.85).aspx- +and once again the mac address of virtio adapter is correct. + + +Might be related: +http://support.microsoft.com/kb/981080?wa=wsignin1.0 +http://support.microsoft.com/kb/2569646 + + +Best regards, +Yan. + + +This bug is still present in QEM 1.6.0 (qemu-system-x86 1.6.0+dfsg-1) and/or Virtio 0.1-65. + +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.] + + + + + +The issue is still there in 2023. +Well since XP's source code had been leaked. I've gone through the source code and may have found the cause. + +Nowadays UuidCreateSequential should use MAC address when available. +Here I quoted from the link below: +"For security reasons, UuidCreate was modified so that it no longer uses a machine's MAC address to generate UUIDs. UuidCreateSequential was introduced to allow creation of UUIDs using the MAC address of a machine's Ethernet card." +https://learn.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidcreatesequential + +Now let take a look at XP's code: +UuidCreateSequential() in dceuuid.cxx: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/rpc/runtime/mtrt/dceuuid.cxx#L122 + +RPC_STATUS RPC_ENTRY +UuidCreateSequential ( + OUT UUID PAPI * Uuid + ) +/*++ + +Routine Description: + + This routine will create a new UUID (or GUID) which is unique in + time and space. We will try to guarantee that the UUID (or GUID) + we generate is unique in time and space. This means that this + routine may fail if we can not generate one which we can guarantee + is unique in time and space. + +Arguments: + + Uuid - Returns the generated UUID (or GUID). + +Return Value: + + RPC_S_OK - The operation completed successfully. + + RPC_S_UUID_NO_ADDRESS - We were unable to obtain the ethernet or + token ring address for this machine. + + RPC_S_UUID_LOCAL_ONLY - On NT & Chicago if we can't get a + network address. This is a warning to the user, the + UUID is still valid, it just may not be unique on other machines. + + RPC_S_OUT_OF_MEMORY - Returned as needed. +--*/ +{ + RPC_UUID_GENERATE PAPI * RpcUuid = (RPC_UUID_GENERATE PAPI *) Uuid; + RPC_STATUS Status = RPC_S_OK; + static DWORD LastTickCount = 0; + + InitializeIfNecessary(); + + if (GetTickCount()-LastTickCount > MAX_CACHED_UUID_TIME) + { + UuidCachedValues.AllocatedCount = 0; + LastTickCount = GetTickCount(); + } + + ULARGE_INTEGER Time; + long Delta; + + for(;;) + { + Time.QuadPart = UuidCachedValues.Time.QuadPart; + + // Copy the static info into the UUID. We can't do this later + // because the clock sequence could be updated by another thread. + + *(unsigned long *)&RpcUuid->ClockSeqHiAndReserved = + *(unsigned long *)&UuidCachedValues.ClockSeqHiAndReserved; + *(unsigned long *)&RpcUuid->NodeId[2] = + *(unsigned long *)&UuidCachedValues.NodeId[2]; + + Delta = InterlockedDecrement(&UuidCachedValues.AllocatedCount); + + if (Time.QuadPart != UuidCachedValues.Time.QuadPart) + { + // If our captured time doesn't match the cache then another + // thread already took the lock and updated the cache. We'll + // just loop and try again. + continue; + } + + if (Delta >= 0) + { + break; + } + + // + // Allocate block of Uuids. + // + + Status = UuidGetValues( &UuidCachedValues ); + if (Status == RPC_S_OK) + { + UuidCacheValid = CACHE_VALID; + } + else + { + UuidCacheValid = CACHE_LOCAL_ONLY; + } + + if (Status != RPC_S_OK + && Status != RPC_S_UUID_LOCAL_ONLY) + { +#ifdef DEBUGRPC + if (Status != RPC_S_OUT_OF_MEMORY) + PrintToDebugger("RPC: UuidGetValues returned or raised: %x\n", Status); +#endif + ASSERT( (Status == RPC_S_OUT_OF_MEMORY) ); + + + return Status; + } + + // Loop + } + + + Time.QuadPart -= Delta; + + RpcUuid->TimeLow = (unsigned long) Time.LowPart; + RpcUuid->TimeMid = (unsigned short) (Time.HighPart & 0x0000FFFF); + RpcUuid->TimeHiAndVersion = (unsigned short) + (( (unsigned short)(Time.HighPart >> 16) + & RPC_UUID_TIME_HIGH_MASK) | RPC_UUID_VERSION); + + ASSERT( Status == RPC_S_OK + || Status == RPC_S_UUID_LOCAL_ONLY); + + if (UuidCacheValid == CACHE_LOCAL_ONLY) + { + return RPC_S_UUID_LOCAL_ONLY; + } + + return(Status); +} + +UuidGetValues() in uuidsup.cxx: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/rpc/runtime/mtrt/uuidsup.cxx#L43 + +UuidGetValues( + OUT UUID_CACHED_VALUES_STRUCT __RPC_FAR *Values + ) +/*++ + +Routine Description: + + This routine allocates a block of uuids for UuidCreate to handout. + +Arguments: + + Values - Set to contain everything needed to allocate a block of uuids. + The following fields will be updated here: + + NextTimeLow - Together with LastTimeLow, this denotes the boundaries + of a block of Uuids. The values between NextTimeLow + and LastTimeLow are used in a sequence of Uuids returned + by UuidCreate(). + + LastTimeLow - See NextTimeLow. + + ClockSequence - Clock sequence field in the uuid. This is changed + when the clock is set backward. + +Return Value: + + RPC_S_OK - We successfully allocated a block of uuids. + + RPC_S_OUT_OF_MEMORY - As needed. +--*/ +{ + NTSTATUS NtStatus; + ULARGE_INTEGER Time; + ULONG Range; + ULONG Sequence; + int Tries = 0; + + do { + NtStatus = NtAllocateUuids(&Time, &Range, &Sequence, (char *) &Values->NodeId[0]); + + if (NtStatus == STATUS_RETRY) + { + Sleep(1); + } + + Tries++; + + if (Tries == 20) + { +#ifdef DEBUGRPC + PrintToDebugger("Rpc: NtAllocateUuids retried 20 times!\n"); + ASSERT(Tries < 20); +#endif + NtStatus = STATUS_UNSUCCESSFUL; + } + + } while(NtStatus == STATUS_RETRY); + + if (!NT_SUCCESS(NtStatus)) + { + return(RPC_S_OUT_OF_MEMORY); + } + + // NtAllocateUuids keeps time in SYSTEM_TIME format which is 100ns ticks since + // Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582. + + // 17 Days in Oct + 30 (Nov) + 31 (Dec) + 18 years and 5 leap days. + + Time.QuadPart += (unsigned __int64) (1000*1000*10) // seconds + * (unsigned __int64) (60 * 60 * 24) // days + * (unsigned __int64) (17+30+31+365*18+5); // # of days + + ASSERT(Range); + + Values->ClockSeqHiAndReserved = + RPC_UUID_RESERVED | (((unsigned char) (Sequence >> 8)) + & (unsigned char) RPC_UUID_CLOCK_SEQ_HI_MASK); + + Values->ClockSeqLow = (unsigned char) (Sequence & 0x00FF); + + // The order of these assignments is important + + Values->Time.QuadPart = Time.QuadPart + (Range - 1); + Values->AllocatedCount = Range; + + if ((Values->NodeId[0] & 0x80) == 0) + { + return(RPC_S_OK); + } + + return (RPC_S_UUID_LOCAL_ONLY); +} + + +NtAllocateUuids() in uuid.c: +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/base/ntos/ex/uuid.c#L545 + +/*++ + +Copyright (c) 1994-1997 Microsoft Corporation + +Module Name: + + uuid.c + +Abstract: + + This module implements the core time and sequence number allocation + for UUIDs (exposed to user mode), as well as complete UUID + creation (exposed to kernel mode only). + + (e.g. RPC Runtime) (e.g. NTFS) + | | + V V + NtAllocateUuids ExUuidCreate + | | + V V + | ExpUuidGetValues + | | + | | + +------> ExpAllocateUuids <----+ +NTSTATUS +NtAllocateUuids ( + OUT PULARGE_INTEGER Time, + OUT PULONG Range, + OUT PULONG Sequence, + OUT PCHAR Seed + ) + +/*++ + +Routine Description: + + This function reserves a range of time for the caller(s) to use for + handing out Uuids. As far a possible the same range of time and + sequence number will never be given out. + + (It's possible to reboot 2^14-1 times and set the clock backwards and then + call this allocator and get a duplicate. Since only the low 14bits of the + sequence number are used in a real uuid.) + +Arguments: + + Time - Supplies the address of a variable that will receive the + start time (SYSTEMTIME format) of the range of time reserved. + + Range - Supplies the address of a variable that will receive the + number of ticks (100ns) reserved after the value in Time. + The range reserved is *Time to (*Time + *Range - 1). + + Sequence - Supplies the address of a variable that will receive + the time sequence number. This value is used with the associated + range of time to prevent problems with clocks going backwards. + + Seed - Pointer to a 6 byte buffer. The current seed is written into this buffer. + +Return Value: + + STATUS_SUCCESS is returned if the service is successfully executed. + + STATUS_RETRY is returned if we're unable to reserve a range of + UUIDs. This may (?) occur if system clock hasn't advanced + and the allocator is out of cached values. + + STATUS_ACCESS_VIOLATION is returned if the output parameter for the + UUID cannot be written. + + STATUS_UNSUCCESSFUL is returned if some other service reports + an error, most likly the registery. + +--*/ + +{ + + KPROCESSOR_MODE PreviousMode; + NTSTATUS Status; + + LARGE_INTEGER OutputTime; + ULONG OutputRange; + ULONG OutputSequence; + PKTHREAD CurrentThread; + + PAGED_CODE(); + + // + // Establish an exception handler and attempt to write the output + // arguments. If the write attempt fails, then return + // the exception code as the service status. Otherwise return success + // as the service status. + // + + try { + + // + // Get previous processor mode and probe arguments if necessary. + // + + PreviousMode = KeGetPreviousMode(); + if (PreviousMode != KernelMode) { + ProbeForWriteSmallStructure((PVOID)Time, sizeof(LARGE_INTEGER), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Range, sizeof(ULONG), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Sequence, sizeof(ULONG), sizeof(ULONG)); + ProbeForWriteSmallStructure((PVOID)Seed, SEED_SIZE, sizeof(CHAR)); + } + } except (ExSystemExceptionFilter()) { + return GetExceptionCode(); + } + + // Take the lock, because we're about to update the UUID cache. + CurrentThread = KeGetCurrentThread (); + KeEnterCriticalRegionThread(CurrentThread); + ExAcquireFastMutexUnsafe(&ExpUuidLock); + + // Get the sequence number and a range of times that can + // be used in UUID-generation. + + Status = ExpAllocateUuids( &OutputTime, &OutputRange, &OutputSequence ); + + if( !NT_SUCCESS(Status) ) { + ExReleaseFastMutexUnsafe(&ExpUuidLock); + KeLeaveCriticalRegionThread(CurrentThread); + return( Status ); + } + + // If necessary, save the sequence number. If there's an error, + // we'll just leave it marked as dirty, and retry on some future call. + + ExpUuidSaveSequenceNumberIf(); + + // Release the lock + ExReleaseFastMutexUnsafe(&ExpUuidLock); + KeLeaveCriticalRegionThread(CurrentThread); + + // + // Attempt to store the result of this call into the output parameters. + // This is done within an exception handler in case output parameters + // are now invalid. + // + + try { + Time->QuadPart = OutputTime.QuadPart; + *Range = OutputRange; + *Sequence = OutputSequence; + RtlCopyMemory((PVOID) Seed, &ExpUuidCachedValues.NodeId[0], SEED_SIZE); + } except (ExSystemExceptionFilter()) { + return GetExceptionCode(); + } + + return(STATUS_SUCCESS); +} + + +NTSTATUS +NtSetUuidSeed ( + IN PCHAR Seed + ) +/*++ + +Routine Description: + + This routine is used to set the seed used for UUID generation. The seed + will be set by RPCSS at startup and each time a card is replaced. + +Arguments: + + Seed - Pointer to a six byte buffer + +Return Value: + + STATUS_SUCCESS is returned if the service is successfully executed. + + STATUS_ACCESS_DENIED If caller doesn't have the permissions to make this call. + You need to be logged on as Local System in order to call this API. + + STATUS_ACCESS_VIOLATION is returned if the Seed could not be read. + +--*/ +{ + NTSTATUS Status; + LUID AuthenticationId; + SECURITY_SUBJECT_CONTEXT SubjectContext; + LUID SystemLuid = SYSTEM_LUID; + BOOLEAN CapturedSubjectContext = FALSE; + + PAGED_CODE(); + + ASSERT(KeGetPreviousMode() != KernelMode); + + try { + // + // Check if the caller has the appropriate permission + // + SeCaptureSubjectContext(&SubjectContext); + CapturedSubjectContext = TRUE; + + Status = SeQueryAuthenticationIdToken( + SeQuerySubjectContextToken(&SubjectContext), + &AuthenticationId); + if (!NT_SUCCESS(Status)) { + ExRaiseStatus(Status); + } + + if (RtlCompareMemory(&AuthenticationId, &SystemLuid, sizeof(LUID)) != sizeof(LUID)) { + ExRaiseStatus(STATUS_ACCESS_DENIED); + } + + // + // Store the UUID seed + // + ProbeForReadSmallStructure(Seed, SEED_SIZE, sizeof(CHAR)); + RtlCopyMemory(&ExpUuidCachedValues.NodeId[0], Seed, SEED_SIZE); + + if ((Seed[0] & 0x80) == 0) + { + // If the high bit is not set the NodeId is a valid IEEE 802 + // address and should be globally unique. + ExpUuidCacheValid = CACHE_VALID; + } + else + { + ExpUuidCacheValid = CACHE_LOCAL_ONLY; + } + + Status = STATUS_SUCCESS; + } + except (EXCEPTION_EXECUTE_HANDLER) { + Status = GetExceptionCode(); + } + + if (CapturedSubjectContext) { + SeReleaseSubjectContext( &SubjectContext ); + } + + return Status; +} + + + +start.cxx: + +https://github.com/tongzx/nt5src/blob/daad8a087a4e75422ec96b7911f1df4669989611/Source/XPSP1/NT/com/ole32/dcomss/wrapper/start.cxx#L282C23-L282C41 + +/*++ + +Copyright (c) 1995 Microsoft Corporation + +Module Name: + + Start.c + +Abstract: + + Process init and service controller interaction for dcomss.exe + +Author: + + Mario Goertzel [MarioGo] + +Revision History: + + MarioGo 06-14-95 Cloned from the old endpoint mapper. + MazharM 10-12.98 Add pnp stuff + TarunA 12-11-98 Removed pnpmngr.h + a-sergiv 25-08-99 Defined gC2Security for process-wide use + +--*/ +DealWithDeviceEvent() +/*++ +Function Name: DealWithDeviceEvent + +Parameters: + +Description: + +Returns: + +--*/ +{ + UCHAR MacAddress[8]; + NTSTATUS NtStatus; + + if (getMacAddress(&MacAddress[0])) + { + NtStatus = NtSetUuidSeed((PCHAR) &MacAddress[0]); + } + else + { + CookupNodeId(&MacAddress[0]); + + ASSERT(MacAddress[0] & 0x80); + + NtStatus = NtSetUuidSeed((PCHAR) &MacAddress[0]); + } + + if (!NT_SUCCESS(NtStatus)) + { + #if DBG + DbgPrint("NtSetUuidSeed failed\n", NtStatus); + #endif + } + +#if !defined(SPX_IPX_OFF) + UpdateSap( SAP_CTRL_UPDATE_ADDRESS ); +#endif +} + + +getMacAddress ( + PUCHAR pMacAddress + ) +/*++ +Function Name:getMacAddress + +Parameters: + +Description: + +Returns: + +--*/ +{ + int i; + UINT fStatus; + int Size = 1024*5; + PNDIS_ENUM_INTF Interfaces; + UCHAR OidVendData[16]; + + Interfaces = (PNDIS_ENUM_INTF) I_RpcAllocate (Size); + if (Interfaces == 0) + { + return FALSE; + } + + if (NdisEnumerateInterfaces(Interfaces, Size)) + { + UINT i; + + for (i = 0; i < Interfaces->TotalInterfaces; i++) + { + PUNICODE_STRING pDeviceName= &(Interfaces->Interface[i].DeviceName); + UCHAR PermMacAddr[6]; + + fStatus = NdisQueryHwAddress(pDeviceName, pMacAddress, PermMacAddr, &OidVendData[0]); + if (fStatus && (OidVendData[0] != 0xFF + || OidVendData[1] != 0xFF + || OidVendData[2] != 0xFF)) + { + I_RpcFree (Interfaces); + + return TRUE; + } + } + } + + I_RpcFree (Interfaces); + + return FALSE; +} + +As we can see in DealWithDeviceEvent() which is realted to UuidCreateSequential(it use the seed as the last 48 bits of uuid), the it calls getMacAddress to obtain MAC address. If OidVendorData's first 6 bytes is 0xff, the function will fail, casing a random value generated rather than the mac of our adapter. So I guess its related to the virtio implementation. But I can't identify where the OidVendData is defined. So I think I should file an issue to virtio dev teams too. + +For those encountered this problem: +This is not a bug. Instead, it is the exepected behaviour. +Refer to: +https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1017 + diff --git a/results/classifier/108/boot/1273944 b/results/classifier/108/boot/1273944 new file mode 100644 index 000000000..49b31e610 --- /dev/null +++ b/results/classifier/108/boot/1273944 @@ -0,0 +1,75 @@ +boot: 0.935 +graphic: 0.873 +performance: 0.770 +device: 0.760 +semantic: 0.745 +other: 0.683 +files: 0.583 +network: 0.571 +PID: 0.543 +socket: 0.514 +debug: 0.463 +vnc: 0.409 +permissions: 0.380 +KVM: 0.334 + +multiboot header has 0 in mem_upper field + +When booting a multiboot image,. mem_upper is now always zero. + +To test, build qemu from current git head, then do + cd tests/multiboot + ./run_test.sh + +You will see the test fail. In each case mem_upper is 0k. + +git-bisect says the bad commit is 0169c511554cb0014a00290b0d3d26c31a49818f in qemu.git + +This change fixes it. + +diff --git a/exec.c b/exec.c +index 2435d9e..b387d28 100644 +--- a/exec.c ++++ b/exec.c +@@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block, + } + + /* MAP_POPULATE silently ignores failures */ +- for (i = 0; i < (memory/hpagesize); i++) { ++ for (i = 0; i < (memory/hpagesize)-1; i++) { + memset(area + (hpagesize*i), 0, 1); + } + +peterc@Diprotodon:/usr/src/qemu/tests/m + +>>>>> "Peter" == Peter Chubb <email address hidden> writes: +This change fixes it. + +> diff --git a/exec.c b/exec.c +> index 2435d9e..b387d28 100644 +> --- a/exec.c +> +++ b/exec.c +> @@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block, +> } +> +> /* MAP_POPULATE silently ignores failures */ +> - for (i = 0; i < (memory/hpagesize); i++) { +> + for (i = 0; i < (memory/hpagesize)-1; i++) { +> memset(area + (hpagesize*i), 0, 1); +> } + +I don't know why this fixes the issue. Hence, no signed-off-by line, etc. + +My guess is that the memset zeros something it shouldn't off the end of +the array (but that doesn't make sense to me!) + +Peter C +-- +Dr Peter Chubb peter.chubb AT nicta.com.au +http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA + + +tests/multiboot seems to work with current git again, so I assume this issue has been fixed? Or is there something left to do? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/boot/1289898 b/results/classifier/108/boot/1289898 new file mode 100644 index 000000000..208194555 --- /dev/null +++ b/results/classifier/108/boot/1289898 @@ -0,0 +1,132 @@ +boot: 0.977 +socket: 0.976 +semantic: 0.973 +permissions: 0.972 +graphic: 0.970 +debug: 0.967 +network: 0.966 +device: 0.962 +performance: 0.947 +files: 0.945 +vnc: 0.942 +other: 0.939 +PID: 0.936 +KVM: 0.899 + +qemu-system-ppc64 easily cause file corruption + +the qemu-system-ppc64 is used to run Fedora-19 on RHEL 5.3. +Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: + +* using scp to transfer a tar.bz file from the RHEL 5.3 host to the Fedora-19 PPC VM, found the size is correct, but the content is corrupted from the middle of the 80+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. + +Correction, the qemu-system-ppc64 is running a VM for RHEL5.9 for PPC, not fedora-19. + +Hi, any chance you could try the latest snapshot from git? It has a lot of PPC64 changes. Also, please pass your QEMU command line. + +I used the following way to start the VM: + +#!/bin/bash +ifconfig -a|grep tap0 >/dev/null 2>&1 || qemu-ifup tap0 + +qemu-system-ppc64 -hda ppcrhel5.img -cpu POWER7 -machine type=pseries,usb=off -m 768 -nographic -net nic -net tap,ifname=tap0,script=no +qemu-ifdown tap0 + +I found a CentOS 6.4 machine which has QEMU 1.5.3, and copied the ppcrhel5.img to that machine, and tested, found it's reliable, and no such file and filesystem easy corruption issue. So, it's the 1.6.2 and 1.7.0 have the problem. + +I can't test from git: on one box with git, it failed for the pixman missing. and the RHEL 5.3 doesn't have git. + +On 10 March 2014 10:00, wzis <email address hidden> wrote: +> I can't test from git: on one box with git, it failed for the pixman +> missing + +Did you try the git submodule command that configure +suggests when it can't find pixman? That will pull +in and build a local copy of pixman for QEMU. + +thanks +-- PMM + + +Also, RHEL5 does have git in the EPEL repository. + +On my RHEL 5.3 box, there are too many problems to get git work. And on the CentOS 6.4 it has many problem to get pixman, so I just can't test the latest qemu unless you also put the pixman in as 1.7.0 does. + +> Date: Mon, 10 Mar 2014 10:53:48 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1289898] Re: qemu-system-ppc64 easily cause file corruption +> +> Also, RHEL5 does have git in the EPEL repository. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1289898 +> +> Title: +> qemu-system-ppc64 easily cause file corruption +> +> Status in QEMU: +> New +> +> Bug description: +> the qemu-system-ppc64 is used to run RHEL5.9 for IBM Power on RHEL 5.3. +> Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: +> +> * using scp to transfer a tar.bz file from the RHEL 5.3 host to the RHEL 5.9 PPC VM, found the size is correct, but the content is corrupted from the middle of the 90+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +> The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1289898/+subscriptions + + +Yes, I tried that, but it failed due to some php component missing. + +> Date: Mon, 10 Mar 2014 10:45:34 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 1289898] Re: qemu-system-ppc64 easily cause file corruption +> +> On 10 March 2014 10:00, wzis <email address hidden> wrote: +> > I can't test from git: on one box with git, it failed for the pixman +> > missing +> +> Did you try the git submodule command that configure +> suggests when it can't find pixman? That will pull +> in and build a local copy of pixman for QEMU. +> +> thanks +> -- PMM +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1289898 +> +> Title: +> qemu-system-ppc64 easily cause file corruption +> +> Status in QEMU: +> New +> +> Bug description: +> the qemu-system-ppc64 is used to run RHEL5.9 for IBM Power on RHEL 5.3. +> Previously I was using QEMU 1.5.x for several months with no problem. But after the RHEL 5.3 host damaged, and rebuilt, now I tried both QEMU 1.6.2 and QEMU 1.7.0, found both can easily cause file corruptions. Symptoms: +> +> * using scp to transfer a tar.bz file from the RHEL 5.3 host to the RHEL 5.9 PPC VM, found the size is correct, but the content is corrupted from the middle of the 90+ MB file. re-transfer again, got a correct file. But after untar, found some extracted files corrupted. +> The extracted file corruption happened several times, and also the filesystem in the VM had corrupted several times, had to restore the boot image to recover. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1289898/+subscriptions + + +and lots of dependency issue . + +After got qemu 2.3.0, I tested on CentOS6.6, the qemu-system-ppc64 also causes filesystem corruption for the big endian RHEL5.9 for power. So this should confirm the qemu for ppc has bug from at least 1.7 onward. + +And seems no developer cares about this issue. + +Is this the same issue as bug https://bugs.launchpad.net/qemu/+bug/1463812 ? If so, I think we should close one of the two tickets - no need to track an issue twice. + diff --git a/results/classifier/108/boot/1290558 b/results/classifier/108/boot/1290558 new file mode 100644 index 000000000..522f981e5 --- /dev/null +++ b/results/classifier/108/boot/1290558 @@ -0,0 +1,214 @@ +boot: 0.955 +device: 0.931 +PID: 0.930 +debug: 0.927 +graphic: 0.927 +socket: 0.925 +other: 0.925 +permissions: 0.900 +semantic: 0.899 +performance: 0.893 +files: 0.888 +vnc: 0.863 +network: 0.836 +KVM: 0.826 + +color issue (ppc as guest) + +Hi, + +on my qemu 1.6.1 -- installed via fink on host Mac OS X 10.8 -- guest PowerPc with Mac OS X 10.4 from original install disk, boots fine but I observe a color issue exactly as described here: +http://virtuallyfun.superglobalmegacorp.com/?p=3197 +http://virtuallyfun.superglobalmegacorp.com/?p=3189 + +Has the problem been reported and/or fixed already? Is any workaround known or has one been suggested? +I apologize for a "fuzzy" problem description, but I am not an expert user. You may get in touch with me directly at <email address hidden> + +Thanks, +Joe. + +Hi Joe, + +Thanks for the bug report. A few things to try: + +- Can you confirm that you see the same color issue when booting a Darwin ISO such as darwinppc-602.iso? +- Do you still see the same the issue with QEMU git master as 1.6 is fairly old now? + +Using the Darwin image above, I do not see the color issue in the above posts on my Linux x86-64 machine. If it is still present for you, you'll need to give more information about the libraries used to build your QEMU and your host (perhaps it is something specific to OS X and/or your build environment?). + + +ATB, + +Mark. + + +Hi Mark, + +thank you for taking some time! + +a) +Yes, the color issue is exactly the same for qemu 1.6.0 with darwinppc-602.cdr from https://opensource.apple.com/static/iso/ +command used: + +qemu-system-ppc -snapshot -L -hda /Users/joe/darwinppc-602.cdr -g 1280x1024x32 + +I have tried some additional options like the g3beige but without effect; maybe I haven't tried all of them yet… + +The color seems to be wrong right from the very first apperance of the opening guest window, even before anything is (visibly) beeing booted. The color depth changes the way in which colors are off: +32: boot screen deep yellow at first, colors mixed up in always the same consistent way, otherwise system seems to be fully usable. +24, 16: bright yellow at first, then funny distorted apple logo screen, than unreadible, text(?) in same color as background… +8: somewhat normal at first but turns into extremly unusable greyscale later on, feels more like bad 4bit. +Please let me know if you can reproduce that or if I should take a screen move for example. + +b) +I would need some help installing a newer version of qemu than 1.6.0. For 1.6.0, I got the attached info file which shows all dependencies to compile and install easily via fink. ( http://www.finkproject.org ) Can you provide something similar for qemu 2.0.0rc0 or tell me where/how to get it? Or alternatively, do you see any outdated (even for 1.6.0) dependencies in that info file that could account for that error? Then, would simply rebuilding help? +Again, I am guessing what might be involved outside qemu, but I am NOT an expert an any of that. + +Thank you very much for your help! + +Best, +Joe. + + + + + +On 12.03.2014, at 08:37, Mark Cave-Ayland <email address hidden> wrote: + +> Hi Joe, +> +> Thanks for the bug report. A few things to try: +> +> - Can you confirm that you see the same color issue when booting a Darwin ISO such as darwinppc-602.iso? +> - Do you still see the same the issue with QEMU git master as 1.6 is fairly old now? +> +> Using the Darwin image above, I do not see the color issue in the above +> posts on my Linux x86-64 machine. If it is still present for you, you'll +> need to give more information about the libraries used to build your +> QEMU and your host (perhaps it is something specific to OS X and/or your +> build environment?). +> +> +> ATB, +> +> Mark. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1290558 +> +> Title: +> color issue (ppc as guest) +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> on my qemu 1.6.1 -- installed via fink on host Mac OS X 10.8 -- guest PowerPc with Mac OS X 10.4 from original install disk, boots fine but I observe a color issue exactly as described here: +> http://virtuallyfun.superglobalmegacorp.com/?p=3197 +> http://virtuallyfun.superglobalmegacorp.com/?p=3189 +> +> Has the problem been reported and/or fixed already? Is any workaround known or has one been suggested? +> I apologize for a "fuzzy" problem description, but I am not an expert user. You may get in touch with me directly at <email address hidden> +> +> Thanks, +> Joe. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1290558/+subscriptions + + + +Hi Joe, + +Thanks for confirming that you still see the issue with the ISO above. From what you're saying, it seems that the problem is apparent on OS X which means I am definitely unable to recreate it here. Since other OS X QEMU users would likely have noticed the bug, I think it may be something related to the build environment. + +My suspicion would lie with the libraries used to build QEMU, particularly pixman which is the low-level graphics library used. Do you know whether the pixman submodule from git.qemu.org was used, or whether it was sourced from somewhere else? Unfortunately as I don't use OS X myself it's going to be difficult for me to help you further with the build unless it's just general advice about building QEMU. + + +HTH, + +Mark. + + +Hi Mark, + +It still seems to me that the problem is somewhere *within* the qemu tree but specific to all MacOSX hosts, and not to my individual build environment. I have done some further research and I found for example +http://www.emaculation.com/doku.php/ppc-osx-on-qemu-for-osx +It lists my exact problem at the bottom of the page under "known issues". (Known to whom, if it seems not to have reached the qemu team yet). It is also present under OSX 10.9.2, which I tried today. + +Also I've tried out the latest builds from qemu.org with the same results. qemu-system-ppc --version returns 1.7.90 (though I downloaded 2.0.0 rc0) +Interestingly, using qemu-system-ppc64 instead produces the correct colors at the very start of the booting, though of course it doesn't get anywhere else since MacOSX 10.4 and 10.5 are both still 32 bit kernels as far as I know. However, that is at least an indicator that the problem may not be the build environment because that environment was exactly the same for qemu-system-ppc and qemu-system-ppc64 + +Thanks for your efforts, I appreciate it! +Joe. + + +On 27.03.2014, at 01:16, Mark Cave-Ayland <email address hidden> wrote: + +> Hi Joe, +> +> Thanks for confirming that you still see the issue with the ISO above. +> From what you're saying, it seems that the problem is apparent on OS X +> which means I am definitely unable to recreate it here. Since other OS X +> QEMU users would likely have noticed the bug, I think it may be +> something related to the build environment. +> +> My suspicion would lie with the libraries used to build QEMU, +> particularly pixman which is the low-level graphics library used. Do you +> know whether the pixman submodule from git.qemu.org was used, or whether +> it was sourced from somewhere else? Unfortunately as I don't use OS X +> myself it's going to be difficult for me to help you further with the +> build unless it's just general advice about building QEMU. +> +> +> HTH, +> +> Mark. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1290558 +> +> Title: +> color issue (ppc as guest) +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> on my qemu 1.6.1 -- installed via fink on host Mac OS X 10.8 -- guest PowerPc with Mac OS X 10.4 from original install disk, boots fine but I observe a color issue exactly as described here: +> http://virtuallyfun.superglobalmegacorp.com/?p=3197 +> http://virtuallyfun.superglobalmegacorp.com/?p=3189 +> +> Has the problem been reported and/or fixed already? Is any workaround known or has one been suggested? +> I apologize for a "fuzzy" problem description, but I am not an expert user. You may get in touch with me directly at <email address hidden> +> +> Thanks, +> Joe. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1290558/+subscriptions + + + +Hi Joe, + +Sorry for the delay with this - have had quite a lot on recently. Just to reiterate what I mentioned above, can you rebuild with pixman as a git submodule and see if that makes a difference? Otherwise configure may pick up a different (older) version of pixman on the system which may have bugs. You can confirm which version is being used by the executable by using ldd on the command line. + +Also with your current build does 8-bit colour work correctly, e.g. use -g 1024x768x8 on the command line? + + +ATB, + +Mark. + + +This problem was fixed in early 2015. Mac OS 9 and Mac OS X both display the correct colors. + diff --git a/results/classifier/108/boot/1516 b/results/classifier/108/boot/1516 new file mode 100644 index 000000000..99c1ac67b --- /dev/null +++ b/results/classifier/108/boot/1516 @@ -0,0 +1,54 @@ +boot: 0.931 +files: 0.881 +device: 0.819 +graphic: 0.754 +performance: 0.744 +semantic: 0.729 +PID: 0.646 +vnc: 0.610 +permissions: 0.604 +network: 0.424 +debug: 0.422 +socket: 0.388 +KVM: 0.366 +other: 0.225 + +QEMU does not reload kernel image on guest reboot (direct kernel boot) +Description of problem: +I am using virtiofs as root filesystem with QEMU direct kernel boot. The kernel is loaded from the guests directory structure that is exported from the host. + +The problem is that QEMU does not reload the kernel image file from disk during a guest reboot. This means it is not possible to update the kernel from inside the guest and do a simple reboot to load it. A full power cycle of the guest is required to load the updated kernel image. +Steps to reproduce: +1. Migrate a Linux guest to virtiofs as root fs. +2. Enable QEMU direct kernel boot and point to guest's kernel in the exported root filesystem. +3. Boot. +4. Update the kernel inside the guest. Overwrite the existing kernel image +5. Issue `reboot` inside the guest. +6. When the guest reboots, the old kernel is still booted, even though the image file was overwritten. +7. Issue `poweroff` inside the guest. +8. Issue `virsh start <guest-vm>` +9. Now the new kernel image is booted. +Additional information: +XML: +``` +<type arch='x86_64' machine='pc-q35-7.0'>hvm</type> + <kernel>/media/vm/libvirt/images/alpine-q/root/boot/vmlinuz-virt</kernel> + <initrd>/media/vm/libvirt/images/alpine-q/root/boot/initramfs-virt</initrd> + <cmdline>rootfstype=virtiofs root=root rw</cmdline> + <boot dev='hd'/> + <bootmenu enable='no'/> + </os> + +... + + <filesystem type='mount' accessmode='passthrough'> + <driver type='virtiofs'/> + <binary path='/usr/libexec/virtiofsd' xattr='on'> + <cache mode='always'/> + <lock posix='on' flock='on'/> + </binary> + <source dir='/media/vm/libvirt/images/alpine-q/root'/> + <target dir='root'/> + <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> + </filesystem> +``` diff --git a/results/classifier/108/boot/1589 b/results/classifier/108/boot/1589 new file mode 100644 index 000000000..16c5063d1 --- /dev/null +++ b/results/classifier/108/boot/1589 @@ -0,0 +1,25 @@ +boot: 0.943 +device: 0.873 +graphic: 0.775 +semantic: 0.619 +other: 0.585 +PID: 0.520 +vnc: 0.449 +performance: 0.435 +debug: 0.416 +files: 0.395 +socket: 0.260 +permissions: 0.229 +network: 0.184 +KVM: 0.035 + +Crash when using qemu 8.0.0 version tcg mode +Description of problem: +Can I no longer use qemu in tcg mode? +When operating in tcg mode in all versions of 8.0.0, a crash occurs on the booting screen and the window closes (the window stops responding before closing). +Steps to reproduce: +1. Run qemu with -accel tcg option +2. enter the boot screen +3. The screen freezes and the window closes after a few seconds (at which point it becomes unresponsive) +Additional information: +I have not checked whether the same symptom occurs in Linux, and it occurs in all versions of 8.0.0 for Windows. diff --git a/results/classifier/108/boot/1589153 b/results/classifier/108/boot/1589153 new file mode 100644 index 000000000..5f08675f1 --- /dev/null +++ b/results/classifier/108/boot/1589153 @@ -0,0 +1,64 @@ +boot: 0.924 +socket: 0.868 +performance: 0.846 +device: 0.827 +files: 0.790 +KVM: 0.767 +semantic: 0.740 +graphic: 0.713 +network: 0.704 +vnc: 0.674 +permissions: 0.665 +debug: 0.616 +other: 0.603 +PID: 0.515 + +qemu-system-x86_64 version 2.5.0 freezes during windows 7 installation in lubuntu 16.04 + +Hi! + +I have been using qemu - kvm for several years in different versions of ubuntu (lubuntu). I am trying to migrate from 15.04 to 16.04 and am having a problem. In particular, on my machine (a samsung series 9 with dual core i7 processor and 8gb ram) the following commands worked in 15.04 but do not work in 15.10 and 16.04. FYI, I tested them on a clean machine, where I have created a 60GB image file in its own partition.. In particular, I am using the command to start installing windows 7 and it works in a clean install of 15.04 (yesterday) but not in 15.10 (yesterday) or 16.04 (the day before). I do not get any error messages in my xterminal when running this and do not know how to check for windows error messages. By not working I mean that after loading files it gets to a windows screen and then stays there forever. + +The command lines used to invoke qemu is: +echo "*** Installing windows 7 virtual machine - Step 2" + + +echo "*** Try command for slow mouse" +export SDL_VIDEO_X11_DGAMOUSE=0 + +sudo qemu-system-x86_64 \ + -enable-kvm \ + -machine pc,accel=kvm \ + -cdrom /home/Archives/Software/OperatingSystems.Windows7HP.64/Windows7HP64_Install.iso \ + -boot d \ + -net nic,macaddr=56:44:45:30:31:34 \ + -net user \ + -cpu host \ + -vga qxl \ + -spice port=5900,disable-ticketing \ + -uuid 8373c3d6-1e6c-f022-38e2-b94e6e14e170 \ + -smp cpus=2,maxcpus=3 \ + -m 6144 \ + -name DrPhilSS9AWin7VM \ + -hda /mnt/Windows7Image/Windows7Guest.img \ + -localtime \ + -k en-us \ + -usb \ + -usbdevice tablet& +sleep 10 +spicy --host 127.0.0.1 --port 5900 + +Have a similar issue though on Ubuntu 14.04 (4.2.0-36-generic #42~14.04.1-Ubuntu) + +We use an automated appliance build process, to create qemu/KVM appliances. + +Ever since qemu 2.0.0+dfsg-2ubuntu1.24 security update, we are getting the same issue as mentioned above (Windows 7 Installation CD - X17-24281.iso, hangs after loading files). + +We had to pin to 2.0.0+dfsg-2ubuntu1.22 to resolve the issue. + + + +Please see http://ubuntuforums.org/showthread.php?t=2325843&p=13499322#post13499322 for a similar discussion and for a workaround. But please note that to the best I can tell it is still a bug. + +Phil + diff --git a/results/classifier/108/boot/1652286 b/results/classifier/108/boot/1652286 new file mode 100644 index 000000000..945dbf248 --- /dev/null +++ b/results/classifier/108/boot/1652286 @@ -0,0 +1,53 @@ +boot: 0.921 +performance: 0.850 +device: 0.807 +PID: 0.788 +graphic: 0.782 +semantic: 0.730 +network: 0.721 +socket: 0.696 +permissions: 0.574 +files: 0.555 +vnc: 0.540 +other: 0.466 +debug: 0.433 +KVM: 0.289 + +QEMU manpages provoke man(1) "can't break line" warnings + +I noticed when I ran 'man qemu' for version 2.8.0 I am getting this back at the terminal; + + +<standard input>:1674: warning [p 1, 188.5i, div `an-div', 0.2i]: can't break line +<standard input>:1677: warning [p 1, 188.8i, div `an-div', 0.2i]: can't break line + +This still reproduces with current QEMU: + +$ man -l build/qemu.1 >/dev/null +<standard input>:248: warning [p 3, 6.8i, div `an-div', 0.2i]: can't break line +<standard input>:376: warning [p 5, 2.5i, div `an-div', 0.2i]: can't break line +<standard input>:667: warning [p 8, 9.7i, div `an-div', 0.2i]: can't break line + +(and so on for more warnings) + +'man' produces these warnings when the input has a line which it is unable to cleanly line-break to fit in the output terminal (and so the number of warnings you get depends on the width of the terminal you're using). For instance this line: +.IP "\fB\-boot [order=\fR\fIdrives\fR\fB][,once=\fR\fIdrives\fR\fB][,menu=on|off][,splash=\fR\fIsp_name\fR\fB][,splash\-time=\fR\fIsp_time\fR\fB][, + +has no spaces in the whole of the part after "-boot" so it will typically not line break cleanly. + +Ideally we would fix this by arranging to have the groff output include '\:' zero-width break points between the ']' and '[' in this kind of long line so that it knew where to wrap. But I don't know if this is easy/possible with how we're generating the manpages at the moment. + +In any case the warning is harmless and the hard-wrapped lines are not too unreadable, so this is a minor issue. + + +Still happens with the new Sphinx-generated manpages, for exactly the same reason. + + + +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/214 + + diff --git a/results/classifier/108/boot/1745 b/results/classifier/108/boot/1745 new file mode 100644 index 000000000..168f880d6 --- /dev/null +++ b/results/classifier/108/boot/1745 @@ -0,0 +1,82 @@ +boot: 0.935 +device: 0.921 +files: 0.865 +performance: 0.861 +graphic: 0.710 +permissions: 0.710 +network: 0.689 +socket: 0.689 +PID: 0.649 +debug: 0.601 +vnc: 0.515 +KVM: 0.492 +semantic: 0.486 +other: 0.232 + +qemu-system-sparc64 v8.0.2 failed to read the file system. +Steps to reproduce: +1. Run qemu-system-sparc64 with the following command line. + `qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2` +2. The system will report a issue "Could not open option rom 'pflash0': No such file or directory" +3. Then, enter the boot command on the boot loader. +4. The command failed with following message. +``` +Boot device: vdisk File and args: +Bad magic number in disk label +Can't open disk label package + +Can't open boot device +``` +Additional information: +``` +$ qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2 +Could not open option rom 'pflash0': No such file or directory +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +Bad magic number in disk label +Can't open disk label package + +Can't open boot device + +ok +``` + +It works fine with the previous qemu-system-sparc64 version. + +``` +$ qemu-7.2.3/build/qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2 +cpu Probing I/O buses + + +Sun Fire T2000, No Keyboard +Copyright 2005 Sun Microsystems, Inc. All rights reserved. +OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. +[mo23723 obp4.20.0 #0] +Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. + + + +ok boot +Boot device: vdisk File and args: +Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54. +FCode UFS Reader 1.12 00/07/17 15:48:16. +Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot +Loading: /platform/sun4v/ufsboot +SunOS Release 5.10 Version Generic_118822-23 64-bit +Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Hostname: unknown + +unknown console login: +``` diff --git a/results/classifier/108/boot/1826 b/results/classifier/108/boot/1826 new file mode 100644 index 000000000..05dd2839a --- /dev/null +++ b/results/classifier/108/boot/1826 @@ -0,0 +1,44 @@ +boot: 0.967 +graphic: 0.938 +performance: 0.907 +device: 0.894 +other: 0.853 +debug: 0.793 +semantic: 0.791 +vnc: 0.675 +files: 0.668 +PID: 0.658 +permissions: 0.646 +KVM: 0.532 +network: 0.514 +socket: 0.459 + +Segfault in memory_region_dispatch_write() +Description of problem: +Several possible outcomes +- Kernel freeze and rcu lockup messages. +- segfault + +For segfault, using gdb. +``` +in memory_region_dispatch_write (mr=mr@entry=0x130013001300013, addr=addr@entry=176, data=dat@entry=0, op=op@entry=M0_42, attrs=...) at ../../softwmmu/memory.c:1515 +1515 if (mr->alias) { + +in memory_region_dispatch_write( .. as above...) +in io_writex(env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, mmu_idx=mmu_idx@entry=0, val=0, addr=addr@entry=18446744073699049648, retaddr=retaddr@entry=140736023420498, op=MO_32) at ../../accel/tcg/cputlb.c:1448 +in do_st_mmio_leN (env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, val_le=<optmized out>, val_le@entry=0, addr=addr@entry=18446744073699049648, size=size@entry=4, mmu_idx=mmu_idx@entry=0, ra=140736023420498) at ../../accel/tcg/cputlb.c:2755 +in do_st_4 (ra=<optmized_out>, memop=<optimized out> mmu_idx=0, val=0, p=0x7ffff529c140, env=0x555556a84320) at ../../accel/tcg/cputbl.c:2921 +do_st4_mmu (env=0x555556a84320, addr=<optimized out> val=<optmized out>, oi=<otpmized out> ra=140736023420498) at ../../accel/tcg/cputlb.c:3006 +in code_gen_buffer() +in cpu_tb_exec(..) //getting lazy on typing as seems unlikely anything useful beyond here. +in cpu_loop_exec_tb() +cpu_exec_loop +in cpu_exec_setjmp() +in cpu_exec() +in tcg_cpus_exec() +``` +Steps to reproduce: +1. Boot. +2. Use gdb to grab back trace after segfault. +Additional information: +Seems to segfault mid way through PCI enumeration in the kernel. Which device seems to vary between runs. diff --git a/results/classifier/108/boot/1840920 b/results/classifier/108/boot/1840920 new file mode 100644 index 000000000..55df3f3c3 --- /dev/null +++ b/results/classifier/108/boot/1840920 @@ -0,0 +1,29 @@ +boot: 0.933 +vnc: 0.931 +device: 0.873 +graphic: 0.711 +files: 0.617 +semantic: 0.613 +network: 0.515 +socket: 0.333 +performance: 0.323 +other: 0.317 +debug: 0.239 +PID: 0.151 +permissions: 0.118 +KVM: 0.057 + +changelog 4.1 krenel typo + +The changelog for 4.1 subsection Arm has a typo (krenel --> kernel) +https://wiki.qemu.org/ChangeLog/4.1#Arm + +At the following line: +The i.mx7 PCI controller emulation has been improved so it can boot current Linux krenels + +it should be: +The i.mx7 PCI controller emulation has been improved so it can boot current Linux kernels + +Thanks for this report -- I've just updated the changelog page to fix the typo. + + diff --git a/results/classifier/108/boot/1906181 b/results/classifier/108/boot/1906181 new file mode 100644 index 000000000..7f0572398 --- /dev/null +++ b/results/classifier/108/boot/1906181 @@ -0,0 +1,61 @@ +boot: 0.933 +graphic: 0.914 +other: 0.882 +performance: 0.757 +device: 0.747 +KVM: 0.667 +permissions: 0.636 +files: 0.629 +PID: 0.626 +semantic: 0.611 +vnc: 0.548 +network: 0.525 +debug: 0.462 +socket: 0.397 + +Mouse starts jumping wildly on guest desktop + +Sometimes mouse goes completely crazy and starts jumping around the guest desktop by itself and becomes completely unusable. + +This does not happen on every boot, only sometimes. It may be caused by some input combination but I haven't yet found any specific cause. It happens soon after the desktop has been loaded and rebooting seems to be the only way to resolve the situation. + + +Guest: Kubuntu 20.04 64-bit (live), with KDE desktop +Host: Arch Linux, with KDE desktop +QEMU version: 5.1.0 + +QEMU start command: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +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/boot/2034 b/results/classifier/108/boot/2034 new file mode 100644 index 000000000..7a0852f9c --- /dev/null +++ b/results/classifier/108/boot/2034 @@ -0,0 +1,23 @@ +boot: 0.958 +graphic: 0.935 +device: 0.794 +semantic: 0.723 +debug: 0.710 +performance: 0.658 +PID: 0.633 +files: 0.604 +socket: 0.602 +network: 0.490 +vnc: 0.473 +KVM: 0.308 +other: 0.163 +permissions: 0.163 + +ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +Description of problem: +``` +cat boot.log +aarch64>** +aarch64>ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +aarch64>Bail out! ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu)) +``` diff --git a/results/classifier/108/boot/2212 b/results/classifier/108/boot/2212 new file mode 100644 index 000000000..de7db2f0c --- /dev/null +++ b/results/classifier/108/boot/2212 @@ -0,0 +1,32 @@ +boot: 0.958 +files: 0.909 +graphic: 0.904 +device: 0.898 +vnc: 0.852 +socket: 0.800 +semantic: 0.742 +PID: 0.739 +performance: 0.735 +permissions: 0.673 +network: 0.656 +debug: 0.538 +KVM: 0.315 +other: 0.174 + +"pci_hp_register failed with error -16" was found in Guest when launching VM with pci-bridge and "-machine q35" +Description of problem: +Host and guest config file configuration: + CONFIG_HOTPLUG_PCI_CPCI=y + CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m + CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m + CONFIG_HOTPLUG_PCI_SHPC=y +Use this configuration kernel to boot QEMU, with the QEMU parameter "-machine q35 -device pci-bridge,id=bridge0,chassis_nr=1". After the guest boot, dmesg will display "shpchp 0000:00:04.0: pci_hp_register failed with error -16". +Steps to reproduce: +1.Boot QEMU + +2.Check dmesg in VM +Additional information: +Error log: +[root@localhost ~]# dmesg | grep pci_hp_register +[ 0.723893] shpchp 0000:00:04.0: pci_hp_register failed with error -16 +[dmesg.log](/uploads/8ce302f996255544b4327d27ea4ac555/dmesg.log) diff --git a/results/classifier/108/boot/2337 b/results/classifier/108/boot/2337 new file mode 100644 index 000000000..e0b5f651e --- /dev/null +++ b/results/classifier/108/boot/2337 @@ -0,0 +1,77 @@ +boot: 0.988 +socket: 0.986 +device: 0.978 +graphic: 0.971 +semantic: 0.968 +permissions: 0.957 +PID: 0.947 +vnc: 0.939 +network: 0.936 +debug: 0.933 +files: 0.933 +performance: 0.912 +other: 0.651 +KVM: 0.545 + +Os boot issues on 9p filesystem due to unix domain sockets open failure +Description of problem: +Unix filesystem API is broken, unix domain socket special files return an error at open() +Steps to reproduce: +Simple script. Tries to use netcat to get data through a local unix domain socket file +``` +#!/bin/bash + +# Cleanup target dir +[ -d ./target ] && rm -rf target +mkdir target + +# Add configuration updates +mkdir -p ./target/etc/initramfs-tools/ +echo 9p >> ./target/etc/initramfs-tools/modules +echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules + +# Add the test script +cat > ./target/test_init << EOF +#!/bin/bash + +echo "Test for unix domain sockets" + +nc -Ul /socket & +sleep 1 +echo "Sockets work" | nc -UN /socket || echo "Sockets fail" + +echo o > /proc/sysrq-trigger +sleep 999 +EOF +chmod 700 ./target/test_init + +# Create an Ubuntu 23.10 around it +echo "Creating Ubuntu target OS" +debootstrap --variant=minbase\ + --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \ + --exclude=man,bash-completion \ + mantic ./target > /dev/null || exit 1 + +# Run the test in 9p forwarded filesystem +echo "Running OS in qemu" +qemu-system-s390x \ + -m 8192 \ + -smp 4 \ + -nodefaults -nographic -no-reboot -no-user-config \ + -kernel ./target/boot/vmlinuz \ + -initrd ./target/boot/initrd.img \ + -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \ + -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \ + -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \ + -device virtio-serial-ccw -device sclpconsole,chardev=console \ + -chardev stdio,id=console,signal=off +``` +Additional information: +Test output: +``` +Test for unix domain sockets +qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory) +nc: No such device or address +nc: /socket: No such file or directory +Sockets fail +``` diff --git a/results/classifier/108/boot/2620 b/results/classifier/108/boot/2620 new file mode 100644 index 000000000..bfdd0ab9f --- /dev/null +++ b/results/classifier/108/boot/2620 @@ -0,0 +1,24 @@ +boot: 0.923 +device: 0.907 +graphic: 0.795 +vnc: 0.771 +socket: 0.596 +debug: 0.548 +files: 0.423 +semantic: 0.399 +performance: 0.397 +network: 0.313 +permissions: 0.310 +PID: 0.256 +other: 0.104 +KVM: 0.097 + +Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc +Description of problem: + +Steps to reproduce: +1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO. Works on real Sparcstation 5, 10, or 20 +2.Start OS install +3. +Additional information: + diff --git a/results/classifier/108/boot/2699 b/results/classifier/108/boot/2699 new file mode 100644 index 000000000..73541baa5 --- /dev/null +++ b/results/classifier/108/boot/2699 @@ -0,0 +1,33 @@ +boot: 0.978 +vnc: 0.943 +device: 0.925 +debug: 0.908 +graphic: 0.874 +PID: 0.841 +KVM: 0.757 +socket: 0.748 +performance: 0.701 +files: 0.667 +network: 0.579 +semantic: 0.451 +permissions: 0.426 +other: 0.252 + +kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9) +Description of problem: +QEMU 9.1.91 monitor - type 'help' for more information +(qemu) kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9) +test.sh: line 14: 105283 Aborted (core dumped) /usr/local/bin/qemu-system-x86_64 -M q35 -m 8G -smp 8 -cpu host -enable-kvm -device VGA,bus=pcie.0,addr=0x2 -drive file=//home/fedora-38.qcow2,media=disk,if=virtio -device virtio-net-pci,mac=00:11:22:33:44:00,netdev=id8cxFGH,id=idaFLYjy,bus=pcie.0,addr=0x7 -netdev tap,id=id8cxFGH,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -vnc :0 -monitor stdio -qmp tcp:0:5555,server,nowait +Steps to reproduce: +1. Boot a guest +2. set_link false nic and set_link true nic + +{"execute": "qmp_capabilities"} +{"return": {}} +{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": false}} +{"return": {}} +{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": true}} + +3. Guest hit qemu core dump +Additional information: + diff --git a/results/classifier/108/boot/2705 b/results/classifier/108/boot/2705 new file mode 100644 index 000000000..f52cf6f1c --- /dev/null +++ b/results/classifier/108/boot/2705 @@ -0,0 +1,32 @@ +boot: 0.931 +device: 0.926 +performance: 0.915 +vnc: 0.865 +other: 0.853 +semantic: 0.851 +graphic: 0.845 +debug: 0.771 +socket: 0.687 +permissions: 0.665 +files: 0.565 +PID: 0.548 +KVM: 0.519 +network: 0.411 + +USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X) +Steps to reproduce: +1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above. +2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off` +3. Boot macOS. + +USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable. + + +While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection: + + * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.) + * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2. + * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped. + * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references. + +It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup. diff --git a/results/classifier/108/boot/2754 b/results/classifier/108/boot/2754 new file mode 100644 index 000000000..3e8811711 --- /dev/null +++ b/results/classifier/108/boot/2754 @@ -0,0 +1,41 @@ +boot: 0.963 +vnc: 0.958 +network: 0.957 +debug: 0.953 +device: 0.947 +socket: 0.944 +graphic: 0.932 +performance: 0.891 +files: 0.877 +PID: 0.871 +permissions: 0.740 +semantic: 0.736 +other: 0.609 +KVM: 0.309 + +Virt-manager using QEMU exit in flash and return an I/O Error when attempting to create an loongarch64 QEMU virtual machine +Description of problem: +Cannot complete the installation:'Enter the end of the file when reading data:I/O Error' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper + callback(asyncjob, *args, **kwargs) + ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install + installer.start_install(guest, meter=meter) + ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 726, in start_install + domain = self._create_guest( + guest, meter, initial_xml, final_xml, + doboot, transient) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + File "/usr/lib64/python3.13/site-packages/libvirt.py", line 4545, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: 'Enter the end of the file when reading data:I/O Error' +Steps to reproduce: +1.Click to create loongarch64 virtual machine using virt-manager +2.Configure all arguments of virtual machine +3.Then click start installation,then the error occurs. +Additional information: + diff --git a/results/classifier/108/boot/2788 b/results/classifier/108/boot/2788 new file mode 100644 index 000000000..be9f69102 --- /dev/null +++ b/results/classifier/108/boot/2788 @@ -0,0 +1,28 @@ +boot: 0.939 +device: 0.922 +other: 0.911 +semantic: 0.908 +graphic: 0.787 +performance: 0.765 +vnc: 0.646 +PID: 0.617 +KVM: 0.603 +permissions: 0.578 +socket: 0.549 +debug: 0.543 +files: 0.478 +network: 0.444 + +[solved] input mouse and keyboard not working on a distro +Description of problem: +The distro work but does not take input from either keyboard or mouse. +At the boot menu (syslinux) where I have to choose the boot mode the keyboard works, but it stops working when the desktop has booted. +The distro is not blocked I can tell by observing that the clock in the panel keeps running and if I click in the qemu menubar on machine > power down, the distro correctly performs the shutdown procedure. +I have tried other distributions (porteus and tinycore) and both do not have this problem. +I also tried using as -display vnc and sdl but I have the same problem. +I am using a [portable version of qemu](https://gitlab.com/qemu-project/qemu/-/issues/new) but I also tried with the repository version having the same problem. +Steps to reproduce: +Simply boot the virtual machine with the distro, in my case with the portable qemu version: +./QEMU-git-x86_64.AppImage qemu-system-x86_64 -m 512 -enable-kvm -boot d -cdrom ./Nemesis-v25.01-XFCE-x86_64.iso +Additional information: +I am not expert in qemu, if you need some more data I can try to produce it diff --git a/results/classifier/108/boot/2863 b/results/classifier/108/boot/2863 new file mode 100644 index 000000000..3771187f0 --- /dev/null +++ b/results/classifier/108/boot/2863 @@ -0,0 +1,16 @@ +boot: 0.954 +other: 0.709 +vnc: 0.653 +semantic: 0.573 +device: 0.573 +KVM: 0.477 +performance: 0.474 +network: 0.448 +files: 0.381 +socket: 0.367 +graphic: 0.343 +PID: 0.333 +permissions: 0.211 +debug: 0.125 + +Invalid read reason: rejected diff --git a/results/classifier/108/boot/2957 b/results/classifier/108/boot/2957 new file mode 100644 index 000000000..f02d9d16a --- /dev/null +++ b/results/classifier/108/boot/2957 @@ -0,0 +1,43 @@ +boot: 0.932 +device: 0.899 +vnc: 0.877 +other: 0.862 +permissions: 0.799 +graphic: 0.778 +files: 0.723 +PID: 0.710 +socket: 0.704 +semantic: 0.661 +network: 0.623 +debug: 0.618 +performance: 0.356 +KVM: 0.344 + +qemu-system-riscv32: Some ROM regions are overlapping +Description of problem: +Booting the image produces: +``` +qemu-system-riscv32: Some ROM regions are overlapping +These ROM regions might have been loaded by direct user request or by default. +They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. +Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. + +The following two regions overlap (in the memory address space): + output/images/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000278cc) + mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028) +``` +Steps to reproduce: +1. `make qemu_riscv32_virt_defconfig` +2. `make` +3. `qemu-system-riscv32 \ +-M virt -nographic \ +-bios output/images/fw_jump.elf \ +-kernel output/images/Image \ +-append "root=/dev/vda ro" \ +-drive file=output/images/rootfs.ext2,format=raw,id=hd0 \ +-device virtio-blk-device,drive=hd0 \ +-netdev user,id=net0 -device virtio-net-device,netdev=net0` +Additional information: +Changing `-bios output/images/fw_jump.elf` to `-bios output/images/fw_jump.bin` or `-bios output/images/fw_dynamic.bin` resolves the issue. + +Similar issue observed elsewhere, e.g. here [https://github.com/riscv-software-src/opensbi/issues/372](https://github.com/riscv-software-src/opensbi/issues/372) diff --git a/results/classifier/108/boot/2959 b/results/classifier/108/boot/2959 new file mode 100644 index 000000000..8d6d8f566 --- /dev/null +++ b/results/classifier/108/boot/2959 @@ -0,0 +1,92 @@ +boot: 0.949 +graphic: 0.838 +files: 0.836 +device: 0.835 +debug: 0.799 +performance: 0.793 +semantic: 0.733 +other: 0.690 +vnc: 0.618 +socket: 0.608 +PID: 0.573 +permissions: 0.543 +network: 0.474 +KVM: 0.265 + +int 0x10 teletype output cuts final character in custom MBR on QEMU (i386 real mode) +Description of problem: +When using QEMU to test a custom bootloader in 16-bit real mode (i386), the BIOS interrupt `int 0x10` with AH=0x0E (teletype output) fails to display the last character of the printed message. For example, printing `"hello"` only renders `"hell"`. + +This happens only with this exact combination: + +real mode `int 0x10` teletype output + +message ends with `13, 10, 0` + +`QEMU` output cuts off the last character consistently + +All buffer and code logic has been verified to be correct. The same code, when run on Bochs or physical hardware, prints properly. +Steps to reproduce: +1.Assemble the following boot.asm: +```nasm +[org 0x7C00] +[BITS 16] + +_start: + cli + xor ax, ax + mov ds, ax + mov es, ax + mov ss, ax + mov sp, 0x7C00 + + mov si, msg + call print + + hlt + jmp $ + +print: + pusha +.loop: + lodsb + or al, al + jz .done + mov ah, 0x0E + int 0x10 + jmp .loop +.done: + popa + ret + +msg db 'hello', 13, 10, 0 +times 510 - ($ - $$) db 0 +dw 0xAA55 +``` + +2. Compile and run: +```bash +$ nasm -f bin boot.asm -o boot.img +$ qemu-system-i386 -nographic -boot a -drive format=raw,file=boot.img,index=0,if=floppy +``` + +3. Output will be: +```text +Booting from Floppy... +hell +``` +Expected output: +```text +Booting from Floppy... +hello +``` +Additional information: +- Adding padding (extra 13, 10) does not solve the problem. + +- Confirmed that boot.img includes all bytes (xxd dump is correct). + +- Tested on multiple machines with same QEMU version. + +- May relate to VGA character output buffer not flushing after last INT 0x10? + +- This makes QEMU inaccurate for BIOS-level debugging of bootloaders. diff --git a/results/classifier/108/boot/436 b/results/classifier/108/boot/436 new file mode 100644 index 000000000..3a1d63987 --- /dev/null +++ b/results/classifier/108/boot/436 @@ -0,0 +1,16 @@ +boot: 0.979 +device: 0.908 +performance: 0.851 +graphic: 0.599 +debug: 0.345 +permissions: 0.325 +semantic: 0.281 +PID: 0.259 +vnc: 0.256 +other: 0.256 +network: 0.218 +files: 0.112 +socket: 0.078 +KVM: 0.004 + +window 8 stuck during boot on Qemu diff --git a/results/classifier/108/boot/475 b/results/classifier/108/boot/475 new file mode 100644 index 000000000..bb6054a7d --- /dev/null +++ b/results/classifier/108/boot/475 @@ -0,0 +1,16 @@ +boot: 0.938 +performance: 0.881 +device: 0.875 +graphic: 0.622 +PID: 0.617 +files: 0.516 +network: 0.464 +semantic: 0.456 +debug: 0.454 +vnc: 0.386 +socket: 0.264 +permissions: 0.199 +other: 0.177 +KVM: 0.001 + +4.2 regression: ReactOS crashes on boot diff --git a/results/classifier/108/boot/622 b/results/classifier/108/boot/622 new file mode 100644 index 000000000..a17ae1602 --- /dev/null +++ b/results/classifier/108/boot/622 @@ -0,0 +1,16 @@ +boot: 0.962 +device: 0.940 +other: 0.738 +graphic: 0.566 +performance: 0.554 +debug: 0.331 +network: 0.304 +socket: 0.272 +semantic: 0.244 +vnc: 0.206 +permissions: 0.167 +files: 0.166 +PID: 0.100 +KVM: 0.001 + +Mac OS X Cheetah Virtual Machine booting back into Mac OS 9 for no reason diff --git a/results/classifier/108/boot/627982 b/results/classifier/108/boot/627982 new file mode 100644 index 000000000..e915d2af3 --- /dev/null +++ b/results/classifier/108/boot/627982 @@ -0,0 +1,46 @@ +boot: 0.935 +PID: 0.732 +semantic: 0.724 +device: 0.688 +other: 0.670 +graphic: 0.579 +performance: 0.543 +permissions: 0.513 +network: 0.463 +socket: 0.410 +vnc: 0.408 +files: 0.376 +debug: 0.303 +KVM: 0.279 + +linux 2.6.35 hangs with -no-acpi + +Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance the Debian kernel: + +qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 + +There is no output except just "Booting the kernel" + + On 09/01/2010 01:54 PM, Samuel thibault wrote: +> Public bug reported: +> +> Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance +> the Debian kernel: +> +> qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 +> +> There is no output except just "Booting the kernel" +> + +Is this a kernel regression? A qemu regression? What do 'info +registers' and 'x/20i $eip' show? + +You know better than this. + +-- +I have a truly marvellous patch that fixes the bug which this +signature is too narrow to contain. + + +Since kernel 2.6.35 is pretty much outdated nowadays, I think we can close this bug now (Feel free to re-open it if necessary). + diff --git a/results/classifier/108/boot/669 b/results/classifier/108/boot/669 new file mode 100644 index 000000000..8c7a9b0f4 --- /dev/null +++ b/results/classifier/108/boot/669 @@ -0,0 +1,38 @@ +boot: 0.961 +files: 0.944 +device: 0.925 +graphic: 0.904 +PID: 0.849 +performance: 0.802 +debug: 0.785 +network: 0.779 +socket: 0.754 +vnc: 0.751 +other: 0.746 +permissions: 0.739 +KVM: 0.733 +semantic: 0.614 + +QEMU Segmentation fault - UnRaid 9.3.2 when passing nvidia k620 GPU inserted into Lenovo x3550 M5 server +Description of problem: +When I pass the following GPU to any Virtual Machine: +IOMMU group 33:[10de:13bb] 81:00.0 VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K620] (rev a2) +I receive this error as soon as i try to boot the VM (any OS). + +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: enabling device (0140 -> 0141) +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258 +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +**Oct 13 03:06:12 MyUnraid-1U kernel: qemu-system-x86[6080]: segfault at a8 ip 00005618620c812a sp 00007ffc610531b0 error 4 in qemu-system-x86_64[561861fbb000+51d000] +Oct 13 03:06:12 MyUnraid-1U kernel: Code: ef ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 e8 4e de ff ff 48 89 df e8 16 e9 ff ff <48> 8b 85 a8 00 00 00 48 85 c0 74 52 8b 93 a0 00 00 00 eb 0e 66 90** +Oct 13 03:06:13 MyUnraid-1U avahi-daemon[3536]: Interface vnet0.IPv6 no longer relevant for mDNS. + +This is one example of W10 VM: +In attach my VM template + +[VM_example.txt](/uploads/428ca5a10ef3338d5d408583fc552b25/VM_example.txt) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/108/boot/797 b/results/classifier/108/boot/797 new file mode 100644 index 000000000..51cca15c4 --- /dev/null +++ b/results/classifier/108/boot/797 @@ -0,0 +1,24 @@ +boot: 0.943 +graphic: 0.938 +device: 0.884 +semantic: 0.493 +debug: 0.478 +permissions: 0.375 +files: 0.347 +performance: 0.328 +socket: 0.307 +PID: 0.291 +vnc: 0.252 +other: 0.241 +network: 0.236 +KVM: 0.015 + +ARM64 hvf fails to boot Windows 11 on 6.2.0 +Description of problem: +On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner"). +Steps to reproduce: +1. `brew install qemu` +2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64 +3. Run command from above. +Additional information: + diff --git a/results/classifier/108/boot/822408 b/results/classifier/108/boot/822408 new file mode 100644 index 000000000..acea65215 --- /dev/null +++ b/results/classifier/108/boot/822408 @@ -0,0 +1,85 @@ +boot: 0.932 +device: 0.896 +performance: 0.890 +semantic: 0.850 +other: 0.842 +graphic: 0.834 +permissions: 0.810 +files: 0.793 +network: 0.773 +socket: 0.773 +PID: 0.770 +debug: 0.682 +vnc: 0.600 +KVM: 0.438 + +Unable to access disk image on mipsel host + +Something is wrong with hard disk images on MIPSel host. + +The host system is mips64el (Loongson cpu, Linux 2.6.39, eglibc 2.13) +Tried Qemu 0.14.1 and 0.15.0-rc2, both compiled with GCC 4.6.0. + +First I was trying to install WinXP (i386-softmmu). +Starting install, create partition, format (either quick and full), seems to complete, boom the error: + +" +Setup was unable to format the partition. The disk may be damaged. Make sure the drive is switched on and properly connected to your computer. If the disk is a SCSI disk, make sure your SCSI devices are properly terminated. Consult your computer manual or SCSI adapter documentation for more information. + +You must select a different partition for Windows XP. +To continue, press ENTER. +" + +This happens with both raw and qcow2 image format. +Tried 10Gb image, tried 16Gb one - no difference. + +On a x86 host, that formatting makes the image (qcow2) grow to about 81 Mb by the time it reaches 100% formatted (quick), but on mipsel it grows to 0.8Mb at the same time and the error appears. + +I tried the same installing of Windows in Qemu on x86 host and copied over the completed image. +In that case it starts loading, but in the middle of the animation there is an error: + +" +STOP: c0000221 Unknown Hard Error +\Systemroot\System32\ntdll.dll +" +(or HAL.dll) + +So, i tried linux-0.2.img.bz2 from the Qemu site, and that fails too. +Thus it's the minimal bug reproduction thing. + +During boot there are multiple errors like: +" +hda: dma_intr: status=0x41 { DriveReady Error } +hda: dma_intr: error=0x04 { DriveStatusError } +hda: Failed opcode was: unknown +" + +It booted and kind of worked, there were weird glitches in every program. +Unusable. + +Summarily, that suggest some error in hard disk emulation or back storage, specific either to MIPSel or non-x86 hosts. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +Well, that's a blast from the past. +Still have the MIPS laptop in question (Lemote Yeeloong 8101b), got it running. + +Built Qemu 0.14.1, the bug is replicated as before. +Built Qemu 2.9.0, the bug is still replicated as before (but qemu is now about 100x slower for some reason). + +So it would appear that whatever the problem is, it never got solved in the last 5 years. + +Raw image (linux-0.2.img.bz2), can't quite test on WinXP any more since it's awfully slow. +Still gives the same kinds of errors: +hda: dma_intr: status=0x41 { DriveReady Error } +hda: dma_intr: error=0x04 { DriveStatusError } +hda: Failed opcode was: unknown + +Built with ./configure --target-list=i386-softmmu + + +Triage-wise, both the laptop, the company and the CPU architecture lost the test of time and are at best collector's items these days, so unless the bug can be replicated on some modern MIPS system it's not worth bothering with. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/boot/87 b/results/classifier/108/boot/87 new file mode 100644 index 000000000..d97fbeea0 --- /dev/null +++ b/results/classifier/108/boot/87 @@ -0,0 +1,16 @@ +boot: 0.960 +device: 0.925 +performance: 0.859 +other: 0.770 +semantic: 0.599 +graphic: 0.539 +PID: 0.523 +KVM: 0.505 +permissions: 0.386 +debug: 0.369 +network: 0.312 +vnc: 0.308 +files: 0.220 +socket: 0.184 + +doesn't clear screen on boot diff --git a/results/classifier/108/boot/886 b/results/classifier/108/boot/886 new file mode 100644 index 000000000..12832310e --- /dev/null +++ b/results/classifier/108/boot/886 @@ -0,0 +1,31 @@ +boot: 0.951 +device: 0.935 +graphic: 0.880 +performance: 0.776 +vnc: 0.662 +semantic: 0.584 +socket: 0.581 +PID: 0.568 +network: 0.444 +debug: 0.362 +permissions: 0.284 +other: 0.148 +KVM: 0.095 +files: 0.092 + +OpenIndiana panics when using -accel hvf +Description of problem: +OpenIndiana panics on boot. + +``` +Loading unix... +Loading /platform/i86pc/amd64/boot_archive... +Loading /platform/i86pc/amd64/boot_archive.hash... +Booting... +OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit + +panic[cpu0]/thread=fffffffffbc49060: +``` +Steps to reproduce: +1. Run given command +2. Wait |