> On 17 Mar 2023, at 22:53, Moritz Buhl wrote:
>
> Any better names?
> "ffs-node-lock"
> "ffsndlock"
ffsnodelk or ffsndlck if the length shouldn’t exceed 8.
Below is an updated diff addressing the following concerns:
On Fri, Mar 17, 2023 at 03:45:59PM +0100, Alexander Bluhm wrote:
> The FreeBSD Code puts the check_nifree label before the if
> (fs->fs_cs(fs, cg).cs_nifree == 0) check. Could you move this chunk
> a little up to keep us in sync?
On Fri
On Thu, Mar 16, 2023 at 12:25:15PM -0500, Scott Cheloha wrote:
> This code has been dead since we switched sparc64 to clockintr several
> months ago. Nobody has come forward asking for a timer(4/sparc64)
> intrclock.
>
> As of now, you need %TICK_CMPR or %STICK_CMPR to run OpenBSD on
> sparc64. T
We have released OpenBGPD 7.8, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.
This release includes the following changes to the previous release:
* Improved performance by optimising the output filters
* Add Autonomous System Provider Authorization (AS
> Date: Fri, 17 Mar 2023 15:23:19 +0100
> From: Moritz Buhl
>
> Dear tech,
>
> I have a machine with some kind of hardware defect.
> Smartctl shows that one SSD regularly has an unexpected power loss
> (Attribute 174):
>
> 174 Unknown_Attribute 0x0032 100 100 000Old_age
> Always
On Fri, Mar 17, 2023 at 03:23:19PM +0100, Moritz Buhl wrote:
> FreeBSD fixed this in 2013:
> https://github.com/freebsd/freebsd-src/commit/94f4ac214c403b99cbc44dd6e9cdf4db2cc9b297
>
> Below is a diff that addresses this with a exclusive lock
> using RW_SLEEPFAIL.
The FreeBSD Code puts the check_n
Dear tech,
I have a machine with some kind of hardware defect.
Smartctl shows that one SSD regularly has an unexpected power loss
(Attribute 174):
174 Unknown_Attribute 0x0032 100 100 000Old_age
Always - 284.
On the console I see the following output:
root on sd0a (b
On Fri, Mar 17, 2023 at 11:39:20AM +0100, Claudio Jeker wrote:
> Dumb mistake from my side. The rtr_aspa struct is on the stack and only
> covers that data up to the spas. The spas are a variable array and not
> copied over. So access these from the buf.
Ugh. How did I miss that.
> Remove the tra
Dumb mistake from my side. The rtr_aspa struct is on the stack and only
covers that data up to the spas. The spas are a variable array and not
copied over. So access these from the buf.
Remove the trap of the 0 sized array in spas since it is now unused.
Not entierly happy about that but unless we
