Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Oct 2020 11:25:52 -0400
From:      Alexander Motin <mav@FreeBSD.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Xin LI <d@delphij.net>, FreeBSD Current <freebsd-current@freebsd.org>, Warner Losh <imp@freebsd.org>
Subject:   Re: GPF on boot with devmatch
Message-ID:  <385234b0-0ca4-cec6-6a2e-6dec0a84b0f0@FreeBSD.org>
In-Reply-To: <5e4f0439-08fa-7715-7672-05793d05cc6d@FreeBSD.org>
References:  <02fa309e-9467-f741-8092-974bfc145c9a@FreeBSD.org> <CANCZdfp_djyU_-UkRHy1eZEu_XLekc%2BYuA2=9k74=rbJFR3S0A@mail.gmail.com> <5e4f0439-08fa-7715-7672-05793d05cc6d@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 05.10.2020 17:39, Alexander Motin wrote:
> On 05.10.2020 17:20, Warner Losh wrote:
>> On Mon, Oct 5, 2020 at 12:36 PM Alexander Motin <mav@freebsd.org
>> <mailto:mav@freebsd.org>> wrote:
>>
>>     I can add that we've received report about identical panic on FreeBSD
>>     releng/12.2 of r365436, AKA TrueNAS 12.0-RC1:
>>     https://jira.ixsystems.com/browse/NAS-107578 .  So it looks a) pretty
>>     rate (one report from thousands of early adopters and none in our lab),
>>     and b) it is in stable/12 too, not only head.
>>
>> Thanks! I'll see if I can recreate here....  But we're accessing the
>> sysctl tree from devmatch to get some information, which should always
>> be OK (the fact that it isn't suggests either a bug in some driver
>> leaving bad pointers, or some race or both)...  It would be nice to know
>> which nodes they were, or to have a kernel panic I can look at...
> 
> All we have now in this case is a screenshot you may see in the ticket.
>  Also previously the same user on some earlier version of stable/12
> reported other very weird panics on process lock being dropped where it
> can't be in some other sysctls inside kern.proc, so if we guess those
> are related, I suspect there may be some kind of memory corruption
> happening, but have no clue where.  Unfortunately we have only textdumps
> for those.  So if Xin is able to reproduce it locally, it may be our
> best chance to debug it, at least this specific issue.

The TrueNAS user has confirmed that preloading the modules as Xin did
workarounds the problem for him also.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?385234b0-0ca4-cec6-6a2e-6dec0a84b0f0>