Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
+1. ThinkPad T420 with nvidia discrete GPU, amd64 using memstick.img dd'ed to USB memstick. (So UEFI boot.) *Vanilla r276247 doesn't boot. No panic, just hang in allocating resource for pcib. Sorry for not recording exact message. *Reverting r276064 alone from r276247 helped. All other parts are r276247. *Legacy boot in VirtualBox VM is OK with vanilla r276247. On Sun, 28 Dec 2014 20:33:55 +0100 (CET) Jakob Alvermark ja...@alvermark.net wrote: Ian Lepore ian at freebsd.org writes: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohartman at zedat.fu- berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adrian at freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( r276064 looks like a candidate. At least, it has 'efi' in the name. :) I can confirm that. The same happened when UEFI-booting on my Acer E3-112. Undoing r276064 makes it boot again. (I will post some more experiences with FreeBSD on this machine later.) Jakob ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Tomoaki AOKIjunch...@dec.sakura.ne.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
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. Roger. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
El 28/12/14 a les 22.37, Adrian Chadd ha escrit: Hah sweet! You found the commit! Would you please file a PR so it doesn't get lost? Thanks! -adrian On 28 December 2014 at 12:09, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote: Am Fri, 26 Dec 2014 12:23:42 -0700 Ian Lepore i...@freebsd.org schrieb: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? 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? Thanks, Roger. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
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. Could you provide the information requested above with this patch applied? Thanks, Roger. diff --git a/sys/x86/x86/nexus.c b/sys/x86/x86/nexus.c index 0663602..d563c36 100644 --- a/sys/x86/x86/nexus.c +++ b/sys/x86/x86/nexus.c @@ -367,6 +367,10 @@ nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, struct rman *rm; int needactivate = flags RF_ACTIVE; + if (type == SYS_RES_MEMORY) + printf(%s: RSV range 0x%lx - 0x%lx size %lu\n, + device_get_name(child), start, end, count); + /* * If this is an allocation of the default range for a given * RID, and we know what the resources for this device are ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
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. Marius Index: dev/vt/hw/efifb/efifb.c === --- dev/vt/hw/efifb/efifb.c (revision 276343) +++ dev/vt/hw/efifb/efifb.c (working copy) @@ -211,8 +211,8 @@ res_id = 0; pseudo_phys_res = bus_alloc_resource(dev, SYS_RES_MEMORY, res_id, local_info.fb_pbase, - local_info.fb_pbase + local_info.fb_size, - local_info.fb_size, RF_ACTIVE); + local_info.fb_pbase + local_info.fb_size - 1, + local_info.fb_size, 0); if (pseudo_phys_res == NULL) panic(Unable to reserve vt_efifb memory); return (0); Index: dev/vt/hw/vga/vt_vga.c === --- dev/vt/hw/vga/vt_vga.c (revision 276343) +++ dev/vt/hw/vga/vt_vga.c (working copy) @@ -1275,8 +1275,8 @@ res_id = 0; pseudo_phys_res = bus_alloc_resource(dev, SYS_RES_MEMORY, - res_id, VGA_MEM_BASE, VGA_MEM_BASE + VGA_MEM_SIZE, - VGA_MEM_SIZE, RF_ACTIVE); + res_id, VGA_MEM_BASE, VGA_MEM_BASE + VGA_MEM_SIZE - 1, + VGA_MEM_SIZE, 0); if (pseudo_phys_res == NULL) panic(Unable to reserve vt_vga memory); return (0); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On Mon, Dec 29, 2014 at 08:12:42PM +0100, 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. Err, end = start + size - 1 that is. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
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. Jakob ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
Am Fri, 26 Dec 2014 12:23:42 -0700 Ian Lepore i...@freebsd.org schrieb: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). To avoid interferences from rogue modules, I disabled all modules loaded by the loader, including drm2 and i915kms, but the picture is always the same. I'm sorry, I have some duties to perform, so intersecting further is possible later only ... I performed the iterative search of the foul commit by svn update -r 276XXX and then build kernel only via make kernel - this just for the record in case some world-dependencies might have effects. Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( r276064 looks like a candidate. At least, it has 'efi' in the name. :) -- Ian Well, r276063 works, but r2766064 doesn't. oh pgpvj85PRaWFh.pgp Description: OpenPGP digital signature
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
Ian Lepore ian at freebsd.org writes: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohartman at zedat.fu- berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adrian at freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( r276064 looks like a candidate. At least, it has 'efi' in the name. :) I can confirm that. The same happened when UEFI-booting on my Acer E3-112. Undoing r276064 makes it boot again. (I will post some more experiences with FreeBSD on this machine later.) Jakob ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote: Am Fri, 26 Dec 2014 12:23:42 -0700 Ian Lepore i...@freebsd.org schrieb: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). To avoid interferences from rogue modules, I disabled all modules loaded by the loader, including drm2 and i915kms, but the picture is always the same. I'm sorry, I have some duties to perform, so intersecting further is possible later only ... I performed the iterative search of the foul commit by svn update -r 276XXX and then build kernel only via make kernel - this just for the record in case some world-dependencies might have effects. Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( r276064 looks like a candidate. At least, it has 'efi' in the name. :) -- Ian Well, r276063 works, but r2766064 doesn't. oh cc'ing the author of r276064, since spotting the fact that 'efi' was involved in that revision used up 100% of my expertise in efi stuff. :) -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
Hah sweet! You found the commit! Would you please file a PR so it doesn't get lost? Thanks! -adrian On 28 December 2014 at 12:09, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote: Am Fri, 26 Dec 2014 12:23:42 -0700 Ian Lepore i...@freebsd.org schrieb: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). To avoid interferences from rogue modules, I disabled all modules loaded by the loader, including drm2 and i915kms, but the picture is always the same. I'm sorry, I have some duties to perform, so intersecting further is possible later only ... I performed the iterative search of the foul commit by svn update -r 276XXX and then build kernel only via make kernel - this just for the record in case some world-dependencies might have effects. Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( r276064 looks like a candidate. At least, it has 'efi' in the name. :) -- Ian Well, r276063 works, but r2766064 doesn't. oh cc'ing the author of r276064, since spotting the fact that 'efi' was involved in that revision used up 100% of my expertise in efi stuff. :) -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). To avoid interferences from rogue modules, I disabled all modules loaded by the loader, including drm2 and i915kms, but the picture is always the same. I'm sorry, I have some duties to perform, so intersecting further is possible later only ... I performed the iterative search of the foul commit by svn update -r 276XXX and then build kernel only via make kernel - this just for the record in case some world-dependencies might have effects. oh ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). To avoid interferences from rogue modules, I disabled all modules loaded by the loader, including drm2 and i915kms, but the picture is always the same. I'm sorry, I have some duties to perform, so intersecting further is possible later only ... I performed the iterative search of the foul commit by svn update -r 276XXX and then build kernel only via make kernel - this just for the record in case some world-dependencies might have effects. Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh I narrowed down the culprit commit to be between r276060 (works) and r276075 (works not). To avoid interferences from rogue modules, I disabled all modules loaded by the loader, including drm2 and i915kms, but the picture is always the same. I'm sorry, I have some duties to perform, so intersecting further is possible later only ... I performed the iterative search of the foul commit by svn update -r 276XXX and then build kernel only via make kernel - this just for the record in case some world-dependencies might have effects. Hi! Thanks for that. Would you please file a PR with the details and what you've done? I hope you can narrow it down further. You've done a great job already, I just can't see any clear winner there for a commit to back out :( r276064 looks like a candidate. At least, it has 'efi' in the name. :) -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh pgp_9ujRHrS91.pgp Description: OpenPGP digital signature
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Merry christmas day, oh ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
