Re: GPF on boot with devmatch

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Mon, 12 Oct 2020 11:25:52 -0400
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_at_freebsd.org
>> <mailto:mav_at_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
Received on Mon Oct 12 2020 - 13:25:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC