linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Linas Vepstas <linasvepstas@gmail.com>
To: Mike Mason <mmlnx@us.ibm.com>
Cc: linuxppc-dev@ozlabs.org, ellerman@au1.ibm.com, paulus@samba.org
Subject: Re: [PATCH] Only disable/enable LSI interrupts in EEH
Date: Tue, 10 Feb 2009 11:14:10 -0600	[thread overview]
Message-ID: <3ae3aa420902100914t572da49chf22b5fdda644033f@mail.gmail.com> (raw)
In-Reply-To: <4990EF8B.7060203@us.ibm.com>

2009/2/9 Mike Mason <mmlnx@us.ibm.com>:
> The EEH code disables and enables interrupts during the
> device recovery process.  This is unnecessary for MSI
> and MSI-X interrupts because they are effectively disabled
> by the DMA Stopped state when an EEH error occurs.  The current code is also
> incorrect for MSI-X interrupts.  It
> doesn't take into account that MSI-X interrupts are tracked
> in a different way than LSI/MSI interrupts.  This patch ensures only LSI
> interrupts are disabled/enabled.
>
> The patch also includes a couple minor formatting fixes.
>
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>

Looks good to me.
Acked-by: Linas Vepstas <linasvepstas@gmail.com>

On a somewhat-related note: there was an issue (I forget
the details) where the kernel needed to shadow some sort
of MSI state so that it could be correctly, um, kept-track-of,
after an EEH reset (it didn't need to be restored, because
firmware did this(?)).  After some digging around and
discussion, we concluded that some generic PPC MSI
code needed to be altered to track this state, and/or
the main kernel MSI code needed to be changed to
(not?) track this state.  Mike Ellerman seemed to best
grasp this area ... was this ever fixed?

Or perhaps this is an alternate fix for that bug? It may
well have been that calling the MSI disable triggered
the problem, I don't remember now.

--linas

  reply	other threads:[~2009-02-10 17:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10  3:07 [PATCH] Only disable/enable LSI interrupts in EEH Mike Mason
2009-02-10 17:14 ` Linas Vepstas [this message]
2009-02-10 23:38   ` Michael Ellerman
2009-02-10 23:46     ` Linas Vepstas
2009-02-10 21:12 ` Mike Mason
2009-02-10 23:39   ` Michael Ellerman
2009-02-12 16:06     ` Mike Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ae3aa420902100914t572da49chf22b5fdda644033f@mail.gmail.com \
    --to=linasvepstas@gmail.com \
    --cc=ellerman@au1.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mmlnx@us.ibm.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).