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

[john stultz <johnstul@us.ibm.com>]

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