From owner-freebsd-sparc64@FreeBSD.ORG Sun May 18 09:29:17 2014 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9053D9D for ; Sun, 18 May 2014 09:29:16 +0000 (UTC) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.cs.jhu.edu", Issuer "InCommon Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A591F29F9 for ; Sun, 18 May 2014 09:29:16 +0000 (UTC) Received: from gradx.cs.jhu.edu (gradx.cs.jhu.edu [128.220.13.52]) by blaze.cs.jhu.edu (8.14.4/8.14.4) with ESMTP id s4I8YEHd016575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 18 May 2014 04:34:14 -0400 Received: from gradx.cs.jhu.edu (localhost [127.0.0.1]) by gradx.cs.jhu.edu (8.14.8/8.14.5) with ESMTP id s4I8YEWh036576 for ; Sun, 18 May 2014 04:34:14 -0400 Received: (from nwf@localhost) by gradx.cs.jhu.edu (8.14.8/8.14.8/Submit) id s4I8YE3x036575 for freebsd-sparc64@freebsd.org; Sun, 18 May 2014 04:34:14 -0400 Date: Sun, 18 May 2014 04:34:14 -0400 From: Nathaniel W Filardo To: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD 10-STABLE/sparc64 panic Message-ID: <20140518083413.GK24043@gradx.cs.jhu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VSVNCtZB1QZ8vhj+" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 09:29:17 -0000 --VSVNCtZB1QZ8vhj+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I am experiencing this, too, after a recent fresh install of stable/10 on my V240 (2x1.53GHz). When /etc/rc.d/netif kicks in, bge0 announces its transition to DOWN, but all I get is the "b" of the next line, which is, I think, bge0 announcing its transition to UP. Curiously, setting net.link.log_link_state_change=0 seems to fix that particular bit of sadness sometimes, but not always. When it fails despite that, I am told: spin lock 0xc0742eb0 (smp rendezvous) held by 0xfffff8000827b240 (tid 100329) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: panic() at panic+0x1d4 _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x50 _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xb8 tick_get_timecount_mp() at tick_get_timecount_mp+0xdc binuptime() at binuptime+0x3c timercb() at timercb+0x6c tick_intr() at tick_intr+0x220 -- interrupt level=0xe pil=0x4 %o7=0xc02e19d4 -- smp_rendezvous_action() at smp_rendezvous_action+0x260 -- interrupt level=0x4 pil=0 %o7=0xc02bdbe0 -- sched_idletd() at sched_idletd+0x3a8 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 Uptime: 1m12s Once, the system, with net.link.log_link_state_change=0 in sysctl.conf managed to boot as far as bringing up pf and pflog before failing with a suspiciously similar panic: spin lock 0xc0742eb0 (smp rendezvous) held by 0xfffff8001904c000 (tid 100608) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: panic() at panic+0x1d4 _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x50 _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xb8 tick_get_timecount_mp() at tick_get_timecount_mp+0xdc binuptime() at binuptime+0x3c timercb() at timercb+0x6c tick_intr() at tick_intr+0x220 -- interrupt level=0xe pil=0x4 %o7=0xc02e19d4 -- smp_rendezvous_action() at smp_rendezvous_action+0xec -- interrupt level=0x4 pil=0 %o7=0xc02bdbe0 -- sched_idletd() at sched_idletd+0x3b8 fork_exit() at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 Uptime: 2m40s Manually bringing up bge0 (with net.link.log_link_state_change=0) at least got me a system where I could fetch the 10-RELEASE kernel.txz file. This bisection is going to be very painful, but here goes nothing. I don't know if this is informative or useless data. Hopefully the former. --nwf; --VSVNCtZB1QZ8vhj+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlN4cIUACgkQTeQabvr9Tc94ogCeLFvaiN0jtK9jzWw6UcFgls+M uJUAn2Ot2F3fwttyDp57UWKCOvAf+nxR =LY8L -----END PGP SIGNATURE----- --VSVNCtZB1QZ8vhj+--