lkml.org 
[lkml]   [2007]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: PATCH/RFC: [kdump] fix APIC shutdown sequence
    Date
    Martin Wilck <martin.wilck@fujitsu-siemens.com> writes:

    > Hello Eric,
    >
    >> How bad is it if you just run with irqpoll in the kdump kernel?
    >> If running with irqpoll is usable that is probably preferable
    >> to putting in a hardware work around we can survive without.
    >
    > Yes, I tried that. No effect.

    Ok. Later in the thread it sounds like you have retried this and
    irqpoll is working now.

    >> Have you done any looking at moving where the kernel initalizes
    >> io_apics? One of the todo items on the path is to leave
    >> io_apic mode enabled and just startup the kernel in io_apic
    >> mode.
    >
    > I have tried to recover from the "IRR set" situation in several ways by
    > changing setup_IO_APIC_irq(). But I haven't found a way to recover from
    > this situation once disable_IO_APIC() had been called.

    Yes. The long term goal is to remove the need for calling
    disable_IO_APIC(). Because that makes the code simpler etc.

    Once we get the kernel to the point where it can start in
    ioapic mode (and not in i8259 mode) we can remove the
    disabled code from the kexec on panic path.

    > I concluded thatthe sequence of events
    > "send INT message - never receive EOI - disable IO-APIC pin"
    > messes up the IO-APIC (at least this specific one in the
    > PCIEx-PCI bridge of the ICH7).

    It is quite possible. I have observed a lot of obscure bugs in the
    corner cases of the state machines, although it is possible
    this is correct behavior and it is just specific to level
    triggered interrupts which are almost exclusively not on
    the first ioapic in a system like you describe.

    I suspect the issue is that we never send the EOI message from
    the local apic, and so it waits forever. Or that we have
    reprogrammed the vectors by the time we send the EOI message
    so that the EOI and the ioapic don't agree on the vector
    number when the EOI message is sent. Grumble silly level
    triggered interrupts grumble.

    Eric
    -
    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: 2007-08-08 17:29    [W:0.046 / U:30.936 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site