As people following HEAD may have seen, around 1 month ago a fix to lockmgr(9) has been committed that should prevent a deadlock for that primitive (the fixup is composed by r200447,201703,201709-201710). As long as the approach choosen in HEAD is optimal, unluckilly it does introduce an ABI breakage. In order to allow a MFC, a similar approach, being a bit sub-optimal, but not breaking ABI, has been prepared for STABLE_8: http://www.freebsd.org/~attilio/lockmgr_fix8.diff I'm seeking for testers here. Any report would be very much appreciated. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
> In order to allow a MFC, a similar approach, being a bit sub-optimal, > but not breaking ABI, has been prepared for STABLE_8: > http://www.freebsd.org/~attilio/lockmgr_fix8.diff > > I'm seeking for testers here. > Any report would be very much appreciated.I'll give this a shot - I ahve a machine running 8.0 which shows occasional lockups (though annoyingly not with WITNESS in the kernel). I shall update to the latest stable, apply the patch and run GENERIC on it to see what happens. cheeers, -pete.
> http://www.freebsd.org/~attilio/lockmgr_fix8.diff > > I'm seeking for testers here. > Any report would be very much appreciated.I tested the patch on my machine which locks up, and I am afraid that it still locks, even with the patch applied. The last things on the console before the lock are. 1) A whole load of sshd errors for one of those flood attacks which try multiple usersnames. This is not unusual, all my systems with an external ssh port see this. 2) Four 'Watchdog timeout occurreed, resetting!" messages from if_bce.c. These are new - without your patch I did not get these. I have tried rnning this machine with WITNESS in the kernel, but it will not deadlock then. Without WiTNESS it will lock up in about twelve hours. I am going to try with just KDB and DDB to see if I can get it into a state where we can get some useful information out of it. I realsie, of course, that this might be utterly unrelated to the problem your patch is trying to address! cheers, -pete.
2010/1/14 Pete French <petefrench@ticketswitch.com>:>> INVARIANTS requires INVARIANT_SUPPORT [sic] in the kernel config (see comments in GENERIC). > > Ah, right, that would explain it. Thanks!INVARIANT_SUPPORT is made mandatory in order to allow non-INVARIANT kernel to be able to handle INVARIANT compiled modules. Attilio -- Peace can only be achieved by understanding - A. Einstein
2010/1/15 Pete French <petefrench@ticketswitch.com>:> Well, the machine has been running the WITNESS + INVARIANTS kernel > for 20 hours now without locking up.This looks like what I > saw before - compiling in WITNESS stops it locking up -( > > Is there any use in my runing a kernel with just INVARIANTS to see if > that will lcok ? I know it locks with KDN and DDb on their own, but > am not usre how useful that is.One may never know, try without WITNESS but still the same setup. Attilio -- Peace can only be achieved by understanding - A. Einstein