Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Jul 2017 00:36:49 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        Mark Johnston <markj@FreeBSD.org>
Cc:        FreeBSD Stable <freebsd-stable@FreeBSD.org>, Alexander Motin <mav@freebsd.org>
Subject:   Re: stable/11 debugging kernel unable to produce crashdump again
Message-ID:  <59763031.7000109@grosbein.net>
In-Reply-To: <20170724172232.GA71482@wkstn-mjohnston.west.isilon.com>
References:  <587928B3.2050607@grosbein.net> <20170113193726.GC77535@wkstn-mjohnston.west.isilon.com> <587A0E12.7070205@grosbein.net> <59746BD5.5010301@grosbein.net> <20170724014445.GA20872@raichu> <59762849.5090208@grosbein.net> <20170724172232.GA71482@wkstn-mjohnston.west.isilon.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 0xffffffff80919c00
>> 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 before
>> crashdump generation but works just fine during normal system shutdown.
> 
> I think graid probably needs a treatment similar to r301173/r316032.
> g_raid_shutdown_post_sync() appears to be quite similar to the
> corresponding gmirror handler. In particular, it just attempts to mark
> the individual components as clean and destroy the GEOM, which is not
> really safe after a panic.
> 
> diff --git a/sys/geom/raid/g_raid.c b/sys/geom/raid/g_raid.c
> index 7a1fd8c5ce2e..aa2529d5466a 100644
> --- a/sys/geom/raid/g_raid.c
> +++ b/sys/geom/raid/g_raid.c
> @@ -2461,6 +2461,9 @@ g_raid_shutdown_post_sync(void *arg, int howto)
>  	struct g_raid_softc *sc;
>  	struct g_raid_volume *vol;
>  
> +	if (panicstr != NULL)
> +		return;
> +
>  	mp = arg;
>  	g_topology_lock();
>  	g_raid_shutdown = 1;
> 

I'r rather leave this to Alexander.

Funny thing is that it's not 100% hangs if I add some debugging printfs:
more printfs added, more probability that it does not hang and proceeds
to successfull crashdump generation. I use old "sc" console (not vt), if that matters.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59763031.7000109>