Date: Mon, 10 Apr 2006 14:40:34 -0700 (PDT) From: Tom Samplonius <tom@uniserve.com> To: Eric Anderson <anderson@centtech.com> Cc: freebsd-scsi@freebsd.org Subject: Re: LIP destroyed xxx active commands Message-ID: <20060410143733.V89316@mgmt.uniserve.ca> In-Reply-To: <443AC4E4.9030808@centtech.com> References: <443AA86A.5020207@centtech.com> <20060410120647.W46924@mgmt.uniserve.ca> <443AC4E4.9030808@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Apr 2006, Eric Anderson wrote: > Tom Samplonius wrote: >> >> Eric, >> >> It seems that isp0 is connected to a loop topology network (as opposed to >> a point to point, or fabric), and something keeps initializing the loop by >> sending a LIP command. >> >> Are you plugging or unplugging things into the loop all of the time? Or >> are you loop part on a switch, and someone else is plugging or unplugging >> things from the fabric? If you are going straight into a switch, it might >> be better to change the port to a fabric port instead. > > > This host has it's isp device directly connected to a fiber channel array. Probably should use point-to-point mode instead. See if you can change the port type on the array controller. > The array is not disappearing, or being rebooted, nor is there any other > machine rebooting or resetting. I see these same errors on another box that > has 3 arrays connected to a qlogic switch. I seem to only see these when the > machine is heavily accessing the disks. Same here. You shouldn't see LIPs on a fabric. So the QLogic switch must be trying to maintain a loop per port. I suspect that loop mode is also less stable than point-to-point or fabric. There is an indication in the isp manpage that it is possible for the driver to hang on boot waiting for a LIP. The solution to that problem has been to force a LIP (unplug something), or don't use a loop mode. > > Eric Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060410143733.V89316>