On Wed, 2008-04-23 at 06:08 -0700, Eric W. Biederman wrote:
quoted text
> Michael Ellerman <michael@ellerman.id.au> writes:
>=20
> > On Tue, 2008-04-22 at 21:48 -0700, Yinghai Lu wrote:
> >> this change
> >>=20
> >> | 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.
quoted text
> >> |
> >> |     Signed-off-by: Sathya Prakash <sathya.prakash@lsi.com>
> >> |     Signed-off-by: James Bottomley <James.Bottomley@HansenPartnershi=
p.com>
quoted text
> >> |
> >> cause kexec RHEL 5.1 kernel fail.
> >>=20
> >> 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
quoted text
> > path
> >>=20
> >> 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?
>=20
> Taking a quick look our current msi initialization appears robust in
> not assuming the state of the msi config bits.

But does that help us? What if the device driver in the 2nd kernel
assumes it's using INTX, when in fact MSI is enabled on the device. In
that case none of the MSI code will even be called AFAIK.

cheers

--=20
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person