From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 30 06:24:46 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A912816A41F for ; Wed, 30 Nov 2005 06:24:46 +0000 (GMT) (envelope-from rajesh_ghanekar@persistent.co.in) Received: from smtp.persistent.co.in (smtp.persistent.co.in [202.54.11.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C0F43D69 for ; Wed, 30 Nov 2005 06:24:33 +0000 (GMT) (envelope-from rajesh_ghanekar@persistent.co.in) Received: from [10.77.196.113] ([10.77.196.113]) (authenticated bits=0) by smtp.persistent.co.in (8.12.9/) with ESMTP id jAU6O0Mr012204; Wed, 30 Nov 2005 11:54:25 +0530 Message-ID: <438D4AF9.7040600@persistent.co.in> Date: Wed, 30 Nov 2005 12:17:21 +0530 From: "Rajesh S. Ghanekar" User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <438C750D.5030604@persistent.co.in> <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> In-Reply-To: <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 06:24:46 -0000 Matthew Jacob wrote: > > > (da0:isp0:0:2:1): inquiry changed > > > Did you transcribe by hand? The closest would be: > > "Inquiry data has changed" > > This just means that the the EVA sent back a command with "Inquiry > Data Changed" > > (da0:isp0:0:2:1): . CDB: 2a 0 8 9f 6d 25 0 0 4 0 > > Fatal trap 12: page fault while in kernel mode > mp_lock = 01000002; cpuid = 1; lapic.id = 06000000 > fault virtual address = 0x60 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01aec1b > stack pointer = 0x10:0xf4f41d5c > frame pointer = 0x10:0xf4f41d74 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 10750 (IOtest-static) > interrupt mask = none <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 01000002; cpuid = 1; lapic.id = 06000000 > boot() called on cpu#1 > > > > w/o a traceback I can't really say what happened here with certainty. > Given the other probe messages somehow we seem to be re-scanning due > to the other system going down. > > Try a 'boot verbose' and see whether on the surviving system that the > disks are being seen as going away by the ISP driver. > > What's the connection topology, btw? > Its a simple topology with all the hosts presented to all the available LUNs 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