From owner-freebsd-hackers Thu Feb 13 00:40:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA27056 for hackers-outgoing; Thu, 13 Feb 1997 00:40:20 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27049 for ; Thu, 13 Feb 1997 00:40:13 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id JAA27792; Thu, 13 Feb 1997 09:41:53 +0100 (MET) From: Søren Schmidt 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 ..