headers
Steven Dake | 1 Sep 2005 02:25

Re: adp94xx driver for 2.6.13?

On Wed, 2005-08-31 at 16:08 -0400, James Bottomley wrote:
> On Tue, 2005-08-30 at 22:33 -0700, Ravikiran G Thirumalai wrote:
> > Are drivers/sources available for Adaptec's AIC-94XX SAS controllers
> > someplace?  I am trying to run 2.6.13 on a x460.  Any pointers to the latest
> > driver sources appreciated.
> 
> There is no driver source for Adaptec SATA hardware.  You need to get
> the latest binary drivers from Adaptec support.
> 
> James
> 
> 

James & Ravikiran,
Adaptec does have source code available under the GPL for the AIC 94xx.
In fact it was submitted to this list and rejected.

It appears to work reasonably well under our stress testing environments
here at mvista.  It does have some problems on x86_64 with 8gb of ram
but works well with 6gb on x86_64.  It also has a significant amount of
nits which make it unacceptable for kernel.org merging.

Regards
-steve
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bagalkote, Sreenivas | 1 Sep 2005 02:34

FW: [Fwd: Re: [PATCH scsi-misc 2/2] megaraid_sas: LSI Logic MegaR AID SAS RA ID D river]

> Looks pretty good to me.  Small issues I've identified:
> 
>  - what do you need the hba_count attribute for?  This should be
>    implementable in userspace pretty easily by iterating of all
>    devices of the scsi_host class that are attached to the driver

I have removed hba_count

>  - the ->queuecommand cleanup patch I sent you a awhile ago doesn't
>    seem to be applied

I seem to have missed it. I will submit the patch after inclusion

>  - there's quite a lot of slightly odd formating, it would be nice
>    if you could run the code through scripts/Lindent.

