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"

Reply via email to