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