On 14.01.2017 18:40, Eugene Grosbein wrote:
> 
>> I suspect that this is because we only stop the scheduler upon a panic
>> if SMP is configured. Can you retest with the patch below applied?
>>
>> Index: sys/kern/kern_shutdown.c
>> ===================================================================
>> --- sys/kern/kern_shutdown.c (revision 312082)
>> +++ sys/kern/kern_shutdown.c (working copy)
>> @@ -713,6 +713,7 @@
>>              CPU_CLR(PCPU_GET(cpuid), &other_cpus);
>>              stop_cpus_hard(other_cpus);
>>      }
>> +#endif
>>  
>>      /*
>>       * Ensure that the scheduler is stopped while panicking, even if panic
>> @@ -719,7 +720,6 @@
>>       * has been entered from kdb.
>>       */
>>      td->td_stopsched = 1;
>> -#endif
>>  
>>      bootopt = RB_AUTOBOOT;
>>      newpanic = 0;
>>
>>
> 
> Indeed, my router is uniprocessor system and your patch really solves the 
> problem.
> Now kernel generates crashdump just fine in case of panic. Please commit the 
> fix, thanks!

Sadly, this time 11.1-STABLE r321371 SMP hangs instead of doing crashdump:

- "call doadump" from DDB prompt works just fine;
- "shutdown -r now" reboots the system without problems;
- "sysctl debug.kdb.panic=1" triggers a panic just fine but system hangs just 
afer showing uptime
instead of continuing with crashdump generation; same if "real" panic occurs.

Same for debug.minidump set to 1 or 0. How do I debug this?

Eugene Grosbein

_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to