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
>
On Sat, Oct 24, 2020 at 10:38:04PM +0700, Robert Elz wrote:
> | file systems that are used as what spools?
>
> Ah, youth!
>
> The old text:
> This option is useful for optimizing read performance on file systems
> that are used as news spools.
> was refering to netnews (usenet,
On Sat, Oct 24, 2020 at 10:51:34AM +, Nia Alarie wrote:
> Modified Files:
> src/sbin/mount: mount.8
>
> Log Message:
> file systems that are used as what spools?
Kibozing caches.
--
David A. Holland
dholl...@netbsd.org
Hi Tobias,
> If you're interested there is an older version[1] of envctrl in the
> Attic that might be relevant to use for reference. It supported fan
> speed controls on E450. IIRC I got some of the magic constants from
> OpenSolaris. Sadly I don't own an E450 any more.
>
> [1]
>
On Sat, 24 Oct 2020 15:16:39 +
Julian Coleman wrote:
> Module Name: src
> Committed By: jdc
> Date: Sat Oct 24 15:16:39 UTC 2020
>
> Modified Files:
> src/sys/arch/sparc64/dev: pcf8591_envctrl.c
>
> Log Message:
> Add support for automatically changing the CPU fan speed on
Date:Sat, 24 Oct 2020 10:51:34 +
From:"Nia Alarie"
Message-ID: <20201024105134.6539bf...@cvs.netbsd.org>
| file systems that are used as what spools?
Ah, youth!
The old text:
This option is useful for optimizing read performance on file systems
Hi,
On 2020/10/21 15:42, Michael wrote:
Hello,
On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama" wrote:
Module Name:src
Committed By: rin
Date: Sun Oct 18 11:54:21 UTC 2020
Modified Files:
src/sys/dev/wsfb: genfb.c
Log Message:
For WSDISPLAYIO_GET_FBINFO ioctl, set
Hello,
On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Oct 18 11:54:21 UTC 2020
>
> Modified Files:
> src/sys/dev/wsfb: genfb.c
>
> Log Message:
> For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
>
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote:
> I'm also one who feels hesitate to import Linux'ism into our basic
> components. However, for this problem in particular, I still think
> it is not a good choice to keep NetBSD support in driver-aarch64.c:
>
> (a) Our sysctl(3)-based
Hi,
(tech-toolchain@ added to cc)
On 2020/10/16 1:49, Kamil Rytarowski wrote:
On 15.10.2020 17:14, Rin Okuyama wrote:
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes
This still isn't quite correct.
For i386, a custom kernel build fails. Here's the diff between GENERIC
and the custom config (this mirrors the config I used on amd64 to file
the original PR kern/55731):
--- GENERIC 2020-09-27 22:28:13.468056102 -0700
+++ TEST2020-10-20
I am getting errors, too, when I build a NOCOMPAT kernel:
# link NOCOMPAT/netbsd
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0x8020 -e start -z
max-page-size=0x20 -X -o netbsd
Hi,
This causes build failures for LP64 archs without COMPAT_NETBSD32,
i.e., alpha and ie64:
kern_core.o: in function `coredump_modcmd':
(.text+0x1c4): undefined reference to `real_coredump_elf32
https://releng.netbsd.org/builds/HEAD/202010200300Z/
(Failure for aarch64eb is irrelevant, and
In article <20201019144701.a6d3bf...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Mon Oct 19 14:47:01 UTC 2020
>
>Modified Files:
> src/sys/kern: sys_ptrace.c sys_ptrace_common.c
>
>Log Message:
>Remove obsolete references
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun Oct 18 10:10:18 UTC 2020
>
> Modified Files:
> src/distrib/sets/lists/debug: mi module.mi
>
> Log Message:
> Fix build for mips; move from mi to module.mi debug symbols for
> test cases only available when
On 2020/10/18 21:18, Jared McNeill wrote:
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get
when you mmap the device. When shadow FB is used, that is generally only used
for rasops and mmap bypasses the shadow and uses device memory directly. So I
think this could
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you
get when you mmap the device. When shadow FB is used, that is generally
only used for rasops and mmap bypasses the shadow and uses device memory
directly. So I think this could cause performance regressions on such
Date:Fri, 16 Oct 2020 04:07:31 +
From:"Thomas Mueller"
Message-ID: <20201016052422.e063084...@mail.netbsd.org>
| Should I add ,linux to the end of the procfs line?
You can, but it isn't needed these days -- I used to mount procfs twice,
once without the linux
On Fri, 2020-10-16 at 04:59 +, Martin Husemann wrote:
> On Thu, Oct 15, 2020 at 05:44:45PM +, Micha? G?rny wrote:
> > Module Name:src
> > Committed By: mgorny
> > Date: Thu Oct 15 17:44:45 UTC 2020
> >
> > Modified Files:
> > src/distrib/sets/lists/tests:
On 2020/10/16 14:53, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Oct 16 05:53:40 UTC 2020
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Fixes a problem that the attach function reported
"wm_gmii_setup_phytype: Unknown PHY model.
Excerpt from Rin Okuyama:
> Nowadays, -o linux is turned on by default (unless nolinux is
> specified explicitly). Still, native apps probably should not
> depend on it.
> This needs MI changes to procfs, not MD to aarch64. Should we
> enable /proc/cpuinfo unconditionally?
My NetBSD
On Thu, Oct 15, 2020 at 05:44:45PM +, Micha? G?rny wrote:
> Module Name: src
> Committed By: mgorny
> Date: Thu Oct 15 17:44:45 UTC 2020
>
> Modified Files:
> src/distrib/sets/lists/tests: mi
> src/etc/mtree: NetBSD.dist.tests
> src/tests/sys: Makefile
> Added
On 15.10.2020 17:14, Rin Okuyama wrote:
> On 2020/10/15 16:12, matthew green wrote:
>> Martin Husemann writes:
>>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux. ryo@ recently
added additional /proc/cpuinfo support
1001 - 1100 of 11236 matches
Mail list logo
