Date: Sat, 30 Aug 2008 00:28:09 -0600 From: Fuujin Networks LLC <erich@fuujinnetworks.com> To: Alexander Sack <pisymbol@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: Qlogic FC scsi_target ISP2310 Message-ID: <48B8E879.7020809@fuujinnetworks.com> In-Reply-To: <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com> References: <48B4CF57.30603@fuujinnetworks.com> <3c0b01820808271520w78d0f338iaf6996774512b5bb@mail.gmail.com> <48B733CF.5000105@fuujinnetworks.com> <3c0b01820808290914s638c970ejeae1d4f8c8c8a9d9@mail.gmail.com> <3c0b01820808290915t4e964182y784c215e28977252@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <isp_1040>
registered firmware set <isp_1040_it>
registered firmware set <isp_1080>
registered firmware set <isp_1080_it>
registered firmware set <isp_12160>
registered firmware set <isp_12160_it>
registered firmware set <isp_2100>
registered firmware set <isp_2200>
registered firmware set <isp_2300>
registered firmware set <isp_2322>
registered firmware set <isp_2400>
[snip]
isp0: <Qlogic ISP 2300 PCI FC-AL Adapter> 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 <pisymbol@gmail.com> wrote:
>> On Thu, Aug 28, 2008 at 7:25 PM, Fuujin Networks LLC
>> <erich@fuujinnetworks.com> 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 <Version 1.1> irqs 0-23 on motherboard
>>> registered firmware set <isp_1040>
>>> registered firmware set <isp_1040_it>
>>> registered firmware set <isp_1080>
>>> registered firmware set <isp_1080_it>
>>> registered firmware set <isp_12160>
>>> registered firmware set <isp_12160_it>
>>> registered firmware set <isp_2100>
>>> registered firmware set <isp_2200>
>>> registered firmware set <isp_2300>
>>> registered firmware set <isp_2322>
>>> registered firmware set <isp_2400>
>>> isp0: <Qlogic ISP 2300 PCI FC-AL Adapter> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48B8E879.7020809>