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

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

[Matt Turner]

Hi John,

I just sent a patch series to linux-mips@ that enables the RTC on a
particular Broadcom MIPS motherboard (BCM91250A SWARM). The RTC is an
M41T80.

When I first found the patchset (it was originally sent a a few years
ago) and applied it to 2.6.37, it worked perfectly.

Applied to 3.x (and I think even 2.6.38) I get the following when I run hwclock:

# hwclock --systohc
select() to /dev/rtc0 to wait for clock tick timed out

dmesg shows:

[    1.068000] i2c /dev entries driver
[    1.072000] i2c-sibyte: i2c SMBus adapter module for SiByte board
[    1.080000] rtc-m41t80 1-0068: chip found, driver version 0.06
[    1.088000] rtc-m41t80 1-0068: rtc core: registered m41t81 as rtc0
[    1.172000] rtc-m41t80 1-0068: setting system clock to 2011-08-18
19:56:53 UTC (1313697413)

I'm emailing you because I thought it might be the same problem as
https://lkml.org/lkml/2011/1/20/306

Do you know what might be the problem?

The patch series can be found here [1], if they did not find their way
to you through another mailing list.

Thanks,
Matt

[1] http://www.linux-mips.org/archives/linux-mips/2011-08/threads.html

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

[john stultz]

On Fri, 2011-08-19 at 00:16 -0400, Matt Turner wrote:
> Hi John,
> 
> I just sent a patch series to linux-mips@ that enables the RTC on a
> particular Broadcom MIPS motherboard (BCM91250A SWARM). The RTC is an
> M41T80.
> 
> When I first found the patchset (it was originally sent a a few years
> ago) and applied it to 2.6.37, it worked perfectly.
> 
> Applied to 3.x (and I think even 2.6.38) I get the following when I run hwclock:
> 
> # hwclock --systohc
> select() to /dev/rtc0 to wait for clock tick timed out
> 
> dmesg shows:
> 
> [    1.068000] i2c /dev entries driver
> [    1.072000] i2c-sibyte: i2c SMBus adapter module for SiByte board
> [    1.080000] rtc-m41t80 1-0068: chip found, driver version 0.06
> [    1.088000] rtc-m41t80 1-0068: rtc core: registered m41t81 as rtc0
> [    1.172000] rtc-m41t80 1-0068: setting system clock to 2011-08-18
> 19:56:53 UTC (1313697413)
> 
> I'm emailing you because I thought it might be the same problem as
> https://lkml.org/lkml/2011/1/20/306

Hmm. I thought we had gotten one that sorted. 

> Do you know what might be the problem?

I'll take a look and see what I find.

Thanks for the report!
-john

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

[john stultz]

On Fri, 2011-08-19 at 00:16 -0400, Matt Turner wrote:
> Hi John,
> 
> I just sent a patch series to linux-mips@ that enables the RTC on a
> particular Broadcom MIPS motherboard (BCM91250A SWARM). The RTC is an
> M41T80.
> 
> When I first found the patchset (it was originally sent a a few years
> ago) and applied it to 2.6.37, it worked perfectly.
> 
> Applied to 3.x (and I think even 2.6.38) I get the following when I run hwclock:
> 
> # hwclock --systohc
> select() to /dev/rtc0 to wait for clock tick timed out

So do alarm interrupts actually work on the hardware? 

The rtc-m41t80.c driver looks like it should support them ok.

Does the test program at the end of Documentation/rtc.txt do much?

thanks
-john

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

[Matt Turner]

On Fri, Aug 19, 2011 at 2:07 PM, john stultz <johnstul@us.ibm.com> wrote:
> On Fri, 2011-08-19 at 00:16 -0400, Matt Turner wrote:
>> Hi John,
>>
>> I just sent a patch series to linux-mips@ that enables the RTC on a
>> particular Broadcom MIPS motherboard (BCM91250A SWARM). The RTC is an
>> M41T80.
>>
>> When I first found the patchset (it was originally sent a a few years
>> ago) and applied it to 2.6.37, it worked perfectly.
>>
>> Applied to 3.x (and I think even 2.6.38) I get the following when I run hwclock:
>>
>> # hwclock --systohc
>> select() to /dev/rtc0 to wait for clock tick timed out
>
> So do alarm interrupts actually work on the hardware?
>
> The rtc-m41t80.c driver looks like it should support them ok.
>
> Does the test program at the end of Documentation/rtc.txt do much?
>
> thanks
> -john

Counting 5 update (1/sec) interrupts from reading /dev/rtc0:

... and then it doesn't count.

Would it help if I tried to bisect this? (Is there an easy way to
bisect 2.6.37..master with my patches applied to each iteration?)

Thanks,
Matt

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

[john stultz]

On Fri, 2011-08-19 at 15:41 -0400, Matt Turner wrote:
> On Fri, Aug 19, 2011 at 2:07 PM, john stultz <johnstul@us.ibm.com> wrote:
> > On Fri, 2011-08-19 at 00:16 -0400, Matt Turner wrote:
> > thanks
> > -john
> 
> Counting 5 update (1/sec) interrupts from reading /dev/rtc0:
> 
> ... and then it doesn't count.
> 
> Would it help if I tried to bisect this? (Is there an easy way to
> bisect 2.6.37..master with my patches applied to each iteration?)

I suspect bisecting won't help too much, as I've reworked a good chunk
of the generic rtc code in 2.6.38, so its not likely to be one small
change.

How about this modified (cutting out the UIE testing) version of the
Documentation/rtc.txt test below?

I'm basically trying to find out if the alarm functionality is actually
working or not, since with 2.6.38+ we use the one-shot style alarm mode
to trigger UIE interrupts.

thanks
-john



/*
 *      Real Time Clock Driver Test/Example Program
 *
 *      Compile with:
 *		     gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
 *
 *      Copyright (C) 1996, Paul Gortmaker.
 *
 *      Released under the GNU General Public License, version 2,
 *      included herein by reference.
 *
 */

#include <stdio.h>
#include <linux/rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>


/*
 * This expects the new RTC class driver framework, working with
 * clocks that will often not be clones of what the PC-AT had.
 * Use the command line to specify another RTC if you need one.
 */
static const char default_rtc[] = "/dev/rtc0";


int main(int argc, char **argv)
{
	int i, fd, retval, irqcount = 0;
	unsigned long tmp, data;
	struct rtc_time rtc_tm;
	const char *rtc = default_rtc;

	switch (argc) {
	case 2:
		rtc = argv[1];
		/* FALLTHROUGH */
	case 1:
		break;
	default:
		fprintf(stderr, "usage:  rtctest [rtcdev]\n");
		return 1;
	}

	fd = open(rtc, O_RDONLY);

	if (fd ==  -1) {
		perror(rtc);
		exit(errno);
	}

	fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");

test_READ:
	/* Read the RTC time/date */
	retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
	if (retval == -1) {
		perror("RTC_RD_TIME ioctl");
		exit(errno);
	}

	fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
		rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
		rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

	/* Set the alarm to 5 sec in the future, and check for rollover */
	rtc_tm.tm_sec += 5;
	if (rtc_tm.tm_sec >= 60) {
		rtc_tm.tm_sec %= 60;
		rtc_tm.tm_min++;
	}
	if (rtc_tm.tm_min == 60) {
		rtc_tm.tm_min = 0;
		rtc_tm.tm_hour++;
	}
	if (rtc_tm.tm_hour == 24)
		rtc_tm.tm_hour = 0;

	retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
	if (retval == -1) {
		if (errno == ENOTTY) {
			fprintf(stderr,
				"\n...Alarm IRQs not supported.\n");
			goto test_PIE;
		}
		perror("RTC_ALM_SET ioctl");
		exit(errno);
	}

	/* Read the current alarm settings */
	retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
	if (retval == -1) {
		perror("RTC_ALM_READ ioctl");
		exit(errno);
	}

	fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
		rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

	/* Enable alarm interrupts */
	retval = ioctl(fd, RTC_AIE_ON, 0);
	if (retval == -1) {
		perror("RTC_AIE_ON ioctl");
		exit(errno);
	}

	fprintf(stderr, "Waiting 5 seconds for alarm...");
	fflush(stderr);
	/* This blocks until the alarm ring causes an interrupt */
	retval = read(fd, &data, sizeof(unsigned long));
	if (retval == -1) {
		perror("read");
		exit(errno);
	}
	irqcount++;
	fprintf(stderr, " okay. Alarm rang.\n");

	/* Disable alarm interrupts */
	retval = ioctl(fd, RTC_AIE_OFF, 0);
	if (retval == -1) {
		perror("RTC_AIE_OFF ioctl");
		exit(errno);
	}

test_PIE:
	/* Read periodic IRQ rate */
	retval = ioctl(fd, RTC_IRQP_READ, &tmp);
	if (retval == -1) {
		/* not all RTCs support periodic IRQs */
		if (errno == ENOTTY) {
			fprintf(stderr, "\nNo periodic IRQ support\n");
			goto done;
		}
		perror("RTC_IRQP_READ ioctl");
		exit(errno);
	}
	fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);

	fprintf(stderr, "Counting 20 interrupts at:");
	fflush(stderr);

	/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
	for (tmp=2; tmp<=64; tmp*=2) {

		retval = ioctl(fd, RTC_IRQP_SET, tmp);
		if (retval == -1) {
			/* not all RTCs can change their periodic IRQ rate */
			if (errno == ENOTTY) {
				fprintf(stderr,
					"\n...Periodic IRQ rate is fixed\n");
				goto done;
			}
			perror("RTC_IRQP_SET ioctl");
			exit(errno);
		}

		fprintf(stderr, "\n%ldHz:\t", tmp);
		fflush(stderr);

		/* Enable periodic interrupts */
		retval = ioctl(fd, RTC_PIE_ON, 0);
		if (retval == -1) {
			perror("RTC_PIE_ON ioctl");
			exit(errno);
		}

		for (i=1; i<21; i++) {
			/* This blocks */
			retval = read(fd, &data, sizeof(unsigned long));
			if (retval == -1) {
				perror("read");
				exit(errno);
			}
			fprintf(stderr, " %d",i);
			fflush(stderr);
			irqcount++;
		}

		/* Disable periodic interrupts */
		retval = ioctl(fd, RTC_PIE_OFF, 0);
		if (retval == -1) {
			perror("RTC_PIE_OFF ioctl");
			exit(errno);
		}
	}

done:
	fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");

	close(fd);

	return 0;
}

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

[Matt Turner]

On Fri, Aug 19, 2011 at 3:59 PM, john stultz <johnstul@us.ibm.com> wrote:
> On Fri, 2011-08-19 at 15:41 -0400, Matt Turner wrote:
>> On Fri, Aug 19, 2011 at 2:07 PM, john stultz <johnstul@us.ibm.com> wrote:
>> > On Fri, 2011-08-19 at 00:16 -0400, Matt Turner wrote:
>> > thanks
>> > -john
>>
>> Counting 5 update (1/sec) interrupts from reading /dev/rtc0:
>>
>> ... and then it doesn't count.
>>
>> Would it help if I tried to bisect this? (Is there an easy way to
>> bisect 2.6.37..master with my patches applied to each iteration?)
>
> I suspect bisecting won't help too much, as I've reworked a good chunk
> of the generic rtc code in 2.6.38, so its not likely to be one small
> change.
>
> How about this modified (cutting out the UIE testing) version of the
> Documentation/rtc.txt test below?
>
> I'm basically trying to find out if the alarm functionality is actually
> working or not, since with 2.6.38+ we use the one-shot style alarm mode
> to trigger UIE interrupts.
>
> thanks
> -john

Nope, just hangs.

Current RTC date/time is 19-8-2011, 00:20:51.
Alarm time now set to 00:20:56.
Waiting 5 seconds for alarm...

Would it at least help if I booted 2.6.37 to confirm that this test
program works there? I'd hate to waste a bunch of your time only to
find out that it's a problem with my patches.

Thanks,
MAtt

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

[john stultz]

On Fri, 2011-08-19 at 16:06 -0400, Matt Turner wrote:
> Nope, just hangs.
> 
> Current RTC date/time is 19-8-2011, 00:20:51.
> Alarm time now set to 00:20:56.
> Waiting 5 seconds for alarm...

Ok. That confirms the alarm irq isn't working.

> Would it at least help if I booted 2.6.37 to confirm that this test
> program works there? I'd hate to waste a bunch of your time only to
> find out that it's a problem with my patches.

Yea, that's probably a good idea.

>From there we can instrument the code to see why the alarm irq isn't
working.

Thanks again for the testing!
-john

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

[john stultz]

On Fri, 2011-08-19 at 16:06 -0400, Matt Turner wrote:
> Nope, just hangs.
> 
> Current RTC date/time is 19-8-2011, 00:20:51.
> Alarm time now set to 00:20:56.
> Waiting 5 seconds for alarm...

Ok. That confirms the alarm irq isn't working.

> Would it at least help if I booted 2.6.37 to confirm that this test
> program works there? I'd hate to waste a bunch of your time only to
> find out that it's a problem with my patches.

Yea, that's probably a good idea.

From there we can instrument the code to see why the alarm irq isn't
working.

Thanks again for the testing!
-john

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

[Matt Turner]

On Fri, Aug 19, 2011 at 4:34 PM, john stultz <johnstul@us.ibm.com> wrote:
> On Fri, 2011-08-19 at 16:06 -0400, Matt Turner wrote:
>> Nope, just hangs.
>>
>> Current RTC date/time is 19-8-2011, 00:20:51.
>> Alarm time now set to 00:20:56.
>> Waiting 5 seconds for alarm...
>
> Ok. That confirms the alarm irq isn't working.
>
>> Would it at least help if I booted 2.6.37 to confirm that this test
>> program works there? I'd hate to waste a bunch of your time only to
>> find out that it's a problem with my patches.
>
> Yea, that's probably a good idea.
>
> From there we can instrument the code to see why the alarm irq isn't
> working.
>
> Thanks again for the testing!
> -john

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. :(

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

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.

Thanks,
Matt

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

[john stultz]

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

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

[Matt Turner]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

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: 2.6.37-strace-output.gz --]
[-- Type: application/x-gzip, Size: 27280 bytes --]

[-- Attachment #3: 3.1.0-rc2-strace-output.gz --]
[-- Type: application/x-gzip, Size: 21292 bytes --]

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

[Matt Turner]

On Fri, Aug 19, 2011 at 5:48 PM, Matt Turner <mattst88@gmail.com> wrote:
> 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

I looked through the datasheet and tried to find a place where we're
doing something wrong in the driver, but I didn't see anything.

http://www.datasheetcatalog.com/datasheets_pdf/M/4/1/T/M41T80.shtml

Any ideas?

Matt

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

[Atsushi Nemoto]

On Thu, 25 Aug 2011 13:30:02 -0400, Matt Turner <mattst88@gmail.com> wrote:
> I looked through the datasheet and tried to find a place where we're
> doing something wrong in the driver, but I didn't see anything.
> 
> http://www.datasheetcatalog.com/datasheets_pdf/M/4/1/T/M41T80.shtml

Excuse me for slow response.

As you and John discovered, this driver do not support alarm
completely.  This driver just can set/read alarm date/time, but RTC
interrupt is not implemented yet.

So possible solutions would be:

* Implement RTC irq handler. (Now we have threaded-irq so it would be
easier than the past)
* Drop .set_alarm function. (i.e. drop whole alarm codes)

I cannot test this driver by myself, but I will take a look if you had
any fix.  Thank you.

---
Atsushi Nemoto

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

[Xiangfu Liu]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

Hi John Stultz

I meet the same problem on MIPS jz4740, here is the step I try to find out the problem:

1. when I direct run 'hwclock' it will give
    "select() to /dev/rtc0 to wait for clock tick timed out"
    attachment 'hwclock.time.out' is the strace log

2. run 'rtctest' program. it works fine. the output is here[1]

3. after 'rtctest', run 'hwclock' again. then it works fine
    attachment 'hwclock.wors' is the strace log

without 'rtctest' run first. 'hwclock' never works.
the hwclock works fine in 2.6.27.6, failed under '3.0.0'

Please give me some tips how to fix this problem. shoule I modify the driver code
or is that relate to 'CONFIG_RTC_INTF_DEV_UIE_EMUL'?

thanks in advance.
xiangfu

[1]
root@BenNanoNote:~# ./rtctest
			RTC Driver Test Example.
Current RTC date/time is 30-12-2011, 08:25:55.
Alarm time now set to 08:26:00.
Waiting 5 seconds for alarm... okay. Alarm rang.

Periodic IRQ rate is 64Hz.
Counting 20 interrupts at:
2Hz:	 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
4Hz:	 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
8Hz:	 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
16Hz:	 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
32Hz:	 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
64Hz:	 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

			 *** Test complete ***

[-- Attachment #2: hwclock.time.out --]
[-- Type: text/plain, Size: 3339 bytes --]

execve("/sbin/hwclock", ["hwclock"], [/* 15 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2aab7000
stat("/etc/ld.so.cache", 0x7faaa3f0)    = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=70228, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2aab8000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\2204\0\0004\0\0\0"..., 4096) = 4096
old_mmap(NULL, 126976, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aac8000
old_mmap(0x2aac8000, 59116, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2aac8000
old_mmap(0x2aae6000, 2476, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x2aae6000
close(3)                                = 0
munmap(0x2aab8000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=629904, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2aab8000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0000\246\0\0004\0\0\0"..., 4096) = 4096
old_mmap(NULL, 675840, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aae7000
old_mmap(0x2aae7000, 577564, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2aae7000
old_mmap(0x2ab84000, 7504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8d000) = 0x2ab84000
old_mmap(0x2ab86000, 20604, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ab86000
close(3)                                = 0
munmap(0x2aab8000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=629904, ...}) = 0
close(3)                                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=31756, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2aab8000
set_thread_area(0x2aabf2d0)             = 0
mprotect(0x2ab84000, 4096, PROT_READ)   = 0
mprotect(0x2aac6000, 4096, PROT_READ)   = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, 0x7faaa3c0)          = -1 ENOTTY (Inappropriate ioctl for device)
gettimeofday({1325230583, 813665}, NULL) = 0
getuid()                                = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = 3
close(3)                                = 0
stat64(0x404840, 0x7faaa238)            = 0
brk(0)                                  = 0x701000
brk(0x702000)                           = 0x702000
open("/etc/adjtime", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, TIOCNXCL, 0x7faaa1e8)          = -1 ENOTTY (Inappropriate ioctl for device)
brk(0x703000)                           = 0x703000
read(3, "0.000000 1325230378 0.000000\n132"..., 4096) = 46
close(3)                                = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = 3
ioctl(3, PRESTO_GETMOUNT or RTC_UIE_ON, 0) = 0
_newselect(4, [3], NULL, NULL, {5, 0})  = 0 (Timeout)
write(2, "select() to ", 12select() to )            = 12
write(2, "/dev/rtc", 8/dev/rtc)                 = 8
write(2, " to wait for clock tick timed ou"..., 34 to wait for clock tick timed out
) = 34
ioctl(3, PRESTO_SETPID or RTC_UIE_OFF, 0) = 0
close(3)                                = 0
exit_group(1)                           = ?

[-- Attachment #3: hwclock.works --]
[-- Type: text/plain, Size: 4591 bytes --]

execve("/sbin/hwclock", ["hwclock"], [/* 15 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2ac15000
stat("/etc/ld.so.cache", 0x7fb21be0)    = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=70228, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2ac16000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\2204\0\0004\0\0\0"..., 4096) = 4096
old_mmap(NULL, 126976, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac26000
old_mmap(0x2ac26000, 59116, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ac26000
old_mmap(0x2ac44000, 2476, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x2ac44000
close(3)                                = 0
munmap(0x2ac16000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=629904, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2ac16000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0000\246\0\0004\0\0\0"..., 4096) = 4096
old_mmap(NULL, 675840, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac45000
old_mmap(0x2ac45000, 577564, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ac45000
old_mmap(0x2ace2000, 7504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8d000) = 0x2ace2000
old_mmap(0x2ace4000, 20604, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ace4000
close(3)                                = 0
munmap(0x2ac16000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=629904, ...}) = 0
close(3)                                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=31756, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x2ac16000
set_thread_area(0x2ac1d2d0)             = 0
mprotect(0x2ace2000, 4096, PROT_READ)   = 0
mprotect(0x2ac24000, 4096, PROT_READ)   = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, 0x7fb21bb0)          = -1 ENOTTY (Inappropriate ioctl for device)
gettimeofday({1325231181, 400545}, NULL) = 0
getuid()                                = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = 3
close(3)                                = 0
stat64(0x404840, 0x7fb21a28)            = 0
brk(0)                                  = 0xa6c000
brk(0xa6d000)                           = 0xa6d000
open("/etc/adjtime", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, TIOCNXCL, 0x7fb219d8)          = -1 ENOTTY (Inappropriate ioctl for device)
brk(0xa6e000)                           = 0xa6e000
read(3, "0.000000 1325230378 0.000000\n132"..., 4096) = 46
close(3)                                = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = 3
ioctl(3, PRESTO_GETMOUNT or RTC_UIE_ON, 0) = 0
_newselect(4, [3], NULL, NULL, {5, 0})  = 1 (in [3], left {3, 20190})
ioctl(3, PRESTO_SETPID or RTC_UIE_OFF, 0) = 0
close(3)                                = 0
gettimeofday({1325231183, 397422}, NULL) = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = 3
ioctl(3, PRESTO_SETOPT or RTC_RD_TIME, {tm_sec=23, tm_min=46, tm_hour=7, tm_mday=30, tm_mon=11, tm_year=111, ...}) = 0
close(3)                                = 0
time(NULL)                              = 1325231183
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
time(NULL)                              = 1325231183
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
time(NULL)                              = 1325231183
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
open("/etc/TZ", O_RDONLY)               = 3
read(3, "UTC\n", 68)                    = 4
close(3)                                = 0
write(1, "Fri Dec 30 07:46:23 2011  -1.996"..., 44Fri Dec 30 07:46:23 2011  -1.996877 seconds
) = 44
exit_group(0)                           = ?

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

[Xiangfu Liu]

Hi

After I update kernel to linux v3.2.1. the problem still there.
Please give me some advice, how to fix this issue?

Thanks

On 12/30/2011 04:31 PM, Xiangfu Liu wrote:
> Hi John Stultz
>
> I meet the same problem on MIPS jz4740, here is the step I try to find out the problem:
>
> 1. when I direct run 'hwclock' it will give
>     "select() to /dev/rtc0 to wait for clock tick timed out"
>     attachment 'hwclock.time.out' is the strace log
>
> 2. run 'rtctest' program. it works fine. the output is here[1]
>
> 3. after 'rtctest', run 'hwclock' again. then it works fine
>     attachment 'hwclock.wors' is the strace log
>
> without 'rtctest' run first. 'hwclock' never works.
> the hwclock works fine in 2.6.27.6, failed under '3.0.0'
>
> Please give me some tips how to fix this problem. shoule I modify the driver code
> or is that relate to 'CONFIG_RTC_INTF_DEV_UIE_EMUL'?
>
> thanks in advance.
> xiangfu

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

[John Stultz]

On 12/30/2011 12:31 AM, Xiangfu Liu wrote:
> I meet the same problem on MIPS jz4740, here is the step I try to find 
> out the problem:
>
> 1. when I direct run 'hwclock' it will give
>    "select() to /dev/rtc0 to wait for clock tick timed out"
>    attachment 'hwclock.time.out' is the strace log
>
> 2. run 'rtctest' program. it works fine. the output is here[1]
>
> 3. after 'rtctest', run 'hwclock' again. then it works fine
>    attachment 'hwclock.wors' is the strace log
>
> without 'rtctest' run first. 'hwclock' never works.
> the hwclock works fine in 2.6.27.6, failed under '3.0.0'
>
> Please give me some tips how to fix this problem. shoule I modify the 
> driver code
> or is that relate to 'CONFIG_RTC_INTF_DEV_UIE_EMUL'?

Sorry I missed this email originally, and thank you for pinging me.

Is CONFIG_RTC_INTF_DEV_UIE_EMUL set in the config you're seeing this 
with? Does disabling it change the behavior?

Just a shot in the dark, but does the following help at all?
thanks
-john

Signed-off-by: John Stultz<john.stultz@linaro.org>

diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c

index 05ab227..c6c81ba 100644

--- a/drivers/rtc/rtc-jz4740.c

+++ b/drivers/rtc/rtc-jz4740.c

@@ -171,7 +171,8 @@ static int jz4740_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)

  static int jz4740_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)

  {

      struct jz4740_rtc *rtc = dev_get_drvdata(dev);

-    return jz4740_rtc_ctrl_set_bits(rtc, JZ_RTC_CTRL_AF_IRQ, enable);

+    return jz4740_rtc_ctrl_set_bits(rtc,

+                 JZ_RTC_CTRL_AE |JZ_RTC_CTRL_AF_IRQ, enable);

  }

  

  static struct rtc_class_ops jz4740_rtc_ops = {

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

[Xiangfu Liu]

Hi John

Thanks for reply. the patch is not working. I found a work around.
checkout this patch:
  http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/5a49fe26a5cefe0b1f8dcff1315cf3f2e12bc8f6/target/linux/xburst/patches-3.2/0029-rtc-jz4740-fix-hwclock-give-time-out.patch

after apply this patch. the hwclock worksf ine again. but it is may not a good patch.

Please take a look give me some advice. Thanks John
Xiangfu

On 03/17/2012 09:10 AM, John Stultz wrote:
> On 12/30/2011 12:31 AM, Xiangfu Liu wrote:
>> I meet the same problem on MIPS jz4740, here is the step I try to find out the problem:
>>
>> 1. when I direct run 'hwclock' it will give
>> "select() to /dev/rtc0 to wait for clock tick timed out"
>> attachment 'hwclock.time.out' is the strace log
>>
>> 2. run 'rtctest' program. it works fine. the output is here[1]
>>
>> 3. after 'rtctest', run 'hwclock' again. then it works fine
>> attachment 'hwclock.wors' is the strace log
>>
>> without 'rtctest' run first. 'hwclock' never works.
>> the hwclock works fine in 2.6.27.6, failed under '3.0.0'
>>
>> Please give me some tips how to fix this problem. shoule I modify the driver code
>> or is that relate to 'CONFIG_RTC_INTF_DEV_UIE_EMUL'?
>
> Sorry I missed this email originally, and thank you for pinging me.
>
> Is CONFIG_RTC_INTF_DEV_UIE_EMUL set in the config you're seeing this with? Does disabling it change the behavior?
>
> Just a shot in the dark, but does the following help at all?
> thanks
> -john
>
> Signed-off-by: John Stultz<john.stultz@linaro.org>
>
> diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
>
> index 05ab227..c6c81ba 100644
>
> --- a/drivers/rtc/rtc-jz4740.c
>
> +++ b/drivers/rtc/rtc-jz4740.c
>
> @@ -171,7 +171,8 @@ static int jz4740_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
>
> static int jz4740_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
>
> {
>
> struct jz4740_rtc *rtc = dev_get_drvdata(dev);
>
> - return jz4740_rtc_ctrl_set_bits(rtc, JZ_RTC_CTRL_AF_IRQ, enable);
>
> + return jz4740_rtc_ctrl_set_bits(rtc,
>
> + JZ_RTC_CTRL_AE |JZ_RTC_CTRL_AF_IRQ, enable);
>
> }
>
>
>
> static struct rtc_class_ops jz4740_rtc_ops = {
>
>
>
>