Date: Tue, 26 Apr 2016 13:40:16 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Svatopluk Kraus <onwahe@gmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Another reboot hang Message-ID: <20160426204016.GO71221@www.zefox.net> In-Reply-To: <CAFHCsPU94vrXgHRSNPvwAFNE0Hnd-6zzhsCSUGDGkVyGQ6jNMg@mail.gmail.com> References: <20160426183030.GN71221@www.zefox.net> <CAFHCsPU94vrXgHRSNPvwAFNE0Hnd-6zzhsCSUGDGkVyGQ6jNMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 26, 2016 at 10:18:24PM +0200, Svatopluk Kraus wrote: > > exception_exit() at exception_exit > > pc = 0xc05687fc lr = 0xc0515a44 (ffs_sync+0x104) > > sp = 0xd75ebb88 fp = 0xd75ebba8 > > r0 = 0x00000004 r1 = 0xc3a5f000 > > r2 = 0xc3fdb2c0 r3 = 0xc3a5f000 > > r4 = 0xc0620546 r5 = 0x00000001 > > r6 = 0xc3fdb2c0 r7 = 0x00000608 > > r8 = 0x00000000 r9 = 0xc3fdb2b0 > > r10 = 0xd75ebbf0 r12 = 0xc061cf05 > > The break to debugger happened here. So system was in > __mtx_lock_flags() called from ffs_sync(). It's impossible to say from > the backtrace if system was stuck or you just break it there. However, > interrupts was working, so system was not dead totally. One method how > to learn more is to break to debugger repeatedly to see if system is > stuck to one place or not. You also can try to type the following > commands in ddb to see if there is any deadlock. > > show all pcpu > show all procs > show all locks > > For the second command, kernel must be built with WITNESS option. > In past occurences I've waited considerably longer than the normal reboot time, so it really did seem stuck. The hangs aren't repeatable, so I'll try the first and third comands at the next opportunity and turn on WITNESS as a last resort; it really slows the machine down. Thanks for your help! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160426204016.GO71221>