Denys, > -----Original Message----- > From: Denys Vlasenko [mailto:[email protected]] > Sent: Friday, May 02, 2014 3:10 AM > To: Bryan Evenson > Cc: [email protected]; busybox; [email protected] > Subject: Re: [PATCH 1/1] hwclock: Verify RTC file descriptor; use reentrant > functions > > On Tuesday 29 April 2014 18:29, Bryan Evenson wrote: > > > -----Original Message----- > > > From: Denys Vlasenko [mailto:[email protected]] > > > Sent: Tuesday, April 29, 2014 10:19 AM > > > To: Bryan Evenson > > > Cc: busybox; [email protected] > > > Subject: Re: [PATCH 1/1] hwclock: Verify RTC file descriptor; use > > > reentrant functions > > > > > > On Fri, Apr 25, 2014 at 7:48 PM, Bryan Evenson > > > <[email protected]> wrote: > > > > If the RTC is in use by another process or if the dev interface is > > > > not properly established, calling rtc_xopen will fail. > > > > > > I don't see how is that possible: > > > > > > int FAST_FUNC rtc_xopen(const char **default_rtc, int flags) { > > > int rtc; > > > > > > if (!*default_rtc) { > > > *default_rtc = "/dev/rtc"; > > > rtc = open(*default_rtc, flags); > > > if (rtc >= 0) > > > return rtc; > > > *default_rtc = "/dev/rtc0"; > > > rtc = open(*default_rtc, flags); > > > if (rtc >= 0) > > > return rtc; > > > *default_rtc = "/dev/misc/rtc"; > > > } > > > > > > return xopen(*default_rtc, flags); } > > > > > > If all open()'s fail, we end up executing "return xopen(...)". > > > And xopen() never returns failure - it exits with error message instead. > > > > Sorry, a little clarification on what I am seeing. If rtc_xopen can't > > open the rtc it returns an error instead of the file descriptor for the rtc. > > I don't see how this can happen. Do you have evidence rtc_xopen() did > return a result less than zero?
I don't have evidence, but that seemed to be the most likely result through code inspection. rtc_xopen() returns the result of xopen(), which returns the result of open(). open() returns -1 if an error occurred, meaning rtc_xopen() could return -1 if an error occurred opening the rtc file. The only configuration option I can see that directly relates to this section is CONFIG_ENABLE_FEATURE_CLEAN_UP, which in my configuration is disabled. > > > > > The problem can be reproduced by running two instances of the > > > > following shell script: > > > > > > > > #!/bin/sh > > > > while [ 1 ]; do > > > > /sbin/hwclock -w -u > > > > sleep 1; > > > > done > > > > > > Works for me with no problems with current bbox git tree. > > > Modifying it to run hwclock much more often: > > > > > > #!/bin/sh > > > i=0 > > > while true; do > > > ./busybox hwclock -w -u > > > echo $i $? > > > : $((i++)) > > > done > > > > > > and running two instances, I get this: > > > > > > ... > > > ... > > > 11461 0 > > > hwclock: can't open '/dev/misc/rtc': No such file or directory > > > 11462 1 > > > 11463 0 > > > hwclock: can't open '/dev/misc/rtc': No such file or directory > > > 11464 1 > > > hwclock: can't open '/dev/misc/rtc': No such file or directory > > > 11465 1 > > > 11466 0 > > > ... > > > ... > > > > > > Looks like it doesn't hang. > > > It's a question whether it should be failing or retrying, but I > > > don't see it hanging. > > > > > > > Maybe. The incrementing number is sequential, indicating it is from a > single instance of the script. > > I ran two instances of the script *in two different terminals*. > Both are showing the output similar to what I posted: > periodically, hwclock fails. OK, that makes sense. I ran both in the background on one terminal, which would have interleaved the output. > > > Of course this was just a few lines of output, so both scripts could > > be running on your system without problem and there just wasn't enough > data to show it. > > Could you confirm that your output shows both scripts are still running? > > Yes, I had two scripts running in parallel. > No, the output doesn't show both of them at once - the output is from one > of the two concurrently running scripts. > > -- > vda I've been sidetracked with other issues, but I am planning to get back to this. I plan to get a kernel with strace support built and on my machine so I can see what is causing the uninterruptable sleep on my system. I'll report back when I have some more information. -Bryan _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
