On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote:
> Module Name: src
> Committed By: reinoud
> Date: Wed Jan 20 19:46:48 UTC 2021
>
[..]
> Log Message:
> Add VirtIO PCI v1.0 attachments and fix the drivers affected.
>
> * virtio on sparc64 attaches but is it not
"Nia Alarie" writes:
> Module Name: src
> Committed By: nia
> Date: Wed Jan 20 13:22:08 UTC 2021
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC MODULAR XEN3_DOM0 XEN3_DOMU
> src/sys/arch/evbarm/conf: OPENBLOCKS_AX3
> src/sys/arch/i386/conf: GENERIC MODULAR
On Tue, Jan 19, 2021 at 07:19:51PM +0100, Martin Husemann wrote:
> On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote:
> > Module Name:src
> > Committed By: thorpej
> > Date: Tue Jan 19 00:35:10 UTC 2021
> >
> > Modified Files:
> >
On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Tue Jan 19 00:35:10 UTC 2021
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_sramc.c
>
> Log Message:
> Use device_compatible_entry / of_search_compatible()
> Log Message:
> Fix build as crash(8); Protect db_md_meminfo_cmd() by defined(_KERNEL).
thanks. surprised i never saw this as the change was in a
tree for a few weeks, but i guess i was mostly doing kernels
in that tree not full builds..
.mrg.
On 2021/01/18 14:49, Rin Okuyama wrote:
(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
wrongly returns false. As a result, callee functions misunderstood
that they are not running in the
On 2021/01/18 13:35, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Jan 18 04:35:05 UTC 2021
Modified Files:
src/sys/arch/powerpc/ibm4xx: clock.c
Log Message:
Invoke hardclock() and statclock() in the interrupt context.
Otherwise, entropy_enter() is
Hi Simon
On 17/01/2021 11:26, Simon Burge wrote:
On 15/01/2021 07:15, matthew green wrote:
Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
and is the same struct on all BSD. While bringing the same functionality to
IPv4, I elected to keep the same struct just to
The change isn't wrong, but I booted the wrong kernel and it does not fix
the aarch64 issue I am seeing.
On Sun, 17 Jan 2021, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Jan 17 15:13:15 UTC 2021
Modified Files:
src/sys/dev/wscons:
Hi Roy,
Roy Marples wrote:
> On 15/01/2021 07:15, matthew green wrote:
> >> Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
> >> and is the same struct on all BSD. While bringing the same functionality to
> >> IPv4, I elected to keep the same struct just to have the
> Note that `entropy' is not an `rcvar' the way upsdriver is (if your
ah! i missed this, and wasn't really even thinking about
more than foo and foo_flags. thanks!
.mrg.
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Sat Jan 16 01:23:04 UTC 2021
>
> Modified Files:
> src/sys/dev/acpi: tpm_acpi.c
>
> Log Message:
> Match PNP0C31 as a TPM 1.2 device. Works on my ThinkPad X260, and
> eliminates the last of the devices that
On Sat, Jan 16, 2021 at 14:46:46 +1100, matthew green wrote:
> > Log Message:
> > Tweak wording for consistency: `if empty or not set', not `if unset'.
>
> is this correct?
>
> rc complains if unset or not set (ie, if "$foo" is zero length):
>
> /etc/rc.d/upsdriver: WARNING: $upsdriver is not
> Date: Sat, 16 Jan 2021 14:46:46 +1100
> from: matthew green
>
> > Log Message:
> > Tweak wording for consistency: `if empty or not set', not `if unset'.
>
> is this correct?
>
> rc complains if unset or not set (ie, if "$foo" is zero length):
>
> /etc/rc.d/upsdriver: WARNING: $upsdriver is
> Log Message:
> Tweak wording for consistency: `if empty or not set', not `if unset'.
is this correct?
rc complains if unset or not set (ie, if "$foo" is zero length):
/etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5).
.mrg.
On 15/01/2021 02:43, Simon Burge wrote:
I'll test a bit more
I can't actually test as my ERLite won't boot anymore.
Console light is green, cu says I'm connected but I get nothing out of it.
With cat5 cables plugged in the ports they flash green and then stick on amber.
I'm guessing this is
On 15/01/2021 07:15, matthew green wrote:
Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
and is the same struct on all BSD. While bringing the same functionality to
IPv4, I elected to keep the same struct just to have the same API, warts
and all. I like consistency.
> Oh, I quite agree.
> However, in6_nbrinfo predates my involvement with NetBSD and is the same
> struct
> on all BSD. While bringing the same functionality to IPv4, I elected to keep
> the
> same struct just to have the same API, warts and all. I like consistency.
[ .. ]
>
> That breaks
On 15/01/2021 02:43, Simon Burge wrote:
Hi Roy,
Roy Marples wrote:
On 14/01/2021 11:03, Simon Burge wrote:
Sure, I will have a look. Anything IPv6 related I might need a helping
hand to get a test case though :).
As they share a similar structure, you solve one you likely solve the other.
Hi Roy,
Roy Marples wrote:
> On 14/01/2021 11:03, Simon Burge wrote:
> > Sure, I will have a look. Anything IPv6 related I might need a helping
> > hand to get a test case though :).
>
> As they share a similar structure, you solve one you likely solve the other.
> I can assume you have working
On 14/01/2021 11:03, Simon Burge wrote:
Sure, I will have a look. Anything IPv6 related I might need a helping
hand to get a test case though :).
As they share a similar structure, you solve one you likely solve the other.
I can assume you have working IPv4 ;)
Roy
Module Name:src
Committed By: pgoyette
Date: Thu Jan 14 19:07:03 UTC 2021
Modified Files:
src/distrib/sets/lists/debug: mi
Log Message:
/home/paul/XXX.txt
Crap - meant to include the text file... Here's the good log info...
Update sets lists to accomodate
Roy Marples wrote:
> On 14/01/2021 08:00, Simon Burge wrote:
> > Module Name:src
> > Committed By: simonb
> > Date: Thu Jan 14 08:00:45 UTC 2021
> >
> > Modified Files:
> > src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h
> >
> > Log Message:
On 14/01/2021 08:00, Simon Burge wrote:
Module Name:src
Committed By: simonb
Date: Thu Jan 14 08:00:45 UTC 2021
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h
Log Message:
Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with
On 09.01.2021 17:42, Martin Husemann wrote:
On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:
I guess a simple "make clean && make" will clear up the situation.
Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove
On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:
> I guess a simple "make clean && make" will clear up the situation.
Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove all lint objdirs completely).
Please add an
On 09.01.2021 12:42, Jared McNeill wrote:
Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:
--- lint1 ---
# link lint1/lint1
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
That's weird
Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:
--- lint1 ---
# link lint1/lint1
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-I/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/include/compat
Hi Roy !
That looks more semantics (the ones I know of - dynamic interface
scanning is one of my NTPd parts)
preserving now.
So far I see no other issues from the pitfalls I know of.
Lets hope our kernel and other SO_RERRORS systems miss any
interface scan worthy events.
Frank
On
On 02/01/2021 23:33, Frank Kardel wrote:
Also the behavior now fully relies in the routing message functionality which
can be disabled
on serious procession errors - at that point the code robustness relies on the
periodic
re-scanning - so I am not sure whether the periodic re-scanning
On 02/01/2021 23:33, Frank Kardel wrote:
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
...
This patch seems (by visual inspection) to
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
See man ntpd:
...
−U number, −−updateinterval=number
interval in
On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on a timer
approach.
Does this look ok?
Better patch:
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33 2021
Hi Frank
On 02/01/2021 09:55, Frank Kardel wrote:
I doubt that the explicit draining is helpful here as it already happens
I was aware of that.
I was just trying to avoid excess timer interface timeouts if we don't get
around to reading the next message in UPDATE_GRACE time.
Let's see what
Hi Roy !
I doubt that the explicit draining is helpful here as it already happens
in the outer loop processing any routing socket input. All that is happening
in the routing messages processing path is to call
timer_interfacetimeout(current_time + UPDATE_GRACE) and
this is robust for
>sys/external/gpl2/dts/dist is meant for upstream dts files only. Do
>you mind moving this to sys/arch/arm/dts with the other custom dts files?
Ah, I Understood. Sorry, I didn't have a good grasp of the
sys/external/gpl2/dts/dist/arch policy.
I will move it to sys/arch/arm/dts.
Thanks!
--
Please also add the appropriate entry to src/distrib/sets/lists/debug.mi
for those of us who build with MKDEBUG=YES
:)
On Sat, 2 Jan 2021, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Sat Jan 2 03:24:02 UTC 2021
Modified Files:
Date:Fri, 1 Jan 2021 20:38:36 +
From:"Roy Marples"
Message-ID: <20210101203836.2cadcf...@cvs.netbsd.org>
| Modified Files:
| src/external/bsd/unbound/lib/libunbound: Makefile
|
| Log Message:
| libunbound: Now we use libevent, don't build mini_event
Hi!
sys/external/gpl2/dts/dist is meant for upstream dts files only. Do
you mind moving this to sys/arch/arm/dts with the other custom dts files?
Thanks!
Jared
On Fri, 1 Jan 2021, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Fri Jan 1 07:41:46 UTC 2021
Oops. The change was to make sure that a devicetree node with a
"rockchip,grf" property on a device type that doesn't provide a config
struct doesn't deref a NULL ptr.
On Fri, 1 Jan 2021, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Fri Jan 1 11:44:41
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Tue Dec 22 08:10:39 UTC 2020
>
> Modified Files:
> src/usr.bin/make: parse.c
i'm not sure which change did it (but before this one for sure),
but my builds crash early now (still trying to bootstrap nbmake):
In article <20201213212746.3cfc3f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Sun Dec 13 21:27:46 UTC 2020
>
>Modified Files:
> src/usr.bin/make: for.c meta.c parse.c var.c
>
>Log Message:
>make(1): replace %zu with %u in
On Sun, Dec 13, 2020 at 12:04:40AM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Sun Dec 13 00:04:40 UTC 2020
>
> Modified Files:
> src/external/gpl2/diffutils/dist/src: util.c
>
> Log Message:
> diffutils: execl requires a NULL sentinel
Strictly
On 2020/12/11 14:01, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Dec 11 05:01:19 UTC 2020
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c ixgbe_type.h
Log Message:
Don't use EIMC_OTHER bit because it's read only other than 82598.
Documents
On 10.12.2020 08:14, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Thu Dec 10 07:14:58 UTC 2020
>
> Modified Files:
> src/external/gpl3/gdb/dist/gdb: nbsd-nat.c
>
> Log Message:
> Fix arm, for which PT_STEP is defined but unimplemented.
>
> XXX
> Stop exposing
> On Dec 4, 2020, at 8:57 AM, Christos Zoulas wrote:
>
> In article <20201204004439.90c25f...@cvs.netbsd.org>,
> Jason R Thorpe wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:thorpej
>> Date:Fri Dec 4 00:44:39 UTC 2020
>>
>> Modified Files:
>>
In article <20201204004439.90c25f...@cvs.netbsd.org>,
Jason R Thorpe wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: thorpej
>Date: Fri Dec 4 00:44:39 UTC 2020
>
>Modified Files:
> src/sys/netinet: files.ipfilter
>
>Log Message:
>Build ip_sync.c with -Wno-error to avoid
On 2020-11-28, Yorick Hardy wrote:
> Module Name: src
> Committed By: yhardy
> Date: Sat Nov 28 22:53:06 UTC 2020
>
> Modified Files:
> src/external/cddl/osnet/dist/uts/common/fs/zfs: vdev_disk.c
>
> Log Message:
> Use vn_close to release the vnodes in the error handling blocks,
Excellent! Thank you so much for finding out and fixing this!
Full ATF successfully completed for Raspberry Pi 2b, which formerly
crashed due to "anon != NULL && anon->an_ref != 0" panic.
Now, ATF is running on Cubietruck and Raspberry Pi Zero W.
Thanks,
rin
On 2020/11/22 4:44, Nick Hudson
Please pull up to netbsd-8 and netbsd-9 release branches.
> On Nov 11, 2020, at 23:44, Simon Burge wrote:
>
> Module Name: src
> Committed By: simonb
> Date: Thu Nov 12 07:44:01 UTC 2020
>
> Modified Files:
> src/sys/conf: param.c
> src/sys/kern: init_main.c
>
On Sun, Nov 08, 2020 at 09:56:48PM +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Sun Nov 8 21:56:48 UTC 2020
>
> Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
> src/external/ibm-public/postfix: Makefile.inc
>
On 2020/11/13 2:35, nia wrote:
I'll revert the commit shortly.
Thank you very much for your quick response.
I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.
Yeah, this is why we need tests, and also listen to
On Thu, Nov 12, 2020 at 07:58:13PM +, Taylor R Campbell wrote:
> But there's a snag with heimdal.
>
> Heimdal exposes the sqlite3 library to clients via libgssapi.so which
> links against libkrb5.so which brings in libsqlite3.so. So we get nice
> situations like this:
>
> % ldd
> Date: Thu, 12 Nov 2020 11:21:43 -0800
> From: Jason Thorpe
>
> > On Nov 12, 2020, at 9:40 AM, nia wrote:
> >
> > For the record I'm just trying to fix things so that running
> > third-party software on NetBSD sucks less. If fewer third-party
> > libraries were exposed by the base system this
> On Nov 12, 2020, at 9:40 AM, nia wrote:
>
> For the record I'm just trying to fix things so that running
> third-party software on NetBSD sucks less. If fewer third-party
> libraries were exposed by the base system this wouldn't be
> necessary.
Why do we even have sqlite in the base system
On Thu, Nov 12, 2020 at 05:35:44PM +, nia wrote:
> I'll revert the commit shortly.
>
> I wasn't expecting such major breakage (obviously) and actually
> did run a build but ran into different problems with libstdc++.
For the record I'm just trying to fix things so that running
third-party
I'll revert the commit shortly.
I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.
On 2020/11/12 23:03, Rin Okuyama wrote:
The backtrace reads:
| (gdb) bt
| #0 0xfc2961bca308 in ?? ()
| #1 0xfc2961b9ec10 in __deregister_frame_info_bases ()
| from /usr/lib/libgcc_s.so.1
| #2 0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400,
|
On 2020/11/11 1:50, nia wrote:
On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote:
Module Name:src
Committed By: nia
Date: Sun Nov 8 21:56:48 UTC 2020
Modified Files:
src/external/bsd/kyua-cli: Makefile.inc
src/external/ibm-public/postfix:
On 2020/11/12 6:52, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Nov 10 21:40:07 UTC 2020
Modified Files:
src/sys/arch/arm/arm: cpu_exec.c
Log Message:
Test (epp->ep_esch->es_emul != _netbsd) instead of
nice, this is a step
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Nov 10 21:40:07 UTC 2020
>
> Modified Files:
> src/sys/arch/arm/arm: cpu_exec.c
>
> Log Message:
> Test (epp->ep_esch->es_emul != _netbsd) instead of
nice, this is a step forward.
an optimisation on it could
On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By: nia
> > Date: Sun Nov 8 21:56:48 UTC 2020
> >
> > Modified Files:
> > src/external/bsd/kyua-cli: Makefile.inc
> > src/external/ibm-public/postfix: Makefile.inc
> Module Name:src
> Committed By: nia
> Date: Sun Nov 8 21:56:48 UTC 2020
>
> Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
> src/external/ibm-public/postfix: Makefile.inc
> src/external/public-domain/sqlite: Makefile.inc
>
On 2020/11/10 1:15, Christos Zoulas wrote:
- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
file, instead of writing directly to ${.TARGET} and then overwriting
${.TARGET} with ctfconvert. This avoids build failures after a build
got interrupted (the "partially
On 08.11.2020 22:56, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Sun Nov 8 21:56:48 UTC 2020
>
> Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
> src/external/ibm-public/postfix: Makefile.inc
> src/external/public-domain/sqlite:
On 08.11.2020 17:55, Christos Zoulas wrote:
> In article <20201108145236.3a009f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sun Nov 8 14:52:36 UTC 2020
>>
>> Modified Files:
>> src: BUILDING
>>
In article <20201108145236.3a009f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sun Nov 8 14:52:36 UTC 2020
>
>Modified Files:
> src: BUILDING
> src/distrib/sets: sets.subr
> src/doc: BUILDING.mdoc
>
Thanks for checking!
I agree with your proposed changes. If noone else objects, please
go ahead and commit.
On Sun, 8 Nov 2020, Rin Okuyama wrote:
Thanks Paul for finding out the bug!
Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without
Thanks Paul for finding out the bug!
Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.
However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.
By
Thanks for fixing ...
On Sat, 7 Nov 2020, Christos Zoulas wrote:
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined
> .if ${MACHINE_ARCH} == "arm"
this is wrong. it should use MACHINE_CPU.
.mrg.
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
> On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
>
> OK, I think I found the problem, but I don't know how to solve it...
>
> All of the undefined symbols are supposed to be provided by
>
>
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined symbols are supposed to be provided by
.../sys/arch/arm/arm32/netbsd32_machdep.c
but there is no netbsd32_machdep.o included in the compat_netbsd32
module. This file should be included by the
On 2020/11/05 23:07, Paul Goyette wrote:
I will investigate.
Thanks!
Can you confirm that it works correctly if you have the built-in
module? (ie, kernel with ``options COMPAT_NETBSD32'')
Yes, it works fine.
rin
I will investigate.
Can you confirm that it works correctly if you have the built-in
module? (ie, kernel with ``options COMPAT_NETBSD32'')
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then
On 2020/11/05 2:45, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and
OK, this is my mistake. When I change the calls in the ptrace_common
modcmd, I should also have renamed the functions (including their
entries in sys/ptrace.h). I will commit this shortly, before I leave.
Thanks for the "recipe" for reproducing the problem - I will try it
later when I return.
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in
> On Nov 4, 2020, at 5:33 AM, Paul Goyette wrote:
>
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.
In this particular case, it's for the old 32-bit ABI that predates the EABI
standard the ARM port now uses.
-- thorpej
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via
On 2020/11/04 22:31, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name: src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
On Wed, Nov 04, 2020 at 05:33:29AM -0800, Paul Goyette wrote:
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.
(At least) mips and arm have various 32bit ABIs that are handled by
COMPAT_NETBSD32.
Martin
I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.
Christos, can you help out on this?
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hello again,
On 2020/11/02 3:51, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't
Hello again,
On 2020/11/02 3:51, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1 18:51:03 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini
On Sun, 1 Nov 2020, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1 18:51:03 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
I've asked.
Best,
christos
> On Nov 1, 2020, at 11:19 AM, Kimmo Suominen wrote:
>
>> Log Message:
>> CHANGED FROM 3.1b TO 3.1c
>>
>> * Do not write after the end of the array and overwrite the stack when
>> colon-separated SGR sequences contain empty arguments.
>
> Pullup to -9 and -8 for
> Log Message:
> CHANGED FROM 3.1b TO 3.1c
>
> * Do not write after the end of the array and overwrite the stack when
> colon-separated SGR sequences contain empty arguments.
Pullup to -9 and -8 for security fix?
https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html
On Wed, 2020-10-28 at 11:56 +, nia wrote:
> On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote:
> > > i can have a look at mate-applets tomorrow, the current code looks
> > > like it won't work with AMD CPUs on netbsd-9 and that should
> > > ideally
> > > be fixed.
> >
> >
On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote:
> > i can have a look at mate-applets tomorrow, the current code looks
> > like it won't work with AMD CPUs on netbsd-9 and that should ideally
> > be fixed.
>
> Yeah, that's my understanding. (I'm guessing Youri only had Intel
On Tue, 2020-10-27 at 19:54 +, nia wrote:
> On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> > On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
> > > On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> > > > this doesn't seem like the right design. we have
On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
> >On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> >> this doesn't seem like the right design. we have cpus
> >> already that have multiple frequency domains,
On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
>On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
>> this doesn't seem like the right design. we have cpus
>> already that have multiple frequency domains, so this
>> doesn't work with that setup, so attempt to use it as a
>> general
On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> this doesn't seem like the right design. we have cpus
> already that have multiple frequency domains, so this
> doesn't work with that setup, so attempt to use it as a
> general method for estd etc seems limited and thsu not
> the
On Sun, Oct 25, 2020 at 05:37:36PM +, Simon J. Gerraty wrote:
> Modified Files:
> src/usr.bin/make: main.c
> src/usr.bin/make/unit-tests: varmod-match-escape.exp
>
> Log Message:
> Skip reading .MAKE.DEPENDFILE if set to
> "/dev/null" or anything starting with "no".
>
>
"Nia Alarie" writes:
> Module Name: src
> Committed By: nia
> Date: Sun Oct 25 16:39:00 UTC 2020
>
> Modified Files:
> src/share/man/man4: acpicpu.4
> src/share/man/man4/man4.x86: est.4 powernow.4
> src/sys/arch/evbmips/loongson: loongson_clock.c
>
1001 - 1100 of 11259 matches
Mail list logo
