On Fri, Apr 25, 2014 at 7:48 PM, Bryan Evenson <beven...@melinkcorp.com> 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.
> Similarly, the returned pointer of ctime and localtime was
> being used without checking if the pointer was valid. One of
> these calls was causing a call to hwclock to enter an
> uninterruptable sleep when the invalid hwclock access occurred.
Did you investigate which value of time_t caused that?
> 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.
> This patch verifies the RTC file descriptor is valid before it
> is used, and it switches all ctime and localtime calls to
> ctime_r localtime_r respectively. Before applying the patch,
> running the previously described test resulted in one instance
> of the script to hang with hwclock in an uninterruptable sleep
> within seconds of starting both scripts. After the patch, ran
> two instances of the scripts for ten minutes without permanently
> blocking access to the RTC.
Let's focus first on reproducing the problem.
Which version of busybox do you use, what .config file,
on what kernel?
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
