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 <ian_at_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 <ian_at_freebsd.org> schrieb: >> >> > 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. :) >> > > >> >> > > >> Thanks! >> > > >> >> > > >> >> > > >> >> > > >> -adrian >> > > >> >> > > >> >> > > >> On 25 December 2014 at 10:42, O. Hartmann <ohartman_at_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_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Sun Dec 28 2014 - 20:37:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC