Re: stable/11 debugging kernel unable to produce crashdump again

On 25.07.2017 00:22, Mark Johnston wrote: > On Tue, Jul 25, 2017 at 12:03:05AM +0700, Eugene Grosbein wrote: >> Thanks, this helped: >> >> $ addr2line -f -e kernel.debug 0x80919c00 >> g_raid_shutdown_post_sync >> /home/src/sys/geom/raid/g_raid.c:2458 >> >> That is GEOM_RAID's

Re: stable/11 debugging kernel unable to produce crashdump again

I've often wondered why, for CAM at least, we don't automatically fall back to the dump way when scheduling is stopped rather than have two different interfaces and special knowledge of this in a lot of places... Warner On Mon, Jul 24, 2017 at 11:25 AM, Alexander Motin wrote:

Re: stable/11 debugging kernel unable to produce crashdump again

I guess that problem of g_raid_shutdown_post_sync in case of panic can be explained by the fact it tries to write clean metadata in regular (not dumping) way while system is already in panic mode and there is no proper scheduling. May be it could be just bypassed in case of dumping (should be

Re: stable/11 debugging kernel unable to produce crashdump again

On Tue, Jul 25, 2017 at 12:03:05AM +0700, Eugene Grosbein wrote: > Thanks, this helped: > > $ addr2line -f -e kernel.debug 0x80919c00 > g_raid_shutdown_post_sync > /home/src/sys/geom/raid/g_raid.c:2458 > > That is GEOM_RAID's g_raid_shutdown_post_sync() that hangs if called just >

Re: stable/11 debugging kernel unable to produce crashdump again

CCing mav@ as graid expert. On 24.07.2017 08:44, Mark Johnston wrote: >> 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"

Re: stable/11 debugging kernel unable to produce crashdump again

On 24.07.2017 08:44, Mark Johnston wrote: >> Sadly, this time 11.1-STABLE r321371 SMP hangs instead of doing crashdump: > > Is this amd64 GENERIC, or something else? Custom kernel, amd64. > >> >> - "call doadump" from DDB prompt works just fine; >> - "shutdown -r now" reboots the system

Re: stable/11 debugging kernel unable to produce crashdump again

On Sun, Jul 23, 2017 at 04:26:45PM +0700, Eugene Grosbein wrote: > 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:

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 >>

Re: 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 > >

Re: 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

Re: stable/11 debugging kernel unable to produce crashdump

On Sat, Jan 14, 2017 at 02:21:23AM +0700, Eugene Grosbein wrote: > Hi! > > I'm struggling to debug a panic in 11.0-STABLE/i386 that successfully > produces crashdump > but I want more information. So I've rebuilt my custom kernel to include > options INVARIANTS, WITNESS and DEADLKRES. Now any

stable/11 debugging kernel unable to produce crashdump

Hi! I'm struggling to debug a panic in 11.0-STABLE/i386 that successfully produces crashdump but I want more information. So I've rebuilt my custom kernel to include options INVARIANTS, WITNESS and DEADLKRES. Now any panic results in quick unclean reboot without crashdump generation. Serial