Date: Tue, 13 May 2014 18:27:58 -0400 From: Eric Benoit <eric@ecks.ca> To: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD 10-STABLE/sparc64 panic Message-ID: <53729c6e.TPfWjfi8cU4wuT0E%eric@ecks.ca> In-Reply-To: <CF3106DD-6A27-49C1-9A30-57C852151C35@distal.com> References: <536fdecc.JQrHYQJDeuWX7GXM%eric@ecks.ca> <8E36E49D-CD77-4B61-9BB4-A51109297E22@distal.com> <537092a9.hwZcQEw68NSGutSo%eric@ecks.ca> <687CCD82-F111-4285-A734-F006C135B5A6@distal.com> <53718e80.Tof6MSA85MMTLCRr%eric@ecks.ca> <CF3106DD-6A27-49C1-9A30-57C852151C35@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just to clarify for the list, this particular issue is concerning a panic as
reported a while back on this list. Specifically:
spin lock 0xc0c63f30 (smp rendezvous) held by 0xfffff80003a70920 (tid 100059) too long
timeout stopping cpus
panic: spin lock held too long
cpuid = 1
KDB: stack backtrace:
#0 0xc05214f0 at _mtx_lock_spin_failed+0x50
#1 0xc05215b8 at _mtx_lock_spin_cookie+0xb8
#2 0xc088999c at tick_get_timecount_mp+0xdc
#3 0xc054379c at binuptime+0x3c
#4 0xc085366c at timercb+0x6c
#5 0xc0889d00 at tick_intr+0x220
> > It should be noted that of course 10-STABLE on amd64 is fine, and
> > also on a V100, which is of course uniprocessor.
> Still with a bge? I'm suspecting it's related to the bge, but as
> you note, it could just be network subsystem in general.
No, the V100 has a pair of dc interfaces.
I tried pulling the network cable and that had it come up without issue. I
then tried hooking up a an offboard bge NIC, and that worked in that I was able
to configure that manually with dhclient, etc.
I turned on rc_debug to get an idea where it was failing, which seemed to be
after bringing up bge0. I saw mention of ipv6_activate_all_interfaces which
I haven't set, and indeed:
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
bge1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
I stopped the local router advertisement daemon briefly, and tested using the
original setup. Sure enough it came up as expected, minus a global IPv6
address (and routing).
It seems like it may be an issue with accepting IPv6 router advertisements,
at least when the system is first coming up. Once fully booted it seems fine.
Any ideas on how to proceed?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53729c6e.TPfWjfi8cU4wuT0E%eric>