Date: Wed, 13 Jan 2021 18:18:32 -0700 From: Rebecca Cran <rebecca@bsdio.com> To: Warner Losh <imp@bsdimp.com>, Alexander Motin <mav@freebsd.org> 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: <1d27b217-1ce2-0075-3884-eed01ccd74d7@bsdio.com> In-Reply-To: <CANCZdfqGzeQFspsnNbAc2PUd0_JiEjSzmzeHqOZKZ=twr-Go3Q@mail.gmail.com> 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> <CANCZdfqGzeQFspsnNbAc2PUd0_JiEjSzmzeHqOZKZ=twr-Go3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/12/20 12:13 PM, Warner Losh wrote: > Xin Li's traceback lead to code I just rewrote in current, while this code > leads to code that's been there for a long time and hasn't been MFC'd. This > suggests that Xin Li's backtrace isn't to be trusted, or there's two issues > at play. Both are plausible. I've fixed a minor signedness bug and a > possible one byte overflow that might have happened in the code I just > rewrote. But I suspect this is due to something else related to how > children are handled after we've raced. Maybe there's something special > about how USB does things, because other buses will create the child early > and the child list is stable. If USB's discovery code is adding something > and is racing with devd's walking of the tree, that might explain it... It > would be nice if there were some way to provoke the race on a system I > could get a core from for deeper analysis.... I'm seeing this crash on 13-CURRENT main-c255937-g818390ce0ca-dirty when running GENERIC (but not on GENERIC-NODEBUG). I've uploaded the core dump etc. to https://bsdio.com/freebsd/crashes/2021-01-13-devmatch/ . -- Rebecca Cran
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d27b217-1ce2-0075-3884-eed01ccd74d7>