From owner-freebsd-current@FreeBSD.ORG Sun Dec 28 19:57:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02626A37; Sun, 28 Dec 2014 19:57:56 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F5EF64A63; Sun, 28 Dec 2014 19:57:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Y5JyE-003vBE-Op>; Sun, 28 Dec 2014 20:57:46 +0100 Received: from g226063010.adsl.alicedsl.de ([92.226.63.10] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Y5JyE-001mqp-Ko>; Sun, 28 Dec 2014 20:57:46 +0100 Date: Sun, 28 Dec 2014 20:57:39 +0100 From: "O. Hartmann" To: Ian Lepore Subject: Re: r276200: EFI boot failure: kernel stops booting at pci0: on pcib0 Message-ID: <20141228205739.154243d8.ohartman@zedat.fu-berlin.de> In-Reply-To: <1419621822.1018.187.camel@freebsd.org> References: <20141225194207.5dfd3636.ohartman@zedat.fu-berlin.de> <20141226130113.5200bfbb.ohartman@zedat.fu-berlin.de> <1419621822.1018.187.camel@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/mv5xernPaTNimen.vDWj6sn"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.10 X-ZEDAT-Hint: A Cc: Adrian Chadd , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 19:57:56 -0000 --Sig_/mv5xernPaTNimen.vDWj6sn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 26 Dec 2014 12:23:42 -0700 Ian Lepore schrieb: > On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: > > On 26 December 2014 at 04:01, O. Hartmann = wrote: > > > Am Thu, 25 Dec 2014 11:40:47 -0800 > > > Adrian Chadd 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 wrote: > > >> > > > >> > Since 23rd's update of CURRENT, the kernel fails to boot on system= s 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 boxe= s which boot > > >> > via legacy method. The very same failure showed up at the lab on a= n older HP > > >> > Compaq 8300 system, based on H81 chipset equipted with an Ivy-Brid= ge 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 r27= 5896 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 modul= es 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 poss= ible 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. > >=20 > > Hi! > >=20 > > Thanks for that. Would you please file a PR with the details and what > > you've done? > >=20 > > 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 :( >=20 > r276064 looks like a candidate. At least, it has 'efi' in the name. :) >=20 > -- Ian Well, r276063 works, but r2766064 doesn't. oh --Sig_/mv5xernPaTNimen.vDWj6sn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUoGCzAAoJEOgBcD7A/5N8dS0IAKKy6Q1VTSvf4xS9BCMRwTXe A3kPywWRkYaPDdF7iuTlF2csDQYEu/iVCRfWfhWJiTTe31pdhAm1u0sBe0FJJedl bPtkQPtZ5POnJaYdcRX0pG6KuuyS72OqnU4WjUTMEx7rnzG0LpaAh39Jn7wZ7bp0 WKj8EkudOOdNrK8tIxKAk68oLEE4Ps1qBe9vN6bk269ZS3yFUrDcSlHfwtJSuOcQ FMmy6hFfXsREA1unY9MDfLI9X2CxoJJOmtBkPOQZezpAFZmDD8sne4c508a5Pxuu WG3h16+ASCwzPEw9QyCsQo8or2ni0RBH4dnZB0pJcO6oimf/JBtAEb+96yKNQgk= =9qLQ -----END PGP SIGNATURE----- --Sig_/mv5xernPaTNimen.vDWj6sn--