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 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
>
> 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
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
> 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 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 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
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
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,
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
> 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
> Module Name:src
> Committed By: joe
> Date: Sun Feb 16 15:56:06 UTC 2025
>
> Modified Files:
> src/sys/dev/hyperv: if_hvn.c
>
> Log Message:
> avoid buffer overflow when copying the ether header host into the ether vland
> header host
> on hyper-v
> [...]
> @@ -1697,7 +
riastradh@ wrote:
> > Modified Files:
> > src/sys/arch/sun3/dev: bw2.c cg2.c cg4.c fb.c fd.c kd.c xd.c xy.c
> >
> > Log Message:
> > Make local dev_type_*() functions static.
>
> While you're doing this kind of cleanup, maybe you could also change
>
> static dev_type_open(foo_open);
>
> Module Name:src
> Committed By: tsutsui
> Date: Sat Dec 21 17:40:11 UTC 2024
>
> Modified Files:
> src/sys/arch/sun3/dev: bw2.c cg2.c cg4.c fb.c fd.c kd.c xd.c xy.c
>
> Log Message:
> Make local dev_type_*() functions static.
While you're doing this kind of cleanup, may
thanks, I will take a look!
christos
> On Dec 16, 2024, at 5:26 AM, J. Hannken-Illjes wrote:
>
>
>>
>> On 15. Dec 2024, at 18:42, Christos Zoulas wrote:
>>
>> Module Name: src
>> Committed By: christos
>> Date: Sun Dec 15 17:42:34 UTC 2024
>>
>> Modified Files:
>> src/sys/kern: sys_ptrace
> On 15. Dec 2024, at 18:42, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Sun Dec 15 17:42:34 UTC 2024
>
> Modified Files:
> src/sys/kern: sys_ptrace_common.c
>
> Log Message:
> PR/58896: Martin Husemann: PT_KILL will not deliver a kill signal to a stopped
> proc
On Sat, Nov 23, 2024 at 08:32:43PM -0800, T K Spindler (moof) wrote:
> On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote:
> > On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> >
> > > Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> > > wit
On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote:
> On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
>
> > Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> > with -current), it's still insufficient for the disks on the same
> > target from
On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> with -current), it's still insufficient for the disks on the same
> target from attaching except for the first one; they do still show
> up in `scsictl sd0
> Modified Files:
> src/sys/dev/scsipi: scsiconf.c
>
> Log Message:
> The code tried to limit number of LUNs per target to 3, but would
> only default to a single LUN when that limit is exceeded.
>
> With the limit removed, more LUNs will be attached (up to the limit
> imposed by the host a
On 2024/11/11 23:23, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Mon Nov 11 14:23:11 UTC 2024
>
> Modified Files:
> src/sys/dev/pci: pcidevs
>
> Log Message:
> Add many Brainboxes devices. Repoted in PR/kern 55824 by Cameron Williams.
s/55824/5882
Date:Sun, 10 Nov 2024 09:35:29 +
From:Taylor R Campbell
Message-ID: <20241110093534.e816384...@mail.netbsd.org>
| Yikes! Do you have a reproducer handy for this?
Yes, it turns out to be trivially easy to do, once the
bug is understood - just very rare to actua
> Module Name:src
> Committed By: kre
> Date: Sun Nov 10 00:11:43 UTC 2024
>
> Modified Files:
> src/sys/kern: kern_descrip.c
>
> Log Message:
> Make O_CLOEXEC always close specified files on exec
>
> It turns out that close-on-exec doesn't always close on exec.
Yikes!
On 2024/11/07 18:51, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Nov 7 09:51:00 UTC 2024
Modified Files:
src/sys/external/bsd/vchiq/dist/interface/vchiq_arm:
vchiq_kmod_netbsd.c
Log Message:
vchiq: Use SYSCTL_DESCR() to comply with SYSCTL_
My aplogies. I've removed scsipi_done_once and have commited your alternative
change.
I must have tried this earlier and made an error (not as you intended).
Best regards,
Nat
> Module Name:src
> Committed By: nat
> Date: Mon Oct 28 14:36:43 UTC 2024
>
> Modified Files:
> src/sys/dev/ic: ncr5380sbc.c
> src/sys/dev/scsipi: scsipi_base.c scsipiconf.h
>
> Log Message:
> Introduce scsipi_done_once.
>
> This allows for transfers to be sucess
Yes, thanks Michael, this was all my fault because I made a last minute change.
The code was correct before.
christos
> On Oct 7, 2024, at 9:17 AM, Rin Okuyama wrote:
>
> ATF failures seem to be fixed by mlelstv@:
> https://mail-index.netbsd.org/source-changes/2024/10/06/msg153736.html
> https
ATF failures seem to be fixed by mlelstv@:
https://mail-index.netbsd.org/source-changes/2024/10/06/msg153736.html
https://releng.netbsd.org/b5reports/i386/commits-2024.10.html#end
Thanks,
rin
On 2024/10/07 21:00, Christos Zoulas wrote:
no, i did not. I will fix asap.
christos
On Oct 6, 2024,
no, i did not. I will fix asap.
christos
> On Oct 6, 2024, at 7:59 PM, Taylor R Campbell wrote:
>
>
>>
>> Module Name:src
>> Committed By: christos
>> Date: Thu Oct 3 16:50:52 UTC 2024
>>
>> Modified Files:
>>src/sys/kern: syscalls.master sysv_sem.c
>>src/sy
> Module Name:src
> Committed By: christos
> Date: Thu Oct 3 16:50:52 UTC 2024
>
> Modified Files:
> src/sys/kern: syscalls.master sysv_sem.c
> src/sys/sys: sem.h
>
> Log Message:
> Add semtimedop GSoC 2024 (Shivraj Jamgade)
This doesn't seem to pass the existing
On Sat, 5 Oct 2024, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Oct 5 18:04:53 UTC 2024
Modified Files:
src/sys/kern: syscalls.master
Log Message:
New syscall requires SYSVSEM build option.
Seems to me that the new syscall should be part o
Just wondering, should this be included in the SYSV_* module rather than
in every kernel?
On Thu, 3 Oct 2024, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Thu Oct 3 16:50:52 UTC 2024
Modified Files:
src/sys/kern: syscalls.master sysv_sem.c
>
> This code could have done that - implemented linux's clone3() and then
> redefined clone() to be a particular way of calling clone3() (which is
> what I'd guess linux implementations might do, if they don't just have
> both versions in full). That would have worked, but requires updating
>
Date:Mon, 30 Sep 2024 09:09:04 -0400
From:Christos Zoulas
Message-ID: <2f4ec894-d66f-4608-84b1-7dd8433eb...@zoulas.com>
| [quoting mrg@]
| > this looks like it should use NETBSD32IPTR64(),
No, that would be wrong (even if it happened to work), it is expecting
to
> On Sep 29, 2024, at 10:27 PM, matthew green wrote:
>
> thanks for fixing the build.
>
> "Robert Elz" writes:
>> Module Name: src
>> Committed By:kre
>> Date:Mon Sep 30 01:26:48 UTC 2024
>>
>> Modified Files:
>> src/sys/compat/linux/common: linux_sched.c
>>
>> L
thanks for fixing the build.
"Robert Elz" writes:
> Module Name: src
> Committed By: kre
> Date: Mon Sep 30 01:26:48 UTC 2024
>
> Modified Files:
> src/sys/compat/linux/common: linux_sched.c
>
> Log Message:
> Supply a missing cast, which fixes the i386 (other 32 bit too probably)
>
Hi,
On 2024/09/19 3:33, Andrius V wrote:
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 18 00:44:03 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib: libi386.h
Log Message:
i386/stand: Remove XMS leftover from
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Wed Sep 18 00:44:03 UTC 2024
>
> Modified Files:
> src/sys/arch/i386/stand/lib: libi386.h
>
> Log Message:
> i386/stand: Remove XMS leftover from libi386.h, NFC
>
> PR port-i3
Thank you very much for kind & rapid response!!
rin
On 2024/09/18 10:34, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Wed Sep 18 01:34:08 UTC 2024
Modified Files:
src/sys/arch/mac68k/dev: adb.c
Log Message:
The delay is only required for machines with
Hi,
Can you please localize this quirk only for the affected machines?
It seems too much to me, to have 5 sec delay for irrelevant machines.
Thanks,
rin
On 2024/09/15 5:56, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Sat Sep 14 20:56:51 UTC 2024
Modified Fil
On Wed, Sep 11, 2024 at 05:17:45 +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Wed Sep 11 05:17:45 UTC 2024
>
> Modified Files:
> src/sys/arch/x86/x86: intr.c
>
> Log Message:
> apply some more diagnostic checks for x86 interrupts
How does this mix wi
This was also supposed to include in the log message:
Include mqueue-based entries only if built with MQUEUE option.
On Sat, 14 Sep 2024, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sat Sep 14 01:37:42 UTC 2024
Modified Files:
src/sys/miscfs/procf
Hi,
Christos Zoulas writes:
> And committed.
Thank you very much for your quick fix.
It works fine for me now.
> christos
>
>
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
And committed.
christos
On 2024-09-11 11:18 am, Taylor R Campbell wrote:
Date: Thu, 12 Sep 2024 00:05:24 +0900
From: Ryo ONODERA
"Taylor R Campbell" writes:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so they should not be exposed by,
> e.g., _XOPEN_SOURCE=70
> Date: Thu, 12 Sep 2024 00:05:24 +0900
> From: Ryo ONODERA
>
> "Taylor R Campbell" writes:
>
> > sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
> >
> > These are non-standard extensions, so they should not be exposed by,
> > e.g., _XOPEN_SOURCE=700.
> >
> > PR standards/57807: #i
Hi,
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Mon Sep 9 18:17:14 UTC 2024
>
> Modified Files:
> src/sys/sys: endian.h
>
> Log Message:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so t
On Wed, Aug 21, 2024 at 01:42:28AM -0700, John Nemeth wrote:
> } Log Message:
> } Add Areca ARC-1224
>
> I noticed that you mentioned newer Areca devices on icb. Is
> there a particular device that you're interested in. I have an
> updated version of arcmsr(4) that I've been meaning to clea
1 - 100 of 1114 matches
Mail list logo
