On 3/5/10, Garrett Cooper <[email protected]> wrote: > On Thu, Mar 4, 2010 at 10:54 PM, Silesh C V <[email protected]> wrote: >> On 3/5/10, Garrett Cooper <[email protected]> wrote: >>> On Thu, Mar 4, 2010 at 9:54 PM, Silesh C V <[email protected]> wrote: >>>> On 3/4/10, Rishikesh K Rajak <[email protected]> wrote: >>>>>>Rishi, >>>>> >>>>>>Can you test this patch on the machine on which the tests got stuck >>>>>>earlier? >>>>> >>>>> Yes i tested and found that, it is failing. >>>> >>>> It is supposed to fail :) . What we wanted was a way to come out of >>>> the tests if the >>>> alarm fails to ring. >>>> >>>> >>>>> >>>>> [r...@x335a rtc]# ./rtc-test /dev/rtc >>>>> rtc01 0 TINFO : RTC READ TEST: >>>>> rtc01 1 TPASS : RTC READ TEST Passed >>>>> rtc01 0 TINFO : Current Date/time is 03/03/10 12:38:26 PM >>>>> rtc01 0 TINFO : RTC ALARM TEST : >>>>> rtc01 0 TINFO : Alarm time set to 12:38:31. >>>>> rtc01 0 TINFO : Waiting 5 seconds for the alarm... >>>>> rtc01 2 TFAIL : Timed out waiting for the alarm >>>>> rtc01 0 TINFO : RTC UPDATE INTERRUPTS TEST : >>>>> rtc01 0 TINFO : Waiting for 5 update interrupts... >>>>> rtc01 0 TINFO : Update interrupt 1 >>>>> rtc01 0 TINFO : Update interrupt 2 >>>>> rtc01 0 TINFO : Update interrupt 3 >>>>> rtc01 0 TINFO : Update interrupt 4 >>>>> rtc01 0 TINFO : Update interrupt 5 >>>>> rtc01 3 TPASS : RTC UPDATE INTERRUPTS TEST Passed >>>>> rtc01 0 TINFO : RTC Tests Done! >>>>> [r...@x335a rtc]# ls -l /dev/rtc* >>>>> crw-r--r-- 1 root root 10, 135 Feb 20 13:51 /dev/rtc >>>>> [r...@x335a rtc]# >>>>> >>>>> >>>>> >>>>> In fact while compiling there is some warning also. >>>>> [r...@x335a rtc]# make >>>>> cc rtc-test.c -O2 -Wall -I ../../../../include/ -L ../../../../lib/ >>>>> -lltp -o rtc-test >>>>> rtc-test.c: In function ‘read_alarm_test’: >>>>> rtc-test.c:64: warning: dereferencing type-punned pointer will break >>>>> strict-aliasing rules >>>> >>>> I did not get this warning on gcc-4.3.0 . Anyways I think we can get rid >>>> of this >>>> warning by using -fno-strict-aliasing option at the cost of some >>>> optimizations. >>>> I will send you another patch. >>>> >>> >>> Or maybe just fix the code to not type-pun by converting everything to >>> struct tm on the fly? >>> >>> Let's look at the difference between the two structures: >>> >>> struct rtc_time { >>> int tm_sec; >>> int tm_min; >>> int tm_hour; >>> int tm_mday; >>> int tm_mon; >>> int tm_year; >>> int tm_wday; >>> int tm_yday; >>> int tm_isdst; >>> }; >>> >>> struct tm >>> { >>> int tm_sec; /* Seconds. [0-60] (1 leap second) */ >>> int tm_min; /* Minutes. [0-59] */ >>> int tm_hour; /* Hours. [0-23] */ >>> int tm_mday; /* Day. [1-31] */ >>> int tm_mon; /* Month. [0-11] */ >>> int tm_year; /* Year - 1900. */ >>> int tm_wday; /* Day of week. [0-6] */ >>> int tm_yday; /* Days in year.[0-365] */ >>> int tm_isdst; /* DST. [-1/0/1]*/ >>> >>> #ifdef __USE_BSD >>> long int tm_gmtoff; /* Seconds east of UTC. */ >>> __const char *tm_zone; /* Timezone abbreviation. */ >>> #else >>> long int __tm_gmtoff; /* Seconds east of UTC. */ >>> __const char *__tm_zone; /* Timezone abbreviation. */ >>> #endif >>> }; >>> >>> Note the extra fields down below -- they increase the structure size >>> by a non-trivial amount (12 bytes on 32-bit, 16 bytes on 64-bit), >>> which means that if one of the following two cases are made in >>> strftime tomorrow: >>> >>> 1. They use one of the timezone fields and it isn't properly cleared >>> (not the case today, but it could be on some older versions of Linux). >>> 2. They make assumptions about the size of the memory allocated and >>> thus go out of bounds. >>> >>> BOOM! Segfault... could worse happen in this case after the ioctl is >>> written out to /dev/rtc ? >> >> OK. Can we drop strftime then ? > > Why couldn't you memset ( , 0, ) the value and set the individual > fields?
Sorry . But I could not understand what you meant by setting the individual fields. One of the awesome things about strftime is that it's > localization aware if you use the right format strings (I know -- a > functional nice to have, not necessarily a need to have). > > Unfortunately one of 'em is American friendly only :/ : > > %D Equivalent to %m/%d/%y. (Yecch -- for Americans only. > Ameri- > cans should note that in other countries %d/%m/%y is rather > com- > mon. This means that in international context this format > is > ambiguous and should not be used.) (SU) > >>>>> Please solve these problems and please send me a revised patch. > > Thanks, > -Garrett > Thanks, Silesh -- Silesh ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
