public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/2] pci: add misrouted interrupt error handling
Date: Tue, 05 Aug 2008 13:56:34 -0700	[thread overview]
Message-ID: <1217969794.9923.70.camel@localhost.localdomain> (raw)
In-Reply-To: <200808051353.52323.jbarnes@virtuousgeek.org>

On Tue, 2008-08-05 at 13:53 -0700, Jesse Barnes wrote:
> On Tuesday, August 05, 2008 1:44 pm James Bottomley wrote:
> > On Tue, 2008-08-05 at 10:03 -0700, Jesse Barnes wrote:
> > > This seems to be a function that just returns what type of IRQ you're
> > > using or how it's routed and it isn't necessarily "lost interrupt"
> > > specific.
> >
> > So perhaps this routine should only note but not advise?  The drivers
> > can then just call pci_interrupt_type to see if they can do anything.
> 
> If it's just a pci_irq_type function then it probably shouldn't print 
> anything, and leave that to the caller, since it might be used for other 
> purposes too (e.g. a driver load printk or something).  In the lost interrupt 
> case you already have to disable MSI or MSIX in the Fusion driver, so you may 
> as well put the printk there, right?  I guess I'm saying it should neither 
> note nor advise, just return the IRQ type.

Well, no; the object was to have the layer that knew (PCI) print
information which could be used to identify the problem.  Likely what
the driver will say is something like "MSI isn't working and it's not my
fault".  What I want is for PCI to print something that may be helpful
to people trying to diagnose the problem.  Driver writers aren't going
to get that right.

> > > This information is clearly useful to drivers both for informational
> > > purposes and for debugging problems, so on that front it looks good. 
> > > However, I think it should probably be called pci_interrupt_type(struct
> > > pci_dev *dev) or something instead, and just return an enum of either
> > > MSIX, MSI, or LINE (though I'm open to better names).  From that, the
> > > driver can infer what might be going wrong, though in the case of a LINE
> > > interrupt, all you can really do is report that there's probably a
> > > platform IRQ routing problem.
> >
> > The only thing that this can't do is ACPI ... but on the other hand once
> > the IRQ routing is set by ACPI I'm not sure the driver can do anything
> > to fix it.
> 
> Yeah, ACPI may or may not be the problem, all you'll really know is that 
> you've got a line interrupt that you failed to get...  The driver won't be 
> able to do much in that case aside from complain loudly.

Yes ... it's just that when line interrupts fail (especially if they
worked previously) it's usually ACPI to blame.

James



  reply	other threads:[~2008-08-05 20:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-03 18:02 [PATCH 1/2] pci: add misrouted interrupt error handling James Bottomley
2008-08-04  2:51 ` Matthew Wilcox
2008-08-04  3:46   ` James Bottomley
2008-08-04  4:30 ` Grant Grundler
2008-08-04 13:31   ` James Bottomley
2008-08-04 20:43 ` Bjorn Helgaas
2008-08-04 21:35   ` Matthew Wilcox
2008-08-04 22:20     ` Bjorn Helgaas
2008-08-05  0:02   ` James Bottomley
2008-08-05 15:42     ` Bjorn Helgaas
2008-08-05 17:03 ` Jesse Barnes
2008-08-05 20:44   ` James Bottomley
2008-08-05 20:53     ` Jesse Barnes
2008-08-05 20:56       ` James Bottomley [this message]
2008-08-05 21:15         ` Jesse Barnes
2008-08-05 21:54           ` James Bottomley
2008-08-07 16:03             ` Jesse Barnes
2008-08-07 17:20               ` Greg KH
2008-08-07 17:36                 ` James Bottomley
2008-10-23 21:55 ` 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=1217969794.9923.70.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.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