Eugene Grosbein
2017-Jan-14 11:40 UTC
stable/11 debugging kernel unable to produce crashdump
> 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! Eugene Grosbein
Mark Johnston
2017-Jan-14 22:16 UTC
stable/11 debugging kernel unable to produce crashdump
On Sat, Jan 14, 2017 at 06:40:02PM +0700, 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!Thanks, committed as r312199.
Eugene Grosbein
2017-Jul-23 09:26 UTC
stable/11 debugging kernel unable to produce crashdump again
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