Am 30.09.2025 um 01:26 schrieb Valery Ushakov:
> Being forced to look at this anyway, I think the original change must
> be reverted before 11 is out. It prevents nice things, e.g
>
> ...
>
> 0x80
> 0x80
>
> But on current it produces instead an obnoxious, "you are not too
> smart to use th
Hello,
On Sun, 28 Sep 2025 11:32:23 +
"Jason R Thorpe" wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sun Sep 28 11:32:23 UTC 2025
>
> Modified Files:
> src/sys/arch/macppc/dev: ki2c.c
>
> Log Message:
> There are PowerMac G5 11.2 units in the wild with an OFW dev
On Mon, Sep 15, 2025 at 04:15:00AM +, Konrad Schroder wrote:
> Modified Files:
> src/sys/ufs/lfs: lfs.h lfs_accessors.h lfs_alloc.c
>
> Log Message:
> If setting the head (or tail) of the inode free list to LFS_UNUSED_INUM, also
> set the tail (resp. head) to LFS_UNUSED_INUM, as the
On Mon, Sep 15, 2025 at 11:03:40AM -0700, Konrad Schroder wrote:
> The loop has to run because the head of the free list at this point can
> never be LFS_UNUSED_INUM; but there is no way for GCC to know that.? I'll
> patch it momentarily.
Thanks!
--
David A. Holland
dholl...@netbsd.org
The loop has to run because the head of the free list at this point can
never be LFS_UNUSED_INUM; but there is no way for GCC to know that.
I'll patch it momentarily.
Thanks,
-Konrad
On 9/15/2025 10:49 AM, David Holland wrote:
On Mon, Sep 15, 2025 at 04:15:00AM +, Konrad Schroder wrote:
I forgot to mention in the commit log that the changes for urtwn and xhci
have to be pulled up to -10 and -11.
I'd like to wait 2 weeks though for more testing and identifying any fallout
are completed.
Best regards,
Nat
At Sun, 17 Aug 2025 02:04:56 +,
> Committed By: isaki
> Date: Sun Aug 17 02:04:56 UTC 2025
>
> Modified Files:
> src/sys/arch/m68k/m68k: mmu_subr.s
>
> Log Message:
> m68k: Fix invalid instruction word.
> PMOVE ,TTn instruction doesn't support (An)+ addressing mode on 68030.
> W
On Tue, Jul 08, 2025 at 03:56:23PM +, Emmanuel wrote:
> Module Name: src
> Committed By: joe
> Date: Tue Jul 8 15:56:23 UTC 2025
>
> Modified Files:
> src/sys/net/npf: npf_handler.c
>
> Log Message:
> Pass frames directly when no layer 2 rules are set
>
> NPF's original imple
Hello,
On Sat, 5 Jul 2025 15:16:09 +
"Michael Lorenz" wrote:
> Module Name: src
> Committed By: macallan
> Date: Sat Jul 5 15:16:09 UTC 2025
>
> Modified Files:
> src/sys/arch/macppc/dev: ki2c.c ki2cvar.h
>
> Log Message:
> deal with G5s that have two openpics by:
> - check
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 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 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
>
1 - 100 of 1129 matches
Mail list logo
