From nobody@FreeBSD.org  Tue Aug 26 20:13:25 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D47231065676
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Aug 2008 20:13:25 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id B20A28FC20
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Aug 2008 20:13:25 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m7QKDPuZ049803
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Aug 2008 20:13:25 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m7QKDPC6049802;
	Tue, 26 Aug 2008 20:13:25 GMT
	(envelope-from nobody)
Message-Id: <200808262013.m7QKDPC6049802@www.freebsd.org>
Date: Tue, 26 Aug 2008 20:13:25 GMT
From: Ross <westr@connection.ca>
To: freebsd-gnats-submit@FreeBSD.org
Subject: isp(4) - kernel panic on card initialization
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         126866
>Category:       kern
>Synopsis:       [isp] [panic] kernel panic on card initialization
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-scsi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 26 20:20:02 UTC 2008
>Closed-Date:    Thu Nov 26 09:55:05 UTC 2009
>Last-Modified:  Thu Nov 26 09:55:05 UTC 2009
>Originator:     Ross
>Release:        Freebsd 7.0
>Organization:
>Environment:
FreeBSD <servername> 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #22: Tue Aug 26 13:18:24 EDT 2008     <servername>:/usr/obj/usr/src/sys/BL460C  i386
>Description:
isp(4) driver can crash the kernel with a fatal trap 12/Page fault upon initialization of the driver - this is generally evident in a boot-off-SAN configuration where the card is already active upon boot.

Debugging shows the last outputted message as "isp1: Port Database Changed: freeze simq (loopdown)" [line 288 in isp_freebsd.c].  Further added debugging shows that the function isp_freeze_loopdown() will never return, pointing the problem most likely being with the line 'xpt_freeze_simq(isp->isp_sim, 1);' [line 290 in isp_freebsd.c]

Normal startup/activation of the driver will occur about 50% of the time, which seems to point to the driver receiving a FC command/notification before it's ready for it.

-= Normal successful startup: [hint.isp.0.debug = 0x11F]
..
Aug 26 15:45:16 controller kernel: isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0x4000-0x40ff mem 0xfdff0000-0xfdff3fff irq 18 at device 0.0 on pci16
Aug 26 15:45:16 controller kernel: isp0: set PCI latency to 64
Aug 26 15:45:16 controller kernel: isp0: [ITHREAD]
Aug 26 15:45:16 controller kernel: isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90
Aug 26 15:45:16 controller kernel: isp0: 2K Logins Supported
Aug 26 15:45:16 controller kernel: isp0: Last F/W revision was 4.0.90
Aug 26 15:45:16 controller kernel: isp0: 4096 max I/O command limit set
Aug 26 15:45:16 controller kernel: isp0: line 1207: markportdb
Aug 26 15:45:16 controller kernel: isp0: Starting Initial Loop Down Timer
Aug 26 15:45:16 controller kernel: isp1: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16
Aug 26 15:45:16 controller kernel: isp1: set PCI latency to 64
Aug 26 15:45:16 controller kernel: isp1: [ITHREAD]
Aug 26 15:45:16 controller kernel: isp1: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90
Aug 26 15:45:16 controller kernel: isp1: 2K Logins Supported
Aug 26 15:45:16 controller kernel: isp1: Last F/W revision was 4.0.90
Aug 26 15:45:16 controller kernel: isp1: 4096 max I/O command limit set
Aug 26 15:45:16 controller kernel: isp1: line 1207: markportdb
Aug 26 15:45:16 controller kernel: isp1: Starting Initial Loop Down Timer
..
-=

-= Failed startup
Aug 26 15:45:16 controller kernel: isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0x4000-0x40ff mem 0xfdff0000-0xfdff3fff irq 18 at device 0.0 on pci16
Aug 26 15:45:16 controller kernel: isp0: set PCI latency to 64
Aug 26 15:45:16 controller kernel: isp0: [ITHREAD]
Aug 26 15:45:16 controller kernel: isp0: Board Type 2422, Chip Revision 0x2, resident F/W Revision 4.0.90
Aug 26 15:45:16 controller kernel: isp0: 2K Logins Supported
Aug 26 15:45:16 controller kernel: isp0: Last F/W revision was 4.0.90
Aug 26 15:45:16 controller kernel: isp0: 4096 max I/O command limit set
Aug 26 15:45:16 controller kernel: isp0: line 1207: markportdb
Aug 26 15:45:16 controller kernel: isp0: Starting Initial Loop Down Timer
Aug 26 15:45:16 controller kernel: isp1: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0x4400-0x44ff mem 0xfdfe0000-0xfdfe3fff irq 19 at device 0.1 on pci16
Aug 26 15:45:16 controller kernel: isp1: set PCI latency to 64
Aug 26 15:45:16 controller kernel: isp1: [ITHREAD]
Aug 26 15:45:16 controller kernel: isp1: line 5345: markportdb
Aug 26 15:45:16 controller kernel: isp1: Port Database Changed
Aug 26 15:45:16 controller kernel: isp1: Port Database Changed: freeze simq (loopdown)
[point of crash]
Fatal Trap 12: page fault while in kernel
fault code = Supervisor read, page not present
instruction pointer:    0x20 : 0xc0243a46
stack pointer:          0x20 : 0xc0af63cc
frame pointer:          0x20 : 0xc0af63cc
..
-=


