Re: CVS commit: src/sys/dev/pci
In article , Reinoud Zandijk wrote: >On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote: >> > +#ifndef _LP64 >> >> _LP64 is a terrible way to make this choice. >> >> heaps of our 32 bit platforms implement the _8 variants. > >Can't we then just make sure they have the 8 bit variant? and set a define if >its atomic or not? > >This way drivers van use the _8 variant freely and for the few drivers that >NEED the atomicity, they can check the define and deal with it the way they >like. Perhaps. But still for the ones that don't have it should use the central implementation so that we don't duplicate code. christos
Re: CVS commit: src/sys/dev/pci
In article ,
Nick Hudson wrote:
>On 22/01/2021 04:48, Christos Zoulas wrote:
>> +#if _QUAD_HIGHWORD
>> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
>> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
>> +#else
>> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
>> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value & 0x));
>> +#endif
>> +}
>> +#endif /* !_LP64 */
>
>
>BUS_ADDR_{HI,LO}32 are also available for your convenience.
Will use those thanks!
christos
Re: CVS commit: src/sys/kern (kern_event.c)
On Fri, 22 Jan 2021, Paul Goyette wrote: On Thu, 21 Jan 2021, Paul Goyette wrote: Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. OK, I built and installed a new kernel+userland. Most everything works, and syslogd seems to work fine (at least, it no longer panics during startup). HOWEVER, firefox seems to be badly broken. Attempting to open certain pages results in never-ending-hang, and nothing ever gets rendered. I can use the Stop-Reloading "X" button, and the "oscillating dot" load indicator stops oscillating, but nothing ever happens. At that point, the tab is hung and cannot load any other page, not even pages that loaded successfully previously! I _can_ delete the tab, and opening a new tab works. Some of the "failing" pages are: airnow.gov gmail.com www.prudential.com/login www.myaccountviewonline.com/AccountView/Logon Slight correction: above I said "nothing ever happens" but while I've been composing this Email a couple of the above pages seem to have made some progress (although none of them have finished and stopped the "oscillating dot"). So "ever" is at least 5 minutes or longer ... :) I don't know if the kern_event.c changes are responsible, but I haven't seen anything else recently. I reverted kern_event.c to rev 1.110 and firefox behaves correctly. So it's pretty fair bet that the subsequent kern_event.c changes are the reason for the breakage. PR kern/55946 has been filed. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/kern (kern_event.c)
On Thu, 21 Jan 2021, Paul Goyette wrote: Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. OK, I built and installed a new kernel+userland. Most everything works, and syslogd seems to work fine (at least, it no longer panics during startup). HOWEVER, firefox seems to be badly broken. Attempting to open certain pages results in never-ending-hang, and nothing ever gets rendered. I can use the Stop-Reloading "X" button, and the "oscillating dot" load indicator stops oscillating, but nothing ever happens. At that point, the tab is hung and cannot load any other page, not even pages that loaded successfully previously! I _can_ delete the tab, and opening a new tab works. Some of the "failing" pages are: airnow.gov gmail.com www.prudential.com/login www.myaccountviewonline.com/AccountView/Logon Slight correction: above I said "nothing ever happens" but while I've been composing this Email a couple of the above pages seem to have made some progress (although none of them have finished and stopped the "oscillating dot"). So "ever" is at least 5 minutes or longer ... :) I don't know if the kern_event.c changes are responsible, but I haven't seen anything else recently. FWIW, I'm running firefox 83.0 from pkgsrc, around 2020-12-08 On Thu, 21 Jan 2021, Paul Goyette wrote: This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at netbsd:vpanic+0x156 [ 28.0253983] snprintf() at netbsd:snprintf [ 28.0253983] kqueue_check() at netbsd:kqueue_check+0x183 [ 28.0253983] kevent1() at netbsd:kevent1+0x49f [ 28.0253983] sys___kevent50() at netbsd:sys___kevent50+0x33 [ 28.0253983] syscall() at netbsd:syscall+0x23e [ 28.0253983] --- syscall (number 435) --- [ 28.0253983] netbsd:syscall+0x23e: [ 28.0253983] cpu0: End traceback... [ 28.0253983] fatal breakpoint trap in supervisor mode [ 28.0253983] trap type 1 code 0 rip 0x8021f415 cs 0x8 rflags 0x202 cr2 0x78742459e000 ilevel 0x8 rsp 0xa809281ebb50 [ 28.0253983] curlwp 0xdc138aa46540 pid 1352.1352 lowest kstack 0xa809281e72c0 Stopped in pid 1352.1352 (syslogd) at netbsd:breakpoint+0x5: leave I have a full crash dump if you need any further info. Module Name:src Committed By: jdolecek Date: Thu Jan 21 18:09:23 UTC 2021 Modified Files: src/sys/kern: kern_event.c Log Message: adjust kq_check() (enabled with DEBUG) to new reality - it's now perfectly normal to have kq_count bigger than number of the linked entries on the kqueue PR kern/50094, problem pointed out by Chuck Silvers To generate a diff of this commit: cvs rdiff -u -r1.111 -r1.112 src/sys/kern/kern_event.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/dev/pci
On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote: > > +#ifndef _LP64 > > _LP64 is a terrible way to make this choice. > > heaps of our 32 bit platforms implement the _8 variants. Can't we then just make sure they have the 8 bit variant? and set a define if its atomic or not? This way drivers van use the _8 variant freely and for the few drivers that NEED the atomicity, they can check the define and deal with it the way they like. Reinoud
Re: CVS commit: src/sys/arch/evbarm/conf
I forgot that I added dma-ranges support back in Feb last year. All good, please ignore me :) On Thu, 21 Jan 2021, Jared McNeill wrote: This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I think before turning it on we should restrict it to the lower 1GB of memory like the Pi3 models where we know it at least has a chance of working. You can do this easily by creating a restrictive tag using bus_dmatag_subregion(9). Take care, Jared On Thu, 21 Jan 2021, Nia Alarie wrote: Module Name:src Committed By: nia Date: Thu Jan 21 17:46:28 UTC 2021 Modified Files: src/sys/arch/evbarm/conf: GENERIC64 Log Message: add vcaudio (intentionally this time) gives working audio output on rpi3 without needing to run a 32-bit image. To generate a diff of this commit: cvs rdiff -u -r1.173 -r1.174 src/sys/arch/evbarm/conf/GENERIC64 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/pci
On 22/01/2021 04:48, Christos Zoulas wrote:
+#if _QUAD_HIGHWORD
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
+#else
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value & 0x));
+#endif
+}
+#endif /* !_LP64 */
BUS_ADDR_{HI,LO}32 are also available for your convenience.
Nick
Re: CVS commit: src/sys/dev/pci
In article <27744.1611294...@splode.eterna.com.au>, matthew green wrote: >> +#ifndef _LP64 > >_LP64 is a terrible way to make this choice. > >heaps of our 32 bit platforms implement the _8 variants. Let's add a _HAVE_ variable then? christos
re: CVS commit: src/sys/dev/pci
> +#ifndef _LP64 _LP64 is a terrible way to make this choice. heaps of our 32 bit platforms implement the _8 variants. .mrg.
Re: CVS commit: src/sys/dev/pci
In article <20210121204833.9ebcff...@cvs.netbsd.org>,
Reinoud Zandijk wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: reinoud
>Date: Thu Jan 21 20:48:33 UTC 2021
>
>Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
>Log Message:
>Remove dependency on bus_space_write_8() for i386 and instead implement it as
>two bus_space_write_4()'s as allowed in the spec.
Isn't it better to do it this way so it always works (not just for little
endian)? We could even provide this in the MI bus.h if others need it
and don't care about the non-atomic transactions. I have not even compile
tested it.
christos
Index: virtio_pci.c
===
RCS file: /cvsroot/src/sys/dev/pci/virtio_pci.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 virtio_pci.c
--- virtio_pci.c21 Jan 2021 20:48:33 - 1.18
+++ virtio_pci.c22 Jan 2021 04:46:24 -
@@ -34,6 +34,7 @@ __KERNEL_RCSID(0, "$NetBSD: virtio_pci.c
#include
#include
#include
+#include
#include
#include
@@ -731,9 +732,20 @@ virtio_pci_read_queue_size_10(struct vir
* By definition little endian only in v1.0 and 8 byters are allowed to be
* written as two 4 byters
*/
-#define bus_space_write_le_8(iot, ioh, reg, val) \
- bus_space_write_4(iot, ioh, reg, ((uint64_t) (val)) & 0x); \
- bus_space_write_4(iot, ioh, reg + 4, ((uint64_t) (val)) >> 32);
+#ifndef _LP64
+static __inline void
+bus_space_write_8(bus_space_tag_t iot, bus_space_handle_t ioh,
+ bus_size_t offset, uint64_t value)
+{
+#if _QUAD_HIGHWORD
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
+#else
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value & 0x));
+#endif
+}
+#endif /* !_LP64 */
static void
virtio_pci_setup_queue_10(struct virtio_softc *sc, uint16_t idx, uint64_t addr)
@@ -747,15 +759,15 @@ virtio_pci_setup_queue_10(struct virtio_
bus_space_write_2(iot, ioh, VIRTIO_CONFIG1_QUEUE_SELECT, vq->vq_index);
if (addr == 0) {
bus_space_write_2(iot, ioh, VIRTIO_CONFIG1_QUEUE_ENABLE, 0);
- bus_space_write_le_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_DESC, 0);
- bus_space_write_le_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_AVAIL, 0);
- bus_space_write_le_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_USED, 0);
+ bus_space_write_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_DESC, 0);
+ bus_space_write_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_AVAIL, 0);
+ bus_space_write_8(iot, ioh, VIRTIO_CONFIG1_QUEUE_USED, 0);
} else {
- bus_space_write_le_8(iot, ioh,
+ bus_space_write_8(iot, ioh,
VIRTIO_CONFIG1_QUEUE_DESC, addr);
- bus_space_write_le_8(iot, ioh,
+ bus_space_write_8(iot, ioh,
VIRTIO_CONFIG1_QUEUE_AVAIL, addr + vq->vq_availoffset);
- bus_space_write_le_8(iot, ioh,
+ bus_space_write_8(iot, ioh,
VIRTIO_CONFIG1_QUEUE_USED, addr + vq->vq_usedoffset);
bus_space_write_2(iot, ioh,
VIRTIO_CONFIG1_QUEUE_ENABLE, 1);
@@ -771,7 +783,6 @@ virtio_pci_setup_queue_10(struct virtio_
VIRTIO_CONFIG1_QUEUE_MSIX_VECTOR, vec);
}
}
-#undef bus_space_write_le_8
static void
virtio_pci_set_status_10(struct virtio_softc *sc, int status)
Re: CVS commit: src/sys/kern (kern_event.c)
Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. On Thu, 21 Jan 2021, Paul Goyette wrote: This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at netbsd:vpanic+0x156 [ 28.0253983] snprintf() at netbsd:snprintf [ 28.0253983] kqueue_check() at netbsd:kqueue_check+0x183 [ 28.0253983] kevent1() at netbsd:kevent1+0x49f [ 28.0253983] sys___kevent50() at netbsd:sys___kevent50+0x33 [ 28.0253983] syscall() at netbsd:syscall+0x23e [ 28.0253983] --- syscall (number 435) --- [ 28.0253983] netbsd:syscall+0x23e: [ 28.0253983] cpu0: End traceback... [ 28.0253983] fatal breakpoint trap in supervisor mode [ 28.0253983] trap type 1 code 0 rip 0x8021f415 cs 0x8 rflags 0x202 cr2 0x78742459e000 ilevel 0x8 rsp 0xa809281ebb50 [ 28.0253983] curlwp 0xdc138aa46540 pid 1352.1352 lowest kstack 0xa809281e72c0 Stopped in pid 1352.1352 (syslogd) at netbsd:breakpoint+0x5: leave I have a full crash dump if you need any further info. Module Name:src Committed By: jdolecek Date: Thu Jan 21 18:09:23 UTC 2021 Modified Files: src/sys/kern: kern_event.c Log Message: adjust kq_check() (enabled with DEBUG) to new reality - it's now perfectly normal to have kq_count bigger than number of the linked entries on the kqueue PR kern/50094, problem pointed out by Chuck Silvers To generate a diff of this commit: cvs rdiff -u -r1.111 -r1.112 src/sys/kern/kern_event.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/kern (kern_event.c)
This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at netbsd:vpanic+0x156 [ 28.0253983] snprintf() at netbsd:snprintf [ 28.0253983] kqueue_check() at netbsd:kqueue_check+0x183 [ 28.0253983] kevent1() at netbsd:kevent1+0x49f [ 28.0253983] sys___kevent50() at netbsd:sys___kevent50+0x33 [ 28.0253983] syscall() at netbsd:syscall+0x23e [ 28.0253983] --- syscall (number 435) --- [ 28.0253983] netbsd:syscall+0x23e: [ 28.0253983] cpu0: End traceback... [ 28.0253983] fatal breakpoint trap in supervisor mode [ 28.0253983] trap type 1 code 0 rip 0x8021f415 cs 0x8 rflags 0x202 cr2 0x78742459e000 ilevel 0x8 rsp 0xa809281ebb50 [ 28.0253983] curlwp 0xdc138aa46540 pid 1352.1352 lowest kstack 0xa809281e72c0 Stopped in pid 1352.1352 (syslogd) at netbsd:breakpoint+0x5: leave I have a full crash dump if you need any further info. Module Name:src Committed By: jdolecek Date: Thu Jan 21 18:09:23 UTC 2021 Modified Files: src/sys/kern: kern_event.c Log Message: adjust kq_check() (enabled with DEBUG) to new reality - it's now perfectly normal to have kq_count bigger than number of the linked entries on the kqueue PR kern/50094, problem pointed out by Chuck Silvers To generate a diff of this commit: cvs rdiff -u -r1.111 -r1.112 src/sys/kern/kern_event.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/arch/evbarm/conf
This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I think before turning it on we should restrict it to the lower 1GB of memory like the Pi3 models where we know it at least has a chance of working. You can do this easily by creating a restrictive tag using bus_dmatag_subregion(9). Take care, Jared On Thu, 21 Jan 2021, Nia Alarie wrote: Module Name:src Committed By: nia Date: Thu Jan 21 17:46:28 UTC 2021 Modified Files: src/sys/arch/evbarm/conf: GENERIC64 Log Message: add vcaudio (intentionally this time) gives working audio output on rpi3 without needing to run a 32-bit image. To generate a diff of this commit: cvs rdiff -u -r1.173 -r1.174 src/sys/arch/evbarm/conf/GENERIC64 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/kern
I believe it's this change that's made my vbox image panic at the drop of
a hat; while it occasionally panics before it even hits single user, it
also consistently panics when starting syslogd (even from single-user):
panic: kqueue_scan,1491: kq=0xc779aeff6dc0 kq->kq_count(1) != count(0),
nmarker=1
and the call chain is syscall -> sys___kevent50 -> kevent1 -> kqueue_check
it also causes a panic while trying to dump more than half the time,
but I have managed to get an image or two. ("panic: atastart: channel 0
busy, xfer not possible", if you're curious.)
On Wed, Jan 20, 2021 at 09:39:09PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jan 20 21:39:09 UTC 2021
>
> Modified Files:
> src/sys/kern: kern_event.c
>
> Log Message:
> fix a race in kqueue_scan() - when multiple threads check the same
> kqueue, it could happen other thread seen empty kqueue while kevent
> was being checked for re-firing and re-queued
>
> make sure to keep retrying if there are outstanding kevents even
> if no kevent is found on first pass through the queue, and only
> drop the KN_QUEUED flag and kq_count when actually completely done
> with the kevent
>
> change is inspired by the FreeBSD in-flux handling, but without
> introducing the reference counting
>
> PR kern/50094 by Christof Meerwald
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.110 -r1.111 src/sys/kern/kern_event.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
Re: CVS commit: src/sys/dev
> On Jan 21, 2021, at 12:00 AM, Martin Husemann > wrote: > > 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 functioning though not a >> regression. > > While not a regression by this commit, it *did* work in netbsd-8, > so overall a bad regression that we should fix. This could be a bug in Qemu … it does not work on Alpha, either, and Jonathan Kollasch tracked down to Qemu 5’s Virtio subsystem not considering the DMA window on the Alpha platform. -- thorpej
Re: CVS commit: src/sys/dev
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 functioning though not a > regression. While not a regression by this commit, it *did* work in netbsd-8, so overall a bad regression that we should fix. Martin
re: CVS commit: src/sys/arch
"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 XEN3PAE_DOM0 XEN3PAE_DOMU > src/sys/arch/landisk/conf: GENERIC > src/sys/arch/usermode/conf: GENERIC.common > src/sys/arch/zaurus/conf: GENERIC > > Log Message: > remove compat_ossaudio from kernel modules > > this is only useful with compat_linux and gets autoloaded when > compat_linux is loaded, so there's no reason to bake it into kernels > any more. not everyone uses COMPAT_LINUX as a module. this seems reasonable to have as a comment anywhere COMAPT_LINUX is commented. at least the GENERIC*s should have it, IMO. additionally, there are a few issues remaining. eg, the evbarm/conf/POGO kernel now has a useless "no options" for COMPAT_OSSAUDIO, and there are at least a handful of commented versions remaining. .mrg.
Re: CVS commit: src/sys/arch/arm/sunxi
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: > > src/sys/arch/arm/sunxi: sunxi_sramc.c > > > > Log Message: > > Use device_compatible_entry / of_search_compatible() rather than matching > > against multiple sets of compatibility strings. > > > > > > To generate a diff of this commit: > > cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/sunxi/sunxi_sramc.c > > This breaks cubietruck (fdt is: sun7i-a20-cubietruck.dtb): And it was fixed with $NetBSD: sunxi_sramc.c,v 1.7 2021/01/20 00:48:49 jmcneill Exp $ Martin
Re: CVS commit: src/sys/arch/arm/sunxi
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() rather than matching
> against multiple sets of compatibility strings.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/sunxi/sunxi_sramc.c
This breaks cubietruck (fdt is: sun7i-a20-cubietruck.dtb):
[ 1.000] fclock0 at simplebus2: 2500 Hz fixed clock (mii_phy_tx)
[ 1.000] fclock1 at simplebus2: 12500 Hz fixed clock (gmac_int_tx)
[ 1.000] fclock2 at simplebus2: 2400 Hz fixed clock (osc24M)
[ 1.000] fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
[ 1.000] gtmr0 at simplebus0: Generic Timer
[ 1.000] gtmr0: interrupting on GIC irq 27
[ 1.000] armgtmr0 at gtmr0: Generic Timer (24000 kHz, virtual)
[ 1.030] sun4ia10ccu0 at simplebus1: A20 CCU
[ 1.030] sunxinmi0 at simplebus1: NMI
[ 1.030] sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux
[ 1.030] sunxigpio0 at simplebus1: PIO
[ 1.030] gpio0 at sunxigpio0: 175 pins
[ 1.030] sunxigpio0: interrupting on GIC irq 60
[ 1.030] sun4idma0 at simplebus1: DMA controller
[ 1.030] sun4idma0: interrupting on GIC irq 59
[ 1.030] sunxisramc0 at simplebus1: SRAM Controller
[ 1.030] uvm_fault(0x80b92d68, 0, 1) -> e
[ 1.030] Fatal kernel mode data abort: 'Translation Fault (S)'
[ 1.030] trapframe: 0x80bc8cf0
[ 1.030] FSR=0005, FAR=, spsr=6353
[ 1.030] r0 =92cfd200, r1 =806b0910, r2 =, r3 =
[ 1.030] r4 =92a0cd00, r5 =10c4, r6 =92cfd200, r7 =0dd0
[ 1.030] r8 =806b0910, r9 =114c, r10=80634a80, r11=80bc8d94
[ 1.030] r12=92cf3988, ssp=80bc8d40, slr=804bc688, pc =80061fac
Stopped in pid 0.0 (system) at netbsd:sunxi_sramc_attach+0x16c:ldr
r2, [r2]
(gdb) list *(sunxi_sramc_attach+0x16c)
0x80061fac is in sunxi_sramc_attach
(../../../../arch/arm/sunxi/sunxi_sramc.c:135).
130 if (dce != NULL) {
131 node = kmem_alloc(sizeof(*node), KM_SLEEP);
132 node->phandle = child;
133 node->area = dce->data;
134 TAILQ_INSERT_TAIL(>sc_nodes, node, nodes);
135 aprint_verbose_dev(sc->sc_dev, "area: %s\n",
136 node->area->desc);
137 }
138 }
139 }
With the change backed out it boots fine (dmesg below).
Martin
--8<--
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019, 2020, 2021 The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 9.99.78 (GENERIC) #117: Tue Jan 19 19:14:10 CET 2021
mar...@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/compile/GENERIC
total memory = 2045 MB
avail memory = 1989 MB
entropy: no seed from bootloader
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
armfdt0 (root)
simplebus0 at armfdt0: Cubietech Cubietruck
simplebus1 at simplebus0
cpus0 at simplebus0
simplebus2 at simplebus0
simplebus3 at simplebus0
cpu0 at cpus0: Cortex-A7 r0p4 (Cortex V7A core)
cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 256KB/64B 8-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpufreqdt0 at cpu0
cpu1 at cpus0
cpufreqdt1 at cpu1
gic0 at simplebus1: GIC
armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid)
armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
fclock0 at simplebus2: 2500 Hz fixed clock (mii_phy_tx)
fclock1 at simplebus2: 12500 Hz fixed clock (gmac_int_tx)
fclock2 at simplebus2: 2400 Hz fixed clock (osc24M)
fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
gtmr0 at simplebus0: Generic Timer
gtmr0: interrupting on GIC irq 27
armgtmr0 at gtmr0: Generic Timer (24000 kHz, virtual)
timecounter: Timecounter "armgtmr0" frequency 2400 Hz quality 500
sun4ia10ccu0 at simplebus1: A20 CCU
sunxinmi0 at simplebus1: NMI
sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux
sunxigpio0 at simplebus1: PIO
gpio0 at sunxigpio0: 175 pins
sunxigpio0: interrupting on GIC irq 60
sun4idma0 at simplebus1: DMA controller
sun4idma0: interrupting on GIC irq 59
sunxisramc0 at simplebus1: SRAM Controller
sunxisramc0: area: SRAM A3/A4
sunxisramc0: area: SRAM D
sunxidebe0 at simplebus1: Display Engine Backend (display-backend@1e6)
re: CVS commit: src/sys/arch/aarch64/aarch64
> 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.
Re: CVS commit: src/sys/arch/powerpc/ibm4xx
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 interrupt context.
1.31 --> 1.30
Sorry for bothering you many times...
rin
Re: CVS commit: src/sys/arch/powerpc/ibm4xx
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 used instead of entropy_enter_intr() in
statclock(), which results in KASSERT() failure.
To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/powerpc/ibm4xx/clock.c
This message is somewhat misleading. I meant:
(1) Callers are interrupt handlers, therefore, {hard,stat}clock() are
apparently invoked in the interrupt context.
(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 interrupt context.
I have to improve my English writing skills ;-).
Thanks,
rin
Re: CVS commit: src/sys/compat/netbsd32
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 have the same API, warts and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. No, it's currently unique to NetBSD. Other BSD's just don't have the infrastructure in their network for it either. I'll note that on a 64-bit platform it's 64 bits though so these do gains something. The value is similar to struct if_data counters really, so maybe it should be a uint64_t if you really want to change it. I would then argue that it might be better then to version it proper and move it out of compat32. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. I would just like arp to work without error. My personal preference would be to keep the same API and add compat. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Looks great! Also looks the same as what I did but couldn't get to work. Maybe I missed the netbsd32 on the long. Roy
Re: CVS commit: src/sys/dev/wscons
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: wsdisplay_vconsvar.h Log Message: Add appropriate memory barriers around sc_busy accesses. Fixes an issue where character cells are sometimes not erased properly on aarch64 at boot. To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29 src/sys/dev/wscons/wsdisplay_vconsvar.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/compat/netbsd32
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 same API, warts > >> and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. > > [ .. ] > >> > >> That breaks API/ABI though yes? As such it would require stuff in compat > >> anyway, but leaving it as it just needs n32 compat gunk instead which is > >> less impactful on other systems. > > > > in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can > > choose to break them in -current. there's a slight problem that -current > > has > > a minor flag day here, but it's not the compat issue you seem to think. > > CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5 Sorry, I only checked the history of in_nbrinfo and just assumed that in6_nbrinfo was of a similar vintage. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Cheers, Simon.
re: CVS commit: src/share/man/man5
> 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.
re: CVS commit: src/sys/dev/acpi
"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 attach to "isa". cool. now try to remove all the "at isa" devices in your config :-) (it explodes last i tried.)
Re: CVS commit: src/share/man/man5
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 set properly - see rc.conf(5). What Taylor said. The above warning reflects the status of checkyesnox() that checks that the value is yes/true/1 or no/false/0. -uwe
Re: CVS commit: src/share/man/man5
> 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 not set properly - see rc.conf(5). The allowed settings are: entropy=check entropy=wait entropy="" Note that `entropy' is not an `rcvar' the way upsdriver is (if your /etc/rc.d/upsdriver is pkgsrc/sysutils/ups-nut/files/upsdriver.sh). Compare, e.g., `domainname' or `hostname' in rc.conf(5).
re: CVS commit: src/share/man/man5
> 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.
Re: CVS commit: src/sys/compat/netbsd32
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 non recoverable :( If it is recoverable somehow I can put NetBSD back on it as I have a shiny new USG in it's place. Roy
Re: CVS commit: src/sys/compat/netbsd32
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. [ .. ] That breaks API/ABI though yes? As such it would require stuff in compat anyway, but leaving it as it just needs n32 compat gunk instead which is less impactful on other systems. in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can choose to break them in -current. there's a slight problem that -current has a minor flag day here, but it's not the compat issue you seem to think. CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5 Roy
re: CVS commit: src/sys/compat/netbsd32
> 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 API/ABI though yes? > As such it would require stuff in compat anyway, but leaving it as it just > needs > n32 compat gunk instead which is less impactful on other systems. in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can choose to break them in -current. there's a slight problem that -current has a minor flag day here, but it's not the compat issue you seem to think. with simon's proposed patch, the API doesn't change, so there no source compat issue to worry about either. this _only_ breaks -current in the last 4 months or so. i think we should do this, rather than add additional compat. we're allowed (and should!) fix -current issues like this. .mrg.
Re: CVS commit: src/sys/compat/netbsd32
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. I can assume you have working IPv4 ;) In general where we can define the structure that are passed in an interface, regardless if it's a ioctl or sysctl or whatever, we should try to design the structure so that it's the same regardless of if it's built with 32-bit or 64-bit userlands. 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. The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in the structure, so this has different sizes depending on your native long size. I _think_ this is the is value out of the la_asked member of struct llentry which is a uint16_t so we can just make it an int the your structures will align nicely. In both cases the ifname name is 16 bytes. For in_nbrinfo in_addr is effectively an int so we have just four ints after the ifname. For in6_nbrinfo the in6_addr is 128 bytes so aligns nicely, then a couple more ints after that. If "asked" is from struct llentry then the attached patch should work without requiring any compat32 support. If you're happy with this, I'll test a bit more then commit. That breaks API/ABI though yes? As such it would require stuff in compat anyway, but leaving it as it just needs n32 compat gunk instead which is less impactful on other systems. Roy
Re: CVS commit: src/sys/compat/netbsd32
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 IPv4 ;)
In general where we can define the structure that are passed in an
interface, regardless if it's a ioctl or sysctl or whatever, we should
try to design the structure so that it's the same regardless of if it's
built with 32-bit or 64-bit userlands. This is hard where you have
pointers, both otherwise is usually possible with a bit of planning.
You especially need to watch out for long which is a different size on
32-bit/64-bit userlands and also for int64_t which can align differently
depending on the architecture. If you can do a printf of the struct
size with a variety of arches and they're all the same then good! amd64,
i386, mips64 (n32), sparc would probably cover the range of cases to
test on (a compile test will do if you look at the generated code for
what is passed to printf). The general rule is if we can avoid touching
compat/netbsd32 then life is easier!
The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in
the structure, so this has different sizes depending on your native long
size.
I _think_ this is the is value out of the la_asked member of struct
llentry which is a uint16_t so we can just make it an int the your
structures will align nicely. In both cases the ifname name is 16
bytes. For in_nbrinfo in_addr is effectively an int so we have just
four ints after the ifname. For in6_nbrinfo the in6_addr is 128 bytes
so aligns nicely, then a couple more ints after that.
If "asked" is from struct llentry then the attached patch should work
without requiring any compat32 support. If you're happy with this, I'll
test a bit more then commit.
Cheers,
Simon.
Index: netinet/in_var.h
===
RCS file: /cvsroot/src/sys/netinet/in_var.h,v
retrieving revision 1.98
diff -d -p -u -r1.98 in_var.h
--- netinet/in_var.h11 Sep 2020 15:22:12 - 1.98
+++ netinet/in_var.h15 Jan 2021 02:18:01 -
@@ -118,7 +118,7 @@ struct in_ifaddr {
struct in_nbrinfo {
char ifname[IFNAMSIZ]; /* if name, e.g. "en0" */
struct in_addr addr;/* IPv4 address of the neighbor */
- longasked; /* number of queries already sent for this addr
*/
+ int asked; /* number of queries already sent for this addr
*/
int state; /* reachability state */
int expire; /* lifetime for NDP state transition */
};
Index: netinet6/nd6.h
===
RCS file: /cvsroot/src/sys/netinet6/nd6.h,v
retrieving revision 1.91
diff -d -p -u -r1.91 nd6.h
--- netinet6/nd6.h 11 Sep 2020 15:03:33 - 1.91
+++ netinet6/nd6.h 15 Jan 2021 02:18:01 -
@@ -83,7 +83,7 @@ struct nd_kifinfo {
struct in6_nbrinfo {
char ifname[IFNAMSIZ]; /* if name, e.g. "en0" */
struct in6_addr addr; /* IPv6 address of the neighbor */
- longasked; /* number of queries already sent for this addr
*/
+ int asked; /* number of queries already sent for this addr
*/
int isrouter; /* if it acts as a router */
int state; /* reachability state */
int expire; /* lifetime for NDP state transition */
Re: CVS commit: src/sys/compat/netbsd32
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
Re: CVS commit: src/distrib/sets/lists/debug
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 KERNEL_DIR. When both KERNEL_DIR and MKDEBUG are defined, we create an empty $DESTDIR/usr/libdata/debug/netbsd/ directory. Should fix ``build.sh release'' issue reported in kern/55923 XXX Since nothing ever seems to populate this directory, perhaps we should XXX simply prevent its creation? If we do create it, should its creation XXX perhaps be conditioned on MKKDEBUG rather than MKDEBUG? XXX There is still another problem with ``build.sh install-image'' but I XXX open a new PR for that. On Thu, 14 Jan 2021, Paul Goyette wrote: ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/sys/compat/netbsd32
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: > > Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now. > > XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled. > > Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 > (ndp -a) please? > > I could never get that working. Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). Cheers, Simon.
Re: CVS commit: src/sys/compat/netbsd32
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 compat32 now. XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled. Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 (ndp -a) please? I could never get that working. Thanks Roy
Re: CVS commit: src/usr.bin/xlint/lint1
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 all lint objdirs completely). Please add an entry to src/UPDATING, I would suggest something like: find $OBJDIR -type d -name \*lint\* | xargs rm -rf Thanks for the suggestion, I first did that. I was unsatisfied though that people would actively have to read src/UPDATING. Therefore, after reproducing the problem locally, I renamed ops.c to oper.c, after which the build ran successfully. Roland
Re: CVS commit: src/usr.bin/xlint/lint1
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 entry to src/UPDATING, I would suggest something like: find $OBJDIR -type d -name \*lint\* | xargs rm -rf Martin
Re: CVS commit: src/usr.bin/xlint/lint1
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 for several reasons: 1. The word STRUCT_ASSIGN no longer appears in the whole source tree, as I removed the macro. 2. The compiler should have already caught this "implicit function declaration" with -Werror and never let the linker see this. I guess a simple "make clean && make" will clear up the situation. Roland
Re: CVS commit: src/usr.bin/xlint/lint1
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
-I/home/jmcneill/netbsd/cvs-src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1 -I.
-DPASS=\"lint1.h\"
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../arch/aarch64
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../common
-o lint1 cgram.lo decl.lo emit.lo emit1.lo err.lo func.lo init.lo
inittyp.lo main1.lo mem.lo mem1.lo ops.lo print.lo scan.lo tree.lo
tyname.lo
-L/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/lib
-lnbcompat -lrt -lz -lm
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
collect2: error: ld returned 1 exit status
*** [lint1] Error code 1
nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
1 error
nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
nbmake[2]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
*** Failed target: dependall-lint1
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/home/jmcneill/netbsd/cvs-src/tools" ;; *) this="${dir}/";
real="/home/jmcneill/netbsd/cvs-src/tools/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" &&
/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget lint1 dependall
*** Error code 2
Stop.
nbmake[1]: stopped in /home/jmcneill/netbsd/cvs-src/tools
*** [build_install] Error code 1
nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
1 error
nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
ERROR: Failed to make build_install in "tools"
*** BUILD ABORTED ***
On Tue, 5 Jan 2021, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Jan 5 23:50:29 UTC 2021
Modified Files:
src/usr.bin/xlint/lint1: Makefile op.h ops.def
Added Files:
src/usr.bin/xlint/lint1: ops.c
Removed Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h mkops
Log Message:
lint: clean up generation of the operator tables
Instead of running a shell program that runs an AWK program that
generates the two files ops.c and ops.h, just define the operator tables
once in ops.def and use these definitions flexibly in ops.c and op.h.
To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.56 src/usr.bin/xlint/lint1/Makefile
cvs rdiff -u -r1.3 -r0 src/usr.bin/xlint/lint1/Makefile.ops-c \
src/usr.bin/xlint/lint1/Makefile.ops-h
cvs rdiff -u -r1.13 -r0 src/usr.bin/xlint/lint1/mkops
cvs rdiff -u -r1.9 -r1.10 src/usr.bin/xlint/lint1/op.h
cvs rdiff -u -r0 -r1.1 src/usr.bin/xlint/lint1/ops.c
cvs rdiff -u -r1.6 -r1.7 src/usr.bin/xlint/lint1/ops.def
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 01/03/21 12:03, Roy Marples wrote:
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 break that logic.
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
should be completely
Valid points.
New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0); /* also notifies routing
message listener *
So this should be good now.
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58
2021 +
@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;
- if (val >= 0)
+ if (val >= 0) {
interface_interval = val;
- else {
+ if (interface_interval == 0)
+ disable_dynamic_updates = 1;
+ } else {
fprintf(stderr,
"command line interface update
interval %ld must not be negative\n",
val);
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 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sun Jan 03 10:56:58
2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58
2021 +
@@ -423,9 +423,11 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (!disable_dynamic_updates &&
+ interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 should be completely disabled. Could you expand on this please? It sounds like you want it to be user disabled but not for routing messages? I don't understand. Roy
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 break that logic.
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 should be
completely
Valid points.
New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0); /* also notifies routing message
listener *
So this should be good now.
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58 2021 +
@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;
- if (val >= 0)
+ if (val >= 0) {
interface_interval = val;
- else {
+ if (interface_interval == 0)
+ disable_dynamic_updates = 1;
+ } else {
fprintf(stderr,
"command line interface update interval %ld
must not be negative\n",
val);
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 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sun Jan 03 10:56:58 2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58 2021 +
@@ -423,9 +423,11 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (!disable_dynamic_updates &&
+ interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 seconds between scans for new or dropped
inter‐
faces. This option takes an integer number as its
argument.
Give the time in seconds between two scans for new or
dropped
interfaces. For systems with routing socket support the
scans will be performed shortly after the interface change
has been detected by the system. Use 0 to disable
scanning.
60 seconds is the minimum time between scans.
...
This patch seems (by visual inspection) to break that logic.
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 should
be completely
disabled.
Best regards,
Frank
On 01/02/21 19:41, Roy Marples wrote:
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 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 18:39:34
2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34
2021 +
@@ -423,9 +423,10 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 18:39:34 2021 +
@@ -455,8 +455,13 @@
{
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+ /* route(4) overflow can be observed */
+ interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif
#ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34 2021 +
@@ -423,9 +423,10 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 upstream says.
Also the ntp_io system will periodically refresh it interface lists in time as
it was explicitly designed to be robust against lost messages from the routing
socket.
That's a good point, with this we can now remove that forced sync on a timer
approach.
Does this look ok?
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 17:19:28 2021 +
@@ -423,9 +423,18 @@
/*
* Interface update timer
*/
- if (interface_interval && interface_timer <= current_time) {
- timer_interfacetimeout(current_time +
- interface_interval);
+ if (interface_timer && interface_timer <= current_time) {
+#ifdef SO_RERROR
+ /*
+* Because we can catch route(4) overflow, there is no
+* need to update interfaces every interface_interval.
+*/
+ interface_timer = 0;
+#else
+ if (interface_interval)
+ timer_interfacetimeout(current_time +
+ interface_interval);
+#endif
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}
We should try to keep the differences to the up-stream code as little as
possible. Especially when the upstream code already handles the situation
reasonably the is no need for additional code.
Agreed.
I already submitted the diff upstream, but will adjust it to remove the forced
refresh.
Happy new year!
And the same to you!
Roy
Re: CVS commit: src/external/bsd/ntp/dist/ntpd
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 multiple calls. Ignoring ENOBUFS was ok here due to the automatic periodic interface updates. calling timer_interfacetimeout(current_time + UPDATE_GRACE) is also possible if you expect a single ENOBUFS within UPDATE_GRACE seconds. But there is no need o special case flushing the routing socket here. There is no functional improvement except for save a few cycles in the overflow case. Also the ntp_io system will periodically refresh it interface lists in time as it was explicitly designed to be robust against lost messages from the routing socket. We should try to keep the differences to the up-stream code as little as possible. Especially when the upstream code already handles the situation reasonably the is no need for additional code. Happy new year! Frank On 01/01/21 18:21, Roy Marples wrote: cvs rdiff -u -r1.27 -r1.28 src/external/bsd/ntp/dist/ntpd/ntp_io.c
Re: CVS commit: src
>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! -- ryo shimizu
Re: CVS commit: src/distrib/sets/lists/games
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: src/distrib/sets/lists/games: mi Log Message: Add testpat(6) to the games set. To generate a diff of this commit: cvs rdiff -u -r1.59 -r1.60 src/distrib/sets/lists/games/mi Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5fefe793123761591715016! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/external/bsd/unbound/lib/libunbound
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 or winsock_event. That changes the ABI of the library (libunbound) and so at the very least would require a major version bump. It also breaks the build. Please revert, and also (and this applies to *everyone*) please do release builds BEFORE committing changes which can (even remotely possibly) affect the rest of the build (which more or less means any change other than to doc - and even there if any doc is new or deleted). kre
Re: CVS commit: src
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 Modified Files: src/distrib/sets/lists/dtb: ad.aarch64 ad.aarch64eb src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic: Makefile Added Files: src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic: meson-g12b-odroid-n2-plus.dts Log Message: add dts for odroid-N2 plus. meson-g12b-odroid-n2-plus.dts of linux is not optimized for the odroid-N2plus CPU clock. and the dts for odroid-n2-plus in the hardkernel repository is significantly changed, so cannot be imported without modification. Therefore, a simple meson-g12b-odroid-n2-plus.dts has been added based on "meson-g12b-odroid-n2.dts" with only the cpu_opp_table and regulator table changed. To generate a diff of this commit: cvs rdiff -u -r1.3 -r1.4 src/distrib/sets/lists/dtb/ad.aarch64 cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/dtb/ad.aarch64eb cvs rdiff -u -r1.1.1.7 -r1.2 \ src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/Makefile cvs rdiff -u -r0 -r1.1 \ src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2-plus.dts Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/arm/rockchip
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 UTC 2021 Modified Files: src/sys/arch/arm/rockchip: rk_i2s.c Log Message: rk_i2s.c To generate a diff of this commit: cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/rockchip/rk_i2s.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
re: CVS commit: src/usr.bin/make
"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):
cc -o nbmake *.o
assertion "*line_end == '\n'" failed: file "/usr/src/usr.bin/make/parse.c",
line 2844, function "ParseGetLine"
[1] Abort trap (core dumped) "${make}" -m ${TOP}/share/mk -s -B -f- _x_ <<...
ERROR: bomb_getmakevar MAKECONF: /tmp/nbbuild14989/nbmake failed
please fix :-)
.mrg.
Re: CVS commit: src/usr.bin/make
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 printf calls > >This is needed to compile bmake with GCC 2.8.1 on SunOS 5.9. > >To support ancient systems like this, the whole code of usr.bin/make is >supposed to use only ISO C90 features, except for filemon, which is not >used on these systems. Please revert! This breaks everyone else. %zu is the format to print size_t. Last I checked SunOS 5.9 has been dead since 2014 and whoever is still using it might as well install a new compiler, or tie the box at the end of a long chain so it can find its true calling. If you really want to support it instead define MAKE_FMT_SIZE_T and conditionalize it properly for "ancient OS", windows, cygwin, mingwin, and regular folks (this does not even handle "ancient os"): https://github.com/file/file/blob/master/src/file.h#L55 I am still against it though... christos
Re: CVS commit: src/external/gpl2/diffutils/dist/src
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 speaking, this needs a cast to work properly. It really needs to be a pointer and NULL isn't necessarily one. Joerg
Re: CVS commit: src/sys/dev/pci/ixgbe
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 say: 82598: All of bit 31(OTHER bit) of EIxx are reserved. In reality, at least EIMS_OTHER and EIMC_OTHER exist and the OTHER interrupt doesn't work without EIMS_OTHER. Other than 82598: + EICR's bit 31 is defined and other EIXX's bit 31 are reserved. + In reality, EIMS_OTHER is read only and EIMC_OTHER doesn't exist. If one of bit 29..16 is set, EIMS_OTHER is set to 1 (Note that bit 30(TCP timer isn't included)). Even if write bit 31 of EIMC to 1, it's ignored (EIMS_OTHER doesn't set). We introduced new spin mutex in ixgbe.c rev. 1.260, so it's OK to remove EIMC_OTHER stuff. We already set EIMS_OTHER in if_init(), so keep it for 82598. No functional change other than 82598. Another solution is to control bit 30..16 directly to mask/unmask interrupt instead of the mutex. TODO: Some MSI-X interrupt(LSC, module insertion/removal etc.)'s mask/unmask code between ixgbe_msix_admin() and ixgbe_handle_admin() may be wrong. It'll be fixed later. To generate a diff of this commit: cvs rdiff -u -r1.261 -r1.262 src/sys/dev/pci/ixgbe/ixgbe.c cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe_type.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/external/gpl3/gdb/dist/gdb
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 PT_STEP to userland for arm? > Yes, please remove it from headers for arm. This was a hack for DTrace as far as I recall, to expose PT_STEP that way and get DTrace building. Then, please restore nbsd-nat.c to the previous state. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/netinet
> 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: >> src/sys/netinet: files.ipfilter >> >> Log Message: >> Build ip_sync.c with -Wno-error to avoid failing due to excessive stack >> usage. > > Can you please make this more specific? Like -Wno-error=foo? Feel free to try. -Wno-error=stack-usage produced an error for me. -- thorpej
Re: CVS commit: src/sys/netinet
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 failing due to excessive stack >usage. Can you please make this more specific? Like -Wno-error=foo? christos
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
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, since > the vnodes were opened for writing. Fix proposed on current-users > and improved by hannken@. > > > To generate a diff of this commit: > cvs rdiff -u -r1.18 -r1.19 \ > src/external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. Oops, that should have been "proposed on tech-kern": http://mail-index.netbsd.org/tech-kern/2020/11/28/msg026984.html -- Kind regards, Yorick Hardy
Re: CVS commit: src/sys/arch/arm/arm32
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 wrote: Module Name:src Committed By: skrll Date: Sat Nov 21 19:44:52 UTC 2020 Modified Files: src/sys/arch/arm/arm32: cpuswitch.S Log Message: Ensure that r5 contains curlwp before DO_AST_AND_RESTORE_ALIGNMENT_FAULTS in lwp_trampoline as required by the move to make ASTs operate per-LWP rather than per-CPU. Thanks to martin@ for bisecting the amap corruption he was seeing and testing this fix. To generate a diff of this commit: cvs rdiff -u -r1.103 -r1.104 src/sys/arch/arm/arm32/cpuswitch.S Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys
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 > src/sys/sys: param.h > > Log Message: > Set a better default for MAXFILES on larger RAM machines if not > otherwise specified the kernel config file. Arbitary numbers are > 20,000 files for 16GB RAM or more and 10,000 files for 1GB RAM or > more. > > TODO: Adjust this and other values totally dynamically. > > > To generate a diff of this commit: > cvs rdiff -u -r1.68 -r1.69 src/sys/conf/param.c > cvs rdiff -u -r1.532 -r1.533 src/sys/kern/init_main.c > cvs rdiff -u -r1.678 -r1.679 src/sys/sys/param.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src
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 > src/external/public-domain/sqlite: Makefile.inc > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support So the core issue here is that it actually does two separate things. It does not only enable threadsafety (which is good), but also enables the worker thread support (which is bad). There is little reason for wanting the latter in a general build, at least the way it is implemented right now. Just doing the former is a lot less intrusive... Joerg diff -r 2bb2635be785 external/public-domain/sqlite/Makefile.inc --- a/external/public-domain/sqlite/Makefile.incThu Nov 12 23:24:18 2020 +0100 +++ b/external/public-domain/sqlite/Makefile.incThu Nov 12 23:28:36 2020 +0100 @@ -15,6 +15,7 @@ -DHAVE_STRERROR_R=1 \ -DHAVE_USLEEP=1 \ -DHAVE_SYS_ENDIAN_H=1 \ + -DSQLITE_THREADSAFE \ -DSQLITE_MAX_WORKER_THREADS=0 \ -DSQLITE_ENABLE_COLUMN_METADATA \ -DSQLITE_ENABLE_FTS3_PARENTHESIS \
Re: CVS commit: src
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 others before making somewhat big changes. No one is perfect... Thanks, rin
Re: CVS commit: src
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 /pkg/2020Q2/bin/svn | grep sqlite > -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0 > -lsqlite3.1 => /usr/lib/libsqlite3.so.1 > > This is also why the change to base sqlite3 affected, e.g., su(1). How about making sqlite3 just a private lib statically linked into whatever part of heimdahl actually needs it, and not exposing any symbols from it? Martin
Re: CVS commit: src
> 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 wouldn't be > > necessary. > > Why do we even have sqlite in the base system in the first place? apropos(1); a handful of other things also use it (heimdal, postfix). I suggested that we leave the bells & whistles out of base sqlite3, maybe even stop installing the .so symlink, and teach pkgsrc to just use pkgsrc sqlite3 (with all bells & whistles included) rather than base sqlite3 -- after all, sqlite3 is meant to be embedded and has lots of optional bells & whistles that apropos(1) has no need of, so it is silly to impose those costs on apropos(1) or make sqlite3 part of the NetBSD API. 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 /pkg/2020Q2/bin/svn | grep sqlite -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0 -lsqlite3.1 => /usr/lib/libsqlite3.so.1 This is also why the change to base sqlite3 affected, e.g., su(1). I have no idea what heimdal does with sqlite3, but it puts us in a pretty pickle: we can't reliably use pkgsrc sqlite3 on existing NetBSD installs for packages that use gssapi, and we can't rely on sqlite3 in existing NetBSD installs for packages that need newer/threaded/jsonned sqlite3 as we often encounter.
Re: CVS commit: src
> 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 in the first place? -- thorpej
Re: CVS commit: src
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 software on NetBSD sucks less. If fewer third-party libraries were exposed by the base system this wouldn't be necessary.
Re: CVS commit: src
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++.
Re: CVS commit: src
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, | addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514 | ... The fault address is anon memory w/o exec permission when su exits: | # pmap -p xxx | ... | FC2961BB1000 4K read/write /altroot/lib/libgcc_s.so.1.0 | FC2961BB6000 40K read/write [ anon ] | FC2961BE6000 40K read/write [ anon ] | ... Oops, correction: the fault address is not mapped when su exits; FC2961BB6000 + 40K = FC2961BC. The discussion thereafter does not change. Thanks, rin
Re: CVS commit: src
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: Makefile.inc src/external/public-domain/sqlite: Makefile.inc src/external/public-domain/sqlite/bin: Makefile src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in src/usr.sbin/makemandb: Makefile Log Message: sqlite: do not build without multithreading support at least a few pkgsrc packages avoid base sqlite because it fails this check, and it's probably a surprising performance penalty for unsuspecting users Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just have pkgsrc always use pkgsrc sqlite3, and change base to go back to the smaller non-threaded sqlite3 with only the options the things in base actually need? Also: What is the performance penalty? The sqlite3 documentation (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ SQLITE_THREADSAFE has a performance penalty, not the other way around. It seems to me we've had a lot of problems over the years trying to use base sqlite3 for everything in pkgsrc. It's not clear to me that any of the recent changes are helpful for the three things in base that need sqlite3, and it's also not clear that they will help with running newer pkgsrc on older NetBSD. libevent is also problematic. Maybe there's just too many third-party libraries that are exposed that sholdn't be. A failure for cvs, suspected to be a fallout of threaded sqlite3 was reported in port-arm@. See thread starts with: http://mail-index.netbsd.org/port-arm/2020/11/12/msg007046.html Also, I encountered another fallout: ``su -'' receives SIGSEGV when exits (on aarch64, but I bet this is MI problem): | $ su | # exit | $ su - | # exit | [2] Segmentation fault (core dumped) su - 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, | addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514 | ... The fault address is anon memory w/o exec permission when su exits: | # pmap -p xxx | ... | FC2961BB1000 4K read/write/altroot/lib/libgcc_s.so.1.0 | FC2961BB6000 40K read/write [ anon ] | FC2961BE6000 40K read/write [ anon ] | ... However, when su is running, libpthread is loaded at this address: | # pmap -p xxx | ... | FC2961BB1000 4K read/write/altroot/lib/libgcc_s.so.1.0 | FC2961BB6000 40K read/write [ anon ] | FC2961BC 76K read/exec /altroot/lib/libpthread.so.1.4 | FC2961BD3000 64K /altroot/lib/libpthread.so.1.4 | ... su is not explicitly linked to libpthread, but it is loaded via libkrb5 via libpam. It registers its own deconstructor, however, it is unloaded before su exits. Then, SIGSEGV takes place as a result. IMO, this commit should be reverted ASAP. This kind of change needs more tests, and discussion in appropriate lists before commit. Unfortunately, the committer did not even carry out ``build.sh'' before commit (martin fixed the build failure due to this). This is not what we, at least, I expect our developers. Thanks, rin
Re: CVS commit: src/sys/arch/arm/arm
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 forward. an optimisation on it could be to remove this test entirely if neither MODULAR or COMAPT_NETBSD32 are set, as it will always be false there. Ah, yes. I will commit after some test. Thanks! rin
re: CVS commit: src/sys/arch/arm/arm
"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 be to remove this test entirely if neither MODULAR or COMAPT_NETBSD32 are set, as it will always be false there. thanks. .mrg.
Re: CVS commit: src
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 > > src/external/public-domain/sqlite: Makefile.inc > > src/external/public-domain/sqlite/bin: Makefile > > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > > src/usr.sbin/makemandb: Makefile > > > > Log Message: > > sqlite: do not build without multithreading support > > > > at least a few pkgsrc packages avoid base sqlite because it fails > > this check, and it's probably a surprising performance penalty for > > unsuspecting users > > Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just > have pkgsrc always use pkgsrc sqlite3, and change base to go back to > the smaller non-threaded sqlite3 with only the options the things in > base actually need? > > Also: What is the performance penalty? The sqlite3 documentation > (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ > SQLITE_THREADSAFE has a performance penalty, not the other way around. > > It seems to me we've had a lot of problems over the years trying to > use base sqlite3 for everything in pkgsrc. It's not clear to me that > any of the recent changes are helpful for the three things in base > that need sqlite3, and it's also not clear that they will help with > running newer pkgsrc on older NetBSD. libevent is also problematic. Maybe there's just too many third-party libraries that are exposed that sholdn't be.
Re: CVS commit: src
> 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 > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support > > at least a few pkgsrc packages avoid base sqlite because it fails > this check, and it's probably a surprising performance penalty for > unsuspecting users Why do we even expose NetBSD's libsqlite3.so to pkgsrc? Why not just have pkgsrc always use pkgsrc sqlite3, and change base to go back to the smaller non-threaded sqlite3 with only the options the things in base actually need? Also: What is the performance penalty? The sqlite3 documentation (https://www.sqlite.org/faq.html#q6) suggests that _enabling_ SQLITE_THREADSAFE has a performance penalty, not the other way around. It seems to me we've had a lot of problems over the years trying to use base sqlite3 for everything in pkgsrc. It's not clear to me that any of the recent changes are helpful for the three things in base that need sqlite3, and it's also not clear that they will help with running newer pkgsrc on older NetBSD.
Re: CVS commit: src/share/mk
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 built from C" scourge).
Thanks, I wanted this!
rin
Re: CVS commit: src
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: Makefile.inc > src/external/public-domain/sqlite/bin: Makefile > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in > src/usr.sbin/makemandb: Makefile > > Log Message: > sqlite: do not build without multithreading support > > at least a few pkgsrc packages avoid base sqlite because it fails > this check, and it's probably a surprising performance penalty for > unsuspecting users > I'm getting: dependall ===> usr.sbin/makemandb nbmake[6]: nbmake[6]: don't know how to make -ltermlib. Stop nbmake[6]: stopped in /usr/src/usr.sbin/makemandb signature.asc Description: OpenPGP digital signature
Re: CVS commit: src
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 >> src/distrib/sets: sets.subr >> src/doc: BUILDING.mdoc >> src/share/man/man5: mk.conf.5 >> src/share/mk: bsd.README bsd.man.mk bsd.own.mk >> >> Log Message: >> Remove the support for MKCATPAGES >> >> It was optional since 1999 and disabled by default since 2012. >> >> Proposed on tech-userlevel@. > > What about the sets? > > christos > I'm test-building a local patch removing the cat files, directories and a few other remnants. Once it will be done, I will land it. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src
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 > src/share/man/man5: mk.conf.5 > src/share/mk: bsd.README bsd.man.mk bsd.own.mk > >Log Message: >Remove the support for MKCATPAGES > >It was optional since 1999 and disabled by default since 2012. > >Proposed on tech-userlevel@. What about the sets? christos
Re: CVS commit: src/sys
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 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 fixing them, OABI binaries work and dump valid core files!
I changed two files.
(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c
Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.
(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c
This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.
I will commit them soon if there's no objection.
Thanks,
rin
On 2020/11/08 6:53, Paul Goyette wrote:
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 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 following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH:?? ${S}/arch/arm/arm32
SRCS+=?? netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
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
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 compat_netbsd32_coredump modules
?? modload compat_netbsd32
?? modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
?? #include
?? int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD?? 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov?? 5 20:26:39 JST
2020 rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[?? 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_vm_default_addr' not found
[?? 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_machdep_md_init' not found
[?? 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_sendsig' not found
[?? 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `cpu_mcontext32_validate' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `cpu_setmcontext32' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_machdep_md_fini' not found
[?? 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `startlwp32' not found
[?? 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `cpu_getmcontext32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `machine32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error:
symbol `netbsd32_sysarch' not found
[?? 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in
files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail
addresses: |
| (Retired)?? | FA29 0E3B 35AF E8AE 6651 |
p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org
|
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail
addresses: |
|
Re: CVS commit: src/sys
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 fixing them, OABI binaries work and dump valid core files!
I changed two files.
(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c
Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.
(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c
This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.
I will commit them soon if there's no objection.
Thanks,
rin
On 2020/11/08 6:53, Paul Goyette wrote:
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 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 following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH: ${S}/arch/arm/arm32
SRCS+= netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
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
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 compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
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 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 following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH: ${S}/arch/arm/arm32
SRCS+= netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
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
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 compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
re: CVS commit: src/sys
> .if ${MACHINE_ARCH} == "arm"
this is wrong. it should use MACHINE_CPU.
.mrg.
Re: CVS commit: src/sys
/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
>
> .../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 following code in
> .../sys/modules/compat_netbsd32/Makefile
>
> .if ${MACHINE_ARCH} == "arm"
> .PATH: ${S}/arch/arm/arm32
> SRCS+= netbsd32_machdep.c
> .endif
>
> but it seems not to work (or at least, it doesn't do what it was
> intended to do).
>
>
>
>
>
>
> 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
>>> 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 compat_netbsd32_coredump modules
>>>
>>> modload compat_netbsd32
>>> modload compat_netbsd32_coredump
>>> Then see if emulation of the old ABI still works, and check if core-
>>> dump works for old-ADI programs; the test program I've been using for
>>> core-dump checking is
>>>
>>> #include
>>> int main(int argc, void *argv) { abort(); }
>>> I really have to leave and take care of some personal business, so I
>>> would greatly appreciate if you can check this out.
>>
>> Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
>>
>>
>> # uname -ap
>> NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
>> rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
>> # modload compat_netbsd32
>> [ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_vm_default_addr' not found
>> [ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_machdep_md_init' not found
>> [ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_sendsig' not found
>> [ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `cpu_mcontext32_validate' not found
>> [ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `cpu_setmcontext32' not found
>> [ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_machdep_md_fini' not found
>> [ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `startlwp32' not found
>> [ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `cpu_getmcontext32' not found
>> [ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `machine32' not found
>> [ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
>> `netbsd32_sysarch' not found
>> [ 29.7318320] WARNING: module error: unable to affix module
>> `compat_netbsd32', error 8
>> modload: compat_netbsd32: Exec format error
>>
>>
>> This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
>> not included in compat_netbsd32 module. compat_netbsd32 module must not
>> work also for aarch64 and mips64 for the same reason, whereas amd64 and
>> sparc64 seem OK.
>>
>> Thanks,
>> rin
>>
>> !DSPAM:5fa3f309175521945872603!
>>
>>
>
> ++--+---+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
> ++--+---+
signature.asc
Description: Message signed with OpenPGP
Re: CVS commit: src/sys
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 following code in
.../sys/modules/compat_netbsd32/Makefile
.if ${MACHINE_ARCH} == "arm"
.PATH: ${S}/arch/arm/arm32
SRCS+= netbsd32_machdep.c
.endif
but it seems not to work (or at least, it doesn't do what it was
intended to do).
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
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 compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
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
Re: CVS commit: src/sys
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
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 compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
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 boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
Re: CVS commit: src/sys/kern
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 in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> options PTRACE # Include ptrace(2) syscall
###> options PTRACE_HOOKS # Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd, ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd, ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Yes that would be a problem.
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
I have some prior obligations, so I won't be able to look at this
until this evening.
Thanks for the detailed analysis.
Fixed. Thanks!
rin
Re: CVS commit: src/sys
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 compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Thanks!
On Wed, 4 Nov 2020, Paul Goyette wrote:
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 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
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile
Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.
Welcome to 7.99.75 !!!
To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:
panic: kernel diagnostic assertion "!*hooked" failed: file
"../../../../kern/kern_module_hook.c", line 70
Does the attached patch seem reasonable to you?
Thanks,
rin
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
!DSPAM:5fa2ae10252946113815662!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
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 initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd,
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd,
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of
'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
Thanks,
rin
!DSPAM:5fa2b869233318156490363!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
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 initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd,
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd,
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Yes that would be a problem.
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of
'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
I have some prior obligations, so I won't be able to look at this
until this evening.
Thanks for the detailed analysis.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
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 module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd,
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd,
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
Thanks,
rin
Re: CVS commit: src/sys
> 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
Re: CVS commit: src/sys/kern
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 init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys/kern
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:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini routines.
To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.
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 init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
Thanks,
rin
Re: CVS commit: src/sys
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
