Port-sparc64 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: U2 panic: "!cpu_intr_p()" failed
Hi Martin,
> I'll try and add some debugging around this and see what I can spot.
So, with some debugging in xc__highpri_intr(), I can see that ci_idepth is
1 just before we crash (not unexpectedly). So, I added more debugging.
With the appended diff, I don't see the crash. Guessing that something
with the extra time spend in xc_highpri() is changing the timing. With
the commented out part, I saw:
[ 1.2900220] xc_highpri: cur_cpu = 1, ci = 1717792621
and later:
[ 2.4700180] cpu0: data fault: pc=13fadb4 rpc=178901bc8 addr=0
[ 2.4700180] kernel trap 30: data access exception
ci->cpuid seems bogus, but does that mean that ci was bogus as well? I'll
see if I can get more debugging when it does crash.
Regards,
Julian
- - - - - 8< - - - - - - - - - - - - - - - - - - - - - - - - - 8< - - - - - -
Index: subr_xcall.c
===================================================================
RCS file: /cvsroot/src/sys/kern/subr_xcall.c,v
retrieving revision 1.26
diff -u -r1.26 subr_xcall.c
--- subr_xcall.c 7 Feb 2018 04:25:09 -0000 1.26
+++ subr_xcall.c 28 Jun 2019 21:22:13 -0000
@@ -432,6 +432,13 @@
void *arg1, *arg2;
xcfunc_t func;
+ int i;
+ struct cpu_info *ci;
+
+ i = cpu_intr_p();
+ ci = curcpu();
+ printf("xc_highpri_intr: cpu_intr_p returned %d on %u\n", i, ci->ci_cpuid);
+
KASSERTMSG(!cpu_intr_p(), "high priority xcall for function %p",
xc->xc_func);
/*
@@ -491,6 +498,11 @@
#else
#ifdef MULTIPROCESSOR
kpreempt_disable();
+ printf("xc_highpri: cur_cpu = %d\n",curcpu()->ci_cpuid);
+ /*
+ printf("xc_highpri: cur_cpu = %d, ci = %d\n", curcpu()->ci_cpuid,
+ ci->ci_cpuid);
+ */
if (curcpu() == ci) {
/* Unicast: local CPU. */
xc_ipi_handler();
Home |
Main Index |
Thread Index |
Old Index