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 CranReceived on Thu Jan 14 2021 - 00:18:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC