Re: NFSv4 crash of CURRENT

Rick, I can confirm Kostik’s fix works on 13-stable. Peter > On 15 Jan 2024, at 16:13, Peter Blok wrote: > > I can give it a shot on one of my clients. > >> On 15 Jan 2024, at 16:04, Rick Macklem > <mailto:rick.mack...@gmail.com>> wrote: >> >>

Re: NFSv4 crash of CURRENT

I can give it a shot on one of my clients. > On 15 Jan 2024, at 16:04, Rick Macklem wrote: > > On Mon, Jan 15, 2024 at 2:53 AM Peter Blok <mailto:pb...@bsd4all.org>> wrote: >> >> Hi, >> >> Forgot to mention I’m on 13-stable. The fix that is

Re: NFSv4 crash of CURRENT

(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e) When I remove the fix, the problem is gone. Add it back and the crash happens. Peter > On 15 Jan 2024, at 09:31, Peter Blok wrote: > > Hi, > > I do have a crash on a NFS client with

Re: NFSv4 crash of CURRENT

Hi, I do have a crash on a NFS client with stable of today (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe it is the same problem. I have ports automounted on /am/ports. When I do cd /am/ports/sys and type tab to autocomplete it crashes with the below stack trace.

Re: CFT: if_bridge performance improvements

Just using pf is enough to provoke this panic. I had the same back trace. This patch from Kristof fixed it for me. diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c index 373fa096d70..83c453090bb 100644 --- a/sys/net/if_bridge.c +++ b/sys/net/if_bridge.c @@ -2529,7 +2529,6 @@

Re: INTRNG

While on the subject INTRNG - does anybody know the status of handling GPIO interrupts with queue/kevent? There were some patches before INTRNG, but they require some work. Peter > On 23 Feb 2018, at 07:25, Jon Brawn wrote: > > Wotcha Gang! > > In my travels through the

Re: Time to increase MAXPHYS?

One area that breaks after changing MAXPHYS from 128K to 1MB is the iscsi target. I don’t have details, because that server is semi-production and I reverted it back ASAP > On 5 Jun 2017, at 19:49, Edward Tomasz Napierała wrote: > > On 0604T0952, Hans Petter Selasky wrote:

panic with jail bug_id 213673 was: VNET branch destiny

The problem happens when stopping a jail. It doesn’t seem to be related to vnet at all. When stopping a jail, pfr_cleanup calls uma_zdestroy(V_pfr_kentry_z). The dtor calls zone_release, which calls slab_free_item. The issue seems to be that the keg found in zone_release does not belong to the

Re: VNET branch destiny

Hi Kristof, I’m prety sure it is the same as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 . It is unrelated to epair or ng_eiface (my case). I’ll dig some more. Peter > On 11 Apr 2017, at 08:47, Kristof Provost

Re: VNET branch destiny

No problem. Although pf is not used the vnet_destroy seems to be the issue. Some parts are not virtualized and the vnet_destroy->vnet_pf_uninit teardown happens on the host vnet so to speak. > On 10 Apr 2017, at 22:11, Ernie Luzar wrote: > > peter.b...@bsd4all.org wrote:

Re: VNET branch destiny

Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my intention to use the netgrpah bridge with bhyve as well. The panic (one-time) happened in pfioctl when I refreshed the rules. I suspect

Re: VNET branch destiny

There have been issues with pf if I recall correctly. I currently have issues with stable, pf and vnet. There is an issue with pf table entries when an interface is moved to a different vnet. Does anyone no if there is a specific fix for this that hasn’t been ported to stable? I haven’t had

Re: [RFC/RFT] projects/ipsec

Andrey, Is this going to MFC'ed to stable-11 in the future? I have tested with current and found no issues, but I would like to add it to a semi-production environment running stable-11 Peter > On 6 Feb 2017, at 10:07, Andrey V. Elsukov wrote: > > On 11.12.2016 02:07,

Re: crash in iflib_fast_intr

This is with an igb interface. Peter > On 18 Jan 2017, at 15:31, Sean Bruno wrote: > > > > On 01/18/17 03:37, peter.b...@bsd4all.org > wrote: >> Hi, >> >> A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since >>

crash in iflib_fast_intr

Hi, A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is reproducible. KDB: stack backtrace: #0 0x805cec97 at kdb_backtrace+0x67 #1 0x80584816 at vpanic+0x186 #2 0x80584683