Date: Thu, 4 Feb 1999 22:44:31 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: tony@dell.com (Tony Overfield) Cc: avalon@advicom.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Unable to newfs HD >10G with 3.0 Message-ID: <199902042044.WAA27917@ceia.nordier.com> In-Reply-To: <3.0.6.32.19990204131321.00793ec0@bugs.us.dell.com> from Tony Overfield at "Feb 4, 99 01:13:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Overfield wrote:
> The newer PC's work fine because they all implement the same spec to solve
> the problem. There isn't a problem at the hardware level either because
> nothing has changed at the hardware level to support more than 8.4 GB.
>
> > Operating systems don't think that some of these non-standard
> >implementations are very funny, as turning a hard drive into a large
> >number of blocks into a logical volume is not as easy as it sounds, and
> >this can be made much more difficult when manufacturers start cutting
> >corners on drive firmware...
>
> This makes no sense. Most older operating systems do not support the
> BIOS extensions, but that's simply because they need to be updated,
> not because anything funny is going on.
This is not the case. At present, the result of an int 0x13/0x41
(Check Extensions Present) simply cannot be accepted at face value.
Microsoft goes to the considerable trouble of running tests in
their Windows fdisk utility, on a drive-by-drive basis, before
enabling support for int 0x13 extensions. (They don't rely on int
0x13/0x41.)
Portions of the FreeBSD boot code were initially written (late last
year) to rely on int 0x13/0x41 to indicate presence of disk address
packet support: choosing either a conventional (0x13/0x2) or extended
read (0x13/0x42), having tested the interface support bitmap. This
approach failed miserably.
Versions of Linux I've looked at don't appear to regard the int 0x13
extensions as (yet) being a viable standard.
Several DOS/Windows programmers of disk diagnostic/repair software,
in an informal survey late last year, indicated that they weren't
supporting the extensions, as they couldn't be relied on to "just
work" on any given machine which claimed support.
At least two specific problems I'm personally aware of are:
o Certain (probably older) BIOSes claim support, but the
CHS-LBA translation is not in accordance with the Phoenix
EDD 1.1 specification. (IIRC, some Award BIOSes have this
problem.)
o In certain BIOS setup configurations, the machine claims to
support the int 0x13 extensions, but in fact doesn't make
even a vague attempt to do so successfully. (A case in
point is a -- yes, it's a Dell -- OptiPlex Gxa here, despite
a late 1998 flash BIOS upgrade.)
This certainly is *not* an issue of "Oh, we just haven't gotten
around to updating the code yet."
--
Robert Nordier
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902042044.WAA27917>