Date: Thu, 6 May 2021 18:22:12 +0200 From: Michael Schmiedgen <schmiedgen@gmx.net> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: page fault while in kernel mode - after upgrade from 12.2 to 13.0 Message-ID: <b719e972-6237-84d2-6a77-f2eafeadd849@gmx.net> In-Reply-To: <YJQTMEuT0fLcpM1X@nuc> References: <d7c3bfbd-2e54-c0f4-ec23-5dab08287ea3@gmx.net> <YJBS8YMZFkMtWPEu@nuc> <d37716a3-927d-b200-c805-b31d7b36383d@gmx.net> <YJGaUnWCPVXRC4NC@nuc> <51a3abc5-76b9-df09-acbe-895b62ec87b3@gmx.net> <YJLmH7fcr57mnHpz@nuc> <90ed0277-9fcc-28c0-a546-c6a80babfa34@gmx.net> <YJQTMEuT0fLcpM1X@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06.05.2021 18:02, Mark Johnston wrote: > On Thu, May 06, 2021 at 06:00:05PM +0200, Michael Schmiedgen wrote: >> BTW, we got 2 other systems, also with userland NAT but different workl= oad. >> After an uncertain amount of time, mostly weeks, the natd starts to spi= n 100% >> CPU on these systems. Quick noobish workaround was restarting natd ever= y night. >> I saw your recent commits that applied some more safety in that area, d= o you >> plan to MFC these as well? I can imagine that could help with my NAT pr= oblems. > > I am skeptical that anything I did recently would fix this. Did you try > attaching a debugger to natd to see where it's getting stuck? Is it > also a regression from upgrading to 13.0? Unfortunately this was difficult to trigger, and when it did, networking s= topped working and these are remote machines. This was/is on 12, I plan to upgrad= e these in the near future and keep an eye on it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b719e972-6237-84d2-6a77-f2eafeadd849>