Updated to fc24, got unbootable 4.5.0-rc7 kernel, qemu 2.5.0 and edk2.git-0-20160324.b1635.gf0bbcdf.x86_64. The problem still persists. I was able to jump into ovmf setup menu, the drive is recognised. Trying booting from any partition results in a hang and errors. First it says about invalid MBR on a GPT disk, the last two lines of the debug console are: ExtractConfig: BlockToConfig(): Invalid Parameter, Progress="<null string> ASSERT /home/jenkins/workspace/edk2/rpmbuild/rpm/BUILD/edk2.git/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c(1256): TmpRequest != ((void *) 0)
In short, updating to qemu 2.5 did not help. On Mar 27, 2016 2:01 AM, "Blank Field" <ihatethisfi...@gmail.com> wrote: > OVMF is from git, upgrading QEMU ATM to 2.5.x. Apparently, fedora has 2.5 > qemu only in beta 24. > > Thanks for the advice, didn't know about the new qemu release. > On Mar 27, 2016 1:01 AM, "Dan Ziemba" <zman0...@gmail.com> wrote: > >> On Fri, 2016-03-25 at 01:10 +0300, Blank Field wrote: >> > Hello again, fellow subscribers. >> > >> > Since 4.3.X kernels I am experiencing some strange problems with disk >> > IO. >> > >> > I am passing through the whole /dev/sda(since i also dualboot into >> > that system for some weird software or hardware) to my VM, and since >> > recent versions of kernel the VM gets stuck in an endless loop, >> > consuming 100% one core. >> > >> > The ISA debug console says stuff like: >> > PartitionValidMbr: Bad MBR partition size EndingLBA(D99299D3) > >> > LastLBA(31FFF) >> > >> > The thing is that the disk in question has nothing to do with MBR, it >> > is formatted into GPT. >> > I can't pinpoint the source of that weird D99299D3 number. >> > >> > That kind of error happens for every partition detected. >> > >> > Device Start End Sectors Size Type >> > /dev/sda1 2048 1171875000 1171872953 558.8G Microsoft basic >> > data >> > /dev/sda2 1171875840 1172080639 204800 100M EFI System >> > /dev/sda3 1172080640 1172342783 262144 128M Microsoft reserved >> > /dev/sda4 1172342784 1465145343 292802560 139.6G Microsoft basic >> > data >> > /dev/sda5 1465145344 1953525134 488379791 232.9G Microsoft basic >> > data >> > That looks like a valid partition table for me. Moreover, the fact >> > that i am able to boot an UEFI-capable system bare-metal confirms >> > that >> > the partition table is correct. >> > >> > I remember i've seen some related messages on the list in february or >> > something, but they only stated the existence of this error. >> > >> > Have any of you seen stuff like that? If so, how do you live with it? >> > >> > Maybe i should write to edk2-devel mailing list for this, because it >> > isn't much related to VFIO, but normal qemu folks rarely sacrifice >> > the >> > whole disk to a VM. >> > >> > Versions: >> > QEMU emulator version 2.4.1 (qemu-2.4.1-7.fc23) >> > kernel 4.4.5-300.fc23.x86_64(doesn't matter much from 4.3.X) >> > edk2.git-0-20160311.b1594.gf6326d1.x86_64 >> > >> >> A lot of people had problems booting with OVMF with kernels 4.2 and >> 4.3. It's fixed for myself and I think most others with 4.4, but I >> think you may need fairly recent qemu and ovmf versions. Looks like >> your OVMF is new enough if that date means what I think it does, but >> you should try upgrading to qemu 2.5. >> >> _______________________________________________ >> vfio-users mailing list >> vfio-users@redhat.com >> https://www.redhat.com/mailman/listinfo/vfio-users >> >
_______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
