r276200: EFI boot failure: kernel stops booting at pci0: <ACPI PCI bus> on pcib0

[Jakob Alvermark]

On Tue, December 30, 2014 13:39, Roger Pau Monné wrote:
> El 29/12/14 a les 23.49, Jakob Alvermark ha escrit:
>
>> On Mon, December 29, 2014 20:12, Marius Strobl wrote:
>>
>>> On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote:
>>>
>>>
>>>> El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> Sorry for not noticing this earlier, I've been without a computer
>>>>> for some days. Do you get a panic message, or the system just
>>>>> freezes?
>>>>>
>>>>> Can you please post the full boot output with boot_verbose
>>>>> enabled?
>>>>>
>>>>
>>>> I'm not able to reproduce the problem with Qemu and OVMF, and I
>>>> don't have any box right now that uses UEFI.
>>>>
>>>> I'm guessing that this is due to some memory reservation conflict,
>>>> so I'm attaching a patch that should help diagnose it.
>>>>
>>>>
>>>
>>> You'll probably want to nuke RF_ACTIVE so the resources are marked
>>> as taken but in case of vt_efifb(4), the memory isn't mapped twice. I
>>> don't not know whether the latter actually is a problem for x86,
>>> though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING
>>> mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might not
>>> be sufficient for the Xen bits to mark the resource as reserved, this
>>> should be fixed in the FreeBSD/Xen code then, however.
>>> Also end = size - 1, see the attached patch.
>>>
>>
>> Hi, I tried this patch on my Acer. I does not help. Legacy boot (BIOS)
>> still works.
>
> I've reverted the EFI part of r276064 and committed it as r276405, I
> will revisit it in a couple of days when I have an UEFI system setup in
> order to test it on real hardware.

It works fine. Both legacy and UEFI. Thanks! Now on to the other
"interresting" things with UEFI on this machine...

Jakob