Updating src tree:
P src/common/lib/libc/arch/aarch64/atomic/Makefile.inc
U src/common/lib/libc/arch/aarch64/atomic/__aarch64_swp1_acq.S
U src/common/lib/libc/arch/aarch64/atomic/__aarch64_swp1_acq_rel.S
U src/common/lib/libc/arch/aarch64/atomic/__aarch64_swp1_rel.S
U
matthew green writes:
> i saw a report that netbsd-8 can't be built on -current but i'm
> not finding it right now.
>
> i can confirm this is the case. you can work around the GCC 10
> inspired issues for now with eg:
>
>./build.sh -V HOST_CFLAGS='-fcommon -O2'
this is likely to remain
Jan Schaumann wrote:
> So if this is correct, then it looks like (a) the
> router is misbehaving (it should send a NA when we so
> politely ask)
Joerg found the culprit:
It turns out that apparently the router will only
reply with NAs to a NS that originates from a
predicted IPv6 address.
On Wed, 21 Apr 2021, Robert Swindells wrote:
Think we need to make dhcpcd work with rump if it is the only way to
do RA processing.
And create an appropriate set of rump-based atf tests to detect future
regressions.
++--+---+
|
Joerg Sonnenberger wrote:
>On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
>> On Apr 20, 21:13, Joerg Sonnenberger wrote:
>> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
>> } > It seems as if what is happening, is that the router is sending RA's with
>> } > the
On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
> On Apr 20, 21:13, Joerg Sonnenberger wrote:
> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
> } > It seems as if what is happening, is that the router is sending RA's with
> } > the source-link addr option, which isn't
On Apr 20, 21:13, Joerg Sonnenberger wrote:
} On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
} > It seems as if what is happening, is that the router is sending RA's with
} > the source-link addr option, which isn't being added to the neighbour
} > cache.
} >
} > Then NetBSD is doing
