This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
dev/audio/t_audio:audioctl_kqueue
dev/audio/t_audio:kqueue_empty
dev/audio/t_audio:kqueue_full
dev/audio/t_audio:kqueue_hiwat
Updating src tree:
P src/crypto/external/bsd/openssh/dist/cipher.h
P src/crypto/external/bsd/openssh/dist/compat.h
P src/crypto/external/bsd/openssh/dist/monitor.h
P src/crypto/external/bsd/openssh/dist/scp.1
P src/crypto/external/bsd/openssh/dist/scp.c
P
{184} route show -inet net 192.168.0/24
route: botched keyword: 192.168.0/24
Usage: route [-dfLnqSsTtv] cmd [[-] args]
route show is documented to print the table. It does not take narrowing
specifiers.
Try
route get -inet 192.168.0.0/24
and it's arguably a bug that
route get -inet
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
first successful build:
2023.07.28.19.01.10 christos
src/sys/compat/linux/arch/aarch64/syscalls.master 1.6
2023.07.28.19.01.11 christos
> {184} route show -inet net 192.168.0/24
> route: botched keyword: 192.168.0/24
> Usage: route [-dfLnqSsTtv] cmd [[-] args]
[After reading both route(8) and the source:]
The "show" sub command just accepts a few of the initial "[-dfLnqSsTtv]"
options, a few "-
recvpipe sendpipe ssthresh
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2023.07.28.18.20.52.
An extract from the build.sh output follows:
Paul Goyette writes:
Paul Goyette writes:
> Can anyone exlpain what I'm doing wrong?
> {184} route show -inet net 192.168.0/24
> route: botched keyword: 192.168.0/24
> Usage: route [-dfLnqSsTtv] cmd [[-] args]
route show is documented to print the table. It does not take narrowing
> Date: Fri, 28 Jul 2023 09:42:30 -0400
> From: Brad Spencer
>
> Thanks, that allowed the dtrace to execute, but I never have time to
> execute the second probe, as this kernel panic occures within a few
> seconds of the first probe being run (probably on the order of 4 - 5
> seconds):
>
> [
Can anyone exlpain what I'm doing wrong?
{183} route show -inet
Routing tables
Internet:
DestinationGatewayFlagsRefs UseMtu Interface
default192.168.0.1UG -- - wm0
127/8 localhost UGRS-
Taylor R Campbell writes:
>> Date: Fri, 28 Jul 2023 07:42:04 -0400
>> From: Brad Spencer
>>
>> dtrace: invalid probe specifier sdt:xen:hardclock:jump { @ = quantize(arg1 -
>> arg0) } tick-10s { printa(@) }: probe description :::tick-10s does not match
>> any probes
>
> modload dtrace_profile
Taylor R Campbell writes:
>> Date: Fri, 28 Jul 2023 07:42:04 -0400
>> From: Brad Spencer
>>
>> dtrace: invalid probe specifier sdt:xen:hardclock:jump { @ = quantize(arg1 -
>> arg0) } tick-10s { printa(@) }: probe description :::tick-10s does not match
>> any probes
>
> modload dtrace_profile
> Date: Fri, 28 Jul 2023 07:42:04 -0400
> From: Brad Spencer
>
> dtrace: invalid probe specifier sdt:xen:hardclock:jump { @ = quantize(arg1 -
> arg0) } tick-10s { printa(@) }: probe description :::tick-10s does not match
> any probes
modload dtrace_profile
Taylor R Campbell writes:
>> Date: Thu, 27 Jul 2023 11:17:30 -0400
>> From: Brad Spencer
>>
>> On the system that I have that exhibits the negative runtime problem, it
>> may very well be the case that hardclocks are missed for 4.3sec. The
>> system has to have been up for a while and busy as
> Date: Thu, 27 Jul 2023 11:17:30 -0400
> From: Brad Spencer
>
> On the system that I have that exhibits the negative runtime problem, it
> may very well be the case that hardclocks are missed for 4.3sec. The
> system has to have been up for a while and busy as a prereq., but if I
> then run:
>
14 matches
Mail list logo
