From: Grant Grundler <grundler@parisc-linux.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Grant Grundler <grundler@parisc-linux.org>,
Vivek Goyal <vgoyal@in.ibm.com>,
greg@kroah.com,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Fastboot mailing list <fastboot@lists.osdl.org>,
Morton Andrew Morton <akpm@osdl.org>,
Bodo Eggert <7eggert@gmx.de>,
Dipankar Sarma <dipankar@in.ibm.com>,
stern@rowland.harvard.edu, awilliam@fc.hp.com,
bjorn.helgaas@hp.com
Subject: Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
Date: Tue, 7 Jun 2005 10:21:43 -0600 [thread overview]
Message-ID: <20050607162143.GE29220@colo.lackof.org> (raw)
In-Reply-To: <m1slzuwkqx.fsf@ebiederm.dsl.xmission.com>
On Tue, Jun 07, 2005 at 03:59:18AM -0600, Eric W. Biederman wrote:
> > *lots* of PCI devices predate PCI2.3. Possibly even the majority.
>
> In general generic hardware bits for disabling DMA, disabling interrupts
> and the like are all advisory. With the current architecture things
> will work properly even if you don't manage to disable DMA (assuming
> you don't reassign IOMMU entries at least).
ISTR, pSeries (IBM), some alpha, some sparc64, and parisc (64-bit) require
use of the IOMMU for *any* DMA. ie IOMMU entries need to be programmed.
Probably want to make a choice to ignore those arches for now
or sort out how to deal with an IOMMU.
> Shared interrupts are an interesting case. The simplest solution I can
> think of for a crash dump capture kernel is to periodically poll
> the hardware, as if all interrupts are shared. At that level
> I think we could get away with ignoring all hardware interrupt sources.
Yes, that's perfectly ok. We are no longer in a multitasking env.
> Does anyone know of a anything that would break by always polling
> the hardware? I guess there could be a problem with drivers
> that don't understand shared interrupts, are there enough of those
> to be an issue.
PCI requires drivers support Shared IRQs.
A few oddballs might be broken but I expect networking/mass storage
drivers get this right.
grant
next prev parent reply other threads:[~2005-06-07 16:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-07 3:07 [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel Vivek Goyal
2005-06-07 5:07 ` Grant Grundler
2005-06-07 9:59 ` Eric W. Biederman
2005-06-07 16:21 ` Grant Grundler [this message]
2005-06-07 18:42 ` [Fastboot] " Eric W. Biederman
2005-06-08 4:02 ` Grant Grundler
2005-06-08 4:38 ` Eric W. Biederman
2005-06-08 6:38 ` Vivek Goyal
2005-06-08 11:23 ` Vivek Goyal
-- strict thread matches above, loose matches on Subject: below --
2005-06-07 11:56 Vivek Goyal
[not found] <4bExX-3uT-11@gated-at.bofh.it>
2005-06-04 12:38 ` Bodo Eggert
2005-06-04 10:57 Vivek Goyal
2005-06-04 15:35 ` Alan Stern
2005-06-04 18:26 ` Grant Grundler
2005-06-04 10:43 Vivek Goyal
2005-06-03 11:25 Vivek Goyal
2005-06-03 11:54 ` Richard B. Johnson
2005-06-03 15:24 ` Alan Stern
2005-06-03 18:26 ` Eric W. Biederman
2005-06-03 18:21 ` Greg KH
2005-06-03 18:36 ` Eric W. Biederman
2005-06-04 13:18 ` Denis Vlasenko
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=20050607162143.GE29220@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=awilliam@fc.hp.com \
--cc=bjorn.helgaas@hp.com \
--cc=dipankar@in.ibm.com \
--cc=ebiederm@xmission.com \
--cc=fastboot@lists.osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=vgoyal@in.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.