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