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