Bug 162256

Summary: [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0'
Product: Base System Reporter: alexander.haderer
Component: kernAssignee: freebsd-scsi (Nobody) <scsi>
Status: Closed Unable to Reproduce    
Severity: Affects Only Me CC: sbruno
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.shar none

Description alexander.haderer 2011-11-02 19:20:07 UTC 
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

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:
How-To-Repeat: Run a machine with mpt controller, connect daN disks, setup a gmirror / ZFS raid and generate disk load (writes?).
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-11-21 00:08:23 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-scsi

This PR might get some more visibility on this mailing list.
Comment 2 marius 2011-11-21 20:25:52 UTC 
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
Comment 3 Sean Bruno freebsd_committer freebsd_triage 2013-05-07 15:55:41 UTC 
State Changed
From-To: open->feedback

These patches are probably going to be rejected.  But, we would request that you retest 
the hardware specified  on stable/9 or newer.
Comment 4 Sean Bruno freebsd_committer freebsd_triage 2015-05-07 15:32:02 UTC 
No feedback on testing newer releases from submitter.  If this is still an issue for you on newer FreeBSD, please open a new ticket.