Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

2024-08-21 Thread Matthew L. Dailey
se locallocks=1. > > rick > > On Wed, Aug 21, 2024 at 7:29 AM Matthew L. Dailey > mailto:matthew.l.dai...@dartmouth.edu>> > wrote: > > Hi all, > > I posted messages to the this list back in February and March > > (https://lists.freebsd.org/arc

Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

2024-08-21 Thread Matthew L. Dailey
Hi all, I posted messages to the this list back in February and March (https://lists.freebsd.org/archives/freebsd-current/2024-February/005546.html) regarding kernel panics we were having with nfs clients doing hdf5 file operations. After a hiatus in troubleshooting, I had more time this summe

Re: FreeBSD panics possibly caused by nfs clients

2024-03-06 Thread Matthew L. Dailey
Posting a few updates on this issue. I was able to induce a panic on a CURRENT kernel (20240215), built with GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189 hours. The panic message and backtrace are below - please reach out directly if you'd like to have a look at the core.

Re: FreeBSD panics possibly caused by nfs clients

2024-02-20 Thread Matthew L. Dailey
Hi all, I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after about 24 hours. This is the one without any debugging, so it only confirms the fact that the panics we've been experiencing still exist in CURRENT. There was some disk issue that prevented the dump, so all I have i

Re: FreeBSD panics possibly caused by nfs clients

2024-02-19 Thread Matthew L. Dailey
Hi all, So I finally induced a panic on a "pure" ufs system - root and exported filesystem were both ufs. So, I think this definitively rules out zfs as a source of the issue. This panic was on 14.0p5 without debugging options, so the core may not be helpful. The panic and backtrace are below

Re: FreeBSD panics possibly caused by nfs clients

2024-02-16 Thread Matthew L. Dailey
Hi all, Before the week was out, I wanted to provide an update on this issue. Last weekend, I installed two VMs with CURRENT (20240208-82bebc793658-268105) - one on zfs and one on ufs - and built a kernel with this config file: include GENERIC ident THAYER-FULLDEBUG makeoptions DEBUG=-g op

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Matthew L. Dailey
On 2/9/24 4:18 PM, Mark Johnston wrote: > [You don't often get email from ma...@freebsd.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote: >> I had my first ke

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Matthew L. Dailey
I had my first kernel panic with a KASAN kernel after only 01:27. This first panic was a "double fault," which isn't anything we've seen previously - usually we've seen trap 9 or trap 12, but sometimes others. Based on the backtrace, it definitely looks like KASAN caught something, but I don't

Re: FreeBSD panics possibly caused by nfs clients

2024-02-09 Thread Matthew L. Dailey
On 2/9/24 11:04 AM, Mark Johnston wrote: > [You don't often get email from ma...@freebsd.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote: >> Good morning all, &

FreeBSD panics possibly caused by nfs clients

2024-02-08 Thread Matthew L. Dailey
ermining if it is ZFS specific would be the best > first step, I think? > > It would be good to post this to a mailing list like freebsd-current@, > since others might have some insite into this. (Although you are > not using freebsd-current@, that is where most developers read