On Fri, Oct 13, 2023 at 05:11:47PM +0300, Andreas Gustafsson wrote:
> Even though some of the test failures were reported as an excessive
> number of separate emails and attributed to the wrong commit, the
> failures themselves are real.
Indeed, on my real hardware tests the jumps are impressive:
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v4v6_esp_cast128cbc
>
> The above test failed in each of the last 4 test runs, and passed
Date:Sat, 27 May 2023 20:26:06 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Perhaps add a flag to the mount command to not do the realpath check?
No longer needed, hannken@ provided a fix for the tests. I didn't
consider that one as a
In article <1617.1685135...@jacaranda.noi.kre.to>,
Robert Elz wrote:
>
>I'll keep looking, and see if there is a reasonable path forward, which
>allows rump's bizarre etfs to function as needed, without completely
>breaking normal unix pathname resolution semantics.
Perhaps add a flag to the
Date:Fri, 26 May 2023 02:29:05 + (UTC)
From:NetBSD Test Fixture
Message-ID: <168506814541.4954.15559262820055138...@babylon5.netbsd.org>
| The newly failing test cases are:
|
| fs/nfs/t_rquotad:get_nfs_be_1_both
|
NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> lib/libc/net/t_protoent:protoent
>
> The above test failed in each of the last 4 test runs, and passed in
> at least 26 consecutive
Date:Sat, 12 Mar 2022 23:35:47 + (UTC)
From:NetBSD Test Fixture
Message-ID: <164712814771.10628.11343290967506895...@babylon5.netbsd.org>
| The newly failing test cases are:
| lib/libc/stdlib/t_hsearch:hsearch_basic
It is possible those might all be
This test still fails as:
kqueue: [5.986468s] Failed: dir/b did not receive NOTE_LINK
Can you please take a look?
Thanks,
rin
On 2021/10/21 5:43, NetBSD Test Fixture wrote:
This is an automatically generated notice of a new failure of the
NetBSD test suite.
The newly failing test case is:
On 07.02.2021 01:33, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
usr.bin/make/t_make:archive
usr.bin/make/t_make:cmdline
I will take care of these.
Roland
On Sun, Jan 17, 2021 at 08:03:20PM +0200, Andreas Gustafsson wrote:
> The cause of the 1000+ new test failures has now been narrowed down to
> the following commit:
>
> 2021.01.16.23.50.49 chs src/sys/rump/librump/rumpkern/rump.c,v 1.352
> 2021.01.16.23.51.50 chs
The cause of the 1000+ new test failures has now been narrowed down to
the following commit:
2021.01.16.23.50.49 chs src/sys/rump/librump/rumpkern/rump.c,v 1.352
2021.01.16.23.51.50 chs src/sys/arch/arm/arm/psci.c,v 1.5
2021.01.16.23.51.50 chs src/sys/conf/files,v 1.1278
Yesterday, the NetBSD Test Fixture wrote:
> The newly failing test case is:
>
> rump/rumpkern/t_vm:busypage
This one is still failing. The rump kernel panics with:
[ 1.1400050] panic: kernel diagnostic assertion "(pg->flags & PG_FAKE) ==
0" failed: file
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> lib/libm/t_fmod:fmod
>
[...]
> 2020.08.23.06.12.52 rillig src/usr.bin/make/buf.c,v 1.36
[...]
False alarm - it looks like
On 23/10/2020 08:25, Andreas Gustafsson wrote:
Roy Marples wrote:
This is rump crashing and I don't know why.
If the rump kernel crashes in the test, that likely means the real
kernel will crash in actual use.
I can't get a backtrace to tell me where the problem is.
I managed to get one
Roy Marples wrote:
> This is rump crashing and I don't know why.
If the rump kernel crashes in the test, that likely means the real
kernel will crash in actual use.
> I can't get a backtrace to tell me where the problem is.
I managed to get one this way:
sysctl -w
Hi Andreas
On 22/10/2020 09:00, Andreas Gustafsson wrote:
Hi Roy,
On Oct 16, the NetBSD Test Fixture wrote:
The newly failing test cases are:
net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv4
net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv6
net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv4
Hi Roy,
On Oct 16, the NetBSD Test Fixture wrote:
> The newly failing test cases are:
>
> net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv4
> net/if_l2tp/t_l2tp:l2tp_basic_ipv4overipv6
> net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv4
> net/if_l2tp/t_l2tp:l2tp_basic_ipv6overipv6
>
On 2020/10/22 12:06, Chuck Silvers wrote:
On Wed, Oct 21, 2020 at 08:30:17PM +0900, Rin Okuyama wrote:
On 2020/10/21 20:10, Andreas Gustafsson wrote:
Two days ago, the NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly
On Wed, Oct 21, 2020 at 08:30:17PM +0900, Rin Okuyama wrote:
> On 2020/10/21 20:10, Andreas Gustafsson wrote:
> > Two days ago, the NetBSD Test Fixture wrote:
> > > This is an automatically generated notice of new failures of the
> > > NetBSD test suite.
> > >
> > > The newly failing test cases
On 2020/10/21 20:10, Andreas Gustafsson wrote:
Two days ago, the NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
sbin/resize_ffs/t_grow:grow_16M_v0_8192
Two days ago, the NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> sbin/resize_ffs/t_grow:grow_16M_v0_8192
> sbin/resize_ffs/t_grow:grow_16M_v1_16384
>
On 16/10/2020 15:54, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
net/if_wg/t_basic:wg_basic_ipv6_over_ipv4
net/if_wg/t_basic:wg_basic_ipv6_over_ipv6
On 14/10/2020 07:15, Andreas Gustafsson wrote:
On Oct 8, the NetBSD Test Fixture wrote:
The newly failing test cases are:
net/carp/t_basic:carp_handover_ipv4_halt_carpdevip
net/carp/t_basic:carp_handover_ipv4_halt_nocarpdevip
net/carp/t_basic:carp_handover_ipv4_ifdown_carpdevip
On Oct 8, the NetBSD Test Fixture wrote:
> The newly failing test cases are:
>
> net/carp/t_basic:carp_handover_ipv4_halt_carpdevip
> net/carp/t_basic:carp_handover_ipv4_halt_nocarpdevip
> net/carp/t_basic:carp_handover_ipv4_ifdown_carpdevip
>
On 23/09/2020 11:42, NetBSD Test Fixture wrote:
This is an automatically generated notice of a new failure of the
NetBSD test suite.
The newly failing test case is:
net/if/t_ifconfig:ifconfig_options
The above test failed in each of the last 4 test runs, and passed in
at least 26
On 20/09/2020 04:40, Robert Elz wrote:
Date:Sun, 20 Sep 2020 04:02:45 +0100
From:Roy Marples
Message-ID: <51d2f8dc-d059-5eae-9899-5c91539d1...@marples.name>
| The test case just needed fixing.
That is not uncommon after changes elsewhere.
| The ping
Date:Sun, 20 Sep 2020 04:02:45 +0100
From:Roy Marples
Message-ID: <51d2f8dc-d059-5eae-9899-5c91539d1...@marples.name>
| The test case just needed fixing.
That is not uncommon after changes elsewhere.
| The ping to an invalid address caused the ARP entry to
On 13/09/2020 23:10, Robert Elz wrote:
Date:Sun, 13 Sep 2020 22:14:00 +0100
From:Roy Marples
Message-ID:
| >| > net/arp/t_arp:arp_proxy_arp_pub
| >| > net/arp/t_arp:arp_proxy_arp_pubproxy
| >
| > Those two are still failing.
|
Date:Sun, 13 Sep 2020 22:14:00 +0100
From:Roy Marples
Message-ID:
| >| > net/arp/t_arp:arp_proxy_arp_pub
| >| > net/arp/t_arp:arp_proxy_arp_pubproxy
| >
| > Those two are still failing.
|
| Works fine on my box.
| Can you say how
On 13/09/2020 22:07, Robert Elz wrote:
Date:Sun, 13 Sep 2020 20:06:45 +0100
From:Roy Marples
Message-ID: <9e977478-d209-2dbb-49d9-3fa9acd25...@marples.name>
| > net/arp/t_arp:arp_cache_expiration_10s
| > net/arp/t_arp:arp_cache_expiration_5s
Date:Sun, 13 Sep 2020 20:06:45 +0100
From:Roy Marples
Message-ID: <9e977478-d209-2dbb-49d9-3fa9acd25...@marples.name>
| > net/arp/t_arp:arp_cache_expiration_10s
| > net/arp/t_arp:arp_cache_expiration_5s
Those two are "fixed" (if you can call deleted
On 12/09/2020 22:57, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
net/arp/t_arp:arp_cache_expiration_10s
net/arp/t_arp:arp_cache_expiration_5s
net/arp/t_arp:arp_command
The NetBSD Test Fixture reported this test failure twice:
> net/net/t_unix:sockaddr_un_local_peereid
Sorry about the duplicate report. The testbed is now using Python 3
and that appears to have broken the duplicate suppression. I'll fix it.
--
Andreas Gustafsson, g...@gson.org
Hi,
On 2020/06/19 21:04, Martin Husemann wrote:
On Fri, Jun 19, 2020 at 08:56:32PM +0900, Rin Okuyama wrote:
I will make these tests (and similar ones in kernel/t_trapsignal) skipped on
QEMU, if there's no objection.
No objections from me.
Could you file a qemu bug for this, please?
Thank
On Fri, Jun 19, 2020 at 08:56:32PM +0900, Rin Okuyama wrote:
> I will make these tests (and similar ones in kernel/t_trapsignal) skipped on
> QEMU, if there's no objection.
No objections from me.
Could you file a qemu bug for this, please?
Thanks!
Martin
This seems due to QEMU bug, as also observed in
tests/lib/libc/gen/t_siginfo:sigfpe_flt, see:
http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libc/gen/t_siginfo.c#rev1.20
Actually, these tests pass on
(1) VirtualBox, and
(2) real hardware under amd64 kernel with COMPAT_NETBSD32.
I will make
I will examine this.
Thanks,
rin
On 2020/06/19 19:28, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
lib/libc/sys/t_ptrace_wait3:traceme_crash_fpe
> On 16. Jun 2020, at 12:42, NetBSD Test Fixture wrote:
>
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
>fs/vfs/t_full:nfs_fillfs
[snip]
>2020.06.14.23.38.25 kamil src/sys/rump/include/rump/rump.h,v
> On Jun 8, 2020, at 10:33 AM, Jason Thorpe wrote:
>
>
>> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote:
>>
>> This is an automatically generated notice of new failures of the
>> NetBSD test suite.
>>
>> The newly failing test cases are:
>>
>>
> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote:
>
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
>net/if/t_ifconfig:ifconfig_description
>sbin/gpt/t_gpt:backup_2part
I think this is just a
Fixed, thanks!
christos
> On May 22, 2020, at 4:15 AM, Andreas Gustafsson wrote:
>
> Christos,
>
> On May 18, the NetBSD Test Fixture wrote:
>> The newly failing test cases are:
>>
>>atf/atf-c/detail/fs_test:mkdtemp_err
>>atf/atf-c/detail/fs_test:mkstemp_err
>>
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> dev/audio/t_audio:AUDIO_ERROR_RDWR
> dev/audio/t_audio:AUDIO_ERROR_WRONLY
[and many more]
That message got stuck somewhere
There are actually now more than 2,000 failing test cases in total,
but the email message reporting most of them has failed to appear on
current-users, perhaps because of its size.
--
Andreas Gustafsson, g...@gson.org
Date:Fri, 24 Apr 2020 19:59:31 + (UTC)
From:NetBSD Test Fixture
Message-ID: <158775837076.23438.17159050926672197...@babylon5.netbsd.org>
| The newly failing test cases are:
|
| usr.bin/printf/t_builtin:A_floats
| usr.bin/printf/t_command:A_floats
On Sat, Apr 18, 2020 at 10:32:18AM +0300, Andreas Gustafsson wrote:
> The NetBSD Test Fixture sent three reports listing the following
> groups of commits, respectively:
>
> >2020.04.16.14.39.58 joerg src/lib/libc/gen/pthread_atfork.c,v 1.13
> >2020.04.16.14.39.58 joerg
On Sat, Apr 18, 2020 at 01:09:52AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait4:fork10
> lib/libc/sys/t_ptrace_wait4:fork2
>
The NetBSD Test Fixture sent three reports listing the following
groups of commits, respectively:
>2020.04.16.14.39.58 joerg src/lib/libc/gen/pthread_atfork.c,v 1.13
>2020.04.16.14.39.58 joerg src/libexec/ld.elf_so/rtld.c,v 1.204
>2020.04.16.14.39.58 joerg
NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> fs/puffs/t_basic:root_chrdev
> fs/puffs/t_basic:root_fifo
> fs/puffs/t_basic:root_lnk
(etc)
These are already reported in
On 31/03/2020 12:22, NetBSD Test Fixture wrote:
The newly failing test case is:
usr.bin/infocmp/t_terminfo:basic
This error in infocmp is now fixed.
Roy
Probably mine - working on it
On Wed, 18 Mar 2020, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
dev/sysmon/t_swsensor:alarm_sensor
dev/sysmon/t_swsensor:entropy_interrupt_sensor
This morning, the NetBSD Test Fixture wrote:
> The newly failing test case is:
>
> net/if_ipsec/t_ipsec_natt:ipsecif_natt_transport_rijndaelcbc
>
> The above test failed in each of the last 3 test runs, and passed in
> at least 27 consecutive runs before that.
>
> The following commits were
The NetBSD Test Fixture wrote:
> The newly failing test case is:
>
> net/ipsec/t_ipsec_l2tp:ipsec_l2tp_ipv6_transport_ah_null
>
> The above test failed in each of the last 3 test runs, and passed in
> at least 27 consecutive runs before that.
The fourth test run passed, so this looks like
The NetBSD Test Fixture wrote:
> The newly failing test case is:
>
> net/ipsec/t_ipsec_tunnel:ipsec_tunnel_ipv4_ah_keyedmd5
>
> The above test failed in each of the last 3 test runs, and passed in
> at least 27 consecutive runs before that.
>
> The following commits were made between the
On Wed, Jan 29, 2020 at 02:45:22AM +, NetBSD Test Fixture wrote:
> The newly failing test case is:
>
> lib/libpthread/t_detach:pthread_detach
...
> 2020.01.27.20.50.05 ad src/lib/libpthread/pthread.c,v 1.157
Wrong error code from the kernel (ESRCH vs EINVAL) worked around with
The remaining failures should be fixed by:
1.181 src/sys/rump/librump/rumpkern/vm.c
Cheers,
Andrew
On Thu, Jan 02, 2020 at 01:26:42PM +, Andrew Doran wrote:
> I think this is likely fixed already but will take a look now.
>
> Andrew
>
> On Thu, Jan 02, 2020 at 08:35:09AM +,
I think this is likely fixed already but will take a look now.
Andrew
On Thu, Jan 02, 2020 at 08:35:09AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
>
On Wed, Dec 18, 2019 at 01:27:32PM +, Andrew Doran wrote:
> On Wed, Dec 18, 2019 at 08:25:15AM +, NetBSD Test Fixture wrote:
>
> > This is an automatically generated notice of new failures of the
> > NetBSD test suite.
> >
> > The newly failing test cases are:
> >
> >
Andrew Doran wrote:
> > sbin/resize_ffs/t_grow:grow_16M_v1_16384
> > sbin/resize_ffs/t_grow:grow_16M_v2_32768
> > sbin/resize_ffs/t_grow_swapped:grow_16M_v0_65536
> > sbin/resize_ffs/t_grow_swapped:grow_16M_v1_4096
> > sbin/resize_ffs/t_grow_swapped:grow_16M_v2_8192
> >
On Wed, Dec 18, 2019 at 08:25:15AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> fs/vfs/t_full:lfs_fillfs
> fs/vfs/t_io:lfs_extendfile
>
The NetBSD Test Fixture wrote:
> The newly failing test case is:
>
> sbin/resize_ffs/t_grow:grow_16M_v0_8192
>
> The above test failed in each of the last 4 test runs, and passed in
> at least 36 consecutive runs before that.
>
> The following commits were made between the last successful
Fixed in:
src/tests/lib/libc/sys/t_ptrace_wait.c r.1.141
src/tests/lib/libc/sys/t_ptrace_wait.h r.1.18
On 12.11.2019 18:34, Paul Goyette wrote:
> I've confirmed that these failures occur with builds from before
> my most recent changes. So, as Kamil indicated (and Joerg on
> IRC), it ain't my
I've confirmed that these failures occur with builds from before
my most recent changes. So, as Kamil indicated (and Joerg on
IRC), it ain't my fault!
On Tue, 12 Nov 2019, Paul Goyette wrote:
Hmmm, this might be my fault. Checking/bisecting now...
On Tue, 12 Nov 2019, NetBSD Test Fixture
The problem is in ATF tests with assumptions that are no longer valid.
We are working on this. The right fix is to improve the tests.
On 12.11.2019 13:53, Paul Goyette wrote:
> Hmmm, this might be my fault. Checking/bisecting now...
>
> On Tue, 12 Nov 2019, NetBSD Test Fixture wrote:
>
>>
On Tue, 12 Nov 2019, Kamil Rytarowski wrote:
The problem is in ATF tests with assumptions that are no longer valid.
We are working on this. The right fix is to improve the tests.
Oh, good - not my fault after all!
Thanks!
On 12.11.2019 13:53, Paul Goyette wrote:
Hmmm, this might be
Hmmm, this might be my fault. Checking/bisecting now...
On Tue, 12 Nov 2019, NetBSD Test Fixture wrote:
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals
On 12.11.2019 09:26, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals
>
Sorry, I misread the logs - it was the wait4 variant of the test that
succeeded in the test run after the wait6 one failed.
In any case, this simply looks like flaky/racy tests, or ptrace(),
(and certainly unrelated to the listed commits).
kre
Date:Fri, 18 Oct 2019 15:14:04 + (UTC)
From:NetBSD Test Fixture
Message-ID: <157141164388.24477.1554860029123...@babylon5.netbsd.org>
| The newly failing test case is:
|
| lib/libc/sys/t_ptrace_waitid:tracer_sysctl_lookup_without_duplicates
While
On 21.09.2019 18:18, Robert Elz wrote:
> Date:Sat, 21 Sep 2019 15:40:49 + (UTC)
> From:NetBSD Test Fixture
> Message-ID: <156908044959.2857.11788397410553967...@babylon5.netbsd.org>
>
> | The newly failing test cases are:
> |
> |
Date:Sat, 21 Sep 2019 15:40:49 + (UTC)
From:NetBSD Test Fixture
Message-ID: <156908044959.2857.11788397410553967...@babylon5.netbsd.org>
| The newly failing test cases are:
|
| fs/vfs/t_ro:ext2fs_attrs
| fs/vfs/t_ro:ffs_attrs
|
On Mon, Aug 26, 2019 at 03:13:29AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> net/if_ipsec/t_ipsec_pfil:ipsecif_pfil_esp_null
>
On Thu, 8 Aug 2019, Paul Goyette wrote:
I am investigating...
This should be fixed by sys/kern/kern_module.c rev 1.138
On Thu, 8 Aug 2019, NetBSD Test Fixture wrote:
This is an automatically generated notice of a new failure of the
NetBSD test suite.
The newly failing test case is:
I am investigating...
On Thu, 8 Aug 2019, NetBSD Test Fixture wrote:
This is an automatically generated notice of a new failure of the
NetBSD test suite.
The newly failing test case is:
modules/t_builtin:busydisable
The above test failed in each of the last 3 test runs, and passed in
at
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> lib/libc/sys/t_ptrace_waitpid:tracer_sysctl_lookup_without_duplicates
>
> The above test failed in each of the last 3 test runs,
On 21.06.2019 18:09, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> fs/vfs/t_vnops:ext2fs_rename_dir
> fs/vfs/t_vnops:ext2fs_rename_reg_nodir
> fs/vfs/t_vnops:ffs_rename_dir
On 03.05.2019 11:20, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait3:bytes_transfer_alignment_piod_read_auxv
>
On 02.05.2019 01:54, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> usr.bin/gdb/t_regress:pie
>
Addressed in sys_ptrace_common.c 1.5
It looks like a bug in GDB, but for now I will
Date:Tue, 30 Apr 2019 21:58:19 + (UTC)
From:NetBSD Test Fixture
Message-ID: <155666149938.7910.2797000443449332...@babylon5.netbsd.org>
| The newly failing test cases are:
|
| sys/net/t_print:dl_print
| sys/net/t_print:sdl_print
These should be
Date:Mon, 29 Apr 2019 12:02:10 +0300
From:Valery Ushakov
Message-ID: <20190429090210.gd11...@pony.stderr.spb.ru>
| E.g. in sys/arch/sh3/include/adcreg.h
Yes, I noticed many uses in arch/* ... I sampled a bunch of them,
and was mostly finding "old" style uses... So
On Mon, Apr 29, 2019 at 10:29:43 +0700, Robert Elz wrote:
> I've done some searching (not exhaustive for sure) and the only
> thing I can find that uses 'F' in our tree that I can find is
> (which provided the newly added example in snprintb.3)
> which is missing that final NUL after the F field
Thanks!
christos
> On Apr 28, 2019, at 10:33 PM, Robert Elz wrote:
>
>Date:Mon, 29 Apr 2019 08:58:43 +0700
>From:Robert Elz
>Message-ID: <17972.1556503...@jinx.noi.kre.to>
>
> | I know what is happening with that, and I will fix...
> |
> | The problem relates
Date:Mon, 29 Apr 2019 09:33:59 +0700
From:Robert Elz
Message-ID: <22739.1556505...@jinx.noi.kre.to>
| Upon reflection, I'm inclined to instead [...]
And upon further reflection, and noticing this sentence in
the snprintb() man page (snprintb.3)
Finally,
Date:Mon, 29 Apr 2019 08:58:43 +0700
From:Robert Elz
Message-ID: <17972.1556503...@jinx.noi.kre.to>
| I know what is happening with that, and I will fix...
|
| The problem relates to a difference of opinion/misunderstanding
| of the 'F' (new style) format
Date:Sun, 28 Apr 2019 21:50:45 + (UTC)
From:NetBSD Test Fixture
Message-ID: <155648824563.27186.9065778287415893...@babylon5.netbsd.org>
| The newly failing test case is:
|
| lib/libutil/t_snprintb:snprintb
I know what is happening with that, and I
Fixed, thanks!
christos
> On Apr 7, 2019, at 8:32 AM, Rin Okuyama wrote:
>
> On 2019/04/07 1:00, Andreas Gustafsson wrote:
>> Christos Zoulas wrote:
>>> Must be, but I can't reproduce it, can you run gdb on the core file?
>> No need to go hunting or a core, simply running "date" with no
>>
On 2019/04/07 1:00, Andreas Gustafsson wrote:
Christos Zoulas wrote:
Must be, but I can't reproduce it, can you run gdb on the core file?
No need to go hunting or a core, simply running "date" with no
arguments will reproduce it. Doing that under gdb shows:
(gdb) where
#0 0xac643b67
Christos Zoulas wrote:
> Must be, but I can't reproduce it, can you run gdb on the core file?
No need to go hunting or a core, simply running "date" with no
arguments will reproduce it. Doing that under gdb shows:
(gdb) where
#0 0xac643b67 in ?? () from /lib/libc.so.12
#1 0xac644496 in
Must be, but I can't reproduce it, can you run gdb on the core file?
christos
> On Apr 6, 2019, at 3:52 AM, Andreas Gustafsson wrote:
>
> NetBSD Test Fixture wrote:
>> This is an automatically generated notice of new failures of the
>> NetBSD test suite.
>>
>> The newly failing test cases
NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> atf/tools/atf-run_test:broken_results
[...]
Looking at the log for the first failing test, "date" is dumping core:
In article <23645.7935.238592.235...@guava.gson.org>,
Andreas Gustafsson wrote:
>The NetBSD Test Fixture wrote:
>> The newly failing test cases are:
>>
>> dev/raidframe/t_raid:raid1_comp0fail
>> dev/raidframe/t_raid:raid1_compfail
>> dev/raidframe/t_raid:raid1_normal
>>
The NetBSD Test Fixture wrote:
> The newly failing test cases are:
>
> dev/raidframe/t_raid:raid1_comp0fail
> dev/raidframe/t_raid:raid1_compfail
> dev/raidframe/t_raid:raid1_normal
> dev/raidframe/t_raid:raid5_compfail
> dev/raidframe/t_raid:raid5_normal
This was a duplicate
The NetBSD Test Fixture wrote:
> The newly failing test cases are:
>
> lib/libc/sys/t_ptrace_wait3:dbregs_dr0_dont_inherit_execve
> lib/libc/sys/t_ptrace_wait3:dbregs_dr0_dont_inherit_lwp
(etc, more than 300 failing test cases)
These are also failing on real i386 hardware, but not on
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> usr.bin/c++/t_asan_poison:poison
> usr.bin/c++/t_asan_poison:poison_pic
> usr.bin/cc/t_asan_poison:poison
>
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> sbin/gpt/t_gpt:migrate_disklabel
This was a false alarm - sorry about that. Looks like the testbed
used some idle time to fill in
Michael van Elst wrote:
> I have reverted that part of the commit that introduced that change.
> Lets find out if that makes the test succeed in the testbed again (it
> always succeeded here on real hardware). Then fix the test.
Reverting did make the lib/libc/sys/t_sendmmsg/sendmmsg_basic test
On Fri, Nov 30, 2018 at 03:43:23PM +0100, Martin Husemann wrote:
> This test has hung for me (untill atf timeout) on some machines (e.g.
> single core arm) since several weeks, I think the test code is buggy.
While the test is buggy, the bug was triggered by the changed scheduler
behaviour.
I
On Fri, Nov 30, 2018 at 03:16:00PM +0200, Andreas Gustafsson wrote:
> The NetBSD Test Fixture wrote:
> > This is an automatically generated notice of a new failure of the
> > NetBSD test suite.
> >
> > The newly failing test case is:
> >
> > lib/libc/sys/t_sendmmsg:sendmmsg_basic
This test
The NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> lib/libc/sys/t_sendmmsg:sendmmsg_basic
Sorry about the duplicate reports about this, that was an error on my
part which should now
Date:Mon, 19 Nov 2018 01:07:17 + (UTC)
From:NetBSD Test Fixture
Message-ID: <154258963726.7846.5173440576646830...@babylon5.netbsd.org>
| The newly failing test case is:
| bin/sh/t_patterns:case_matching
This is expected - the failures are from newly
Robert Elz wrote:
> | The newly failing test case is:
> |
> | sbin/gpt/t_gpt:migrate_disklabel
[...]
> That leaves mrg's gcc changes, and if gcc has started generating bad code for
> (the fairly simple source that is) fdisk (or for dd, which makes a filesys
> image via a copy from
1 - 100 of 142 matches
Mail list logo
