Another reboot hang

[Svatopluk Kraus]

On Tue, Apr 26, 2016 at 10:40 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> 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.

Hmm, it's third command which needs WITNESS option. I added 'show all
pcpu' on first place later and did not fix the reference. By breaking
to debugger repeatedly I mean -  type 'c' in ddb ('continue' command)
and then break to debugger again.


>
> Thanks for your help!
>
> bob prohaska
>