Date: Sun, 20 Apr 1997 15:21:59 -0700 (PDT) From: Steve Passe <fsmp> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mpapic.c sys/i386/include mpapic.h Message-ID: <199704202221.PAA21068@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
fsmp 97/04/20 15:21:58
Modified: i386/include mpapic.h
i386/i386 mpapic.c
Log:
changed default behaviour from FAST_IPI to FAST_IPI_NOT.
added default #define for APICIPI_BANDAID.
The purpose of these changes is to create a short-term fix for the
APIC_IO freeze problem.
Undefining FAST_IPI changes the calls from inlines
to real functions, only real effect should be speed, and I can't see any
measurable difference so far.
APICIPI_BANDAID invokes a "lazy delivery" mode for IPIs where we bail out
after an arbitrary period, assumming we are in the "dead-lock" condition,
but that the IPI will eventually get delivered. The early exit should allow
the mplock to be freed, and the dead-lock to be avoided.
IF it still hasn't been delivered by the next call to apicIPI (and after
waiting a LONG time in this next call) we finally panic.
This new method may add some SLIGHT statistical chance of corrupted memory,
as we don't wait for the SMP_INVLTBL IPI to definately reach the target CPU,
but since the current model already has that failing (it's NOT sync'ed
with the target CPU(s)) I *think* its better than not using it. And it should
be much better than the possible disk corruption fron hitting big red to
unfreeze the system. To revert to the old behaviour change
i386/include/mpapic.h from:
#define FAST_IPI_NOT
#define APICIPI_BANDAID
to:
#define FAST_IPI
#define APICIPI_BANDAID_NOT
Revision Changes Path
1.11 +3 -2 sys/i386/include/mpapic.h
1.27 +37 -1 sys/i386/i386/mpapic.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704202221.PAA21068>