scsi bus numbering
Quoted 8 lines · Peter Daum
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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:
[...]
Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
scsihosts <<<<<<<<<<<<<
As a boot time option try:
scsihosts=aic7xxx:ncr53c8xxx
or if you are using lilo, in/etc/lilo.confadd:
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
Quoted 7 lines · Peter Daum
On Sun, 1 Apr 2001, Douglas Gilbert wrote:
[...]
Quoted 2 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
scsihosts <<<<<<<<<<<<<
Quoted 8 lines
Quoted 4 lines
As a boot time option try:
scsihosts=aic7xxx:ncr53c8xxx
or if you are using lilo, in/etc/lilo.confadd:
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
Quoted 11 lines · Douglas Gilbert
[...]
Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
scsihosts <<<<<<<<<<<<<
As a boot time option try:
scsihosts=aic7xxx:ncr53c8xxx
or if you are using lilo, in/etc/lilo.confadd:
append="scsihosts=aic7xxx:ncr53c8xxx"
Quoted 6 lines
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
Quoted 7 lines
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
Quoted 2 lines · Justin T. Gibbs
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)
Signature · 3 lines
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.
Quoted 7 lines
Quoted 2 lines · Justin T. Gibbs
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