From owner-freebsd-stable@freebsd.org Wed Jul 1 02:29:07 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 1E2CA990F15 for ; Wed, 1 Jul 2015 02:29:07 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A285E2E8E for ; Wed, 1 Jul 2015 02:29:06 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200:0:0:0:ae25]) (authenticated bits=0) by hydra.pix.net (8.15.1/8.15.1) with ESMTPSA id t612Srl8004451 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2015 22:29:03 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Received: from magrathea.distal.com (magrathea.distal.com [206.138.151.12]) (authenticated bits=0) by mail.distal.com (8.14.9/8.14.9) with ESMTP id t612RVwR079441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jun 2015 22:27:32 -0400 (EDT) (envelope-from cross+freebsd@distal.com) Subject: Re: New FreeBSD snapshots available: stable/10 (20150625 r284813) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A0096BDE-297D-4BBB-B27A-204BBD33B7EB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Chris Ross In-Reply-To: <55934CFB.7050407@pix.net> Date: Tue, 30 Jun 2015 22:27:21 -0400 Cc: freebsd-stable@freebsd.org Message-Id: <56A9EB91-2F97-4096-99C8-26D3EFC13D2D@distal.com> References: <20150626174927.GA69720@FreeBSD.org> <559330CF.2050606@pix.net> <20150701001613.GH5423@FreeBSD.org> <55934CFB.7050407@pix.net> To: Kurt Lidl X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.distal.com [206.138.151.250]); Tue, 30 Jun 2015 22:27:32 -0400 (EDT) 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:29:07 -0000 --Apple-Mail=_A0096BDE-297D-4BBB-B27A-204BBD33B7EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yeah, this is the same panic you, I, and others have been seeing on = sparc64's with bge's, or at least v240's (and one other IIRC) for many many = months. Thanks for grabbing a core! When I was trying to search for a commit that caused the change of = behavior, I had difficultly doing it, but it was well back in 2014. The "boots = sometimes" makes this a hard one to track, but as I only have my production v240, = also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite = the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. - Chris 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 = 100340) 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 = long") > 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 = smp.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=3D0x1fa2db300) > 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=3D0xfffff80003396800, > pending=3D1) at /usr/src/sys/net/if.c:2131 > #19 0x00000000c05cab38 in taskqueue_run_locked = (queue=3D0xfffff80003288000) > 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=3D0xfffff80003295860, > 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.org" >=20 --Apple-Mail=_A0096BDE-297D-4BBB-B27A-204BBD33B7EB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVk1AUAAoJEPFBDnXvoNg0MCMQAIgO8ZfUiPb4/8nnnMOGrQCv UvyUVV6NG2HVyUHq9fkRIk3VOk5fslE8UZucr5bEZAhTKbK9ql0bY9ndakXsiIq4 L/Kgb1VCmLCzf/+PLEvOaO+fVljyOtOo7ygOWPL1xmwd1JCp6Fkg9RxjZ/L53gML yZvEJ0ox7NPhitO2T/ELLnkzbEpbqlQ0EWzVb9IfbaZO18GE+LZdWgWcC7hahzWY doDTP2yx/IkhoFPCkBB4l8aMj1X83ICOTyff/ImJG7Y8Tm8ara1ntc0Zq8Z9GOb+ CrHp4+iUPowBLjKOEcQnTXqLx1GhLSpY4u2XRg0/V1dWuP27gEKJh+gmDTilGisl YI1JSLnNM+WoLi/dn4p565KLtph2esK6HpNVNVfBJnP8PZfWQ8cC5FZWWv3M+SML 2RngdIUmxgPEF1BG8n/I2tR1iTlt2pYHhhEvkDmPyXqm8jzaW8mMwzSNXMCFLO3Y tNqsjTsB3ozmwjO7RoV3BTQQ4PUcIUQ254lWoY5cGWHWCCnA6+3CLtFN8rUDo67v GyDGTLbp7gNOej5jJwxWreLiUBD+XIBCFBsh1E79dBp4fg19m9CFsFcQ+WxkCl8Q QPfgs1k9VUSbeNFE2/LyjBGNlbJSvh94XgidfQ6Tn7/IBjaJe2HYFmCFE5D2LqNN XhfNgS15HSUboLXnAS+i =Lf9M -----END PGP SIGNATURE----- --Apple-Mail=_A0096BDE-297D-4BBB-B27A-204BBD33B7EB--