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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
