I see in the archives of this mailing list that someone was working on the
aacraid driver for the 2.4 kernel however that post was almost 2 months old.
I know Alan Cox denied inclusion of the driver due to the poor nature it was
written for the 2.2 tree. Every post that I have seen so far has just said
that Adaptec is working on it. However, I am sure there are many people out
there like myself that have to support this card in enviroments that would
be benifical to upgrade to 2.4 kernel. I am not a part of this list however
have been scouring through geocrawler.com archives of this list everyday for
the last month hoping and waiting.
Does anyone know the status of the driver or even the possibilities of it
getting included into the next kernel version (2.4.2)?
Please CC me on any replies that you may send.
Thanks for you time..
Jason Ford
[email protected]
Heymax Interactive
http://www.heymax.com
On Wed, 7 Feb 2001, Jason Ford wrote:
> I see in the archives of this mailing list that someone was working on the
> aacraid driver for the 2.4 kernel however that post was almost 2 months old.
> I know Alan Cox denied inclusion of the driver due to the poor nature it was
> written for the 2.2 tree. Every post that I have seen so far has just said
> that Adaptec is working on it. However, I am sure there are many people out
> there like myself that have to support this card in enviroments that would
> be benifical to upgrade to 2.4 kernel. I am not a part of this list however
> have been scouring through geocrawler.com archives of this list everyday for
> the last month hoping and waiting.
While it's totally unofficial, I have a patch for aacraid 1.0.6 for 2.4.1-ac5.
I have not tested it yet, but it compiles cleanly. I'd like to hear any results
(good or bad) you have on it.
You can find it at:
ftp://ftp.winds.org/linux/patches/2.4.1/aacraid-2.4.1-1.0.6.patch
Regards,
Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
Byron,
I got your patch to compile in fine however it still exhibits the same
behavior that the older patches did. It looks like the commands sent to the
controller are still not working correctly as the new subsystem in the
kernel was rewritten.
This is the error I get in my messages file when trying to copy from one
disk partition to another one.
Feb 7 19:32:11 bass kernel: SCSI disk error : host 0 channel 0 id 0 lun 0
return code = 1
Feb 7 19:32:11 bass kernel: I/O error: dev 08:08, sector 657672
Feb 7 19:32:11 bass kernel:
Feb 7 19:32:11 bass kernel:
Feb 7 19:32:11 bass kernel: AacHba_`DoScsiWrite: WRITE request is larger
than 64K
Feb 7 19:32:11 bass kernel: AacHba_DoScsiWrite: ByteCount: 69632
Feb 7 19:32:11 bass kernel: AacHba_DoScsiWrite: SG ELEMENTS: 16
Feb 7 19:32:11 bass kernel: Dump SG Element Size...
Feb 7 19:32:11 bass kernel: SG Segment 0: 4096
Feb 7 19:32:11 bass kernel: SG Segment 1: 4096
Feb 7 19:32:11 bass kernel: SG Segment 2: 4096
Feb 7 19:32:11 bass kernel: SG Segment 3: 4096
Feb 7 19:32:11 bass kernel: SG Segment 4: 4096
Feb 7 19:32:11 bass kernel: SG Segment 5: 4096
Feb 7 19:32:11 bass kernel: SG Segment 6: 4096
Feb 7 19:32:11 bass kernel: SG Segment 7: 8192
Feb 7 19:32:11 bass kernel: SG Segment 8: 4096
Feb 7 19:32:11 bass kernel: SG Segment 9: 4096
Feb 7 19:32:11 bass kernel: SG Segment 10: 4096
Feb 7 19:32:11 bass kernel: SG Segment 11: 4096
Feb 7 19:32:11 bass kernel: SG Segment 12: 4096
Feb 7 19:32:11 bass kernel: SG Segment 13: 4096
Feb 7 19:32:11 bass kernel: SG Segment 14: 4096
Feb 7 19:32:11 bass kernel: SG Segment 15: 4096
Feb 7 19:32:11 bass kernel:
Feb 7 19:32:12 bass kernel:
Feb 7 19:32:12 bass kernel: SCSI disk error : host 0 channel 0 id 0 lun 0
return code = 1
Feb 7 19:32:12 bass kernel: I/O error: dev 08:08, sector 665864
Feb 7 19:32:12 bass kernel:
Feb 7 19:32:12 bass kernel:
Feb 7 19:32:12 bass kernel: AacHba_`DoScsiWrite: WRITE request is larger
than 64K
Feb 7 19:32:12 bass kernel: AacHba_DoScsiWrite: ByteCount: 69632
Feb 7 19:32:12 bass kernel: AacHba_DoScsiWrite: SG ELEMENTS: 16
Feb 7 19:32:12 bass kernel: Dump SG Element Size...
Feb 7 19:32:12 bass kernel: SG Segment 0: 4096
Feb 7 19:32:12 bass kernel: SG Segment 1: 4096
Feb 7 19:32:12 bass kernel: SG Segment 2: 4096
Feb 7 19:32:12 bass kernel: SG Segment 3: 4096
Feb 7 19:32:12 bass kernel: SG Segment 4: 4096
Feb 7 19:32:12 bass kernel: SG Segment 5: 4096
Feb 7 19:32:12 bass kernel: SG Segment 6: 4096
Feb 7 19:32:12 bass kernel: SG Segment 7: 4096
Feb 7 19:32:12 bass kernel: SG Segment 8: 8192
Feb 7 19:32:12 bass kernel: SG Segment 9: 4096
Feb 7 19:32:12 bass kernel: SG Segment 10: 4096
Feb 7 19:32:12 bass kernel: SG Segment 11: 4096
Feb 7 19:32:12 bass kernel: SG Segment 12: 4096
Feb 7 19:32:12 bass kernel: SG Segment 13: 4096
Feb 7 19:32:12 bass kernel: SG Segment 14: 4096
Feb 7 19:32:12 bass kernel: SG Segment 15: 4096
Feb 7 19:32:12 bass kernel:
Feb 7 19:32:12 bass kernel:
so on and so on.. Am I doing something wrong?
Thanks for your reply post..
Jason
-----Original Message-----
From: Byron Stanoszek [mailto:[email protected]]
Sent: Wednesday, February 07, 2001 5:48 PM
To: Jason Ford
Cc: [email protected]
Subject: Re: aacraid 2.4.0 kernel
On Wed, 7 Feb 2001, Jason Ford wrote:
> I see in the archives of this mailing list that someone was working on the
> aacraid driver for the 2.4 kernel however that post was almost 2 months
old.
> I know Alan Cox denied inclusion of the driver due to the poor nature it
was
> written for the 2.2 tree. Every post that I have seen so far has just said
> that Adaptec is working on it. However, I am sure there are many people
out
> there like myself that have to support this card in enviroments that would
> be benifical to upgrade to 2.4 kernel. I am not a part of this list
however
> have been scouring through geocrawler.com archives of this list everyday
for
> the last month hoping and waiting.
While it's totally unofficial, I have a patch for aacraid 1.0.6 for
2.4.1-ac5.
I have not tested it yet, but it compiles cleanly. I'd like to hear any
results
(good or bad) you have on it.
You can find it at:
ftp://ftp.winds.org/linux/patches/2.4.1/aacraid-2.4.1-1.0.6.patch
Regards,
Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
On Wed, 7 Feb 2001, Jason Ford wrote:
> Byron,
>
> I got your patch to compile in fine however it still exhibits the same
> behavior that the older patches did. It looks like the commands sent to the
> controller are still not working correctly as the new subsystem in the
> kernel was rewritten.
>
> This is the error I get in my messages file when trying to copy from one
> disk partition to another one.
>
> so on and so on.. Am I doing something wrong?
Nope. It looks horribly broken. Oh well.. I guess I'd stick to 2.2.19-pre on
the Dell machines for the time being.
-Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
> I see in the archives of this mailing list that someone was
> working on the
> aacraid driver for the 2.4 kernel however that post was
> almost 2 months old.
Adaptec is still working on it. Basically (and as Jason discovered), the
driver and firmware can't handle single I/O requests larger than 64KB. Even
when scatter/gathered, if the total is >64KB, it chokes. This was just fine
for 2.2.x (no one has ever run into this problem there), but the
much-improved block layer of 2.4.x throws larger I/Os at the driver. So,
the developers at Adaptec are busy trying to add support to break large
requests into smaller chunks, and then gather them back together.
> I know Alan Cox denied inclusion of the driver due to the
> poor nature it was
> written for the 2.2 tree. Every post that I have seen so far
> has just said
> that Adaptec is working on it.
So, there are three objectives:
1) Get and maintain a working 2.2.x driver. Yes, Alan Cox doesn't want to
merge this into the stock kernel, so until then, it's available separately,
and several distributions have picked it up, such as Red Hat Linux 7.
2) Get a working 2.4.x driver. Dell and Adaptec both believe this is
critical. Again, we don't expect this driver to make it into the 2.4.x
stock kernel, it'll be made available separately to those who want it. This
is where development time is being spent today. The best I can say here is
"we hope to have something soon".
3) Develop an aacraid driver for both 2.2.x and 2.4.x that will be accepted
into the stock kernels. For this to happen, Adaptec engineers will be
re-writing the driver from the ground up as a Linux driver. Due to schedule
constraints (wanting 2.4.x support sooner rather than later), and because we
didn't expect the 64K issue, this has been delayed until 2) is finished.
Hopefully the 64K limit will be eradicated then too.
I've made a web page http://domsch.com/linux on which I've posted all the
2.2.x aacraid patches, and where I'll post a 2.4.x patch when it's
available. I've also created an announcements-only mailing list
http://domsch.com/mailman/listinfo/linux-aacraid-announce which you may
subscribe to and receive notices of new driver availability. I've created a
developers list http://domsch.com/mailman/listinfo/linux-aacraid-devel for
discussion of the driver if you wish to contribute.
Both the web page and mailing lists will likely be moved to a Dell.com
server in the near future.
I hope this helps clarify the situation. Thank you for your interest and
continued patience.
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
http://www.dell.com/linux
On Wed, Feb 07 2001, [email protected] wrote:
> Adaptec is still working on it. Basically (and as Jason discovered), the
> driver and firmware can't handle single I/O requests larger than 64KB. Even
> when scatter/gathered, if the total is >64KB, it chokes. This was just fine
> for 2.2.x (no one has ever run into this problem there), but the
> much-improved block layer of 2.4.x throws larger I/Os at the driver. So,
> the developers at Adaptec are busy trying to add support to break large
> requests into smaller chunks, and then gather them back together.
Poor hardware, even IDE does better than this with scatter gather.
However, that's not why I'm replying. A driver should never have
to deal with bigger requests than it can handle. This just leads
to duplicated code in the block drivers and someone getting it
wrong (in fact, 2.4.1-pre showed bugs in the cpqarray driver
doing this for sg). The block layer is flexible enough to stop
merging beyond the low level drivers limit.
I haven't seen this driver, but if it uses the SCSI layer instead
of being a "pure" block driver then I can see a slight problem
in that currently only understand max sg entry limits and not
total request sizes. I would rather fix this limitation then, and
would also be interested to know if any of the (older) SCSI drivers
have such limitations too.
--
Jens Axboe
> I haven't seen this driver, but if it uses the SCSI layer instead
> of being a "pure" block driver then I can see a slight problem
> in that currently only understand max sg entry limits and not
> total request sizes. I would rather fix this limitation then, and
> would also be interested to know if any of the (older) SCSI drivers
> have such limitations too.
Yes, it's a SCSI driver, not a block driver. Adaptec thought it prudent to
try to fix this in their driver rather than try to change the SCSI layer in
2.4.x just now. They expected it would be more difficult getting such a
change through validation and into the kernel in a timely manner.
-Matt
On Wed, Feb 07 2001, [email protected] wrote:
> > I haven't seen this driver, but if it uses the SCSI layer instead
> > of being a "pure" block driver then I can see a slight problem
> > in that currently only understand max sg entry limits and not
> > total request sizes. I would rather fix this limitation then, and
> > would also be interested to know if any of the (older) SCSI drivers
> > have such limitations too.
>
> Yes, it's a SCSI driver, not a block driver. Adaptec thought it prudent to
> try to fix this in their driver rather than try to change the SCSI layer in
> 2.4.x just now. They expected it would be more difficult getting such a
> change through validation and into the kernel in a timely manner.
The changes are going to be really small and obvious. Which I bet
the driver changes won't :-). And as I said, if other drivers have
this limitation too then we need to do it anyway.
--
Jens Axboe
> much-improved block layer of 2.4.x throws larger I/Os at the driver. So,
> the developers at Adaptec are busy trying to add support to break large
> requests into smaller chunks, and then gather them back together.
That sounds like it should be doable at the queuing layer. If not the scsi
queue code or ll_rw_blk wants a bit of tweaking - Jens ?
> total request sizes. I would rather fix this limitation then, and
> would also be interested to know if any of the (older) SCSI drivers
> have such limitations too.
And some new ones. One of my i2o scsi controllers has that problem.
On Thu, Feb 08 2001, Alan Cox wrote:
> > total request sizes. I would rather fix this limitation then, and
> > would also be interested to know if any of the (older) SCSI drivers
> > have such limitations too.
>
> And some new ones. One of my i2o scsi controllers has that problem.
Ok thanks, I'll do the patch then.
--
Jens Axboe