>How-To-Repeat:

Reboot the box, and hope the FC command doesn't come down the pipe before the driver is fully initialized.  :-)
>Fix:
none.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->freebsd-bugs 
Responsible-Changed-By: remko 
Responsible-Changed-When: Wed Aug 27 06:32:52 UTC 2008 
Responsible-Changed-Why:  
reassign to the -bugs team, this does not seem i386 specific. 
Not sure where we should move san connectors to btw (can be 
a networking device, but also just a system device) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126866 
Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Aug 27 09:05:34 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126866 

From: Ross West <westr@connection.ca>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization
Date: Mon, 15 Sep 2008 11:42:59 -0400

 Bug solved: issue is with the driver not doing a reset of the HBA
 before attempting to read the firmware version from the HBA mailbox
 and getting a different response than expected.
 
 Patch that appears to fix the issue by doing the HBA reset first, then
 full card initialization.
 
 Many thanks to Alexander Sack (pisymbol@gmail.com) for the hard work
 in finding the proper solution.
 
 Patch as follows:
 -= start
 --- isp.c       2008-09-02 12:45:07.000000000 -0400
 +++ isp.c.0     2008-09-02 11:06:55.000000000 -0400
 @@ -171,61 +171,6 @@
  
         isp->isp_state = ISP_NILSTATE;
  
 -       /*
 -        * Basic types (SCSI, FibreChannel and PCI or SBus)
 -        * have been set in the MD code. We figure out more
 -        * here. Possibly more refined types based upon PCI
 -        * identification. Chip revision has been gathered.
 -        *
 -        * After we've fired this chip up, zero out the conf1 register
 -        * for SCSI adapters and do other settings for the 2100.
 -        */
 -
 -       /*
 -        * Get the current running firmware revision out of the
 -        * chip before we hit it over the head (if this is our
 -        * first time through). Note that we store this as the
 -        * 'ROM' firmware revision- which it may not be. In any
 -        * case, we don't really use this yet, but we may in
 -        * the future.
 -        */
 -       if (isp->isp_touched == 0) {
 -               /*
 -                * First see whether or not we're sitting in the ISP PROM.
 -                * If we've just been reset, we'll have the string "ISP   "
 -                * spread through outgoing mailbox registers 1-3. We do
 -                * this for PCI cards because otherwise we really don't
 -                * know what state the card is in and we could hang if
 -                * we try this command otherwise.
 -                *
 -                * For SBus cards, we just do this because they almost
 -                * certainly will be running firmware by now.
 -                */
 -               if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 ||
 -                   ISP_READ(isp, OUTMAILBOX2) != 0x5020 ||
 -                   ISP_READ(isp, OUTMAILBOX3) != 0x2020) {
 -                       /*
 -                        * Just in case it was paused...
 -                        */
 -                       if (IS_24XX(isp)) {
 -                               ISP_WRITE(isp, BIU2400_HCCR,
 -                                   HCCR_2400_CMD_RELEASE);
 -                       } else {
 -                               ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE);
 -                       }
 -                       MEMZERO(&mbs, sizeof (mbs));
 -                       mbs.param[0] = MBOX_ABOUT_FIRMWARE;
 -                       mbs.logval = MBLOGNONE;
 -                       isp_mboxcmd(isp, &mbs);
 -                       if (mbs.param[0] == MBOX_COMMAND_COMPLETE) {
 -                               isp->isp_romfw_rev[0] = mbs.param[1];
 -                               isp->isp_romfw_rev[1] = mbs.param[2];
 -                               isp->isp_romfw_rev[2] = mbs.param[3];
 -                       }
 -               }
 -               isp->isp_touched = 1;
 -       }
 -
         ISP_DISABLE_INTS(isp);
  
         /*
 @@ -254,7 +199,6 @@
                 return;
         }
  
 -
         /*
          * Set up default request/response queue in-pointer/out-pointer
          * register indices.
 @@ -680,7 +624,6 @@
         ISP_WRITE(isp, isp->isp_respinrp, 0);
         ISP_WRITE(isp, isp->isp_respoutrp, 0);
  
 -
         /*
          * Do MD specific post initialization
          */
 @@ -706,6 +649,52 @@
                         }
                 }
         }
 +       
 +       /*
 +        * Basic types (SCSI, FibreChannel and PCI or SBus)
 +        * have been set in the MD code. We figure out more
 +        * here. Possibly more refined types based upon PCI
 +        * identification. Chip revision has been gathered.
 +        *
 +        * After we've fired this chip up, zero out the conf1 register
 +        * for SCSI adapters and do other settings for the 2100.
 +        */
 +       if (isp->isp_touched == 0) {
 +               /*
 +                * First see whether or not we're sitting in the ISP PROM.
 +                * If we've just been reset, we'll have the string "ISP   "
 +                * spread through outgoing mailbox registers 1-3. We do
 +                * this for PCI cards because otherwise we really don't
 +                * know what state the card is in and we could hang if
 +                * we try this command otherwise.
 +                *
 +                * For SBus cards, we just do this because they almost
 +                * certainly will be running firmware by now.
 +                */
 +               if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 ||
 +                   ISP_READ(isp, OUTMAILBOX2) != 0x5020 ||
 +                   ISP_READ(isp, OUTMAILBOX3) != 0x2020) {
 +                       /*
 +                        * Just in case it was paused...
 +                        */
 +                       if (IS_24XX(isp)) {
 +                               ISP_WRITE(isp, BIU2400_HCCR,
 +                                   HCCR_2400_CMD_RELEASE);
 +                       } else {
 +                               ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE);
 +                       }
 +                       MEMZERO(&mbs, sizeof (mbs));
 +                       mbs.param[0] = MBOX_ABOUT_FIRMWARE;
 +                       mbs.logval = MBLOGNONE;
 +                       isp_mboxcmd(isp, &mbs);
 +                       if (mbs.param[0] == MBOX_COMMAND_COMPLETE) {
 +                               isp->isp_romfw_rev[0] = mbs.param[1];
 +                               isp->isp_romfw_rev[1] = mbs.param[2];
 +                               isp->isp_romfw_rev[2] = mbs.param[3];
 +                       }
 +               }
 +               isp->isp_touched = 1;
 +       }
  
         /*
          * Up until this point we've done everything by just reading or
 -= end
 

From: "Paul A. Procacci" <pprocacci@datapipe.com>
To: bug-followup@FreeBSD.org, westr@connection.ca
Cc:  
Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization
Date: Thu, 25 Sep 2008 03:56:10 -0500

 Hello,
 
 I am having the same exact problem you were having using the same 
 device.  I started receiving this error on FBSD7-RELEASE and thought it 
 was specific to that version.  Naturally I upgraded to FBSD7-Stable as 
 of today (9/25/2008), but still haven't been able to resolve this error, 
 even with the patch presented here.  Like you had mentioned on 
 freebsd-scsi, the machine panic's roughly 50% of the time during boot.
 
 Here is my `trap` with the patch applied.  Due note that this is typed 
 by hand as the kvm I'm on doesn't allow for copy and paste:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address = 0x20
 fault code = supervisor read data, page not present
 instruction pointer = 0x8 :0xffffffff80187350
 stack pointer = 0x10 :ffffffffac499810
 frame pointer = 0x10 : ffffff0003782320
 code segment = base 0x0, limit 0xfffff, type 0x1b
                       =     DPL 0, pres 1, long 1, def32, 0, ran 1
 processor eflags = interrupt enabled, resume, IOPL = 0
 current process = 5 (thread taskq)
 trap number = 12
 panic: page fault
 cpuid = 0
 Uptime 5s
 
 ----------------------------------------------------------------
 I wish I had further information to give.  The information I provided 
 almost certainly pales in comparison to the submitters, but I believe it 
 relevant given the symptoms / deice are identical.

From: Alexander Sack <asack@niksun.com>
To: bug-followup@FreeBSD.org, westr@connection.ca
Cc:  
Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization
Date: Fri, 3 Oct 2008 14:39:14 -0400

 --Apple-Mail-13--61181355
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed;
 	delsp=yes
 Content-Transfer-Encoding: 7bit
 
 The main problem is if you issue a firmware MAILBOX command before you  
 quiesce the ISP then you will wound up handling async events to early  
 at attach time.  I've moved checking for the reset signature further  
 down the isp_reset() path as well as remove checking OUTMAILBOX3  
 (OUTMAILBOX3 is really isp->isp_type (but its a string), if you see  
 the 'ISP' characters in OUTMAILBOX1 and 2 then we assume the soft  
 reset sequence worked and we can move on).  Note the ABOUT FIRMWARE  
 command seems to fail on ISP24xx after a reset until the EXEC occurs.   
 We might want to rehash this sequence at some point but for now, we  
 either load via dodnld or we don't via loader.conf parameter., i.e. we  
 are still not checking which firmware is newer the one on the card or  
 the one shipped with the driver.
 
 I also removed putting the ISP24xx into PAUSE mode - I don't see the  
 reason for this since we only touch SXP and FPM/FBM registers for non- 
 ISP24xx cards.
 
 Note I have another patch to fix some firmware related issues as well  
 which I will coordinate with this fix...
 
 -aps
 
 
 
 --Apple-Mail-13--61181355
 Content-Disposition: attachment;
 	filename=isp.c.patch
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="isp.c.patch"
 Content-Transfer-Encoding: 7bit
 
 --- isp.c	Tue Sep 30 18:09:42 2008
 +++ isp.c.fix	Fri Oct  3 14:27:48 2008
 @@ -171,60 +171,6 @@
  
  	isp->isp_state = ISP_NILSTATE;
  
 -	/*
 -	 * Basic types (SCSI, FibreChannel and PCI or SBus)
 -	 * have been set in the MD code. We figure out more
 -	 * here. Possibly more refined types based upon PCI
 -	 * identification. Chip revision has been gathered.
 -	 *
 -	 * After we've fired this chip up, zero out the conf1 register
 -	 * for SCSI adapters and do other settings for the 2100.
 -	 */
 -
 -	/*
 -	 * Get the current running firmware revision out of the
 -	 * chip before we hit it over the head (if this is our
 -	 * first time through). Note that we store this as the
 -	 * 'ROM' firmware revision- which it may not be. In any
 -	 * case, we don't really use this yet, but we may in
 -	 * the future.
 -	 */
 -	if (isp->isp_touched == 0) {
 -		/*
 -		 * First see whether or not we're sitting in the ISP PROM.
 -		 * If we've just been reset, we'll have the string "ISP   "
 -		 * spread through outgoing mailbox registers 1-3. We do
 -		 * this for PCI cards because otherwise we really don't
 -		 * know what state the card is in and we could hang if
 -		 * we try this command otherwise.
 -		 *
 -		 * For SBus cards, we just do this because they almost
 -		 * certainly will be running firmware by now.
 -		 */
 -		if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 ||
 -		    ISP_READ(isp, OUTMAILBOX2) != 0x5020 ||
 -		    ISP_READ(isp, OUTMAILBOX3) != 0x2020) {
 -			/*
 -			 * Just in case it was paused...
 -			 */
 -			if (IS_24XX(isp)) {
 -				ISP_WRITE(isp, BIU2400_HCCR,
 -				    HCCR_2400_CMD_RELEASE);
 -			} else {
 -				ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE);
 -			}
 -			MEMZERO(&mbs, sizeof (mbs));
 -			mbs.param[0] = MBOX_ABOUT_FIRMWARE;
 -			mbs.logval = MBLOGNONE;
 -			isp_mboxcmd(isp, &mbs);
 -			if (mbs.param[0] == MBOX_COMMAND_COMPLETE) {
 -				isp->isp_romfw_rev[0] = mbs.param[1];
 -				isp->isp_romfw_rev[1] = mbs.param[2];
 -				isp->isp_romfw_rev[2] = mbs.param[3];
 -			}
 -		}
 -		isp->isp_touched = 1;
 -	}
  
  	ISP_DISABLE_INTS(isp);
  
 @@ -279,13 +225,13 @@
  	}
  
  	/*
 -	 * Put the board into PAUSE mode (so we can read the SXP registers
 +	 * XXX: For 23xx and earlier, put the board into 
 +	 * PAUSE mode (so we can read the SXP registers
  	 * or write FPM/FBM registers).
  	 */
  	if (IS_24XX(isp)) {
  		ISP_WRITE(isp, BIU2400_HCCR, HCCR_2400_CMD_CLEAR_HOST_INT);
  		ISP_WRITE(isp, BIU2400_HCCR, HCCR_2400_CMD_CLEAR_RISC_INT);
 -		ISP_WRITE(isp, BIU2400_HCCR, HCCR_2400_CMD_PAUSE);
  	} else {
  		ISP_WRITE(isp, HCCR, HCCR_CMD_PAUSE);
  	}
 @@ -675,6 +621,61 @@
  		ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE);
  	}
  
 +	/*
 +	 * Basic types (SCSI, FibreChannel and PCI or SBus)
 +	 * have been set in the MD code. We figure out more
 +	 * here. Possibly more refined types based upon PCI
 +	 * identification. Chip revision has been gathered.
 +	 *
 +	 * After we've fired this chip up, zero out the conf1 register
 +	 * for SCSI adapters and do other settings for the 2100.
 +	 */
 +
 +	/*
 +	 * Get the current running firmware revision out of the
 +	 * chip before we hit it over the head (if this is our
 +	 * first time through). Note that we store this as the
 +	 * 'ROM' firmware revision- which it may not be. In any
 +	 * case, we don't really use this yet, but we may in
 +	 * the future.
 +	 */
 +	if (isp->isp_touched == 0) {
 +		/*
 +		 * First see whether or not we're sitting in the ISP PROM.
 +		 * If we've just been reset, we'll have the string "ISP   "
 +		 * spread through outgoing mailbox registers 1-3. We do
 +		 * this for PCI cards because otherwise we really don't
 +		 * know what state the card is in and we could hang if
 +		 * we try this command otherwise.
 +		 *
 +		 * For SBus cards, we just do this because they almost
 +		 * certainly will be running firmware by now.
 +		 */
 +		if (ISP_READ(isp, OUTMAILBOX1) != 0x4953 ||
 +		    ISP_READ(isp, OUTMAILBOX2) != 0x5020) {
 +		    	isp_prt(isp, ISP_LOGERR, "reset signature was invalid, RISC maybe paused");
 +			/*
 +			 * Just in case it was paused...
 +			 */
 +			if (IS_24XX(isp)) {
 +				ISP_WRITE(isp, BIU2400_HCCR,
 +				    HCCR_2400_CMD_RELEASE);
 +			} else {
 +			    ISP_WRITE(isp, HCCR, HCCR_CMD_RELEASE);
 +			    MEMZERO(&mbs, sizeof (mbs));
 +			    mbs.param[0] = MBOX_ABOUT_FIRMWARE;
 +			    mbs.logval = MBLOGNONE;
 +			    isp_mboxcmd(isp, &mbs);
 +			    if (mbs.param[0] == MBOX_COMMAND_COMPLETE) {
 +				isp->isp_romfw_rev[0] = mbs.param[1];
 +				isp->isp_romfw_rev[1] = mbs.param[2];
 +				isp->isp_romfw_rev[2] = mbs.param[3];
 +			    }
 +			}
 +		}
 +		isp->isp_touched = 1;
 +	}
 +
  	ISP_WRITE(isp, isp->isp_rqstinrp, 0);
  	ISP_WRITE(isp, isp->isp_rqstoutrp, 0);
  	ISP_WRITE(isp, isp->isp_respinrp, 0);
 @@ -738,6 +739,7 @@
  		mbs.logval = MBLOGALL;
  		isp_mboxcmd(isp, &mbs);
  		if (mbs.param[0] != MBOX_COMMAND_COMPLETE) {
 +		    	isp_prt(isp, ISP_LOGERR, "Mailbox Register Test mailbox command failed to complete");
  			ISP_RESET0(isp);
  			return;
  		}
 @@ -1832,7 +1834,6 @@
  	mbs.logval = MBLOGALL;
  	isp_mboxcmd(isp, &mbs);
  	if (mbs.param[0] != MBOX_COMMAND_COMPLETE) {
 -	    	isp_prt(isp, ISP_LOGERR, "setting firmware options failed");
  		return;
  	}
  
 @@ -2056,7 +2057,6 @@
  	isp_mboxcmd(isp, &mbs);
  	FC_SCRATCH_RELEASE(isp);
  	if (mbs.param[0] != MBOX_COMMAND_COMPLETE) {
 -	    	isp_prt(isp, ISP_LOGERR, "initialization of firmware fails");
  		return;
  	}
  	isp->isp_reqidx = 0;
 
 --Apple-Mail-13--61181355
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed
 Content-Transfer-Encoding: 7bit
 
 
 
 
 
 
 --Apple-Mail-13--61181355--

From: Ross West <westr@connection.ca>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization
Date: Wed, 25 Nov 2009 10:53:57 -0500

 Close pr please.
 
 Major rewrite/update of isp driver fixed this issue, since merged into
 MAIN + RELENG_8_0.
 
 See: SVN rev 196008 on 2009-08-01 01:04:26Z by mjacob for details.
 
 -- 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Thu Nov 26 09:54:42 UTC 2009 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126866 
>Unformatted:
