Date: Thu, 01 Dec 2005 08:47:08 -0700 From: Scott Long <scottl@samsco.org> To: Matthew Jacob <lydianconcepts@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed Message-ID: <438F1AFC.1080301@samsco.org> In-Reply-To: <7579f7fb0511301933j2593b780wf3130bbcb37ab43f@mail.gmail.com> References: <438C750D.5030604@persistent.co.in> <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> <438D4AF9.7040600@persistent.co.in> <7579f7fb0511301933j2593b780wf3130bbcb37ab43f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote: > Switch as in 'Fabric' or 'Segmented FC-AL'? > > The panic looks like the ones where as far as the system is concerned the > disk went away. > > Right now, certain fabric and loop events cause the isp driver to think the > target has gone away, and this gets sent as async event upstream. I'm > beginning to think that this is a losing proposition for FreeBSD- on the > other hand, the unexpected disappearance of a device isn't handled well by > FreeBSD *either*. Yeah, the most serious and hard to fix problem is that most filesystems and I/O related parts of the VM assume that all I/O succeeds. > > When I did a hardening exercise at Mirapoint for the FreeBSD isp driver and > SCSI midlayer, I seem to recall that I put in a deferred device > disappearance algorithm. Maybe I should check with Mirapoint to see if I can > pull that code back. > John Polstra committed some fixes about a month ago related to device disappearance in SCSI. Might be good to look at that too. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438F1AFC.1080301>