You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(36) |
Nov
(95) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(17) |
Feb
(34) |
Mar
(22) |
Apr
(54) |
May
(61) |
Jun
(14) |
Jul
(11) |
Aug
(18) |
Sep
(6) |
Oct
(3) |
Nov
(19) |
Dec
(24) |
| 2004 |
Jan
(10) |
Feb
(47) |
Mar
(15) |
Apr
(28) |
May
(72) |
Jun
(35) |
Jul
(21) |
Aug
(25) |
Sep
(14) |
Oct
(2) |
Nov
(15) |
Dec
(25) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(15) |
Apr
(11) |
May
(33) |
Jun
(17) |
Jul
(11) |
Aug
(12) |
Sep
(11) |
Oct
(8) |
Nov
(1) |
Dec
(8) |
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(44) |
Oct
(30) |
Nov
(5) |
Dec
|
| 2007 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Charles C. <cha...@gm...> - 2016-08-19 17:39:23
|
Hi guys,
I realized that my last email may be not easy to understand because all
changes are put in the same big
patch. I spend some time to refactor and split the big patch into a serious
of smaller ones. And these small
patches are organized based on features. Hope it 's much easier to
understand in this version.
We want to contribute to the community and any comments are welcome!
feature1,
use intmax_t/uintmax_t to make it compatible for different platforms. For
example, on LP32 systems some data structures like time_t could be long long
patch1, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0001_compatible_format.patch
feature2, avoid shadowing of #define constants by prefixing them with MY_
patch2, https://github.com/ycui1984/posixtestsuite/blob/master/
patches/TESTSUITE/0002_add_MY.patch
feature3, add necessary headers to enable features in netbsd
patch3, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0003_enable_features.patch
feature4, use setpgid(0, 0) instead of setpgrp() for portability across BSD
and systemV
patch4, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0004_compatible_setpgrp.patch
feature5, make use of cpuset utility provided by NetBSD
patch5, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0005_cpuset.patch
feature6, force convert to pthread_once_t to make it compilable
patch6, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0006_pthread.patch
feature7, correct compile flag
patch7, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0007_compile_flag.patch
feature8, make use of gmake
patch8, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0008_gmake.patch
feature9, add more debugging info
patch9, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0009_debugging.patch
feature10, better reporting
patch10, https://github.com/ycui1984/posixtestsuite/blob/
master/patches/TESTSUITE/0010_better_reporting.patch
2016-08-13 11:36 GMT-07:00 Charles Cui <cha...@gm...>:
> Hi posix test suite developers,
>
>
> This is Charles Cui and I am selected for this year's GSOC program.
> My project is to support posix test suite on NetBSD system under the
> guidance of Christos Zoulas. Basically, we fixed the problems of posix test
> suite when running on NetBSD, including benchmark related problems and
> NetBSD system improvements. Here is the github address of this project.
> https://github.com/ycui1984/posixtestsuite
> We have a patch of posix test suite which enables the support of NetBSD,
> https://github.com/ycui1984/posixtestsuite/blob/master/
> patches/TESTSUITE/testsuite.patch We hope this patch to be reviewed and
> be helpful to the community.
> Please let me know if there are any comments.
>
>
> Thanks, Charles.
>
|
|
From: Charles C. <cha...@gm...> - 2016-08-13 18:36:10
|
Hi posix test suite developers,
This is Charles Cui and I am selected for this year's GSOC program.
My project is to support posix test suite on NetBSD system under the
guidance of Christos Zoulas. Basically, we fixed the problems of posix test
suite when running on NetBSD, including benchmark related problems and
NetBSD system improvements. Here is the github address of this project.
https://github.com/ycui1984/posixtestsuite
We have a patch of posix test suite which enables the support of NetBSD,
https://github.com/ycui1984/posixtestsuite/blob/master/patches/TESTSUITE/testsuite.patch
We hope this patch to be reviewed and be helpful to the community.
Please let me know if there are any comments.
Thanks, Charles.
|
|
From: Jeff H. <jha...@al...> - 2012-07-04 19:15:59
|
Thanks. This is helpful. I'll try LTP. Jeff On Wed, Jul 4, 2012 at 12:53 PM, Randy Dunlap <rd...@xe...> wrote: > On 07/03/2012 12:44 PM, Jeff Hammond wrote: > >> I read the documentation - perhaps not thoroughly enough - and cannot >> figure out how to launch the tests in a cross-compile environment. >> Specifically, I am working on Blue Gene/Q, where I need to build using >> the cross compiler and launch jobs through the queue system or, at the >> very least, be able to prepend the invocation with something >> equivalent to mpirun. >> >> Is this possible? I would really like to use these tests to verify >> POSIX compliance of Blue Gene/Q. > > > Hi, > > posixtest project is dead AFAIK. It has mostly been > merged into LTP (Linux Test Project: http://ltp.sf.net). > > You could try asking your question on the ltp mailing list. > They may have fixed or modified the cross-compile interface -- > I don't know, I haven't looked .... > > -- > ~Randy > > and I'm now unsubscribing from the posixtest-discuss mailing list. -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jha...@al... / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond |
|
From: Randy D. <rd...@xe...> - 2012-07-04 18:20:57
|
On 07/03/2012 12:44 PM, Jeff Hammond wrote: > I read the documentation - perhaps not thoroughly enough - and cannot > figure out how to launch the tests in a cross-compile environment. > Specifically, I am working on Blue Gene/Q, where I need to build using > the cross compiler and launch jobs through the queue system or, at the > very least, be able to prepend the invocation with something > equivalent to mpirun. > > Is this possible? I would really like to use these tests to verify > POSIX compliance of Blue Gene/Q. Hi, posixtest project is dead AFAIK. It has mostly been merged into LTP (Linux Test Project: http://ltp.sf.net). You could try asking your question on the ltp mailing list. They may have fixed or modified the cross-compile interface -- I don't know, I haven't looked .... -- ~Randy and I'm now unsubscribing from the posixtest-discuss mailing list. |
|
From: Jeff H. <jha...@al...> - 2012-07-03 19:45:07
|
I read the documentation - perhaps not thoroughly enough - and cannot figure out how to launch the tests in a cross-compile environment. Specifically, I am working on Blue Gene/Q, where I need to build using the cross compiler and launch jobs through the queue system or, at the very least, be able to prepend the invocation with something equivalent to mpirun. Is this possible? I would really like to use these tests to verify POSIX compliance of Blue Gene/Q. Thanks, Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jha...@al... / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond |
|
From: ruizhe z. <rui...@gm...> - 2010-12-20 09:51:35
|
Hi there: At first appolagize to all for my poor English, I'm a Chinese, my name is Ruizhe Zhao, English is not my mother language, so if I stage some mess presentation, just correct it, I'll be very very very appreciating. I download the 'posixtestsuite' and run it, I fount a little mistake(in my opinion) in output format: conformance/interfaces/pthread_cond_wait/2-1: link: FAILED. Linker output: conformance/interfaces/pthread_mutex_getprioceiling/1-1: build: FAILED: Compiler output: conformance/interfaces/aio_suspend/4-1: link: FAILED. Linker output: conformance/interfaces/aio_suspend/1-1: link: FAILED. Linker output: In 'link: FAILED' lines a period (.) following the 'FAILED' not a colon (:), is this a mistake? or my mistake. I found it in the Makefile: ./Makefile:89: echo "$(@:.test=): link: FAILED. Linker output: "; \ Any suggestion is appreciated. |
|
From: Edjunior B. M. <ema...@li...> - 2008-08-11 16:15:16
|
Hi all, conformance/interfaces/timer_getoverrun/2-2 has failed on tests with some distros running on ppc64 machines. As far as I could realize, it happens due to these machines are running kernel with timer frequency configured to 100 Hz, which represents a clock precision smaller than the defined INTERVALNSEC. This patch sets the interval equals to the clock precision (retrieved via function clock_getres()), in order to avoid to use a interval smaller than the resolution of the clock. However, with these changes, this testcase becomes very similar to the test 2-3. Is this a valid modification? Any thought what should be done in this case? Thanks in advance, -- Edjunior |
|
From: Yi Xu <yx...@su...> - 2008-01-09 08:59:17
|
Hi Subrata,
Attached is the patch to pthread_create_1_6.
Thanks,
Yi
=E5=9C=A8 2008-01-09=E4=B8=89=E7=9A=84 14:13 +0530=EF=BC=8CSubrata Modak=E5=
=86=99=E9=81=93=EF=BC=9A
> Where=C5=9B the Patch ?
>=20
> --Subrata
>=20
> On Tue, 2008-01-08 at 16:29 +0100, Yi Xu wrote:
> > =E5=9C=A8 2007-12-03=E4=B8=80=E7=9A=84 13:18 +0100=EF=BC=8CPatrick Kirs=
ch=E5=86=99=E9=81=93=EF=BC=9A
> > > Hey all,
> > > I have a question on testcase pthread_create/1-1.c :
> > > there is shared variable "int *ctrl =3D (int *) arg;" in function
> > > "hp_func" which should be protected through pthread_mutex or similar,=
right?
> > > As I understand this shared variable should always be protected?
> > > So is there a reason why there are no pthread synchronisation calls?
> > >=20
> > > As you can see in the suggested temporary patch below, is it possible=
to
> > > add volatile-statement to the shared variables?
> > >=20
> > > I'm asking, because sometimes this testcase fails on s390x.
> > >=20
> > > ---
> > > testcases/open_posix_testsuite/conformance/interfaces/pthread_create/=
1-6.c
> > > +++
> > > testcases/open_posix_testsuite/conformance/interfaces/pthread_create/=
1-6.c
> > > @@ -111,7 +111,7 @@
> > >=20
> > > void * hp_func(void * arg)
> > > {
> > > - int *ctrl =3D (int *) arg;
> > > + volatile int *ctrl =3D (int *) arg;
> > > int dummy=3D0, i;
> > > do
> > > {
> > >=20
> > >=20
> > > Thanks for advice,
> >=20
> > Hi,
> >=20
> > I have also met this bug. It also happens on ia64 and x86 architectures=
.
> >=20
> > While running pthread_create_1_6, sometimes I get error like below:
> >=20
> > 15:59:26]-----
> > [15:59:26]Starting test with scenario (17): Explicit FIFO max param
> > [15:59:27]Thread has been created successfully for this scenario
> > [15:59:28]-----
> > [15:59:28]Starting test with scenario (18): Explicit RR max param
> > [15:59:28]The low priority thread executed. This might be normal if you
> > have more than 5 CPU.
> > [15:59:28]Test conformance/interfaces/pthread_create/1-6.c FAILED: Low
> > priority thread executed -- the sched parameters are ignored?
> >=20
> > (see the attachment and you can find out "ctrl" changed from 0 to 2)
> >=20
> >=20
> > Some other times it goes into infinite loop and triggers alarm clock
> > like following:
> >=20
> > [15:59:32]-----
> > [15:59:32]Starting test with scenario (16): Detached, Min stack size, 1=
p
> > guard
> > [15:59:32]Thread has been created successfully for this scenario
> > [15:59:32]-----
> > [15:59:32]Starting test with scenario (17): Explicit FIFO max param
> > [15:59:32]Thread has been created successfully for this scenario
> > Alarm clock
> >=20
> >=20
> > Would you please have a look of this bug, and Patrick's patch?
> >=20
> > Thanks,
> > Yi
> >=20
>=20
--=20
Yi Xu, QA Engineer
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=C3=BCrnberg)
|
|
From: Mike F. <va...@ge...> - 2007-12-04 04:47:14
|
On Monday 03 December 2007, Patrick Kirsch wrote: > I have a question on testcase pthread_create/1-1.c : > there is shared variable "int *ctrl =3D (int *) arg;" in function > "hp_func" which should be protected through pthread_mutex or similar, > right? As I understand this shared variable should always be protected? > So is there a reason why there are no pthread synchronisation calls? > > As you can see in the suggested temporary patch below, is it possible to > add volatile-statement to the shared variables? > > I'm asking, because sometimes this testcase fails on s390x. perhaps look at the generated assembly code and see if gcc is incorrectly=20 optimizing away memory loads ? adding volatile sounds like you're ignoring= a=20 deeper problem ... =2Dmike |
|
From: Patrick K. <pk...@su...> - 2007-12-03 12:18:10
|
Hey all,
I have a question on testcase pthread_create/1-1.c :
there is shared variable "int *ctrl = (int *) arg;" in function
"hp_func" which should be protected through pthread_mutex or similar, right?
As I understand this shared variable should always be protected?
So is there a reason why there are no pthread synchronisation calls?
As you can see in the suggested temporary patch below, is it possible to
add volatile-statement to the shared variables?
I'm asking, because sometimes this testcase fails on s390x.
---
testcases/open_posix_testsuite/conformance/interfaces/pthread_create/1-6.c
+++
testcases/open_posix_testsuite/conformance/interfaces/pthread_create/1-6.c
@@ -111,7 +111,7 @@
void * hp_func(void * arg)
{
- int *ctrl = (int *) arg;
+ volatile int *ctrl = (int *) arg;
int dummy=0, i;
do
{
Thanks for advice,
--
Patrick Kirsch - Quality Assurance Department
SUSE Linux Products GmbH GF: Markus Rex, HRB 16746 (AG Nuernberg)
|
|
From: Patrick K. <pk...@su...> - 2007-10-09 12:54:02
|
Patrick Kirsch wrote: > Can you add the parameter "-D_FORTIFY_SOURCE=2" as a standard for > compiling posix-testcases? > > FORTIFY_SOURCE is a Glibc feature which adds memory and string function > protection. There is no home site for this feature, but it is described > well on this page: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html > > With FORTIFY_SOURCE option compiling, I saw a lot testcases segfaulting, > due to too short char array, see attached patch (they all have the same > problem, the former char array size of 20 iss too short, if the PID is > randomly too large). So what about default compiling with FORTIFY_SOURCE=2 ? Do you add the patch for next version? Regards, -- Patrick Kirsch - Quality Assurance Department SUSE Linux Products GmbH GF: Markus Rex, HRB 16746 (AG Nuernberg) |
|
From: Mike F. <va...@ge...> - 2007-09-24 11:25:43
|
On Monday 24 September 2007, Patrick Kirsch wrote: > -=A0=A0=A0=A0=A0=A0=A0char semname[20]; > +=A0=A0=A0=A0=A0=A0=A0char semname[28]; > =A0 > =A0=A0=A0=A0=A0=A0=A0=A0sprintf(semname, "/" FUNCTION "_" TEST "_%d", get= pid()); which probably mostly works today, but who knows tomorrow ... probably a lo= ng=20 term solution would be to have a common init function and move this same=20 logic there ... =2Dmike |
|
From: Patrick K. <pk...@su...> - 2007-09-24 11:15:30
|
Hey, Can you add the parameter "-D_FORTIFY_SOURCE=2" as a standard for compiling posix-testcases? FORTIFY_SOURCE is a Glibc feature which adds memory and string function protection. There is no home site for this feature, but it is described well on this page: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html With FORTIFY_SOURCE option compiling, I saw a lot testcases segfaulting, due to too short char array, see attached patch (they all have the same problem, the former char array size of 20 iss too short, if the PID is randomly too large). Regards, -- Patrick Kirsch - Quality Assurance Department SUSE Linux Products GmbH GF: Markus Rex, HRB 16746 (AG Nuernberg) |
|
From: Thomas S. <tsc...@gn...> - 2007-08-02 13:57:58
|
Hello! To whom it may concern: the link to the ``List Archives'' on <http://posixtest.sourceforge.net/> is pointing to the scummvm-devel list. I gather that the Open POSIX Test Suite does not contain tests for fifo (named pipe) implementations, right? Does someone by chance know about a test suite for those? Does someone have mbox files of this list, posixtest-discuss? The sourceforge.net mailing list archive's web interface is a real pain to use... Regards, Thomas |
|
From: Fu, E. <el...@in...> - 2007-07-05 06:32:14
|
Thank you very much! I will check in PTS after I verified the patch.=20
Thanks
Elva Fu
-----Original Message-----
From: pos...@li... =
[mailto:pos...@li...] On Behalf Of =
Joseph S. Myers
Sent: 2007=C4=EA6=D4=C228=C8=D5 9:12
To: pos...@li...
Subject: [posixtest-discuss] Miscellaneous test harness fixes
This patch fixes some miscellaneous issues I've found in Open POSIX=20
testing.
- On 64-bit Power, function symbols point to function descriptors rather =
than directly to the function code, so the nm command must accept "main" =
being a data symbol.
- If a test gets killed with SIGINT, bash (possibly depending on how =
it's=20
configured) can interpret this as the user pressing Ctrl-C to interrupt=20
the whole script and so will exit after that test; running tests from=20
execute.sh in a separate shell command avoid this.
- Redirecting output from functional tests to separate files (a) yields=20
cleaner output from the functional tests and (b) helps avoid problems=20
where a test fails to terminate properly and that test ends up writing =
to=20
the same stdout as used by the rest of the test process carrying on =
after=20
the test failed to terminate properly.
Index: Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/posixtest/posixtestsuite/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile 15 May 2006 07:49:03 -0000 1.30
+++ Makefile 28 Jun 2007 01:01:54 -0000
@@ -79,7 +79,7 @@
%.test: %.o
@COMPLOG=3D$(LOGFILE).$$$$; \
[ -f $< ] || exit 0; \
- { nm -g $< | grep -q " T main"; } || \
+ { nm -g $< | grep -q " [DT] main"; } || \
{ echo "$(@:.test=3D): link: SKIP" | tee -a $(LOGFILE) && exit 0; }; \
if $(CC) $(CFLAGS) $< -o $@ $(LDFLAGS) > $$COMPLOG 2>&1; \
then \
Index: execute.sh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/posixtest/posixtestsuite/execute.sh,v
retrieving revision 1.2
diff -u -r1.2 execute.sh
--- execute.sh 15 May 2006 07:49:03 -0000 1.2
+++ execute.sh 28 Jun 2007 01:01:54 -0000
@@ -233,7 +233,7 @@
then
FILEcut=3D`echo $FILE | cut -b3-80`
TOTAL=3D$TOTAL+1
- ./t0 $TIMEOUT_VAL $FILE > /dev/null 2>&1
+ sh -c "./t0 $TIMEOUT_VAL $FILE > /dev/null 2>&1"
=20
RET_VAL=3D$?
=20
Index: functional/mqueues/run.sh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/posixtest/posixtestsuite/functional/mqueues/run.sh,v
retrieving revision 1.1
diff -u -r1.1 run.sh
--- functional/mqueues/run.sh 28 Jan 2003 07:36:53 -0000 1.1
+++ functional/mqueues/run.sh 28 Jun 2007 01:02:03 -0000
@@ -12,7 +12,7 @@
{
echo "TEST: " $1
TOTAL=3D$TOTAL+1
- ./$1
+ ./$1 > $1.output 2>&1
if [ $? =3D=3D 0 ]; then
PASS=3D$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/semaphores/run.sh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: =
/cvsroot/posixtest/posixtestsuite/functional/semaphores/run.sh,v
retrieving revision 1.2
diff -u -r1.2 run.sh
--- functional/semaphores/run.sh 28 Jan 2003 07:57:02 -0000 1.2
+++ functional/semaphores/run.sh 28 Jun 2007 01:02:03 -0000
@@ -12,7 +12,7 @@
{
echo "TEST: " $1
TOTAL=3D$TOTAL+1
- ./$1
+ ./$1 > $1.output 2>&1
if [ $? =3D=3D 0 ]; then
PASS=3D$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/threads/pi_test/run.sh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: =
/cvsroot/posixtest/posixtestsuite/functional/threads/pi_test/run.sh,v
retrieving revision 1.3
diff -u -r1.3 run.sh
--- functional/threads/pi_test/run.sh 20 Jun 2003 09:59:46 -0000 1.3
+++ functional/threads/pi_test/run.sh 28 Jun 2007 01:02:03 -0000
@@ -21,7 +21,7 @@
{
echo "TEST: " $1
TOTAL=3D$TOTAL+1
- ./$1 > output.$1
+ ./$1 > output.$1 2>&1
if [ $? =3D=3D 0 ]; then
PASS=3D$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/threads/robust_test/run.sh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: =
/cvsroot/posixtest/posixtestsuite/functional/threads/robust_test/run.sh,v=
retrieving revision 1.1
diff -u -r1.1 run.sh
--- functional/threads/robust_test/run.sh 30 May 2003 21:33:04 -0000 1.1
+++ functional/threads/robust_test/run.sh 28 Jun 2007 01:02:03 -0000
@@ -7,7 +7,7 @@
{
echo "TEST: " $1
TOTAL=3D$TOTAL+1
- ./$1
+ ./$1 > $1.output 2>&1
if [ $? =3D=3D 0 ]; then
PASS=3D$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/timers/run.sh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/posixtest/posixtestsuite/functional/timers/run.sh,v
retrieving revision 1.2
diff -u -r1.2 run.sh
--- functional/timers/run.sh 9 Jan 2003 22:11:16 -0000 1.2
+++ functional/timers/run.sh 28 Jun 2007 01:02:03 -0000
@@ -11,7 +11,7 @@
RunTest()
{
echo "TEST: " $1
- $1
+ $1 > $1.output 2>&1
if [ $? =3D=3D 0 ]; then
PASS=3D$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
--=20
Joseph S. Myers
jo...@co...
-------------------------------------------------------------------------=
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
posixtest-discuss mailing list
pos...@li...
https://lists.sourceforge.net/lists/listinfo/posixtest-discuss
|
|
From: Joseph S. M. <jo...@co...> - 2007-06-28 01:12:11
|
This patch fixes some miscellaneous issues I've found in Open POSIX
testing.
- On 64-bit Power, function symbols point to function descriptors rather
than directly to the function code, so the nm command must accept "main"
being a data symbol.
- If a test gets killed with SIGINT, bash (possibly depending on how it's
configured) can interpret this as the user pressing Ctrl-C to interrupt
the whole script and so will exit after that test; running tests from
execute.sh in a separate shell command avoid this.
- Redirecting output from functional tests to separate files (a) yields
cleaner output from the functional tests and (b) helps avoid problems
where a test fails to terminate properly and that test ends up writing to
the same stdout as used by the rest of the test process carrying on after
the test failed to terminate properly.
Index: Makefile
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile 15 May 2006 07:49:03 -0000 1.30
+++ Makefile 28 Jun 2007 01:01:54 -0000
@@ -79,7 +79,7 @@
%.test: %.o
@COMPLOG=$(LOGFILE).$$$$; \
[ -f $< ] || exit 0; \
- { nm -g $< | grep -q " T main"; } || \
+ { nm -g $< | grep -q " [DT] main"; } || \
{ echo "$(@:.test=): link: SKIP" | tee -a $(LOGFILE) && exit 0; }; \
if $(CC) $(CFLAGS) $< -o $@ $(LDFLAGS) > $$COMPLOG 2>&1; \
then \
Index: execute.sh
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/execute.sh,v
retrieving revision 1.2
diff -u -r1.2 execute.sh
--- execute.sh 15 May 2006 07:49:03 -0000 1.2
+++ execute.sh 28 Jun 2007 01:01:54 -0000
@@ -233,7 +233,7 @@
then
FILEcut=`echo $FILE | cut -b3-80`
TOTAL=$TOTAL+1
- ./t0 $TIMEOUT_VAL $FILE > /dev/null 2>&1
+ sh -c "./t0 $TIMEOUT_VAL $FILE > /dev/null 2>&1"
RET_VAL=$?
Index: functional/mqueues/run.sh
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/functional/mqueues/run.sh,v
retrieving revision 1.1
diff -u -r1.1 run.sh
--- functional/mqueues/run.sh 28 Jan 2003 07:36:53 -0000 1.1
+++ functional/mqueues/run.sh 28 Jun 2007 01:02:03 -0000
@@ -12,7 +12,7 @@
{
echo "TEST: " $1
TOTAL=$TOTAL+1
- ./$1
+ ./$1 > $1.output 2>&1
if [ $? == 0 ]; then
PASS=$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/semaphores/run.sh
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/functional/semaphores/run.sh,v
retrieving revision 1.2
diff -u -r1.2 run.sh
--- functional/semaphores/run.sh 28 Jan 2003 07:57:02 -0000 1.2
+++ functional/semaphores/run.sh 28 Jun 2007 01:02:03 -0000
@@ -12,7 +12,7 @@
{
echo "TEST: " $1
TOTAL=$TOTAL+1
- ./$1
+ ./$1 > $1.output 2>&1
if [ $? == 0 ]; then
PASS=$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/threads/pi_test/run.sh
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/functional/threads/pi_test/run.sh,v
retrieving revision 1.3
diff -u -r1.3 run.sh
--- functional/threads/pi_test/run.sh 20 Jun 2003 09:59:46 -0000 1.3
+++ functional/threads/pi_test/run.sh 28 Jun 2007 01:02:03 -0000
@@ -21,7 +21,7 @@
{
echo "TEST: " $1
TOTAL=$TOTAL+1
- ./$1 > output.$1
+ ./$1 > output.$1 2>&1
if [ $? == 0 ]; then
PASS=$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/threads/robust_test/run.sh
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/functional/threads/robust_test/run.sh,v
retrieving revision 1.1
diff -u -r1.1 run.sh
--- functional/threads/robust_test/run.sh 30 May 2003 21:33:04 -0000 1.1
+++ functional/threads/robust_test/run.sh 28 Jun 2007 01:02:03 -0000
@@ -7,7 +7,7 @@
{
echo "TEST: " $1
TOTAL=$TOTAL+1
- ./$1
+ ./$1 > $1.output 2>&1
if [ $? == 0 ]; then
PASS=$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
Index: functional/timers/run.sh
===================================================================
RCS file: /cvsroot/posixtest/posixtestsuite/functional/timers/run.sh,v
retrieving revision 1.2
diff -u -r1.2 run.sh
--- functional/timers/run.sh 9 Jan 2003 22:11:16 -0000 1.2
+++ functional/timers/run.sh 28 Jun 2007 01:02:03 -0000
@@ -11,7 +11,7 @@
RunTest()
{
echo "TEST: " $1
- $1
+ $1 > $1.output 2>&1
if [ $? == 0 ]; then
PASS=$PASS+1
echo -ne "\t\t\t***TEST PASSED***\n\n"
--
Joseph S. Myers
jo...@co...
|
|
From: Randy D. <rd...@xe...> - 2007-06-14 03:37:41
|
Hi, I often want to see a quick summary (SCORE) of an open POSIX test suite full run without having to read the log file, so I wrote a small script to provide a SCORE (0 - 100) of a test run. The script is attached in case anyone finds it as useful as I do. Example (from linux-2.6.22-rc4-git5 on x86_64): Using logfile=logfile build errors: 13 files, 31 lines PASS: 1715 FAILED: 39 UNTESTED: 95 UNRESOLVED: 10 UNSUPPORTED: 22 INTERRUPTED: 7 SCORE: 91 Regards, --- ~Randy |
|
From: Fu, E. <el...@in...> - 2007-04-17 18:09:47
|
I don't think so. it just seems most user interest in the conformance = test more. ________________________________ From: pos...@li... = [mailto:pos...@li...] On Behalf Of = Riaz Rahaman Sent: 2007=C4=EA4=D4=C28=C8=D5 16:27 To: pos...@li... Subject: [posixtest-discuss] are functional, stress,performance & = speculative tests used? Has any one in the list run the open-posix- tests i.e Conformance, = Functional, Stress, Performance, and Speculative categories under open = posix? >From what I can make out from the home page under the implementation is = that only Conformance test is being used as of now , performance = testcase were never used, functional & stress are prototypes and = speculative tests are quite a recent idea.=20 Is the above information right or is it quite dated? --=20 Regards, Riaz Ur Rahaman=20 |
|
From: Riaz R. <rah...@gm...> - 2007-04-08 08:27:20
|
Has any one in the list run the open-posix- tests i.e *Conformance*, * Functional*, *Stress*, *Performance*, and *Speculative* categories under open posix? >From what I can make out from the home page under the implementation is that only Conformance test is being used as of now , performance testcase were never used, functional & stress are prototypes and speculative tests are quite a recent idea. Is the above information right or is it quite dated? -- Regards, Riaz Ur Rahaman |
|
From: Fu, E. <el...@in...> - 2007-03-21 08:07:16
|
The patch was checked in. Thank you very much! Elva Fu=20 -----Original Message----- From: pos...@li... = [mailto:pos...@li...] On Behalf Of = Will Newton Sent: 2007=C4=EA3=D4=C215=C8=D5 23:36 To: pos...@li... Subject: [posixtest-discuss] [PATCH] Building PTS with gcc 2.95.2 Hi all, I ran into a few issues with building PTS with an older gcc. I have attached patches to fix most of them, around 90%. There should be no functionality changes, just code reorganization. |
|
From: Will N. <wil...@gm...> - 2007-03-15 15:36:24
|
Hi all, I ran into a few issues with building PTS with an older gcc. I have attached patches to fix most of them, around 90%. There should be no functionality changes, just code reorganization. |
|
From: Fu, E. <el...@in...> - 2007-03-01 02:25:14
|
Hi xiaoxiao, Welcome to posixtestsuite world:-) For semaphore function testing, did you check whether NPTL is installed = as default posix thread library at your side? if so, you can use = '-lpthread' and '-lrt' flags. Otherwise, to build against NPTL, export = the following variable: export GLIBCDIR=3D/path/to/NPTL/libc-build Then in LDFLAGS, add the following lines:=20 $GLIBCDIR/nptl/libpthread.so.0 $GLIBCDIR/libc.so.6 = -Wl,-rpath,$GLIBCDIR:$GLIBCDIR/nptl:$GLIBCDIR/elf,-dynamic-linker,$GLIBCD= IR/elf/ld-linux.so.2 If you want to run the semaphore test suite against posix1b (downloading = it from: http://www.garret.ru/~knizhnik/posix1b.tar.gz = <http://www.garret.ru/~knizhnik/posix1b.tar.gz> ), then you should have = the library compiled and installed in /usr/lib first. It seems you = already did so. That's fine. Then add the following library in the = LDFLAGS:=20 -lposix1b Make sure /usr/lib/ is in your PATH. For more info about how to BUILD and run test suite, you can refer to = BUILD and Document/HOWTO_*** documents within posixtestsuite.=20 If you want to run the whole testsuite, I suggest you logged as root, = since some build needs root privileges.=20 =20 Any problem, feel free to let me know. =20 Elva Fu ________________________________ From: Xiaoxiao Cui (xcui) [mailto:xc...@ci...]=20 Sent: 2007=C4=EA3=D4=C21=C8=D5 9:22 To: el...@us...; li...@us...; = ro...@us... Cc: Sri Dharmasanam (sdharmas) Subject: PTS question about semaphore test Hi, PTS project admins, Currently we are trying to use PTS to evaluate our linux kernel upgrade. = When we test semaphore function under conformance/interfaces. We got one = issue. If we put -lpthread in LDFLAGS, we got error as "sem_open: = function not implemented". But if we remove it the linker seems to find = the posix1b lib that we have built. Also some of the tests seem to = require root privileges. Is it required that we be logged in as root on = the system where we run these tests? Thanks a lot in advance. Xiaoxiao |
|
From: Fu, E. <el...@in...> - 2007-01-23 03:42:57
|
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBvc2l4dGVzdC1kaXNjdXNzLWJvdW5j ZXNAbGlzdHMuc291cmNlZm9yZ2UubmV0IFttYWlsdG86cG9zaXh0ZXN0LWRpc2N1c3MtYm91bmNl c0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdIE9uIEJlaGFsZiBPZiBTqKZiYXN0aWVuIER1Z3Wopg0K U2VudDogMjAwNsTqN9TCNcjVIDIxOjU1DQpUbzogcG9zaXh0ZXN0LWRpc2N1c3NAbGlzdHMuc291 cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBbcG9zaXh0ZXN0LWRpc2N1c3NdIE1ha2UgdGhlIGFpb19y ZWFkL3dyaXRlIHRlc3RzIGNvbmNlcm5pbmcgdGhlIG9mZnNldCBtYXhpbXVtIHJldHVybiBQVFNf VU5URVNURUQNCg0KDQogIEhpIGFsbCwNCg0KICBUaGUgZm9sbG93aW5nIHRlc3RzOg0KDQoJYWlv X3JlYWQvNi0xLmMNCglhaW9fcmVhZC8xNS0xLmMNCglhaW9fd3JpdGUvNC0xLmMNCglhaW9fd3Jp dGUvMTMtMS5jDQoNCiAgYXJlIHdyb25nLg0KDQogIEkgbWlzdGFrZW5seSB0b29rIHRoZSBvZmZz ZXQgbWF4aW11bSBhc3NvY2lhdGVkIHdpdGggYSBmaWxlIGRlc2NyaXB0b3INCnRvIGJlIHRoZSBs aW1pdCBzZXQgYnkgc2V0cmxpbWl0KFJMSU1JVF9GU0laRSwgLi4uKSB3aGljaCBpcyBwbGFpbg0K d3JvbmcuDQoNCiAgVGhpcyBwYXRjaCByZXZlcnRzIHRvIHRoZSBvcmlnaW5hbCBiZWhhdmlvdXIg d2hpY2ggd2FzIHRvIHJldHVybiANClBUU19VTlRFU1RFRC4gSSBkb24ndCB0aGluayB0aGlzIHBh cnQgb2YgdGhlIFBPU0lYIHNwZWNpZmljYXRpb24NCmlzIHRlc3RhYmxlLCBidXQgSSBtYXkgYmUg d3JvbmcuDQoNCiAgU6imYmFzdGllbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICBTqKZiYXN0aWVuIER1Z3WopiAgICAgICAgICAg ICAgICBCVUxML0ZSRUM6QjEtMjQ3DQogIHBob25lOiAoKzMzKSA0NzYgMjkgNzcgNzAgICAgICBC dWxsY29tOiAyMjktNzc3MA0KDQogIG1haWx0bzpzZWJhc3RpZW4uZHVndWVAYnVsbC5uZXQNCg0K ICBMaW51eCBQT1NJWCBBSU86IGh0dHA6Ly93d3cuYnVsbG9wZW5zb3VyY2Uub3JnL3Bvc2l4DQog ICAgICAgICAgICAgICAgICAgaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9wYWlvbA0K ICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkluZGV4OiBwb3NpeHRlc3RzdWl0ZS9jb25mb3JtYW5jZS9pbnRlcmZhY2VzL2Fpb19yZWFk LzE1LTEuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9jdnNyb290L3Bvc2l4dGVzdC9wb3NpeHRl c3RzdWl0ZS9jb25mb3JtYW5jZS9pbnRlcmZhY2VzL2Fpb19yZWFkLzE1LTEuYyx2DQpyZXRyaWV2 aW5nIHJldmlzaW9uIDEuMw0KZGlmZiAtVTMgLXIxLjMgMTUtMS5jDQotLS0gcG9zaXh0ZXN0c3Vp dGUvY29uZm9ybWFuY2UvaW50ZXJmYWNlcy9haW9fcmVhZC8xNS0xLmMJMiBKdW4gMjAwNSAxMDo0 OTo0OSAtMDAwMAkxLjMNCisrKyBwb3NpeHRlc3RzdWl0ZS9jb25mb3JtYW5jZS9pbnRlcmZhY2Vz L2Fpb19yZWFkLzE1LTEuYwk1IEp1bCAyMDA2IDEzOjMxOjUwIC0wMDAwDQpAQCAtMTUsMjYgKzE1 LDE3IEBADQogICoNCiAgKiBtZXRob2Q6DQogICoNCi0gKgktIHdyaXRlIEJVRl9TSVpFIGJ5dGVz IHRvIGEgZmlsZQ0KLSAqCS0gZHJvcCBSTElNSVRfRlNJWkUgdG8gQlVGX1NJWkUvMg0KLSAqCS0g cmVhZCBCVUZfU0laRS8yIGJ5dGVzIGF0IG9mZnNldCBCVUZfU0laRS8yDQotICoJLSBjaGVjayBl cnJvciBjb2RlDQorICoJVU5URVNURUQNCiAgKg0KICAqLw0KIA0KICNkZWZpbmUgX1hPUEVOX1NP VVJDRSA2MDANCiAjaW5jbHVkZSA8c3RkaW8uaD4NCiAjaW5jbHVkZSA8dW5pc3RkLmg+DQotI2lu Y2x1ZGUgPHN0cmluZy5oPg0KLSNpbmNsdWRlIDxlcnJuby5oPg0KLSNpbmNsdWRlIDxzdGRsaWIu aD4NCi0jaW5jbHVkZSA8c3lzL3Jlc291cmNlLmg+DQogI2luY2x1ZGUgPGFpby5oPg0KIA0KICNp bmNsdWRlICJwb3NpeHRlc3QuaCINCiANCi0jZGVmaW5lIFROQU1FICJhaW9fcmVhZC8xNS0xLmMi DQotDQogaW50IG1haW4oKQ0KIHsNCiAJY2hhciB0bXBmbmFtZVsyNTZdOw0KQEAgLTQ4LDc0ICsz OSw1IEBADQogCWV4aXQoUFRTX1VOU1VQUE9SVEVEKTsNCiAjZW5kaWYNCiANCi0Jc25wcmludGYo dG1wZm5hbWUsIHNpemVvZih0bXBmbmFtZSksICIvdG1wL3B0c19haW9fd3JpdGVfMTNfMV8lZCIs IA0KLQkJICBnZXRwaWQoKSk7DQotCXVubGluayh0bXBmbmFtZSk7DQotCWZkID0gb3Blbih0bXBm bmFtZSwgT19DUkVBVCB8IE9fUkRXUiB8IE9fRVhDTCwNCi0JCSAgU19JUlVTUiB8IFNfSVdVU1Ip Ow0KLQlpZiAoZmQgPT0gLTEpDQotCXsNCi0JCXByaW50ZihUTkFNRSAiIEVycm9yIGF0IG9wZW4o KTogJXNcbiIsDQotCQkgICAgICAgc3RyZXJyb3IoZXJybm8pKTsNCi0JCWV4aXQoUFRTX1VOUkVT T0xWRUQpOw0KLQl9DQotDQotCXVubGluayh0bXBmbmFtZSk7DQotDQotCWlmICh3cml0ZShmZCwg YnVmLCBCVUZfU0laRSkgIT0gQlVGX1NJWkUpDQotCXsNCi0JCXByaW50ZihUTkFNRSAiIEVycm9y IGF0IHdyaXRlKCk6ICVzXG4iLA0KLQkJICAgICAgIHN0cmVycm9yKGVycm5vKSk7DQotCQljbG9z ZShmZCk7DQotCQlleGl0KFBUU19VTlJFU09MVkVEKTsNCi0JfQ0KLQ0KLQkvKiBTZXQgZmlsZSBz aXplIHNvZnQgbGltaXQgdG8gNTEyICovDQotCWdldHJsaW1pdChSTElNSVRfRlNJWkUgLCAmbGlt aXQpOw0KLQ0KLQlsaW1pdC5ybGltX2N1ciA9IEJVRl9TSVpFIC8gMjsNCi0NCi0JaWYgKHNldHJs aW1pdChSTElNSVRfRlNJWkUgLCAmbGltaXQpID09IC0xKQ0KLQl7DQotCQlwcmludGYoVE5BTUUg IiBFcnJvciBhdCBzZXRsaW1pdCgpOiAlc1xuIiwNCi0JCSAgICAgICBzdHJlcnJvcihlcnJubykp Ow0KLQkJZXhpdChQVFNfVU5SRVNPTFZFRCk7DQotCX0NCi0NCi0JLyogdHJ5IHRvIHJlYWQgQlVG X1NJWkUvMiBieXRlcyBhdCBvZmZzZXQgQlVGX1NJWkUvMiAqLw0KLQltZW1zZXQoJmFpb2NiLCAw LCBzaXplb2Yoc3RydWN0IGFpb2NiKSk7DQotCWFpb2NiLmFpb19maWxkZXMgPSBmZDsNCi0JYWlv Y2IuYWlvX2J1ZiA9IGJ1ZjsNCi0JYWlvY2IuYWlvX25ieXRlcyA9IEJVRl9TSVpFLzI7DQotCWFp b2NiLmFpb19vZmZzZXQgPSBCVUZfU0laRS8yOw0KLQ0KLQlpZiAoYWlvX3JlYWQoJmFpb2NiKSAh PSAtMSkNCi0Jew0KLQkJd2hpbGUgKGFpb19lcnJvciAoJmFpb2NiKSA9PSBFSU5QUk9HUkVTUyk7 DQotDQotCQlpbnQgZXJyID0gYWlvX2Vycm9yICgmYWlvY2IpOw0KLQkJaW50IHJldCA9IGFpb19y ZXR1cm4gKCZhaW9jYik7DQotDQotCQlpZiAocmV0ICE9IC0xKSB7DQotCQkJcHJpbnRmKFROQU1F ICIgYmFkIGFpb19yZWFkIHJldHVybiB2YWx1ZVxuIik7DQotCQkJY2xvc2UgKGZkKTsNCi0JCQll eGl0KFBUU19GQUlMKTsNCi0JCX0gZWxzZSBpZiAoZXJyICE9IEVPVkVSRkxPVykgew0KLQkJCXBy aW50ZihUTkFNRSAiIGVycm9yIGNvZGUgaXMgbm90IEVPVkVSRkxPVyAlc1xuIiwgc3RyZXJyb3Io ZXJybm8pKTsNCi0JCQljbG9zZSAoZmQpOw0KLQkJCWV4aXQoUFRTX0ZBSUwpOw0KLQkJfQ0KLQl9 ICBlbHNlIHsNCi0NCi0JCWlmIChlcnJubyAhPSBFT1ZFUkZMT1cpDQotCQl7DQotCQkJcHJpbnRm KFROQU1FICIgZXJybm8gaXMgbm90IEVPVkVSRkxPVyAlc1xuIiwgc3RyZXJyb3IoZXJybm8pKTsN Ci0JCQljbG9zZShmZCk7DQotCQkJZXhpdChQVFNfRkFJTCk7DQotCQl9DQotCX0NCi0NCi0JY2xv c2UoZmQpOw0KLQlwcmludGYgKCJUZXN0IFBBU1NFRFxuIik7DQotCXJldHVybiBQVFNfUEFTUzsN CisJcmV0dXJuIFBUU19VTlRFU1RFRDsNCiB9DQpJbmRleDogcG9zaXh0ZXN0c3VpdGUvY29uZm9y bWFuY2UvaW50ZXJmYWNlcy9haW9fcmVhZC82LTEuYw0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9j dnNyb290L3Bvc2l4dGVzdC9wb3NpeHRlc3RzdWl0ZS9jb25mb3JtYW5jZS9pbnRlcmZhY2VzL2Fp b19yZWFkLzYtMS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zDQpkaWZmIC1VMyAtcjEuMyA2 LTEuYw0KLS0tIHBvc2l4dGVzdHN1aXRlL2NvbmZvcm1hbmNlL2ludGVyZmFjZXMvYWlvX3JlYWQv Ni0xLmMJMiBKdW4gMjAwNSAxMDo0OTo0OSAtMDAwMAkxLjMNCisrKyBwb3NpeHRlc3RzdWl0ZS9j b25mb3JtYW5jZS9pbnRlcmZhY2VzL2Fpb19yZWFkLzYtMS5jCTUgSnVsIDIwMDYgMTM6MzE6NTAg LTAwMDANCkBAIC0xNSwxMjUgKzE1LDIzIEBADQogICoNCiAgKiBtZXRob2Q6DQogICoNCi0gKgkt IG9wZW4gZmlsZQ0KLSAqCS0gd3JpdGUgMTAyNCBieXRlcyB1c2luZyBhaW9fd3JpdGUNCi0gKgkt IFNldCBSTElNSVRfRlNJWkUgdG8gNTEyDQotICoJLSB0cnkgdG8gcmVhZCAxMDI0IGJ5dGVzIHVz aW5nIGFpb19yZWFkDQotICoJLSBjaGVjayB0aGF0IG9ubHkgNTEyIGJ5dGVzIHdlcmUgcmVhZA0K KyAqCVVOVEVTVEVEDQogICoNCiAgKi8NCiANCiAjZGVmaW5lIF9YT1BFTl9TT1VSQ0UgNjAwDQog I2luY2x1ZGUgPHN0ZGlvLmg+DQogI2luY2x1ZGUgPHVuaXN0ZC5oPg0KLSNpbmNsdWRlIDxzdHJp bmcuaD4NCi0jaW5jbHVkZSA8ZXJybm8uaD4NCi0jaW5jbHVkZSA8c3RkbGliLmg+DQotI2luY2x1 ZGUgPHN5cy9yZXNvdXJjZS5oPg0KICNpbmNsdWRlIDxhaW8uaD4NCiANCiAjaW5jbHVkZSAicG9z aXh0ZXN0LmgiDQogDQotI2RlZmluZSBUTkFNRSAiYWlvX3JlYWQvNi0xLmMiDQotDQogaW50IG1h aW4oKQ0KIHsNCi0JY2hhciB0bXBmbmFtZVsyNTZdOw0KLSNkZWZpbmUgQlVGX1NJWkUgMTAyNA0K LQljaGFyIGJ1ZltCVUZfU0laRV07DQotCWNoYXIgY2hlY2tbQlVGX1NJWkVdOw0KLQlpbnQgZmQ7 DQotCXN0cnVjdCBhaW9jYiBhaW9jYjsNCi0Jc3RydWN0IHJsaW1pdCBsaW1pdDsNCi0JaW50IGVy cjsNCi0JaW50IHJldDsNCiANCiAjaWYgX1BPU0lYX0FTWU5DSFJPTk9VU19JTyAhPSAyMDAxMTJM DQogCWV4aXQoUFRTX1VOU1VQUE9SVEVEKTsNCiAjZW5kaWYNCiANCi0Jc25wcmludGYodG1wZm5h bWUsIHNpemVvZih0bXBmbmFtZSksICIvdG1wL3B0c19haW9fd3JpdGVfNF8xXyVkIiwgDQotCQkg IGdldHBpZCgpKTsNCi0JdW5saW5rKHRtcGZuYW1lKTsNCi0JZmQgPSBvcGVuKHRtcGZuYW1lLCBP X0NSRUFUIHwgT19SRFdSIHwgT19FWENMLA0KLQkJICBTX0lSVVNSIHwgU19JV1VTUik7DQotCWlm IChmZCA9PSAtMSkNCi0Jew0KLQkJcHJpbnRmKFROQU1FICIgRXJyb3IgYXQgb3BlbigpOiAlc1xu IiwNCi0JCSAgICAgICBzdHJlcnJvcihlcnJubykpOw0KLQkJZXhpdChQVFNfVU5SRVNPTFZFRCk7 DQotCX0NCi0NCi0JdW5saW5rKHRtcGZuYW1lKTsNCi0NCi0JbWVtc2V0KGJ1ZiwgMHhhYSwgQlVG X1NJWkUpOw0KLQ0KLQlpZiAod3JpdGUoZmQsIGJ1ZiwgQlVGX1NJWkUpICE9IEJVRl9TSVpFKQ0K LQl7DQotCQlwcmludGYoVE5BTUUgIiBFcnJvciBhdCB3cml0ZSgpOiAlc1xuIiwNCi0JCSAgICAg ICBzdHJlcnJvcihlcnJubykpOw0KLQkJZXhpdChQVFNfVU5SRVNPTFZFRCk7DQotCX0NCi0NCi0J LyogU2V0IGZpbGUgc2l6ZSBzb2Z0IGxpbWl0IHRvIDUxMiAqLw0KLQlnZXRybGltaXQoUkxJTUlU X0ZTSVpFICwgJmxpbWl0KTsNCi0NCi0JbGltaXQucmxpbV9jdXIgPSBCVUZfU0laRSAvIDI7DQot DQotCWlmIChzZXRybGltaXQoUkxJTUlUX0ZTSVpFICwgJmxpbWl0KSA9PSAtMSkNCi0Jew0KLQkJ cHJpbnRmKFROQU1FICIgRXJyb3IgYXQgc2V0bGltaXQoKTogJXNcbiIsDQotCQkgICAgICAgc3Ry ZXJyb3IoZXJybm8pKTsNCi0JCWV4aXQoUFRTX1VOUkVTT0xWRUQpOw0KLQl9DQotDQotCW1lbXNl dChjaGVjaywgMCwgQlVGX1NJWkUpOw0KLQltZW1zZXQoJmFpb2NiLCAwLCBzaXplb2Yoc3RydWN0 IGFpb2NiKSk7DQotCWFpb2NiLmFpb19maWxkZXMgPSBmZDsNCi0JYWlvY2IuYWlvX2J1ZiA9IGNo ZWNrOw0KLQlhaW9jYi5haW9fbmJ5dGVzID0gQlVGX1NJWkU7DQotDQotCWlmIChhaW9fcmVhZCgm YWlvY2IpID09IC0xKQ0KLQl7DQotCQlwcmludGYoVE5BTUUgIiBFcnJvciBhdCBhaW9fcmVhZCgp OiAlc1xuIiwNCi0JCSAgICAgICBzdHJlcnJvcihlcnJubykpOw0KLQkJZXhpdChQVFNfRkFJTCk7 DQotCX0NCi0NCi0JLyogV2FpdCB1bnRpbCBlbmQgb2YgdHJhbnNhY3Rpb24gKi8NCi0Jd2hpbGUg KChlcnIgPSBhaW9fZXJyb3IgKCZhaW9jYikpID09IEVJTlBST0dSRVNTKTsNCi0NCi0JZXJyID0g YWlvX2Vycm9yKCZhaW9jYik7DQotCXJldCA9IGFpb19yZXR1cm4oJmFpb2NiKTsNCi0NCi0JaWYg KGVyciAhPSAwKQ0KLQl7DQotCQlwcmludGYoVE5BTUUgIiBFcnJvciBhdCBhaW9fZXJyb3IoKSA6 ICVzXG4iLCBzdHJlcnJvciAoZXJyKSk7DQotCQljbG9zZShmZCk7DQotCQlleGl0KFBUU19GQUlM KTsNCi0JfQ0KLQ0KLQlpZiAocmV0ICE9IEJVRl9TSVpFLzIpDQotCXsNCi0JCXByaW50ZihUTkFN RSAiIEVycm9yIGF0IGFpb19yZXR1cm4oKVxuIik7DQotCQljbG9zZShmZCk7DQotCQlleGl0KFBU U19GQUlMKTsNCi0JfQ0KLQ0KLQkvKiBjaGVjayBpdCAqLw0KLQlpZiAobWVtY21wIChidWYsIGNo ZWNrLCBCVUZfU0laRS8yKSAhPSAwKSB7DQotCQlwcmludGYoVE5BTUUgIiByZWFkIHZhbHVlcyBh cmUgY29ycnVwdGVkXG4iKTsNCi0JCWNsb3NlKGZkKTsNCi0JCWV4aXQoUFRTX0ZBSUwpOw0KLQl9 DQotDQotCWlmIChjaGVja1tCVUZfU0laRS8yICsgMV0gIT0gMCkgew0KLQkJcHJpbnRmKFROQU1F ICIgcmVhZCBwYXN0IGxpbWl0XG4iKTsNCi0JCWNsb3NlKGZkKTsNCi0JCWV4aXQoUFRTX0ZBSUwp Ow0KLQl9DQotDQotCWNsb3NlKGZkKTsNCi0JcHJpbnRmICgiVGVzdCBQQVNTRURcbiIpOw0KLQly ZXR1cm4gUFRTX1BBU1M7DQorCXJldHVybiBQVFNfVU5URVNURUQ7DQogfQ0KSW5kZXg6IHBvc2l4 dGVzdHN1aXRlL2NvbmZvcm1hbmNlL2ludGVyZmFjZXMvYWlvX3dyaXRlLzEzLTEuYw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUkNTIGZpbGU6IC9jdnNyb290L3Bvc2l4dGVzdC9wb3NpeHRlc3RzdWl0ZS9jb25mb3Jt YW5jZS9pbnRlcmZhY2VzL2Fpb193cml0ZS8xMy0xLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAx LjMNCmRpZmYgLVUzIC1yMS4zIDEzLTEuYw0KLS0tIHBvc2l4dGVzdHN1aXRlL2NvbmZvcm1hbmNl L2ludGVyZmFjZXMvYWlvX3dyaXRlLzEzLTEuYwkyIEp1biAyMDA1IDEwOjQ5OjQ5IC0wMDAwCTEu Mw0KKysrIHBvc2l4dGVzdHN1aXRlL2NvbmZvcm1hbmNlL2ludGVyZmFjZXMvYWlvX3dyaXRlLzEz LTEuYwk1IEp1bCAyMDA2IDEzOjMxOjUwIC0wMDAwDQpAQCAtMTUsMTE0ICsxNSwyMyBAQA0KICAq DQogICogbWV0aG9kOg0KICAqDQotICoJLSBvcGVuIGZpbGUgZm9yIHdyaXRpbmcNCi0gKgktIGRy b3AgUkxJTUlUX0ZTSVpFIHRvIDUxMg0KLSAqCS0gd3JpdGUgMTAyNCBieXRlcyBhdCBvZmZzZXQg NTEyIHVzaW5nIGFpb193cml0ZQ0KLSAqCS0gY2hlY2sgZXJyb3IgY29kZSBpcyBFRkJJRw0KKyAq CVVOVEVTVEVEDQogICoNCiAgKi8NCiANCiAjZGVmaW5lIF9YT1BFTl9TT1VSQ0UgNjAwDQogI2lu Y2x1ZGUgPHN0ZGlvLmg+DQogI2luY2x1ZGUgPHVuaXN0ZC5oPg0KLSNpbmNsdWRlIDxzdHJpbmcu aD4NCi0jaW5jbHVkZSA8ZXJybm8uaD4NCi0jaW5jbHVkZSA8c3RkbGliLmg+DQotI2luY2x1ZGUg PHN5cy9yZXNvdXJjZS5oPg0KICNpbmNsdWRlIDxhaW8uaD4NCiANCiAjaW5jbHVkZSAicG9zaXh0 ZXN0LmgiDQogDQotI2RlZmluZSBUTkFNRSAiYWlvX3dyaXRlLzEzLTEuYyINCi0NCi1pbnQgZ290 X3NpZ3hmc3ogPSAwOw0KLQ0KLXZvaWQNCi1zaWd4ZnN6X2hhbmRsZXIoaW50IHNpZ251bSwgc2ln aW5mb190ICppbmZvLCB2b2lkICpjb250ZXh0KQ0KLXsNCi0JZ290X3NpZ3hmc3ogPSAxOw0KLX0N Ci0NCiBpbnQgbWFpbigpDQogew0KLQljaGFyIHRtcGZuYW1lWzI1Nl07DQotI2RlZmluZSBCVUZf U0laRSAxMDI0DQotCWNoYXIgYnVmW0JVRl9TSVpFXTsNCi0JaW50IGZkOw0KLQlzdHJ1Y3QgYWlv Y2IgYWlvY2I7DQotCXN0cnVjdCBybGltaXQgbGltaXQ7DQotCXN0cnVjdCBzaWdhY3Rpb24gYWN0 aW9uOw0KIA0KICNpZiBfUE9TSVhfQVNZTkNIUk9OT1VTX0lPICE9IDIwMDExMkwNCiAJZXhpdChQ VFNfVU5TVVBQT1JURUQpOw0KICNlbmRpZg0KIA0KLQkvKiBTZXQgZmlsZSBzaXplIHNvZnQgbGlt aXQgdG8gNTEyICovDQotCWdldHJsaW1pdChSTElNSVRfRlNJWkUgLCAmbGltaXQpOw0KLQ0KLQls aW1pdC5ybGltX2N1ciA9IEJVRl9TSVpFIC8gMjsNCi0NCi0JaWYgKHNldHJsaW1pdChSTElNSVRf RlNJWkUgLCAmbGltaXQpID09IC0xKQ0KLQl7DQotCQlwcmludGYoVE5BTUUgIiBFcnJvciBhdCBz ZXRsaW1pdCgpOiAlc1xuIiwNCi0JCSAgICAgICBzdHJlcnJvcihlcnJubykpOw0KLQkJZXhpdChQ VFNfVU5SRVNPTFZFRCk7DQotCX0NCi0NCi0Jc25wcmludGYodG1wZm5hbWUsIHNpemVvZih0bXBm bmFtZSksICIvdG1wL3B0c19haW9fd3JpdGVfMTNfMV8lZCIsIA0KLQkJICBnZXRwaWQoKSk7DQot CXVubGluayh0bXBmbmFtZSk7DQotCWZkID0gb3Blbih0bXBmbmFtZSwgT19DUkVBVCB8IE9fUkRX UiB8IE9fRVhDTCwNCi0JCSAgU19JUlVTUiB8IFNfSVdVU1IpOw0KLQlpZiAoZmQgPT0gLTEpDQot CXsNCi0JCXByaW50ZihUTkFNRSAiIEVycm9yIGF0IG9wZW4oKTogJXNcbiIsDQotCQkgICAgICAg c3RyZXJyb3IoZXJybm8pKTsNCi0JCWV4aXQoUFRTX1VOUkVTT0xWRUQpOw0KLQl9DQotDQotCXVu bGluayh0bXBmbmFtZSk7DQotDQotCS8qIFNldHVwIGhhbmRsZXIgZm9yIFNJR1hGU1ogKi8NCi0J YWN0aW9uLnNhX3NpZ2FjdGlvbiA9IHNpZ3hmc3pfaGFuZGxlcjsNCi0Jc2lnZW1wdHlzZXQoJmFj dGlvbi5zYV9tYXNrKTsNCi0JYWN0aW9uLnNhX2ZsYWdzID0gU0FfU0lHSU5GT3xTQV9SRVNUQVJU Ow0KLQlzaWdhY3Rpb24oU0lHWEZTWiwgJmFjdGlvbiwgTlVMTCk7DQotDQotCW1lbXNldChidWYs IDB4YWEsIEJVRl9TSVpFKTsNCi0JbWVtc2V0KCZhaW9jYiwgMCwgc2l6ZW9mKHN0cnVjdCBhaW9j YikpOw0KLQlhaW9jYi5haW9fZmlsZGVzID0gZmQ7DQotCWFpb2NiLmFpb19idWYgPSBidWY7DQot CWFpb2NiLmFpb19uYnl0ZXMgPSBCVUZfU0laRTsNCi0JYWlvY2IuYWlvX29mZnNldCA9IDUxMjsN Ci0NCi0JaWYgKGFpb193cml0ZSgmYWlvY2IpICE9IC0xKQ0KLQl7DQotCQl3aGlsZSAoYWlvX2Vy cm9yICgmYWlvY2IpID09IEVJTlBST0dSRVNTKTsNCi0NCi0JCWludCBlcnIgPSBhaW9fZXJyb3Ig KCZhaW9jYik7DQotCQlpbnQgcmV0ID0gYWlvX3JldHVybiAoJmFpb2NiKTsNCi0NCi0JCWlmIChy ZXQgIT0gLTEpIHsNCi0JCQlwcmludGYoVE5BTUUgIiBiYWQgYWlvX3dyaXRlIHJldHVybiB2YWx1 ZVxuIik7DQotCQkJY2xvc2UgKGZkKTsNCi0JCQlleGl0KFBUU19GQUlMKTsNCi0JCX0gZWxzZSBp ZiAoZXJyICE9IEVGQklHKSB7DQotCQkJcHJpbnRmKFROQU1FICIgZXJyb3IgY29kZSBpcyBub3Qg RUZCSUcgJXNcbiIsIHN0cmVycm9yKGVycm5vKSk7DQotCQkJY2xvc2UgKGZkKTsNCi0JCQlleGl0 KFBUU19GQUlMKTsNCi0JCX0NCi0JfSAgZWxzZSB7DQotDQotCQlpZiAoZXJybm8gIT0gRUZCSUcp DQotCQl7DQotCQkJcHJpbnRmKFROQU1FICIgZXJybm8gaXMgbm90IEVGQklHICVzXG4iLCBzdHJl cnJvcihlcnJubykpOw0KLQkJCWNsb3NlKGZkKTsNCi0JCQlleGl0KFBUU19GQUlMKTsNCi0JCX0N Ci0JfQ0KLQ0KLQljbG9zZShmZCk7DQotCXByaW50ZiAoIlRlc3QgUEFTU0VEXG4iKTsNCi0JcmV0 dXJuIFBUU19QQVNTOw0KKwlyZXR1cm4gUFRTX1VOVEVTVEVEOw0KIH0NCkluZGV4OiBwb3NpeHRl c3RzdWl0ZS9jb25mb3JtYW5jZS9pbnRlcmZhY2VzL2Fpb193cml0ZS80LTEuYw0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9jdnNyb290L3Bvc2l4dGVzdC9wb3NpeHRlc3RzdWl0ZS9jb25mb3JtYW5j ZS9pbnRlcmZhY2VzL2Fpb193cml0ZS80LTEuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMw0K ZGlmZiAtVTMgLXIxLjMgNC0xLmMNCi0tLSBwb3NpeHRlc3RzdWl0ZS9jb25mb3JtYW5jZS9pbnRl cmZhY2VzL2Fpb193cml0ZS80LTEuYwkyIEp1biAyMDA1IDEwOjQ5OjQ5IC0wMDAwCTEuMw0KKysr IHBvc2l4dGVzdHN1aXRlL2NvbmZvcm1hbmNlL2ludGVyZmFjZXMvYWlvX3dyaXRlLzQtMS5jCTUg SnVsIDIwMDYgMTM6MzE6NTAgLTAwMDANCkBAIC0xNSwxMjcgKzE1LDIzIEBADQogICoNCiAgKiBt ZXRob2Q6DQogICoNCi0gKgktIFNldCBSTElNSVRfRlNJWkUgdG8gNTEyDQotICoJLSBvcGVuIGZp bGUNCi0gKgktIHdyaXRlIDEwMjQgYnl0ZXMgdXNpbmcgYWlvX3dyaXRlDQotICoJLSBjaGVjayB0 aGF0IG9ubHkgNTEyIGJ5dGVzIHdlcmUgd3JpdHRlbg0KLSAqCS0gdHJ5IHRvIHJlYWQgMTAyNCBi eXRlcw0KLSAqCS0gY2hlY2sgdGhhdCBvbmx5IDUxMiBieXRlcyB3ZXJlIHJlYWQNCisgKglVTlRF U1RFRA0KICAqDQogICovDQogDQogI2RlZmluZSBfWE9QRU5fU09VUkNFIDYwMA0KICNpbmNsdWRl IDxzdGRpby5oPg0KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiAjaW5jbHVkZSA8dW5pc3RkLmg+ DQotI2luY2x1ZGUgPHN5cy9zdGF0Lmg+DQotI2luY2x1ZGUgPGZjbnRsLmg+DQotI2luY2x1ZGUg PHN0cmluZy5oPg0KLSNpbmNsdWRlIDxlcnJuby5oPg0KLSNpbmNsdWRlIDxzdGRsaWIuaD4NCi0j aW5jbHVkZSA8c3lzL3RpbWUuaD4NCi0jaW5jbHVkZSA8c3lzL3Jlc291cmNlLmg+DQogI2luY2x1 ZGUgPGFpby5oPg0KIA0KICNpbmNsdWRlICJwb3NpeHRlc3QuaCINCiANCi0jZGVmaW5lIFROQU1F ICJhaW9fd3JpdGUvNC0xLmMiDQotDQogaW50IG1haW4oKQ0KIHsNCi0JY2hhciB0bXBmbmFtZVsy NTZdOw0KLSNkZWZpbmUgQlVGX1NJWkUgMTAyNA0KLQljaGFyIGJ1ZltCVUZfU0laRV07DQotCWNo YXIgY2hlY2tbQlVGX1NJWkVdOw0KLQlpbnQgZmQ7DQotCXN0cnVjdCBhaW9jYiBhaW9jYjsNCi0J c3RydWN0IHJsaW1pdCBsaW1pdDsNCi0JaW50IGVycjsNCi0JaW50IHJldDsNCiANCiAjaWYgX1BP U0lYX0FTWU5DSFJPTk9VU19JTyAhPSAyMDAxMTJMDQogCWV4aXQoUFRTX1VOU1VQUE9SVEVEKTsN CiAjZW5kaWYNCiANCi0JLyogU2V0IGZpbGUgc2l6ZSBzb2Z0IGxpbWl0IHRvIDUxMiAqLw0KLQln ZXRybGltaXQoUkxJTUlUX0ZTSVpFICwgJmxpbWl0KTsNCi0NCi0JbGltaXQucmxpbV9jdXIgPSBC VUZfU0laRSAvIDI7DQotDQotCWlmIChzZXRybGltaXQoUkxJTUlUX0ZTSVpFICwgJmxpbWl0KSA9 PSAtMSkNCi0Jew0KLQkJcHJpbnRmKFROQU1FICIgRXJyb3IgYXQgc2V0bGltaXQoKTogJXNcbiIs DQotCQkgICAgICAgc3RyZXJyb3IoZXJybm8pKTsNCi0JCWV4aXQoUFRTX1VOUkVTT0xWRUQpOw0K LQl9DQotDQotCXNucHJpbnRmKHRtcGZuYW1lLCBzaXplb2YodG1wZm5hbWUpLCAiL3RtcC9wdHNf YWlvX3dyaXRlXzRfMV8lZCIsIA0KLQkJICBnZXRwaWQoKSk7DQotCXVubGluayh0bXBmbmFtZSk7 DQotCWZkID0gb3Blbih0bXBmbmFtZSwgT19DUkVBVCB8IE9fUkRXUiB8IE9fRVhDTCwNCi0JCSAg U19JUlVTUiB8IFNfSVdVU1IpOw0KLQlpZiAoZmQgPT0gLTEpDQotCXsNCi0JCXByaW50ZihUTkFN RSAiIEVycm9yIGF0IG9wZW4oKTogJXNcbiIsDQotCQkgICAgICAgc3RyZXJyb3IoZXJybm8pKTsN Ci0JCWV4aXQoUFRTX1VOUkVTT0xWRUQpOw0KLQl9DQotDQotCXVubGluayh0bXBmbmFtZSk7DQot DQotCW1lbXNldChidWYsIDB4YWEsIEJVRl9TSVpFKTsNCi0JbWVtc2V0KCZhaW9jYiwgMCwgc2l6 ZW9mKHN0cnVjdCBhaW9jYikpOw0KLQlhaW9jYi5haW9fZmlsZGVzID0gZmQ7DQotCWFpb2NiLmFp b19idWYgPSBidWY7DQotCWFpb2NiLmFpb19uYnl0ZXMgPSBCVUZfU0laRTsNCi0NCi0JaWYgKGFp b193cml0ZSgmYWlvY2IpID09IC0xKQ0KLQl7DQotCQlwcmludGYoVE5BTUUgIiBFcnJvciBhdCBh aW9fd3JpdGUoKTogJXNcbiIsDQotCQkgICAgICAgc3RyZXJyb3IoZXJybm8pKTsNCi0JCWV4aXQo UFRTX0ZBSUwpOw0KLQl9DQotDQotCS8qIFdhaXQgdW50aWwgY29tcGxldGlvbiAqLw0KLQl3aGls ZSAoYWlvX2Vycm9yICgmYWlvY2IpID09IEVJTlBST0dSRVNTKTsNCi0NCi0JZXJyID0gYWlvX2Vy cm9yKCZhaW9jYik7DQotCXJldCA9IGFpb19yZXR1cm4oJmFpb2NiKTsNCi0NCi0JaWYgKGVyciAh PSAwKQ0KLQl7DQotCQlwcmludGYgKFROQU1FICIgRXJyb3IgYXQgYWlvX2Vycm9yKCkgOiAlc1xu Iiwgc3RyZXJyb3IgKGVycikpOw0KLQkJY2xvc2UgKGZkKTsNCi0JCWV4aXQoUFRTX0ZBSUwpOw0K LQl9DQotDQotCS8qIENoZWNrIHRoYXQgd3JpdHRlbiBzaXplIGRpZCBub3QgZXhjZWVkIG1heCB2 YWx1ZSAqLw0KLQlpZiAocmV0ICE9IEJVRl9TSVpFLzIpDQotCXsNCi0JCXByaW50ZihUTkFNRSAi IEVycm9yIGF0IGFpb19yZXR1cm4oKVxuIik7DQotCQljbG9zZShmZCk7DQotCQlleGl0KFBUU19G QUlMKTsNCi0JfQ0KLQ0KLQkvKiBjaGVjayB0aGUgdmFsdWVzIHdyaXR0ZW4gKi8NCi0NCi0JaWYg KGxzZWVrKGZkLCAwLCBTRUVLX1NFVCkgPT0gLTEpDQotCXsNCi0JCXByaW50ZihUTkFNRSAiIEVy cm9yIGF0IGxzZWVrKCk6ICVzXG4iLA0KLQkJICAgICAgIHN0cmVycm9yKGVycm5vKSk7DQotCQll eGl0KFBUU19GQUlMKTsNCi0JfQ0KLQ0KLQkvKiB3ZSB0cnkgdG8gcmVhZCBtb3JlIHRoYW4gd2Ug d3JvdGUgdG8gYmUgc3VyZSBvZiB0aGUgc2l6ZSB3cml0dGVuICovDQotDQotCWlmIChyZWFkKGZk LCBjaGVjaywgQlVGX1NJWkUpICE9IEJVRl9TSVpFIC8gMikNCi0Jew0KLQkJcHJpbnRmKFROQU1F ICIgRXJyb3IgYXQgcmVhZCgpOiAlc1xuIiwNCi0JCSAgICAgICBzdHJlcnJvcihlcnJubykpOw0K LQkJZXhpdChQVFNfRkFJTCk7DQotCX0NCi0NCi0JY2xvc2UoZmQpOw0KLQlwcmludGYgKCJUZXN0 IFBBU1NFRFxuIik7DQotCXJldHVybiBQVFNfUEFTUzsNCisJcmV0dXJuIFBUU19VTlRFU1RFRDsN CiB9DQoNClVzaW5nIFRvbWNhdCBidXQgbmVlZCB0byBkbyBtb3JlPyBOZWVkIHRvIHN1cHBvcnQg d2ViIHNlcnZpY2VzLCBzZWN1cml0eT8NCkdldCBzdHVmZiBkb25lIHF1aWNrbHkgd2l0aCBwcmUt aW50ZWdyYXRlZCB0ZWNobm9sb2d5IHRvIG1ha2UgeW91ciBqb2IgZWFzaWVyDQpEb3dubG9hZCBJ Qk0gV2ViU3BoZXJlIEFwcGxpY2F0aW9uIFNlcnZlciB2LjEuMC4xIGJhc2VkIG9uIEFwYWNoZSBH ZXJvbmltbw0KaHR0cDovL3NlbC5hcy11cy5mYWxrYWcubmV0L3NlbD9jbWQ9bG5rJmtpZD0xMjA3 MDkmYmlkPTI2MzA1NyZkYXQ9MTIxNjQyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcG9zaXh0ZXN0LWRpc2N1c3MgbWFpbGluZyBsaXN0DQpwb3NpeHRl c3QtZGlzY3Vzc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCmh0dHBzOi8vbGlzdHMuc291cmNlZm9y Z2UubmV0L2xpc3RzL2xpc3RpbmZvL3Bvc2l4dGVzdC1kaXNjdXNzDQo= |
|
From: Erik H. <eh...@su...> - 2007-01-03 16:43:54
|
Hello,
> We really need to remove the signal within some aio_suspend test cases=
. since each asynchronous IO operation may possibly provoke signal when i=
t finish, the error is EINTR instead of EAGAIN.
I have rewritten aio-suspend/9-1.c and aio-suspend/4-1.c testsuites witho=
ut signals.
These are attached to this mail.
> For aio-suspend/9-1.c, it is used to test if no aio indicated in the li=
st completed before timeout, aio_suspend should fail with EAGAIN. So we s=
till need to rewrite it without signal. It is very strange that aio_susp=
end/4-1.c pass while aio_suspend/9-1.c faild on your side. Could you remo=
ve the signal and re-run it on your machine?
Original versions of these tests didn't pass. Only after my patch which w=
ipes
out at least the sigrt1_handler. (I have wiped out both signals and signa=
l handlers)
> For conformance/interfaces/aio_write/4-1.c, according the codes, the re=
sult should be always UNSUPPORTED or UNTESTED.=20
I can't found in code, how conformance/interfaces/aio_write/4-1.c can end=
s with
UNTESTED. This testsuite always pass on my machine. Only problem is when =
stdout is
redirected to file, which is used by testsuite loader.
Here is the example, how it behaves:
...conformance/interfaces/aio_write 0$./4-1
Test PASSED
...conformance/interfaces/aio_write 0$rm /tmp/test000000001
...conformance/interfaces/aio_write 0$./4-1 >>/tmp/test000000001
...conformance/interfaces/aio_write 0$dd if=3D/dev/zero bs=3D1 count=3D51=
2 >> /tmp/test000000001 2>/dev/null
...conformance/interfaces/aio_write 0$./4-1 >>/tmp/test000000001
File size limit exceeded
...conformance/interfaces/aio_write 153$
The last numger in prompt is return value of executed command.
Have a nice day
Yokotashi
=20
> Really appreciate you help on posixtestsuite. I have checked in your pa=
tch partially. thank you very much!
>=20
> Elva Fu=20
>=20
> -----Original Message-----
> From: pos...@li... [mailto:posixtest=
-dis...@li...] On Behalf Of Erik Hamera
> Sent: 2006=E5=B9=B410=E6=9C=8825=E6=97=A5 20:29
> To: pos...@li...
> Subject: [posixtest-discuss] Cumulative patch for aio_suspend and aio_w=
ritetestsuites
>=20
> Hello,
> I have repaired some aio_suspend() testsuites, which fails always on:
> "aio_suspend() should set errno to EAGAIN: 4 (Interrupted system call)"=
,
> because signal, which is used for notify interrupts the aio_suspend()
> function. I rewrote these for operating without this signal.
>=20
> The aio_suspend/9-1.c testsuite cannot pass on my machine, because it
> suspends for at least one jiffie and my AMD Athlon 64 3500+ can done th=
e
> operation before suspended testsuite gets context back. My patch is
> -#define BUF_SIZE 1024*1024
> +#define BUF_SIZE 1024*1024*8
> I don't know how make this better.
>=20
On Wed, Nov 22, 2006 at 02:23:11PM +0800, Fu, Elva wrote:
> The aio_write/4-1.c testsuite cannot pass when is run from loader, but =
can
> pass alone. The rlimit has been set back to -1 (no limit) between aio_w=
rite()
> and printf ("Test PASSED\n");.
>=20
> Thank you all for working on testsuites and have a nice day
>=20
> Yokotashi
>=20
|
|
From: Fu, E. <el...@in...> - 2006-11-22 06:23:22
|
We really need to remove the signal within some aio_suspend test cases. =
since each asynchronous IO operation may possibly provoke signal when it =
finish, the error is EINTR instead of EAGAIN.
For aio-suspend/9-1.c, it is used to test if no aio indicated in the =
list completed before timeout, aio_suspend should fail with EAGAIN. So =
we still need to rewrite it without signal. It is very strange that =
aio_suspend/4-1.c pass while aio_suspend/9-1.c faild on your side. Could =
you remove the signal and re-run it on your machine?
For conformance/interfaces/aio_write/4-1.c, according the codes, the =
result should be always UNSUPPORTED or UNTESTED.=20
Really appreciate you help on posixtestsuite. I have checked in your =
patch partially. thank you very much!
Elva Fu=20
-----Original Message-----
From: pos...@li... =
[mailto:pos...@li...] On Behalf Of =
Erik Hamera
Sent: 2006=C4=EA10=D4=C225=C8=D5 20:29
To: pos...@li...
Subject: [posixtest-discuss] Cumulative patch for aio_suspend and =
aio_writetestsuites
Hello,
I have repaired some aio_suspend() testsuites, which fails always on:
"aio_suspend() should set errno to EAGAIN: 4 (Interrupted system call)",
because signal, which is used for notify interrupts the aio_suspend()
function. I rewrote these for operating without this signal.
The aio_suspend/9-1.c testsuite cannot pass on my machine, because it
suspends for at least one jiffie and my AMD Athlon 64 3500+ can done the
operation before suspended testsuite gets context back. My patch is
-#define BUF_SIZE 1024*1024
+#define BUF_SIZE 1024*1024*8
I don't know how make this better.
The aio_write/4-1.c testsuite cannot pass when is run from loader, but =
can
pass alone. The rlimit has been set back to -1 (no limit) between =
aio_write()
and printf ("Test PASSED\n");.
Thank you all for working on testsuites and have a nice day
Yokotashi
|