Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Dec 2014 08:48:22 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        "O. Hartmann" <ohartman@zedat.fu-berlin.de>
Cc:        FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: r276200: EFI boot failure: kernel stops booting at pci0: <ACPI PCI bus> on pcib0
Message-ID:  <CAJ-Vmo=GUdB-0km4WuGbBmg-tuEebD1aAuWzGLDargUKcUffiw@mail.gmail.com>
In-Reply-To: <20141226130113.5200bfbb.ohartman@zedat.fu-berlin.de>
References:  <20141225194207.5dfd3636.ohartman@zedat.fu-berlin.de> <CAJ-VmomfxA3Fbmfx%2B5vHHR86KsR=YMh3e=nTBTci_nNa=Pz34w@mail.gmail.com> <20141226130113.5200bfbb.ohartman@zedat.fu-berlin.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26 December 2014 at 04:01, O. Hartmann <ohartman@zedat.fu-berlin.de> wrote:
> Am Thu, 25 Dec 2014 11:40:47 -0800
> Adrian Chadd <adrian@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 <ohartman@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=GUdB-0km4WuGbBmg-tuEebD1aAuWzGLDargUKcUffiw>