mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?)

[Josef Karthauser]

On Sat, Jan 27, 2007 at 10:47:49PM +0000, Josef Karthauser wrote:
> 
> The error messages from mpt are attached in the file called 'messages'.
> The kernel probe boot time log is attached as dmesg.log.
> 

> Jan 27 18:42:03 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x01 Depth 121
> Jan 27 18:44:01 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x00 Depth 121
> Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756328:48785 timed out for ccb 0xca8f0c00 (req->ccb 0xca8f0c00)
> Jan 27 18:51:06 littoralis kernel: mpt0: attempting to abort req 0xca756328:48785 function 0
> Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755c28:48786 timed out for ccb 0xcc213800 (req->ccb 0xcc213800)

An update for anyone who's following this thread.

At Matthew Jacob's suggestion I tweaked the 'camcontrol tags'
settings for the drives, and with a particular choice of settings
the problems goes away.

So, at boot time both drives (da0|1) report that they have 255 tag
openings.  However you can see above in the logs that the mpt files
when the depth gets to 121.  If I manually set the tags for the
drives to anything 120 or above the drive controller complains under
load, and one of the disks goes away.  If I get it to 119 the server
runs all day without missing a beat.

Matt suggested quirking the drives to fix this.  I'm wondering though
where it is that the mpt controller get the queue size of 121 from, and
why the drives report 255 at boot time.  Is this because the control
isn't mediating this information properly, or is there a bug in the
controller firmware or driver?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070130/e97aabd9/attachment.pgp