Searched hist:1.689 (Results 1 - 22 of 22) sorted by relevance

/src/sys/dev/pci/
H A Dpcidevs.h1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
1.689 Tue Jan 25 00:55:25 GMT 2005 matt branches: 1.689.2;
Regen.
H A Dpcidevs_data.h1.689 Thu Jan 27 21:48:37 GMT 2005 jdolecek regen: add id for nForce2 Ultra 400 audio
1.689 Thu Jan 27 21:48:37 GMT 2005 jdolecek regen: add id for nForce2 Ultra 400 audio
1.689 Thu Jan 27 21:48:37 GMT 2005 jdolecek regen: add id for nForce2 Ultra 400 audio
1.689 Thu Jan 27 21:48:37 GMT 2005 jdolecek regen: add id for nForce2 Ultra 400 audio
H A Dpcidevs1.689 Thu Jan 27 13:31:45 GMT 2005 kent add some nForce 4 devices
1.689 Thu Jan 27 13:31:45 GMT 2005 kent add some nForce 4 devices
1.689 Thu Jan 27 13:31:45 GMT 2005 kent add some nForce 4 devices
1.689 Thu Jan 27 13:31:45 GMT 2005 kent add some nForce 4 devices
/src/sys/dev/usb/
H A Dusbdevs1.689 Wed Feb 04 14:23:04 GMT 2015 jmcneill add Xbox 360 Wireless Receiver
H A Dusbdevs.h1.689 Wed Jun 17 14:21:22 GMT 2015 nonaka regen
H A Dusbdevs_data.h1.689 Mon Apr 06 17:16:25 GMT 2015 bouyer Regen (Add Apple Magic Trackpad)
/src/share/man/man4/
H A DMakefile1.689 Wed Nov 20 09:37:45 GMT 2019 hikaru Add opencrypto driver for Intel QuickAssist.
/src/usr.bin/xlint/lint1/
H A Dtree.c1.689 Sun Sep 07 09:53:28 GMT 2025 rillig lint: clean up checks for '<<' and '>>'
/src/usr.bin/make/
H A Dparse.c1.689 Sat Oct 01 09:25:06 GMT 2022 rillig make: use consistent variable names in parser

No functional change.
H A Dvar.c1.689 Tue Nov 17 20:11:02 GMT 2020 rillig make(1): fix error message of failed :!cmd! modifier (since 2000-04-29)
1.689 Tue Nov 17 20:11:02 GMT 2020 rillig make(1): fix error message of failed :!cmd! modifier (since 2000-04-29)
/src/sys/arch/i386/i386/
H A Dmachdep.c1.689 Thu Jul 15 22:19:19 GMT 2010 jym pte0 is used to map the page required by bioscall() trampoline code, so
add VM_PROT_EXECUTE protection for it.

Currently, this does not change much, as page execute permission is not
enforced for i386 (except for Xen, where BIOS calls are not used anyway).
1.689 Thu Jul 15 22:19:19 GMT 2010 jym pte0 is used to map the page required by bioscall() trampoline code, so
add VM_PROT_EXECUTE protection for it.

Currently, this does not change much, as page execute permission is not
enforced for i386 (except for Xen, where BIOS calls are not used anyway).
1.689 Thu Jul 15 22:19:19 GMT 2010 jym pte0 is used to map the page required by bioscall() trampoline code, so
add VM_PROT_EXECUTE protection for it.

Currently, this does not change much, as page execute permission is not
enforced for i386 (except for Xen, where BIOS calls are not used anyway).
/src/doc/
H A D3RDPARTY1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
1.689 Wed Apr 22 13:31:44 GMT 2009 wiz gcc-4.4.0 out.
H A DCHANGES1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
1.689 Sat Sep 09 23:57:21 GMT 2006 riz Note addition of msk(4).
/src/distrib/sets/lists/base/
H A Dshl.mi1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
1.689 Sat Feb 08 19:17:42 GMT 2014 jmmv Update file lists for atf 0.19.

This has been tested with both MKKYUA=no (the default) and MKKYUA=yes, as
well as with a non-clean tree and a clean build. Hopefully I got the
details right... but they were tricky!
H A Dmi1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
1.689 Thu Mar 01 23:55:43 GMT 2007 martin Add dkscan_bsdlabel
/src/sys/sys/
H A Dparam.h1.689 Wed Feb 17 22:32:04 GMT 2021 christos - pass the alignment instead of the mask (as Roy asked and to match the
other macro)
- use alignof to determine that alignment and CTASSERT what we expect
- remove unused macros
1.689 Wed Feb 17 22:32:04 GMT 2021 christos - pass the alignment instead of the mask (as Roy asked and to match the
other macro)
- use alignof to determine that alignment and CTASSERT what we expect
- remove unused macros
/src/distrib/sets/lists/comp/
H A Dmi1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
1.689 Sun Mar 28 18:23:27 GMT 2004 he branches: 1.689.2;
Add entries for new include files installed by the new version of IPF.
/src/sys/arch/i386/conf/
H A DGENERIC1.689 Mon Jul 18 00:02:21 GMT 2005 augustss Add uipaq driver.
/src/distrib/sets/lists/tests/
H A Dmi1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
1.689 Sun Oct 30 16:17:16 GMT 2016 kamil Add new test t_timedmutex

This test is a clone on t_mutex with additional two tests for timed-mutex
specific block.

All simple-mutex (not with the timed property according to the C11 wording)
specific tests are covered by pthread_mutex_timedlock(3) with parameter
ts_lengthy of sufficiently large tv_sec value (right now UINT16_MAX). If,
a test will hang, it won't wait UINT16_MAX seconds, but will be terminated
within the default timeout for ATF tests (right now 300 [sec] in my
NetBSD/amd64 setup).

This test was inspired by a classic selflock test failure of
pthread_mutex_timedlock(3) of the following form:

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)
{
pthread_mutex_t mtx;
struct timespec ts;

ts.tv_sec = 0;
ts.tv_nsec = 1000;
printf("ts{.tv_sec = %d, .tv_nsec=%ld}\n", ts.tv_sec, ts.tv_nsec);
fflush(stdout);

printf("mtx_init\n");
assert(pthread_mutex_init(&mtx, NULL) == 0);

printf("mtx_lock\n");
assert(pthread_mutex_lock(&mtx) == 0);

printf("mtx_timedlock\n");
assert(pthread_mutex_timedlock(&mtx, &ts) == ETIMEDOUT);

printf("mtx_unlock\n");
assert(pthread_mutex_unlock(&mtx) == 0);

printf("mtx_destroy\n");
assert(pthread_mutex_destroy(&mtx) == 0);

return 0;
}

Current NetBSD implementation wrongly hangs on this test.

The issue was detected during development of the C11 portable threads.

My local tests in chroot presents that the are further issues:

t_timedmutex (21/25): 10 test cases
mutex1: [0.001142s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:75: *param != 20
mutex2: [0.261499s] Passed.
mutex3: [0.261496s] Passed.
mutex4: [0.001204s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:265: pthread_mutex_timedlock(&mutex, &ts_lengthy): Connection timed out
mutex5: [0.001235s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:337: pthread_mutex_timedlock(&mutex5, &ts_lengthy): Connection timed out
mutex6: [21.218497s] Failed: /usr/src/tests/lib/libpthread/t_timedmutex.c:512: start != 1
mutexattr1: [0.001328s] Passed.
mutexattr2: [0.001175s] Passed.
timedmutex1: [301.119397s] Failed: Test case timed out after 300 seconds
timedmutex2: [301.123081s] Failed: Test case timed out after 300 seconds
[623.990659s]

I'm also receiveing the same failure in the mutex6 test in t_mutex, so
there might be a false positives due to local chroot(8) issues.

Commit approved by <christos>.
/src/share/mk/
H A Dbsd.own.mk1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
1.689 Mon Oct 31 14:20:11 GMT 2011 chs switch everything except vax to gcc 4.5.
switch m68k to -Os since -O2 produces much bigger code
with gcc 4.5 than it did with gcc 4.1.
/src/distrib/sets/lists/man/
H A Dmi1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
1.689 Mon May 03 02:47:04 GMT 2004 kochi Move spic.4 from man4 to man4.i386.
/src/sys/conf/
H A Dfiles1.689 Mon Oct 04 01:07:25 GMT 2004 thorpej Move wedge code to a subdirectory, as suggested by Christos.

Completed in 10497 milliseconds