[email protected] (Mark Kettenis), 2020.11.30 (Mon) 21:05 (CET): > > Date: Mon, 30 Nov 2020 19:12:19 +0100 > > From: Alexander Bluhm <[email protected]> > > > > On Thu, Nov 26, 2020 at 04:51:23PM +0100, Marcus MERIGHI wrote: > > > Starting stack trace... > > > panic(ffffffff81de557b) at panic+0x11d > > > kerntrap(ffff8000229c1630) at kerntrap+0x114 > > > alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b > > > fill_file(ffff800000ca8000,fffffd811c6a23d0,fffffd81012516f8,3,0,ffff800022735658) > > > at fil6 > > > sysctl_file(ffff8000229c1c58,4,b4769963000,ffff8000229c1c88,ffff8000227d8c98) > > > at sysctl_f2 > > > kern_sysctl(ffff8000229c1c54,5,b4769963000,ffff8000229c1c88,0,0) at > > > kern_sysctl+0x1d1 > > > sys_sysctl(ffff8000227d8c98,ffff8000229c1cf0,ffff8000229c1d50) at > > > sys_sysctl+0x184 > > > syscall(ffff8000229c1dc0) at syscall+0x389 > > > Xsyscall() at Xsyscall+0x128 > > > end of kernel > > > > This trace looks like a bug in the fstat sysctl. I guess that > > NET_LOCK() sleeps and the allprocess ps_list is not protected. > > Well, you're guessing here. The backtrace posted in the bug report > has the lines truncated, so we can't actually tell where it failed. > Can we have a proper backtrace for this bug?
The apu4 is back running, but hasn't paniced yet. Will try to get the untruncated output next time it panics. Marcus
