Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jan 2006 15:51:07 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        thierry@herbelot.com
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic: spin lock held too long (while rebooting)
Message-ID:  <200601231551.08474.jhb@freebsd.org>
In-Reply-To: <200601210705.11539.thierry@herbelot.com>
References:  <200601040806.37953.thierry@herbelot.com> <200601040838.49663.jhb@freebsd.org> <200601210705.11539.thierry@herbelot.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 21 January 2006 01:05, Thierry Herbelot wrote:
> Le Wednesday 4 January 2006 14:38, John Baldwin a =E9crit :
> > 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 th=
is=20
point, etc.  You can try this hack to see if it fixes it:

Index: vm_machdep.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /usr/cvs/src/sys/i386/i386/vm_machdep.c,v
retrieving revision 1.267
diff -u -r1.267 vm_machdep.c
=2D-- 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
                                    =20
The better fix is that we really should take CPUs offline more gracefully=20
during a shutdown (at least during an orderly shutdown).

=2D-=20
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =3D  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601231551.08474.jhb>