On 2020/11/27 18:50, Mark Kettenis wrote: > > Date: Fri, 27 Nov 2020 18:43:47 +0100 > > From: Marcus MERIGHI <[email protected]> > > > > [email protected] (Stuart Henderson), 2020.11.27 (Fri) 17:54 (CET): > > > On 2020/11/27 16:21, Marcus MERIGHI wrote: > > > > It happened again; anything I should do when "syncing disks..." is done? > > > > This time around it doesn't seem to finish "syncing disks..." and drop > > into ddb>. So it can't be rebooted via "boot reboot". Is there a way to > > reboot via the serial console? Sending a BREAK (~#) doesn't seem to do > > anything... > > > > > Can you try dowgrading the bios to 4.11.0.4? > > > https://pcengines.github.io/#mr-33 > > > > Will do, as soon as the machine is rebooted. Thanks for the pointer! > > (You mention 4.11.0.4, but your link goes to 4.11.0.5?) > > Frankly I think this issue is a kernel bug, where somehow the sysctl > code that reports on open files is racing against code that closes > those files or otherwise messes with the associated data structures. > I bet that if you stop the process that is doing those sysctl calls, > things will run stable again.
fstat was running on Marcus' machine. > Given what you wrote about the configuration of the machine I'd say > this is related to sockets and missing locking in/against the network > stack. Unfortunately the traces you showed so far don't really give > me any clues. >
