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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"