support for adaptec 2100s under RH7.0?
Kelledin
back, but it hasn't been posted. What this means to me is that there's
probably some issues that came up before the release.
The official maintainer of the driver was, at last census, Deanna Bonds
(deanna...@adaptec.com). She occasionally posts on linux.dev.raid; her
last message said to e-mail her if you need the driver. She would also
probably appreciate receiving bug reports (minus flaming, of course). I
e-mailed her a few days ago, but she hasn't replied yet.
Adaptec's tech support isn't much help, although they do make an honest
effort; my guess is that they haven't actually received much Linux training.
Some of them don't seem to know any more than to point you to
http://linux.adaptec.com
> I've seen that some of the 6.x's are supported. But there seems to be
> know way that I can find to get 7.0 to recognize the card at boot time.
> This is important because I would like to install to the primary raid
> device. Has anyone seen any support for this and/or know of a work
> around?
>
> Thanks in advance
>
> -B
>
>
Kim R.
There is a Red Hat 7.0 driver. Adaptec is working hard at continuing to
train technical support. Many have been through training. I have faith
that experience will greatly enhance their ability to provide support under
Linux.
The next development phase of http://linux.adaptec.com should be happening
soon along with some facelifts, the new and improved 2.x driver, and
additional SCSI/NIC drivers and patches on the website.
Kim
> Kelledin wrote in message ...
Peter T. Breuer
> The next development phase of http://linux.adaptec.com should be happening
> soon along with some facelifts, the new and improved 2.x driver, and
> additional SCSI/NIC drivers and patches on the website.
Now where did I get the
linux-aic7xxx-latest-2.4.0.diffs.gz
from? I can't seem to work it out from the contents. It looks like a
work of justin gibbs at freebsd, replacing the Doug Ledford driver.
But it must be someone trying to write a universal interface, because
it's got a linux-compatibilty code module that obviously is meant to
make the whole thing swing.
Anyone recognize it?
-rw-r--r-- 1 ptb 179381 Mar 18 12:45 linux-aic7xxx-6.1.7-src.tar.gz
-rw-r--r-- 1 ptb 431385 Mar 18 12:45 linux-aic7xxx-latest-2.2.16.diffs.gz
-rw-r--r-- 1 ptb 432114 Mar 18 12:44 linux-aic7xxx-latest-2.2.18.diffs.gz
-rw-r--r-- 1 ptb 445339 Mar 18 12:44 linux-aic7xxx-latest-2.4.0.dif
I wanna talk to the author ...
Peter
Trevor Hemsley
wrote:
Looks like Justin Gibbs' driver that is now the default in kernel
2.4.3. 2.4.3 has 6.1.5 IIRC but JG's web site is up to 6.1.8 or 9.
--
Trevor Hemsley, Brighton, UK.
Trevor-...@dial.pipex.com
Bjørn Wennberg
URL to the aic7xxx drivers:
http://people.FreeBSD.org/~gibbs/linux/
(The 6.1.5 version of the aic7xxx driver apparantly had a bug in the link-line
adding the driver last when compiling the driver so you could actually end up
getting your old /dev/sda becoming /dev/sdb. Gibbs recommends using the latest
driver)
btw - I just patched up a 2.2.19 kernel with the latest driver and saw
major speed improvements.
bjornw>
--
------------------------------------------------------------------------
bjo...@planetarion.com Bjørn Wennberg, Fifth Season AS
Peter T. Breuer
> Trevor-...@no.spam.dial.pipex.com (Trevor Hemsley) writes:
> URL to the aic7xxx drivers:
> http://people.FreeBSD.org/~gibbs/linux/
> (The 6.1.5 version of the aic7xxx driver apparantly had a bug in the link-line
> adding the driver last when compiling the driver so you could actually end up
> getting your old /dev/sda becoming /dev/sdb. Gibbs recommends using the latest
> driver)
> btw - I just patched up a 2.2.19 kernel with the latest driver and saw
> major speed improvements.
I'm just trying for stability. I have a 19160 controller and 4 WD lvd
disks. I've stepped the controler down to 40MB/s and it's much more
stable. But putting 3 disks online and I get various horrors ...
SCSI disk error : host 0 channel 0 id 3 lun 0 return code = 70000
I/O error: dev 08:21, sector 11498
(scsi0:A:3:0): Unexpected busfree in Data-out phase
SEQADDR == 0x56
(scsi0:A:3:0): Unexpected busfree in Data-out phase
SEQADDR == 0x57
(scsi0:A:3:0): Unexpected busfree in Data-out phase
SEQADDR == 0x55
This is with the 6.1.5 driver under 2.4.0, but I believe it must be
hardware or cable related. The machine tends not to complete the bios
scan sometimes, which usually means cable or termination. Mind you,
the controller just verified (low level sweep) the disks successfully.
There are too many parameters to call ... One of the disks is offering
the termination. Should I set term-pwr on it? Surely that's only in
case an external terminator is there. That disk is set to term.
And what's with the init-target jumpers? I have the disks set to
delayed startup and the controller set to issue startup, which seems to
me to be right in order to avoid the forst power spike.
Sigh .. maybe I'll step things down further.
I'll also patch the 2.2.15 kernel (it's my favorite).
Peter
Bjørn Wennberg
> In comp.os.linux.hardware Bjorn Wennberg <bjo...@planetarion.com> wrote:
> > Trevor-...@no.spam.dial.pipex.com (Trevor Hemsley) writes:
> > URL to the aic7xxx drivers:
> > http://people.FreeBSD.org/~gibbs/linux/
>
> > (The 6.1.5 version of the aic7xxx driver apparantly had a bug in the link-line
> > adding the driver last when compiling the driver so you could actually end up
> > getting your old /dev/sda becoming /dev/sdb. Gibbs recommends using the latest
> > driver)
>
> > btw - I just patched up a 2.2.19 kernel with the latest driver and saw
> > major speed improvements.
>
> I'm just trying for stability. I have a 19160 controller and 4 WD lvd
> disks. I've stepped the controler down to 40MB/s and it's much more
> stable. But putting 3 disks online and I get various horrors ...
>
> SCSI disk error : host 0 channel 0 id 3 lun 0 return code = 70000
> I/O error: dev 08:21, sector 11498
> (scsi0:A:3:0): Unexpected busfree in Data-out phase
> SEQADDR == 0x56
> (scsi0:A:3:0): Unexpected busfree in Data-out phase
> SEQADDR == 0x57
> (scsi0:A:3:0): Unexpected busfree in Data-out phase
> SEQADDR == 0x55
I'm not a hardware wuzz, but you should try to enable the extra
checks in scsi commands under the SCSI kernel config.
About termination. You just hook up all disks on the cable and terminate
the cable at the end.
You should also try one disk at a time and see if you are simply having
problems with one of the disks.
>
> This is with the 6.1.5 driver under 2.4.0, but I believe it must be
> hardware or cable related. The machine tends not to complete the bios
> scan sometimes, which usually means cable or termination. Mind you,
> the controller just verified (low level sweep) the disks successfully.
>
> There are too many parameters to call ... One of the disks is offering
> the termination. Should I set term-pwr on it? Surely that's only in
> case an external terminator is there. That disk is set to term.
>
> And what's with the init-target jumpers? I have the disks set to
> delayed startup and the controller set to issue startup, which seems to
> me to be right in order to avoid the forst power spike.
>
> Sigh .. maybe I'll step things down further.
>
> I'll also patch the 2.2.15 kernel (it's my favorite).
>
> Peter
--
Peter T. Breuer
> "Peter T. Breuer" <p...@oboe.it.uc3m.es> writes:
>> In comp.os.linux.hardware Bjorn Wennberg <bjo...@planetarion.com> wrote:
>> > Trevor-...@no.spam.dial.pipex.com (Trevor Hemsley) writes:
>> > http://people.FreeBSD.org/~gibbs/linux/
>> > (The 6.1.5 version of the aic7xxx driver apparantly had a bug in the link-line
>> > adding the driver last when compiling the driver so you could actually end up
>> > getting your old /dev/sda becoming /dev/sdb. Gibbs recommends using the latest
>> disks. I've stepped the controler down to 40MB/s and it's much more
>> stable. But putting 3 disks online and I get various horrors ...
>>
>> SCSI disk error : host 0 channel 0 id 3 lun 0 return code = 70000
>> I/O error: dev 08:21, sector 11498
>> (scsi0:A:3:0): Unexpected busfree in Data-out phase
>> SEQADDR == 0x56
>> (scsi0:A:3:0): Unexpected busfree in Data-out phase
>> SEQADDR == 0x57
>> (scsi0:A:3:0): Unexpected busfree in Data-out phase
>> SEQADDR == 0x55
> I'm not a hardware wuzz, but you should try to enable the extra
> checks in scsi commands under the SCSI kernel config.
Everything's checked.
> About termination. You just hook up all disks on the cable and terminate
> the cable at the end.
Yes, we know. The question is whether term-pwr does anything when the
disk itself is the terminator (i.e. last on the line, and the physical
end of bus too, and set to term). It's not clear to me if term-pwr is
for external terminators or for the internal one. It only makes sense
to me if it's for the external one (which isn't there).
> You should also try one disk at a time and see if you are simply having
> problems with one of the disks.
No disk on its own has any problems (didn't I say so? Oh well), though
I haven't tried them all in every position and on every socket on the
cable. I do have two cables and at least 4 sockets on each to try! The
number of combos is prohibitively large. My impression from experiments
is that the controller will do 80 or 169MB/s, but set it to do either
and the disks go nuts. I guess they're scsi 2 and the controller can't tell.
Nevertheless, low level scans from the controller show nothing bad, so it
must do all those at a conservative rate. I measured no difference in speed
to completion under various settings.
Maybe the 19160 has an unanounced limit of 2 scsi didks that it can
handle.
>> This is with the 6.1.[7] driver under 2.4.0, but I believe it must be
>> hardware or cable related. The machine tends not to complete the bios
>> scan sometimes, which usually means cable or termination. Mind you,
>> the controller just verified (low level sweep) the disks successfully.
>>
>> There are too many parameters to call ... One of the disks is offering
>> the termination. Should I set term-pwr on it? Surely that's only in
>> case an external terminator is there. That disk is set to term.
>>
>> And what's with the init-target jumpers? I have the disks set to
>> delayed startup and the controller set to issue startup, which seems to
>> me to be right in order to avoid the forst power spike.
>>
>> Sigh .. maybe I'll step things down further.
>>
>> I'll also patch the 2.2.15 kernel (it's my favorite).
This setting is safe. Three on line and things go bonkers.
Adaptec AIC7xxx driver version: 6.1.7
aic7892: Wide Channel A, SCSI Id=7, 32/255 SCBs
Channel A Target 0 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz DT, offset 255, 16bit)
Goal: 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
Curr: 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
Channel A Target 0 Lun 0 Settings
Commands Queued 152520
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 1 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz DT, offset 255, 16bit)
Goal: 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
Curr: 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
Channel A Target 1 Lun 0 Settings
Commands Queued 60
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 2 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz DT, offset 255, 16bit)
...
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: WDIGTL Model: WDE9100 ULTRA2 Rev: 1.21
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: WDIGTL Model: WDE9100 ULTRA2 Rev: 1.21
Type: Direct-Access ANSI SCSI revision: 02
Peter
Trevor Hemsley
wrote:
> The question is whether term-pwr does anything when the
> disk itself is the terminator (i.e. last on the line, and the physical
> end of bus too, and set to term).
I don't think *any* LVD disk has built in terminators. WD had some
duff documentation that said that their drives did but in fact they
didn't (the LVD spec actually requires that devices do not include
termination resistors).
You need a separate terminator for LVD devices.
Term power has nothing to do with termination BTW. It just controls
who or how many devices supply the power for termination to function.
Under normal circumstances the host adapter should supply term-pwr
without being asked. Some HA's have an option to provide/not provide
term-pwr - my DPT PM3334UW does for example - others don't mention it
at all or have undocumented jumpers that en/disable it (Adaptec 2940UW
f.e.). For most SCSI bus lengths it's usually sufficient that one
thing supplies term-pwr but for extra long cables it might be
necessary to enable term-pwr on a device near the far end of the cable
as well as on the HA.
Your symptoms sound suspiciously like lack of termination to me. With
only one or two devices on a bus you can often get away without it.
The more devices you have on the bus, the more likely it is to show up
as nasty errors wehn one end of a bus is unterminated.
Peter T. Breuer
> On Sat, 7 Apr 2001 16:22:57, "Peter T. Breuer" <p...@lab.it.uc3m.es>
> wrote:
>> The question is whether term-pwr does anything when the
>> disk itself is the terminator (i.e. last on the line, and the physical
>> end of bus too, and set to term).
> I don't think *any* LVD disk has built in terminators. WD had some
> duff documentation that said that their drives did but in fact they
> didn't (the LVD spec actually requires that devices do not include
> termination resistors).
Ahmmmmmmm! Yes, that would certainly explain it. The disks have jumpers
on the back labelled "term", but those aren't brought out to the front
jumpers (on the sca to lvd converter socket).
Owwwww.
> You need a separate terminator for LVD devices.
> Term power has nothing to do with termination BTW. It just controls
I understand this. It's just that it's not clear if - supposing there
were termination available on the disk - if term-pwr also needs to be
set to have the disk supply power to it (i.e. for active termination),
rather than the power for the internal termination - it it existed -
coming off the bus.
> who or how many devices supply the power for termination to function.
> Under normal circumstances the host adapter should supply term-pwr
The controller? I.e. power comes off the bus for it.
> without being asked. Some HA's have an option to provide/not provide
> term-pwr - my DPT PM3334UW does for example - others don't mention it
> at all or have undocumented jumpers that en/disable it (Adaptec 2940UW
> f.e.). For most SCSI bus lengths it's usually sufficient that one
So I presume it would also cause sparks to have term-pwr enabled both
on a controller and on a disk .. assuming that either worked!
> thing supplies term-pwr but for extra long cables it might be
> necessary to enable term-pwr on a device near the far end of the cable
> as well as on the HA.
> Your symptoms sound suspiciously like lack of termination to me. With
> only one or two devices on a bus you can often get away without it.
> The more devices you have on the bus, the more likely it is to show up
> as nasty errors wehn one end of a bus is unterminated.
Yes, I agree. Thanks.
Peter
Trevor Hemsley
wrote:
> It's just that it's not clear if - supposing there
> were termination available on the disk - if term-pwr also needs to be
> set to have the disk supply power to it (i.e. for active termination),
> rather than the power for the internal termination - it it existed -
> coming off the bus.
You should mostly only need one source of term-pwr on a SCSI bus. As I
said, it depends on bus length to some extent, more being required if
the bus is exceptionally long. It usually doesn't _hurt_ to have more
than one thing providing term-pwr on the same bus though I suspect
that if you enabled it on all your devices at once it might have
negative effects (there are fuses on most host adapters that will blow
and have to be replaced).
> > who or how many devices supply the power for termination to function.
> > Under normal circumstances the host adapter should supply term-pwr
>
> The controller? I.e. power comes off the bus for it.
From reading comp.periphs.scsi over a few years I've gathered that
"controller" in SCSI terms refers to the chip that sits on each
device. What thee and me generally refer to as a controller is more
properly known as a host adapter.
The jumper on the drive is used to tell it whether to feed term-pwr
onto the bus. Some Seagate drives have a multiple choice of how
term-pwr is provided. On my ST34371W you can select from a bank of
three jumpers that
A Drive Supplies Bus
B Drive Supplies Own
C Bus Supplies Drive
I'd guess that if it is on an LVD drive and it's not that specific
then it means that it'll supply term-pwr to the bus (since LVD drives
don't have their own terminators to power).