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. :) 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. 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
