From owner-freebsd-scsi@FreeBSD.ORG Tue Sep 2 18:42: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 751031065687 for ; Tue, 2 Sep 2008 18:42:14 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 43F628FC08 for ; Tue, 2 Sep 2008 18:42:14 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3363949rvf.43 for ; Tue, 02 Sep 2008 11:42:14 -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=gRCXPB7Ejz+E0ktmzoFdTd07ZcwzrKbBcxAhUB1dJTM=; b=l9/Q+F52MV5BKxIg2R7oFYjviX525dvrgrdO8C6M5OitNSVkko1bryQBFB/APDI/gw UUB8/UjbtY0O0/UPAeLbqQSASQguOtsZVc4xjzFR5j1Nz7MGtWDGNG4Bsq+6jk0fMZLN 7OdyFVz6kIDcXOtVQTetkELAEKUUgwK1I3fUM= 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=blsqvsZgmbHXkEouSIIe2i15zOZuHPz0cYU1AIHfbFEKmmw1GQRDlfob+WqK097h3G IHsnrcPfUeTIjStwL7ZktSd1w9Unm0fJIfFluXVPVJ8ynXXsPTM3q+l2CzHE5Zr0hMFX 50FWmUFYXHRd7m7ZWPN4xe31qbiy/s/My/4V4= Received: by 10.141.146.4 with SMTP id y4mr4350447rvn.272.1220380933913; Tue, 02 Sep 2008 11:42:13 -0700 (PDT) Received: by 10.140.127.19 with HTTP; Tue, 2 Sep 2008 11:42:13 -0700 (PDT) Message-ID: <3c0b01820809021142v1192123aq1116c5528dda4920@mail.gmail.com> Date: Tue, 2 Sep 2008 14:42:13 -0400 From: "Alexander Sack" To: Ross In-Reply-To: <479922773.20080902125207@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> <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com> <479922773.20080902125207@connection.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: Re[8]: 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, 02 Sep 2008 18:42:14 -0000 On Tue, Sep 2, 2008 at 12:52 PM, Ross wrote: > > AS> I think your doing some great work but I don't think this is the > AS> *right* direction to take. The bottom line is the ISP should have > AS> interrupts disabled until it completes a full reset and loads the > AS> firmware, period. You shouldn't have to ignore ASYNC events during a > AS> reset - that doesn't make sense to me....yet....! > > I've created a small patch that so far seems to be working (survived > ~10+ reboots). From what I can tell, using the ISP_ENABLE_INTS & > ISP_DISABLE_INTS functions won't do anything to stop the problem. Yes Ross, I just discovered this myself that AYNC events are let through to the host regardless of ISP_ENABLE_INTS. > Basically my hypotheses is that the ASYNC command is already sitting > around in the mailbox of the card waiting to be read, so no interrupt > is actually being generated during the time the driver is starting up > - so you can't disable it. That's right but the ISP should be reset. YWe actually issue mailbox commands BEFORE we do the RISC reset. I think that maybe ultimately the bug. > (The card is active with a valid running rom before freebsd gets it's > paws on it, so it's probably already cleanly read it, but hasn't acted > upon it) Yes I believe your right. > The crash is located with the very first mailbox read, where if it > doesn't recognize the mailbox response, it parses it anyways > (in case it's something that needs to be done), and exit out if > there's an error. > > But the isp_parse_async() function makes the assumption that isp_state > == ISP_RUNSTATE, so it's safe to do anything. Where in fact is > actually gets called when not in ISP_RUNSTATE (with the assumption > that no problematic async command could be generated at this point). > > I'm guessing the true fix would be upon startup to somehow make sure > the mailbox queue is emptied before attempting to query the card > (for the firmware version). But how to do that is beyond me. Are you ok with trying another patch to maybe do exactly that? Let me take a look at your patch as well. Thanks! -aps