kern/159414: isp(4)+gmultipath(8) : removing active fiber path,
and gmultipath failing over to standby path provokes a kernel panic
Stephane Lapie
stephane.lapie at darkbsd.org
Wed Aug 3 12:50:09 UTC 2011
>Number: 159414
>Category: kern
>Synopsis: isp(4)+gmultipath(8) : removing active fiber path, and gmultipath failing over to standby path provokes a kernel panic
>Confidential: no
>Severity: critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Aug 03 12:50:08 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Stephane Lapie
>Release: 8.2-RELEASE
>Organization:
Aozora Bank
>Environment:
FreeBSD fccbakpoda.aozora.lan 8.2-RELEASE-AZB FreeBSD 8.2-RELEASE-AZB #1: Thu Mar 3 18:39:55 UTC 2011 root at fcc4svnapf01.aozora.lan:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
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.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list