public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: michael@ellerman.id.au
Cc: yhlu.kernel@gmail.com, Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Jesse Barnes <jbarnes@virtuousgeek.org>, Greg KH <greg@kroah.com>,
	David Miller <davem@davemloft.net>, Jeff Garzik <jeff@garzik.org>,
	linux-pci <linux-pci@atrey.karlin.mff.cuni.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Sathya Prakash <sathya.prakash@lsi.com>
Subject: Re: [PATCH] pci: let pci_device_shutdown to call pci_disable_msi
Date: Wed, 23 Apr 2008 06:08:09 -0700	[thread overview]
Message-ID: <m1hcdsoh1i.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <1208928277.9212.1.camel@concordia.ozlabs.ibm.com> (Michael Ellerman's message of "Wed, 23 Apr 2008 15:24:37 +1000")

Michael Ellerman <michael@ellerman.id.au> writes:

> On Tue, 2008-04-22 at 21:48 -0700, Yinghai Lu wrote:
>> this change
>> 
>> | commit 23a274c8a5adafc74a66f16988776fc7dd6f6e51
>> | Author: Prakash, Sathya <sathya.prakash@lsi.com>
>> | Date:   Fri Mar 7 15:53:21 2008 +0530
>> |
>> |     [SCSI] mpt fusion: Enable MSI by default for SAS controllers
>> |
>> | This patch modifies the driver to enable MSI by default for all SAS chips.
>> |
>> |     Signed-off-by: Sathya Prakash <sathya.prakash@lsi.com>
>> |     Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>> |
>> cause kexec RHEL 5.1 kernel fail.
>> 
>> root casue: the rhel 5.1 kernel still use INTx emulation.
>> and mptscsih_shutdown doesn't call pci_disable_msi to reenable INTx on kexec
> path
>> 
>> so try to call pci_disable_msi in shutdown patch
>
> How is kdump going to work? Your shutdown routine won't be called and
> you'll have the same problem in the 2nd kernel, won't you?

Taking a quick look our current msi initialization appears robust in
not assuming the state of the msi config bits.

So the only remaining problem is running older software that 
assumes the msi config bits are in the state they should be in
out of reset.

YH on that score it appears I goofed a little when I gave you
my suggestion on how to fix this in pci_disable_msi.

If we have crazy hardware that supports multi irqs in with
a plain msi capability.  During initialization we mask
all of the irqs.

from msi_capability_init:
        if (entry->msi_attrib.maskbit) {
                unsigned int maskbits, temp;
                /* All MSIs are unmasked by default, Mask them all */
                pci_read_config_dword(dev,
                        msi_mask_bits_reg(pos, is_64bit_address(control)),
                        &maskbits);
                temp = (1 << multi_msi_capable(control));
                temp = ((temp - 1) & ~temp);
                maskbits |= temp;
                pci_write_config_dword(dev,
                        msi_mask_bits_reg(pos, is_64bit_address(control)),
                        maskbits);
        }

So it appears to truly return to the reset state we should unmask
them all, instead of just that one.  Not that it matters in practice,
but handling that corner case would be polite.

Eric

  parent reply	other threads:[~2008-04-23 13:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-23  4:48 [PATCH] pci: let pci_device_shutdown to call pci_disable_msi Yinghai Lu
2008-04-23  5:24 ` Michael Ellerman
2008-04-23  6:08   ` Yinghai Lu
2008-04-23 13:08   ` Eric W. Biederman [this message]
2008-04-23 17:31     ` Yinghai Lu
2008-04-24  0:17     ` Michael Ellerman
2008-04-24  1:22       ` Yinghai Lu
2008-04-24  2:11         ` Yinghai Lu
2008-04-23 12:57 ` Eric W. Biederman
2008-04-23 17:32   ` Yinghai Lu
2008-04-23 21:56 ` [PATCH 1/2] pci/irq: restore mask_bits in msi shutdown -v3 Yinghai Lu
2008-04-23 21:58   ` [PATCH 2/2] pci/irq: let pci_device_shutdown to call pci_msi_shutdown v2 Yinghai Lu
2008-04-25  0:40   ` [PATCH 1/2] pci/irq: restore mask_bits in msi shutdown -v3 Yinghai Lu
2008-04-25 21:48   ` Jesse Barnes
2008-04-25 22:08     ` Yinghai Lu
2008-04-29 16:13       ` Jesse Barnes

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=m1hcdsoh1i.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=greg@kroah.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=michael@ellerman.id.au \
    --cc=mingo@elte.hu \
    --cc=sathya.prakash@lsi.com \
    --cc=yhlu.kernel@gmail.com \
    /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