[PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device driver for new sequence firmware.

[PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device driver for new sequence firmware.

[Wu, Gilbert]

Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
driver for new sequence firmware.

 

Contribution:

   Ed Chim <ed_chim@adaptec.com>
   Gilbert Wu <gilbert_wu@adaptec.com>

Change Log:
 
1.    Use dword instead of qword to display the value of Connection
State register for debug purpose.

2.    There are some registers location of AIC94xx chip has been changed
according to the new V28 firmware. The patch has redefined the register
location and provided initialization.

3.    The new sequencer firmware v28 for Aic94xx SAS/SATA Linux open
source device driver can be downloaded from
http://www.adaptec.com/NR/exeres/35B611BC-9789-4B5B-82C6-85A2CCA8A46A.ht
m

 

Patch: apply to scsi-misc-2.6.git development tree

Signed-off-by: Gilbert Wu <gilbert_wu@adaptec.com>



diff -urN a/drivers/scsi/aic94xx/aic94xx_dump.c
b/drivers/scsi/aic94xx/aic94xx_dump.c
--- a/drivers/scsi/aic94xx/aic94xx_dump.c	2007-01-29
10:20:44.000000000 -0800
+++ b/drivers/scsi/aic94xx/aic94xx_dump.c	2007-01-29
10:31:44.000000000 -0800
@@ -556,7 +556,7 @@
 	PRINT_LMIP_word(asd_ha, lseq, Q_TGTXFR_TAIL);
 	PRINT_LMIP_byte(asd_ha, lseq, LINK_NUMBER);
 	PRINT_LMIP_byte(asd_ha, lseq, SCRATCH_FLAGS);
-	PRINT_LMIP_qword(asd_ha, lseq, CONNECTION_STATE);
+	PRINT_LMIP_dword(asd_ha, lseq, CONNECTION_STATE);
 	PRINT_LMIP_word(asd_ha, lseq, CONCTL);
 	PRINT_LMIP_byte(asd_ha, lseq, CONSTAT);
 	PRINT_LMIP_byte(asd_ha, lseq, CONNECTION_MODES);
diff -urN a/drivers/scsi/aic94xx/aic94xx_reg_def.h
b/drivers/scsi/aic94xx/aic94xx_reg_def.h
--- a/drivers/scsi/aic94xx/aic94xx_reg_def.h	2007-01-29
10:21:14.000000000 -0800
+++ b/drivers/scsi/aic94xx/aic94xx_reg_def.h	2007-01-29
10:35:54.000000000 -0800
@@ -2226,9 +2226,10 @@
 #define LmSEQ_SAS_RESET_MODE(LinkNum)		(LmSCRATCH(LinkNum) +
0x0074)
 #define LmSEQ_LINK_RESET_RETRY_COUNT(LinkNum)	(LmSCRATCH(LinkNum) +
0x0075)
 #define LmSEQ_NUM_LINK_RESET_RETRIES(LinkNum)	(LmSCRATCH(LinkNum) +
0x0076)
-#define LmSEQ_OOB_INT_ENABLES(LinkNum)		(LmSCRATCH(LinkNum) +
0x007A)
+#define LmSEQ_OOB_INT_ENABLES(LinkNum)		(LmSCRATCH(LinkNum) +
0x0078)
+#define LmSEQ_NOTIFY_TIMER_DOWN_COUNT(LinkNum)	(LmSCRATCH(LinkNum) +
0x007A)
 #define LmSEQ_NOTIFY_TIMER_TIMEOUT(LinkNum)	(LmSCRATCH(LinkNum) +
0x007C)
-#define LmSEQ_NOTIFY_TIMER_DOWN_COUNT(LinkNum)	(LmSCRATCH(LinkNum) +
0x007E)
+#define LmSEQ_NOTIFY_TIMER_INITIAL_COUNT(LinkNum) (LmSCRATCH(LinkNum) +
0x007E)
 
 /* Mode dependent scratch page 1, mode 0 and mode 1 */
 #define LmSEQ_SG_LIST_PTR_ADDR0(LinkNum)        (LmSCRATCH(LinkNum) +
0x0020)
diff -urN a/drivers/scsi/aic94xx/aic94xx_seq.c
b/drivers/scsi/aic94xx/aic94xx_seq.c
--- a/drivers/scsi/aic94xx/aic94xx_seq.c	2007-01-29
10:21:28.000000000 -0800
+++ b/drivers/scsi/aic94xx/aic94xx_seq.c	2007-01-29
10:42:55.000000000 -0800
@@ -810,6 +810,8 @@
 	/* No delay for the first NOTIFY to be sent to the attached
target. */
 	asd_write_reg_word(asd_ha, LmSEQ_NOTIFY_TIMER_DOWN_COUNT(lseq),
 			   ASD_NOTIFY_DOWN_COUNT);
+	asd_write_reg_word(asd_ha,
LmSEQ_NOTIFY_TIMER_INITIAL_COUNT(lseq),
+			   ASD_NOTIFY_DOWN_COUNT);
 
 	/* LSEQ Mode dependent, mode 0 and 1, page 1 setup. */
 	for (i = 0; i < 2; i++)	{

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device driver for new sequence firmware.

[Christoph Hellwig]

On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
> Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> driver for new sequence firmware.
> 
>  
> 
> Contribution:
> 
>    Ed Chim <ed_chim@adaptec.com>
>    Gilbert Wu <gilbert_wu@adaptec.com>
> 
> Change Log:
>  
> 1.    Use dword instead of qword to display the value of Connection
> State register for debug purpose.
> 
> 2.    There are some registers location of AIC94xx chip has been changed
> according to the new V28 firmware. The patch has redefined the register
> location and provided initialization.

These look like incompatible changes, so you should make sure the driver
still works when it detects the old firmware.

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device driver for new sequence firmware.

[James Bottomley]

On Wed, 2007-01-31 at 09:56 +0000, Christoph Hellwig wrote:
> On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
> > Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> > driver for new sequence firmware.
> > 
> >  
> > 
> > Contribution:
> > 
> >    Ed Chim <ed_chim@adaptec.com>
> >    Gilbert Wu <gilbert_wu@adaptec.com>
> > 
> > Change Log:
> >  
> > 1.    Use dword instead of qword to display the value of Connection
> > State register for debug purpose.
> > 
> > 2.    There are some registers location of AIC94xx chip has been changed
> > according to the new V28 firmware. The patch has redefined the register
> > location and provided initialization.
> 
> These look like incompatible changes, so you should make sure the driver
> still works when it detects the old firmware.

Yes, there's going to be a bit of a problem if they are:  I expected the
firmware to be backward compatible, so the current driver only prints
out the firmware version, it won't refuse to use it ... what will happen
if we use the new firmware on an old driver?

James

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device driver for new sequence firmware.

[Luben Tuikov]

--- James Bottomley <James.Bottomley@SteelEye.com> wrote:

> On Wed, 2007-01-31 at 09:56 +0000, Christoph Hellwig wrote:
> > On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
> > > Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> > > driver for new sequence firmware.
> > > 
> > >  
> > > 
> > > Contribution:
> > > 
> > >    Ed Chim <ed_chim@adaptec.com>
> > >    Gilbert Wu <gilbert_wu@adaptec.com>
> > > 
> > > Change Log:
> > >  
> > > 1.    Use dword instead of qword to display the value of Connection
> > > State register for debug purpose.
> > > 
> > > 2.    There are some registers location of AIC94xx chip has been changed
> > > according to the new V28 firmware. The patch has redefined the register
> > > location and provided initialization.
> > 
> > These look like incompatible changes, so you should make sure the driver
> > still works when it detects the old firmware.
> 
> Yes, there's going to be a bit of a problem if they are:  I expected the
> firmware to be backward compatible, so the current driver only prints
> out the firmware version, it won't refuse to use it ... what will happen
> if we use the new firmware on an old driver?

What will happen?  No-workie, or if you're lucky, unexpected random
behavior from the sequencer and thus the driver.

Hmm, I think I mentioned this on several an occasion, back when "the community"
decided that the best thing to do is to pull out the FW out of the driver and
into user space, thus decoupling the source code (version) from the FW version.
I just don't have the time to search linux-scsi in marc.10east.com and include
links to the messages here.

That is, if the user upgrades the kernel to include a new(er) driver, but
forgets to upgrade the FW (now living in the filesystem in user space)
then kaboom, no-workie.

For this reason, and to make it easiest for the user to upgrade, the FW should
be part of the driver source code, as was originally designed.  Then when
a user upgrades the kernel, possibly including a new(er) driver, the FW is right
there, in the source code.  Then compile and run, simple.

Now a user, before rebooting, will have to go out on the internet and find
this (elusive?) new FW version to go with their new kernel.  This is especially
true when the driver provides the device on which the root fs is mounted, else
after a reboot -- no workie.

This split only makes it harder for the user: integration and deployment are
"out with the bath water".  And after all, faster integration and deployment
and easy upgrade is what the user wants, and what should probably be striven to.

    Luben
P.S. Needless to say, the driver as I maintain it, still has the FW right
in the source -- patch, compile and run.

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device driver for new sequence firmware.

[James Bottomley]

On Tue, 2007-01-30 at 15:31 -0800, Wu, Gilbert wrote:
> Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> driver for new sequence firmware.

I put the patch, which seems fine, into scsi-misc-2.6; however, it looks
like the firmware isn't fine.  With the V28 firmware I get instability
on my directly attached SATA disk.  It begins about three minutes into a
small exercise of the filesystem on the disk as:

Feb  3 16:13:50 localhost kernel: sas: command 0xf7aca994, task
0x00000000, gone: EH_RESET_TIMER

and then times out commands and eventually flips ext3 into read only
mode because of the errors.

If I run the same tests with the V17/10c6 firmware, everything runs fine
and to completion.

James

RE: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source devicedriver for new sequence firmware.

[Wu, Gilbert]

Hi James,

  We are investigating this issue here. We will update the status when
we can duplicate the problem here and root cause.

Thanks!
Gilbert


-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@SteelEye.com] 
Sent: Saturday, February 03, 2007 2:29 PM
To: Wu, Gilbert
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source
devicedriver for new sequence firmware.

On Tue, 2007-01-30 at 15:31 -0800, Wu, Gilbert wrote:
> Subject:  [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source
device
> driver for new sequence firmware.

I put the patch, which seems fine, into scsi-misc-2.6; however, it looks
like the firmware isn't fine.  With the V28 firmware I get instability
on my directly attached SATA disk.  It begins about three minutes into a
small exercise of the filesystem on the disk as:

Feb  3 16:13:50 localhost kernel: sas: command 0xf7aca994, task
0x00000000, gone: EH_RESET_TIMER

and then times out commands and eventually flips ext3 into read only
mode because of the errors.

If I run the same tests with the V17/10c6 firmware, everything runs fine
and to completion.

James

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source devicedriver for new sequence firmware.

[Darrick J. Wong]

Wu, Gilbert wrote:
> Hi James,
> 
>   We are investigating this issue here. We will update the status when
> we can duplicate the problem here and root cause.

FWIW,

v17 looks good for both SAS/SATA load testing.  The 24-disk x260 seems
to have crapped out after about 800 rounds of load/unload due to the
phys reporting devices, then no devices about 10s later, and then having
the module unloaded before the dead SAS commands finished returning.
Not sure what that's about, though I might also have borked the x260 :(

Though who really is going to reboot the machine 800 times in rapid-fire
succession???

(I'm not trying to slam the v28 sequencer, I'm merely providing a
baseline for comparison between the two.  It may very well be the case
that all the bugs we used to observe with v17 were merely a result of us
poking the sequencer the wrong way....)

--D

RE: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source devicedriver for new sequence firmware.

[Wu, Gilbert]

Hi Darrick,

 We can duplicate the problem here. The aic94xx with V28 passed IO
testing overnight if we apply IO directly to /dev/sd?.  But it fails
very quickly when we create a partition and format it as ext3. The V17
sequencer works fine with both cases. We are looking into it and find
the root cause ASAP.

Thanks!
Gilbert

-----Original Message-----
From: Darrick J. Wong [mailto:djwong@us.ibm.com] 
Sent: Wednesday, February 07, 2007 1:12 AM
To: Wu, Gilbert
Cc: James Bottomley; linux-scsi@vger.kernel.org; Alexis Bruemmer
Subject: Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source
devicedriver for new sequence firmware.

Wu, Gilbert wrote:
> Hi James,
> 
>   We are investigating this issue here. We will update the status when
> we can duplicate the problem here and root cause.

FWIW,

v17 looks good for both SAS/SATA load testing.  The 24-disk x260 seems
to have crapped out after about 800 rounds of load/unload due to the
phys reporting devices, then no devices about 10s later, and then having
the module unloaded before the dead SAS commands finished returning.
Not sure what that's about, though I might also have borked the x260 :(

Though who really is going to reboot the machine 800 times in rapid-fire
succession???

(I'm not trying to slam the v28 sequencer, I'm merely providing a
baseline for comparison between the two.  It may very well be the case
that all the bugs we used to observe with v17 were merely a result of us
poking the sequencer the wrong way....)

--D

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source devicedriver for new sequence firmware.

[Darrick J. Wong]

Wu, Gilbert wrote:
> Hi Darrick,
> 
>  We can duplicate the problem here. The aic94xx with V28 passed IO
> testing overnight if we apply IO directly to /dev/sd?.  But it fails
> very quickly when we create a partition and format it as ext3. The V17
> sequencer works fine with both cases. We are looking into it and find
> the root cause ASAP.

This may be fairly self evident by now, but it looks like the sequencer
for the link (LSEQ, I think?) is somehow locking up, which explains why
the scsi_cmnds start timing out and after that all commands (stp, phy
control, etc) time out as well.  The other drives continue operating
normally, so I don't think the central sequencer isn't borked up.

Then again, you guys at Adaptec have the sequencer source code works and
I don't, so I can't do much more than make vague guesses. Oh well :(

--D

RE: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source devicedriver for new sequence firmware.

[Wu, Gilbert]

Yes, we are still looking into it. From the trace, the sequencer stuck
on DMA transferring data. Most likely the V28 sequencer introduces new
problem. Any way, we are going to find out the root cause.

Thanks!
Gilbert

-----Original Message-----
From: Darrick J. Wong [mailto:djwong@us.ibm.com] 
Sent: Thursday, February 08, 2007 3:32 PM
To: Wu, Gilbert
Cc: James Bottomley; linux-scsi@vger.kernel.org; Alexis Bruemmer
Subject: Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source
devicedriver for new sequence firmware.

Wu, Gilbert wrote:
> Hi Darrick,
> 
>  We can duplicate the problem here. The aic94xx with V28 passed IO
> testing overnight if we apply IO directly to /dev/sd?.  But it fails
> very quickly when we create a partition and format it as ext3. The V17
> sequencer works fine with both cases. We are looking into it and find
> the root cause ASAP.

This may be fairly self evident by now, but it looks like the sequencer
for the link (LSEQ, I think?) is somehow locking up, which explains why
the scsi_cmnds start timing out and after that all commands (stp, phy
control, etc) time out as well.  The other drives continue operating
normally, so I don't think the central sequencer isn't borked up.

Then again, you guys at Adaptec have the sequencer source code works and
I don't, so I can't do much more than make vague guesses. Oh well :(

--D

Re: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source devicedriver for new sequence firmware.

[Mark Rustad]

On Feb 7, 2007, at 3:11 AM, Darrick J. Wong wrote:

> Wu, Gilbert wrote:
>> Hi James,
>>
>>   We are investigating this issue here. We will update the status  
>> when
>> we can duplicate the problem here and root cause.
>
> FWIW,
>
> v17 looks good for both SAS/SATA load testing.  The 24-disk x260 seems
> to have crapped out after about 800 rounds of load/unload due to the
> phys reporting devices, then no devices about 10s later, and then  
> having
> the module unloaded before the dead SAS commands finished returning.
> Not sure what that's about, though I might also have borked the  
> x260 :(
>
> Though who really is going to reboot the machine 800 times in rapid- 
> fire
> succession???
>
> (I'm not trying to slam the v28 sequencer, I'm merely providing a
> baseline for comparison between the two.  It may very well be the case
> that all the bugs we used to observe with v17 were merely a result  
> of us
> poking the sequencer the wrong way....)

My understanding is that the new sequencer has moved some registers  
and so each version of the sequencer would have to be run with a  
driver coded for that particular version of the sequencer. If you are  
trying to use the same driver with both versions of the sequencer,  
bad things will happen unless you have a driver that can recognize  
both versions and handle each appropriately. I don't think that the  
aic94xx driver as it exists can do that.

Please excuse me if you were already aware of this, but if you  
weren't I wanted to try to short-circuit some of your head-banging.

-- 
Mark Rustad, MRustad@gmail.com