Date: Wed, 30 Nov 2005 19:33:41 -0800 From: Matthew Jacob <lydianconcepts@gmail.com> To: "Rajesh S. Ghanekar" <rajesh_ghanekar@persistent.co.in> Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed Message-ID: <7579f7fb0511301933j2593b780wf3130bbcb37ab43f@mail.gmail.com> In-Reply-To: <438D4AF9.7040600@persistent.co.in> References: <438C750D.5030604@persistent.co.in> <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> <438D4AF9.7040600@persistent.co.in>
next in thread | previous in thread | raw e-mail | index | archive | help
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*. 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 ca= n pull that code back. Its a simple topology with all the hosts presented to all the available LUN= s > on EVA. > I am sorry that I said it is FreeBSD-4.10, it is FreeBSD-4.1. This logs > the message > as "inquiry changed". > > > -------------------------------------------- > | HP > EVA-8k | > | (cntrl > 1) | > > -------------------------------------------- > | > | > > -------------------------------------------------------------------------= - > | FC > Switch | > > | > | > > ------------------------------------------------------------------------- > > | | > > | | > Machine 1 Machine > 2 > > > > Backtrace is as follows: > ----------------------------- > > (kgdb) #0 0xc01a44af in boot () > #1 0xc01a4c0f in panic () > #2 0xc02849f0 in trap_fatal () > #3 0xc028466d in trap_pfault () > #4 0xc02841df in trap () > #5 0xc01aec1b in dscheck () > #6 0xc01ae94a in diskstrategy () > #7 0xc01a049c in physio () > #8 0xc01e1ee6 in spec_read () > #9 0xc0238160 in ufsspec_read () > #10 0xc0238a5d in ufs_vnoperatespec () > #11 0xc01d91fc in vn_read () > #12 0xc01b31cd in dofileread () > #13 0xc01b2fd6 in read () > #14 0xc0284e86 in syscall2 () > #15 0xc027066b in Xint0x80_syscall () > cannot read proc at 0 > > On the surviving system (the machine which rebooted initially) can see > all the LUNs after it comes up on reboot. > > Thanks, > Rajesh > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7579f7fb0511301933j2593b780wf3130bbcb37ab43f>