Date: Mon, 9 Jun 2014 14:13:06 -0400 From: Chris Ross <cross+freebsd@distal.com> To: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD 10-STABLE/sparc64 panic Message-ID: <BC35853D-DA5E-4799-947C-4C64A0BC7D36@distal.com> In-Reply-To: <A9D37635-CA61-401B-BEAE-14C4F370BFD6@distal.com> References: <20140518083413.GK24043@gradx.cs.jhu.edu> <751F7778-95CE-40FC-857F-222FB37737C0@distal.com> <20140518235853.GM24043@gradx.cs.jhu.edu> <20140519145222.GN24043@gradx.cs.jhu.edu> <A092DFEB-D5CF-473E-88BD-81B005C26C57@distal.com> <20140519193529.GO24043@gradx.cs.jhu.edu> <20140519205047.GP24043@gradx.cs.jhu.edu> <CA75738D-066D-4EDC-9018-89936EE861C6@distal.com> <AB5649B5-BBFB-4284-9CFF-4784D28A18F3@distal.com> <A9D37635-CA61-401B-BEAE-14C4F370BFD6@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 20, 2014, at 10:45, Chris Ross <cross+freebsd@distal.com> wrote:
> For anyone else following along, and for my own records. Following
> my successes with r262743 and r262783, I moved well forward to
> r263980. Despite the first boot working successfully, I rebooted it
> again this morning, after it had been running for quite a few hours,
> and the panic occurred 6 times [=85]
Back a few weeks ago, after my failures with r263980, I compiled and
booted r263101, which booted on the first attempt 6 times across a span
of 3-4 days. I called that =93stable=94, and moved on to r263307 next=85
I ended up getting out of the pattern of testing things, but I know I =
ran
r263307 for weeks, and rebooted it anytime I remembered to, and never
saw it exhibit the failure.
This morning, I moved forward to r263508, which looks to be a very
large batch of MFC=92s to things in the kernel. This one fails, =
although once
it did bring up DHCP _before_ failing. But, most of the time if fails =
in the
same place, after configuring the bge0 interface. All the failures are =
still
the same backtrace:
spin lock 0xc0c61cb0 (smp rendezvous) held by 0xfffff8000552b240 (tid =
100342) too long
timeout stopping cpus
panic: spin lock held too long
cpuid =3D 1
KDB: stack backtrace:
#0 0xc051fcb0 at _mtx_lock_spin_failed+0x50
#1 0xc051fd78 at _mtx_lock_spin_cookie+0xb8
#2 0xc088771c at tick_get_timecount_mp+0xdc
#3 0xc0541ebc at binuptime+0x3c
#4 0xc085138c at timercb+0x6c
#5 0xc0887a80 at tick_intr+0x220
reboot in 15 seconds - press a key on the console to abort
Again, it failed many times running before eventually lucking into =
getting
all the way to multiuser.
More information for the records. I=92ll likely try to drop back just =
before
r263508 (r263478) since r263508 was so seemingly large, in case I=92ve
found the =93problem point=94. One can hope.
- Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC35853D-DA5E-4799-947C-4C64A0BC7D36>