linux-kernel - Re: Unhandled IRQs on AMD E-450

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+5PVA4NJ4fB-qEVB45sz48E7kCdwZ+O5D9jvk16z4hrXSgCwQ@mail.gmail.com>
Date:	Fri, 27 Apr 2012 09:49:16 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Jeroen Van den Keybus <jeroen.vandenkeybus@...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

On Fri, Apr 27, 2012 at 9:28 AM, Jeroen Van den Keybus
<jeroen.vandenkeybus@...il.com> wrote:
>> 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 ?

I'd have to go back and look through all the bug reports.  Essentially,
it wound up being "this used to work fine, now I get stuck in polling
mode".  When we dropped the patch in those cases, it went back to
working fine.

I'm not sure if it was a matter of a shared IRQ hitting quickly in
succession, or if it was really small bursts of spurious IRQs.

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

Yes, except the threshold was lowered from 100000 to 10 in the original
patch.  Apparently that's too low.

>> 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;
> +       }

Indeed.  Probably do.

josh
--
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/