Qemuarm-ltp: Difference between revisions

From Yocto Project
Jump to navigationJump to search
Line 6: Line 6:
         chdir01A fallocate01 fallocate02 fallocate03 getcontext01 splice02 utimensat01 hackbench01  
         chdir01A fallocate01 fallocate02 fallocate03 getcontext01 splice02 utimensat01 hackbench01  


audit: 33 (89%)
audit: 37 (100%)


*LTP: 0
*LTP: 0


*NAB: 2
*NAB: 4


*Fixed: 0
*Fixed: 1


*Matched: 29
*Matched: 29
Line 18: Line 18:
pending: 3
pending: 3


not started: 3
not started: 0


{|border="1"  
{|border="1"  
|| '''LTP cases'''|| '''status''' || '''owner''' || '''error msg''' || '''lsb''' || '''comment''' || '''bugzilla'''
|| '''LTP cases'''|| '''status''' || '''owner''' || '''error msg''' || '''lsb''' || '''comment''' || '''bugzilla'''
|-
|-
|| chdir01A || NAB || Kevin Tian || symlink(object, symbolic) was succesful.
|| utimensat01 || Fixed || Kevin Tian || EXPECTED: EPERM
 
mkdir(object, 0700) was successful
 
chdir(2) returned successfully, but getcwd(3) indicated new current working directory location /var/volatile/tmp/ltp-XXXXK9vOzf/chdNQdk3G/object not equal to expected /tmp/ltp-XXXXK9vOzf/chdNQdk3G/object
|| n/a
|| this is caused by not using "-d tmpdir" to specify a new tmp directory.
 
Then it means that /tmp is used which is however a symbol link to /var/volatile/tmp.
 
getcwd() syscall retrieves the full path from the leaf to the /, which has not idea of the original symbol link, and thus break LTP's expectation
|| n/a
|-
|| getcontext01 || NAB || Kevin Tian || getcontext - Sanity test :  Fail errno=38 : Function not implemented || n/a
|| libc doesn't implement getcontext for ARM, so this result is expected
|| n/a
|-
|| utimensat01 || pending || Kevin Tian || EXPECTED: EPERM


RESULT:  SUCCESS 1 1
RESULT:  SUCCESS 1 1
Line 52: Line 35:


chattr: Inappropriate ioctl for device while reading flags on /tmp/ltp-XXXX36nW4a/utimensat_tests/utimensat.test_file
chattr: Inappropriate ioctl for device while reading flags on /tmp/ltp-XXXX36nW4a/utimensat_tests/utimensat.test_file
|| n/a
 
|-
it has been fixed in 2.6.37, and thus should be able to be further confirmed in 1.0-M3
|| hackbench01 || not started || n/a || n/a || n/a || n/a || n/a
|-
|| splice02 || NAB || Kevin Tian || splice failed - errno = 28 : No space left on device || n/a
|| this is because no "-d tmpdir" specified when running this test, while standard /dev/hda only have limited space
|| n/a
|| n/a
|-
|-
Line 71: Line 50:
|| fallocate03 || pending || Kevin Tian || fallocate(6, 0, 49152, 4096) failed: TEST_ERRNO=EFBIG(27): File too large || n/a || same as fallocate01
|| fallocate03 || pending || Kevin Tian || fallocate(6, 0, 49152, 4096) failed: TEST_ERRNO=EFBIG(27): File too large || n/a || same as fallocate01
|| [[http://bugzilla.pokylinux.org/show_bug.cgi?id=678 bug678]]
|| [[http://bugzilla.pokylinux.org/show_bug.cgi?id=678 bug678]]
|-
|| chdir01A || NAB || Kevin Tian || symlink(object, symbolic) was succesful.
mkdir(object, 0700) was successful
chdir(2) returned successfully, but getcwd(3) indicated new current working directory location /var/volatile/tmp/ltp-XXXXK9vOzf/chdNQdk3G/object not equal to expected /tmp/ltp-XXXXK9vOzf/chdNQdk3G/object
|| n/a
|| this is caused by not using "-d tmpdir" to specify a new tmp directory.
Then it means that /tmp is used which is however a symbol link to /var/volatile/tmp.
getcwd() syscall retrieves the full path from the leaf to the /, which has not idea of the original symbol link, and thus break LTP's expectation
|| n/a
|-
|| getcontext01 || NAB || Kevin Tian || getcontext - Sanity test :  Fail errno=38 : Function not implemented || n/a
|| libc doesn't implement getcontext for ARM, so this result is expected
|| n/a
|-
|| hackbench01 || NAB || Kevin Tian || the system simply hangs || n/a || it's not approriate to run this stress test in such an emulator, and this case has been commented when doing test on other platforms || n/a
|-
|| splice02 || NAB || Kevin Tian || splice failed - errno = 28 : No space left on device || n/a
|| this is because no "-d tmpdir" specified when running this test, while standard /dev/hda only have limited space
|| n/a
|-
|-
|| ioctl03 || [[qemux86-ltp|qemux86]] || n/a || n/a || n/a || n/a || n/a
|| ioctl03 || [[qemux86-ltp|qemux86]] || n/a || n/a || n/a || n/a || n/a

Revision as of 06:33, 30 January 2011

1.0/M1

total: 37

similarity: 29 (78.00%):

       chdir01A fallocate01 fallocate02 fallocate03 getcontext01 splice02 utimensat01 hackbench01 

audit: 37 (100%)

  • LTP: 0
  • NAB: 4
  • Fixed: 1
  • Matched: 29

pending: 3

not started: 0

LTP cases status owner error msg lsb comment bugzilla
utimensat01 Fixed Kevin Tian EXPECTED: EPERM

RESULT: SUCCESS 1 1

FAILED test 78

... (Failed tests: 46 47 48 49 50 51 52 53 54 55 56 57 58 61 62 63 64 65 66 67 68 69 70 73 74 75 76 77 78)

n/a utimensat01 tried to verify all kinds of success and error conditions as defined in utimensat manual, for example, to get EPERM when the file is marked as append-only or immutable by chattr. However chattr has problem to change desired attributes as below:

chattr: Inappropriate ioctl for device while reading flags on /tmp/ltp-XXXX36nW4a/utimensat_tests/utimensat.test_file

it has been fixed in 2.6.37, and thus should be able to be further confirmed in 1.0-M3

n/a
fallocate01 pending Kevin Tian fallocate(6, 0, 49152, 4096) failed: TEST_ERRNO=EFBIG(27): File too large n/a This case is expected to return -EOPNOSUPP and then LTP will skip it. However on qemuarm/qemumips -EFBIG is returned earlier, and thus trigger this failure.

Actually I don't understand why this will happen, and any offset/length returns same failure. fallocate from util-linux could trigger this failure too.

[bug678]
fallocate02 pending Kevin Tian fallocate(6, 0, 49152, 4096) failed: TEST_ERRNO=EFBIG(27): File too large n/a same as fallocate01 [bug678]
fallocate03 pending Kevin Tian fallocate(6, 0, 49152, 4096) failed: TEST_ERRNO=EFBIG(27): File too large n/a same as fallocate01 [bug678]
chdir01A NAB Kevin Tian symlink(object, symbolic) was succesful.

mkdir(object, 0700) was successful

chdir(2) returned successfully, but getcwd(3) indicated new current working directory location /var/volatile/tmp/ltp-XXXXK9vOzf/chdNQdk3G/object not equal to expected /tmp/ltp-XXXXK9vOzf/chdNQdk3G/object

n/a this is caused by not using "-d tmpdir" to specify a new tmp directory.

Then it means that /tmp is used which is however a symbol link to /var/volatile/tmp.

getcwd() syscall retrieves the full path from the leaf to the /, which has not idea of the original symbol link, and thus break LTP's expectation

n/a
getcontext01 NAB Kevin Tian getcontext - Sanity test : Fail errno=38 : Function not implemented n/a libc doesn't implement getcontext for ARM, so this result is expected n/a
hackbench01 NAB Kevin Tian the system simply hangs n/a it's not approriate to run this stress test in such an emulator, and this case has been commented when doing test on other platforms n/a
splice02 NAB Kevin Tian splice failed - errno = 28 : No space left on device n/a this is because no "-d tmpdir" specified when running this test, while standard /dev/hda only have limited space n/a
ioctl03 qemux86 n/a n/a n/a n/a n/a
lchown02 qemux86 n/a n/a n/a n/a n/a
lchown02_16 qemux86 n/a n/a n/a n/a n/a
sysctl03 qemux86 n/a n/a n/a n/a n/a
syslog01 qemux86 n/a n/a n/a n/a n/a
syslog02 qemux86 n/a n/a n/a n/a n/a
syslog03 qemux86 n/a n/a n/a n/a n/a
syslog04 qemux86 n/a n/a n/a n/a n/a
syslog05 qemux86 n/a n/a n/a n/a n/a
syslog07 qemux86 n/a n/a n/a n/a n/a
syslog08 qemux86 n/a n/a n/a n/a n/a
syslog09 qemux86 n/a n/a n/a n/a n/a
syslog10 qemux86 n/a n/a n/a n/a n/a
mtest06_2 qemux86 n/a n/a n/a n/a n/a
mmapstress06 qemux86 n/a n/a n/a n/a n/a
su01 qemux86 n/a n/a n/a n/a n/a
cron02 qemux86 n/a n/a n/a n/a n/a
cron_deny01 qemux86 n/a n/a n/a n/a n/a
cron_allow01 qemux86 n/a n/a n/a n/a n/a
cron_dirs_checks01 qemux86 n/a n/a n/a n/a n/a
ld qemux86 n/a n/a n/a n/a n/a
ldd qemux86 n/a n/a n/a n/a n/a
file qemux86 n/a n/a n/a n/a n/a
tar qemux86 n/a n/a n/a n/a n/a
cron qemux86 n/a n/a n/a n/a n/a
logrotate qemux86 n/a n/a n/a n/a n/a
cpio qemux86 n/a n/a n/a n/a n/a
unzip01 qemux86 n/a n/a n/a n/a n/a
gzip01 qemux86 n/a n/a n/a n/a n/a