r276200: EFI boot failure: kernel stops booting at pci0: <ACPI PCI bus> on pcib0
Jakob Alvermark
jakob at alvermark.net
Tue Dec 30 14:15:24 UTC 2014
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
More information about the freebsd-current
mailing list