On 2 March 2015 at 16:06, Laszlo Ersek <ler...@redhat.com> wrote: > On 03/02/15 16:26, Gabriel L. Somlo wrote: >> Hi, >> >> Somewhere between commits bbc3758ab5bc0e526994a63d739d445416ff0c07 and >> d401a487416926594f5176cb8acf75eed4bea0f0 a bug was introduced which >> causes a booting qemu x86_64 vm to hang with a black screen. Getting >> OVMF to generate a debug log shows this: >> >> ... >> Loading driver FAB5D4F4-83C0-4AAF-8480-442D11DF6CEA >> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F40B240 >> Loading driver at 0x0007ED7C000 EntryPoint=0x0007ED7C2AF VirtioScsiDxe.efi >> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F3FA698 >> InstallProtocolInterface: 18A031AB-B443-4D1A-A5C0-0C09261E9F71 7ED81420 >> InstallProtocolInterface: 107A772C-D5E1-11D4-9A46-0090273FC14D 7ED81480 >> InstallProtocolInterface: 6A7A5CFF-E8D9-4F70-BADA-75AB3025CE14 7ED814A0 >> Loading driver CF569F50-DE44-4F54-B4D7-F4AE25CDA599 >> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F40B040 >> Loading driver at 0x0007ED76000 EntryPoint=0x0007ED762AF XenIoPciDxe.efi >> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F3FA398 >> InstallProtocolInterface: 18A031AB-B443-4D1A-A5C0-0C09261E9F71 7ED799A0 >> InstallProtocolInterface: 107A772C-D5E1-11D4-9A46-0090273FC14D 7ED79A00 >> InstallProtocolInterface: 6A7A5CFF-E8D9-4F70-BADA-75AB3025CE14 7ED79A20 >> Loading driver 565EC8BA-A484-11E3-802B-B8AC6F7D65E6 >> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7F400E40 >> Loading driver at 0x0007ED64000 EntryPoint=0x0007ED642AF XenBusDxe.efi >> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F3FA098 >> >> ASSERT_EFI_ERROR (Status = Not Found) >> ASSERT >> /home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC49/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/AutoGen.c(262): >> !EFI_ERROR (Status) >> >> >> I was going to bisect, but bbc3758ab5bc0e526994a63d739d445416ff0c07 >> also crashes during build, and I don't know if it's supposed to be >> "good" or "bad" from the point of view of the bug I'm actually chasing >> :) >> >> Please help (and sorry if this is already known, it just started >> happening to me after I pulled an hour or so ago)... > > I found this bug literally three minutes ago. :) >
Whoops, blind spot! We made sure everything still works ok under Xen on x86, but I completely forgot about the Ovmf/x86 on !Xen case. My apologies. > The problem is that the xen hypercall lib initialization (the > constructor) fails in a non-Xen guest. Library constructor failures > trigger ASSERT_EFI_ERROR()s in autogenerated code. > > The right way to go about this is to call the library initialization > routine manually in client modules (which is XenBusDxe in this > instance), and if it fails, then exit the driver's entry point with an > error. > > It's quite bad that I didn't notice this during review. If Ard wants to > send a fix, that's good, otherwise I'll fix it up soon myself. > Well, could we first align on how to approach this? Calling the constructor explicitly is fine imo, but it means I should add an empty constructor to the ARM version as well. The ARM version is used in other (early) places as well, such as the XenConsoleSerialPortLib, and to be 100% correct, we should add calls to the constructor to those as well. Or we don't bother, which is also fine by me. > Alternatively, I should have found this bug before I pushed the v5 > patchset, but it was Saturday night, so I was satisfied when I saw that > everything compiled at least. :) > > Cheers > Laszlo ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
