Subject: Re: UltraDMA problems under 1.6F (probably hardware)
To: None <current-users@netbsd.org>
From: gabriel rosenkoetter <gr@eclipsed.net>
List: current-users
Date: 08/13/2002 21:51:32
--HnQK338I3UIa/qiP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 13, 2002 at 09:11:43PM -0400, Stephen Degler wrote:
> You have two different drives with two different claimed speeds on
> the same ide interface. I'm not sure what NetBSD drivers will do with
> that (is the right thing in this case to drop to the lowest common
> denominator?). I think it would be best if they were on different ide
> channels.
Keep in mind that the old motherboard did this, running the big
drive at Ultra/100 and the small one at Ultra/66, just fine under
NetBSD 1.6B.
But it's a valid datapoint, there's a secondary IDE bus, and I've
got the cabling to try each as the sole drive on their bus (or,
really, take the 10 GB out of the picture entirely, since it's doing
precisely zip right now). I'll try that tomorrow evening. The
biggest problem is remembering how to jumper an IDE drive to be
alone, rather than a master. :^>
> The drive is 160 marketing gigabytes. Which your kernel correctly
> calculates to 152 computer science gigabytes. You should be able to use
> that amount.
But not under Ultra/100, which is limited to 120 visible GBs by
design (because, you know, 640 KB should be enough for anyone,
right?). Ultra/133 did away with that (addressing) error.
In any case, what I most want to know here is if there is some
specific debugging routine I should be going through to figure out
whether it's pciide(4) or our wd(4) that's not dealing properly with
this hardware. (I guess it's also possible that the response is
"Acer hardware sucks. Sorry kid!"... but that's what "quirks" are
for, last I checked. ;^>)
Oh, fwiw, this is the last IA32 (or, really, IAanything) machine I
will ever buy. The pure agony of dealing with the IRQ conflicts
getting just the SCSI card recognized properly is a process I
*never* need to repeat. And these are problems I wouldn't have had
with any other arch we support that I own (macppc, mac68k, alpha,
sgimips, next68k, sparc, sparc64... I think that's it these days).
So uh, up yours, Intel. :^>
--=20
gabriel rosenkoetter
gr@eclipsed.net
--HnQK338I3UIa/qiP
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (NetBSD)
iD8DBQE9Wbek9ehacAz5CRoRApnqAKCW3okcPgJAR/SYPlieWQG/cw507gCgk5mX
GL/UlVUMziTAdvhpFUXdTjE=
=hyZ0
-----END PGP SIGNATURE-----
--HnQK338I3UIa/qiP--