Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel

From: Grant Grundler (grundler_at_parisc-linux.org)
Date: 06/07/05

  • Next message: Alan Cox: "Re: Overcommit problems with 2.6.12-rc4 (on AMD64)" 
    Date:	Tue, 7 Jun 2005 10:21:43 -0600
To: "Eric W. Biederman" <ebiederm@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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Alan Cox: "Re: Overcommit problems with 2.6.12-rc4 (on AMD64)"

    Relevant Pages

    • Re: timing code in 2.6.1
      ... The hardware doesn't produce an interrupt ... For medical equipment which affects patient safety, ... These will produce interrupts. ... very likely that you need accurate and consistent time intervals ...
      (Linux-Kernel)
    • Re: [Fastboot] Re: [RFC/PATCH] Kdump: Disabling PCI interrupts in capture kernel
      ... >> you don't reassign IOMMU entries at least). ... >> the hardware, as if all interrupts are shared. ... I guess there could be a problem with drivers ...
      (Linux-Kernel)
    • Re: Stopping execution
      ... ages" of the 8 bit 8085, I understood something about interrupts. ... That driver tells the OS that a hardware event has ... certain system event" slow down the acutal execution of a bit of code ... slowdown due to the OS' kernel having to do something. ...
      (microsoft.public.vc.language)
    • Re: Help on: How to avoid placing millions of software checkpoints
      ... I have a programming problem/challenge. ... is responsible for handling hardware. ... The problem arises when the hardware receives a "stop command". ... Using interrupts doesn't seem to help me ...
      (comp.lang.c)