From owner-freebsd-scsi@FreeBSD.ORG Wed May 8 19:33:13 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id 2B55DC68; Wed, 8 May 2013 19:33:13 +0000 (UTC) Date: Wed, 8 May 2013 19:33:13 +0000 From: John To: FreeBSD SCSI Subject: Re: Repeated msgs & kernel panic w/ r246437 (Revamp the CAM enclosure services driver) Message-ID: <20130508193313.GA65921@FreeBSD.org> References: <20130422030053.GA23186@FreeBSD.org> <517641C6.7010905@FreeBSD.org> <20130423140237.GA50775@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130423140237.GA50775@nargothrond.kdm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , "Kenneth D. Merry" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 19:33:13 -0000 ----- Kenneth D. Merry's Original Message ----- > > On 22.04.2013 06:00, John wrote: > > >Hi Folks, > > > > > > After updating one of our servers to the latest stable image, > > >it appears that commit r246437 appears to be causing it to panic. > I agree. I added the xpt_create_path_unlocked() call to fix a > panic with a stack trace just like the one above. It looks like a problem > due to running r246437 exactly. As noted above, the system panics with the latest stable image. We simply started backing off commits until we found where the system no longer panic'd. Side note: is there a way to disable the new daemon that I haven't seen? sysctl? loader config? Apologies for the delay - here is the stable information: 'working' tag - has 1 of the external LSI cards disabled (so only 1 path through the shelves). 'broken' tag - has both cards enabled and panics in short order. Both of these are with a stable build (r249895) http://www.freebsd.org/~jwd/r246437/dmesg.working.txt http://www.freebsd.org/~jwd/r246437/dmesg.broken.txt Some db output: Panic: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 04 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ce7db8 stack pointer = 0x28:0xffffff975fe55a00 frame pointer = 0x28:0xffffff975fe55a30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (thread taskq) [ thread pid 0 tid 100035 ] Stopped at memcpy+0x8: repe movsq (%rsi),%es:(%rdi) db> bt Tracing pid 0 tid 100035 td 0xfffffe00262f4490 memcpy() at memcpy+0x8/frame 0xffffff975fe55a30 xpt_getattr() at xpt_getattr+0xed/frame 0xffffff975fe55b40 pass_add_physpath() at pass_add_physpath+0xdf/frame 0xffffff975fe55b70 taskqueue_run_locked() at taskqueue_run_locked+0x74/frame 0xffffff975fe55bc0 taskqueue_thread_loop() at taskqueue_thread_loop+0x46/frame 0xffffff975fe55be0 fork_exit() at fork_exit+0x11f/frame 0xffffff975fe55c30 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff975fe55c30 --- trap 0, rip = 0, rsp = 0xffffff975fe55cf0, rbp = 0 --- broken.txt contains more db trace info. Thanks, John