From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 28 19:27:31 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270D7106566B for ; Fri, 28 Jan 2011 19:27:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ED7DF8FC1C for ; Fri, 28 Jan 2011 19:27:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A2D2646B06; Fri, 28 Jan 2011 14:27:30 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A114E8A009; Fri, 28 Jan 2011 14:27:29 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Fri, 28 Jan 2011 14:23:02 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101281400.01840.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101281423.02701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Jan 2011 14:27:29 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: Divide-by-zero in loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 19:27:31 -0000 On Friday, January 28, 2011 2:14:45 pm Matthew Fleming wrote: > On Fri, Jan 28, 2011 at 11:00 AM, John Baldwin wrote: > > On Friday, January 28, 2011 12:41:08 pm Matthew Fleming wrote: > >> I spent a few days chasing down a bug and I'm wondering if a loader > >> change would be appropriate. > >> > >> So we have these new front-panel LCDs, and like everything these days > >> it's a SoC. Normally it presents to FreeBSD as a USB communications > >> device (ucom), but when the SoC is sitting in its own boot loader, it > >> presents as storage (umass). If the box is rebooted in this state, > >> the reboot gets into /boot/loader and then reboots itself. (It took a > >> few days just to figure out I was getting into /boot/loader, since the > >> only prompt I could definitively stop at was boot2). > >> > >> Anyways, I eventually debugged it to the device somehow presenting > >> itself to /boot/loader with a geometry of 1024/256/0, and since od_sec > >> is 0 that causes a divide-by-zero error in bd_io() while the loader is > >> trying to figure out if this is GPT or MBR formatted. We're still > >> trying to figure out why the loader sees this incorrect geometry. > >> > >> But meanwhile, this patch fixes the issue, and I wonder if it would be > >> a useful safety-belt for other devices where an incorrect geometry can > >> be seen? > > > > That's probably fine. A sector count of zero is invalid for CHS. However, > > probably we should not even be using C/H/S at all if the device claims to > > support EDD. We already use raw LBAs if it supports EDD, and we should > > probably just ignore C/H/S altogether if it supports EDD. > > This is all almost entirely outside my knowledge, but at the moment > bd_eddprobe() requres a geometry of 1023/255/63 before it attempts to > check if EDD can be used. Is that check incorrect? Well, it is very conservative in that it only uses EDD if it thinks it can't use C/H/S. It would be interesting to see if simply checking for a sector count of 0 there would avoid the divide-by-zero and let your device "work". However, it might actually be useful to always use EDD if possible, esp. EDD3 since that lets you not use bounce buffers down in 1MB. > In my specific case I know there's no bootable stuff on this disk; the > earlier layers bypassed it correctly without a problem. > > Thanks, > matthew > -- John Baldwin