[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPRPZsDDEYUf2a+=ZbwvFw+qJku0UvMLf0+eNDvw+FbinCbysA@mail.gmail.com>
Date: Fri, 27 Apr 2012 15:28:00 +0200
From: Jeroen Van den Keybus <jeroen.vandenkeybus@...il.com>
To: Josh Boyer <jwboyer@...il.com>
Cc: Borislav Petkov <borislav.petkov@....com>,
Clemens Ladisch <clemens@...isch.de>, andymatei@...il.com,
"Huang, Shane" <Shane.Huang@....com>,
Borislav Petkov <bp@...64.org>, linux-kernel@...r.kernel.org
Subject: Re: Unhandled IRQs on AMD E-450
> Apparently there are
> some pieces of hardware that generate a small number of spurious IRQs
> "normally" and lowering the threshold to such a small value caused
> those machines to kick into polling mode when they really didn't need
> to.
Hm. I'd really expect a spurious IRQ to happen as its name suggests:
spuriously. What kind of hardware behaves like this ?
> 1) While the quirk helps shield people without the buggy bridge, it
> doesn't help the case where people have the bridge, but they have no
> devices actually behind it. That means such setups hit the polling
> mode when they don't really need to as described above.
Curious, the polling mode is left until a new spurious IRQ is detected.
> 2) People, rightfully, complain that it makes inter-activity on their
> desktop pretty laggy. The mouse pointer jumps around a lot and key
> strokes are often missed. For a server class machine, I doubt it
> would matter much but Fedora is essentially a desktop distro so that
> tends to be a high priority.
Again, I am a bit surprised. However, according to your patch:
> + if (!irq_poll_and_retry)
> + if (likely(desc->irq_count < 100000))
> + return;
> + else
> + if (likely(desc->irq_count < 10))
> + return;
Don't you mean :
+ if (!irq_poll_and_retry) {
+ if (likely(desc->irq_count < 100000))
+ return;
+ }
+ else {
+ if (likely(desc->irq_count < 10))
+ return;
+ }
Jeroen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists