FreeBSD 10-STABLE/sparc64 panic

[Chris Ross]

On May 20, 2014, at 10:45, Chris Ross <cross+freebsd at 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 […]

 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 “stable”, and moved on to r263307 next…

  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’s 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 = 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’ll likely try to drop back just before
r263508 (r263478) since r263508 was so seemingly large, in case I’ve
found the “problem point”.  One can hope.

                                 - Chris