Re: aacraid 2.4.0 kernel
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
> 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 ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
> 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 www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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 www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
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 ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
