From owner-freebsd-current@freebsd.org Mon Jan 18 23:30:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D121A87E38 for ; Mon, 18 Jan 2016 23:30:44 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id DEF731DEA; Mon, 18 Jan 2016 23:30:43 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (bcdd4360.skybroadband.com [188.221.67.96]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id E1EC1D7A17; Mon, 18 Jan 2016 23:30:12 +0000 (UTC) Date: Mon, 18 Jan 2016 23:30:11 +0000 From: Andrew Turner To: Steven Hartland Cc: Ed Maste , Dimitry Andric , "O. Hartmann" , freebsd-current Subject: Re: r294248: boot stuck: EFI loader doesn't proceed Message-ID: <20160118233011.25314f89@zapp> In-Reply-To: <569D6B3A.5090508@multiplay.co.uk> References: <20160118072000.4a03a4d2@freyja.zeit4.iv.bundesimmobilien.de> <596CBFC9-275C-445F-9D2B-23B90DB9966A@FreeBSD.org> <20160118113411.2a4d3079@zapp> <569CD4D6.50404@freebsd.org> <20160118202642.4f52614b@zapp> <569D6B3A.5090508@multiplay.co.uk> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 18 Jan 2016 23:30:44 -0000 On Mon, 18 Jan 2016 22:46:18 +0000 Steven Hartland wrote: > On 18/01/2016 21:57, Ed Maste wrote: > > On 18 January 2016 at 15:26, Andrew Turner > > wrote: > >> the issue was we were caching reads from the first filesystem we > >> looked at. I've committed the fix in r294291 to force the code to > >> re-read on each filesystem it looks at. > > Thanks Andrew - my QEMU boot failure is not reproducible on a build > > from a clean tree with this change included. > I still think there are issues in there, specifically the lookup call > in try_load, which calls fsread should be getting bad results. How? fsread will be called with dsk_meta == 0 so it will call the force probe path. Andrew