From netch@quarta.carrier.kiev.ua  Tue Aug 10 06:18:08 2004
Return-Path: <netch@quarta.carrier.kiev.ua>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 05ED616A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 10 Aug 2004 06:18:08 +0000 (GMT)
Received: from quarta.carrier.kiev.ua (quarta.carrier.kiev.ua [193.193.193.11])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B9CFD43D45
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 10 Aug 2004 06:18:06 +0000 (GMT)
	(envelope-from netch@quarta.carrier.kiev.ua)
Received: from quarta.carrier.kiev.ua (localhost [127.0.0.1])
	by quarta.carrier.kiev.ua (8.12.11/8.12.11) with ESMTP id i7A6I4R6071747;
	Tue, 10 Aug 2004 09:18:04 +0300 (EEST)
	(envelope-from netch@quarta.carrier.kiev.ua)
Received: (from netch@localhost)
	by quarta.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i7A6I3Jb071746;
	Tue, 10 Aug 2004 09:18:03 +0300 (EEST)
	(envelope-from netch)
Message-Id: <200408100618.i7A6I3Jb071746@quarta.carrier.kiev.ua>
Date: Tue, 10 Aug 2004 09:18:03 +0300 (EEST)
From: Valentin Nechayev <netch@netch.kiev.ua>
Reply-To: Valentin Nechayev <netch@netch.kiev.ua>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: boot1 logic fix for large disks
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         70241
>Category:       i386
>Synopsis:       boot1 logic fix for large disks
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 10 06:20:23 GMT 2004
>Closed-Date:    Mon Dec 06 11:15:45 GMT 2004
>Last-Modified:  Mon Dec 06 11:15:45 GMT 2004
>Originator:     Valentin Nechayev
>Release:        FreeBSD 4.10-RELEASE-p2 i386
>Organization:
private
>Environment:
FreeBSD (any modern one)

>Description:

boot1 (src/src/sys/boot/i386/boot2/boot1.s) contains code (used by boot1,
boot2, and loader) to read disks, until kernel initializes its drivers
and get control.

This code uses makes BIOS calls in real x86 mode. To select between
"plain old" (geometerized) interface (B-1302 in Ralf Brown's terms)
and Int13x/EDD interface (d-1342), it uses EDD installation checking and
BIOS geometry request. Current logic (introduced in revision 1.13) tries
to fit arguments in B-1302 limitations (1024 cylinders, 256 heads, 63 sectors)
and use EDD only when it can't be fit (cyl>1023).

The problem appeared with ATA disks larger than 32G and Award 6.00 BIOSes.
In following I'll partially cite my message from hackers@
(http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2004-03/0181.html)

==={{{
The main factor to kill old access is strange BIOS translation for disks
larger than 32G. For two my home disks:

Model: IBM IC35L040AVER07-0
LBA size: 80418240 blocks
BIOS geometry in "LBA" mode: 5005*255*63
BIOS geometry in "NORMAL" mode: 19710*16*255
BIOS geometry in "LARGE" mode: 1314*240*255

Model: SAMSUNG SP1203N
LBA size: 234493056 blocks
BIOS geometry in "LBA" mode: 14596*255*63
BIOS geometry in "NORMAL" mode: 57473*16*255
BIOS geometry in "LARGE" mode: 3831*240*255
===}}}

So, BIOS translates geometry in any mode other than LBA[-assisted], to
one with 255 sectors. But geometry reporting interface (B-1308) can show
only 63 sectors, and boot1 code calls BIOS to load another block than
is supposed.

This was proven practically using system with Award BIOS and FreeBSD.
When switching BIOS to any translation other than LBA, boot failed
(boot2 loaded incorrect data instead of loader or kernel).

I asked Award support for reasons of such strange BIOS behavior;
silence was reply. I suppose no modern system uses traditional interface
when EDD is available (at least Linux and MS-Windows use EDD whenever possible),so

>How-To-Repeat:

All required data are in description section. In my letter in hackers@
(see URL above) I shown DOS mode test program and its results showing that
BIOS uses 255 sectors in internal calculations when reporting 63 sectors.

>Fix:

Revert logic of selection between traditional and EDD reading mode
to one which prefers EDD if available (as was in the same file in revisions
1.11 and 1.12). This is supported by John Baldwin (private conversation
after thread in hackers@):

==={{{
The problem is that there are BIOS's out there that claim to support EDD but
still don't work correctly.  I don't remember all the details at this point,
but I think it had to do with sysinstall not always being in sync with the
BIOS about how sectors were in a cylinder.  I guess though we could just turn
EDD on by default in 5.x or perhaps 6.0.  5.x doesn't really run well on a
386 or even a 486, and that is the class of machine that has problems with
EDD.
===}}}

So, at least preference to EDD is reasonable for -current; but I think
it can be also applicable for modern 4.* systems, at least as build option
or runtime flag. If it's needed I can attach patch for such variants.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Wed Aug 11 08:34:27 GMT 2004 
Responsible-Changed-Why:  
I hope I remember enough of PC BIOS programming to handle this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70241 

From: Yar Tikhiy <yar@freebsd.org>
To: Valentin Nechayev <netch@netch.kiev.ua>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: i386/70241: boot1 logic fix for large disks
Date: Wed, 11 Aug 2004 13:56:06 +0400

 This problem seems to boil down to the following.  FreeBSD /boot
 programs (namely, boot1, boot2, and loader) will fail to address
 a disk sector correctly if the following conditions are met:
 
 1) the disk reports more than 63 sectors per track as its "native"
    geometry parameter;
 2) the BIOS interacts with the disk in CHS mode;
 3) the sector resides within the first 1024 cylinders, as calculated
    using the _incorrect_ geometry reported by the BIOS through the old
    Get Drive Info call, INT13/08h
    ({incorrect sect/trk} = {correct sect/trk} mod 64).
 
 Using LBA as the BIOS disk mode can serve a workaround to this problem.
 
 Right?
 
 Which is really sad news, the FreeBSD mbr program seems to be even
 more broken.  It tries to use some intelligence based on values
 from the PC partition table to figure out the right mode for the
 disk.  However, the particular approach used looks really questionable.
 Additionally, it might fail under the same conditions.  A workaround
 is to install the boot0 program instead and configure it to use
 "packet mode" as described on the boot0cfg(8) manpage.
 
 And in the meantime we'll try to work out a solution...
 
 -- 
 Yar

