mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Chuck Ebbert <cebbert@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: "No handler for vector" patches don't work on some systems
Date: Fri, 09 Mar 2007 09:45:08 -0700	[thread overview]
Message-ID: <m1slce4b8r.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <45F188ED.7030202@redhat.com> (Chuck Ebbert's message of "Fri, 09 Mar 2007 11:18:53 -0500")

Chuck Ebbert <cebbert@redhat.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

  reply	other threads:[~2007-03-09 16:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-09 16:18 Chuck Ebbert
2007-03-09 16:45 ` Eric W. Biederman [this message]
2007-03-09 17:24   ` Chuck Ebbert
2007-03-09 17:45     ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2007-03-09 16:16 Chuck Ebbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1slce4b8r.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=cebbert@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome