From owner-freebsd-scsi@FreeBSD.ORG Sun Aug 31 17:12:33 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 A563C106567D for ; Sun, 31 Aug 2008 17:12:33 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 7160A8FC15 for ; Sun, 31 Aug 2008 17:12:33 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2169747rvf.43 for ; Sun, 31 Aug 2008 10:12:32 -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=WO6XZaQJBfaW99dday49iUueZEgsqoBaWf4nu7yFTPw=; b=DfRtXVY3WznmyT/AGQpwPA7GITsjWOrE2rymLZYzccujgP24FlpbIESRIk4gMnNC2k d84ozcKqvPPDn6z7QllE3dgYUg8a54eckfgcwVQvL8QzUHzx3slFEA/5l5LKw3bAHuef vs7yc3Usut1ufsgvw04/L+RJWy8XcBgqYSSBs= 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=qQsw4bhq/Zf1Zzv4Usa1D38U9wj8A9UMXT3tLJE2LJucmgggFzifWFDlztU5KGSCtX lKf2/Y4SYmuhjZlQfEBuHGK9Bw2VGFETErouTnEO2VmWYMJckCbefOuPt00JLg1hCg0e eMqwLjFWYPFDXQJfoj0ZN5elS8QDuYYvOTVfU= Received: by 10.141.23.7 with SMTP id a7mr2880849rvj.58.1220202752340; Sun, 31 Aug 2008 10:12:32 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Sun, 31 Aug 2008 10:12:32 -0700 (PDT) Message-ID: <3c0b01820808311012n7e83a948t732e6544ddb0d703@mail.gmail.com> Date: Sun, 31 Aug 2008 13:12:32 -0400 From: "Alexander Sack" To: "Fuujin Networks LLC" In-Reply-To: <48BA87C6.5070008@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> <3c0b01820808300708s5ed5cb18o5199e0e4ec1dcbba@mail.gmail.com> <48BA87C6.5070008@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: Sun, 31 Aug 2008 17:12:33 -0000 On Sun, Aug 31, 2008 at 8:00 AM, Fuujin Networks LLC wrote: > I apologize for not being more specific in my questions. I understand that > we're loading the firmware via the kernel, but my question was why not load > it from the card? If I have an HP SmartArray 5300 card and the firmware is > out of date, I'm expected to update it, not load a kernel module to do it > for me. This makes sense for many reasons, not he least of which is > compatibility. I'm in no position to suggest what is proper from the > standpoint of this particular problem, but I'm trying to understand the > reason for choosing a kernel module rather than an sys admin as with nearly > all other devices. We do both! QLogic ships each card with some version of the firmware on it that boots up at runtime. One of the nice features of the ISP is that its RISC based firmware can be updated at runtime ensuring you are always running the latest. The ispfw driver is strictly used to register firmwares with the generic firmware driver (the real action happens in isp during isp_reset()). I think the driver should really check to see if the ispfw version is less than the resident driver and do the right thing. I think it used to do that but was taken out, I don't know why - I'm actually thinking of maybe it should be added back. In any event, if you want to disable loading of the firmware you can set in your hints file: hint.isp.0.fwload_disable=1 That should prevent the driver from loading the ispfw version (please check during bootup what version your resident firmware is at to determine which is newer). If you do this then you should see: isp0: Board Type 2300, Chip Revision 0x1, resident F/W Revision instead of isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision Having a separate utility (typically DOS or Windows based) is not that great in my eyes but to each his own. Bottom line is you should run the latest ISP firmware (whether its the one that was flashed from QLogic or the one in the ispfw driver). I'm thinking that perhaps and audit should be done and we should ship the latest firmware off the QLogic website. What version is shipped with your card? Looks like 3.3.25 is the latest for 23xx cards. Hmmm.... > I misunderstood the purpose of your patch as well. I thought the problem > was a firmware loading issue, but as you mentioned, this does not appear to > be the case. Right, it seems something else. > I did see your message with the patch and it was correctly applied and the > kernel was correctly compiled. I did, however, reinstall the OS because of > all the fiddling I did to this point. Funny thing is that I can't get it to > crash anymore. I tried it clean, and the system tanked, but after I applied > your patch, I can't get it to panic anymore. The loop looks like it comes > up, but when I rescan with the initiator, the target stays up without > incident, but nothing shows up in camcontrol as an emulated disk: > > amd_svr0-01# camcontrol devlist -v > scbus0 on isp0 bus 0: > < > at scbus0 target -1 lun -1 () > scbus-1 on xpt0 bus 0: > < > at scbus-1 target -1 lun -1 (xpt0) > > I do get this on the initiator though: > > [snip] > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.5 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.6 (count 36, resid 36, > status not marked) > Aug 31 05:44:34 test kernel: isp0: bad underrun for 0.7 (count 36, resid 36, > status not marked) > [snip] > > After a clean install, this is what I see from dmesg on the target: > > [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 > isp0: port 0x3000-0x30ff mem > 0xfe020000-0xfe020fff irq 25 at device 1.0 on pci2 > 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 0x1007 > isp0: target notify code 0x1008 > isp0: target notify code 0x1006 > [snip] Is this with or without the isp patch I sent regarding the firmware? I noticed its not trying to get isp_2300_it like before (I'm hoping that's due to the patch I sent otherwise I'm confused this holiday weekend). > Here's the complete kernel, also after a fresh install and the removal of > unnecessary options/devices (stuff not in the server): > # SCSI Controllers > device isp # Qlogic family > device ispfw # Firmware for QLogic HBAs- normally a > module > options ISP_TARGET_MODE # for ISP cards to operate in target mode > device targ # SCSI Target device > device targbh # SCSI Target Black Hole > options CAMDEBUG > options VFS_AIO Thanks for this, I just wanted to verify your build options look good. > Not sure what to make of this.... Would you recommend a different FC card? > Emulex? I have no direct experience with Emulex with FreeBSD so I'm not the right person to ask. I was under the impression that the 23xx target mode was working. Did you enable target mode in the BIOS by chance (or disable it, I think on my 24xx BIOS I have that option but I'm not in front of it yet). Just verify your BIOS version number and options before completely giving up! :D -aps