From: Valentin Nechayev <netch@netch.kiev.ua>
To: Yar Tikhiy <yar@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: i386/70241: boot1 logic fix for large disks
Date: Wed, 11 Aug 2004 15:13:40 +0300

 Hi.
 
  Wed, Aug 11, 2004 at 13:56:06, yar wrote about "Re: i386/70241: boot1 logic fix for large disks": 
 
 > This problem seems to boil down to the following.  FreeBSD /boot
 > programs (namely, boot1, boot2, and loader) will fail to address
 > a disk sector correctly if the following conditions are met:
 > 
 > 1) the disk reports more than 63 sectors per track as its "native"
 >    geometry parameter;
 
 Almost correct, but it was not _disk_ initiative to report 255 sectors.
 Disks report 16383*16*63 as on-bus geometry, which is canonical value
 according to modern ATA standards. 255 sectors are personal artifact of
 Award BIOS. I've reported that AMI BIOS doesn't have this problem, but
 also doesn't have explicit geometry switch and uses checking of on-disk PT.
 
 > 2) the BIOS interacts with the disk in CHS mode;
 > 3) the sector resides within the first 1024 cylinders, as calculated
 >    using the _incorrect_ geometry reported by the BIOS through the old
 >    Get Drive Info call, INT13/08h
 >    ({incorrect sect/trk} = {correct sect/trk} mod 64).
 > 
 > Using LBA as the BIOS disk mode can serve a workaround to this problem.
 > 
 > Right?
 
 Yes.
 
 > Which is really sad news, the FreeBSD mbr program seems to be even
 > more broken.  It tries to use some intelligence based on values
 > from the PC partition table to figure out the right mode for the
 > disk.  However, the particular approach used looks really questionable.
 
 For the nowadays, such intelligence seems to be obsolete.
 
 > Additionally, it might fail under the same conditions.  A workaround
 > is to install the boot0 program instead and configure it to use
 > "packet mode" as described on the boot0cfg(8) manpage.
 
 
 -netch-

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: freebsd-gnats-submit@FreeBSD.org, netch@netch.kiev.ua
Cc:  
Subject: Re: i386/70241: boot1 logic fix for large disks
Date: Fri, 27 Aug 2004 18:40:00 +0400

 By the way, boot0 was fixed recently to use EDD by default.
 
 -- 
 Yar
State-Changed-From-To: open->patched 
State-Changed-By: yar 
State-Changed-When: Sat Aug 28 08:45:34 GMT 2004 
State-Changed-Why:  
Now CURRENT's boot1 and mbr try to use INT13 in packet mode first. 
Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70241 
State-Changed-From-To: patched->closed 
State-Changed-By: yar 
State-Changed-When: Mon Dec 6 11:11:12 GMT 2004 
State-Changed-Why:  
The issue has been addressed in CURRENT and 5-STABLE. 
The old boot logic will be kept in 4-STABLE. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70241 
>Unformatted:
