From nobody@FreeBSD.org  Wed Nov  2 19:17:41 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 05E6B1065677
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  2 Nov 2011 19:17:41 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id E93928FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  2 Nov 2011 19:17:40 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pA2JHegS037093
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 2 Nov 2011 19:17:40 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id pA2JHeP7037092;
	Wed, 2 Nov 2011 19:17:40 GMT
	(envelope-from nobody)
Message-Id: <201111021917.pA2JHeP7037092@red.freebsd.org>
Date: Wed, 2 Nov 2011 19:17:40 GMT
From: Alexander Haderer <alexander.haderer@loescap.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0'
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         162256
>Category:       kern
>Synopsis:       [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0'
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-scsi
>State:          feedback
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 02 19:20:07 UTC 2011
>Closed-Date:    
>Last-Modified:  Tue May 07 14:57:06 UTC 2013
>Originator:     Alexander Haderer
>Release:        8.1 R i386
>Organization:
LoeScap Technology GmbH
>Environment:
FreeBSD my.host.here 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
Having SCSI disks connected to an mpt based controller, me and other people experience problems with disappearing disks with messsages "mpt_cam_even: 0x0" like in [1] or QUEUE FULL EVENT like in [2]. Others see failing requests or requests timing out like in PR 117688 [3]. More examples can be found via a search engine.

Often, but not always people are running a software RAID on these drives, gmirror or ZFS based for example. The error messages appear, when there is some load on the disks / raid.

A workaround mentioned on some sites is to reduce the "tags" of the disks connected to mpt using "camcontrol tags -N value"

Probably this behaviour is mpt firmware related and can't be solved by fixing the mpt driver.

My change request:

What about adding a sysctl variable, where one can set the tags value for each mpt conroller connected to the system? Doing so one can automatically set the tags value at boot time.

Mention this sysctl variable in the mpt man page.


[1] http://forums.freebsd.org/showthread.php?t=17802&highlight=mpt0

[2] http://ndok.wordpress.com/2009/07/03/mpt0-queue-full-event-bus-0x00-target-0x08-depth-128/

[3] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117688
>How-To-Repeat:
Run a machine with mpt controller, connect daN disks, setup a gmirror / ZFS raid and generate disk load (writes?).
>Fix:
No real fix, but instead a shell script to be put in /usr/local/etc/rc.d. To enable it add to rc.conf:

mpttags_enable="YES"
mpttags_value="100"

to set the tags value for all daN disks attached to all mpt controllers to 100.

Please find this script attached to this PR.

Patch attached with submission follows:

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	mpttags
#
echo x - mpttags
sed 's/^X//' >mpttags << '5d94cc96def1eaaabbdd9ab978da76db'
X#!/bin/sh
X
X# PROVIDE: mpttags
X# REQUIRE: FILESYSTEMS
X#
X# Set parameter 'tags' to value $mpttags_value for all daN disks connected
X# to an mpt controller using command 'camcontrol tags -N val'
X# 
X# Add the following line(s) to /etc/rc.conf to enable mpttags:
X#
X#  mpttags_enable="YES"
X#
X#  mpttags_value="N"   An integer value for tags, range 2..255, defaults to 100
X#
X# This scripts takes one of the following commands:
X#
X#   start 
X#
X
X. /etc/rc.subr
X
X# set default values
Xname="mpttags"
Xrcvar=`set_rcvar`
Xmpttags_enable=${mpttags_enable:-"NO"}
Xmpttags_value=${mpttags_value:-"100"}
X
Xstart_cmd="mpttags_start"
Xstop_cmd=":"
X
X# set default programs
XCAMCONTROL=${CAMCONTROL:-"/sbin/camcontrol"}
XEGREP=${EGREP:-"/usr/bin/egrep"}
X
Xmpttags_start()
X{
X	for disk in $(${SYSCTL_N} kern.disks); do 
X		case ${disk} in
X
X		da[0-9]|da[0-9][0-9])
X			if ${CAMCONTROL} tags ${disk} | 
X			   ${EGREP} '^\(pass[0-9]{1,2}:mpt[0-9]:' > /dev/null ;
X			then
X				${CAMCONTROL} tags ${disk} -N ${mpttags_value} \
X				> /dev/null
X			fi
X			;;
X		*)
X			;;
X		esac
X	done
X}
X
Xload_rc_config $name
Xrun_rc_command "$1"
5d94cc96def1eaaabbdd9ab978da76db
exit



>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Nov 21 00:08:23 UTC 2011 
Responsible-Changed-Why:  
This PR might get some more visibility on this mailing list. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162256 

From: Marius Strobl <marius@alchemy.franken.de>
To: bug-followup@FreeBSD.org, alexander.haderer@loescap.de
Cc:  
Subject: Re: kern/162256: [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0'
Date: Mon, 21 Nov 2011 21:25:52 +0100

 Could you please test how many of these problems are left when using
 8-stable as of r224820 or later or one of the 9.0 RCs? There was at
 least one bug causing mpt(4) to not actually adjust the number of
 tags in case of MPI_EVENT_QUEUE_FULL for disks not part of a RAID on
 RAID-capable controllers fixed since 8.1, as well a bug that caused
 disks that went away not to be reported, causing upper layers to
 retry requests for ages. Some innocuous events were also silenced
 since 8.1.
 In any case I'm not very found of the mpttags script suggested as-is,
 even if the underlying problem can't be fixed; for one tags should be
 configurable per target as one very well might need different values
 for different models and also generally adding the appropriate
 camcontrol(8) invocations to /etc/rc.local seems trivial enough and
 less complex.
 
 Marius
 
State-Changed-From-To: open->feedback 
State-Changed-By: sbruno 
State-Changed-When: Tue May 7 14:55:41 UTC 2013 
State-Changed-Why:  
These patches are probably going to be rejected.  But, we would request that you retest 
the hardware specified  on stable/9 or newer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=162256 
>Unformatted:
