The first problem (during probing) seems to be a hardware/pc problem, but
has NetBSD resolved all/any of the problems below re. 4gb size ?  I realise
there was a large amount of work done to make things 64bit, but I've not
RTFS or tried a big disk like that :)

Darren

In some mail from S\xren Schmidt, sie said:
> From owner-freebsd-hackers@freefall.freebsd.org Thu Feb 13 20:18:20 EDT 1997
> From: S\xren Schmidt <sos@ravenock.cybercity.dk>
> Message-Id: <199702130841.JAA27792@ravenock.cybercity.dk>
> Subject: Re: _big_ IDE disks?
> In-Reply-To: <199702130320.NAA17080@genesis.atrad.adelaide.edu.au> from Michael Smith at "Feb 13, 97 01:50:31 pm"
> To: msmith@atrad.adelaide.edu.au (Michael Smith)
> Date: Thu, 13 Feb 1997 09:41:43 +0100 (MET)
> Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org
> X-Mailer: ELM [version 2.4ME+ PL30 (25)]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 8bit
> Sender: owner-hackers@freebsd.org
> X-Loop: FreeBSD.org
> Precedence: bulk
> 
> In reply to Michael Smith who wrote:
> > Some more information :
> > 
> > Michael Smith stands accused of saying:
> > > These are the 5GB Maxtor 'DiamondMax' disks we're talking about here,
> > > talking to a Tekram P5H30WS motherboard (current Award BIOS).
> > > 
> > > The problem set looks something like this :
> > > 
> > >  - during probe, the disk is reported thus :
> > > 
> > > a8tor 85120 A8  ->: <
> > 
> > This apears to be about right; DM (Maxtor's "MaxBlast" software) reports the
> > same ID.  Weird.  Anyone have any contacts at Maxtor I should be bugging
> > about this?
> 
> Try maxtor directly, they have provided me with some info in the past
> (allthough that was long ago)
> 
> > > wd0: 633MB (9685824 sectors), 9224 cylinders, 16 heads, 61 S/T, 512 B/S
> > 
> > The '633MB' is due to bad arithmetic in wd.c, where an intermediate is
> > set to the number of bytes on the disk :
> > 
> > 		du->dk_dd.d_secperunit
> > 		* du->dk_dd.d_secsize / (1024 * 1024),
> > 
> > I propose to change this to :
> > 
> > 		(long)((long long)du->dk_dd.d_secperunit
> > 		* du->dk_dd.d_secsize / (1024 * 1024)),
> > 
> > in order to force the intermediate values to 'long long'.  An alternative
> > would be to use the approach that sd.c does :
> > 
> > 		dp->disksize / ((1024L * 1024L) / dp->secsiz)
> > 
> > which loses some precision but avoids playing type games.  Comments?
> 
> I'm easy on this one, the sd.c approach looks a bit prettier though...
> 
> > >  - While installing, the installer seems to write the partition table OK,
> > >    but can't write the label or swap on the disk.
> > 
> > This appears to be because I can't make a single partition bigger than 4GB.
> > I'll try installing to the Jaz in this box so that I can get it onto our
> > network.  Soren, if you're playing ATA god, I'd really appreciate any
> > input you may have here.
> 
> Hmm, this is exactly one of the drives I'm planning to buy for my ATA
> project (which I think I told you right?), just a wee bit short of cash 
> yet, but if this is important enough, I'll try find a solution to that. 
> We are likely to have to change a fair bit of arithmetic here and
> there it seems, to have this working for wd/ata/ide devices :(
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Søren Schmidt               (sos@FreeBSD.org)               FreeBSD Core Team
>                 Even more code to hack -- will it ever end
> ..
>