linux-kernel - Re: 2.6.24-rt1 IRQ routing anomaly

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 3 Mar 2008 09:31:00 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mark Hounschell <markh@...pro.net>
cc:	Jon Masters <jonathan@...masters.org>,
	Mark Hounschell <dmarkh@....rr.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: 2.6.24-rt1 IRQ routing anomaly

On Mon, 3 Mar 2008, Mark Hounschell wrote:
5B> >
> >
> Steve is correct. I have plenty of other choices. Steve, you mentioned, a "work around"
> is in -rt3. My only concern is does the current "work around" for other hardware really
> work or may I see this again with other "non cheap" hardware?

We have a work around for secondary IOAPICS, which sometimes shows this
behaviour (on non-cheap hardware).

The problem we have is that for some reason, IO-APICS with PCI-X chips get
confused when the interrupt line is masked. The work around that we
currently have (besides noapic) is to switch the interrupt to an edged
level interrupt instead of masking. We mark the interrupt as IN_PROGRESS
and if new interrupts come in from the same line, we can just flag them as
pending and return.

This works for some boxes. But this can cause problems for other boxes
that don't like having the interrupt being switched from level to edge and
back. For these boxes, the workaround must be disabled.

Then we have a third set of boxes where the masking causes wrong
interrupts (like what you were seeing) and the level/edge hack also causes
problems. For these boxes the only current solution is noapic.

The last solution to this, which is also our long term fix, is to add a
new interface for devices to let them disable the interrupt at the device
level (not masked at the IO-APIC). The disadvantage to this is the longer
time to traverse the PCI Bus, and added traffic on it. But the advantage
is not only a fix to this problem, but a way to figrane the priorities of
interrupts further than just the interrupt line. With this fix we can
create an interrupt thread per device. Also making the use of tasklets and
softirqs obsolete.  But this has a long way to go still.

>
> Is there a known list of hardware this problem is seen on?

We know of some, the list is still growing.

Jon, where are we on the "blacklist"?

-- Steve

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