> - For alpha and sparc64, don't define MUTEX_CAS() in terms of their own
> _lock_cas(), which has its own memory barriers; the call sites in
> kern_mutex.c already have the appropriate memory barrier calls. Thus,
> alpha and sparc64 can use default definition.
this seems to leave _lock_cas
> XXX: I wonder if each Xorg server extension can be enabled/disabled
> per ${MACHINE} basis rather than in MI include/dix-config.h header.
i had a look at this, and we could do it but it might require
generating a patched eg, xorg-config.h and maybe others, some
that are installed, some that
Hey Roland - friendly question:
I saw this error earlier today and threw in a temporary local fix where I
pushed the “const” qualifier deeper (into findcc.[ch]) rather than relax it
in mk dep.c. You choose the other route. Did you do that because you expect
to have that storage r/w, or something el
Am 20.08.2021 um 03:12 schrieb Robert Elz:
> Date:Thu, 19 Aug 2021 21:21:04 +
> From:"Roland Illig"
> Message-ID: <20210819212104.7c965f...@cvs.netbsd.org>
>
> | mkdep: fix prototype of findcc
>
> That broke the build.
I'm sorry for that. I knew that mkdep and
Date:Thu, 19 Aug 2021 21:21:04 +
From:"Roland Illig"
Message-ID: <20210819212104.7c965f...@cvs.netbsd.org>
| mkdep: fix prototype of findcc
That broke the build.
| A function that modifies a string argument must not declare that
| argument as 'const char *
On Tue, Aug 17, 2021 at 11:39:26PM +, Taylor R Campbell wrote:
> >
> > Log Message:
> > skip symbol tables that were unloaded again to avoid EFAULT when reading
> > ksyms.
> >
> > also restore TAILQ_FOREACH idiom.
>
> This change isn't quite right: Reading past st = ksyms_last_snapshot
> in
> Module Name:src
> Committed By: mlelstv
> Date: Sun Jul 18 06:57:28 UTC 2021
>
> Modified Files:
> src/sys/kern: kern_ksyms.c
>
> Log Message:
> skip symbol tables that were unloaded again to avoid EFAULT when reading
> ksyms.
>
> also restore TAILQ_FOREACH idiom.
This
On 2021/08/09 7:26, Rin Okuyama wrote:
- Initialize LIST_HEAD.
Hmm, since HEADs are static, this is not necessary. But, it should be
a good practice to initialize HEADs always, IMO...
Thanks,
rin
Sorry, no idea what happened with that. And thanks Martin for fixing it.
kre
The script no longer works:
Starting devpubd.
/libexec/devpubd-hooks/02-wedgenames: 164: Syntax error: end of file unexpected
(expecting "done")
Take care,
Jared
On Thu, 5 Aug 2021, Robert Elz wrote:
Module Name:src
Committed By: kre
Date: Thu Aug 5 12:52:47 UTC 2021
Modif
Hi,
On 2021/08/06 17:58, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 6 08:58:42 UTC 2021
Modified Files:
src/sys/arch/arm/xscale: i80321_intr.h
Log Message:
Do *NOT* lower IPL in i80321_splraise().
Fix various strange crashes for DIAGNOSTIC kern
Date:Mon, 2 Aug 2021 20:02:28 +0900
From:Rin Okuyama
Message-ID: <21dae7de-f153-2e53-4e66-cc61c8241...@gmail.com>
quoting Michael van Elst:
| > If you insist on a separate barrier, one name would be USERDEVICEPATHS
| > or short UDEV.
UDEV (or UDEVS) sounds good
On 2021/08/02 19:15, Michael van Elst wrote:
On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
Hi,
this commit causes:
rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
for systems with MKZ
On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
> On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> > Hi,
> >
> > this commit causes:
> >
> > rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
> >
> > for systems with MKZFS=no.
> >
> > Install
On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> Hi,
>
> this commit causes:
>
> rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
>
> for systems with MKZFS=no.
>
> Install /etc/rc.d/zfs for everyone? This should be harmless; the script
> properly checks e
On Mon, Aug 02, 2021 at 12:44:01PM +0700, Robert Elz wrote:
> Date:Mon, 2 Aug 2021 11:54:27 +0900
> From:Rin Okuyama
> Message-ID:
>
> | Install /etc/rc.d/zfs for everyone?
>
> Add a new dummy rc.d script (like LOGIN or DISKS)
> have devpubd come before that, and
Date:Mon, 2 Aug 2021 11:54:27 +0900
From:Rin Okuyama
Message-ID:
| Install /etc/rc.d/zfs for everyone?
Add a new dummy rc.d script (like LOGIN or DISKS)
have devpubd come before that, and everything
which should come later require it.
That's cleaner. We should
The H6 BSP provides some clues:
#if defined(CONFIG_ARCH_SUN8IW12) \
|| defined(CONFIG_ARCH_SUN8IW15) \
|| defined(CONFIG_ARCH_SUN50IW3) \
|| defined(CONFIG_ARCH_SUN50IW6)
#define SUNXI_UART_FIFO_SIZE256
#elif defined(CONFIG_ARCH_SUN3IW1)
#define SUNXI_UART_FIFO_S
Hi,
this commit causes:
rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
for systems with MKZFS=no.
Install /etc/rc.d/zfs for everyone? This should be harmless; the script
properly checks existence of /sbin/zfs, i.e., MKZFS=yes.
Alternatively, autogen /etc/rc.d/devp
> On Jul 31, 2021, at 3:17 AM, Tobias Nygren wrote:
>
> It's not possible to deduce from the manual what DesignWare revision
> is used but I guess I can go over the data sheets of currently
> released SoCs and build a matrix of the proper values regardless
> of DesignWare revision.
Have the dr
On Fri, 30 Jul 2021 22:36:45 +0200
Tobias Nygren wrote:
> On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
> Jared McNeill wrote:
>
> > Why only A20?
>
> It is the hardware I have on hand. If you know specifically which
> SoCs need this, the compat_data array can be extended.
> I guess maybe these als
On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
Jared McNeill wrote:
> Why only A20?
It is the hardware I have on hand. If you know specifically which
SoCs need this, the compat_data array can be extended.
I guess maybe these also?
allwinner,sun4i-a10
allwinner,sun6i-a31
Why only A20?
On Fri, 30 Jul 2021, Tobias Nygren wrote:
Module Name:src
Committed By: tnn
Date: Fri Jul 30 12:46:46 UTC 2021
Modified Files:
src/sys/arch/arm/sunxi: sunxi_platform.c
src/sys/dev/ic: com.c
Log Message:
com(4): fix FIFO for DW_APB on Allwinner A20
On Tue, Jul 27, 2021 at 12:22:18AM +0300, Valery Ushakov wrote:
> I'm not sure what is the discussion you are referring to, but it's not
> a matter of a simple rewording. "It's complicated", as it ties into a
> few other things, so ideally it needs a coordinated change to several
> man pages.
Dur
On Mon, Jul 26, 2021 at 21:04:37 +, nia wrote:
> On Mon, Jul 26, 2021 at 09:01:51PM +, nia wrote:
> > On Mon, Jul 26, 2021 at 11:55:24PM +0300, Valery Ushakov wrote:
> > > On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
> > >
> > > > Module Name:src
> > > > Committed By: n
On Mon, 26 Jul 2021, nia wrote:
"Some modern terminals may display characters with the standout
attribute set identically to those with the bold or reverse attribute
set."
I would remove the word "modern" completely.
++--+--+
|
On Mon, Jul 26, 2021 at 09:01:51PM +, nia wrote:
> On Mon, Jul 26, 2021 at 11:55:24PM +0300, Valery Ushakov wrote:
> > On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
> >
> > > Module Name: src
> > > Committed By: nia
> > > Date: Mon Jul 26 20:17:10 UTC 2021
> >
On Mon, Jul 26, 2021 at 11:55:24PM +0300, Valery Ushakov wrote:
> On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
>
> > Module Name:src
> > Committed By: nia
> > Date: Mon Jul 26 20:17:10 UTC 2021
> >
> > Modified Files:
> > src/lib/libcurses: curses_stan
On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Mon Jul 26 20:17:10 UTC 2021
>
> Modified Files:
> src/lib/libcurses: curses_standout.3
>
> Log Message:
> The BUGS sections is incorrect again for "modern" terminals.
>
> For
Hi,
Thank you for suggestions, I will take them in mind for future
commits. I believe I will avoid doing such big commits in the future
though, just I had submitted them all in my own PR some time ago... I
actually asked about the strategy in IRC and I got comment to do one
commit this time, just
On 2021/07/25 6:32, Joerg Sonnenberger wrote:
On Sat, Jul 24, 2021 at 05:27:26AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Jul 24 05:27:26 UTC 2021
Modified Files:
src/lib/libc/arch/powerpc/string: Makefile.inc
Log Message:
For evbppc, use C
On 2021/07/25 6:31, Andrius Varanavicius wrote:
Module Name:src
Committed By: andvar
Date: Sat Jul 24 21:31:39 UTC 2021
...
Log Message:
Fix all remaining typos, mainly in comments but also in few definitions and log
messages, reported by me in PR kern/54889.
Also fixed some
I guess I should revert this particular change then. Yes, I saw PGOFSET
definition and assumed it's a typo too, just too widely used and like you
said historical value. In some header files PGOFSET had a comment: "byte
offset into page" next to it.
On Sun, Jul 25, 2021, 00:53 Izumi Tsutsui wrote
> Log Message:
> Fix all remaining typos, mainly in comments but also in few definitions and
> log messages, reported by me in PR kern/54889.
> Also fixed some additional typos in comments, found on review of same files
> or typos.
:
> cvs rdiff -u -r1.51 -r1.52 src/sys/arch/sh3/sh3/exception_ve
On Sat, Jul 24, 2021 at 05:27:26AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat Jul 24 05:27:26 UTC 2021
>
> Modified Files:
> src/lib/libc/arch/powerpc/string: Makefile.inc
>
> Log Message:
> For evbppc, use C version of bcopy(3), memcpy(3), memcmp(
On Mon, Jul 19, 2021 at 01:33:53AM +, David A. Holland wrote:
> Part 3; cvs randomly didn't commit all the files the first time, still
> hunting down the files it skipped.
ok, I'm pretty sure that's the lot.
--
David A. Holland
dholl...@netbsd.org
On Fri, 16 Jul 2021 12:44:18 +0200
Frank Kardel wrote:
> I am not sure why NO_FOLLOW was there and if we want to keep it how
>
> we would handle named wedges. We could create a /dev/wedgedev from
>
> devpubd with hard links to the devices - that would work with ZFS but
>
> is really ugly.
>
>
Hi !
This triggered an unexpected side effect.
I have my ZFS vdev on gpt partitions as wedges.
I configured the vdevs via the /dev/wedges/* symlinks via the wedge names.
data 1.28T 424G 888G - 4% 32% 1.31x
ONLINE -
raidz2 1.28T 424G 888G
On 15/07/2021 04:25, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Thu Jul 15 03:25:50 UTC 2021
Modified Files:
src/sys/dev/usb: if_mue.c uchcom.c
Log Message:
explanation typo
To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61 src/sys/
> On Jul 15, 2021, at 12:06 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jul 14 13:24:59 UTC 2021
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>>
>> Log Message:
>> cl
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Jul 14 13:24:59 UTC 2021
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>
> Log Message:
> clang does not support __float128 in our configuration and i386
shouldn't you replace
On 04/07/2021 23:11, Joerg Sonnenberger wrote:
On Sun, Jul 04, 2021 at 06:55:47AM +, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Sun Jul 4 06:55:47 UTC 2021
Modified Files:
src/common/lib/libc/arch/aarch64/atomic: atomic_nand_16.S
atomic
On Sun, Jul 04, 2021 at 06:55:47AM +, Nick Hudson wrote:
> Module Name: src
> Committed By: skrll
> Date: Sun Jul 4 06:55:47 UTC 2021
>
> Modified Files:
> src/common/lib/libc/arch/aarch64/atomic: atomic_nand_16.S
> atomic_nand_32.S atomic_nand_64.S atomic_nand_8.S
>
On Thu, Jul 01, 2021 at 12:25:51AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/sys/kern: vfs_vnops.c
>
> Log Message:
> don't clear the error before we use it to determine if we are moving or
> duping.
oh ffs...
*goes to soak head*
--
David A. Holland
dholl...@netbsd.org
On Wed, Jun 30, 2021 at 06:42:21PM +0900, Rin Okuyama wrote:
> /home/source/ab/HEAD/src/sys/kern/vfs_vnops.c:357:11: error: 'vp' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 357 | *ret_vp = vp;
> | ^~~~
> cc1: all warnings being treated as e
On 30/06/2021 15:13, Joerg Sonnenberger wrote:
On Tue, Jun 29, 2021 at 11:26:00PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jun 29 23:26:00 UTC 2021
Modified Files:
src/sys/external/bsd/compiler_rt/dist/lib/builtins/arm: aeabi_cfcmp.S
On Tue, Jun 29, 2021 at 11:26:00PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Jun 29 23:26:00 UTC 2021
>
> Modified Files:
> src/sys/external/bsd/compiler_rt/dist/lib/builtins/arm: aeabi_cfcmp.S
> divmodsi4.S divsi3.S modsi3.S
>
> Log Mes
On Tue, Jun 29, 2021 at 10:40:54PM +, David A. Holland wrote:
> Module Name: src
> Committed By: dholland
> Date: Tue Jun 29 22:40:54 UTC 2021
>
> Modified Files:
> src/external/cddl/osnet/sys/sys: vnode.h
> src/share/man/man9: errno.9 vnsubr.9
> src/sys/dev: firmloa
Hi,
GCC warns maybe-uninitialized for this commit (for some architectures and
optimization levels: https://releng.netbsd.org/builds/HEAD/202106292250Z/):
/home/source/ab/HEAD/src/sys/kern/vfs_vnops.c: In function 'vn_open':
/home/source/ab/HEAD/src/sys/kern/vfs_vnops.c:357:11: error: 'vp' m
On Tue, 29 Jun 2021, Paul Goyette wrote:
Please note that both riastradh@ and dh@ have plans to ride this
version bump. You might want to delay any ``cvs up'' commands for
a short while.
:)
Looks like both commits are done, so ``cvs up'' should get you a
workable source tree.
+
On Tue, 29 Jun 2021, David A. Holland wrote:
Module Name:src
Committed By: dholland
Date: Tue Jun 29 22:39:21 UTC 2021
Modified Files:
src/sys/fs/puffs: puffs_vnops.c
src/sys/fs/union: union_vnops.c
src/sys/fs/unionfs: unionfs_subr.c
src/sys/kern:
Oops, this is broken. I will fix shortly...
rin
On 2021/06/30 8:29, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jun 29 23:29:12 UTC 2021
Modified Files:
src/lib/libc/arch/arm/gen: swapcontext.S
src/lib/libc/arch/arm/sys: __clone.S
Log Message
Please note that both riastradh@ and dh@ have plans to ride this
version bump. You might want to delay any ``cvs up'' commands for
a short while.
:)
On Tue, 29 Jun 2021, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Tue Jun 29 21:03:37 UTC 2021
Modified Fi
On Wed, Jun 23, 2021 at 07:29:30AM +, Martin Husemann wrote:
> This (or the series) broke the non-wide char builds.
> Easy/quick reproducer: build.sh -m sun2 release
/home/builds/ab/HEAD/sun3/202106222020Z-tools/lib/gcc/m68k--netbsdelf/10.3.0/../../../../m68k--netbsdelf/bin/ld:
libhack.o: in
On Tue, Jun 22, 2021 at 07:49:09AM +, Brett Lymn wrote:
> Module Name: src
> Committed By: blymn
> Date: Tue Jun 22 07:49:09 UTC 2021
>
> Modified Files:
> src/lib/libcurses: addbytes.c
>
> Log Message:
> Rework the fix for lib/56224.
> Move the scroll check to _cursesi_addwcha
On 2021/06/16 19:23, Rin Okuyama wrote:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
> Date: Wed, 16 Jun 2021 17:38:26 +0900
> From: Rin Okuyama
>
> KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
> [...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
> "/usr/src/sys/dev/pad/pad.c", line 214
Can you share `ident netbsd | grep
Hi,
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
# cd /usr/tests/usr.bin/mixerctl && atf-run
...
tc-start: ..., nflag
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
[...] cpu0: Begin traceba
Date:Mon, 14 Jun 2021 03:56:48 +0200
From:Joerg Sonnenberger
Message-ID:
| This is even more true for multi-threaded applications
| (where POSIX explicitly suggests that requirement).
Sure, anything with fork() and threads has issues, that's messy.
Even I know t
On Mon, Jun 14, 2021 at 01:33:51AM +0700, Robert Elz wrote:
> Date:Sat, 12 Jun 2021 23:13:54 +0200
> From:Joerg Sonnenberger
> Message-ID:
>
> Sorry, missed this message when I was cherry picking messages to read in
> a timely fashion.
>
> | On Wed, Jun 09, 2021 a
Date:Sat, 12 Jun 2021 23:13:54 +0200
From:Joerg Sonnenberger
Message-ID:
Sorry, missed this message when I was cherry picking messages to read in
a timely fashion.
| On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
| > after a vfork() the child can do
On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
> It should, when it is workable for the application, make things
> faster, while also avoiding the vfork() perils. But only when
> it works -- after a vfork() the child can do anything (it should
> avoid touching its parent's state, but
On Wed, 9 Jun 2021, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Wed Jun 9 23:22:51 UTC 2021
Modified Files:
src/sys/dev: dev_verbose.h
Log Message:
Use the localcount(9)-based module_hook mechanism to prevent the verbose
modules' code and data bein
Date:Tue, 8 Jun 2021 16:15:12 +
From:"Nia Alarie"
Message-ID: <20210608161512.1d7c3f...@cvs.netbsd.org>
| vfork.2: recommend posix_spawn instead
You might want to reconsider the wording there, posix_spawn() is
an alternative to [v]fork() + exec*(). Not just v
On 2021/06/08 16:09, nia wrote:
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
If one is requested and _not_ supported, fail; otherwise we might
enter audio_write with a null play track and crash on KASSERT.
I
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
> audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
>
> If one is requested and _not_ supported, fail; otherwise we might
> enter audio_write with a null play track and crash on KASSERT.
It looks like this is an inco
Christos Zoulas writes:
> In article , Joerg Sonnenberger
> wrote:
> >On Fri, Jun 04, 2021 at 10:20:24PM -, Christos Zoulas wrote:
> >> In article , Joerg Sonnenberger
> > wrote:
> >> >On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
> >> >> Module Name:src
> >> >> Commi
In article , Joerg Sonnenberger wrote:
>On Fri, Jun 04, 2021 at 10:20:24PM -, Christos Zoulas wrote:
>> In article , Joerg Sonnenberger
> wrote:
>> >On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
>> >> Module Name: src
>> >> Committed By: christos
>> >> Date:
On Fri, Jun 04, 2021 at 10:20:24PM -, Christos Zoulas wrote:
> In article , Joerg Sonnenberger
> wrote:
> >On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
> >> Module Name: src
> >> Committed By: christos
> >> Date: Thu Jun 3 20:17:37 UTC 2021
> >>
In article , Joerg Sonnenberger wrote:
>On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Jun 3 20:17:37 UTC 2021
>>
>> Modified Files:
>> src/tests/lib/csu: h_ifunc_static.c
>>
>> Log Message:
On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Jun 3 20:17:37 UTC 2021
>
> Modified Files:
> src/tests/lib/csu: h_ifunc_static.c
>
> Log Message:
> PR/56230: Jan-Benedict Glaw: arm oabi does not and will not
Hmm, misleading commit log (code itself is correct). More precisely:
s/the last element of ksyms_symtabs/ksyms_last_snapshot/
Anyway, does this help you to reintroduce
"ksyms(4): Don't skip symbol tables that are soon to be freed."?
That KASSERT does not fire anymore for aarch64, as far as I ca
> Date: Wed, 2 Jun 2021 17:33:39 +0900
> From: Rin Okuyama
>
> On 2021/06/02 6:11, Taylor R Campbell wrote:
> > - KASSERT(filepos <= sizeof(struct ksyms_hdr) +
> > + KASSERT(filepos == sizeof(struct ksyms_hdr) +
> > ksyms_hdr.kh_shdr[SYMTAB].sh_size);
> ...
>
> This KASSERT fires at
Hi,
On 2021/06/02 6:11, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Tue Jun 1 21:11:52 UTC 2021
Modified Files:
src/sys/kern: kern_ksyms.c
Log Message:
ksyms(4): Don't skip symbol tables that are soon to be freed.
They will not actually be f
Correction:
On 2021/06/01 7:10, Rin Okuyama wrote:
On 2021/05/31 23:35, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory us
On 2021/05/31 23:35, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and
On 2021/05/31 23:32, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
The former is used by GCC, and the latter is by LLVM. Since libunwind was
derived from LLVM, it has never supported
On 2021/05/31 23:30, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon May 31 11:41:22 UTC 2021
Modified Files:
src/sys/lib/libunwind: Registers.hpp unwind_registers.S
Log Message:
...
- I
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and double register in the
space. That's what the exi
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
> The former is used by GCC, and the latter is by LLVM. Since libunwind was
> derived from LLVM, it has never supported the former. This results in
> crashes for GC
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Mon May 31 11:41:22 UTC 2021
>
> Modified Files:
> src/sys/lib/libunwind: Registers.hpp unwind_registers.S
>
> Log Message:
> ...
>
> - Introduce enum for flags.
Please und
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May 30 07:20:00 UTC 2021
>
> Modified Files:
>
> src/sys/arch/arm/include/arm32: param.h
>
> Log Message:
>
> Include opt_param.h for MSGBUFSIZE ifdef _KERNEL_OPT.
Thanks Rin! I thought I had checked all the w
Ok, I did not realize that all mips had switched.
christos
> On May 27, 2021, at 4:48 PM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Thu May 27 20:29:24 UTC 2021
>>
>> Modified Files:
>> src/share/mk: bsd
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Thu May 27 20:29:24 UTC 2021
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> mips64 only works with gcc-10
the MACHINE_CPU==mips test should cover mipsn64, that i assume
you mean here...
> On May 24, 2021, at 9:02 PM, matthew green wrote:
>
> this also probably fails to work as wanted (while not
> actually failing) for people who use "cvs -D .CVS", etc.
>
> it's kinda gross.
It is gross, and I considered removing it.
christos
signature.asc
Description: Message signed with
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon May 24 22:40:44 UTC 2021
>
> Modified Files:
> src/distrib/acorn32/stand: Makefile
>
> Log Message:
> PR/56207: Jan-Benedict Glaw: Handle error from find when removing CVS
> directories on a git repo.
On Mon, May 17, 2021 at 01:12:12PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon May 17 17:12:12 UTC 2021
>
> Modified Files:
> src: build.sh
>
> Log Message:
> for mercurial, use the latest revision instead of limiting the output to 1
> (req
I understand. Thanks!
rin
On 2021/05/09 9:20, Christos Zoulas wrote:
In article ,
Rin Okuyama wrote:
How about binutils?
http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/binutils/Makefile#rev1.32
I don't think it makes a difference.
It seems that we need to mknative again for this:
Event
In article ,
Rin Okuyama wrote:
>How about binutils?
>
>http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/binutils/Makefile#rev1.32
I don't think it makes a difference.
>It seems that we need to mknative again for this:
Eventually, but not right now.
christos
How about binutils?
http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/binutils/Makefile#rev1.32
It seems that we need to mknative again for this:
% find /usr/src/external/gpl3/binutils/usr.bin/ld -name '*.h' | xargs grep
HAVE_INITFINI_ARRAY
/usr/src/external/gpl3/binutils/usr.bin/ld/arch/aarc
In article <20210506061816.94bb1f...@cvs.netbsd.org>,
Shoichi YAMAGUCHI wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: yamaguchi
>Date: Thu May 6 06:18:16 UTC 2021
>
>Modified Files:
> src/sys/net: if_spppsubr.c
>
>Log Message:
>do not clear destination address if there
On 2021/04/22 10:09, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Apr 22 01:09:48 UTC 2021
Modified Files:
src/external/gpl3/binutils/dist/bfd: elf32-ppc.c elf64-ppc.c
Log Message:
Fix regression where ld(1) is trapped into infinite loop when
linking bi
On 30.04.2021 15:42, Tobias Nygren wrote:
On Tue, 20 Apr 2021 23:19:53 +
Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Apr 20 23:19:53 UTC 2021
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
Log Message:
clang: fix
Hmm, it seems that we were the only ones that had RES_NOCHECKNAME enabled.
Everyone else uses check-names by default. So I am inclined to leave it as is.
christos
> On Apr 30, 2021, at 5:33 PM, Christos Zoulas wrote:
>
> Signed PGP part
> I guess I will undo it, because as I mentioned in a sepa
I guess I will undo it, because as I mentioned in a separate mail it causes
other problems.
christos
> On Apr 30, 2021, at 5:18 PM, Robert Elz wrote:
>
>Date:Fri, 30 Apr 2021 12:07:49 -0400
>From:"Christos Zoulas"
>Message-ID: <20210430160749.3a4dbf...@cvs.netbsd.
Date:Fri, 30 Apr 2021 12:07:49 -0400
From:"Christos Zoulas"
Message-ID: <20210430160749.3a4dbf...@cvs.netbsd.org>
| src/include: resolv.h
|
| Log Message:
| Default to check-names for safety.
Please don't do that, check-names applies at the wrong place, a
On Tue, 20 Apr 2021 23:19:53 +
Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Tue Apr 20 23:19:53 UTC 2021
>
> Modified Files:
> src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
>
> Log Message:
> clang: fix build for installing libclang_rt.ub
> Module Name:src
> Committed By: thorpej
> Date: Sat Apr 24 23:37:01 UTC 2021
>
> Log Message:
> Merge thorpej-cfargs branch:
>
> Simplify and make extensible the config_search() / config_found() /
> config_attach() interfaces: rather than having different variants for
> which ar
> (I haven't investigated exactly what's going on leading to ~5 KB-byte
> stack frames, but this shuts gcc up, at least, and the hypotheses
> sound plausible to me!)
this matches what i saw when looking at it. i was going to
test the exact same idea (noinline).
.mrg.
801 - 900 of 13240 matches
Mail list logo
