From owner-freebsd-scsi@FreeBSD.ORG Mon Aug 25 11:06:57 2008 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E757106569B for ; Mon, 25 Aug 2008 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9094D8FC39 for ; Mon, 25 Aug 2008 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7PB6vSh027887 for ; Mon, 25 Aug 2008 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7PB6up0027883 for freebsd-scsi@FreeBSD.org; Mon, 25 Aug 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Aug 2008 11:06:56 GMT Message-Id: <200808251106.m7PB6up0027883@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org 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: Mon, 25 Aug 2008 11:06:57 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/120487 scsi [sg] scsi_sg incompatible with scanners o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o kern/123674 scsi [ahc] ahc driver dumping 10 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Aug 25 16:53:08 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61101065706 for ; Mon, 25 Aug 2008 16:53:08 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail1.connection.ca (nc-tor-mail1.connection.ca [205.207.122.26]) by mx1.freebsd.org (Postfix) with ESMTP id BE3EE8FC1D for ; Mon, 25 Aug 2008 16:53:08 +0000 (UTC) (envelope-from westr@connection.ca) Received: from localhost (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail1.connection.ca (Postfix) with ESMTP id 0C0E344B454 for ; Mon, 25 Aug 2008 12:53:08 -0400 (EDT) Date: Mon, 25 Aug 2008 12:53:07 -0400 From: Ross Organization: Network Connection X-Priority: 3 (Normal) Message-ID: <1465985957.20080825125307@connection.ca> To: freebsd-scsi@freebsd.org In-Reply-To: <48A5CE50.4050404@samsco.org> References: <1051060505.20080815123014@connection.ca> <48A5CE50.4050404@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re[2]: isp(4) - setting debug mode flags X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ross List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 16:53:09 -0000 To close my own thread with an answer. I forgot that I was statically compiling in my hints file into the kernel, so therefore any overrides in /boot/device.hints would not work. SL> First thing to check is whether what you're setting is actually making SL> it into the kernel environment and is what you expect it to be. Run SL> 'kenv' on a running system and look for the hint.isp.0.debug string. SL> Second, it looks like ISP_LOGDEBUG1 is the only flag that has any SL> special meaning, make sure you set that as well as ISP_LOGWARN and SL> ISP_LOGERR (the default flags). ISP_LOGDEBUG0 is the best so far - LOGDEBUG1 provides a huge amount of additional output that is probably too much. Debug value of "0x11F" provides the majority of needed output for me. Ross. -- From owner-freebsd-scsi@FreeBSD.ORG Tue Aug 26 20:42:00 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0069B1065698 for ; Tue, 26 Aug 2008 20:41:59 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail1.connection.ca (nc-tor-mail1.connection.ca [205.207.122.26]) by mx1.freebsd.org (Postfix) with ESMTP id B1DC28FC34 for ; Tue, 26 Aug 2008 20:41:59 +0000 (UTC) (envelope-from westr@connection.ca) Received: from localhost (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail1.connection.ca (Postfix) with ESMTP id B399C44B442 for ; Tue, 26 Aug 2008 16:41:58 -0400 (EDT) Date: Tue, 26 Aug 2008 16:41:58 -0400 From: Ross Organization: Network Connection X-Priority: 3 (Normal) Message-ID: <13710393234.20080826164158@connection.ca> To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: isp(4) - kernel panic on initialization of driver X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ross List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2008 20:42:00 -0000 I've been tracking down a problem that is sometimes causing a kernel panic to occur when initializing the isp driver in the system. (System in question is a HP Blade - BL460c w/ QHM 6432 FC dual port card reporting as the following: isp0: port 0x4000-0x40ff mem 0xfdff0000-0xfdff3fff irq 18 at device 0.0 on pci16 isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 isp1: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 We're doing a boot-via-san situation, and the issue looks to be that the card is receiving a ISPASYNC_CHANGE_PDB command on isp1 before it's ready for it. I'm guessing it's due to the fact the card already as the firmware loaded and active (due to the boot). Console debug (hint.isp.[01].debug=0x11f) output looks like the following on a crash: -= kernel: isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 kernel: isp1: set PCI latency to 64 kernel: isp1: [ITHREAD] kernel: isp1: line 5345: markportdb kernel: isp1: Port Database Changed kernel: isp1: Port Database Changed: freeze simq (loopdown) [crash] -= Further debugging shows that isp_freeze_loopdown() function that is called at the above point never returns. Quick guess is the called xpt_freeze_simq() function [line 290 in isp_freebsd.c] is the culprit, but that's about the limit of my ability for tracking this down. If anyone has any pointers to fixing this, that would be appreciated! Thanks, Ross. (Also filed http://www.freebsd.org/cgi/query-pr.cgi?pr=126866 with basically the same notes above) -- From owner-freebsd-scsi@FreeBSD.ORG Tue Aug 26 21:00:29 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D1071065676 for ; Tue, 26 Aug 2008 21:00:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 97AE18FC1A for ; Tue, 26 Aug 2008 21:00:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id m7QL0HKO051152; Tue, 26 Aug 2008 15:00:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48B46EE1.8060408@samsco.org> Date: Tue, 26 Aug 2008 15:00:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Ross References: <13710393234.20080826164158@connection.ca> In-Reply-To: <13710393234.20080826164158@connection.ca> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: isp(4) - kernel panic on initialization of driver 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: Tue, 26 Aug 2008 21:00:29 -0000 Ross wrote: > I've been tracking down a problem that is sometimes causing a kernel > panic to occur when initializing the isp driver in the system. (System > in question is a HP Blade - BL460c w/ QHM 6432 FC dual port card > reporting as the following: > > isp0: port 0x4000-0x40ff mem 0xfdff0000-0xfdff3fff irq 18 at device 0.0 on pci16 > isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 > isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 > isp1: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 > > We're doing a boot-via-san situation, and the issue looks to be that > the card is receiving a ISPASYNC_CHANGE_PDB command on isp1 before > it's ready for it. I'm guessing it's due to the fact the card already > as the firmware loaded and active (due to the boot). > > Console debug (hint.isp.[01].debug=0x11f) output looks like the following on a crash: > > -= > kernel: isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 > kernel: isp1: set PCI latency to 64 > kernel: isp1: [ITHREAD] > kernel: isp1: line 5345: markportdb > kernel: isp1: Port Database Changed > kernel: isp1: Port Database Changed: freeze simq (loopdown) > [crash] > -= > > Further debugging shows that isp_freeze_loopdown() function that is > called at the above point never returns. Quick guess is the called > xpt_freeze_simq() function [line 290 in isp_freebsd.c] is the culprit, > but that's about the limit of my ability for tracking this down. > > > If anyone has any pointers to fixing this, that would be appreciated! > > Thanks, > Ross. > > (Also filed http://www.freebsd.org/cgi/query-pr.cgi?pr=126866 with > basically the same notes above) > Please post the panic trace and messages. Scott From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 03:13:49 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7EA21065674 for ; Wed, 27 Aug 2008 03:13:49 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id AB79A8FC13 for ; Wed, 27 Aug 2008 03:13:49 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTP id 0DCAB8FC22 for ; Tue, 26 Aug 2008 21:52:43 -0500 (CDT) Message-ID: <48B4CF57.30603@fuujinnetworks.com> Date: Tue, 26 Aug 2008 21:51:51 -0600 From: Fuujin Networks LLC User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Qlogic FC scsi_target ISP2310 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, 27 Aug 2008 03:13:50 -0000 I've run into a snag with our SAN and I'm hoping someone out there can shed some light on the glass, as it were. We're trying to use scsi_target mode with a pair of QLogic ISP2310 2GB fibre-channel cards in a Point-to-Point topology. These cards will NOT be part of a switch fabric. I started out with a quad port card, and when I rescanned the SCSI bus on the initiating end of the loop, the target machine tanked. The filer dumps core, reboots, and reproduces the result faithfully. Thinking I might be doing something wrong with port selection, I pulled the quad port card out of the SAN filer and installed a single port card. After several days of jiggery pokery with all manner of knobs, AIO, etc, I've ended up with the same result: a 64-bit space heater. :) I've Googled this to death, crawled the lists, and I've not found a solution other than the occasional "it might be buggy" comment. Full kernel traces are available to anyone interested, possibly even ssh access to a test box if requested. I've been running FreeBSD for about 7 years and I've never seen an operating system as stable, so I'm rather determined to make this work than go to Linux. The filer is running FreeBSD 7.0 amd64, dual Opteron 2216's, with 8 gigs of ram. I've tested this on a pair of HP DL580 G3's to see if there was a difference from 32-bit to 64-bit hardware, but none was apparent. Any help is greatly appreciated! -- Erich M. Jenkins Fuujin Networks, LLC PO Box 792 Brainerd, MN 56401 (p) 218-824-5038 (f) 218-824-7516 "You should never, never doubt what no one is sure about." --Gene Wilder From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 09:05:45 2008 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 302B51065672; Wed, 27 Aug 2008 09:05:45 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E64878FC19; Wed, 27 Aug 2008 09:05:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7R95ipF005863; Wed, 27 Aug 2008 09:05:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7R95iY0005859; Wed, 27 Aug 2008 09:05:44 GMT (envelope-from linimon) Date: Wed, 27 Aug 2008 09:05:44 GMT Message-Id: <200808270905.m7R95iY0005859@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization 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, 27 Aug 2008 09:05:45 -0000 Synopsis: [isp] [panic] kernel panic on card initialization Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 27 09:05:34 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126866 From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 14:42:24 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2618F1065682 for ; Wed, 27 Aug 2008 14:42:24 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail2.connection.ca (nc-tor-mail2.connection.ca [205.207.122.27]) by mx1.freebsd.org (Postfix) with ESMTP id 04CAA8FC21 for ; Wed, 27 Aug 2008 14:42:23 +0000 (UTC) (envelope-from westr@connection.ca) Received: from localhost (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail2.connection.ca (Postfix) with ESMTP id CD10074E5B5 for ; Wed, 27 Aug 2008 10:42:12 -0400 (EDT) Date: Wed, 27 Aug 2008 10:42:09 -0400 From: Ross Organization: Network Connection X-Priority: 3 (Normal) Message-ID: <302438113.20080827104209@connection.ca> To: freebsd-scsi@freebsd.org In-Reply-To: <48B46EE1.8060408@samsco.org> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re[2]: isp(4) - kernel panic on initialization of driver X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ross List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 14:42:24 -0000 SL> Please post the panic trace and messages. If the formatting/spelling is off, it's due to the cut-n-paste done by hand/eye. (due virtual ILOM screen, so no easy save) -= start isp1: set PCI latency to 64 isp1: [ITHREAD] isp1: line 5345: markportdb isp1: Port Database Changed Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0x58 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0243a46 stack pointer = 0x20:0xc0af63cc frame pointer = 0x20:0xc0af63cc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort ... -= end The values are the same across different reboots. R. -- From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 15:12:14 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 246F21065671 for ; Wed, 27 Aug 2008 15:12:14 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id F18228FC23 for ; Wed, 27 Aug 2008 15:12:13 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3979072rvf.43 for ; Wed, 27 Aug 2008 08:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DzQjN8c5AokFHqOkYUK54Xz1XbjFHlangf4Knzom1vo=; b=N0qkIbRPVNGbGWvg2nPLGln5fg3ROZjNVVEXER51Qe2rC6fMeGWOJ6ofyByG+U2htz M7mbCXUAPbiTu6XTSc3Jnj6LyvdCbmawqYk5QjRHoHWmb1gDjBK6tNk/Jme/L8+qoH+1 3+3TTQGn/7WQDvpz20fXRAgq0iKD4neQMnZV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sL1zF8zo03fIRljtVpAdfldi28MFtZCvbP+sFomXgYYS7fS17mtvRO9vKoXqr/XOl0 LJW3DBD/T1unTyDKvKaPyGuX7t/TJdexEQP7AY9qC6fYwMoxf8JwVU59vvYIBEIBQrfg cy45R1qEbnXSrQ5XiebKVtCUl2PYYIOYU4cBQ= Received: by 10.141.162.1 with SMTP id p1mr34689rvo.39.1219848234247; Wed, 27 Aug 2008 07:43:54 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Wed, 27 Aug 2008 07:43:54 -0700 (PDT) Message-ID: <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> Date: Wed, 27 Aug 2008 10:43:54 -0400 From: "Alexander Sack" To: "Scott Long" In-Reply-To: <48B46EE1.8060408@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: isp(4) - kernel panic on initialization of driver 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, 27 Aug 2008 15:12:14 -0000 On Tue, Aug 26, 2008 at 4:41 PM, Ross wrote: > I've been tracking down a problem that is sometimes causing a kernel > panic to occur when initializing the isp driver in the system. (System > in question is a HP Blade - BL460c w/ QHM 6432 FC dual port card > reporting as the following: > > isp0: port 0x4000-0x40ff mem 0xfdff0000-0xfdff3fff irq 18 at device 0.0 on pci16 > isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 > isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 > isp1: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 So one question I have is why doesn't the isp driver load the firmware in ispfw? This is 7.x, so firmware_get() should have returned the isp_2400 registered firmware image for a 2422 card and loaded it it in isp_reset() unless dodnld was set to zero from a hint flag. By any chance do you have "hint.isp.0.fwload_disable" set? I'm not saying that will fix your problem but I just noticed this. > We're doing a boot-via-san situation, and the issue looks to be that > the card is receiving a ISPASYNC_CHANGE_PDB command on isp1 before > it's ready for it. I'm guessing it's due to the fact the card already > as the firmware loaded and active (due to the boot). Nah, I don't think that's it exactly. i.e. whether or not isp/ispfw loads the firmware on boot, I think you can still see this issue. It looks like after isp_reset() is performed which grabs information from the ISP and normally attempts to reset it and do further hardware initialization we get into isp_init(). The isp_init() function attempts to issue MBOX_SET_FIRMWARE_OPTIONS command which will generate an Asynchronous event when a LIP is received. At this point the ISP_LOCK is held (which blocks any ISR at this point). However I see in isp_attach() we drop it which I will bet is when chaos ensues (isr proceeds, obtains the lock and goes through the async event path). WARNING: this is pure speculation on my part from quickly looking at it. I'm just wondering if this is a bug in isp allowing the ASYNC events occuring before a complete attach has been performed. > Console debug (hint.isp.[01].debug=0x11f) output looks like the following on a crash: > > -= > kernel: isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 > kernel: isp1: set PCI latency to 64 > kernel: isp1: [ITHREAD] > kernel: isp1: line 5345: markportdb > kernel: isp1: Port Database Changed > kernel: isp1: Port Database Changed: freeze simq (loopdown) > [crash] > -= > > Further debugging shows that isp_freeze_loopdown() function that is > called at the above point never returns. Quick guess is the called > xpt_freeze_simq() function [line 290 in isp_freebsd.c] is the culprit, > but that's about the limit of my ability for tracking this down. Yes but its not clear to me the bug is REALLY in CAM...yet. It might be ISP letting asynchronous events in before its really ready which means its a driver problem. I have a 24xx card in the lab, maybe I can test this if I get a chance too. I'm assuming all you are doing is booting 7.0-RELEASE off the SAN? As Scott asked, can you get a dump or a trace of the crash? Thanks! -aps From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 15:27:53 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0AB5106566C for ; Wed, 27 Aug 2008 15:27:52 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail2.connection.ca (nc-tor-mail2.connection.ca [205.207.122.27]) by mx1.freebsd.org (Postfix) with ESMTP id A4CBC8FC08 for ; Wed, 27 Aug 2008 15:27:52 +0000 (UTC) (envelope-from westr@connection.ca) Received: from localhost (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail2.connection.ca (Postfix) with ESMTP id 8E87B74E5C8 for ; Wed, 27 Aug 2008 11:27:51 -0400 (EDT) Date: Wed, 27 Aug 2008 11:27:51 -0400 From: Ross Organization: Network Connection X-Priority: 3 (Normal) Message-ID: <86689256.20080827112751@connection.ca> To: freebsd-scsi@freebsd.org In-Reply-To: <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re[2]: isp(4) - kernel panic on initialization of driver X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ross List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 15:27:53 -0000 AS> So one question I have is why doesn't the isp driver load the AS> firmware in ispfw? [...clip...] By any chance do you have AS> "hint.isp.0.fwload_disable" set? I'm not saying that will fix your AS> problem but I just noticed this. The card came with 4.00.90 which is newer than the firmware included in ispfw (4.00.20) - but to answer your question, yes, fwload_disable is set for the cards. I believe that got set since there was some kind of problem that we ran into at one point. I'll do some testing on that. AS> WARNING: this is pure speculation on my part from quickly looking at AS> it. I'm just wondering if this is a bug in isp allowing the ASYNC AS> events occuring before a complete attach has been performed. Apologies if it didn't come across in my previous message, that's basically what I'm saying too. I have about a 50/50 chance of the card booting successfully, and when it does, the output from the debug lines is different, and it looks like the ASYNC event is executing before it's time. (See the end of this message for the full output from isp[01]: for a clean boot, since it's a long output.) AS> Yes but its not clear to me the bug is REALLY in CAM...yet. It might AS> be ISP letting asynchronous events in before its really ready which AS> means its a driver problem. I have a 24xx card in the lab, maybe I AS> can test this if I get a chance too. That's what I'm assuming as well. AS> I'm assuming all you are doing is booting 7.0-RELEASE off the SAN? That is correct. We're just using the i386 image at the current time (eventually going to amd64, but not now). It's been trimmed of the fat, but nothing special/custom added in. AS> As Scott asked, can you get a dump or a trace of the crash? See my other message to freebsd-scsi/Scott for that. Thanks for looking at the issue! Ross. -= start of clean boot output. isp0: port 0x4000-0x40ff mem 0xfdff0000-0xfdff3fff irq 18 at device 0.0 on pci16 isp0: set PCI latency to 64 isp0: [ITHREAD] isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 isp0: 2K Logins Supported isp0: Last F/W revision was 4.0.90 isp0: 4096 max I/O command limit set isp0: line 1207: markportdb isp0: Starting Initial Loop Down Timer isp1: port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16 isp1: set PCI latency to 64 isp1: [ITHREAD] isp1: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90 isp1: 2K Logins Supported isp1: Last F/W revision was 4.0.90 isp1: 4096 max I/O command limit set isp1: line 1207: markportdb isp1: Starting Initial Loop Down Timer ... [other driver startup and then eventually we get] ... isp0: line 5271: markportdb isp0: LIP Received isp1: line 5271: markportdb isp1: LIP Received isp0: line 5333: markportdb isp0: LOOP Reset isp1: line 5333: markportdb isp1: LOOP Reset isp0: line 5271: markportdb isp0: LIP Received isp1: line 5271: markportdb isp1: LIP Received isp0: line 5271: markportdb isp0: LIP Received isp1: line 5271: markportdb isp1: LIP Received isp0: line 5333: markportdb isp0: LOOP Reset isp1: line 5333: markportdb isp1: LOOP Reset isp0: line 5360: markportdb isp0: Stopping Loop Down Timer isp0: Other Change Notify isp0: Point-to-Point mode isp1: line 5360: markportdb isp1: Stopping Loop Down Timer isp1: Other Change Notify isp1: Point-to-Point mode isp0: line 5307: markportdb isp0: Loop UP isp1: line 5307: markportdb isp1: Loop UP isp0: line 5345: markportdb isp0: Port Database Changed isp1: line 5345: markportdb isp1: Port Database Changed isp0: line 5345: markportdb isp0: Port Database Changed isp1: line 5345: markportdb isp1: Port Database Changed isp0: line 5345: markportdb isp0: Port Database Changed isp1: line 5345: markportdb isp1: Port Database Changed isp0: isp_kthread: checking FC state isp0: FC Link Test Entry isp0: line 2460: markportdb isp1: isp_kthread: checking FC state isp1: FC Link Test Entry isp1: line 2460: markportdb isp0: Firmware State Ready> isp1: Firmware State Ready> isp1: Register FC4 Type accepted isp0: Register FC4 Type accepted isp1: 4Gb link speed/s isp1: HBA PortID 0x030100 N-Port Handle 0, Connection Topology 'F Port' isp1: HBA WWNN 0x5001438002211547 HBA WWPN 0x5001438002211546 isp1: FC Link Test Complete isp1: FC Scan Fabric isp0: 4Gb link speed/s isp0: HBA PortID 0x020100 N-Port Handle 0, Connection Topology 'F Port' isp0: HBA WWNN 0x5001438002211545 HBA WWPN 0x5001438002211544 isp0: FC Link Test Complete isp0: FC Scan Fabric isp1: got 12 ports back from name server isp1: skip ourselves @ PortID 0x030100 isp1: Checking Fabric Port 0x030200 isp0: got 13 ports back from name server isp0: skip ourselves @ PortID 0x020100 isp0: Checking Fabric Port 0x020200 isp1: Fabric Port 0x030200 is New Entry isp1: Checking Fabric Port 0x030300 isp0: Fabric Port 0x020200 is New Entry isp0: Checking Fabric Port 0x020300 isp1: Fabric Port 0x030300 is New Entry isp1: Checking Fabric Port 0x030d00 isp0: Fabric Port 0x020300 is New Entry isp0: Checking Fabric Port 0x020d00 isp1: Fabric Port 0x030d00 is New Entry isp1: Checking Fabric Port 0x030e00 isp0: Fabric Port 0x020d00 is New Entry isp0: Checking Fabric Port 0x020e00 isp1: Fabric Port 0x030e00 is New Entry isp1: Checking Fabric Port 0x031000 isp1: Fabric Port 0x031100 is New Entry isp1: Checking Fabric Port 0x050100 isp0: Fabric Port 0x021100 is New Entry isp0: Checking Fabric Port 0x040100 isp1: Fabric Port 0x050100 is New Entry isp1: Checking Fabric Port 0x050200 isp0: Fabric Port 0x040100 is New Entry isp0: Checking Fabric Port 0x040200 isp1: Fabric Port 0x050200 is New Entry isp1: Checking Fabric Port 0x050800 isp0: Fabric Port 0x040200 is New Entry isp0: Checking Fabric Port 0x040800 isp1: Fabric Port 0x050800 is New Entry isp1: Checking Fabric Port 0x050e00 isp0: Fabric Port 0x040800 is New Entry isp0: Checking Fabric Port 0x040e00 isp1: Fabric Port 0x050e00 is New Entry isp1: Checking Fabric Port 0x051100 isp0: Fabric Port 0x040e00 is New Entry isp0: Checking Fabric Port 0x041100 isp1: Fabric Port 0x051100 is New Entry isp1: FC Scan Fabric Done isp1: Synchronizing PDBs isp1: PortID 0x030200 handle 0x1 role Initiator arrived WWNN 0x5001438001fff1df WWPN 0x5001438001fff1de isp1: PortID 0x030300 handle 0x2 role Initiator arrived WWNN 0x5001438002211a1f WWPN 0x5001438002211a1e isp1: PortID 0x030d00 handle 0x3 role Initiator arrived WWNN 0x5001438001fff22f WWPN 0x5001438001fff22e isp1: PortID 0x030e00 handle 0x4 role Initiator arrived WWNN 0x50014380022110c7 WWPN 0x50014380022110c6 isp1: PortID 0x031000 handle 0x5 role Initiator arrived WWNN 0x5001438001fff22b WWPN 0x5001438001fff22a isp1: PortID 0x031100 handle 0x6 role Target arrived at tgt 0 WWNN 0x50001fe150103510 WWPN 0x50001fe15010351d isp1: PortID 0x050100 handle 0x7 role Initiator arrived WWNN 0x5001438002211a6f WWPN 0x5001438002211a6e isp1: PortID 0x050200 handle 0x8 role Initiator arrived WWNN 0x5001438002211aab WWPN 0x5001438002211aaa isp1: PortID 0x050800 handle 0x9 role Initiator arrived WWNN 0x5001438002211a9b WWPN 0x5001438002211a9a isp1: PortID 0x050e00 handle 0xa role Initiator arrived WWNN 0x5001438001fff267 WWPN 0x5001438001fff266 isp1: PortID 0x051100 handle 0xb role Target arrived at tgt 1 WWNN 0x50001fe150103510 WWPN 0x50001fe150103518 isp1: PortID 0xfffffe handle 0x7fe role (none) stayed WWNN 0x100000051e092a5e WWPN 0x200100051e092a5e isp1: isp_kthread: FC state OK isp1: isp_kthread: releasing simq isp1: isp_kthread: sleep time 0 isp0: Fabric Port 0x041100 is New Entry isp0: Checking Fabric Port 0x041300 isp0: Fabric Port 0x041300 is New Entry isp0: FC Scan Fabric Done isp0: Synchronizing PDBs isp0: PortID 0x020200 handle 0x1 role Initiator arrived WWNN 0x5001438001fff1dd WWPN 0x5001438001fff1dc isp0: PortID 0x020300 handle 0x2 role Initiator arrived WWNN 0x5001438002211a1d WWPN 0x5001438002211a1c isp0: PortID 0x020d00 handle 0x3 role Initiator arrived WWNN 0x5001438001fff22d WWPN 0x5001438001fff22c isp0: PortID 0x020e00 handle 0x4 role Initiator arrived WWNN 0x50014380022110c5 WWPN 0x50014380022110c4 isp0: PortID 0x021000 handle 0x5 role Initiator arrived WWNN 0x5001438001fff229 WWPN 0x5001438001fff228 isp0: PortID 0x021100 handle 0x6 role Target arrived at tgt 0 WWNN 0x50001fe150103510 WWPN 0x50001fe150103519 isp0: PortID 0x040100 handle 0x7 role Initiator arrived WWNN 0x5001438002211a6d WWPN 0x5001438002211a6c isp0: PortID 0x040200 handle 0x8 role Initiator arrived WWNN 0x5001438002211aa9 WWPN 0x5001438002211aa8 isp0: PortID 0x040800 handle 0x9 role Initiator arrived WWNN 0x5001438002211a99 WWPN 0x5001438002211a98 isp0: PortID 0x040e00 handle 0xa role Initiator arrived WWNN 0x5001438001fff265 WWPN 0x5001438001fff264 isp0: PortID 0x041100 handle 0xb role Target arrived at tgt 1 WWNN 0x50001fe150103510 WWPN 0x50001fe15010351c isp0: PortID 0x041300 handle 0xc role Initiator arrived WWNN 0x200000e08b8b962d WWPN 0x210000e08b8b962d isp0: PortID 0xfffffe handle 0x7fe role (none) stayed WWNN 0x100000051e092a7c WWPN 0x200100051e092a7c isp0: isp_kthread: FC state OK isp0: isp_kthread: releasing simq isp0: isp_kthread: sleep time 0 da0 at isp0 bus 0 target 0 lun 1 da0: Fixed Direct Access SCSI-5 device da0: 400.000MB/s transfers da0: Command Queueing Enabled da0: 51200MB (104857600 512 byte sectors: 255H 63S/T 6527C) da1 at isp0 bus 0 target 1 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 400.000MB/s transfers WWNN 0x5001438002211a1d WWPN 0x5001438002211a1c PortID 0x20300 da1: Command Queueing Enabled da1: 51200MB (104857600 512 byte sectors: 255H 63S/T 6527C) da2 at isp1 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-5 device da2: 400.000MB/s transfers da2: Command Queueing Enabled da2: 51200MB (104857600 512 byte sectors: 255H 63S/T 6527C) da3 at isp1 bus 0 target 1 lun 1 da3: Fixed Direct Access SCSI-5 device da3: 400.000MB/s transfers WWNN 0x5001438002211a1f WWPN 0x5001438002211a1e PortID 0x30300 da3: Command Queueing Enabled da3: 51200MB (104857600 512 byte sectors: 255H 63S/T 6527C) GEOM_MULTIPATH: adding da0 to bootsys/cdbc7869-2d76-11dd-8fe6-001e0bc7e1d0 GEOM_MULTIPATH: da0 now active path in bootsys SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! GEOM_MULTIPATH: adding da1 to bootsys/cdbc7869-2d76-11dd-8fe6-001e0bc7e1d0 GEOM_MULTIPATH: adding da2 to bootsys/cdbc7869-2d76-11dd-8fe6-001e0bc7e1d0 GEOM_MULTIPATH: adding da3 to bootsys/cdbc7869-2d76-11dd-8fe6-001e0bc7e1d0 Trying to mount root from ufs:/dev/multipath/bootsyss1a [... successful boot at this point ...] -= end -- From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 20:33:08 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A67BB106566B for ; Wed, 27 Aug 2008 20:33:08 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6AB8FC08 for ; Wed, 27 Aug 2008 20:33:08 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so49815rvf.43 for ; Wed, 27 Aug 2008 13:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XwkZxjhuyJSDBglTryKBT5NJblJRADmwoKB77dGyG5M=; b=Smfbuf3sz7MxE+V4tMNihSUUEkJjpL5bF0ouzO4vLG4/xaWetxljevufG6beV1XQli oFl3fWo8q1eb/BoQz8lVQJfDD5qcq91u+DETOevkLjWtk2JhPyTNsUFCpOrPl3d2xtrx xq4lnJxX67glxRfQ6E+E0iXS1IqwEmpyXABO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uYR1Im26EbIsjw6I8OR8/+yj7UlhiLexPwywFduvP2JfhzeuF8R59p+KK2UWHaTZKF J5sVdCOhYXQFSSlJlBQF6cdVUAE/0cBndObzSfQA6tmoeECh1J9/TMY3LLd9mmPF80QO Jrjc+BF7wjMRDgvlnxf17P+PHDR7Kj+kfQqCc= Received: by 10.141.82.20 with SMTP id j20mr250308rvl.234.1219869187915; Wed, 27 Aug 2008 13:33:07 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Wed, 27 Aug 2008 13:33:07 -0700 (PDT) Message-ID: <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> Date: Wed, 27 Aug 2008 16:33:07 -0400 From: "Alexander Sack" To: Ross In-Reply-To: <86689256.20080827112751@connection.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: Re[2]: isp(4) - kernel panic on initialization of driver 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, 27 Aug 2008 20:33:08 -0000 On Wed, Aug 27, 2008 at 11:27 AM, Ross wrote: > > AS> So one question I have is why doesn't the isp driver load the > AS> firmware in ispfw? [...clip...] By any chance do you have > AS> "hint.isp.0.fwload_disable" set? I'm not saying that will fix your > AS> problem but I just noticed this. Ok, I just wanted to make sure I wasn't going crazy! I've just patched the 6.x driver to load firmware again (without the use of the generic firmware driver which I believe came later). I still have to thoroughly test it. > The card came with 4.00.90 which is newer than the firmware included in > ispfw (4.00.20) - but to answer your question, yes, fwload_disable is > set for the cards. I believe that got set since there was some kind > of problem that we ran into at one point. I'll do some testing on > that. Please do but I think what you did is very reasonable. > AS> WARNING: this is pure speculation on my part from quickly looking at > AS> it. I'm just wondering if this is a bug in isp allowing the ASYNC > AS> events occuring before a complete attach has been performed. > > Apologies if it didn't come across in my previous message, that's > basically what I'm saying too. I have about a 50/50 chance of the > card booting successfully, and when it does, the output from the debug > lines is different, and it looks like the ASYNC event is executing > before it's time. (See the end of this message for the full output > from isp[01]: for a clean boot, since it's a long output.) Yea it looks like the loop down timer kthread gets started further down isp_attach() which I believe maybe the issue. I got to look at it some more. > AS> I'm assuming all you are doing is booting 7.0-RELEASE off the SAN? > > That is correct. We're just using the i386 image at the current time > (eventually going to amd64, but not now). It's been trimmed of the > fat, but nothing special/custom added in. Sure, thanks. > AS> As Scott asked, can you get a dump or a trace of the crash? > > See my other message to freebsd-scsi/Scott for that. Ummm, can you get more than what you posted? i.e. can you rebuild the kernel with options KDB options DDB which will enable the debugger. Then boot with a "-v" and when you get into a panic you should fall into the kernel debugger. At the prompt do a "t" and copy the output (you don't have to copy the addresses just the stack trace). I think I can imagine what it looks like but it would be better if you provided it. Another possibility is to obtain a dump: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN and post it. Thanks! -aps From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 27 22:20:56 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DAF01065678 for ; Wed, 27 Aug 2008 22:20:56 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1678FC18 for ; Wed, 27 Aug 2008 22:20:55 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so94990fgb.35 for ; Wed, 27 Aug 2008 15:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=HV5leQ9dMxa/jhdxA9Yy5UpEF1r0KYnaZ15gLsPYBzo=; b=Z3uWNDdkFoKoVpnUEH+X1Dpr0Ua21ABtlb+CJpeHFaxM46WoTJFwOhOECQ5gZxx2BV 4Epo869HSLGpXmZJYG15OPvQ9f8Mw0uh69CZubHakxYgihsChjoTHEISVpJ8BUSOcTut aQt+8NZzPH24HTfUBnq/d70ZC4Qdhj/Huv+YY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UiLMBxxjx8J50X1IWyShBby6g2JNjnejjxQorfnhjbtkQ0KftUXqjKzmw+ycBsCHjI lh6itKTUvJh5OfJPkb+iLEwY4N33Bm9XxwTRLNd4LwFTDFG1GpdrYCwwKV26XAHjFgod pbCN216vAoLcSajKURQtsPGjr1DhxtsIR70Gk= Received: by 10.180.241.3 with SMTP id o3mr659561bkh.29.1219875654884; Wed, 27 Aug 2008 15:20:54 -0700 (PDT) Received: by 10.210.34.1 with HTTP; Wed, 27 Aug 2008 15:20:54 -0700 (PDT) Message-ID: <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> Date: Wed, 27 Aug 2008 18:20:54 -0400 From: "Alexander Sack" To: "Fuujin Networks LLC" In-Reply-To: <48B4CF57.30603@fuujinnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B4CF57.30603@fuujinnetworks.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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, 27 Aug 2008 22:20:56 -0000 On Tue, Aug 26, 2008 at 11:51 PM, Fuujin Networks LLC wrote: > I've run into a snag with our SAN and I'm hoping someone out there can shed > some light on the glass, as it were. We're trying to use scsi_target mode > with a pair of QLogic ISP2310 2GB fibre-channel cards in a Point-to-Point > topology. These cards will NOT be part of a switch fabric. I started out > with a quad port card, and when I rescanned the SCSI bus on the initiating > end of the loop, the target machine tanked. > The filer dumps core, reboots, and reproduces the result faithfully. How about posting some stack traces, dmesg output, etc. etc. about how it tanks? Thanks! -aps From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 15:10:13 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34787106566C for ; Thu, 28 Aug 2008 15:10:13 +0000 (UTC) (envelope-from up@3.am) Received: from richard2.pil.net (mail.pil.net [207.7.198.3]) by mx1.freebsd.org (Postfix) with SMTP id CA9858FC16 for ; Thu, 28 Aug 2008 15:10:12 +0000 (UTC) (envelope-from up@3.am) Received: (qmail 48851 invoked from network); 28 Aug 2008 14:50:00 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by richard2.pil.net with SMTP; 28 Aug 2008 14:50:00 -0000 Date: Thu, 28 Aug 2008 10:50:00 -0400 (EDT) From: up@3.am X-X-Sender: up@richard2.pil.net To: freebsd-scsi@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Urgent: older server disk failed, need mirror replacement 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: Thu, 28 Aug 2008 15:10:13 -0000 Hi: Sorry for the hectic nature of this, but I just got a kernel notification (and confirmed using aaccli's disk list) that one of my RAID level 1 disks on one of my servers has died. The problem is, I'm not entirely sure exactly what replacement I should be ordering. Is there a command line utility that gives you the manufacturer's info (model no, part no) of the disk itself? I looked at some of the disk utilities in ports/systutilities and I'm not seeing anything. Here is what I think I know: IMB/Hitachi 72GB or 73GB 10k or 15k RPM U320 SCSI I built this server 3 or 4 years ago...the RAID adapter is a low profile Adaptec U320 RAID using the aac driver. Are the newer, SAS drives downward compatible with U320 adapters? Is it ok to mix and match, as long as the drives are close in storage capacity? What about mix and matching 10k and 15k rpm? Thanks in Advance! James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am ========================================================================= From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 16:23:44 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F902106566B for ; Thu, 28 Aug 2008 16:23:44 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 17BEA8FC15 for ; Thu, 28 Aug 2008 16:23:43 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 34C0071EFFF; Thu, 28 Aug 2008 12:06:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uOTJ6x-mfmP; Thu, 28 Aug 2008 12:06:30 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 1224A71EFFB; Thu, 28 Aug 2008 12:06:29 -0400 (EDT) Message-ID: <48B6CD05.40805@egr.msu.edu> Date: Thu, 28 Aug 2008 12:06:29 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.16 (X11/20080727) MIME-Version: 1.0 To: up@3.am References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: Urgent: older server disk failed, need mirror replacement 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: Thu, 28 Aug 2008 16:23:44 -0000 up@3.am wrote: > > Hi: > > Sorry for the hectic nature of this, but I just got a kernel > notification (and confirmed using aaccli's disk list) that one of my > RAID level 1 disks on one of my servers has died. The problem is, > I'm not entirely sure exactly what replacement I should be ordering. > Is there a command line utility that gives you the manufacturer's info > (model no, part no) of the disk itself? I looked at some of the disk > utilities in ports/systutilities and I'm not seeing anything. Here is > what I think I know: > > IMB/Hitachi 72GB or 73GB 10k or 15k RPM U320 SCSI > > I built this server 3 or 4 years ago...the RAID adapter is a low > profile Adaptec U320 RAID using the aac driver. Are the newer, SAS > drives downward compatible with U320 adapters? Is it ok to mix and > match, as long as the drives are close in storage capacity? What > about mix and matching 10k and 15k rpm? > > Thanks in Advance! > > James Smallacombe PlantageNet, Inc. CEO and Janitor arcconf GETCONFIG 1 PD or probably in your case: aaccli GETCONFIG 1 PD should return output that includes the model number: Device #6 Device is a Hard drive State : Online Supported : Yes Transfer Speed : SAS 3.0 Gb/s Reported Channel,Device : 0,6 Reported Location : Connector 1, Device 2 Vendor : SEAGATE Model : ST914602SSUN146G Firmware : 0603 World-wide name : 5000C500092888A0 Size : 140009 MB Write Cache : Disabled (write-through) FRU : None S.M.A.R.T. : No From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 16:53:53 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59114106566B for ; Thu, 28 Aug 2008 16:53:53 +0000 (UTC) (envelope-from up@3.am) Received: from richard2.pil.net (mail.pil.net [207.7.198.3]) by mx1.freebsd.org (Postfix) with SMTP id 0C87E8FC08 for ; Thu, 28 Aug 2008 16:53:52 +0000 (UTC) (envelope-from up@3.am) Received: (qmail 10211 invoked from network); 28 Aug 2008 16:53:51 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by richard2.pil.net with SMTP; 28 Aug 2008 16:53:51 -0000 Date: Thu, 28 Aug 2008 12:53:51 -0400 (EDT) From: up@3.am X-X-Sender: up@richard2.pil.net To: freebsd-scsi@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: Urgent: older server disk failed, need mirror replacement 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: Thu, 28 Aug 2008 16:53:53 -0000 That did the trick...turns out it's a 10k RPM, I just ordered a replacement for $44, plus $45 to ship it overnight, I must have spent nearly 10 times that much on the drive back in the day... On Thu, 28 Aug 2008, jason kawaja wrote: > try 'camcontrol devlist' > > good luck. > > On Aug 28, 2008, at 10:50 AM, up@3.am wrote: > >> >> Hi: >> >> Sorry for the hectic nature of this, but I just got a kernel notification >> (and confirmed using aaccli's disk list) that one of my RAID level 1 disks >> on one of my servers has died. The problem is, I'm not entirely sure >> exactly what replacement I should be ordering. Is there a command line >> utility that gives you the manufacturer's info (model no, part no) of the >> disk itself? I looked at some of the disk utilities in ports/systutilities >> and I'm not seeing anything. Here is what I think I know: >> >> IMB/Hitachi 72GB or 73GB 10k or 15k RPM U320 SCSI >> >> I built this server 3 or 4 years ago...the RAID adapter is a low profile >> Adaptec U320 RAID using the aac driver. Are the newer, SAS drives downward >> compatible with U320 adapters? Is it ok to mix and match, as long as the >> drives are close in storage capacity? What about mix and matching 10k and >> 15k rpm? >> >> Thanks in Advance! >> >> James Smallacombe PlantageNet, Inc. CEO and Janitor >> up@3.am >> http://3.am >> ========================================================================= >> _______________________________________________ >> freebsd-scsi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > > > -- > Jason Kawaja, 2-4568 > IT Expert, UF Dept of ECE > > > > James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am ========================================================================= From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 17:05:03 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5DA110656BE for ; Thu, 28 Aug 2008 17:05:03 +0000 (UTC) (envelope-from freebsd-scsi@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 221E08FC23 for ; Thu, 28 Aug 2008 17:05:03 +0000 (UTC) (envelope-from freebsd-scsi@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KYk1c-0001ur-O6 for freebsd-scsi@freebsd.org; Thu, 28 Aug 2008 16:07:08 +0000 Received: from 78-0-86-69.adsl.net.t-com.hr ([78.0.86.69]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Aug 2008 16:07:08 +0000 Received: from ivoras by 78-0-86-69.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Aug 2008 16:07:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-scsi@freebsd.org From: Ivan Voras Date: Thu, 28 Aug 2008 18:06:58 +0200 Lines: 58 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58398C1E7634D6CEFF1119BB" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-86-69.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: Urgent: older server disk failed, need mirror replacement 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: Thu, 28 Aug 2008 17:05:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58398C1E7634D6CEFF1119BB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable up@3.am wrote: >=20 > Hi: >=20 > Sorry for the hectic nature of this, but I just got a kernel > notification (and confirmed using aaccli's disk list) that one of my > RAID level 1 disks on one of my servers has died. The problem is, I'm= > not entirely sure exactly what replacement I should be ordering. Is > there a command line utility that gives you the manufacturer's info > (model no, part no) of the disk itself? I looked at some of the disk > utilities in ports/systutilities and I'm not seeing anything. Here is > what I think I know: >=20 > IMB/Hitachi 72GB or 73GB 10k or 15k RPM U320 SCSI I think you should use arcconf (from ports) to find out your drive models and then look them up in Google or IBM's support pages. See this for example: http://www.clarkconnect.com/forums/showthreaded.php?Number=3D104029 > I built this server 3 or 4 years ago...the RAID adapter is a low profil= e > Adaptec U320 RAID using the aac driver. Are the newer, SAS drives > downward compatible with U320 adapters? =20 No, SCSI and SAS connectors are not compatible. You can still buy SCSI drives. > Is it ok to mix and match, as > long as the drives are close in storage capacity? What about mix and > matching 10k and 15k rpm? As long as your new drive is larger or faster than the old one, it should be fine. --------------enig58398C1E7634D6CEFF1119BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki2zSIACgkQldnAQVacBchXrgCgsULzAhkYkhcj2Jx6t3C/2h1b 1PMAnilNLubgsShK4W8NugE03PShW7Hh =wYEl -----END PGP SIGNATURE----- --------------enig58398C1E7634D6CEFF1119BB-- From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 17:34:19 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DB821065683 for ; Thu, 28 Aug 2008 17:34:19 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 30E7A8FC17 for ; Thu, 28 Aug 2008 17:34:19 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 425A51A9171 for ; Thu, 28 Aug 2008 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHUI+plGCU6Z for ; Thu, 28 Aug 2008 10:24:46 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id D99C91A90BA for ; Thu, 28 Aug 2008 10:24:46 -0700 (PDT) Message-ID: <48B6E19A.7050603@miralink.com> Date: Thu, 28 Aug 2008 10:34:18 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ISP] QLA2432 Target Mode Broken 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: Thu, 28 Aug 2008 17:34:19 -0000 I tried putting a 2432 into target mode this week and noted that the system threw a pretty nice panic and thought I would post the output here. Reviewing the 4G documentation from Qlogic, it looks like they've substantially changed the target mode interface, so I'm not surprised that there's some work to do. If anyone has any patches they'd like me to test, I'm open to integration: isp0: port 0x2000-0x20ff mem 0xe8300000-0xe8303fff irq 16 at device 0.0 on pci4 isp0: setting role to 0x0 for unit 0 isp0: [GIANT-LOCKED] isp0: Polled Mailbox Command (0x8) Timeout (100000us) isp0: Board Type 2422, Chip Revision 0x2, loaded F/W Revision 4.0.20 isp1: port 0x2400-0x24ff mem 0xe8304000-0xe8307fff irq 17 at device 0.1 on pci4 isp1: setting role to 0x2 for unit 1 isp1: [GIANT-LOCKED] isp1: Polled Mailbox Command (0x8) Timeout (100000us) isp1: Board Type 2422, Chip Revision 0x2, loaded F/W Revision 4.0.20 ... isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.20 isp0: Board Type 2422, Chip Revision 0x2, loaded F/W Revision 4.0.20 (odbp0:isp0:0:4:0): Target Mode Enabled (odbp0:isp0:0:4:0): ENABLE LUN returned 0x0 (lun 0) (odbp0:isp0:0:4:0): enable lun CCB rejected, status 0x4 enable lun failed, status 0x4 targinit: targenlun failed with status 0x4 Aug 28 02:06:46 kernel: B-Srch failed to find head/tail Aug 28 02:06:46 kernel: Loop counter at max, aborting. Aug 28 02:06:46 kernel: Targinit was not successfull, TheSoftc == NULL isp0: target notify code 0x1007 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0546709 stack pointer = 0x28:0xe7a2fb90 frame pointer = 0x28:0xe7a2fb90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 21 (irq16: bge0 isp0++) [db> trace Tracing pid 21 tid 100023 td 0xc651e780 isp_get_hdr(c6544000,0,e7a2fbe4) at isp_get_hdr+0x9 isp_intr(c6544000,801d,0,0) at isp_intr+0x264 isp_pci_intr(c6544000) at isp_pci_intr+0x6f ithread_execute_handlers(c651d430,c644e500) at ithread_execute_handlers+0xe6 ithread_loop(c6542070,e7a2fd38,c6542070,c05e1f68,0,...) at ithread_loop+0x66 fork_exit(c05e1f68,c6542070,e7a2fd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7a2fd6c, ebp = 0 --- -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 17:59:11 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB46106564A for ; Thu, 28 Aug 2008 17:59:11 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id D0C618FC21 for ; Thu, 28 Aug 2008 17:59:10 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so638765rvf.43 for ; Thu, 28 Aug 2008 10:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xsWTCaK8ZHYEizyTUjkS1sGxm9oMyNB77pokwPv83WQ=; b=n6hiQ97Ne+0FO4GlwoXhk16uS2sRCdKDSyRgyqWKEpNBAtKGGpHzg2Ltw+TQGzrfSp w/lCNIkvWsHLd6iK9IoqI8markM1TbunOD+2KvJXpN+f1eI562AJh/MuGO54+U7xUbMr 6cfyZvgcAE+fZr4NQxZJFvdoXDMXqbRib6h9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=T0P5U3EIH/Ww2HI5lYcFC1S2nIBYy9XH0PQ3L2X95t++0st8N0bfslynpu/TM+zBLc pmuw6vQeanTVggLj7rlaHZCNeVhXPCmIfZaZ016u0StLtcqKRobj31dEzJPJubA+D2Lp OLlY2+LYqg+lBeNb+5yoI84ERKWxjPaBwtGvY= Received: by 10.140.207.2 with SMTP id e2mr922758rvg.187.1219946350263; Thu, 28 Aug 2008 10:59:10 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Thu, 28 Aug 2008 10:59:10 -0700 (PDT) Message-ID: <3c0b01820808281059k3c33e352g6be72f02817e8e6a@mail.gmail.com> Date: Thu, 28 Aug 2008 13:59:10 -0400 From: "Alexander Sack" To: "Sean Bruno" In-Reply-To: <48B6E19A.7050603@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B6E19A.7050603@miralink.com> Cc: freebsd-scsi@freebsd.org Subject: Re: [ISP] QLA2432 Target Mode Broken 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: Thu, 28 Aug 2008 17:59:11 -0000 On Thu, Aug 28, 2008 at 1:34 PM, Sean Bruno wrote: > I tried putting a 2432 into target mode this week and noted that the system > threw a pretty nice panic and thought I would post the output here. > Reviewing the 4G documentation from Qlogic, it looks like they've > substantially changed the target mode interface, so I'm not surprised that > there's some work to do. If anyone has any patches they'd like me to test, > I'm open to integration: Did you rebuild the isp driver with -DISP_TARGET_MODE defined? I only mention this because the output below seems like you twiddled the "role" hint instead of actually recompile the driver? -aps From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 18:31:57 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4597C1065681 for ; Thu, 28 Aug 2008 18:31:57 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 1F56A8FC20 for ; Thu, 28 Aug 2008 18:31:56 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 9DBA61A8EF2; Thu, 28 Aug 2008 11:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0fL1EzErin9; Thu, 28 Aug 2008 11:22:22 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 611EC1A879B; Thu, 28 Aug 2008 11:22:22 -0700 (PDT) Message-ID: <48B6EF1A.1040805@miralink.com> Date: Thu, 28 Aug 2008 11:31:54 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Alexander Sack References: <48B6E19A.7050603@miralink.com> <3c0b01820808281059k3c33e352g6be72f02817e8e6a@mail.gmail.com> In-Reply-To: <3c0b01820808281059k3c33e352g6be72f02817e8e6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: [ISP] QLA2432 Target Mode Broken 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: Thu, 28 Aug 2008 18:31:57 -0000 Alexander Sack wrote: > On Thu, Aug 28, 2008 at 1:34 PM, Sean Bruno wrote: > >> I tried putting a 2432 into target mode this week and noted that the system >> threw a pretty nice panic and thought I would post the output here. >> Reviewing the 4G documentation from Qlogic, it looks like they've >> substantially changed the target mode interface, so I'm not surprised that >> there's some work to do. If anyone has any patches they'd like me to test, >> I'm open to integration: >> > > Did you rebuild the isp driver with -DISP_TARGET_MODE defined? I only > mention this because the output below seems like you twiddled the > "role" hint instead of actually recompile the driver? > > -aps > Ah, yes, that's a little magic I was trying ... sorry about that. Yes, I definitely compiled with ISP_TARGET_MODE defined. :) -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 21:59:55 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 553331065676 for ; Thu, 28 Aug 2008 21:59:55 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 16DF58FC1B for ; Thu, 28 Aug 2008 21:59:55 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so753664rvf.43 for ; Thu, 28 Aug 2008 14:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6TS132Z3agtzwZA29kiwXiLFtNUnndi9hL/bPBdllc0=; b=VRLeN2vbiE1v+xI3lbAs/LXYVwa+v4iBgk9QAVs3jpa3UhWwWO2MHZlrpTd7vZQGR/ ZG6HZO3dxeBFPWewbGALaUpefJ90pedOtk54JzwS8b/ofbcOFTMC5DXlJ+E7zxfAejYK +6uAn2MpN+9H4+GmwbJqFCGiiKZThUlkn/PKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gbUu+zZTy0T75k2KVRzX3PX43e/FIZXZBI/dfg0OSl4OyUEG8VF1gNivQrLp2iut/b ntTGA/y2Wm4GkRKULJPoDAENVgS68EKPiO/QUm5PD71bqL0kOULiGuXgi1fjAzaQZFWA 832xNY35tkf8gZgkL3JW3HyQNtmHOrFg1KCkk= Received: by 10.141.168.7 with SMTP id v7mr1068649rvo.95.1219960794649; Thu, 28 Aug 2008 14:59:54 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Thu, 28 Aug 2008 14:59:54 -0700 (PDT) Message-ID: <3c0b01820808281459r4990ec4exdb2b4906b4b711f6@mail.gmail.com> Date: Thu, 28 Aug 2008 17:59:54 -0400 From: "Alexander Sack" To: Ross In-Reply-To: <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Re[2]: isp(4) - kernel panic on initialization of driver 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: Thu, 28 Aug 2008 21:59:55 -0000 On Wed, Aug 27, 2008 at 4:33 PM, Alexander Sack wrote: > On Wed, Aug 27, 2008 at 11:27 AM, Ross wrote: >> Apologies if it didn't come across in my previous message, that's >> basically what I'm saying too. I have about a 50/50 chance of the >> card booting successfully, and when it does, the output from the debug >> lines is different, and it looks like the ASYNC event is executing >> before it's time. (See the end of this message for the full output >> from isp[01]: for a clean boot, since it's a long output.) > > Yea it looks like the loop down timer kthread gets started further > down isp_attach() which I believe maybe the issue. I got to look at > it some more. Ross, can you please try this patch? I don't have access to the external SAN right now so if this blows up, I'm apologize in advance. I'm not 100% sure about what is exactly going on without my hardware in front of me. However, it would seem that the LIP events that are enabled in isp_init() are coming in before the isp_ldt (loop down timer) and other things are initialized. I believe interrupts should be disabled until the intrhook gets called before root is mounted. That's what I *think* the author intended. Can you try the following small patch: --- isp_freebsd.c.0 2008-08-28 13:54:27.000000000 -0400 +++ isp_freebsd.c 2008-08-28 13:48:45.000000000 -0400 @@ -231,7 +231,6 @@ if (isp->isp_role != ISP_ROLE_NONE) { isp->isp_state = ISP_RUNSTATE; - ISP_ENABLE_INTS(isp); } if (isplist == NULL) { isplist = isp; I just don't see why ISP_ENABLE_INTS should be called since isp_intr_enable() has been established as the config_intrhook to be called before root mounts. One of the things I noticed is that the isp driver actually handles LIP events as they come in INSTEAD of first doing all the loop/fabric enumeration up front (during attach time which is what other OSes I believe do). This means when the card finally does come up and we are ready to go, it gets very noisy very fast until the fabric settles down. Hence all those portdb change messages during normal bootup! Give this a shot and let me know (either patch or edit the file, its one line, rebuild, reboot etc.). I tried it on my card with no devices attached so I know it works on my system! j/k Again, I'm stabbing in the dark a little but I'm curious if this prevents the panic. -aps From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 28 22:25:55 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1B3E10656D1 for ; Thu, 28 Aug 2008 22:25:55 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id B2C808FC13 for ; Thu, 28 Aug 2008 22:25:55 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTP id 1A7AB8FC2F; Thu, 28 Aug 2008 17:25:55 -0500 (CDT) Message-ID: <48B733CF.5000105@fuujinnetworks.com> Date: Thu, 28 Aug 2008 17:25:03 -0600 From: Fuujin Networks LLC User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Alexander Sack References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> In-Reply-To: <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Thu, 28 Aug 2008 22:25:56 -0000 Alex: Thanks for your interest! Hope the following is of use to you. If you would like, I can put the dump file (~60MB) in folder accessible via the web. Here's the page fault: [snip] (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc48a4a00 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x2825c7d0) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc48a4900 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x28259e80) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc48a4800 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x2825c860) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc48a4700 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x28259f20) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc48a4600 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x2825c8f0) (targ0:isp0:0:0:0): targdone 0xc48a4700 (targ0:isp0:0:0:0): targread (targ0:isp0:0:0:0): targread ccb 0xc48a4700 (0x28259f20) (targ0:isp0:0:0:0): targreturnccb 0xc48a4700 cam_debug: targfreeccb descr 0xc48a2680 and cam_debug: freeing ccb 0xc48a4700 (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): Sending queued ccb 0x933 (0x2825e0c0) (targ0:isp0:0:0:0): targstart 0xc4947c00 (targ0:isp0:0:0:0): sendccb 0xc4947c00 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05d3286 stack pointer = 0x28:0xe68e690c frame pointer = 0x28:0xe68e695c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 847 (scsi_target) trap number = 12 panic: page fault cpuid = 1 Uptime: 12m52s Physical memory: 1011 MB Dumping 57 MB:ATIO/INOT (0x28243670) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc4878700 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x28244c00) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc4878600 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x28243700) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc487c900 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x28244ca0) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc487c800 (targ0:isp0:0:0:0): Sent ATIO/INOT (0x28243790) (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): getccb 0xc487c700 [snip] Here are the relevant lines in the kernel. Everything else is stock. [snip] device isp # Qlogic family device ispfw # Firmware for QLogic HBAs options ISP_TARGET_MODE # for ISP cards in target mode device targ # SCSI Target device device targbh # SCSI Target Black Hole options CAMDEBUG options VFS_AIO [snip] Here is the relevant output from dmseg: [snip] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set isp0: port 0xc000-0xc0ff mem 0xe7103000-0xe7103fff irq 16 at device 8.0 on pci0 firmware_get: failed to load firmware image isp_2300_it isp0: [ITHREAD] isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 isp0: target notify code 0x1007 isp0: target notify code 0x1007 isp0: target notify code 0x1006 isp0: target notify code 0x1007 isp0: target notify code 0x1008 (targbh0:isp0:0:-1:-1): Target Mode Enabled isp0: target notify code 0x1007 isp0: target notify code 0x1007 isp0: target notify code 0x1006 isp0: target notify code 0x1007 isp0: target notify code 0x1006 isp0: target notify code 0x1007 [snip] I'm a bit puzzled by the firmware_get failed line above. I suspect this may be the problem, but I have not been able to resolve it. I've tried disabling the bios on the FC cards, as well as messing with almost every other conceivable option, but the same error appears. Thoughts? Erich M. Jenkins Fuujin Networks, LLC PO Box 792 Brainerd, MN 56401 (p) 218-824-5038 (f) 218-824-7516 "You should never, never doubt what no one is sure about." -- Gene Wilder Alexander Sack wrote: > On Tue, Aug 26, 2008 at 11:51 PM, Fuujin Networks LLC > wrote: >> I've run into a snag with our SAN and I'm hoping someone out there can shed >> some light on the glass, as it were. We're trying to use scsi_target mode >> with a pair of QLogic ISP2310 2GB fibre-channel cards in a Point-to-Point >> topology. These cards will NOT be part of a switch fabric. I started out >> with a quad port card, and when I rescanned the SCSI bus on the initiating >> end of the loop, the target machine tanked. >> The filer dumps core, reboots, and reproduces the result faithfully. > > How about posting some stack traces, dmesg output, etc. etc. about how it tanks? > > Thanks! > > -aps From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 14:36:22 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7DA91065695 for ; Fri, 29 Aug 2008 14:36:22 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail2.connection.ca (nc-tor-mail2.connection.ca [205.207.122.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5FA8FC1D for ; Fri, 29 Aug 2008 14:36:22 +0000 (UTC) (envelope-from westr@connection.ca) Received: from localhost (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail2.connection.ca (Postfix) with ESMTP id D3EFF74E5B5 for ; Fri, 29 Aug 2008 10:36:21 -0400 (EDT) Date: Fri, 29 Aug 2008 10:36:21 -0400 From: Ross Organization: Network Connection X-Priority: 3 (Normal) Message-ID: <34442830.20080829103621@connection.ca> To: freebsd-scsi@freebsd.org In-Reply-To: <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re[4]: isp(4) - kernel panic on initialization of driver X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ross List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 14:36:22 -0000 AS> which will enable the debugger. Then boot with a "-v" and when you AS> get into a panic you should fall into the kernel debugger. At the AS> prompt do a "t" and copy the output (you don't have to copy the AS> addresses just the stack trace). I think I can imagine what it looks AS> like but it would be better if you provided it. Here you go - a rather large pain in the butt, since HP's ilom doesn't allow for cut'n'paste from the virtual console (even in serial mode). Ugh. Hope that it helps some more. This kernel has been built using the 1 line patch you gave me (removing the ISP_ENABLE_INTS call). Cheers, Ross. -= ...[clipped]... stack pointer = 0x20:0xc0af63cc frame pointer = 0x20:0xc0af63cc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at xpt_freeze_simq+0x6: movl 0x58(%ecx),%eax db> t Tracing pid 0 tid 0 td 0xc079fd30 xpt_freeze_simq(0,1,c06f7a16,c06f800f,c06f800f,...) at xpt_freeze_simq+0x6 isp_freeze_loopdown(c81d0e00,2,c06f800f,0,c0cf1f6c,...) at isp_freeze_loopdown+0x42 isp_async(c81d0e00,6,0,14e1,2001d5c3,...) at isp_async+0xa72 isp_intr(c81d0e00,8012,1,8014,c0af6718,...) at isp_intr+0xbc7 isp_mbox_wait_complete(c81d0e00,c0af67e8,50000000,0,8,...) at isp_mbox_wait_complete+0x120 isp_mboxcmd(c0af67e8,24,40000000,c827c380,c0af67cc,...) at isp_mboxcmd+0x1ef isp_reset(c81d0e00,c827c380,e,c0af6880,c02d6ce0,...) at isp_reset+0xe9 isp_pci_attach(c827c380,c827c380,ffffffff,c0708a0a,80000000,...) at isp_pci_attach+0x1899 device_attach(c827c380,c827c380,1,c827c380,c8263980,...) at device_attach+0x36f device_probe_and_attach(c827c380,c8266800,c0af6944,c08b13a1,c8263980,...) at device_probe_and_attach+0xdd bus_generic_attach(c8263980,c816c600,1,c08b0e80,c8263980,...) at bus_generic_attach+0x19 ...[much more clipped]... -= If any number seems 'off', let me know, as it could be my typing skills. -- From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 15:22:26 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1DB41065672 for ; Fri, 29 Aug 2008 15:22:25 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6C68FC14 for ; Fri, 29 Aug 2008 15:22:25 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1214759rvf.43 for ; Fri, 29 Aug 2008 08:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FlqD8TD3v40mqL/EKTmwGl7pF2qHEtdBO7r7RX5NROg=; b=pTDvCDOU9/ypjjEwmrPVphjjIUEzmT6g/cnP2KXSCq9ZyHZ4zwS5I8RM6S9xdZIyds hXcfsTl04JfvdYhrWQq25X/qPomLdcnfd7dIUOerbEVmlYwGaacTYEKKAUkEMd6NO9lI wwv3Blg8cWsOsltjriEvButXt7LFoDkeQmWdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=nwgu6V/uiXadJp+iXP0JrAhGvJL0c7B2WYY4rRayVUVdob3gMvohhjzKJqf9+cRvaU mbxtOuhXCAV0r565PbK5iaTfoLKH16r3IT4rpHAxF9NaCXBqq99Pr39dLTqPUqE+RkxR 9WkXWPVkHTaU4P/wg3tODPmeKCr3v4D7A6Qwo= Received: by 10.141.128.19 with SMTP id f19mr1580721rvn.107.1220023345078; Fri, 29 Aug 2008 08:22:25 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Fri, 29 Aug 2008 08:22:25 -0700 (PDT) Message-ID: <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> Date: Fri, 29 Aug 2008 11:22:25 -0400 From: "Alexander Sack" To: Ross In-Reply-To: <34442830.20080829103621@connection.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> <34442830.20080829103621@connection.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: Re[4]: isp(4) - kernel panic on initialization of driver 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: Fri, 29 Aug 2008 15:22:26 -0000 On Fri, Aug 29, 2008 at 10:36 AM, Ross wrote: > > AS> which will enable the debugger. Then boot with a "-v" and when you > AS> get into a panic you should fall into the kernel debugger. At the > AS> prompt do a "t" and copy the output (you don't have to copy the > AS> addresses just the stack trace). I think I can imagine what it looks > AS> like but it would be better if you provided it. > > Here you go - a rather large pain in the butt, since HP's ilom doesn't > allow for cut'n'paste from the virtual console (even in serial mode). > Ugh. Hope that it helps some more. > > This kernel has been built using the 1 line patch you gave me > (removing the ISP_ENABLE_INTS call). Thanks Ross. Unfortunately, seems like your problem is even before we get to isp_attach()! > -= > ...[clipped]... > stack pointer = 0x20:0xc0af63cc > frame pointer = 0x20:0xc0af63cc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at xpt_freeze_simq+0x6: movl 0x58(%ecx),%eax > db> t > Tracing pid 0 tid 0 td 0xc079fd30 > xpt_freeze_simq(0,1,c06f7a16,c06f800f,c06f800f,...) at xpt_freeze_simq+0x6 > isp_freeze_loopdown(c81d0e00,2,c06f800f,0,c0cf1f6c,...) at isp_freeze_loopdown+0x42 > isp_async(c81d0e00,6,0,14e1,2001d5c3,...) at isp_async+0xa72 > isp_intr(c81d0e00,8012,1,8014,c0af6718,...) at isp_intr+0xbc7 > isp_mbox_wait_complete(c81d0e00,c0af67e8,50000000,0,8,...) at isp_mbox_wait_complete+0x120 > isp_mboxcmd(c0af67e8,24,40000000,c827c380,c0af67cc,...) at isp_mboxcmd+0x1ef > isp_reset(c81d0e00,c827c380,e,c0af6880,c02d6ce0,...) at isp_reset+0xe9 > isp_pci_attach(c827c380,c827c380,ffffffff,c0708a0a,80000000,...) at isp_pci_attach+0x1899 > device_attach(c827c380,c827c380,1,c827c380,c8263980,...) at device_attach+0x36f > device_probe_and_attach(c827c380,c8266800,c0af6944,c08b13a1,c8263980,...) at device_probe_and_attach+0xdd > bus_generic_attach(c8263980,c816c600,1,c08b0e80,c8263980,...) at bus_generic_attach+0x19 > ...[much more clipped]... > -= > > If any number seems 'off', let me know, as it could be my typing > skills. Don't worry about that Ross. Just the stack trace of functions is very enlightening! Looks like you got to isp_reset() before things screwed up. The issue is the CAM stuff is not initialized until isp_attach() I believe so that's why things are screwy (I don't think there is a simq allocated let alone freeze at this point). Give me a sec to look a this some more....bottom line is isp should not be servicing async interrupts until its absolutely ready! -aps From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 16:14:03 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFC5F1065679 for ; Fri, 29 Aug 2008 16:14:03 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE098FC08 for ; Fri, 29 Aug 2008 16:14:03 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1238923rvf.43 for ; Fri, 29 Aug 2008 09:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pbnUQof1K6BftnJafoC5Nn8XkEaqG5sB9GepVy/Ayq8=; b=O0GnadM3oB+S9awhVvjSY6VvATxNnWuFmPFY6SK9OT4JqgZzNr853DuuGNjf7C6BoC nSuBpDp02D3fZZ1LrAMv81fw4wX6gtKueCrRsW2p6X6x/nJhwwWlMzTdHbwnPkVvlgKW QkFcRvprJHb5+d+i7o3b+zsNGWayveNqRZ0mQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=B84gIFbN2siPJxxblw+5sKYwIjeiPpPJulUWHFWsqiEud9Gt2nkvzcFwy+jEo5O+lH t9PLHEwC+XCs441Xc00ZxQ+wnr6BL+82+nZGl/+roQWNqrVl7ND1SKmnms+GGrsw7BOW WpXJmqc4SskTkdvzM57PSXvPMHHOfG2V/O1d8= Received: by 10.140.201.1 with SMTP id y1mr1588330rvf.246.1220026443043; Fri, 29 Aug 2008 09:14:03 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Fri, 29 Aug 2008 09:14:03 -0700 (PDT) Message-ID: <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> Date: Fri, 29 Aug 2008 12:14:03 -0400 From: "Alexander Sack" To: "Fuujin Networks LLC" In-Reply-To: <48B733CF.5000105@fuujinnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Fri, 29 Aug 2008 16:14:03 -0000 On Thu, Aug 28, 2008 at 7:25 PM, Fuujin Networks LLC wrote: > > [snip] > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > isp0: port 0xc000-0xc0ff mem > 0xe7103000-0xe7103fff irq 16 at device 8.0 on pci0 > firmware_get: failed to load firmware image isp_2300_it > isp0: [ITHREAD] > isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 > isp0: target notify code 0x1007 > isp0: target notify code 0x1007 > isp0: target notify code 0x1006 > isp0: target notify code 0x1007 > isp0: target notify code 0x1008 > (targbh0:isp0:0:-1:-1): Target Mode Enabled > isp0: target notify code 0x1007 > isp0: target notify code 0x1007 > isp0: target notify code 0x1006 > isp0: target notify code 0x1007 > isp0: target notify code 0x1006 > isp0: target notify code 0x1007 > [snip] > > I'm a bit puzzled by the firmware_get failed line above. I suspect this may > be the problem, but I have not been able to resolve it. I've tried disabling > the bios on the FC cards, as well as messing with almost every other > conceivable option, but the same error appears. Thoughts? Yes, its a bug in the ISP driver. If you are in target mode, it tries to load the isp_XXX_it version of the RISC code. I *think* the old SCSI cards had two separate firmwares for target and initiator modes (currently if you look at ispfw, there is the 1040, 1080, and 12160_it firmwares). Try this patch: --- isp_pci.c 2008-08-29 07:58:08.000000000 -0400 +++ isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 @@ -1039,7 +1039,7 @@ } isp->isp_osinfo.fw = NULL; - if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { + if (isp->isp_role & ISP_ROLE_TARGET) { snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); isp->isp_osinfo.fw = firmware_get(fwname); } That will fix the above error. The bad news is that this won't fix your problem since you DID load the 3.3.19 firmware since the next line will get the isp_2300 firmware and things will proceed normally down in isp_reset() (where the load actually happens!). So you really need to enable: options DDB options KDB and get a stack trace so when the machine panics you can do a "bt" and print the output (forget about the addresses, just the function calls). Also make sure the BIOS is configured to enable target mode (I forgot if the 2300 had a separate BIOS tunable for that). Let us know, -aps From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 16:15:27 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56ADC1065674 for ; Fri, 29 Aug 2008 16:15:27 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 237318FC1B for ; Fri, 29 Aug 2008 16:15:26 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1239453rvf.43 for ; Fri, 29 Aug 2008 09:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fyadFowZ6V4g75VP26ExLha/YRIVJduJN+/YnVTpE44=; b=tPoAxQpKUYq1eonbMQLAXQGLL/IQfu+qdgWuAZrfKFLMZPHNkG4WG+uCSgukyGu1es 0+CcYc2TX8mbfW1aK/sQmQsFluIcCO3Rkcp4Jf5fIiijt9UX5Nrf6N6F7FLKPhj3XsKZ AfvvVrwPjG0BNVwJYg5KNWZhxJRW5hw0yUUE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sUiOIJ5F95Om3JQ0ExYgKU+P21PwFOlTkotNX5ndHxuj1GTBdlq+SUO+/NbQl+8gSi vd2mfMPWgvEtLij6gBTBfv7vKoyiT8TennuGz9hIIMW+w4NNQfpVRyOQGsS5huA5m4rc LxMbsqp1UJxNL47MO56vMdy/1FFqWhQQ8i8no= Received: by 10.140.172.19 with SMTP id u19mr1627881rve.31.1220026526606; Fri, 29 Aug 2008 09:15:26 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Fri, 29 Aug 2008 09:15:26 -0700 (PDT) Message-ID: <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> Date: Fri, 29 Aug 2008 12:15:26 -0400 From: "Alexander Sack" To: "Fuujin Networks LLC" In-Reply-To: <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Fri, 29 Aug 2008 16:15:27 -0000 On Fri, Aug 29, 2008 at 12:14 PM, Alexander Sack wrote: > On Thu, Aug 28, 2008 at 7:25 PM, Fuujin Networks LLC > wrote: >> >> [snip] >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> ioapic0: Changing APIC ID to 2 >> ioapic0 irqs 0-23 on motherboard >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> isp0: port 0xc000-0xc0ff mem >> 0xe7103000-0xe7103fff irq 16 at device 8.0 on pci0 >> firmware_get: failed to load firmware image isp_2300_it >> isp0: [ITHREAD] >> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1006 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1008 >> (targbh0:isp0:0:-1:-1): Target Mode Enabled >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1006 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1006 >> isp0: target notify code 0x1007 >> [snip] >> >> I'm a bit puzzled by the firmware_get failed line above. I suspect this may >> be the problem, but I have not been able to resolve it. I've tried disabling >> the bios on the FC cards, as well as messing with almost every other >> conceivable option, but the same error appears. Thoughts? > > Yes, its a bug in the ISP driver. If you are in target mode, it tries > to load the isp_XXX_it version of the RISC code. I *think* the old > SCSI cards had two separate firmwares for target and initiator modes > (currently if you look at ispfw, there is the 1040, 1080, and 12160_it > firmwares). > > Try this patch: > > --- isp_pci.c 2008-08-29 07:58:08.000000000 -0400 > +++ isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 > @@ -1039,7 +1039,7 @@ > } > > isp->isp_osinfo.fw = NULL; > - if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { > + if (isp->isp_role & ISP_ROLE_TARGET) { > snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); > isp->isp_osinfo.fw = firmware_get(fwname); > } Whoops! Its reversed! --- isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 +++ isp_pci.c 2008-08-29 07:58:08.000000000 -0400 @@ -1039,7 +1039,7 @@ } isp->isp_osinfo.fw = NULL; - if (isp->isp_role & ISP_ROLE_TARGET) { + if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); isp->isp_osinfo.fw = firmware_get(fwname); } Sorry about that! -aps From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 16:51:55 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8073A1065673 for ; Fri, 29 Aug 2008 16:51:55 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA098FC18 for ; Fri, 29 Aug 2008 16:51:55 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1255260rvf.43 for ; Fri, 29 Aug 2008 09:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EuRdxL750kPVTG/CKRjRN2aRMbE5GogRf1b9uwfmCV4=; b=ZUoXyMhGcjtrNthMQmmHCrE5Wvqq/2ZUp6XN4ye+mhaakwZaN+vQ8+98t31LF00XtV jbnnWL+9yIX30Ud5ofGrBaYU2xgR0KP9+IXu+2NixvQMXqSI1EffJJwQ6IKuJ981fqD+ E2GKl63G5qpd37qvDZp1/dKVvEX824wva/utE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bJaGN4VGG+lRh0Stu+Xc9DXhPkPbjgGoRiAl36s3gW8kRN2l4Q+0jstOxhIiXI5tFJ MZjAj+/Mji/8KDREHPeqAjl+Hj3t6s9fVu2Sezdg3C8lGPfteTYZCdJUmADsbB8B+Rxr 8yaCHrNnN0v88dMn9FIoCQkMWH3VWWLwlUgJk= Received: by 10.140.200.16 with SMTP id x16mr1633777rvf.120.1220028714865; Fri, 29 Aug 2008 09:51:54 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Fri, 29 Aug 2008 09:51:54 -0700 (PDT) Message-ID: <3c0b01820808290951s6a3a8ebuf6ea501308ed91c3@mail.gmail.com> Date: Fri, 29 Aug 2008 12:51:54 -0400 From: "Alexander Sack" To: "Sean Bruno" In-Reply-To: <48B6EF1A.1040805@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B6E19A.7050603@miralink.com> <3c0b01820808281059k3c33e352g6be72f02817e8e6a@mail.gmail.com> <48B6EF1A.1040805@miralink.com> Cc: freebsd-scsi@freebsd.org Subject: Re: [ISP] QLA2432 Target Mode Broken 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: Fri, 29 Aug 2008 16:51:55 -0000 On Thu, Aug 28, 2008 at 2:31 PM, Sean Bruno wrote: > Alexander Sack wrote: >> >> On Thu, Aug 28, 2008 at 1:34 PM, Sean Bruno wrote: >> >>> >>> I tried putting a 2432 into target mode this week and noted that the >>> system >>> threw a pretty nice panic and thought I would post the output here. >>> Reviewing the 4G documentation from Qlogic, it looks like they've >>> substantially changed the target mode interface, so I'm not surprised >>> that >>> there's some work to do. If anyone has any patches they'd like me to >>> test, >>> I'm open to integration: >>> >> >> Did you rebuild the isp driver with -DISP_TARGET_MODE defined? I only >> mention this because the output below seems like you twiddled the >> "role" hint instead of actually recompile the driver? >> >> -aps >> > > Ah, yes, that's a little magic I was trying ... sorry about that. > > Yes, I definitely compiled with ISP_TARGET_MODE defined. :) Yea sorry, I just was checking. I don't have a clue right now why you are dying but some else is seeing similar nastiness in target mode. Minimally you should file a bug. How did you setup your box, how do you reproduce etc. etc.? thanks! -aps From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 17:54:35 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EA6106569C for ; Fri, 29 Aug 2008 17:54:35 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id B18338FC18 for ; Fri, 29 Aug 2008 17:54:35 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id EB9F51A91B6; Fri, 29 Aug 2008 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.335 X-Spam-Level: X-Spam-Status: No, score=-4.335 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.064, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWAA+w1ZjLat; Fri, 29 Aug 2008 10:44:50 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 8CA311A91B5; Fri, 29 Aug 2008 10:44:50 -0700 (PDT) Message-ID: <48B837DB.1000903@miralink.com> Date: Fri, 29 Aug 2008 10:54:35 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Alexander Sack References: <48B6E19A.7050603@miralink.com> <3c0b01820808281059k3c33e352g6be72f02817e8e6a@mail.gmail.com> <48B6EF1A.1040805@miralink.com> <3c0b01820808290951s6a3a8ebuf6ea501308ed91c3@mail.gmail.com> In-Reply-To: <3c0b01820808290951s6a3a8ebuf6ea501308ed91c3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: [ISP] QLA2432 Target Mode Broken 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: Fri, 29 Aug 2008 17:54:36 -0000 Alexander Sack wrote: > On Thu, Aug 28, 2008 at 2:31 PM, Sean Bruno wrote: > >> Alexander Sack wrote: >> >>> On Thu, Aug 28, 2008 at 1:34 PM, Sean Bruno wrote: >>> >>> >>>> I tried putting a 2432 into target mode this week and noted that the >>>> system >>>> threw a pretty nice panic and thought I would post the output here. >>>> Reviewing the 4G documentation from Qlogic, it looks like they've >>>> substantially changed the target mode interface, so I'm not surprised >>>> that >>>> there's some work to do. If anyone has any patches they'd like me to >>>> test, >>>> I'm open to integration: >>>> >>>> >>> Did you rebuild the isp driver with -DISP_TARGET_MODE defined? I only >>> mention this because the output below seems like you twiddled the >>> "role" hint instead of actually recompile the driver? >>> >>> -aps >>> >>> >> Ah, yes, that's a little magic I was trying ... sorry about that. >> >> Yes, I definitely compiled with ISP_TARGET_MODE defined. :) >> > > Yea sorry, I just was checking. I don't have a clue right now why you > are dying but some else is seeing similar nastiness in target mode. > Minimally you should file a bug. > > How did you setup your box, how do you reproduce etc. etc.? > > thanks! > > -aps > Well, I put a 2432 into my box and recompiled with target mode enabled. Nothing fancy. :) A 23XX card in it's place works just fine. I believe, due to the architecture difference between the 4G/8G and 2G cards that it just doesn't work right now. The 4G/8G architecture does nothing in target mode except DMA the incoming data. the 2G cards do some things for the driver. I was hoping that someone has some patches in their trees just lying around that I could look over and test for 4G target mode support. :) -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com Yahoo: sean_bruno@yahoo.com From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 19:17:51 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17B151065670 for ; Fri, 29 Aug 2008 19:17:51 +0000 (UTC) (envelope-from westr@connection.ca) Received: from nc-tor-mail1.connection.ca (nc-tor-mail1.connection.ca [205.207.122.26]) by mx1.freebsd.org (Postfix) with ESMTP id E41C18FC21 for ; Fri, 29 Aug 2008 19:17:50 +0000 (UTC) (envelope-from westr@connection.ca) Received: from localhost (external.tor.connection.ca [216.234.38.18]) by nc-tor-mail1.connection.ca (Postfix) with ESMTP id 263A144B457 for ; Fri, 29 Aug 2008 15:17:50 -0400 (EDT) Date: Fri, 29 Aug 2008 15:17:50 -0400 From: Ross Organization: Network Connection X-Priority: 3 (Normal) Message-ID: <08661720.20080829151750@connection.ca> To: freebsd-scsi@freebsd.org In-Reply-To: <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> <34442830.20080829103621@connection.ca> <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re[6]: isp(4) - kernel panic on initialization of driver X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ross List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 19:17:51 -0000 AS> Give me a sec to look a this some more....bottom line is isp AS> should not be servicing async interrupts until its absolutely AS> ready! Okay, I've done a bit more digging on my side here, and have come up against a small wall - The trace shows: > isp_freeze_loopdown(c81d0e00,2,c06f800f,0,c0cf1f6c,...) at isp_freeze_loopdown+0x42 > isp_async(c81d0e00,6,0,14e1,2001d5c3,...) at isp_async+0xa72 > isp_intr(c81d0e00,8012,1,8014,c0af6718,...) at isp_intr+0xbc7 > isp_mbox_wait_complete(c81d0e00,c0af67e8,50000000,0,8,...) at isp_mbox_wait_complete+0x120 But what's missing in the trace is the call to isp_async() from isp_intr(). What I have found is the call to isp_parse_async() (see line 4560 in isp.c) which in turn calls isp_async(). Setting DEBUG to 0x14F shows the extra debug lines in there confirming the pass through [console output includes the "Async Mbox 0x8014" line before the mbox checkpoint]. I'm guessing that would be the spot to add a check against isp_state, but am not sure whether to just return from the function, or to do the goto jump to 'out' for the cleanup. Let me know if I'm on track. Cheers, Ross. -- From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 22:15:38 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20E231065684 for ; Fri, 29 Aug 2008 22:15:38 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id E67B58FC22 for ; Fri, 29 Aug 2008 22:15:37 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1397021rvf.43 for ; Fri, 29 Aug 2008 15:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2Xdxj7m/3NyArLkrAbwyzLYsC6XDpAZw2Auigg+Os/g=; b=ra1G758nc4hKMF7VlULH69rCb7tpQNTMFhoz2lfVRc7Q0BKlHNfcs0OPcBBET54D6g yG4hBJ3yXH6y/TtdGFU1Q8Qu7ZU14Kj12LnnqiBVDxR4xNIYvGqeABaP7EvBY3K2Iqqn K3nrpwvzQpJltwjZljXe6MV27pEH8AI9GmEbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qM7y6VtjEkPCYtq9HIXsjhcHdDX7joN0at1yTy0ocIZApcpfU5WVVaKYv/adjB2bEg OSnX5C/ax2W5m2dz7iA8dCbFx+VfPHZrwjvn0tV9xIbtPSViqvYNWY+bgY2ySHEY7iTh dE5cYVqg1yDjw2SYp83kG6T9bE6IPsm/OKiHY= Received: by 10.141.197.14 with SMTP id z14mr1773851rvp.283.1220048137488; Fri, 29 Aug 2008 15:15:37 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Fri, 29 Aug 2008 15:15:37 -0700 (PDT) Message-ID: <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com> Date: Fri, 29 Aug 2008 18:15:37 -0400 From: "Alexander Sack" To: Ross In-Reply-To: <08661720.20080829151750@connection.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> <34442830.20080829103621@connection.ca> <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> <08661720.20080829151750@connection.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: Re[6]: isp(4) - kernel panic on initialization of driver 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: Fri, 29 Aug 2008 22:15:38 -0000 On Fri, Aug 29, 2008 at 3:17 PM, Ross wrote: > AS> Give me a sec to look a this some more....bottom line is isp > AS> should not be servicing async interrupts until its absolutely > AS> ready! > > Okay, I've done a bit more digging on my side here, and have come up > against a small wall - > > The trace shows: > >> isp_freeze_loopdown(c81d0e00,2,c06f800f,0,c0cf1f6c,...) at isp_freeze_loopdown+0x42 >> isp_async(c81d0e00,6,0,14e1,2001d5c3,...) at isp_async+0xa72 >> isp_intr(c81d0e00,8012,1,8014,c0af6718,...) at isp_intr+0xbc7 >> isp_mbox_wait_complete(c81d0e00,c0af67e8,50000000,0,8,...) at isp_mbox_wait_complete+0x120 > > But what's missing in the trace is the call to isp_async() from > isp_intr(). What I have found is the call to isp_parse_async() (see line > 4560 in isp.c) which in turn calls isp_async(). > > Setting DEBUG to 0x14F shows the extra debug lines in there confirming > the pass through [console output includes the "Async Mbox 0x8014" > line before the mbox checkpoint]. > > I'm guessing that would be the spot to add a check against isp_state, > but am not sure whether to just return from the function, or to do the > goto jump to 'out' for the cleanup. > > Let me know if I'm on track. I think your doing some great work but I don't think this is the *right* direction to take. The bottom line is the ISP should have interrupts disabled until it completes a full reset and loads the firmware, period. You shouldn't have to ignore ASYNC events during a reset - that doesn't make sense to me....yet....! Can we try something else: @@ -1192,6 +1192,8 @@ isp->isp_touched = 1; } + ISP_DISABLE_INTS(isp); + /* * Make sure we're in reset state. */ --- isp.c.0 2008-08-29 13:35:01.000000000 -0400 +++ isp.c 2008-08-29 14:15:40.000000000 -0400 @@ -226,8 +226,6 @@ isp->isp_touched = 1; } - ISP_DISABLE_INTS(isp); - /* * Pick an initial maxcmds value which will be used * to allocate xflist pointer space. It may be changed @@ -684,7 +682,8 @@ /* * Do MD specific post initialization */ - ISP_RESET1(isp); + if (!IS_24XX(isp)) + ISP_RESET1(isp); /* * Wait for everything to finish firing up. --- isp_freebsd.c.0 2008-08-29 14:05:05.000000000 -0400 +++ isp_freebsd.c 2008-08-29 14:05:32.000000000 -0400 @@ -231,6 +231,7 @@ if (isp->isp_role != ISP_ROLE_NONE) { isp->isp_state = ISP_RUNSTATE; + ISP_ENABLE_INTS(isp); } if (isplist == NULL) { isplist = isp; I wanted to put back that line that we removed so we test one thing at a time. I so wish I could reproduce your exact panic but I can't!!! I've tried about a dozen different ways but I just can't. I'm trying to ignore ALL ASYNC's until after we complete the isp_reset|init|attach cycle and let the intrhook enable interrupts and start the enumeration stuff (at that point simq's have been enabled, bus registered etc.). The mailbox commands should be ok since we use polling to complete them anyway (I have to verify that). I just tried this on my box to verify that my RAID FC array gets enumerated and the driver doesn't panic (its the best I can do right now). Btw, this wouldn't be the final patch but if its effective we are on the right track! :D -aps From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 29 22:43:43 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91930106567C for ; Fri, 29 Aug 2008 22:43:43 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 64C8D8FC19 for ; Fri, 29 Aug 2008 22:43:43 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1408796rvf.43 for ; Fri, 29 Aug 2008 15:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1XDLVW422pJxitM0R4olKQetpx6hiIpCAUV40FDC1CY=; b=kahms9NYL/rEcIAiyfOS5LfP9BWochCBPHslnbdoPYJpk7OGAK7CpiAQzcoghOSzds mY2ctzirfUzUniLX49ACMCrCzWttQ1Xu1EtvA9MvyhKKxIq9+E1ny5QAw5Yan0xnDqly Tpz+AaQqAK+40VPGq0z7mG1+r0gjGheErerYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Ej08H4JrnPYR6GUGO90tvAWqKbZmBwSa0bAhDBASha4iCTkHvMWs4DmMjZP2uGxvLm jxkBJJo7/Mmpv/IaLbkM1IebJcbpSaX9Qq2YVbIArzXaAeEfwmVUycUR9RFUogsp/8N7 Ib1qs8qgzqkiY4SzmmgYlGw9uydF54lpBVYwI= Received: by 10.141.123.4 with SMTP id a4mr1800535rvn.172.1220049822637; Fri, 29 Aug 2008 15:43:42 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Fri, 29 Aug 2008 15:43:42 -0700 (PDT) Message-ID: <3c0b01820808291543q694c9692jc0f1e7c922344f29@mail.gmail.com> Date: Fri, 29 Aug 2008 18:43:42 -0400 From: "Alexander Sack" To: "Sean Bruno" In-Reply-To: <48B837DB.1000903@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B6E19A.7050603@miralink.com> <3c0b01820808281059k3c33e352g6be72f02817e8e6a@mail.gmail.com> <48B6EF1A.1040805@miralink.com> <3c0b01820808290951s6a3a8ebuf6ea501308ed91c3@mail.gmail.com> <48B837DB.1000903@miralink.com> Cc: freebsd-scsi@freebsd.org Subject: Re: [ISP] QLA2432 Target Mode Broken 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: Fri, 29 Aug 2008 22:43:43 -0000 If I get a chance, maybe I can try that and see what happens to me!! -aps On Fri, Aug 29, 2008 at 1:54 PM, Sean Bruno wrote: > Alexander Sack wrote: >> >> On Thu, Aug 28, 2008 at 2:31 PM, Sean Bruno wrote: >> >>> >>> Alexander Sack wrote: >>> >>>> >>>> On Thu, Aug 28, 2008 at 1:34 PM, Sean Bruno wrote: >>>> >>>> >>>>> >>>>> I tried putting a 2432 into target mode this week and noted that the >>>>> system >>>>> threw a pretty nice panic and thought I would post the output here. >>>>> Reviewing the 4G documentation from Qlogic, it looks like they've >>>>> substantially changed the target mode interface, so I'm not surprised >>>>> that >>>>> there's some work to do. If anyone has any patches they'd like me to >>>>> test, >>>>> I'm open to integration: >>>>> >>>>> >>>> >>>> Did you rebuild the isp driver with -DISP_TARGET_MODE defined? I only >>>> mention this because the output below seems like you twiddled the >>>> "role" hint instead of actually recompile the driver? >>>> >>>> -aps >>>> >>>> >>> >>> Ah, yes, that's a little magic I was trying ... sorry about that. >>> >>> Yes, I definitely compiled with ISP_TARGET_MODE defined. :) >>> >> >> Yea sorry, I just was checking. I don't have a clue right now why you >> are dying but some else is seeing similar nastiness in target mode. >> Minimally you should file a bug. >> >> How did you setup your box, how do you reproduce etc. etc.? >> >> thanks! >> >> -aps >> > > Well, I put a 2432 into my box and recompiled with target mode enabled. > Nothing fancy. > > :) > > A 23XX card in it's place works just fine. > I believe, due to the architecture difference between the 4G/8G and 2G cards > that it just doesn't work right now. > The 4G/8G architecture does nothing in target mode except DMA the incoming > data. the 2G cards do some things > for the driver. > > I was hoping that someone has some patches in their trees just lying around > that I could look over and test for > 4G target mode support. :) > > -- > Sean Bruno > MiraLink Corporation > 6015 NE 80th Ave, Ste 100 > Portland, OR 97218 > Phone 503-621-5143 > Fax 503-621-5199 > MSN: sbruno@miralink.com > Google: seanwbruno@gmail.com > Yahoo: sean_bruno@yahoo.com > > From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 30 05:29:01 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 257DF106567A for ; Sat, 30 Aug 2008 05:29:01 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id E06ED8FC16 for ; Sat, 30 Aug 2008 05:29:00 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTP id 0D4BB8FC29; Sat, 30 Aug 2008 00:29:00 -0500 (CDT) Message-ID: <48B8E879.7020809@fuujinnetworks.com> Date: Sat, 30 Aug 2008 00:28:09 -0600 From: Fuujin Networks LLC User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Alexander Sack References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> In-Reply-To: <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Sat, 30 Aug 2008 05:29:01 -0000 Alex: Thanks very much for the patch. Unfortunately, I ended up with a similar result as seen below. Just for grins, I tried the patch on a 64-bit system (AMD64) to see if there was a difference based on which architecture is used for the target. No difference there either; still dumps core and reboots. The upside I would think is that both branches seem to be in sync. I do have a sparc64 box here if you'd like to see what happens in that world (haven't tested it yet). [snip] (targ0:isp0:0:2:0): targdone 0xffffff0001ddda00 (targ0:isp0:0:2:0): targread (targ0:isp0:0:2:0): targread ccb 0xffffff0001ddda00 (0x800b7fe20) (targ0:isp0:0:2:0): targreturnccb 0xffffff0001ddda00 cam_debug: targfreeccb descr 0xffffff0001dda1c0 and cam_debug: freeing ccb 0xffffff0001ddda00 (targ0:isp0:0:2:0): write - uio_resid 8 (targ0:isp0:0:2:0): Sending queued ccb 0x933 (0x800b85040) (targ0:isp0:0:2:0): targstart 0xffffff0001369000 (targ0:isp0:0:2:0): sendccb 0xffffff0001369000 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8025d2e8 stack pointer = 0x10:0xffffffffae3d06f0 frame pointer = 0x10:0xffffffff80a42000 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 = 783 (scsi_target) trap number = 12 panic: page fault cpuid = 0 Uptime: 7m21s Physical memory: 4021 MB Dumping 364 MB:: write - uio_resid 8 (targ0:isp0:0:2:0): getccb 0xffffff0001db7c00 (targ0:isp0:0:2:0): Sent ATIO/INOT (0x800b61a10) (targ0:isp0:0:2:0): write - uio_resid 8 (targ0:isp0:0:2:0): getccb 0xffffff0001db7b00 [snip] Seems to be nearly the same result in loading the firmware: [snip] registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set registered firmware set [snip] isp0: port 0x3000-0x30ff mem 0xfe020000-0xfe020fff irq 25 at device 1.0 on pci2 firmware_get: failed to load firmware image isp_2300_it isp0: [ITHREAD] isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 [snip] isp0: target notify code 0x1007 isp0: target notify code 0x1007 isp0: target notify code 0x1006 isp0: target notify code 0x1007 isp0: target notify code 0x1008 (targbh0:isp0:0:-1:-1): Target Mode Enabled [snip] It doesn't appear that the firmware "isp_2300_it" either exists or possibly isn't named properly on the target machine (or the initiator for that matter). However, there do not seem to be any problems loading the firmware for the card when it's not in target mode. From everything I've read, it looks like the firmware needs to be loaded via the kernel device option "ispfw". If for nothing other than my understanding, is there some reason we're not loading the firmware resident on the card? Thanks very much for your help. This is a bit of a head scratcher for me... Please let me know if SSH access to either boxes would help you and I'll be happy to arrange that. Erich M. Jenkins Fuujin Networks, LLC PO Box 792 Brainerd, MN 56401 (p) 218-824-5038 (f) 218-824-7516 "You should never, never doubt what no one is sure about." -- Gene Wilder Alexander Sack wrote: > On Fri, Aug 29, 2008 at 12:14 PM, Alexander Sack wrote: >> On Thu, Aug 28, 2008 at 7:25 PM, Fuujin Networks LLC >> wrote: >>> [snip] >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 1 >>> ioapic0: Changing APIC ID to 2 >>> ioapic0 irqs 0-23 on motherboard >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> registered firmware set >>> isp0: port 0xc000-0xc0ff mem >>> 0xe7103000-0xe7103fff irq 16 at device 8.0 on pci0 >>> firmware_get: failed to load firmware image isp_2300_it >>> isp0: [ITHREAD] >>> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >>> isp0: target notify code 0x1007 >>> isp0: target notify code 0x1007 >>> isp0: target notify code 0x1006 >>> isp0: target notify code 0x1007 >>> isp0: target notify code 0x1008 >>> (targbh0:isp0:0:-1:-1): Target Mode Enabled >>> isp0: target notify code 0x1007 >>> isp0: target notify code 0x1007 >>> isp0: target notify code 0x1006 >>> isp0: target notify code 0x1007 >>> isp0: target notify code 0x1006 >>> isp0: target notify code 0x1007 >>> [snip] >>> >>> I'm a bit puzzled by the firmware_get failed line above. I suspect this may >>> be the problem, but I have not been able to resolve it. I've tried disabling >>> the bios on the FC cards, as well as messing with almost every other >>> conceivable option, but the same error appears. Thoughts? >> Yes, its a bug in the ISP driver. If you are in target mode, it tries >> to load the isp_XXX_it version of the RISC code. I *think* the old >> SCSI cards had two separate firmwares for target and initiator modes >> (currently if you look at ispfw, there is the 1040, 1080, and 12160_it >> firmwares). >> >> Try this patch: >> >> --- isp_pci.c 2008-08-29 07:58:08.000000000 -0400 >> +++ isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 >> @@ -1039,7 +1039,7 @@ >> } >> >> isp->isp_osinfo.fw = NULL; >> - if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { >> + if (isp->isp_role & ISP_ROLE_TARGET) { >> snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); >> isp->isp_osinfo.fw = firmware_get(fwname); >> } > > Whoops! Its reversed! > > --- isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 > +++ isp_pci.c 2008-08-29 07:58:08.000000000 -0400 > @@ -1039,7 +1039,7 @@ > } > > isp->isp_osinfo.fw = NULL; > - if (isp->isp_role & ISP_ROLE_TARGET) { > + if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { > snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); > isp->isp_osinfo.fw = firmware_get(fwname); > } > > Sorry about that! > > -aps From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 30 06:02:15 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E79C91065672 for ; Sat, 30 Aug 2008 06:02:15 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id B71C78FC16 for ; Sat, 30 Aug 2008 06:02:15 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 4F1BF1A9136; Fri, 29 Aug 2008 22:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.369 X-Spam-Level: X-Spam-Status: No, score=-4.369 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.030, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxUdWZkjRhHs; Fri, 29 Aug 2008 22:52:23 -0700 (PDT) Received: from [10.47.1.6] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id 4F7A31A90FF; Fri, 29 Aug 2008 22:52:23 -0700 (PDT) Message-ID: <48B8E265.4060001@miralink.com> Date: Fri, 29 Aug 2008 23:02:13 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Fuujin Networks LLC References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> <48B8E879.7020809@fuujinnetworks.com> In-Reply-To: <48B8E879.7020809@fuujinnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Sat, 30 Aug 2008 06:02:16 -0000 Fuujin Networks LLC wrote: > Alex: > > Thanks very much for the patch. Unfortunately, I ended up with a > similar result as seen below. Just for grins, I tried the patch on a > 64-bit system (AMD64) to see if there was a difference based on which > architecture is used for the target. No difference there either; still > dumps core and reboots. The upside I would think is that both branches > seem to be in sync. I do have a sparc64 box here if you'd like to see > what happens in that world (haven't tested it yet). > > [snip] > (targ0:isp0:0:2:0): targdone 0xffffff0001ddda00 > (targ0:isp0:0:2:0): targread > (targ0:isp0:0:2:0): targread ccb 0xffffff0001ddda00 (0x800b7fe20) > (targ0:isp0:0:2:0): targreturnccb 0xffffff0001ddda00 > cam_debug: targfreeccb descr 0xffffff0001dda1c0 and > cam_debug: freeing ccb 0xffffff0001ddda00 > (targ0:isp0:0:2:0): write - uio_resid 8 > (targ0:isp0:0:2:0): Sending queued ccb 0x933 (0x800b85040) > (targ0:isp0:0:2:0): targstart 0xffffff0001369000 > (targ0:isp0:0:2:0): sendccb 0xffffff0001369000 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8025d2e8 > stack pointer = 0x10:0xffffffffae3d06f0 > frame pointer = 0x10:0xffffffff80a42000 > 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 = 783 (scsi_target) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 7m21s > Physical memory: 4021 MB > Dumping 364 MB:: write - uio_resid 8 > (targ0:isp0:0:2:0): getccb 0xffffff0001db7c00 > (targ0:isp0:0:2:0): Sent ATIO/INOT (0x800b61a10) > (targ0:isp0:0:2:0): write - uio_resid 8 > (targ0:isp0:0:2:0): getccb 0xffffff0001db7b00 > [snip] > > > Seems to be nearly the same result in loading the firmware: > > [snip] > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > [snip] > isp0: port 0x3000-0x30ff mem > 0xfe020000-0xfe020fff irq 25 at device 1.0 on pci2 > firmware_get: failed to load firmware image isp_2300_it > isp0: [ITHREAD] > isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 > [snip] > isp0: target notify code 0x1007 > isp0: target notify code 0x1007 > isp0: target notify code 0x1006 > isp0: target notify code 0x1007 > isp0: target notify code 0x1008 > (targbh0:isp0:0:-1:-1): Target Mode Enabled > [snip] > > It doesn't appear that the firmware "isp_2300_it" either exists or > possibly isn't named properly on the target machine (or the initiator > for that matter). However, there do not seem to be any problems > loading the firmware for the card when it's not in target mode. > > From everything I've read, it looks like the firmware needs to be > loaded via the kernel device option "ispfw". If for nothing other than > my understanding, is there some reason we're not loading the firmware > resident on the card? > > Thanks very much for your help. This is a bit of a head scratcher for > me... > > Please let me know if SSH access to either boxes would help you and > I'll be happy to arrange that. > > > Erich M. Jenkins > Fuujin Networks, LLC > PO Box 792 > Brainerd, MN 56401 > (p) 218-824-5038 > (f) 218-824-7516 > > "You should never, never doubt what no one is sure about." > -- Gene Wilder > > Alexander Sack wrote: >> On Fri, Aug 29, 2008 at 12:14 PM, Alexander Sack >> wrote: >>> On Thu, Aug 28, 2008 at 7:25 PM, Fuujin Networks LLC >>> wrote: >>>> [snip] >>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>> cpu0 (BSP): APIC ID: 0 >>>> cpu1 (AP): APIC ID: 1 >>>> ioapic0: Changing APIC ID to 2 >>>> ioapic0 irqs 0-23 on motherboard >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> registered firmware set >>>> isp0: port 0xc000-0xc0ff mem >>>> 0xe7103000-0xe7103fff irq 16 at device 8.0 on pci0 >>>> firmware_get: failed to load firmware image isp_2300_it >>>> isp0: [ITHREAD] >>>> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >>>> isp0: target notify code 0x1007 >>>> isp0: target notify code 0x1007 >>>> isp0: target notify code 0x1006 >>>> isp0: target notify code 0x1007 >>>> isp0: target notify code 0x1008 >>>> (targbh0:isp0:0:-1:-1): Target Mode Enabled >>>> isp0: target notify code 0x1007 >>>> isp0: target notify code 0x1007 >>>> isp0: target notify code 0x1006 >>>> isp0: target notify code 0x1007 >>>> isp0: target notify code 0x1006 >>>> isp0: target notify code 0x1007 >>>> [snip] >>>> >>>> I'm a bit puzzled by the firmware_get failed line above. I suspect >>>> this may >>>> be the problem, but I have not been able to resolve it. I've tried >>>> disabling >>>> the bios on the FC cards, as well as messing with almost every other >>>> conceivable option, but the same error appears. Thoughts? >>> Yes, its a bug in the ISP driver. If you are in target mode, it tries >>> to load the isp_XXX_it version of the RISC code. I *think* the old >>> SCSI cards had two separate firmwares for target and initiator modes >>> (currently if you look at ispfw, there is the 1040, 1080, and 12160_it >>> firmwares). >>> >>> Try this patch: >>> >>> --- isp_pci.c 2008-08-29 07:58:08.000000000 -0400 >>> +++ isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 >>> @@ -1039,7 +1039,7 @@ >>> } >>> >>> isp->isp_osinfo.fw = NULL; >>> - if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { >>> + if (isp->isp_role & ISP_ROLE_TARGET) { >>> snprintf(fwname, sizeof (fwname), >>> "isp_%04x_it", did); >>> isp->isp_osinfo.fw = firmware_get(fwname); >>> } >> >> Whoops! Its reversed! >> >> --- isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 >> +++ isp_pci.c 2008-08-29 07:58:08.000000000 -0400 >> @@ -1039,7 +1039,7 @@ >> } >> >> isp->isp_osinfo.fw = NULL; >> - if (isp->isp_role & ISP_ROLE_TARGET) { >> + if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { >> snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); >> isp->isp_osinfo.fw = firmware_get(fwname); >> } >> >> Sorry about that! >> >> -aps > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" Hrm...just to check, do you have the following in your loader.conf: ispfw_load="YES" ? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 30 07:46:31 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D153A1065675 for ; Sat, 30 Aug 2008 07:46:31 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id 973408FC0C for ; Sat, 30 Aug 2008 07:46:31 +0000 (UTC) (envelope-from erich@fuujinnetworks.com) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTP id E16948FC29; Sat, 30 Aug 2008 02:46:30 -0500 (CDT) Message-ID: <48B908B3.6050207@fuujinnetworks.com> Date: Sat, 30 Aug 2008 02:45:39 -0600 From: Fuujin Networks LLC User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Sean Bruno References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> <48B8E879.7020809@fuujinnetworks.com> <48B8E265.4060001@miralink.com> In-Reply-To: <48B8E265.4060001@miralink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Sat, 30 Aug 2008 07:46:32 -0000 Sean: I've tried it with the loader.conf entry and without, but I've not seen any difference in the way it loads the firmware. It is compiled into the Kernel though, so the loader.conf entry should be unnecessary. Thanks for the thought though! I'm willing to look at any possibility to make this work! :) Erich M. Jenkins Fuujin Networks, LLC PO Box 792 Brainerd, MN 56401 (p) 218-824-5038 (f) 218-824-7516 "You should never, never doubt what no one is sure about." -- Gene Wilder Sean Bruno wrote: > Fuujin Networks LLC wrote: >> Alex: >> >> Thanks very much for the patch. Unfortunately, I ended up with a >> similar result as seen below. Just for grins, I tried the patch on a >> 64-bit system (AMD64) to see if there was a difference based on which >> architecture is used for the target. No difference there either; still >> dumps core and reboots. The upside I would think is that both branches >> seem to be in sync. I do have a sparc64 box here if you'd like to see >> what happens in that world (haven't tested it yet). >> >> [snip] >> (targ0:isp0:0:2:0): targdone 0xffffff0001ddda00 >> (targ0:isp0:0:2:0): targread >> (targ0:isp0:0:2:0): targread ccb 0xffffff0001ddda00 (0x800b7fe20) >> (targ0:isp0:0:2:0): targreturnccb 0xffffff0001ddda00 >> cam_debug: targfreeccb descr 0xffffff0001dda1c0 and >> cam_debug: freeing ccb 0xffffff0001ddda00 >> (targ0:isp0:0:2:0): write - uio_resid 8 >> (targ0:isp0:0:2:0): Sending queued ccb 0x933 (0x800b85040) >> (targ0:isp0:0:2:0): targstart 0xffffff0001369000 >> (targ0:isp0:0:2:0): sendccb 0xffffff0001369000 >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x8 >> fault code = supervisor read data, page not present >> instruction pointer = 0x8:0xffffffff8025d2e8 >> stack pointer = 0x10:0xffffffffae3d06f0 >> frame pointer = 0x10:0xffffffff80a42000 >> 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 = 783 (scsi_target) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> Uptime: 7m21s >> Physical memory: 4021 MB >> Dumping 364 MB:: write - uio_resid 8 >> (targ0:isp0:0:2:0): getccb 0xffffff0001db7c00 >> (targ0:isp0:0:2:0): Sent ATIO/INOT (0x800b61a10) >> (targ0:isp0:0:2:0): write - uio_resid 8 >> (targ0:isp0:0:2:0): getccb 0xffffff0001db7b00 >> [snip] >> >> >> Seems to be nearly the same result in loading the firmware: >> >> [snip] >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> registered firmware set >> [snip] >> isp0: port 0x3000-0x30ff mem >> 0xfe020000-0xfe020fff irq 25 at device 1.0 on pci2 >> firmware_get: failed to load firmware image isp_2300_it >> isp0: [ITHREAD] >> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >> [snip] >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1006 >> isp0: target notify code 0x1007 >> isp0: target notify code 0x1008 >> (targbh0:isp0:0:-1:-1): Target Mode Enabled >> [snip] >> >> It doesn't appear that the firmware "isp_2300_it" either exists or >> possibly isn't named properly on the target machine (or the initiator >> for that matter). However, there do not seem to be any problems >> loading the firmware for the card when it's not in target mode. >> >> From everything I've read, it looks like the firmware needs to be >> loaded via the kernel device option "ispfw". If for nothing other than >> my understanding, is there some reason we're not loading the firmware >> resident on the card? >> >> Thanks very much for your help. This is a bit of a head scratcher for >> me... >> >> Please let me know if SSH access to either boxes would help you and >> I'll be happy to arrange that. >> >> >> Erich M. Jenkins >> Fuujin Networks, LLC >> PO Box 792 >> Brainerd, MN 56401 >> (p) 218-824-5038 >> (f) 218-824-7516 >> >> "You should never, never doubt what no one is sure about." >> -- Gene Wilder >> >> Alexander Sack wrote: >>> On Fri, Aug 29, 2008 at 12:14 PM, Alexander Sack >>> wrote: >>>> On Thu, Aug 28, 2008 at 7:25 PM, Fuujin Networks LLC >>>> wrote: >>>>> [snip] >>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>> cpu0 (BSP): APIC ID: 0 >>>>> cpu1 (AP): APIC ID: 1 >>>>> ioapic0: Changing APIC ID to 2 >>>>> ioapic0 irqs 0-23 on motherboard >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> registered firmware set >>>>> isp0: port 0xc000-0xc0ff mem >>>>> 0xe7103000-0xe7103fff irq 16 at device 8.0 on pci0 >>>>> firmware_get: failed to load firmware image isp_2300_it >>>>> isp0: [ITHREAD] >>>>> isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.3.19 >>>>> isp0: target notify code 0x1007 >>>>> isp0: target notify code 0x1007 >>>>> isp0: target notify code 0x1006 >>>>> isp0: target notify code 0x1007 >>>>> isp0: target notify code 0x1008 >>>>> (targbh0:isp0:0:-1:-1): Target Mode Enabled >>>>> isp0: target notify code 0x1007 >>>>> isp0: target notify code 0x1007 >>>>> isp0: target notify code 0x1006 >>>>> isp0: target notify code 0x1007 >>>>> isp0: target notify code 0x1006 >>>>> isp0: target notify code 0x1007 >>>>> [snip] >>>>> >>>>> I'm a bit puzzled by the firmware_get failed line above. I suspect >>>>> this may >>>>> be the problem, but I have not been able to resolve it. I've tried >>>>> disabling >>>>> the bios on the FC cards, as well as messing with almost every other >>>>> conceivable option, but the same error appears. Thoughts? >>>> Yes, its a bug in the ISP driver. If you are in target mode, it tries >>>> to load the isp_XXX_it version of the RISC code. I *think* the old >>>> SCSI cards had two separate firmwares for target and initiator modes >>>> (currently if you look at ispfw, there is the 1040, 1080, and 12160_it >>>> firmwares). >>>> >>>> Try this patch: >>>> >>>> --- isp_pci.c 2008-08-29 07:58:08.000000000 -0400 >>>> +++ isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 >>>> @@ -1039,7 +1039,7 @@ >>>> } >>>> >>>> isp->isp_osinfo.fw = NULL; >>>> - if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { >>>> + if (isp->isp_role & ISP_ROLE_TARGET) { >>>> snprintf(fwname, sizeof (fwname), >>>> "isp_%04x_it", did); >>>> isp->isp_osinfo.fw = firmware_get(fwname); >>>> } >>> >>> Whoops! Its reversed! >>> >>> --- isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 >>> +++ isp_pci.c 2008-08-29 07:58:08.000000000 -0400 >>> @@ -1039,7 +1039,7 @@ >>> } >>> >>> isp->isp_osinfo.fw = NULL; >>> - if (isp->isp_role & ISP_ROLE_TARGET) { >>> + if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { >>> snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); >>> isp->isp_osinfo.fw = firmware_get(fwname); >>> } >>> >>> Sorry about that! >>> >>> -aps >> _______________________________________________ >> freebsd-scsi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > Hrm...just to check, do you have the following in your loader.conf: > ispfw_load="YES" > > ? > From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 30 14:08:53 2008 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9DA1065692 for ; Sat, 30 Aug 2008 14:08:53 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1708FC1A for ; Sat, 30 Aug 2008 14:08:53 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1689078rvf.43 for ; Sat, 30 Aug 2008 07:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=N2VWs1Dr7klnK4rHlXtdf9TWVXX0PpjIk5X0K06fCMs=; b=KDi/ckzuiRm1sQno6y6v1+j9yTgeHGNEhsxqxnP58HYvwG/zGO5m/VY7hT1lq0fNut uJ+fSrK48g1odCj5L4FdbCtLfPvQFLKKDmT54uBdu6KCm0skKRcGP1rTJ+uasubZASjP OG9zjJM3eM+IbtSvkbp6wvckhtMvjhRCNFVgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bz0kBfyskrSl8Yb25meO2Q0Kc35+OFp0JnPJwgdMr0pSvKTBU8k4BawojYgNt96n06 jcv6hAlw3NX0dy9DCZJhW7GLDh0cRBKTW5welW+0q9Ys4jvrAhNWERmShI/Ri5fwDUEn +G9l6mh/KbfJpK1cgsEpEQaPdixOy7gTI7XWI= Received: by 10.140.207.2 with SMTP id e2mr2176210rvg.187.1220105333183; Sat, 30 Aug 2008 07:08:53 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Sat, 30 Aug 2008 07:08:53 -0700 (PDT) Message-ID: <3c0b01820808300708s5ed5cb18o5199e0e4ec1dcbba@mail.gmail.com> Date: Sat, 30 Aug 2008 10:08:53 -0400 From: "Alexander Sack" To: "Fuujin Networks LLC" In-Reply-To: <48B8E879.7020809@fuujinnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> <48B8E879.7020809@fuujinnetworks.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 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: Sat, 30 Aug 2008 14:08:53 -0000 On Sat, Aug 30, 2008 at 2:28 AM, Fuujin Networks LLC wrote: > Alex: > > Thanks very much for the patch. Unfortunately, I ended up with a similar > result as seen below. Just for grins, I tried the patch on a 64-bit system > (AMD64) to see if there was a difference based on which architecture is used > for the target. No difference there either; still dumps core and reboots. > The upside I would think is that both branches seem to be in sync. I do have > a sparc64 box here if you'd like to see what happens in that world (haven't > tested it yet). No, no, no....the patch was not to FIX the target mode issue. There is only one firmware and it does get loaded (even with the error message below). I was *JUST* trying to avoid firmware_get() to attempt to register a firmware that does not exist. I reversed the patch, are you sure you applied the right one? Take a look but isp_pci.c should have an added IS_SCSI(isp) to line 1039 here it is again: --- isp_pci.c.0 2008-08-29 08:03:24.000000000 -0400 +++ isp_pci.c 2008-08-29 07:58:08.000000000 -0400 @@ -1039,7 +1039,7 @@ } isp->isp_osinfo.fw = NULL; - if (isp->isp_role & ISP_ROLE_TARGET) { + if (isp->isp_role & ISP_ROLE_TARGET && IS_SCSI(isp)) { snprintf(fwname, sizeof (fwname), "isp_%04x_it", did); isp->isp_osinfo.fw = firmware_get(fwname); } This should eliminate the firmware_get() message. But AGAIN this will not fix your target mode issues. > [snip] > (targ0:isp0:0:2:0): targdone 0xffffff0001ddda00 > (targ0:isp0:0:2:0): targread > (targ0:isp0:0:2:0): targread ccb 0xffffff0001ddda00 (0x800b7fe20) > (targ0:isp0:0:2:0): targreturnccb 0xffffff0001ddda00 > cam_debug: targfreeccb descr 0xffffff0001dda1c0 and > cam_debug: freeing ccb 0xffffff0001ddda00 > (targ0:isp0:0:2:0): write - uio_resid 8 > (targ0:isp0:0:2:0): Sending queued ccb 0x933 (0x800b85040) > (targ0:isp0:0:2:0): targstart 0xffffff0001369000 > (targ0:isp0:0:2:0): sendccb 0xffffff0001369000 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8025d2e8 > stack pointer = 0x10:0xffffffffae3d06f0 > frame pointer = 0x10:0xffffffff80a42000 > 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 = 783 (scsi_target) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 7m21s > Physical memory: 4021 MB > Dumping 364 MB:: write - uio_resid 8 > (targ0:isp0:0:2:0): getccb 0xffffff0001db7c00 > (targ0:isp0:0:2:0): Sent ATIO/INOT (0x800b61a10) > (targ0:isp0:0:2:0): write - uio_resid 8 > (targ0:isp0:0:2:0): getccb 0xffffff0001db7b00 > [snip] > > > Seems to be nearly the same result in loading the firmware: > > [snip] > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > registered firmware set > [snip] > isp0: port 0x3000-0x30ff mem > 0xfe020000-0xfe020fff irq 25 at device 1.0 on pci2 > firmware_get: failed to load firmware image isp_2300_it > isp0: [ITHREAD] Hold on, do you see this message with the patch? Are you sure you rebuild and rebooted correctly? You should not see this message anymore. I will verify the patch again but see above. > It doesn't appear that the firmware "isp_2300_it" either exists or possibly > isn't named properly on the target machine (or the initiator for that > matter). However, there do not seem to be any problems loading the firmware > for the card when it's not in target mode. No there is no problem. The error message above is harmless. > From everything I've read, it looks like the firmware needs to be loaded via > the kernel device option "ispfw". If for nothing other than my > understanding, is there some reason we're not loading the firmware resident > on the card? You ARE loading the firmware (isp_2300 one from ispfw) it just that the code also tries to get an IT version of it and for fibre channel cards there is no such thing. The patch I gave should remove this nuisance BUT NOT FIX target mode. You need to rebuild the kernel with: options KDB options DDB and when you panic, do a "bt" and copy the stack trace so we know WHERE exactly its panicing on your 23xxx setup. Can you post your kernel configuration file as well? Thanks! -aps