Change Details

When sending an IPI, if a previous IPI was still pending delivery, native_lapic_ipi_vectored() would wait up to 50 ms for the previous IPI to be sent. If that time limit was reached, it would panic. I find no reason to impose this time limit, and a few reasons to remove it: We at Isilon have seen a few instances of this panic, with no obvious explanation. The most recent change to this time limit is commit f418f79ce299, which refers to the Intel Multiprocessor Specification v1.4 (1997). That spec only mentions an IPI timeout in the Application Processor Startup section (B.4). (Granted, that commit was focused on AP startup.) The APIC chapter of the Intel SDM is vague on the handling of the Delivery Status bit, but Section 2.3.5.1 of the x2APIC specification (2008) says the following, with no mention of a timeout: With the legacy xAPIC interface, system software would poll the delivery status bit until it is clear prior to sending an IPI. Similarly if the semantics of the send operation required that the interrupt be sent from the local xAPIC unit, then system software would busy-wait for the delivery status bit to be cleared. Linux and illumos wait forever. In Linux, see __default_send_IPI_shortcut() in arch/x86/kernel/apic/ipi.c. In illumos, see apic_send_ipi() in usr/src/uts/i86pc/io/pcplusmp/apic_common.c.

When sending an IPI, if a previous IPI is still pending delivery, native_lapic_ipi_vectored() waits for the previous IPI to be sent. We've seen a few inexplicable panics with the current timeout of 50 ms. Increase the timeout to 1 second and make it tunable. No hardware specification mentions a timeout in this case; I checked the Intel SDM, Intel MP spec, and Intel x2APIC spec. Linux and illumos wait forever. In Linux, see __default_send_IPI_shortcut() in arch/x86/kernel/apic/ipi.c. In illumos, see apic_send_ipi() in usr/src/uts/i86pc/io/pcplusmp/apic_common.c. However, misbehaving hardware could hang the system if we wait forever. MFC after: 1 week Sponsored by: Dell EMC Isilon

When sending an IPI, if a previous IPI wais still pending delivery, native_lapic_ipi_vectored() would wait up to 50 ms for the previousaits for the previous IPI to be sent. IPI to be sent. If thaWe've seen a few inexplicable panics with the current time limit was reached, it would panicout of 50 ms. Increase the timeout to 1 second and make it tunable. I find no reason to impose this time limit,No hardware specification mentions a timeout in this case; and a few reasons toI checked remove it: We at Isilon have seen a few instances of this panicthe Intel SDM, Intel MP spec, with no obviousand Intel x2APIC spec. Linux and illumos explanation. The most recent change to this time limit is commit f418f79ce299,wait forever. In Linux, see __default_send_IPI_shortcut() in which refers to the Intel Multiprocessor Specification v1.4 (1997).arch/x86/kernel/apic/ipi.c. In illumos, see apic_send_ipi() in That spec only mentions an IPI timeout in the Application Processorusr/src/uts/i86pc/io/pcplusmp/apic_common.c. However, misbehaving hardware Startup section (B.4). (Granted, that commit was focused on AP startup.) The APIC chapter of the Intel SDM is vague on the handling of the Delivery Status bit, but Section 2.3.5.1 of the x2APIC specification (2008) says the following, with no mention of a timeout:could hang the system if we wait forever. With the legacy xAPIC interface, system software would poll theMFC after: 1 week delivery status bit until it is clear prior to sending an IPI. Similarly if the semantics of the send operation required that the interrupt be sent from the local xAPIC unit, then system software would busy-wait for the delivery status bit to be cleared. Linux and illumos wait forever. In Linux, see __default_send_IPI_shortcut() in arch/x86/kernel/apic/ipi.c. In illumos, see apic_send_ipi() in usr/src/uts/i86pc/io/pcplusmp/apic_common.c.Sponsored by: Dell EMC Isilon