Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Feb 1999 21:49:37 -0600
From:      Tony Overfield <tony@dell.com>
To:        Avalon Books <avalon@advicom.net>
Cc:        FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: Unable to newfs HD >10G with 3.0
Message-ID:  <3.0.6.32.19990204214937.00879b20@bugs.us.dell.com>
In-Reply-To: <Pine.BSF.4.05.9902042047240.25131-100000@vespucci.advicom. net>
References:  <3.0.6.32.19990204131321.00793ec0@bugs.us.dell.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 09:00 PM 2/4/99 -0600, Avalon Books wrote:
>   Perhaps some clarifications are in order...
>
>On Thu, 4 Feb 1999, Tony Overfield wrote:
>> This is false.  All newer PC's implement the same INT 13 BIOS extensions 
>> to get around the original INT 13 BIOS's 8.4 GB limitation.
>
>   I beg to differ. 

Well, have you seen a "newer PC" that doesn't implement INT 13 
extensions, or are you confusing what I said with some other problem 
that you've seen?

>PC hardware is what I do for a living, and this 8.4
>Gbyte *standard* is a big deal to my state, federal and
>institutional contracts. 

Heh, same here, among other things.

>For these non-standard implementations to be
>accepted, we have to jump though extra hoops (i.e. testing). Its rarely a
>problem to get them accepted as only a few BIOS's/drive firmware's are
>behind the curve so far as to fail our testing.

I was assuming the devices are not known to be defective.  All bets are 
off for any *standardized* behavior of broken devices.

>   Essentially correct. To the BIOS, its just another big block device.
>But getting that block device to translate into a useable form has had its
>problems. Ask Fujitsu and Samsung about the firmware nightmare they went
>through last year...

Then they must have really bunged it up.  I've not seen such a problem 
with any of the drive suppliers we use.

>> >   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 perfect sense. We have a great deal more trouble from
>idiosyncratic drive firmware than motherboard BIOS's. Sometimes things
>just don't translate like they should, and the O/S's have no choice but to
>"give up" on a drive with broken firmware. Its not the O/S's fault, of
>course, but all you can do is swap the drive for one that works properly.

There's no excuse for busted drive firmware, but you can't blame the 
"8.4 GB solution" which, as I said, works correctly if implemented 
properly.  

You implied that there are a bunch of nonstandard solutions to this 
problem, but that isn't true.  I don't consider a bug in a particular 
drive's firmware to constitute a "nonstandard implementation."  In my 
mind, and probably yours too, it is simply broken and needs to be 
replaced.



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?3.0.6.32.19990204214937.00879b20>