Date: Fri, 28 Jan 2011 14:00:01 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Matthew Fleming <mdf356@gmail.com> Subject: Re: Divide-by-zero in loader Message-ID: <201101281400.01840.jhb@freebsd.org> In-Reply-To: <AANLkTikxWagpLk-qFiEBLsx_S4vXkzCU57kht%2BF%2BcaC-@mail.gmail.com> References: <AANLkTikxWagpLk-qFiEBLsx_S4vXkzCU57kht%2BF%2BcaC-@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101281400.01840.jhb>