On Sun, 20 Feb 2011, Jonathan A. Kollasch wrote:
On Sun, Feb 20, 2011 at 02:32:10PM -0500, Chris Ross wrote:I have a machine that I just built and installed a netbsd-5 from today (Feb 20, 2011). I was untar'ing tarballs from another system into a subdirectory of /var/tmp, and received the following panic: sd0(ciss0:0:0:0): no free tags panic: scsipi_get_tag This is a dual-processor i386 machine, with an HP SmartArray 5i RAID controller, presenting numerous sd(4) devices. The destination filesystem (/var/tmp) is sd0g. WAPBL is enabled on all but the root filesystem of this destination machine. I tried to replicate it again, and was able to extract one tarball, then the next one failed and caused the same panic. That tarball was of /var/log, and does contain a few multi-hundred megabyte files. Possible that's related? Anyone have any idea what happened here? Is this indicative of an instability in ciss(4), or WABPL ?I'd guess it's a locking issue in the scsipi tag get/put code. While ciss(4) is one of the few storage drivers that has modern locking, I'm not sure scsipi does too.
It's much more likely due to a DIAGNOSTIC kernel that panics when the scsipi layer is trying to allocate a tag for a transfer. The ciss(4) ignores the tag set by the scsipi layer and does its own tagging (if I understand the use of tags and how the ciss(4) driver works). Ciss(4) can typically accept > 256 commands, which exceeds the number of tags available to the scsipi layer. When I was testing the changes to ciss(4) to use tagged queueing, I was not running a DIAGNOSTIC kernel, and never saw any problems, even when the number of commands queued to ciss(4) vastly exceeded 256. The following change to ciss.c should fix this by limiting the number of commands the scsipi layer can send to a single peripheral device. Perhaps the maximum of 256 could be controlled by DIAGNOSTIC to take full advantage of the number of commands ciss(4) can handle.
- sc->sc_adapter.adapt_max_periph = sc->sc_adapter.adapt_openings; + sc->sc_adapter.adapt_max_periph = min(sc->sc_adapter.adapt_openings, 256); -- Michael L. Hitch mhitch%montana.edu@localhost Computer Consultant Information Technology Center Montana State University Bozeman, MT USA