panic: spin lock held too long (while rebooting)
John Baldwin
jhb at freebsd.org
Mon Jan 23 13:00:03 PST 2006
On Saturday 21 January 2006 01:05, Thierry Herbelot wrote:
> Le Wednesday 4 January 2006 14:38, John Baldwin a écrit :
> > On Wednesday 04 January 2006 02:06 am, Thierry Herbelot wrote:
>
> [SNIP previous similar panic]
>
> > Next time you get this, can you use 'show threads' to figure out the tid
> > for the thread whose pointer is in the printf (0xc16de480 in this case)
> > and then do a trace of that thread?
>
> Hello,
>
> Here is a more detailed crash session :
>
> is this (zomb) problematic ? (in ps) :
> 8 c182e228 0 1 0 0002204 zomb[INACTIVE] g_mirror gm0s1
>
> I keep the machine in DDB, if there are more detailed commands to
> investigate the panic (the machine is an SMP BP6, runs a GENERIC current
> kernel, and stores its local files in two g_mirror partitions).
>
> The problematic spinlock is held by 0xc16de340 which is cpustop_handler.
>
> TfH
>
> PS : printout of the crash :
>
> # reboot
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining...3 2 2 2 0 0 done
> All buffers synced.
> Uptime: 39m52s
> GEOM_MIRROR: Device files1: provider mirror/files1 destroyed.
> GEOM_MIRROR: Device files1 destroyed.
> GEOM_MIRROR: Device gm0s1: provider mirror/gm0s1 destroyed.
> GEOM_MIRROR: Device gm0s1 destroyed.
> Rebooting...
> cpu_reset: Stopping other CPUs
> spin lock sched lock held by 0xc16de340 for > 5 seconds
> panic: spin lock held too long
Ok, it's not a fatal panic in that your disks should already be clean at this
point, etc. You can try this hack to see if it fixes it:
Index: vm_machdep.c
===================================================================
RCS file: /usr/cvs/src/sys/i386/i386/vm_machdep.c,v
retrieving revision 1.267
diff -u -r1.267 vm_machdep.c
--- vm_machdep.c 14 Nov 2005 00:43:44 -0000 1.267
+++ vm_machdep.c 23 Jan 2006 20:49:21 -0000
@@ -533,6 +533,7 @@
; /* Wait for other cpu to see that we've started */
stop_cpus((1<<cpu_reset_proxyid));
printf("cpu_reset_proxy: Stopped CPU %d\n", cpu_reset_proxyid);
+ disable_intr();
DELAY(1000000);
cpu_reset_real();
}
@@ -581,6 +582,7 @@
/* NOTREACHED */
}
+ disable_intr();
DELAY(1000000);
}
#endif
The better fix is that we really should take CPUs offline more gracefully
during a shutdown (at least during an orderly shutdown).
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current
mailing list