lkml.org 
[lkml]   [2005]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] PCI: Add pci shutdown ability
    From
    Date
    tis 2005-04-26 klockan 11:11 -0400 skrev Alan Stern:
    > On Mon, 25 Apr 2005, Andrew Morton wrote:
    >
    > > I have vague memories of this being discussed at some length last year.
    > > Nothing comprehensive came of it, except that perhaps the kdump code should
    > > spin with irqs off for a couple of seconds so the DMA and IRQs stop.
    >
    > Like Pavel said, this won't work.
    >
    > > (Ongoing DMA is not a problem actually, because the kdump kernel won't be
    > > using that memory anyway)
    >
    > For PCI devices at least, DMA _can_ be disabled in a uniform way as
    > devices are discovered. Some platforms might not want to do this for fear
    > it would kill the initial console display.
    >
    > IRQs _cannot_ be disabled in a uniform way. So they remain a problem.
    >
    > > For kdump we really don't want to be doing fancy driver shutdown inside a
    > > crashed kernel. It would be better to just jump to the new kernel and
    > > to reset the hardware from there. DMA doesn't matter, and maybe IRQs can
    > > be handled with a sustained local_irq_disable() (hard).
    >
    > But at some point you have to enable local IRQs, and then you're in
    > trouble if a device without a driver is generating requests. Unless the
    > new kernel can run with interrupts entirely disabled? Seems pretty
    > unlikely.

    At least on x86 & x64 both i8259A and optional IOAPIC are initially
    fully masked until a driver decides to open up a line.

    If driver initialization fails then it should never open up the line on
    the interrupt controller. So this shouldn't be a problem with interrupts
    or am I missing something?
    Shared interrupt lines do present a problem however as someone else gets
    the chance to scream on an open line ultimately killing it, hmmm.

    > The real problem is that, in general, hardware _can't_ be reset properly
    > by a new kernel. There are things that can help, like the PCI USB quirks
    > code. That might be enough to handle the most pressing existing problems;
    > certainly it would avoid the USB issues we've seen. (But it needs to be
    > updated to avoid interfering with normal operations during
    > resume-from-disk.)



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

    \
     
     \ /
      Last update: 2005-04-26 18:13    [W:4.348 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site