Date: Mon, 15 Sep 2008 17:34:04 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: "Ross West" <westr@connection.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: kern/126866: [isp] [panic] kernel panic on card initialization Message-ID: <3c0b01820809151434g61caec66s44c87e122ce786b2@mail.gmail.com> In-Reply-To: <200809151610.m8FGA4Jh025158@freefall.freebsd.org> References: <200809151610.m8FGA4Jh025158@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ross:
On Mon, Sep 15, 2008 at 12:10 PM, Ross West <westr@connection.ca> wrote:
> The following reply was made to PR kern/126866; it has been noted by GNATS.
>
> 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;
> + }
>
I have more patches and that's why I haven't submitted them formally.
Was going to run it by jkim (friend and colleague) as well.
We have some other issues:
- 6.x tree won't load any firmware because the code was removed (I
have a patch to put it back for <7.x releases) in favor of the generic
firmware stuff (but that doesn't work on 6.x to my knowledge) - I'm
surprised no one has reported this, if so point me to the bugzilla so
we can clean up
- the above line has to be trimmed, the check for 0x2020 is WRONG
since that is checking for the ISP ID (2422, 2312, etc.) - I
discovered that late last week
- have to revise slightly the above patch since the ABOUT FIRMWARE
command really doesn't do anything after the ISP has been reset and
the firmware hasn't been executed (its harmless but needs to be moved
out there)
- there are some target mode panics running around that I have not had
a chance to look at (damn day job) - maybe they should be new
bugzilla's (I'll ask the parties involved to file some)
- don't try to load the isp_*_it versions of firmware for any FC
release (need to incorporate that as well)
Can I have a couple of days to send in a revised patch to fix the
above issue as well as some others?
It would be good for 6.x and 7 (haven't tested it against HEAD).
Sorry for being silent about this, I meant to update the incident
myself, just swamped with other stuff right now!!! :D
-aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820809151434g61caec66s44c87e122ce786b2>