When using FC HBAs handled by the isp(4) driver, gmultipath(8) (two fiber paths to access the same devices), and a ZFS pool, removing the active link and trying to provoke automatic failover, will cause a kernel panic. How-To-Repeat: Remove the active fiber link (confirmable with activity LEDs from the storage unit) while I/O is going on. The kernel log will display some devices failing over, invalidated SCSI packets and devices, isp(4) handle timeouts, before panicking. Latest visible kernel trap message concerns the g_mp_kt thread. However, if gmultipath rotate is used to switch path on all devices, then it can be safely removed. This looks like a race condition between isp(4) loopdown provoking da(4) destruction, and gmultipath(8) failover.
Responsible Changed From-To: freebsd-bugs->freebsd-scsi Over to maintainer(s).
Responsible Changed From-To: freebsd-scsi->mjacob I guessI should own this.
State Changed From-To: open->feedback
Responsible Changed From-To: mjacob->freebsd-geom This is really a geom bug, not an isp bug.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped