[7784] in linux-scsi channel archive
Re: Convincing the aic7xxx driver that it's scsi1
daemon@ATHENA.MIT.EDU (ken@seefried.com)
Sat Jan 1 18:07:38 2000
To: linux-scsi@vger.rutgers.edu
From: ken@seefried.com
Date: Sat, 1 Jan 2000 17:55:53 -0500
Message-ID: <OF85D66B3E.7582A438-ON05256859.007DF6C4@seefried.com>
MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<P>I really don't think there is an issue with multiple cards of the same t=
ype. 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 fix=
ed ideas about who goes first.</P><P>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 ir=
q/mem tupile by saying "linux ether=3D5,0x7000,eth0 ether=3D11,0x280,e=
th1" or some such. Not ideal, I realize, but rather better than =
nothing. Would it be possible to have something that allowed "li=
nux scsi=3D<some probed value(s)>,scsi0 scsi=3D<some probed value(=
s)>,scsi1", or at least something like "linux scsi0=3DAM53C974=
scsi1=3Daic7xxx". </P><P>- Ken</P><P><BR><FONT SIZE=3D2><B>@</B=
></FONT><BR><FONT SIZE=3D2>Sent by: owner-linux-scsi@vger.rutgers.edu</FONT=
><BR><FONT SIZE=3D2>01/01/2000 05:14 PM</FONT><BR><BR> <FONT SIZE=3D2>To:</=
FONT> <FONT SIZE=3D2>Douglas Gilbert <dgilbert@interlog.com></FONT><B=
R> <FONT SIZE=3D2>cc:</FONT> <FONT SIZE=3D2>linux-scsi@vger.rutgers.edu</FO=
NT><BR> <FONT SIZE=3D2>bcc:</FONT> <BR> <FONT SIZE=3D2>Subject:</FONT> <FON=
T SIZE=3D2>Re: Convincing the aic7xxx driver that it's scsi1</FONT><BR> <BR=
><BR></P><P><FONT FACE=3D"Monospace,Courier">On Sat, 1 Jan 2000, Douglas Gi=
lbert wrote:<BR>> I have had a similar frustration with several differen=
t controllers<BR>> (different models) from the same manufacturer that al=
l use the same<BR>> driver. Loading it as a module won't help either. I =
need to hack<BR>> the driver code if I want a different order (and the o=
rder it picks<BR>> is oldest technology first :-( ).<BR>><BR>> A k=
ernel boot option to re-order the host list just after detection<BR>> sh=
ouldn't be too hard. But how to specify the option? On my<BR>> machine t=
he scsi host strings look like this:<BR>><BR>> $ cat /proc/scsi/sg/ho=
st=5Fstrs<BR>> AdvanSys SCSI 3.2L: ISA PnP 16 CDB: BIOS C800, IO 120/F, =
IRQ 10, DMA 7<BR>> AdvanSys SCSI 3.2L: PCI Ultra-Wide: BIOS E0000/7FFF, =
IO C800/3F, IRQ 11<BR>> AdvanSys SCSI 3.2L: PCI Ultra2-Wide: IO CC00/FF,=
IRQ 5<BR>> SCSI host adapter emulation for IDE ATAPI devices<BR>><BR=
>> One idea for a boot line option:<BR>> scsi=5Fh=
osts=5Forder=3DUltra2,,Wide<BR>> This will bring the first host found wi=
th "Ultra2" in its identifier<BR>> string to the scsi0 positio=
n and the "first" host matching "Wide"<BR>> (excludi=
ng the one already matched) to the scsi2 position. That<BR>> leaves the =
first unmatched host (the ISA one) in the scsi1<BR>> position. Comments =
...<BR></FONT><BR><FONT FACE=3D"Monospace,Courier">A couple of observations=
. Just so everyone knows, the order in<BR>which host adapters are det=
ected which are all handled by the same driver<BR>is essentially all up to =
the low-level driver itself.<BR></FONT><BR><FONT FACE=3D"Monospace,Courier"=
>The mid-layer itself is only responsible for the order in which<BR>the com=
piled in drivers are probed. In general I would tend to agree that<BR=
>in situations where there are multiple cards, the user should probably<BR>=
only compile one driver into the kernel and then load the rest as modules.<=
BR>This is essentially the approach that you are forced to take when you<BR=
>install multiple ethercards (the scanning code stops after detecting a<BR>=
single instance, I believe). The ambiguity which remains is when a<BR=
>single driver drives more than one physical card.<BR></FONT><BR><FONT FACE=
=3D"Monospace,Courier">At the moment, I am a little leery of an arbitrary r=
e-ordering of<BR>hosts. I suppose it could be made to work, but there=
are also potential<BR>problems where you have multiple instances of identi=
cal cards in which<BR>case about all you could do is specify something like=
an interrupt number<BR>which would be card/slot specific. Part of my=
reluctance is also my<BR>tendancy to try and avoid creeping featurism, as =
usability goes down the<BR>toilet as you add more and more configuration op=
tions that most people<BR>don't really understand. Finally, I have st=
rong concerns that we might<BR>break something for some drivers by making a=
change of this sort.<BR></FONT><BR><FONT FACE=3D"Monospace,Courier">The ot=
her approach that I have seen used (with aha152x, for<BR>example) is where =
you can specify options to the driver to force a<BR>specific instance to be=
the the first card detected, etc. The<BR>disadvantage here is that t=
his needs to be implemented within each driver,<BR>but the advantage is tha=
t the risk of breakage is probably a lot lower.<BR>If people feel strongly =
about it, I guess I could probably be<BR>convinced to think about a re-orde=
ring some more, but my inclination at<BR>the moment is to seek a different =
solution.<BR></FONT><BR><FONT FACE=3D"Monospace,Courier">-Eric<BR></FONT><B=
R><BR><BR><BR><BR><BR><FONT FACE=3D"Monospace,Courier">-<BR>To unsubscribe =
from this list: send the line "unsubscribe linux-scsi" in<BR>the =
body of a message to majordomo@vger.rutgers.edu</FONT></P>=
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
