From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Moore, Eric" <Eric.Moore@lsi.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"Prakash, Sathya" <Sathya.Prakash@lsi.com>
Subject: RE: Sample implementation of a scheme to handle missing interrupts
Date: Sun, 03 Aug 2008 12:59:11 -0500 [thread overview]
Message-ID: <1217786351.4179.23.camel@localhost.localdomain> (raw)
In-Reply-To: <660360F4F2570145BD872F298951B17A3AC7E4BF@cosmail03.lsi.com>
On Tue, 2008-07-29 at 17:38 -0600, Moore, Eric wrote:
> On Monday, July 28, 2008 2:45 PM, James Bottomley wrote:
> > >
> > > In my case, the MSI problem will manifest itself well before we bind
> > > with the scsi midlayer. Meaning when there is a MSI problem, we
> > > can't even bring up the card. Hence adding code in a eh_timed_out
> > > callback handler would be meaningless in solving our problem. What I
> > > need to do is find a problematic card, so I can verify some things.
> >
> > Actually, you don't need this. I verified the behaviour of the MSI
> > problem simply by commenting out the request_irq. It looks
> > like there's
> > no simple way to simulate MSI misrouting, but perhaps I should look at
> > that, since it would be useful.
> >
>
> Well today I found at FC929X where it fails when MSI enabled. The problem is occuring at the end of mpt_do_ioc_recovery, after we enable interrupts, we are asking for random manufacturing config pages. I see it randomly timing out on the config pages, meaning some time GetLanConfigPages works, then other times it fails. Sometimes it fails later on for either GetIoUnitPage2 or mpt_get_manufacturing_pg_0. So its randomly timing out on config pages, but most the time is the first one. So did the following patch (hopefully its not butcherd by ccmail). What I'm doing is failling back to IOAPIC routing after we have a config page timeout. This works scsi_misc tip with drives attached to both channels of the multifunction FC card. I'm thinking we may still need do what Matt W. sugge
sted just as I pointed, I see random timeouts with the config pages. A side note, I found that pci_disable_msi() is not working in SLES10 SP2.. Did you have any other suggestion where th
is
> could be handled in a generic common method?
Actually, I think mpt_config is too deep. The first time we use it to
get a page is when the failure occurs ... I think that's the point we
can intercept and retry.
I'll send a common coded routine (plus a bit of generic infrastructure
to make this more standard) shortly.
James
prev parent reply other threads:[~2008-08-03 17:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-28 5:56 Sample implementation of a scheme to handle missing interrupts Matthew Wilcox
2008-07-28 9:50 ` Zhao Forrest
2008-07-28 11:58 ` Matthew Wilcox
2008-07-28 19:01 ` Moore, Eric
2008-07-28 20:45 ` James Bottomley
2008-07-29 23:38 ` Moore, Eric
2008-08-03 17:59 ` James Bottomley [this message]
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=1217786351.4179.23.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=Eric.Moore@lsi.com \
--cc=Sathya.Prakash@lsi.com \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/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