From owner-freebsd-stable@freebsd.org Wed Jul 1 02:36:43 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3264D9910FE for ; Wed, 1 Jul 2015 02:36:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 16E0311FE; Wed, 1 Jul 2015 02:36:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 6ED311083; Wed, 1 Jul 2015 02:36:42 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 1 Jul 2015 02:36:40 +0000 From: Glen Barber To: Chris Ross Cc: Kurt Lidl , freebsd-stable@freebsd.org Subject: Re: New FreeBSD snapshots available: stable/10 (20150625 r284813) Message-ID: <20150701023640.GM5423@FreeBSD.org> References: <20150626174927.GA69720@FreeBSD.org> <559330CF.2050606@pix.net> <20150701001613.GH5423@FreeBSD.org> <55934CFB.7050407@pix.net> <56A9EB91-2F97-4096-99C8-26D3EFC13D2D@distal.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="duh3CSr7n2+wOT/l" Content-Disposition: inline In-Reply-To: <56A9EB91-2F97-4096-99C8-26D3EFC13D2D@distal.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 02:36:43 -0000 --duh3CSr7n2+wOT/l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross wrote: >=20 > Yeah, this is the same panic you, I, and others have been seeing on spa= rc64's > with bge's, or at least v240's (and one other IIRC) for many many months.= Thanks > for grabbing a core! >=20 > When I was trying to search for a commit that caused the change of beha= vior, > I had difficultly doing it, but it was well back in 2014. The "boots som= etimes" > makes this a hard one to track, but as I only have my production v240, al= so > makes it one I haven't spent as much time trying to find as I'd like. >=20 > Thank you for letting me know this issue isn't fixed, though, despite t= he other > success with this code. :-) >=20 > Hopefully your stacktrace can help figure out what is wrong. >=20 A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) Glen > - Chris >=20 > On Jun 30, 2015, at 22:14 , Kurt Lidl wrote: > > I got all excited and decided to give it a try on my dual-cpu > > V240 as well. I was able to get it installed, but it panics > > when booting off the mirrored ZFS drives. (Note: I have no > > reason to believe this is ZFS related.) > >=20 > > ---- snip, snip ---- > > Setting hostname: spork.pix.net. > > bge0: link state changed to DOWN > > spin lock 0xc0cb9e38 (smp rendezvous) held by 0xfffff80003e93240 (tid 1= 00340) too long > > timeout stopping cpus > > panic: spin lock held too long > > cpuid =3D 1 > > KDB: stack backtrace: > > #0 0xc0575380 at panic+0x20 > > #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 > > #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 > > #3 0xc08d7b9c at tick_get_timecount_mp+0xdc > > #4 0xc0583c88 at binuptime+0x48 > > #5 0xc08a3b8c at timercb+0x6c > > #6 0xc08d7f00 at tick_intr+0x220 > > Uptime: 29s > > Dumping 8192 MB (4 chunks) > > chunk at 0: 2147483648 bytes ... ok > > chunk at 0x100000000: 2147483648 bytes ... ok > > chunk at 0x1000000000: 2147483648 bytes ... ok > > chunk at 0x1100000000: 2147483648 bytes ... ok > >=20 > > Dump complete > > ---- snip, snip ---- > >=20 > > Now the thing that amazes me is that this happened > > the first three times after I did the install, and > > on the fourth boot, it didn't panic. And it was > > able to 'savecore' the crashdump. > >=20 > > Here's the stacktrace from the core.txt.0 file: > >=20 > > -Kurt > >=20 > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > > Loaded symbols for /boot/kernel/zfs.ko.symbols > > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > > Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. > > Loaded symbols for /boot/kernel/geom_mirror.ko.symbols > > Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. > > Loaded symbols for /boot/kernel/tmpfs.ko.symbols > > #0 0x00000000c05745bc in doadump (textdump=3D) > > at /usr/src/sys/kern/kern_shutdown.c:262 > > 262 savectx(&dumppcb); > > (kgdb) #0 0x00000000c05745bc in doadump (textdump=3D) > > at /usr/src/sys/kern/kern_shutdown.c:262 > > #1 0x00000000c0574fb0 in kern_reboot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:451 > > #2 0x00000000c0575358 in vpanic (fmt=3D0xc0b22fe0 "spin lock held too = long", > > ap=3D0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 > > #3 0x00000000c0575388 in panic (fmt=3D0xc0b22fe0 "spin lock held too l= ong") > > at /usr/src/sys/kern/kern_shutdown.c:687 > > #4 0x00000000c0558e18 in _mtx_lock_spin_failed (m=3D0xc0cb9e38) > > at /usr/src/sys/kern/kern_mutex.c:561 > > #5 0x00000000c0558ee0 in _mtx_lock_spin_cookie (c=3D0xfffff80003e93240, > > tid=3D18446735277669594832, opts=3D0, file=3D0x0, line=3D0) > > at /usr/src/sys/kern/kern_mutex.c:608 > > #6 0x00000000c08d7ba4 in tick_get_timecount_mp (tc=3D0xc0d13378) at sm= p.h:206 > > #7 0x00000000c0583c90 in binuptime (bt=3D0x1fa2da980) > > at /usr/src/sys/kern/kern_tc.c:188 > > #8 0x00000000c08a3b94 in timercb (et=3D0xc0d13308, arg=3D) > > at time.h:418 > > #9 0x00000000c08d7f08 in tick_intr (tf=3D0x1fa2dab20) > > at /usr/src/sys/sparc64/sparc64/tick.c:252 > > #10 0x00000000c00a11bc in tl1_intr () > > #11 0x00000000c08c934c in spinlock_exit () > > at /usr/src/sys/sparc64/sparc64/machdep.c:244 > > #12 0x00000000c08c9330 in spinlock_exit () > > at /usr/src/sys/sparc64/sparc64/machdep.c:240 > > #13 0x00000000c051a194 in cnputs (p=3D0x1fa2db11a "") > > at /usr/src/sys/kern/kern_cons.c:530 > > #14 0x00000000c05c06e0 in putchar (c=3D10, arg=3D0x1fa2db0c8) > > at /usr/src/sys/kern/subr_prf.c:437 > > #15 0x00000000c05bee90 in kvprintf (fmt=3D0xc0b2fb95 "", > > func=3D0xc05c02e0 , arg=3D0x1fa2db0c8, radix=3D10, ap=3D0x1= fa2db300) > > at /usr/src/sys/kern/subr_prf.c:655 > > #16 0x00000000c05bfe80 in _vprintf (level=3D5, flags=3D1, > > fmt=3D0xc0b2fb78 "%s: link state changed to %s\n", ap=3D0x1fa2db2f0) > > at /usr/src/sys/kern/subr_prf.c:281 > > #17 0x00000000c05c0270 in log (level=3D5, > > fmt=3D0xc0b2fb78 "%s: link state changed to %s\n") > > at /usr/src/sys/kern/subr_prf.c:308 > > #18 0x00000000c064ec28 in do_link_state_change (arg=3D0xfffff8000339680= 0, > > pending=3D1) at /usr/src/sys/net/if.c:2131 > > #19 0x00000000c05cab38 in taskqueue_run_locked (queue=3D0xfffff80003288= 000) > > at /usr/src/sys/kern/subr_taskqueue.c:342 > > #20 0x00000000c05cacec in taskqueue_run (queue=3D0xfffff80003288000) > > at /usr/src/sys/kern/subr_taskqueue.c:358 > > #21 0x00000000c05cae20 in taskqueue_swi_run (dummy=3D0x0) > > at /usr/src/sys/kern/subr_taskqueue.c:471 > > #22 0x00000000c0539cc4 in intr_event_execute_handlers (p=3D0xfffff80003= 295860, > > ie=3D0xfffff80003287e00) at /usr/src/sys/kern/kern_intr.c:1264 > > #23 0x00000000c053b86c in ithread_loop (arg=3D0xfffff8000324c080) > > at /usr/src/sys/kern/kern_intr.c:1277 > > #24 0x00000000c0536428 in fork_exit (callout=3D0xc053b780 , > > arg=3D0xfffff8000324c080, frame=3D0x1fa2db880) > > at /usr/src/sys/kern/kern_fork.c:1018 > > #25 0x00000000c00a1270 in fork_trampoline () > > #26 0x00000000c00a1270 in fork_trampoline () > > Previous frame identical to this frame (corrupt stack?) > > (kgdb) > >=20 > >=20 > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" > >=20 >=20 --duh3CSr7n2+wOT/l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVk1I4AAoJEAMUWKVHj+KTqmYP/0TM6DG1v22OJFXqEOrQkFHx +gay3EvanGIMaD3a1+xszGiF9ELoLJm8n00X1Hdb+rXWCSwaL8O8cB30RPZdHMgu UEzkDdkuGv796qvUl862L6Kn/UHbAdImKUHT4GZ5qgttpGpM4Pg2ZP7lK1RTIj9w hD3v03o0AxwbYkWaH0Gw7durqza67nvTpWfwPZUMo6zM0jCItNMLR9jh/iuCtMCZ YaJmqmR/Z0DxextfiNH/AhKezkofQEbh74zZn8CqoTGJik4CR2zyuQ+8gApbQW4i 7Ux3BLcn2+1w3mwN4T076lbcQLuqSCdX7sufLrScZ8AKpv/b9LwyJiIxKqJvK4Wm 6wklGONO+/DlgFB1PB/sFrUqIHffIsOsgIDCLqZEXDJMQP26H4mFReTzMrUqBbvV iE/6+RMb0vhxl2MNY5KEhhzZacGuszAM3oQ3jLak2030Dj3yXjji5wxDlDti0m5P tBO2qGZtShLZuZGS7LKvg0W5OeBVtT3NQa3ErCWX16l8L/dU1GHq1hTnFUKovgod fqoYj3nAOreUcbaYAm5un7YvOuvSuduGCCEfqRs7dCwyQ8G6BNQt+rx8BouaOPeI oJF2wHxjP38egnMa9YmS+frVNbaSJG/NJDbDhc6vDcp1g/s6UW2BbxXl73bzzUi9 nTDs0Q31VEj/RmciKi88 =hqvc -----END PGP SIGNATURE----- --duh3CSr7n2+wOT/l--