From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <862d095fadcca15b20b903f45c9a5e6b@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: venti+fossil problems on new install
From: Charles Forsyth <forsyth@terzarima.net>
Date: Thu, 21 Sep 2006 23:00:40 +0100
In-Reply-To: <598d3f0713b9b8da2f9b048d6e7bf774@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: bd00e96a-ead1-11e9-9d60-3106f5b1d025

> obviously, there's something i still don't understand.  but that's not how it worked for me.  
> i was unable to use the SATA drive on a nForce4 without adding my particilar DIDs to
> the loop.  once i did (and i had to add the DID to 9load, too), the drives were recognized.
> and appeared in /dev.

the key thing is whether or not the SATA drive sits at the normal addresses and reacts as the driver expects.
if it does, it should be found, but  i'm sure i've seen cases
(even before SATA) where something that runs before the operating system, and we might as well
say the something is the BIOS, messes with the chips enough to make them look `different'.
that's why i referred to the `hammer' mentioned in a comment in the code. 
in other words, if they are at the usual ATA addresses and react as the driver expects,
they will be found; so conversely, if they are not found, they didn't, and you (or rather your kernel)
will fall into the subsequent pcimatch code, which requires enumerating the device IDs in its switch statement.