Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 May 2014 04:34:14 -0400
From:      Nathaniel W Filardo <nwf@cs.jhu.edu>
To:        freebsd-sparc64@freebsd.org
Subject:   Re: FreeBSD 10-STABLE/sparc64 panic
Message-ID:  <20140518083413.GK24043@gradx.cs.jhu.edu>

next in thread | raw e-mail | index | archive | help

--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+--



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