First Impression of version 5.0.0

[Doug Ledford]

On 19-Jan-98 Eric Geyer wrote:
>
>I just had one note, and this applies only to the 3940 family.  There is
>note
>in the README (note 5 to be exact)  that mentions the "reverse_scan"
>variable
>in the aic7xxx.c module.  I believe that many 3940 users will have to set
>this
>to make their controllers scan the drivers in the same order as the older
>versions of the driver did.

Yes, if they are trying to maintain compatibility with the old driver, then
they very well may have to do this.  On the other hand, we should be
detecting the two channels on a 3940 in the same order as other operating
systems do at this point.  So, we have the reverse_scan hack in order to
allow people to easily decide which way they want things to be done. 
However, the reverse scan portion doesn't reverse everything.  In general,
the rules followed in this driver are as follows:

Detect any VLB/EISA controllers, find out if their BIOS is enabled, and get
their BIOS address from the config registers.

Detect any PCI controllers, ignore BIOS address (because I can't find a
portable way to get that from these controllers) and only use the BIOS
enabled settings to determine what to do with device negotiation, no more.

Take the list of all VLB/EISA/PCI cards then and before registering them
with the SCSI mid level code, split them into three lists.  The three lists
are as follows (in order that they get registered):

VLB/EISA controllers with their BIOS enabled
PCI controllers, sorted based upon the PCI bus/slot for each controller
VLB/EISA controllers with their BIOS disabled

The reverse scan option only effects the middle list, not the other two.  It
also is global on that list, it reverses the order of the *entire* PCI list.

Now, we register by simply pulling the entries off of those three lists in
the order that they were sorted into.  After talking with Justin, he
informed me that the standard PC BIOS mechanism for find ISA/VLB/EISA cards
was to search frmo 0xc8000 through the end of the available UMB area for a
BIOS signature, and if found, they run that BIOS to init whatever it happens
to control.  So, that means that all VLB/EISA controllers will get found in
the order that their BIOS entries are placed in upper memory.  Therefore,
this particular list sorting should be 100% accurate.  If the BIOS is
disabled on one of these controllers, then it won't get added to the boot
devices available from the normal DOS or BIOS int routines, so placing them
at the end should be totally safe as well.  It's the PCI list that's a
nightmare to get sorted properly.  As a matter of fact, even with the
reverse_scan hack in place, the current code will *not* properly sort the
devices on my machine under any conditions.  Why you ask?  Simple, the PCI
BIOS sucks.  Well, I'll be a little more specific than that.  Most PCI
BIOSes search for devices to init starting at PCI Bus #0, Slot #0 and going
on up to the end.  This is fine, and we'll sort this scenario great. 
However, if there is a bridge chip in that list somewhere, then where ever
that bridge chip is on the regular PCI bus, the BIOS jumps off and goes to
this *other* PCI bus to scan it.  In this driver, we don't know squat about
bridge chips.  All we know, is that some controllers are on another PCI bus
besides bus #0.  We know thier slot number on that bus, but we don't know
the slot number of the bridge chip that get's us there.  So, we go all the
way up one bus, then all the way up the next bus, etc.  In my case, the
problem is that I had the 7895, then a bridge chip on a 3985 was found, so
all of the devices on the 3985 were the next to get inited by the BIOS, then
the 2940UW was found.  Great, but the 7895 and the 2940UW were both on PCI
bus #0, and all three channels of the 3985 were on PCI bus #1.  So, without
the reverse_scan option enabled, the driver found them as 7895, 2940UW,
3985.  With the option enabled, it found 3985, 2940UW, 7895.  So, as you can
see, in order to fix that, I'll have to find the bridge chip that leads us
off of PCI bus #0 and make sure to insert *all* devices on that bus at that
location in the overall chain.  Anyway, just ranting about the hassle one
has to go through in order to get PCI devices in the same order as the PCI
BIOS does.....

>  I don't think that this is a problem, because
>IMHO, the older version scanned in the wrong order, because of some
>weirdness
>in many PCI BIOS implementations.  It would be nice if this was a config
>parameter,

It is a config option, you just set the config in /etc/lilo.conf or in
/etc/conf.modules instead of during the kernel compile :)  Besides, if
you're like me, and you occasionally fiddle with your settings, it's damn
annoying to have to recompile 90% of your kernel in order to change the
commands per lun default.  As much as possible, I'm trying to keep my
options out of the "make config" area simply because of that one issue.  If
you change the aic7xxx.c file OTOH, it only recompiles that one file, which
is *sooooo* much faster.  Besides, making it options that are load time or
boot time options means you don't even have to recompile at all, just reload
the module or reboot the kernel with the different params.  Much easier when
you are trying 20 or 30 different combinations of settings or some such
(although I can't imagine someone needing to do this).  Now, specifically,
on the reverse_scan option, I most definitely wanted that to be a boot time
option as opposed to compile time option for one very simple reason. 
Distributions.  They can't tell a customer to recompile their kernel because
it scans in the wrong order before they install, and after they install, if
they make that change, then all of their devices are out of order from what
the install set things up as :)

> but I can handle the situation as it is.  Anyway, after I fixed
>this
>small problem, everything worked great.  Thanks to Doug, Justin, Dan, and
>anyone else who contributed to this driver.
>
>Cheers
>Eric Geyer
>corduroy at sfo.com

----------------------------------
E-Mail: Doug Ledford <dledford at dialnet.net>
Date: 20-Jan-98
Time: 06:14:54
----------------------------------