Bug 900

Summary: [LTP] clock_nanosleep01 fails on qemux86-64
Product: [Yocto Project Subprojects] Kernel Reporter: Jiajun Xu <jiajun.xu>
Component: kernel-toolingAssignee: Liming Wang <liming.wang>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: dvhart, kevin.tian, richard.purdie, sgw, xudong.hao, yp.kernel.watcher, yp.watcher
Version: unspecified   
Target Milestone: 1.1   
Hardware: x86   
OS: Multiple   
Whiteboard: Patch submitted to list (24-Aug-2011)
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---
Attachments:
Description Flags
the source file of clock_nanosleep01 none

Description Jiajun Xu 2011-03-17 20:32:32 UTC 
Image location: http://autobuilder03.jf.intel.com/nightly/20110305-3/machines/qemu/qemux86_64/
Tree/Branch: Distro/Bernard
Commit: c192fefd868be53c20dfd8bc44e3e815cf53a10a

The case did not fail in v1.0 M2 testing. With v1.0 M4 RC1 and RC2, it always get failure on both sato-sdk and lsb-sdk image. The error log is as below:

#########
tag=clock_nanosleep01 stime=1299827524
cmdline="clock_nanosleep01"
contacts=""
analysis=exit
<<<test_output>>>
EXPECT: return value(ret)=0 errno=0 (Success)
RESULT: return value(ret)=0 errno=0 (Success)
EXPECT: return value(ret)=0 errno=0 (Success)
RESULT: return value(ret)=0 errno=0 (Success)
EXPECT: return value(ret)=22 errno=0 (Success)
RESULT: return value(ret)=22 errno=0 (Success)
EXPECT: return value(ret)=22 errno=0 (Success)
RESULT: return value(ret)=22 errno=0 (Success)
EXPECT: return value(ret)=4 errno=0 (Success)
RESULT: return value(ret)=4 errno=0 (Success)
clock_nanosleep01    0  TINFO  :  (case00) START
clock_nanosleep01    0  TINFO  :  check sleep time: (min:480) < 501 < (max:520) (msec)
clock_nanosleep01    0  TINFO  :  remain time: 0 0
clock_nanosleep01    0  TINFO  :  (case00) END => OK
clock_nanosleep01    0  TINFO  :  (case01) START
clock_nanosleep01    0  TINFO  :  check sleep time: (min:480) < 500 < (max:520) (msec)
clock_nanosleep01    0  TINFO  :  remain time: 0 0
clock_nanosleep01    0  TINFO  :  (case01) END => OK
clock_nanosleep01    0  TINFO  :  (case02) START
clock_nanosleep01    0  TINFO  :  remain time: 0 0
clock_nanosleep01    0  TINFO  :  (case02) END => OK
clock_nanosleep01    0  TINFO  :  (case03) START
clock_nanosleep01    0  TINFO  :  remain time: 0 0
clock_nanosleep01    0  TINFO  :  (case03) END => OK
clock_nanosleep01    0  TINFO  :  (case04) START
clock_nanosleep01    1  TFAIL  :  iclock_gettime failed: TEST_ERRNO=EINVAL(22): Invalid argument
clock_nanosleep01    0  TINFO  :  (case04) END => NG
clock_nanosleep01    0  TINFO  :  (case05) START
clock_nanosleep01    0  TINFO  :  remain time: 9 494470608
clock_nanosleep01    0  TINFO  :  (case05) END => OK
clock_nanosleep01    2  TFAIL  :  clock_nanosleep failed
clock_nanosleep01    0  TINFO  :  NG
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=1 corefile=no
cutime=4 cstime=4
#########
Comment 1 Jiajun Xu 2011-03-17 20:33:10 UTC 
Created attachment 119 [details]
the source file of clock_nanosleep01
Comment 2 Bruce Ashfield 2011-03-21 13:15:40 UTC 
There's no real changes outside of the stable update to the 
kernel in this timeframe. I'm not seeing anything that would
trigger this.

Do the h/w targets exhibit this same failure ?
Comment 3 Jiajun Xu 2011-03-23 07:31:19 UTC 
(In reply to comment #2)
> There's no real changes outside of the stable update to the 
> kernel in this timeframe. I'm not seeing anything that would
> trigger this.
> Do the h/w targets exhibit this same failure ?

Yes, the case also fails on real hardware -- jasperforest and sugarbay, which use x86_64 kernel.
Comment 4 Bruce Ashfield 2011-03-23 12:10:43 UTC 
ok. thanks for the clarification. This means more people can
debug/look into this when it bubbles up the list.
Comment 5 Jiajun Xu 2011-06-06 06:41:24 UTC 
The issue still exists on Yocto 1.1 M1 testing on real hardware, like sugarbay.
Tree/Branch: Poky/1.1_M1
Poky Commit: 4ff7af11ef69849ef9c16f585eae58ac920b222b
Meta Branch: 1.1_M1
Meta Commit: fc719f0cd6530ce15148b4aa274f1644b461b298
Comment 6 Bruce Ashfield 2011-08-22 20:08:03 UTC 
sending to Liming for a 2nd level triage.
Comment 8 Jiajun Xu 2011-09-25 19:39:26 UTC 
Verify the bug as fixed with 1.1 M4 branch.

tree/branch: poky/1.1_M4
commit: 6462c158fc482e495c1171ffc7747e2ad650a292