Divide-by-zero in loader

[Matthew Fleming]

On Fri, Jan 28, 2011 at 11:00 AM, John Baldwin <jhb at 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.  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?

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