Date: Thu, 2 Oct 2014 09:36:09 -0400 From: Chris Ross <cross+freebsd@distal.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD 10-STABLE/sparc64 panic Message-ID: <32B71E26-EA09-4143-9E6F-CF4E033E9106@distal.com> In-Reply-To: <0686B43F-94CC-48BA-81B6-5FBEAF9713EC@distal.com> References: <CA75738D-066D-4EDC-9018-89936EE861C6@distal.com> <AB5649B5-BBFB-4284-9CFF-4784D28A18F3@distal.com> <A9D37635-CA61-401B-BEAE-14C4F370BFD6@distal.com> <BC35853D-DA5E-4799-947C-4C64A0BC7D36@distal.com> <D9350E94-1F01-4FFD-A51E-AD8761F5C9CF@distal.com> <E48E7175-310B-4449-B3E1-2058F9E681D0@distal.com> <323A3936-DE55-459A-B8AA-CFF463922F22@distal.com> <7DD7D2DC-A265-40D6-9995-16ABAF79C1FB@distal.com> <AF5EA0E6-860B-47DF-AC5E-6A45317C6092@distal.com> <456226AE-0712-4510-AEF5-2053F36F2181@distal.com> <20140929042249.GK43300@funkthat.com> <0686B43F-94CC-48BA-81B6-5FBEAF9713EC@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 1, 2014, at 22:53 , Chris Ross <cross+freebsd@distal.com> wrote:
> On Sep 29, 2014, at 00:22 , John-Mark Gurney <jmg@funkthat.com> wrote:
>> If you could get a core dump (call doadump) that'd be good, but dumping
>> the stack of the tid that held the spinlock too long would be a good
>> start..
>
> I fear I'm going to need some help doing this. I'm not sure what I need to
> do to get into ddb. (And, after that, I'm not sure how to dump the stack of
> the tld that held the spinlock)
Okay. I rebuilt GENERIC after adding options DDB, and found the following:
spin lock 0xc0ccbdb0 (smp rendezvous) held by 0xfffff8000559f6d0 (tid 100351) too long
timeout stopping cpus
panic: spin lock held too long
[...]
db> thread 100351
[ thread pid 299 tid 100351 ]
sched_switch+0x3e0: call cpu_switch
db> thread
[ thread pid 299 tid 100351 ]
sched_switch+0x3e0: call cpu_switch
db> bt
Tracing pid 299 tid 100351 td 0xfffff8000559f6d0
mi_switch() at mi_switch+0x19c
critical_exit() at critical_exit+0x9c
spinlock_exit() at spinlock_exit+0x8
turnstile_chain_unlock() at turnstile_chain_unlock+0x6c
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x9c
bge_init() at bge_init+0x5c
ether_ioctl() at ether_ioctl+0x70
M_PLIMIT() at M_PLIMIT+0x8
db> dump
Cannot dump: no dump device specified.
db>
Apparently, I don't have a dump device set, so I'll to fix that next and get a
core dump. I'm not sure, however, if what I provided above was the stack of
the tid as was requested. At least, it's not 100% consistent. Since I had a
DDB kernel running, while trying to get the system back up to multiuser, I did
get many more panic's to experiment with, and doing the same
"thread NNN", "bt" on many passes I sometimes got different results.
Perhaps I'm doing something wrong? Or worse, it may not be 100%
consistent. :-/
A pointer to what I need to do within ddb would be appreciated, if I'm
doing anything wrong (or suboptimmally), or any other instructions. I'll try
to get a dump device specified.
Thanks.
- Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32B71E26-EA09-4143-9E6F-CF4E033E9106>