Re: Unhandled IRQs on AMD E-450

[Jeroen Van den Keybus]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/