public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* errors from mptsas
@ 2008-04-08 22:20 Rick Warner
  2008-04-09 10:53 ` Wakko Warner
  0 siblings, 1 reply; 6+ messages in thread
From: Rick Warner @ 2008-04-08 22:20 UTC (permalink / raw)
  To: linux-scsi

Hello,

I am working on 2 dual opteron systems using LSI 3041E SAS cards (1064E(b3)).  
They each have (1) 73G Seagate SAS drive and (2) 750G Seagate SATA drives 
hooked up to them.

One of the stress tests we run on systems is looping through the hard drives 
running "dd if=/dev/sdX of=/dev/null". With that running, we get a steady 
stream of these errors in the dmesg-

mptbase: ioc0: LogInfo(0x31123000): Originator={PL}, Code={Abort}, 
SubCode(0x3000)

Any idea what's going on here? I have already updated to the latest firmware 
for the card.  The system is loaded with FC8 running 2.6.24.4-64.fc8.

Right now, I have 
Thanks,
Rick

-- 
Richard Warner
Lead Systems Integrator
Microway, Inc
(508)732-5517

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: errors from mptsas
  2008-04-08 22:20 errors from mptsas Rick Warner
@ 2008-04-09 10:53 ` Wakko Warner
  2008-04-09 15:11   ` Moore, Eric
  2008-04-09 15:16   ` Rick Warner
  0 siblings, 2 replies; 6+ messages in thread
From: Wakko Warner @ 2008-04-09 10:53 UTC (permalink / raw)
  To: Rick Warner; +Cc: linux-scsi

Rick Warner wrote:
> I am working on 2 dual opteron systems using LSI 3041E SAS cards (1064E(b3)).  
> They each have (1) 73G Seagate SAS drive and (2) 750G Seagate SATA drives 
> hooked up to them.
> 
> One of the stress tests we run on systems is looping through the hard drives 
> running "dd if=/dev/sdX of=/dev/null". With that running, we get a steady 
> stream of these errors in the dmesg-
> 
> mptbase: ioc0: LogInfo(0x31123000): Originator={PL}, Code={Abort}, 
> SubCode(0x3000)
> 
> Any idea what's going on here? I have already updated to the latest firmware 
> for the card.  The system is loaded with FC8 running 2.6.24.4-64.fc8.

Join the club.  I have an LSI SAS with 3x 750gb seagate sata drives in
raid5.  Does this happen only on your SATA drives or all the drives?
Depending on the activity, it would drop one of them out of the
array.  I think the problem has been solved for now by changing the
queue_depth to 1.

echo 1 > /sys/block/sdX/device/queue_depth

Here's the drives in my system:
[0:0:0:0]    disk    ATA      ST3750640AS      E     /dev/sda
[0:0:1:0]    disk    ATA      ST3750640AS      E     /dev/sdb
[0:0:2:0]    disk    ATA      ST3750640AS      E     /dev/sdc

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: errors from mptsas
  2008-04-09 10:53 ` Wakko Warner
@ 2008-04-09 15:11   ` Moore, Eric
  2008-04-09 16:32     ` Wakko Warner
  2008-04-09 15:16   ` Rick Warner
  1 sibling, 1 reply; 6+ messages in thread
From: Moore, Eric @ 2008-04-09 15:11 UTC (permalink / raw)
  To: Wakko Warner, Rick Warner; +Cc: linux-scsi

On Wednesday, April 09, 2008 4:54 AM,  Rick Warner wrote:
> 
> Join the club.  I have an LSI SAS with 3x 750gb seagate sata drives in
> raid5.  Does this happen only on your SATA drives or all the drives?
> Depending on the activity, it would drop one of them out of the
> array.  I think the problem has been solved for now by changing the
> queue_depth to 1.
> 
> echo 1 > /sys/block/sdX/device/queue_depth
> 
> Here's the drives in my system:
> [0:0:0:0]    disk    ATA      ST3750640AS      E     /dev/sda
> [0:0:1:0]    disk    ATA      ST3750640AS      E     /dev/sdb
> [0:0:2:0]    disk    ATA      ST3750640AS      E     /dev/sdc
> 


Rick - I thought you said the magic number was 32 for SATA devices?  And
we confirmed that in the logs you sent yesterday.   Is that correct, or
did I miss something.

Eric

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: errors from mptsas
  2008-04-09 10:53 ` Wakko Warner
  2008-04-09 15:11   ` Moore, Eric
@ 2008-04-09 15:16   ` Rick Warner
  2008-04-09 16:30     ` Wakko Warner
  1 sibling, 1 reply; 6+ messages in thread
From: Rick Warner @ 2008-04-09 15:16 UTC (permalink / raw)
  To: Wakko Warner; +Cc: linux-scsi

> > I am working on 2 dual opteron systems using LSI 3041E SAS cards
> > (1064E(b3)). They each have (1) 73G Seagate SAS drive and (2) 750G
> > Seagate SATA drives hooked up to them.
> >
> > One of the stress tests we run on systems is looping through the hard
> > drives running "dd if=/dev/sdX of=/dev/null". With that running, we get a
> > steady stream of these errors in the dmesg-
> >
> > mptbase: ioc0: LogInfo(0x31123000): Originator={PL}, Code={Abort},
> > SubCode(0x3000)
> >
> > Any idea what's going on here? I have already updated to the latest
> > firmware for the card.  The system is loaded with FC8 running
> > 2.6.24.4-64.fc8.
>
> Join the club.  I have an LSI SAS with 3x 750gb seagate sata drives in
> raid5.  Does this happen only on your SATA drives or all the drives?
> Depending on the activity, it would drop one of them out of the
> array.  I think the problem has been solved for now by changing the
> queue_depth to 1.
>
> echo 1 > /sys/block/sdX/device/queue_depth
>
> Here's the drives in my system:
> [0:0:0:0]    disk    ATA      ST3750640AS      E     /dev/sda
> [0:0:1:0]    disk    ATA      ST3750640AS      E     /dev/sdb
> [0:0:2:0]    disk    ATA      ST3750640AS      E     /dev/sdc
I ran last night with 1 of the systems doing the repetitive dd on just the SAS 
drive, and that system produced no errors.

This morning, I followed your suggestion and set the queue_depth to 1 for both 
of the SATA drives.  With that setting applied, my rate of errors decreased 
significantly, but they did not go away completely.

The system I am using has 6 onboard SATA ports too, so I have moved the SATA 
drives to those ports instead. Everything is working fine now.  However, lsi 
really needs to fix this problem, as they have always told us that SATA 
drives work on their SAS controllers without issues.

Thanks,
Rick

-- 
Richard Warner
Lead Systems Integrator
Microway, Inc
(508)732-5517

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: errors from mptsas
  2008-04-09 15:16   ` Rick Warner
@ 2008-04-09 16:30     ` Wakko Warner
  0 siblings, 0 replies; 6+ messages in thread
From: Wakko Warner @ 2008-04-09 16:30 UTC (permalink / raw)
  To: Rick Warner; +Cc: linux-scsi

Rick Warner wrote:
> > echo 1 > /sys/block/sdX/device/queue_depth
> >
> > Here's the drives in my system:
> > [0:0:0:0]    disk    ATA      ST3750640AS      E     /dev/sda
> > [0:0:1:0]    disk    ATA      ST3750640AS      E     /dev/sdb
> > [0:0:2:0]    disk    ATA      ST3750640AS      E     /dev/sdc

> This morning, I followed your suggestion and set the queue_depth to 1 for both 
> of the SATA drives.  With that setting applied, my rate of errors decreased 
> significantly, but they did not go away completely.

Hmm, I believe your problem is different than mine.

This is what I have:
04:02.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)

So far, my problem has gone away.  I'm not doing dd tests though.  The
problems I've had seem to be reading from the device, but that may just be a
coincidence

> The system I am using has 6 onboard SATA ports too, so I have moved the SATA 
> drives to those ports instead. Everything is working fine now.  However, lsi 
> really needs to fix this problem, as they have always told us that SATA 
> drives work on their SAS controllers without issues.

I bought this card because I needed 4 sata ports (I have 8 sas ports).  My
motherboard doesn't have onboard sata.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: errors from mptsas
  2008-04-09 15:11   ` Moore, Eric
@ 2008-04-09 16:32     ` Wakko Warner
  0 siblings, 0 replies; 6+ messages in thread
From: Wakko Warner @ 2008-04-09 16:32 UTC (permalink / raw)
  To: Moore, Eric; +Cc: Rick Warner, linux-scsi

Moore, Eric wrote:
> On Wednesday, April 09, 2008 4:54 AM,  Rick Warner wrote:
> > 
> > Join the club.  I have an LSI SAS with 3x 750gb seagate sata drives in
> > raid5.  Does this happen only on your SATA drives or all the drives?
> > Depending on the activity, it would drop one of them out of the
> > array.  I think the problem has been solved for now by changing the
> > queue_depth to 1.
> > 
> > echo 1 > /sys/block/sdX/device/queue_depth
> > 
> > Here's the drives in my system:
> > [0:0:0:0]    disk    ATA      ST3750640AS      E     /dev/sda
> > [0:0:1:0]    disk    ATA      ST3750640AS      E     /dev/sdb
> > [0:0:2:0]    disk    ATA      ST3750640AS      E     /dev/sdc
> > 
> 
> 
> Rick - I thought you said the magic number was 32 for SATA devices?  And
> we confirmed that in the logs you sent yesterday.   Is that correct, or
> did I miss something.

That was ment for me.
>From what I read, the number is 31 for sata drives (I'm not sure about sas
and not sure if it relates to sata drives on a sas controller).
However, I set mine to 1 specifically and have not had a problem.  I'd
rather not try 31 and a drive drop out again.  It takes 4 hours to rebuild
the array and I've had to do it with the system offline.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-04-09 16:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-08 22:20 errors from mptsas Rick Warner
2008-04-09 10:53 ` Wakko Warner
2008-04-09 15:11   ` Moore, Eric
2008-04-09 16:32     ` Wakko Warner
2008-04-09 15:16   ` Rick Warner
2008-04-09 16:30     ` Wakko Warner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox