> > a) apply the workaround to all m68k ports:
> > pros: same m68k binaries can be shared
> > cons: requires extra performance penalty for all m68k (020/030/040/060)
> >
> > b) apply the workaround only for XC68LC040 users:
> > pros: nothing? (only technical interests of developers?)
> > cons:
On Mon, Apr 21, 2025 at 04:59:42PM +0300, Valery Ushakov wrote:
> On Mon, Apr 21, 2025 at 13:21:33 +, Nia Alarie wrote:
>
> > Modified Files:
> > src/include: time.h
> > src/lib/libc/gen: Makefile.inc timespec_get.3
> > Added Files:
> > src/lib/libc/gen: timespec_getres.3 timespec_
On Mon, Apr 21, 2025 at 04:08:52PM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Mon Apr 21 16:08:52 UTC 2025
>
> Modified Files:
> src/distrib/sets/lists/comp: mi
>
> Log Message:
> Add entries for timespec_getres(3) - which should be needed regardless
>
On Mon, Apr 21, 2025 at 13:21:33 +, Nia Alarie wrote:
> Modified Files:
> src/include: time.h
> src/lib/libc/gen: Makefile.inc timespec_get.3
> Added Files:
> src/lib/libc/gen: timespec_getres.3 timespec_getres.c
I don't think it makes sense to split these manual pages per f
On Wed, Apr 16, 2025 at 9:25 PM Taylor R Campbell wrote:
>
> > Module Name:src
> > Committed By: ozaki-r
> > Date: Wed Apr 16 05:29:45 UTC 2025
> >
> > Modified Files:
> > src/sys/net: if_bridge.c
> >
> > Log Message:
> > bridge: avoid a race condition on stopping callout
>
Thanks for pointing this out! I did just that.
christos
> On Apr 16, 2025, at 5:54 PM, Taylor R Campbell wrote:
>
>> Module Name:src
>> Committed By: christos
>> Date: Wed Apr 16 15:23:17 UTC 2025
>>
>> Log Message:
>> Resolve conflicts between 3.0.15 and 3.0.16:
>> - Reverted
> Module Name:src
> Committed By: christos
> Date: Wed Apr 16 15:23:17 UTC 2025
>
> Log Message:
> Resolve conflicts between 3.0.15 and 3.0.16:
> - Reverted 3.0.16 changes to idea, rc2, and rc5 to retain binary compatibility
> The patches to undo the reversion for the next import
> Module Name:src
> Committed By: ozaki-r
> Date: Wed Apr 16 05:29:45 UTC 2025
>
> Modified Files:
> src/sys/net: if_bridge.c
>
> Log Message:
> bridge: avoid a race condition on stopping callout
>
> Without BRIDGE_LOCK, the callout can be scheduled after callout_halt.
O
nvmm_x86_svm.c has same typos.
On Mon, Apr 14, 2025, 01:00 Taylor R Campbell wrote:
> Module Name:src
> Committed By: riastradh
> Date: Sun Apr 13 22:00:43 UTC 2025
>
> Modified Files:
> src/sys/dev/nvmm/x86: nvmm_x86_vmx.c
>
> Log Message:
> nvmm(4): Fix typos in commen
On 2025/04/13 15:50, Thomas Klausner wrote:
On Sun, Apr 13, 2025 at 02:34:03AM +, Rin Okuyama wrote:
...
XXX
This is KABI change, and cannot be pulled up into netbsd-{10,9}.
If this changes the ABI, shouldn't the NetBSD Version in sys/param.h
be bumped?
Thomas
Good question ;)
Thank
On Sun, Apr 13, 2025 at 02:34:03AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Apr 13 02:34:03 UTC 2025
>
> Modified Files:
> src/sys/arch/usermode/dev: ld_thunkbus.c
> src/sys/dev: ld.c ldvar.h
> src/sys/dev/ata: ld_ataraid.c
> src
On Sun, 13 Apr 2025 08:28:04 Izumi Tsutsui wrote:
> > Would you or isaki@ or martin@ like me to assign PR 13078 to either of
> > you and I'll write a followup email to the binutils people stating that
> > from now on you'll handle all responsibilty for the correspondance with
> > them and assign ei
Hi Michael,
On 2025/04/12 21:00, Michael van Elst wrote:
On Sat, Apr 12, 2025 at 08:14:28PM +0900, Rin Okuyama wrote:
Hi Michael, thanks for kind review!
Hi rin,
PS
For ld_sdmmc.c, IIUC, check for ld_sdmmc_dump() yields
```
if (blkno + blkcnt - 1 > sc->sc_sf->csd.capacity)
return
> Would you or isaki@ or martin@ like me to assign PR 13078 to either of you
> and
> I'll write a followup email to the binutils people stating that from now on
> you'll handle all responsibilty for the correspondance with them and assign
> either of you to the doc/HACKS note.
Actually I had n
On Sat, Apr 12, 2025 at 08:14:28PM +0900, Rin Okuyama wrote:
> Hi Michael, thanks for kind review!
Hi rin,
> PS
> For ld_sdmmc.c, IIUC, check for ld_sdmmc_dump() yields
>
> ```
> if (blkno + blkcnt - 1 > sc->sc_sf->csd.capacity)
> return EIO;
capacity is the block count, not the last bl
Hi Michael, thanks for kind review!
On 2025/04/12 19:01, Michael van Elst wrote:
On Sat, Apr 12, 2025 at 06:24:44PM +0900, Rin Okuyama wrote:
Hi!
I've made a draft patch to support dumping against > 2Gi blocks
for backends like nvme(4) or virtio(4).
Does it look reasonable to you?
Hi rin,
On Sat, Apr 12, 2025 at 02:42:33AM -0700, Paul Goyette wrote:
> Does this help kern/59153?
It avoids data loss and corruption in similar cases. The exact
condition in kern/59153 luckily didn't dump at all.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.d
On Sat, Apr 12, 2025 at 06:24:44PM +0900, Rin Okuyama wrote:
> Hi!
>
> I've made a draft patch to support dumping against > 2Gi blocks
> for backends like nvme(4) or virtio(4).
>
> Does it look reasonable to you?
Hi rin,
> - if (blkno < 0 || blkno + nblk - 1 > INT_MAX)
> + if (blkno
Is this related to kern/59153?
On Sat, 12 Apr 2025, Rin Okuyama wrote:
Hi!
I've made a draft patch to support dumping against > 2Gi blocks
for backends like nvme(4) or virtio(4).
Does it look reasonable to you?
Thanks,
rin
On 2025/04/12 16:30, Michael van Elst wrote:
Module Name:src
Co
Does this help kern/59153?
On Sat, 12 Apr 2025, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Apr 12 07:30:01 UTC 2025
Modified Files:
src/sys/dev: ld.c
Log Message:
ld sc_dump backend takes an 'int' as disk address, fail when the
disk address
Hi!
I've made a draft patch to support dumping against > 2Gi blocks
for backends like nvme(4) or virtio(4).
Does it look reasonable to you?
Thanks,
rin
On 2025/04/12 16:30, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Apr 12 07:30:01 UTC 2025
Modifi
On Fri, 11 Apr 2025 02:07:06 Izumi Tsutsui wrote:
> When committing code, it's important to provide a obvious explanation
> of the technical rationale behind the implementation.
>
> Without such rationale, the code can become difficult to maintain
> in the future, as later contributors may not und
On Mon, 7 Apr 2025 17:58:26 Tetsuya Isaki wrote:
> At Sat, 5 Apr 2025 22:47:39 +1100,
>
> Nat Sloss wrote:
> > Before I placed the additional nops before rte I experienced 1 hard
> > lockup which I attributed to the fpu (buggy lc)
>
> > The idea was this:
> It can't be certain that the behavior i
> I did it to be on the safe side. If the kernel was to be built with -mlcfix
> passed to gas(1) the nop would be inserted.
It seems there might be some confusion between the goal
(i.e. avoiding f-line exception during write-pending) and
the approach/workaround (inserting a nop before F-line ins
Hmm, I was still confused.
On 2025/04/10 11:08, Rin Okuyama wrote:
On 2025/04/09 14:38, Rin Okuyama wrote:
Module Name: src
Committed By: rin
Date: Wed Apr 9 05:38:01 UTC 2025
Modified Files:
src/sys/kern: subr_log.c
Log Message:
logread: Stop reading msgbuf without log_lock
On 2025/04/09 14:38, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Apr 9 05:38:01 UTC 2025
Modified Files:
src/sys/kern: subr_log.c
Log Message:
logread: Stop reading msgbuf without log_lock being held
Oops, sorry, here I made typo; s/reading/writing/
On Thu, 10 Apr 2025 00:44:02 Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: nat
> > Date: Wed Apr 9 00:04:41 UTC 2025
> >
> > Modified Files:
> > src/sys/arch/m68k/m68k: fpu.c
> >
> > Log Message:
> > Add workaround for fpu test for kernels defined wit
> Module Name: src
> Committed By: nat
> Date: Wed Apr 9 00:04:41 UTC 2025
>
> Modified Files:
> src/sys/arch/m68k/m68k: fpu.c
>
> Log Message:
> Add workaround for fpu test for kernels defined with M68040.
>
> This is to accomodate kernels built without the -mlcfix option passed
Module Name:src
Committed By: nat
Date: Tue Apr 8 23:42:08 UTC 2025
Modified Files:
src/sys/arch/mac68k/mac68k: pmap_bootstrap.c
Log Message:
Move high back an additional 7 pages to fix crashing on kernels with
ascaudio(4) enabled.
Memory
On Tue, 8 Apr 2025 15:10:24 Martin Husemann wrote:
> On Tue, Apr 08, 2025 at 10:45:23AM +1000, Nat Sloss wrote:
> > nop - f* instructions are not atomicwhat will happen if nop is
> > executed and then the processor is interrupted (by say pressing a
> > keystroke on the keyboard) then after tha
On Tue, Apr 08, 2025 at 10:45:23AM +1000, Nat Sloss wrote:
> nop - f* instructions are not atomicwhat will happen if nop is executed
> and then the processor is interrupted (by say pressing a keystroke on the
> keyboard) then after that interrupt has run the f* instruction is executed.
>
>
On Mon, 7 Apr 2025 17:44:09 Tetsuya Isaki wrote:
> At Sat, 5 Apr 2025 22:01:37 +1100,
>
> Nat Sloss wrote:
> > Following advice and following the spirit of my intentions adding nop in
> > the switch i added nops before "rte" in locore.s in sys/mac68k as
> > opposed to m68k/swicher.
>
> Are you su
At Sat, 5 Apr 2025 22:47:39 +1100,
Nat Sloss wrote:
> Before I placed the additional nops before rte I experienced 1 hard lockup
> which I attributed to the fpu (buggy lc)
>
> The idea was this:
It can't be certain that the behavior is related to this bug.
XC68LC040 series are known for having m
At Sat, 5 Apr 2025 22:01:37 +1100,
Nat Sloss wrote:
> Following advice and following the spirit of my intentions adding nop in the
> switch i added nops before "rte" in locore.s in sys/mac68k as opposed to
> m68k/swicher.
Are you sure?
First, errata E4 said the workaround is "nop-before-f-line"
Hi,
On Tue, Mar 25, 2025 at 08:28:10PM +, Taylor R Campbell wrote:
> Thanks for taking a look at this! This change is not quite enough,
> though. There are two issues:
>
> 1. `#ifdef DIAGNOSTIC printf(...)' is almost always wrong. Generally,
>either:
>
>(a) the condition should be
On Sun, Apr 06, 2025 at 03:27:23AM +, Taylor R Campbell wrote:
> FYI, this was not an accidental local change; I deliberately committed
> this so that it would run on the releng testbed because I was unable
> to reproduce the problem locally.
But it broke the build, so the testbed could not ru
Am 06.04.2025 um 03:24 schrieb Taylor R Campbell:
>> Date: Sat, 5 Apr 2025 19:18:20 +0200
>> From: Roland Illig
>>
>> Would it be narrow enough to add /*CONSTCOND*/ to the definition of
>> ALIGNED_POINTER on i386 and amd64? Or would you consider this still too
>> broad?
>
> Might be reasonable. B
> Module Name:src
> Committed By: martin
> Date: Wed Apr 2 07:25:42 UTC 2025
>
> Modified Files:
> src/lib/librumpuser: sp_common.c
>
> Log Message:
> Revert accidental local test change from previous - the DEBUG define
> is passed on the command line already.
FYI, this
> Date: Sat, 5 Apr 2025 19:18:20 +0200
> From: Roland Illig
>
> Would it be narrow enough to add /*CONSTCOND*/ to the definition of
> ALIGNED_POINTER on i386 and amd64? Or would you consider this still too
> broad?
Might be reasonable. But then we have a lot of predicates that might
be used in
On Fri, 4 Apr 2025 23:27:49 Martin Husemann wrote:
> On Fri, Apr 04, 2025 at 10:48:17PM +1100, Nat Sloss wrote:
> > The changes to the context switch in sys/m68k have been reverted and the
> > nop insertion by gas(1) has been turned off by default.
>
> What does upstream gcc plan to do with the ne
On Mon, 31 Mar 2025 22:48:39 Tetsuya Isaki wrote:
> At Sun, 30 Mar 2025 04:44:26 +,
>
> Nathanial Sloss wrote:
> > Module Name:src
> > Committed By: nat
> > Date: Sun Mar 30 04:44:26 UTC 2025
> >
> > Modified Files:
> > src/sys/arch/m68k/m68k: switch_subr.s
> >
Am 30.03.2025 um 11:51 schrieb Roland Illig:
> Module Name: src
> Committed By: rillig
> Date: Sun Mar 30 09:51:51 UTC 2025
>
> Modified Files:
> src/usr.bin/make: parse.c
> src/usr.bin/make/unit-tests: ...
>
> Log Message:
> make: use '"filename" line 123' for locations instea
Am 05.04.2025 um 02:07 schrieb Taylor R Campbell:
>> Module Name:src
>> Committed By: rillig
>> Date: Fri Apr 4 20:52:32 UTC 2025
>>
>> Modified Files:
>> src/sys/sys: cdefs.h
>>
>> Log Message:
>> sys/cdefs.h: fix __predict_true and __predict_false for lint
>>
>> -#define
At Tue, 1 Apr 2025 02:26:35 +1100,
Nathanial Sloss wrote:
> Consider the following (including my gas patch for binutils):
>
> movq.
> nop
> fnop
>
> Thats as it's assembled but at run time it could posslibly
> run like this
>
> movq
> nop
> (switch task)
> fnop
>
> So the nops are inser
On Thu, Apr 03, 2025 at 11:48:26AM +, Nathanial Sloss wrote:
> Module Name: src
> Committed By: nat
> Date: Thu Apr 3 11:48:26 UTC 2025
>
> Modified Files:
> src/external/gpl3/binutils/dist/gas/config: tc-m68k.c
>
> Log Message:
> Compiler support for buggy early revision 68LC
On Sat, Apr 05, 2025 at 10:47:39PM +1100, Nat Sloss wrote:
> nop
> fnop
>
> could be executed as
>
> nop
> (context swtich)
> (return from context swtich)
> fnop
>
> So without these the fnop would not be coverted.
Not sure what you mean here.
Why would the nop before the rte make any differen
On Sat, 5 Apr 2025 22:32:10 Martin Husemann wrote:
> On Sat, Apr 05, 2025 at 10:01:37PM +1100, Nat Sloss wrote:
> > Following advice and following the spirit of my intentions adding nop in
> > the switch i added nops before "rte" in locore.s in sys/mac68k as
> > opposed to m68k/swicher.
>
> This m
On Sat, Apr 05, 2025 at 10:01:37PM +1100, Nat Sloss wrote:
> Following advice and following the spirit of my intentions adding nop in the
> switch i added nops before "rte" in locore.s in sys/mac68k as opposed to
> m68k/swicher.
This makes no sense to me (but I can only guess how the exact bug w
Following advice and following the spirit of my intentions adding nop in the
switch i added nops before "rte" in locore.s in sys/mac68k as opposed to
m68k/swicher.
Along with adding nops before fline instructions with the modified assember.
I took a picture for your consideration.
http://ftp.n
> Module Name:src
> Committed By: rillig
> Date: Fri Apr 4 20:52:32 UTC 2025
>
> Modified Files:
> src/sys/sys: cdefs.h
>
> Log Message:
> sys/cdefs.h: fix __predict_true and __predict_false for lint
>
> -#define __predict_true(exp) __builtin_expect((exp) ? 1 :
On Fri, 4 Apr 2025 22:37:50 Tetsuya Isaki wrote:
> At Thu, 3 Apr 2025 14:00:16 +0200,
>
> Martin Husemann wrote:
> > > So these all nops are never executed just before any of f-line
> > > instructions.
> >
> > Can you also please explain how you got at that NOP-after-f-line
> > woraround? The Mot
At Thu, 3 Apr 2025 14:00:16 +0200,
Martin Husemann wrote:
> > So these all nops are never executed just before any of f-line
> > instructions.
>
> Can you also please explain how you got at that NOP-after-f-line woraround?
> The Motorola errata text (at least the versions I found on the wayback
>
On Fri, Apr 04, 2025 at 10:48:17PM +1100, Nat Sloss wrote:
> The changes to the context switch in sys/m68k have been reverted and the nop
> insertion by gas(1) has been turned off by default.
What does upstream gcc plan to do with the new option? Default on or off?
I guess we can find some way t
On Thu, Apr 03, 2025 at 08:55:11PM +0900, Tetsuya Isaki wrote:
> So these all nops are never executed just before any of f-line
> instructions.
Can you also please explain how you got at that NOP-after-f-line woraround?
The Motorola errata text (at least the versions I found on the wayback
machine
> Date: Wed, 2 Apr 2025 21:41:25 +0900
> From: Ryo ONODERA
>
> With this commit, builds of pkgsrc/lang/python3* fail.
> I have no build logs of python3* now. However you may easily reproduce
> the failures as follows.
>
> $ cd /usr/pkgsrc/lang/python313
> $ make package
>
> I will submit the lo
Hi,
Thanks for your quick fix.
It fixes my problem.
pkgsrc/lang/python3* build fine under NetBSD/amd64-current for me.
Thanks again!!!
On Thu, Apr 3, 2025 at 2:20 AM Taylor R Campbell wrote:
>
> > Date: Wed, 2 Apr 2025 21:41:25 +0900
> > From: Ryo ONODERA
> >
> > With this commit, builds of pk
Hi,
With this commit, builds of pkgsrc/lang/python3* fail.
I have no build logs of python3* now. However you may easily reproduce
the failures as follows.
$ cd /usr/pkgsrc/lang/python313
$ make package
I will submit the logs later.
Could your take a look at my problem?
Thank you.
On Mon, Mar
At Sun, 30 Mar 2025 04:44:26 +,
Nathanial Sloss wrote:
> Module Name: src
> Committed By: nat
> Date: Sun Mar 30 04:44:26 UTC 2025
>
> Modified Files:
> src/sys/arch/m68k/m68k: switch_subr.s
>
> Log Message:
> Sprinkle nop.
>
> This is the kernel part of addressing the issue w
On Sun, Mar 30, 2025 at 12:39:38AM +, David Holland wrote:
> On Thu, Mar 27, 2025 at 05:42:03AM +0700, Robert Elz wrote:
> > | Because vnds are specifically configured for mounts; the only thing
> > | they're useful for is mounting a fs image that lives in a regular
> > | file.
> >
>
> On Mar 29, 2025, at 9:38 PM, Taylor R Campbell wrote:
>
> This is still broken: now it doesn't read past the end the input
> buffer, but it leaves the bytes bi->bi_msg[rem], bi->bi_msg[rem + 1],
> bi->bi_msg[rem + 2] ..., bi->bi_msg[sizeof(bi->bi_msg) - 2]
> uninitialized, and will later dump
Date:Sun, 30 Mar 2025 01:38:51 +
From:Taylor R Campbell
Message-ID: <20250330013852.a346284...@mail.netbsd.org>
| but it leaves the bytes bi->bi_msg[rem], bi->bi_msg[rem + 1],
| bi->bi_msg[rem + 2] ..., bi->bi_msg[sizeof(bi->bi_msg) - 2]
| uninitialized,
I
> Module Name:src
> Committed By: christos
> Date: Sat Mar 29 23:25:57 UTC 2025
>
> Modified Files:
> src/external/bsd/blocklist/lib: bl.c
>
> Log Message:
> Don't use strlcpy() because it will keep going trying to find the end of the
> input string (thanks riastradh)
>
>
On Thu, Mar 27, 2025 at 05:42:03AM +0700, Robert Elz wrote:
> | Because vnds are specifically configured for mounts; the only thing
> | they're useful for is mounting a fs image that lives in a regular
> | file.
>
> No they're not, they can be used for playing with newfs variants,
> fs
> Module Name:src
> Committed By: christos
> Date: Wed Mar 26 13:52:47 UTC 2025
>
> Modified Files:
> src/external/bsd/blocklist/lib: bl.c
>
> Log Message:
> NUL-terminate the message string (thanks riastradh)
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.5
Date:Wed, 26 Mar 2025 20:46:42 +
From:David Holland
Message-ID:
| Because vnds are specifically configured for mounts; the only thing
| they're useful for is mounting a fs image that lives in a regular
| file.
No they're not, they can be used for playing w
On Thu, Mar 27, 2025 at 02:26:46AM +0700, Robert Elz wrote:
> | GitHub/31: Ricardo Branco: Add -d flag to umount to detach vnds,
>
> Why would we do this for vnd devices, and not cgd, raidframe, ccd, ... ??
Because vnds are specifically configured for mounts; the only thing
they're useful fo
Date:Tue, 25 Mar 2025 15:01:11 -0400
From:"Christos Zoulas"
Message-ID: <20250325190111.e3226f...@cvs.netbsd.org>
| GitHub/31: Ricardo Branco: Add -d flag to umount to detach vnds,
Why would we do this for vnd devices, and not cgd, raidframe, ccd, ... ??
For that,
When did it start causing panics ?
Can I get a log of the crash ?
> On 20 Mar 2025, at 9:49 AM, Paul Goyette wrote:
>
> Module Name: src
> Committed By: pgoyette
> Date: Thu Mar 20 09:49:02 UTC 2025
>
> Modified Files:
> src/sys/net/npf: npf_os.c
>
> Log Message:
> Disable auto
Noted !
> On 25 Mar 2025, at 8:35 PM, Taylor R Campbell wrote:
>
>> Module Name:src
>> Committed By: joe
>> Date: Sun Mar 23 17:04:10 UTC 2025
>>
>> Modified Files:
>>src/sys/external/bsd/drm2/dist/drm/nouveau: nouveau_bo.c
>>
>> Log Message:
>> safety: fix memory leak
> Module Name:src
> Committed By: joe
> Date: Sun Mar 23 17:04:10 UTC 2025
>
> Modified Files:
> src/sys/external/bsd/drm2/dist/drm/nouveau: nouveau_bo.c
>
> Log Message:
> safety: fix memory leak in drm use error lable to free and return on error
In the future, please ru
> Module Name:src
> Committed By: hans
> Date: Sun Mar 23 12:07:24 UTC 2025
>
> Modified Files:
> src/sys/dev/usb: uts.c
>
> Log Message:
> uts(4): make sure the device is enabled before calling uhidev_close()
>
> This check was already there, but only enabled for DIAGNOS
On Tue, Mar 25, 2025 at 02:42:33 +, Michael Lorenz wrote:
> Module Name: src
> Committed By: macallan
> Date: Tue Mar 25 02:42:33 UTC 2025
>
> Modified Files:
> src/sys/dev/wsfont: files.wsfont wsfont.c
> Added Files:
> src/sys/dev/wsfont: Comic_Mono_13x22.h
>
> Log Mess
On Tue, Mar 25, 2025 at 06:42:38PM +1100, matthew green wrote:
> hm. does this really change anything?
You're right. I missed that the ums.c code is a bit different from
uts.c and doesn't suffer from the same panic-inducing problem.
> i've had a couple of crashes near here recently and i haven't
"Hans Rosenfeld" writes:
> Module Name: src
> Committed By: hans
> Date: Sun Mar 23 12:19:32 UTC 2025
>
> Modified Files:
> src/sys/dev/wscons: wsmouse.c
>
> Log Message:
> wsmouse(4): fix bogus DIAGNOSTIC checks
>
> Similar to wskbd(4), these checks should be done always, and the on
"Hans Rosenfeld" writes:
> Module Name: src
> Committed By: hans
> Date: Sun Mar 23 12:08:13 UTC 2025
>
> Modified Files:
> src/sys/dev/usb: ums.c
>
> Log Message:
> ums(4): make sure the device is enabled before calling uhidev_close()
>
> Same issue as in uts(4), his check was alrea
On Thu, 20 Mar 2025, Emmanuel Nyarko wrote:
When did it start causing panics ?
sometime between Feb 9 and March 19
Can I get a log of the crash ?
No serial coonsole, but I did transcribe the backtrace:
vpanic
kern_assert
spec_close
VOP_CLOSE
vn_clos
On Thu, 20 Mar 2025, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Thu Mar 20 15:04:55 UTC 2025
Modified Files:
src/sys/kern: kern_module.c
Log Message:
One more debug message to different manual vs auto unload
differentiate --^
Yet again forgot to add: reviewed and approved by riastradh and bad. Thank you!
Also tested on the multiple VIA V-RAID devices (removing disks, mixing
different RAID arrays, two RAID controllers at the same motherboard
(both setup in ataraid(4) and disks removed or swapped), etc).
On Sun, Mar 16,
On Tue, Mar 11, 2025 at 13:56:49 +, Brad Spencer wrote:
> src/usr.sbin/emcfanctl: Makefile emcfanctl.8 emcfanctl.c emcfanctl.h
Please, can you fix the man page so that it's clear which part of the
command line is fixed keywords recognized by the program and which is
user supplied data.
E.g.
Should have mentioned in commit message that reviewed by bad and
riastradh. Sorry about that.
On Tue, Mar 11, 2025 at 6:51 PM Andrius Varanavicius wrote:
>
> Module Name:src
> Committed By: andvar
> Date: Tue Mar 11 16:51:31 UTC 2025
>
> Modified Files:
> src/sys/dev/ata:
On Tue, Mar 11, 2025 at 6:35 PM Andrius Varanavicius wrote:
>
> Module Name:src
> Committed By: andvar
> Date: Tue Mar 11 16:35:03 UTC 2025
>
> Modified Files:
> src/sys/dev/pci: viaide.c
>
> Log Message:
> viaide(4): check and add ATA RAID capability in via_sata_chip_map_n
On Mon, Mar 03, 2025 at 06:08:17PM +, Taylor R Campbell wrote:
> > Please everyone, avoid implementing hasty solutions, just because we
> > seem to need a solution to something today - we don't - a few days more
> > consideration and discussion can make solutions much more sane, and less
> > li
Date:Mon, 3 Mar 2025 17:20:57 +
From:Taylor R Campbell
Message-ID: <20250303172102.41b6b84...@mail.netbsd.org>
| It's not `wrong'; it's a legitimate way to eliminate unnecessary
| failure modes, weighing costs of one approach vs costs of another.
It is a very
Date:Mon, 3 Mar 2025 18:08:17 +
From:Taylor R Campbell
Message-ID: <20250303180830.d601784...@mail.netbsd.org>
| I did test build, and I ran the arc4random tests, including the test I
| added to verify the new more-graceful failure mode. I just forgot to
|
> Date: Mon, 03 Mar 2025 07:39:55 +0700
> From: Robert Elz
>
> Date:Mon, 03 Mar 2025 06:50:47 +0700
> From:Robert Elz
> Message-ID: <13328.1740959...@jacaranda.noi.kre.to>
>
> | This is the wrong solution,
>
> Further, given that it doesn't even build, please rev
> Date: Mon, 03 Mar 2025 06:50:47 +0700
> From: Robert Elz
>
> Date:Sun, 2 Mar 2025 22:46:24 +
> From:"Taylor R Campbell"
> Message-ID: <20250302224624.1a707f...@cvs.netbsd.org>
>
> | Log Message:
> | libc: New __libc_atfork.
> |
> | This uses caller-pro
> Date: Sun, 2 Mar 2025 12:39:02 -0500
> From: Christos Zoulas
>
> Yes, unfortunately I committed the version from my tree by accident
> and not the one that was on the web server. I already fixed it.
No, you seem to have gotten it the wrong way around...
The original commit, rev. 1.8, had no a
Fixed now.
christos
> On Mar 3, 2025, at 10:41 AM, Taylor R Campbell wrote:
>
>> Date: Sun, 2 Mar 2025 12:39:02 -0500
>> From: Christos Zoulas
>>
>> Yes, unfortunately I committed the version from my tree by accident
>> and not the one that was on the web server. I already fixed it.
>
> No,
Date:Mon, 03 Mar 2025 06:50:47 +0700
From:Robert Elz
Message-ID: <13328.1740959...@jacaranda.noi.kre.to>
| This is the wrong solution,
Further, given that it doesn't even build, please revert it.
I will implement a sane solution in the next day or two (I'll
even t
Date:Sun, 2 Mar 2025 22:46:24 +
From:"Taylor R Campbell"
Message-ID: <20250302224624.1a707f...@cvs.netbsd.org>
| Log Message:
| libc: New __libc_atfork.
|
| This uses caller-provided storage for the callback queues.
|
| Use it in arc4random(3) in order
Yes, unfortunately I committed the version from my tree by accident and not the
one
that was on the web server. I already fixed it.
christos
signature.asc
Description: Message signed with OpenPGP
> Module Name:src
> Committed By: christos
> Date: Thu Feb 27 10:55:27 UTC 2025
>
> Modified Files:
> src/lib/libc/arch/arm/misc: arm_initfini.c
>
> Log Message:
> use the latest version that does not abort on error.
>
> @@ -46,6 +46,7 @@
> #include
> #include
> #inc
> Module Name:src
> Committed By: joe
> Date: Tue Feb 25 02:10:13 UTC 2025
>
> Modified Files:
> src/sys/dev/pci: if_iavf.c
>
> Log Message:
> initialize post to 0
>
> this prevents the use of unitialized variable when we hit an error branch
> on the first attempt/iterati
On 2025-02-24 10:28 pm, matthew green wrote:
"Christos Zoulas" writes:
Module Name:src
Committed By: christos
Date: Sun Feb 23 15:33:49 UTC 2025
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: avx2intrin.h
Log Message:
Pr/59093: Onno van der Linden: Elide ca
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Feb 23 15:33:49 UTC 2025
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/i386: avx2intrin.h
>
> Log Message:
> Pr/59093: Onno van der Linden: Elide cast-qual gcc warning
for dist code i rea
On Mon, 24 Feb 2025, Paul Goyette wrote:
Do we get a man page for this? :)
Oh I see ot now. thnks
On Mon, 24 Feb 2025, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Mon Feb 24 13:47:57 UTC 2025
Modified Files:
src/sbin: Makefile
Added Files
Do we get a man page for this? :)
On Mon, 24 Feb 2025, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Mon Feb 24 13:47:57 UTC 2025
Modified Files:
src/sbin: Makefile
Added Files:
src/sbin/efi: Makefile bootvar.c bootvar.h certs.c certs.h de
On Mon, Feb 24, 2025 at 12:28:22AM +0100, Joerg Sonnenberger wrote:
>
>
> On 2/23/25 8:34 PM, Thomas Klausner wrote:
> > On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
> > > > Log Message:
> > > > Add LIBRARY section and explicitly mention that these interfaces
> > > > require sup
On 2/23/25 8:34 PM, Thomas Klausner wrote:
On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
Log Message:
Add LIBRARY section and explicitly mention that these interfaces
require super-user privileges.
this can be relaxed with the
security.models.extensions.user_set_cpu_affinit
On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
> > Log Message:
> > Add LIBRARY section and explicitly mention that these interfaces
> > require super-user privileges.
>
> this can be relaxed with the
> security.models.extensions.user_set_cpu_affinity sysctl.
I found this and wond
1 - 100 of 1243 matches
Mail list logo