I ran Lindent. It looks worse :( I am submitting the Lindent output anyway.

> 
> If you could sent out an unmangled patch (even as attachment or on 
> LSI's ftp side) I'd like to take another, closer look.

I am sending this from a Linux box. Hopefully, this will comeout clean.
Sorry for mangled patches.

Signed-off-by: Sreenivas Bagalkote <Sreenivas.Bagalkote <at> lsil.com>

diff -Naur scsi_misc-a/drivers/scsi/Makefile
scsi_misc-b/drivers/scsi/Makefile
--- scsi_misc-a/drivers/scsi/Makefile	2005-08-25 16:25:07.000000000 -0400
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ravikiran G Thirumalai | 1 Sep 2005 02:38

Re: adp94xx driver for 2.6.13?

On Wed, Aug 31, 2005 at 04:08:32PM -0400, James Bottomley wrote:
> On Tue, 2005-08-30 at 22:33 -0700, Ravikiran G Thirumalai wrote:
> > Are drivers/sources available for Adaptec's AIC-94XX SAS controllers
> > someplace?  I am trying to run 2.6.13 on a x460.  Any pointers to the latest
> > driver sources appreciated.
> 
> There is no driver source for Adaptec SATA hardware.  You need to get
> the latest binary drivers from Adaptec support.

Someone from adaptec had posted the sources to linux-scsi some time back, but
unfortunately, it is a humongous 27 patch patchset, with some malformed
patches. Also one of the patches is missing (#6 ,or the patch numbering 
was bad). So I was wondering if folks from adaptec or other people stuck with
this adapter could point me to the sources, if it is available...

Thanks,
Kiran
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Bagalkote, Sreenivas | 1 Sep 2005 03:00

FW: [Fwd: Re: [PATCH scsi-misc 2/2] megaraid_sas: LSI Logic MegaR AID SAS RA ID D river]

> Looks pretty good to me.  Small issues I've identified:
> 
>  - what do you need the hba_count attribute for?  This should be
>    implementable in userspace pretty easily by iterating of all
>    devices of the scsi_host class that are attached to the driver
>  - the ->queuecommand cleanup patch I sent you a awhile ago doesn't
>    seem to be applied
>  - there's quite a lot of slightly odd formating, it would be nice
>    if you could run the code through scripts/Lindent.
> 
> If you could sent out an unmangled patch (even as attachment or on
> LSI's ftp side) I'd like to take another, closer look.

Contd. from prev mail

Patch 2 of 2
Signed-off-by: Sreenivas Bagalkote <Sreenivas.Bagalkote <at> lsil.com>
-----------------------

diff -Naur scsi_misc-b/drivers/scsi/megaraid/megaraid_sas.c
scsi_misc-c/drivers/scsi/megaraid/megaraid_sas.c
--- scsi_misc-b/drivers/scsi/megaraid/megaraid_sas.c	1969-12-31
19:00:00.000000000 -0500
+++ scsi_misc-c/drivers/scsi/megaraid/megaraid_sas.c	2005-08-31
19:39:55.001126424 -0400
 <at>  <at>  -0,0 +1,2800  <at>  <at> 
+/*
+ *
+ *		Linux MegaRAID driver for SAS based RAID controllers
+ *
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Sep 2005 03:17
Picon

Re: [RFC] libata new EH document

Luben Tuikov wrote:
> On 08/30/05 06:26, Tejun Heo wrote:
> 
>>Albert Lee wrote:
>>
>>
>>>>4. Corresponding scmd's result code is set to
>>>>  SAM_STAT_CHECK_CONDITION and qc->scsidone() callback is called
>>>>  directly.  As we haven't filled sense data,
>>>>  scsi_determine_disposition() will return FAILED and SCSI EH will
>>>>  be scheduled.  Note that as we directly call qc->scsidone(), qc is
>>>>  left intact.
>>>>
>>>>
>>>
>>>Could we get the sense data before calling qc->scsidone()?  (Using the 
>>>proposed separate
>>>EH qc can keep the original qc intact.)
>>>
>>>The issue:
>>>When a DVD drive returns MEDIUM_ERROR in the sense data, libata doesn't 
>>>retry the command.
>>>
>>>For libata, when scsi_softirq() calls scsi_decide_disposition() and 
>>>scsi_check_sense() to determine
>>>how to handle the result, scsi_check_sense() always returns "fail" since 
>>>the sense data is not there
>>>yet. The sense data is requested later in the libata error handler. But 
>>>the command has already been
>>>considered as an "error".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Sep 2005 04:22
Picon
Favicon

Re: [RFC] libata new EH document

Tejun Heo wrote:
>  IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> mapping as long as possible.  And, in the suggested framework, it's 
> guaranteed that no other command can come inbetween CHECK_SENSE and 
> REQUEST_SENSE.
> 
>  Requesting sense from EH, calling scsi_decide_disposition() on the 
> sense and following the verdict should achieve the same effect as 
> emulating autosense.  Is there any compelling reason to break one qc to 
> one command mapping?

Yes, you should have one qc <-> one ATA/ATAPI command.  That's why, in 
the NCQ scenario, I wanted to make sure that one qc was always reserved 
for error handling:  REQUEST SENSE or READ LOG EXT, most importantly.

For SAT layer MODE SELECT translations, that implies multiple calls to 
qc_new/qc_issue/qc_complete before completing the overall SCSI command. 
  The same for handling sata_sil mod15write:  I am beginning to feel 
like the mod15write workaround might be best implemented in a manner 
that caused libata-scsi (not sata_sil) to create/issue/complete multiple 
ATA commands.

The only problem you run into is that a qc may be active during EH, when 
you need another qc.  So avoiding recursive details becomes an issue.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Sep 2005 04:22
Picon
Favicon

Re: [RFC] libata new EH document

BTW I still have three of your documents to review and comment on. 
Haven't forgotten about them.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Sep 2005 04:42
Picon

Re: [RFC] libata new EH document

 Hello, Jeff.

On Wed, Aug 31, 2005 at 10:22:17PM -0400, Jeff Garzik wrote:
> Tejun Heo wrote:
> > IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> >mapping as long as possible.  And, in the suggested framework, it's 
> >guaranteed that no other command can come inbetween CHECK_SENSE and 
> >REQUEST_SENSE.
> >
> > Requesting sense from EH, calling scsi_decide_disposition() on the 
> >sense and following the verdict should achieve the same effect as 
> >emulating autosense.  Is there any compelling reason to break one qc to 
> >one command mapping?
> 
> 
> Yes, you should have one qc <-> one ATA/ATAPI command.  That's why, in 
> the NCQ scenario, I wanted to make sure that one qc was always reserved 
> for error handling:  REQUEST SENSE or READ LOG EXT, most importantly.

 Having an extra (as opposed to reserved) EH qc doesn't break one qc
<-> one command mapping.

 a. All EH commands are non-NCQ.
 b. Inside EH, no other command is allowed.

 So, we can allocate a qc which does not have a corresponding NCQ tag.
This qc will never be used for normal commands.  It's used only for
internal commands when no other qc can be active.

 If we don't have an extra qc for EH, as non-NCQ devices have only one
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rudolph Pereira | 1 Sep 2005 04:58
Picon
Picon
Favicon

Re: fc remote port timeout with qla2xxx driver

On Wed, Aug 31, 2005 at 03:44:09PM -0700, Andrew Vasquez wrote:
> Hmm, could you try the attached small patch?  This should close that
> whole where the fc_remote_port state is restored to a correct state.
This seems to fix the problem. The debug now shows:
...

Sep  1 10:05:15 baku kernel: scsi(0): LOOP READY
Sep  1 10:05:15 baku kernel: scsi(0): qla2x00_loop_resync - end
Sep  1 10:05:36 baku kernel: scsi(0): Port Update -- creating RSCN fcport f7c2a080 for 81/7/6000.
Sep  1 10:05:36 baku kernel: scsi(0): Handle RSCN -- process RSCN for fcport [ffffff].
Sep  1 10:05:36 baku kernel: scsi(0): Handle RSCN -- attempting login to [81/ffffff].
Sep  1 10:05:36 baku kernel: scsi(0): Sending Login IOCB (a0004000) to [81/ffffff].
Sep  1 10:05:36 baku kernel: scsi(0): Port login retry: 210000d02367d125, id = 0x0081 retry cnt=10
Sep  1 10:05:36 baku kernel: scsi(0): Process IODesc -- processing a0004000.
Sep  1 10:05:36 baku kernel: scsi(0): Login IOCB -- loop id [81] used by port id [0b1132].
Sep  1 10:05:36 baku kernel: scsi(0): Login IOCB -- retrying login to [81/0b1132] (2).
Sep  1 10:05:36 baku kernel: scsi(0): Sending Login IOCB (a0005000) to [81/0b1132].
Sep  1 10:05:36 baku kernel: scsi(0): Process IODesc -- processing a0005000.
Sep  1 10:05:36 baku kernel: scsi(0): Login IOCB -- status=0 mb1=0 pn=210000d02367d125.
Sep  1 10:05:36 baku kernel: scsi(0): fcport-0 - port retry count: 29 remaining
Sep  1 10:05:36 baku kernel: scsi(0): qla2x00_port_login()
Sep  1 10:05:36 baku kernel: scsi(0): Trying Fabric Login w/loop id 0x0081 for port 0b1132.
Sep  1 10:05:36 baku kernel: scsi(0): Login IOCB -- found RSCN fcport in fcports list [f7db8100].
Sep  1 10:05:36 baku kernel: scsi(0): Login IOCB -- marking existing fcport [81/0b1132] online.
Sep  1 10:05:36 baku kernel: scsi(0): Login IOCB -- Freeing RSCN fcport f7c2a080 [81/0b1132].
Sep  1 10:05:36 baku kernel: scsi(0): port login OK: logged in ID 0x81
Sep  1 10:05:36 baku kernel: scsi(0): qla2x00_port_login - end

one thing that I forgot to mention is that I'm prodding the scsi layer to get
rescan for devices by doing:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luben Tuikov | 1 Sep 2005 05:30
Picon
Favicon

Re: [RFC] libata new EH document

--- Tejun Heo <htejun <at> gmail.com> wrote:
>   IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> mapping as long as possible.  And, in the suggested framework, it's 

Yes, that makes sense.

> guaranteed that no other command can come inbetween CHECK_SENSE and 
> REQUEST_SENSE.

That's good.

>   Requesting sense from EH,

Done in an ATA eh handler.

> calling scsi_decide_disposition() on the 
> sense 

Done in SCSI Core.

> and following the verdict should achieve the same effect as
> emulating autosense.

Yes, precisely.

> Is there any compelling reason to break one qc to 
> one command mapping?

?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane