For some reason, the order of initializing the scsi drivers
changed between 2.4.2 and 2.4.3: If both, ncr53c8xx and aic7xxx
drivers are included in the kernel, up to version 2.4.2, the
adaptec driver always came first (so the first disk on an adaptec
controller ended up as /dev/sda) while in 2.4.3, the ncr driver
initializes first and all the device names change - with
potentially disastrous effects for unsuspecting users.
AFAIK, the numbering of scsi busses depends only on the order the
low-level drivers are loaded. Not that I can think of any better
way to do this, but it would be good if things were a little bit
more predictable - in absence of any better idea, maybe by
loading the drivers in alphabetical order or something like that ...
How is it possible, to influence that order at the moment (for
example, to revert to the old order)? I personally couldn't
figure out, where to change this.
Regards,
Peter Daum
Peter Daum <[email protected]> wrote:
> For some reason, the order of initializing the scsi drivers
> changed between 2.4.2 and 2.4.3: If both, ncr53c8xx and aic7xxx
> drivers are included in the kernel, up to version 2.4.2, the
> adaptec driver always came first (so the first disk on an adaptec
> controller ended up as /dev/sda) while in 2.4.3, the ncr driver
> initializes first and all the device names change - with
> potentially disastrous effects for unsuspecting users.
>
> AFAIK, the numbering of scsi busses depends only on the order the
> low-level drivers are loaded. Not that I can think of any better
> way to do this, but it would be good if things were a little bit
> more predictable - in absence of any better idea, maybe by
> loading the drivers in alphabetical order or something like that ...
Looking at the drivers/scsi/Makefile file in lk 2.4.3
you can see that aic7xxx_old.o is about half way down
the list with ncr53c8xx.o towards the end. So this
dictates the old behaviour (in the lk 2.4 series).
However the new aic7xxx driver isn't in that list,
it has its own entry:
subdir-$(CONFIG_SCSI_AIC7XXX) += aic7xxx
which seems to invoke drivers/scsi/aic7xxx/Makefile
_after_ all other built in adapters drivers are built.
Maybe another "make" mechanism needs to be found to
restore the previous ordering information. In any case
building the aic7xxx driver last has already surprised
a lot of people.
> How is it possible, to influence that order at the moment (for
> example, to revert to the old order)? I personally couldn't
> figure out, where to change this.
>>>>>>>>> scsihosts <<<<<<<<<<<<<
As a boot time option try:
scsihosts=aic7xxx:ncr53c8xxx
or if you are using lilo, in /etc/lilo.conf add:
append="scsihosts=aic7xxx:ncr53c8xxx"
Actually just doing:
scsihosts=aic7xxx
should do the trick for most people.
In the unlikely case that the SCSI mid level is a module,
then you can pass the scsihosts argument to the
module load (or add an option line to /etc/modules.conf):
modprobe scsi_mod scsihosts=aic7xxx:ncr53c8xxx
You could also read the SCSI-2.4-HOWTO at:
http://www.linuxdoc.org/HOWTO/SCSI-2.4-HOWTO/
BTW You can thank Richard Gooch and devfs for scsihosts.
Lucky he spotted the requirement some time back.
Doug Gilbert
On Sun, 1 Apr 2001, Douglas Gilbert wrote:
[...]
> >>>>>>>>> scsihosts <<<<<<<<<<<<<
>
> As a boot time option try:
> scsihosts=aic7xxx:ncr53c8xxx
> or if you are using lilo, in /etc/lilo.conf add:
> append="scsihosts=aic7xxx:ncr53c8xxx"
that does indeed change the bus numbering. Unfortunately, even
with this option, the first disk on the ncr controller becomes
"/dev/sda" ...
regards,
Peter Daum
Peter Daum wrote:
>
> On Sun, 1 Apr 2001, Douglas Gilbert wrote:
>
> [...]
>
> > >>>>>>>>> scsihosts <<<<<<<<<<<<<
> >
> > As a boot time option try:
> > scsihosts=aic7xxx:ncr53c8xxx
> > or if you are using lilo, in /etc/lilo.conf add:
> > append="scsihosts=aic7xxx:ncr53c8xxx"
>
> that does indeed change the bus numbering. Unfortunately, even
> with this option, the first disk on the ncr controller becomes
> "/dev/sda" ...
Peter,
This indicates that the method being used by the
new aic7xxx driver for initialization is broken
with respect to other scsi adapters.
The intent is that all built in HBA drivers are
initialized _before_ the built in upper level
drivers (e.g. sd). To get the effect you describe
the driver init order seems to have been:
register ncr53c8xxx
register sd
register aic7xxx # too late ...
Doug Gilbert
>On Sun, 1 Apr 2001, Douglas Gilbert wrote:
>
>[...]
>
>> >>>>>>>>> scsihosts <<<<<<<<<<<<<
>>
>> As a boot time option try:
>> scsihosts=aic7xxx:ncr53c8xxx
>> or if you are using lilo, in /etc/lilo.conf add:
>> append="scsihosts=aic7xxx:ncr53c8xxx"
>
>that does indeed change the bus numbering. Unfortunately, even
>with this option, the first disk on the ncr controller becomes
>"/dev/sda" ...
>
>regards,
> Peter Daum
This is probably because the aic7xxx driver is not linked into
the scsi "library" for statically compiled HBA drivers. It is
linked directly into the kernel and I believe is after the scsi.a
entry on the link line. I'll look into this on monday.
--
Justin
>The intent is that all built in HBA drivers are
>initialized _before_ the built in upper level
>drivers (e.g. sd). To get the effect you describe
>the driver init order seems to have been:
> register ncr53c8xxx
> register sd
> register aic7xxx # too late ...
It is bogus that this stuff depends on link order to function
correctly. The driver is built and linked into the kernel in its
current fashion to satisfy Linus' desire to make drivers as independant
from the SCSI Makefile and Config file as possible. I've modified
how the driver is built for the 6.1.9 driver release so it will be
linked in prior to the top level drivers.
--
Justin
"Justin T. Gibbs" wrote:
> It is bogus that this stuff depends on link order to function
> correctly.
No, it is simply one more rule, and one that is not immediately
obvious. Take heart though. Like Rolaids, 2.5's updated makefile
system will bring relief...
Make sure to add a comment, when you update the 2.4 makefile where link
order is significant. (as it is not, in all cases)
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
>"Justin T. Gibbs" wrote:
>> It is bogus that this stuff depends on link order to function
>> correctly.
>
>No, it is simply one more rule, and one that is not immediately
>obvious. Take heart though. Like Rolaids, 2.5's updated makefile
>system will bring relief...
Its not something the build system can "fix". Its a design issue
that will have to be corrected by writing code.
--
Justin