linux-kernel - Re: "No handler for vector" patches don't work on some systems

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: <m1slce4b8r.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 09 Mar 2007 09:45:08 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Chuck Ebbert <cebbert@...hat.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: "No handler for vector" patches don't work on some systems

Chuck Ebbert <cebbert@...hat.com> writes:

> [sorry for the dup: this time to the right recipient]
>
> So far I've tried the simple "survive having no handler
> for a vector" patch and the preliminary 3-patch series
> that was in -mm for a while, and neither work on the
> Dell PowerEdge 29xx and 19xx systems. These servers
> have the Intel 5000X chipset with the 6700PXH PCI Hub
> with dual independent PCI-X busses, each with its own
> I/OxAPIC with 24 interrupts. The fixes do work on
> "simple" systems but not on these high-end ones.

Ok thanks for the report.  It sounds like there is another cause
for the problem in the Dell case.

The simple patch drops the interrupt handler but acknowledges the
hardware so if the driver can survive missing an interrupt we
should be ok.  With level triggered interrupts this should pretty
much be guaranteed as after the acknowledgement the unhandled
interrupt will be refired.

One of my internal test systems had a 6700PXH PCI hub (at least I
think that was the part) the E7520 chipset.  So I don't think it is
just a matter of the hardware.  Although I do recall Intel having an
errata out on that class of hardware for occasionally reordering
interrupt messages with the end of interrupt coming before the 
interrupt message itself.  Causing various things to get confused.
It would not surprise me if we were tickling some errata like that.

I would very much like to know if what I merged linus's tree helps.
It is a little more conservative, than my earlier patches.  I need
a way to reproduce this or to work closely with someone who is, because
this sounds like it has a different cause and I need to start with
that assumption.

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