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
On Wed, Oct 14, 2020 at 10:13:21PM +0100, Roy Marples wrote:
> On 14/10/2020 20:07, Kimmo Suominen wrote:
> > - not interfere with (static) IPv4 configuration
>
> How do you expect
> ifconfig_vioif0='dhcp rtsol'
> to work?
When I added the code for the rtsol keyword, I did not imagine that
it
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 that should make this
> > just
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 that should make this
> just work with the upstream version, but
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:12:00 UTC 2020
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c
>
> Log Message:
> Reduce diff with upstream a bit.
> No functional changes.
you could try
On 14/10/2020 20:07, Kimmo Suominen wrote:
> - not interfere with (static) IPv4 configuration
How do you expect
ifconfig_vioif0='dhcp rtsol'
to work?
With recent dhcpcd changes, it is possible to get them working independently of
each other, but as it stands right now, you just killed ipv4
Hi Roy,
On Mon, Oct 12, 2020 at 03:56:44PM +0100, Roy Marples wrote:
> Can you explain how it was not functional before and how this fixes it?
I think the change was well described in the same commit in the manual
page updates that you did not quote in your message. The "rtsol" keyword
is used
Thanks for fixing it!
christos
signature.asc
Description: Message signed with OpenPGP
On 13.10.2020 11:14, Leonardo Taccari wrote:
> Hello Kamil,
>
> Kamil Rytarowski writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Oct 6 23:14:47 UTC 2020
>>
>> Modified Files:
>> src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c
>>
>> Log Message:
On Tue, Oct 13, 2020 at 12:57:44PM +0200, Kamil Rytarowski wrote:
> > Log Message:
> > BE32 binaries are no longer supported for ARMv7 and later, and
> > therefore for aarch64eb.
> >
> > Reject them with ENOEXEC, rather than causing illegal instruction
> > exceptions due to unexpected binary
On 2020/10/13 19:57, Kamil Rytarowski wrote:
On 13.10.2020 09:04, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Oct 13 07:04:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: exec_machdep.c
Log Message:
BE32 binaries are no longer supported for
On 13.10.2020 09:04, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:04:49 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: exec_machdep.c
>
> Log Message:
> BE32 binaries are no longer supported for ARMv7 and later, and
> therefore for
Hello Kamil,
Kamil Rytarowski writes:
> Module Name: src
> Committed By: kamil
> Date: Tue Oct 6 23:14:47 UTC 2020
>
> Modified Files:
> src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c
>
> Log Message:
> Undo local patches
>
> They are no longer needed (and are wrong).
>
On Tue, Oct 13, 2020 at 12:15:58AM +0900, Izumi Tsutsui wrote:
> IIRC I added it to avoid users from accidentally destroy existing native
> Windows partition (for NetBSD/arc that initially required FAT partition).
I see. If needed we can add more safety checks when setting the newfs flag
(like we
martin@ wrote:
> Module Name: src
> Committed By: martin
> Date: Mon Oct 12 14:29:41 UTC 2020
>
> Modified Files:
> src/usr.sbin/sysinst: disks.c
>
> Log Message:
> Remove very strange code that special-cased MSDOS file systems and refused
> to newfs the partition (despite
Hi Kimmo
On 11/10/2020 23:38, Kimmo Suominen wrote:
Module Name:src
Committed By: kim
Date: Sun Oct 11 22:38:48 UTC 2020
Modified Files:
src/etc/rc.d: network
src/share/man/man5: ifconfig.if.5
Log Message:
Make "rtsol" functional again.
Hello,
On Sun, 11 Oct 2020 21:41:57 +
"Julian Coleman" wrote:
> Module Name: src
> Committed By: jdc
> Date: Sun Oct 11 21:41:57 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: radeonfb.c
>
> Log Message:
...
> don't ignore the bottom 200 lines of the display (for no
On Mon, 07 Sep 2020 at 20:47:25 +1000, matthew green wrote:
"Jason R Thorpe" writes:
Module Name:src
Committed By: thorpej
Date: Mon Sep 7 03:50:41 UTC 2020
Modified Files:
src/sys/kern: files.kern init_main.c
Log Message:
Add the ability to set an alternate cnmagic
Date:Thu, 08 Oct 2020 19:11:59 +1100
From:matthew green
Message-ID: <22915.1602144...@splode.eterna.com.au>
| at least pacificnew is referenced by the build still:
Yes, sorry, the way that tzdata updates get done makes it
essentially impossible to test what is
"Robert Elz" writes:
> Module Name: src
> Committed By: kre
> Date: Thu Oct 8 04:28:00 UTC 2020
>
> Modified Files:
> src/external/public-domain/tz/dist: TZDATA_VERSION
> Removed Files:
> src/external/public-domain/tz/dist: pacificnew systemv yearistype.sh
at least
Thank you very much!
Thomas
> On 06.10.2020, at 15:42, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Tue Oct 6 13:42:03 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/include: vmparam.h
> src/sys/arch/amd64/include: vmparam.h
>
It works fine now. Thank you for quick fix!!
rin
On 2020/10/06 15:28, Nick Hudson wrote:
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S where the callers exist
To generate
Christos Zoulas committed:
> Module Name:src
> Committed By: christos
> Date: Sun Oct 4 19:32:48 UTC 2020
>
> Modified Files:
> src/crypto/external/bsd/openssl/dist/crypto/bn: bn_print.c
> src/crypto/external/bsd/openssl/dist/include/openssl: bn.h
>
Thanks, I will change it as you suggest.
christos
> On Oct 5, 2020, at 6:20 AM, Rin Okuyama wrote:
>
> Hi,
>
> On 2020/10/05 4:32, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Oct 4 19:32:48 UTC 2020
>> Modified Files:
>>
Hi,
On 2020/10/05 4:32, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Oct 4 19:32:48 UTC 2020
Modified Files:
src/crypto/external/bsd/openssl/dist/crypto/bn: bn_print.c
src/crypto/external/bsd/openssl/dist/include/openssl: bn.h
I will do it once I have BN_bn2oct() done :-)
It is a bit harder to write...
christos
> On Oct 4, 2020, at 7:41 PM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Oct 4 19:32:48 UTC 2020
>>
>> Modified
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Oct 4 19:32:48 UTC 2020
>
> Modified Files:
> src/crypto/external/bsd/openssl/dist/crypto/bn: bn_print.c
> src/crypto/external/bsd/openssl/dist/include/openssl: bn.h
>
On 2020/10/02 22:42, Jonathan A. Kollasch wrote:
On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Jul 21 15:57:24 UTC 2019
Modified Files:
src/sys/dev/fdt: dw_apb_uart.c
Log Message:
The device cannot recognize
On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Jul 21 15:57:24 UTC 2019
>
> Modified Files:
> src/sys/dev/fdt: dw_apb_uart.c
>
> Log Message:
> The device cannot recognize break signal. Use + (five plus signs) as
>> Index: src/sys/arch/aarch64/include/cpu.h
>> diff -u src/sys/arch/aarch64/include/cpu.h:1.27 src/sys/arch/aarch64/inc=
>lude/cpu.h:1.28
>> --- src/sys/arch/aarch64/include/cpu.h:1.27 Mon Sep 14 10:06:35 2020
>> +++ src/sys/arch/aarch64/include/cpu.h Thu Oct 1 06:40:16 2020
>> @@ -1,4
On 01/10/2020 07:40, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Oct 1 06:40:16 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: procfs_machdep.c
src/sys/arch/aarch64/include: cpu.h
Log Message:
fix build error with LLVM
[...]
Index:
On 30/09/2020 08:55, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Wed Sep 30 07:55:31 UTC 2020
Modified Files:
src/etc/mtree: NetBSD.dist.tests
Log Message:
add missing new if_vether subdir.
Thanks!
> Module Name: src
> Committed By: jdolecek
> Date: Sun Sep 27 18:17:35 UTC 2020
>
> Modified Files:
> src/sbin/nvmectl: nvmectl.8 nvmectl.h power.c
>
> Log Message:
> add -s option for 'power' command, this instructs the controller to save
> the value so it persists
On 24.09.2020 18:02, Jonathan A. Kollasch wrote:
cvs rdiff -u -r1.65 -r1.66 src/usr.bin/make/lst.h
breaks build on Debian 9:
In file included from /local/jakllsch/netbsd/src/usr.bin/make/make.h:158:0,
from /local/jakllsch/netbsd/src/usr.bin/make/arch.c:130:
>On 24/09/2020 10:04, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Thu Sep 24 09:04:38 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
>>
>> Log Message:
>> fix bugs in *_bs_rm_8_swap(). it was only
> cvs rdiff -u -r1.65 -r1.66 src/usr.bin/make/lst.h
breaks build on Debian 9:
In file included from /local/jakllsch/netbsd/src/usr.bin/make/make.h:158:0,
from /local/jakllsch/netbsd/src/usr.bin/make/arch.c:130:
/local/jakllsch/netbsd/src/usr.bin/make/lst.h:92:5: error: unknown
On 24/09/2020 10:04, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Sep 24 09:04:38 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
Log Message:
fix bugs in *_bs_rm_8_swap(). it was only reading 4 bytes, not 8 bytes.
I
Hi Maxime, (board@, source-changes-d@)
first of all thank you for contacting board@, as suggested by Taylor.
As I communicated to you directly a week ago, we at board@ have
discussed the situation and asked you for the full list of files, where
you would like to update the
On Tue, 22 Sep 2020 23:52:38 +
Taylor R Campbell wrote:
> > Date: Wed, 23 Sep 2020 01:46:14 +0200
> > From: Tobias Nygren
> >
> > > Modified Files:
> > > src/include: unistd.h
> > > src/lib/libc/gen: Makefile.inc
> > > Removed Files:
> > > src/lib/libc/gen: getentropy.3 getentropy.c
> Date: Wed, 23 Sep 2020 01:46:14 +0200
> From: Tobias Nygren
>
> > Modified Files:
> > src/include: unistd.h
> > src/lib/libc/gen: Makefile.inc
> > Removed Files:
> > src/lib/libc/gen: getentropy.3 getentropy.c
> >
> > Log Message:
> > remove getentropy bits
>
> I know it is
Hi,
On Tue, 22 Sep 2020 21:37:47 +
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Tue Sep 22 21:37:47 UTC 2020
>
> Modified Files:
> src/include: unistd.h
> src/lib/libc/gen: Makefile.inc
> Removed Files:
> src/lib/libc/gen: getentropy.3
Hi,
Chuck Silvers writes:
> On Tue, Sep 22, 2020 at 01:51:33AM +0900, Ryo ONODERA wrote:
>> Hi,
>>
>> It seems that r1.124 of uvm_amap.c causes random userland segfaults
>> on my NetBSD/amd64.
>
> this should be fixed now, could you try again?
>
> this was another case of my usual trick "test
On Tue, Sep 22, 2020 at 01:51:33AM +0900, Ryo ONODERA wrote:
> Hi,
>
> It seems that r1.124 of uvm_amap.c causes random userland segfaults
> on my NetBSD/amd64.
this should be fixed now, could you try again?
this was another case of my usual trick "test a change well, modify
the change at the
Hi,
It seems that r1.124 of uvm_amap.c causes random userland segfaults
on my NetBSD/amd64.
If you cannot reproduce the random segfaults, I will send my backtraces.
"Chuck Silvers" writes:
> Module Name: src
> Committed By: chs
> Date: Sun Sep 20 23:03:01 UTC 2020
>
> Modified Files:
On Wed, Sep 16, 2020 at 06:26:45PM +, m...@netbsd.org wrote:
> Since the background for this is an issue nobody else is experiencing,
> can you at least report a bug for how to reach it?
hello?
in the original proposal joerg already said it has a chance of making
opengl not reentrant. the
I don't think this should be reverted, because LUN 0 must exist, but if
there is no device on it, it will report "NOT PRESENT". We do not want
the scan to stop in this case, but it should continue with other LUNs
(such as those found through REPORT LUNS in the future).
Kind regards,
+ Kimmo
On
Since the background for this is an issue nobody else is experiencing,
can you at least report a bug for how to reach it?
On Wed, Sep 16, 2020 at 06:19:24PM +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Wed Sep 16 18:19:24 UTC 2020
>
> Modified Files:
>
On Tue, Sep 15, 2020 at 03:32:25PM +0200, Kamil Rytarowski wrote:
> I've tried to mark the TSan parts that need porting as explicit failure,
> soo we can reduce the risk of shipping unported runtime.
That risc is quite low as currently the runtime is apparently not buildable
on anything but amd64
On 15.09.2020 07:03, Martin Husemann wrote:
> On Mon, Sep 14, 2020 at 03:17:53PM +, Kamil Rytarowski wrote:
>> Enable TSan tests for GCC and >32bit address space environments
>
> Since tsan does not work on all architectures, this is not a good idea.
> It would be better to code it with an
On Mon, Sep 14, 2020 at 03:17:53PM +, Kamil Rytarowski wrote:
> Enable TSan tests for GCC and >32bit address space environments
Since tsan does not work on all architectures, this is not a good idea.
It would be better to code it with an explicit list of architectures
supported.
Martin
On 14.09.2020 21:05, Robert Elz wrote:
Date:Mon, 14 Sep 2020 16:16:52 +
From:"Roland Illig"
Message-ID: <20200914161652.d4eb5f...@cvs.netbsd.org>
| make(1): inline LPAREN in parse.c
|
| It's shorter and more readable, and the other characters don't
Date:Mon, 14 Sep 2020 16:16:52 +
From:"Roland Illig"
Message-ID: <20200914161652.d4eb5f...@cvs.netbsd.org>
| make(1): inline LPAREN in parse.c
|
| It's shorter and more readable, and the other characters don't have
| named constants as well.
Most likely
On 12.09.2020 23:36, Joerg Sonnenberger wrote:
> On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote:
>> On 12.09.2020 22:06, Joerg Sonnenberger wrote:
>>> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> On
On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote:
> On 12.09.2020 22:06, Joerg Sonnenberger wrote:
> > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
> >> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil
On 12.09.2020 22:06, Joerg Sonnenberger wrote:
> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
>> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
>>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
The current code is confusing, as it attempts to use
On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
> >> The current code is confusing, as it attempts to use unimplemented
> >> _PTHREAD_GETTCB_EXT() and in one
Jared McNeill wrote in
:
|On Sat, 12 Sep 2020, Olaf Seibert wrote:
|
|> bozohttpd: add .m4a and .m4v file extensions.
|
|I don't think audio/mpeg is correct for .m4a. Since .m4a is MPEG audio in
|an MP4 container, I would follow RFC 4337 ("MIME Type Registration for
|MPEG-4") here which
On 11.09.2020 06:57, Rin Okuyama wrote:
> On 2020/09/10 18:28, Kamil Rytarowski wrote:
>> On 10.09.2020 10:50, Rin Okuyama wrote:
>>> On 2020/09/10 16:41, Kamil Rytarowski wrote:
On 10.09.2020 03:53, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date:
On Sat, 12 Sep 2020, Olaf Seibert wrote:
bozohttpd: add .m4a and .m4v file extensions.
I don't think audio/mpeg is correct for .m4a. Since .m4a is MPEG audio in
an MP4 container, I would follow RFC 4337 ("MIME Type Registration for
MPEG-4") here which says you should use audio/mp4 instead.
On 11.09.2020 17:16, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Fri Sep 11 15:16:00 UTC 2020
>
> Modified Files:
> src/sys/net: if_llatbl.c
> src/sys/netinet: if_arp.c if_inarp.h tcp_input.c
>
> Log Message:
> ARP: Use ND rather than our own.
>
> This
On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
>> The current code is confusing, as it attempts to use unimplemented
>> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in
>> other _lwp_getprivate(). This caused
1101 - 1200 of 11274 matches
Mail list logo
