Date: Wed, 17 Jan 2024 12:07:13 +0200 From: Konstantin Belousov <kib@freebsd.org> To: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uspoerlein@gmail.com> Cc: stable@freebsd.org, Rick Macklem <rick.macklem@gmail.com> Subject: Re: Repeatable nfs_readdir kernel panic after upgrade to stable/14 Message-ID: <Zaem0abAxKFYG4HY@kib.kiev.ua> In-Reply-To: <CAJ9axoS5SuZid6dihAWzPgg7xyRj8LX86Pq4ckM5FFaFRBVYOw@mail.gmail.com> References: <CAJ9axoS5SuZid6dihAWzPgg7xyRj8LX86Pq4ckM5FFaFRBVYOw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 17, 2024 at 10:28:01AM +0100, Ulrich Spörlein wrote: > Hey there, > upgraded my NFS server and laptop (NFS client) to stable/14 over the > weekend and now anything "intensive" that reads from NFS seems to kernel > panic. > > I think this started when I upgraded the server first, shrugged it off as > some overload on the laptop, finished the laptop upgrade to 14 and now > everytime I open easytag on the NFS automounted directory, or browsing > photos with geeqie it locks up hard. > > Mounts on the client currently look like so: > > map /etc/auto_tank on /tank (autofs) > map -media on /media (autofs) > 192.168.0.151:/tank/music on /tank/music (nfs, automounted) > > I'm not even sure if I'm using NFS3 or 4 or whether I'm using the ZFS based > one, I've set this up ages ago. > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 02 > fault virtual address = 0x89 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80eee094 > stack pointer = 0x28:0xfffffe01268c0830 > frame pointer = 0x28:0xfffffe01268c0830 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 74673 (easytag) > rdi: 0000000000000000 rsi: ffffffff819bff08 rdx: 0000000000000000 > rcx: 0000000000000000 r8: fffffe003781e0f0 r9: fffff8001ab51740 > rax: 0000000000000000 rbx: fffff8001ab51740 rbp: fffffe01268c0830 > r10: ffffffff00000000 r11: fffffe01268c07b0 r12: fffffe003781e0f0 > r13: fffff8047ac47700 r14: fffffe012ac1ba38 r15: fffff80437cac000 > trap number = 12 > panic: page fault > cpuid = 1 > time = 1705480771 > KDB: stack backtrace: > #0 0xffffffff80b9d68d at kdb_backtrace+0x5d > #1 0xffffffff80b4f95f at vpanic+0x12f > #2 0xffffffff80b4f823 at panic+0x43 > #3 0xffffffff8102902f at trap_fatal+0x40f > #4 0xffffffff8102907f at trap_pfault+0x4f > #5 0xffffffff80ffef48 at calltrap+0x8 > #6 0xffffffff80a3a3fe at ncl_bioread+0xb7e > #7 0xffffffff80a2c0a0 at nfs_readdir+0x1f0 > #8 0xffffffff80c217aa at vop_sigdefer+0x2a > #9 0xffffffff81100280 at VOP_READDIR_APV+0x20 > #10 0xffffffff846af5ae at autofs_readdir+0x2ce > #11 0xffffffff81100280 at VOP_READDIR_APV+0x20 > #12 0xffffffff80c48501 at kern_getdirentries+0x221 > #13 0xffffffff80c488a9 at sys_getdirentries+0x29 > #14 0xffffffff810298d9 at amd64_syscall+0x109 > #15 0xffffffff80fff85b at fast_syscall_common+0xf8 > Uptime: 3m18s > Dumping 1242 out of 32368 > MB:..2%..11%..21%..31%..42%..51%..61%..71%..82%..91% > > I can still access those NFS mounts just fine, can play music off them with > audacious or just mpv, but easytag will try to recursively read everything > and presumably puts a lot of stress on the system. > > I see there was chatter about this recently, and kib committed something to > nfsclient, which got merged to stable/14 on the 11th, but my build is from > the 14th, so presumably I already have this "fix", and it's not working? > > I'm on n266311-299e9fe9709a right now, which _is_ after kib's fixes, maybe > they are not sufficient for stable/14? You need 7b49e60227f8 which I just pushed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zaem0abAxKFYG4HY>