Hi folks,
I see a (more or less reproducable) problem that looks like a softint
is scheduled on cpu0 but fires on cpu1. It then hits a KASSERT since
on
that cpu the sofint is not marked si_active.
I added some instrumentation and couldn't explain things unless in
softint_overlay the l_cpu pointer of the passed lwp is not curcpu(),
so
I added a KASSERT to verify.
Unfortunately with that change I have never been able to reproduce
the problem
again.
Index: kern_softint.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_softint.c,v
retrieving revision 1.29
diff -u -p -r1.29 kern_softint.c
--- kern_softint.c 19 Jul 2009 10:11:55 -0000 1.29
+++ kern_softint.c 29 Oct 2009 13:41:28 -0000
@@ -720,6 +730,7 @@ softint_overlay(void)
si = ((softcpu_t *)ci->ci_data.cpu_softcpu)->sc_int;
KASSERT((l->l_pflag & LP_INTR) == 0);
+ KASSERT(ci == curcpu());
/* Arrange to elevate priority if the LWP blocks. */
s = splhigh();
Now if I can trust my eyes I did write ==, not =, so the problem going
away suprises me a bit.
Anybody got an idea that does not boild down to "cache coherency
problem
at CPUINFO_VA"?