I really don't think there is an issue with multiple cards of the same type. I've found that that sort of ordering can usually be fixed by playing with irq/mem locations, or PCI slots, etc. My problem lies with SCSI cards of different types (esp. on different bus types), and the kernels fixed ideas about who goes first.
Actually, if multiple SCSI controllers behaved as did multiple ethernet cards, the problem would be solved. You are correct that only one ethernet card is automaticly detected, but I can specify at the LILO prompt to look for eth0 or eth1 at a particular irq/mem tupile by saying "linux ether=5,0x7000,eth0 ether=11,0x280,eth1" or some such. Not ideal, I realize, but rather better than nothing. Would it be possible to have something that allowed "linux scsi=<some probed value(s)>,scsi0 scsi=<some probed value(s)>,scsi1", or at least something like "linux scsi0=AM53C974 scsi1=aic7xxx".
- Ken
@
Sent by: [EMAIL PROTECTED]
01/01/2000 05:14 PM
To: Douglas Gilbert <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
bcc:
Subject: Re: Convincing the aic7xxx driver that it's scsi1
On Sat, 1 Jan 2000, Douglas Gilbert wrote:
> I have had a similar frustration with several different controllers
> (different models) from the same manufacturer that all use the same
> driver. Loading it as a module won't help either. I need to hack
> the driver code if I want a different order (and the order it picks
> is oldest technology first :-( ).
>
> A kernel boot option to re-order the host list just after detection
> shouldn't be too hard. But how to specify the option? On my
> machine the scsi host strings look like this:
>
> $ cat /proc/scsi/sg/host_strs
> AdvanSys SCSI 3.2L: ISA PnP 16 CDB: BIOS C800, IO 120/F, IRQ 10, DMA 7
> AdvanSys SCSI 3.2L: PCI Ultra-Wide: BIOS E0000/7FFF, IO C800/3F, IRQ 11
> AdvanSys SCSI 3.2L: PCI Ultra2-Wide: IO CC00/FF, IRQ 5
> SCSI host adapter emulation for IDE ATAPI devices
>
> One idea for a boot line option:
> scsi_hosts_order=Ultra2,,Wide
> This will bring the first host found with "Ultra2" in its identifier
> string to the scsi0 position and the "first" host matching "Wide"
> (excluding the one already matched) to the scsi2 position. That
> leaves the first unmatched host (the ISA one) in the scsi1
> position. Comments ...
A couple of observations. Just so everyone knows, the order in
which host adapters are detected which are all handled by the same driver
is essentially all up to the low-level driver itself.
The mid-layer itself is only responsible for the order in which
the compiled in drivers are probed. In general I would tend to agree that
in situations where there are multiple cards, the user should probably
only compile one driver into the kernel and then load the rest as modules.
This is essentially the approach that you are forced to take when you
install multiple ethercards (the scanning code stops after detecting a
single instance, I believe). The ambiguity which remains is when a
single driver drives more than one physical card.
At the moment, I am a little leery of an arbitrary re-ordering of
hosts. I suppose it could be made to work, but there are also potential
problems where you have multiple instances of identical cards in which
case about all you could do is specify something like an interrupt number
which would be card/slot specific. Part of my reluctance is also my
tendancy to try and avoid creeping featurism, as usability goes down the
toilet as you add more and more configuration options that most people
don't really understand. Finally, I have strong concerns that we might
break something for some drivers by making a change of this sort.
The other approach that I have seen used (with aha152x, for
example) is where you can specify options to the driver to force a
specific instance to be the the first card detected, etc. The
disadvantage here is that this needs to be implemented within each driver,
but the advantage is that the risk of breakage is probably a lot lower.
If people feel strongly about it, I guess I could probably be
convinced to think about a re-ordering some more, but my inclination at
the moment is to seek a different solution.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
