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?).
Responsible Changed From-To: freebsd-bugs->freebsd-scsi This PR might get some more visibility on this mailing list.
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 These patches are probably going to be rejected. But, we would request that you retest the hardware specified on stable/9 or newer.
No feedback on testing newer releases from submitter. If this is still an issue for you on newer FreeBSD, please open a new ticket.