Hello,
On Tue, 10 Jun 2025 11:03:41 +
"Martin Husemann" wrote:
> Module Name: src
> Committed By: martin
> Date: Tue Jun 10 11:03:41 UTC 2025
>
> Modified Files:
> src/sys/dev/adb: adb_ms.c
>
> Log Message:
> Restore MSCLASS_* defines to fix the build for now - something did
On Sat, May 24, 2025 at 16:50:54 +, Nia Alarie wrote:
> Defining this layout is slightly optimistic, since even with latin-2
> fonts loaded and the appropriate locale set, wscons seems to struggle
> to input most of these characters.
>
> Regardless, this allows the supposedly supported "pl" e
I meant but forgot to mention in the commit message that I added the
missing cinclude for XEN3_DOM0.local to amd64/conf/XEN3_DOM0.
On Thu, May 22, 2025 at 09:37:40AM +, Christoph Badura wrote:
> Module Name: src
> Committed By: bad
> Date: Thu May 22 09:37:40 UTC 2025
>
> Modified Fi
On Tue, 20 May 2025, Greg Troxel wrote:
Yes, the commit with log looks fine.
Thanks for confirming.
FWIW, I don't like the use of the word "legacy", essentially ever, but
especially not when the thing being dissed has not been well and truly
formally deprecated.
Yeah, sorry about that. Th
Yes, the commit with log looks fine.
FWIW, I don't like the use of the word "legacy", essentially ever, but
especially not when the thing being dissed has not been well and truly
formally deprecated.
I am also befuddled with KERNEL_DIR being 'recent' and also '5 years
ago' but that's not about re
I reverted the initial commmit, and then re-committed with a
proper log message. Hopefully I got it right.
On Tue, 20 May 2025, Paul Goyette wrote:
On Tue, 20 May 2025, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Tue May 20 12:05:43 UTC 2025
Modified Fi
On Tue, 20 May 2025, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Tue May 20 12:05:43 UTC 2025
Modified Files:
src/share/man/man8/man8.x86: boot.8
src/sys/arch/i386/stand/boot: boot2.c
src/sys/arch/i386/stand/efiboot: boot.c
Log Messa
Date:Fri, 16 May 2025 12:10:59 +
From:nia
Message-ID:
| I don't like the idea of micro-optimizing an error path.
Nor do I in general, and the original intent wasn't that, it was
to avoid unnecessary line wrapping in the code (though that might
have gotten lost
On Fri, May 16, 2025 at 07:05:30PM +0700, Robert Elz wrote:
> And I agree with uwe@ and martin@ - that clang warning is absurd.
I did not say that - it is a good warning for C++ code, but for NetBSD C
code it is useless.
Martin
On Fri, May 16, 2025 at 07:05:30PM +0700, Robert Elz wrote:
> How about we make it
> &"lstat"[usestat]
> then?
>
> Or even
> &usestat["lstat"]
> ?
>
> They all mean the same thing, but those might almost be considered obfuscated.
> The first sounds as if it is what the clang warning w
On Fri, May 16, 2025 at 01:48:14PM +0300, Valery Ushakov wrote:
> I think we should turn that warning off.
Do we have a central place to turn off compiler warnings for the
whole tree? bsd.own.mk looks like the most obvious place to me
but I'd expect to see at least some warnings already disabled.
Date:Fri, 16 May 2025 07:50:28 +
From:nia
Message-ID:
| I wasn't insinuating it's undefined behaviour, just obfuscating.
I disagree. And one should always read (at least) surrounding code
before trying to understand any small part of any code.
How about we
On Fri, May 16, 2025 at 01:48:14PM +0300, Valery Ushakov wrote:
> On Fri, May 16, 2025 at 07:50:28 +, nia wrote:
>
> > stat.c:357:27: error: adding 'int' to a string does not append to the
> > string [-Werror,-Wstring-plus-int]
>
> ROFL. I think we should turn that warning off.
I agree.
M
On Fri, May 16, 2025 at 07:50:28 +, nia wrote:
> stat.c:357:27: error: adding 'int' to a string does not append to the string
> [-Werror,-Wstring-plus-int]
ROFL. I think we should turn that warning off.
-uwe
On Fri, May 16, 2025 at 02:32:19AM +0700, Robert Elz wrote:
> Date:Thu, 15 May 2025 19:11:44 +
> From:"Nia Alarie"
> Message-ID: <20250515191144.954c6f...@cvs.netbsd.org>
>
> | stat(1): Eliminate a compiler warning
>
> What was the warning?
stat.c:357:27: erro
Date:Thu, 15 May 2025 19:11:44 +
From:"Nia Alarie"
Message-ID: <20250515191144.954c6f...@cvs.netbsd.org>
| stat(1): Eliminate a compiler warning
What was the warning?
| This code at the moment is a bit magical, as it uses pointer arithemtic
| on a string a
On Thu, 8 May 2025, Paul Goyette wrote:
Looks to me like duplicated code, since they fall thru to the
trailing else clause.
Yep, that's why I deleted 'em.
-RVP
(b) I'm confused by how some parts of it are relevant to the goal,
particularly these hunks:
--- a/sys/lib/libsa/bootcfg.c Tue May 06 17:12:33 2025 +
+++ b/sys/lib/libsa/bootcfg.c Tue May 06 18:16:12 2025 +
...
@@ -227,8 +227,6 @@ perform_bootcfg(const char *conf, bootcf
On Thu, 8 May 2025, Taylor R Campbell wrote:
Module Name:src
Committed By: pgoyette
Date: Tue May 6 18:16:12 UTC 2025
Modified Files:
src/sys/arch/i386/stand/boot: boot2.c
src/sys/arch/i386/stand/lib: bootmenu.c libi386.h
src/sys/arch/i386/stand/pxeboot:
I've just committed a better, and more well-tested, version. Should
work correctly now.
Thanks for your patience, and sorry for the breakage.
On Tue, 29 Apr 2025, Paul Goyette wrote:
Thanks for the link to the log. I am investigating.
On Tue, 29 Apr 2025, Thomas Klausner wrote:
On Tue, A
Thanks for the link to the log. I am investigating.
On Tue, 29 Apr 2025, Thomas Klausner wrote:
On Tue, Apr 29, 2025 at 09:08:38AM +, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Tue Apr 29 09:08:38 UTC 2025
Modified Files:
src/sys/arch/i386/s
On Tue, Apr 29, 2025 at 09:08:38AM +, Martin Husemann wrote:
> Module Name: src
> Committed By: martin
> Date: Tue Apr 29 09:08:38 UTC 2025
>
> Modified Files:
> src/sys/arch/i386/stand/boot: boot2.c
> src/sys/arch/i386/stand/efiboot: boot.c
>
> Log Message:
> Backout /fi
> > 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,
1 - 100 of 1265 matches
Mail list logo
