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