Date: Fri, 28 Jan 2011 11:14:45 -0800 From: Matthew Fleming <mdf356@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Divide-by-zero in loader Message-ID: <AANLkTinHdZV3vYn25bHq7z_zzhKQM2z-Y8%2BsE%2BEz-fCP@mail.gmail.com> In-Reply-To: <201101281400.01840.jhb@freebsd.org> References: <AANLkTikxWagpLk-qFiEBLsx_S4vXkzCU57kht%2BF%2BcaC-@mail.gmail.com> <201101281400.01840.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 28, 2011 at 11:00 AM, John Baldwin <jhb@freebsd.org> 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. =A0Normally 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). =A0If the box is rebooted in this state, >> the reboot gets into /boot/loader and then reboots itself. =A0(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. =A0We'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. =A0A sector count of zero is invalid for CHS. =A0Ho= wever, > probably we should not even be using C/H/S at all if the device claims to > support EDD. =A0We 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? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinHdZV3vYn25bHq7z_zzhKQM2z-Y8%2BsE%2BEz-fCP>