They will have just been cut off by your terminal, it happens sometimes
after some control sequences. Recording the output with script or ~R in cu
should have the full lines (or use conserver and a logfile).
--
Sent from a phone, apologies for poor formatting.
On 1 December 2020 07:48:39 Marcus MERIGHI <[email protected]> wrote:
[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
