archive mirror
 help / color / mirror / Atom feed
From: Edward Donovan <>
To: Linus Torvalds <>
Cc: Chris Palmer <>,
	Robert Hancock <>,
	Andrew Morton <>,
	Len Brown <>,,,,,,,,
	Thomas Gleixner <>, Ingo Molnar <>
Subject: Re: ASM1083 PCIx-PCI bridge interrupts - widespread problems
Date: Thu, 2 Feb 2012 15:22:44 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Feb 2, 2012 at 2:28 PM, Linus Torvalds
<> wrote:
> On Thu, Feb 2, 2012 at 11:20 AM, Edward Donovan
> <> wrote:
>> If we end up helpless with this chip, will we at least warn the user
>> that it's known to be buggy?  I dont' know if there's a standard
>> procedure when documenting bad hardware.
> That's probably a good idea.
> That said, the "switch to polled mode and then try to reenable every
> 100ms" approach sounds like a good idea regardless. The more robust we
> can be, the better.
> I realize that the people with *this* particular problem would
> probably want to reenable them even more often than 100ms or so, but
> that could lead to problems for people with seriously screaming
> interrupts (which has definitely happened too), so we need to balance
> those two issues out against each other.
> And we'd probably need to limit the warning messages if we start
> re-enabling it - so that people with constantly screaming interrupts
> don't get a constant stream of 10 "nobody cared, disabling" messages
> per second.
> So I'd take a tested patch that looks sane for both the "warning: this
> pcie-pci bridge is dodgy" and for the "try polling, then re-enable for
> a while" approach.

I don't have the bad chip, so I won't try to work that up myself.  And
I'd have to ponder before trying the generic parts of this.  But let
me see if I'm following you.  Is that, potentially, these two or three

* New logic in the generic IRQ code, in spurious.c, adding a "try
polling, then re-enable for
 a while" method, for everybody?

* A warning message about ASM1083, under arch/ or drivers/ ?  A better
place for special checks, than the genirq code.  (Right?)

* Could there be more hardware-specifc code, to crank up the
frequency, when you do have this chip?  I don't think we have this
facility at present: would we let the arch-or-drivers code set a
variable, to be honored by irq/spurious.c?

I speak with hastiness and naivete, especially on that last one.  I
imagine you and Ingo and Thomas have considered such possibly-lousy
ideas a lot more than me, so I hope wisdom will be dispensed.



  reply	other threads:[~2012-02-02 20:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2012-01-30 15:04   ` ASM1083 PCIx-PCI bridge interrupts - widespread problems Chris Palmer
2012-01-31  2:12     ` Robert Hancock
2012-01-31 12:08       ` Chris Palmer
2012-02-02 19:20         ` Edward Donovan
2012-02-02 19:28           ` Linus Torvalds
2012-02-02 20:22             ` Edward Donovan [this message]
2012-02-02 21:39               ` Clemens Ladisch
2012-02-02 22:41               ` Jeroen Van den Keybus
2012-02-03  1:59                 ` Edward Donovan
2012-02-03  8:51                   ` Müller Keve

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).