linux-mips
[Top] [All Lists]

Re: select() to /dev/rtc0 to wait for clock tick timed out

To: john stultz <johnstul@us.ibm.com>
Subject: Re: select() to /dev/rtc0 to wait for clock tick timed out
From: Matt Turner <mattst88@gmail.com>
Date: Fri, 19 Aug 2011 17:48:36 -0400
Cc: linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QkX36K9zfTVzSvI/LzAViXE4Ua0L4+KeKh75Jwz3cOE=; b=B/tJCmAFxdD+0YrJmPzMpBB59r9uKLoqrkDfl0H/vOvctQ/Ix7qstcYivAIe7QTRqA 2VG8pGtNNF7oXGPW1uQXci0/WJPLJWa6bp/5Wp41c8MWmJ9SDqjicdqoodhP75kpyLhq Gk/IxRK5hC8HMceowK1IkT2nN+wdCicku/l7g=
In-reply-to: <1313788912.2970.152.camel@work-vm>
References: <CAEdQ38HGfd9YWE+WLuirE4Km6UE6N26toTj=-1BuXAQUux6t5g@mail.gmail.com> <1313777242.2970.131.camel@work-vm> <CAEdQ38F4zi76ug+ABZPnPLcLvGfUFRhr6SKzYCN+24Otq+qAAQ@mail.gmail.com> <1313783990.2970.136.camel@work-vm> <CAEdQ38H5NC6B+T=gsF4-8Ue2DA=rfrFCi_i+RKC-=DFijjK2=g@mail.gmail.com> <1313786070.2970.144.camel@work-vm> <CAEdQ38H7tHa3d83SOAbhUWFgwMgxCaP9ibJxNAGHAT2gmdEm=w@mail.gmail.com> <1313788912.2970.152.camel@work-vm>
Sender: linux-mips-bounce@linux-mips.org
On Fri, Aug 19, 2011 at 5:21 PM, john stultz <johnstul@us.ibm.com> wrote:
> On Fri, 2011-08-19 at 16:56 -0400, Matt Turner wrote:
>> With 2.6.37 the original rtctest program gives
>>
>>                       RTC Driver Test Example.
>>
>> RTC_UIE_ON ioctl: Invalid argument
>>
>> and the modified version hangs in the same way. :(
>
> Ok, so the AIE/alarm irq isn't working (but returns as if it should),
> and in the older case, the UIE mode properly returned an error.
>
> So I'm guessing since we now use AIE mode interrupts to emulate UIE, the
> UIE code thinks alarms will work and so doesn't return an error,
> confusing the hwclock code.
>
>> With 2.6.37, hwclock did work:
>>
>> bcm91250a-be ~ # date
>> Fri Aug 19 16:52:21 EDT 2011
>> bcm91250a-be ~ # hwclock --systohc
>> bcm91250a-be ~ # date 082016522011
>> Sat Aug 20 16:52:00 EDT 2011
>> bcm91250a-be ~ # hwclock --hctosys
>> bcm91250a-be ~ # date
>> Fri Aug 19 16:53:02 EDT 2011
>
> Running strace on the hwclock --hctosys might prove the theory above.
>
>
>> With 3.1.0-rc2+, it does not
>> bcm91250a-be ~ # date
>> Fri Aug 19 16:54:32 EDT 2011
>> bcm91250a-be ~ # hwclock --systohc
>> select() to /dev/rtc0 to wait for clock tick timed out
>> bcm91250a-be ~ # date 082016542011
>> Sat Aug 20 16:54:00 EDT 2011
>> bcm91250a-be ~ # hwclock --hctosys
>> select() to /dev/rtc0 to wait for clock tick timed out
>> bcm91250a-be ~ # date
>> Sat Aug 20 16:54:11 EDT 2011
>>
>> So, even if the alarm never worked, there is some sort of regression here.
>
> Yea, since we depend on the alarm irq for more functionality now, it not
> working in this case is causing more trouble.
>
> I suspect either fixing the driver alarm code so it either works or
> provides a proper error code will resolve it.
>
> thanks
> -john

Indeed, looks like that's the case.

2.6.37: ioctl(3, PRESTO_GETMOUNT or RTC_UIE_ON, 0) = -1 EINVAL
3.1.0: ioctl(3, PRESTO_GETMOUNT or RTC_UIE_ON, 0) = 0

(Attaching full gz'd logs for posterity.)

Thanks,
Matt

Attachment: 2.6.37-strace-output.gz
Description: GNU Zip compressed data

Attachment: 3.1.0-rc2-strace-output.gz
Description: GNU Zip compressed data

<Prev in Thread] Current Thread [Next in Thread>