* select() to /dev/rtc0 to wait for clock tick timed out @ 2011-08-19 4:16 Matt Turner 2011-08-19 17:23 ` john stultz 2011-08-19 18:07 ` john stultz 0 siblings, 2 replies; 17+ messages in thread From: Matt Turner @ 2011-08-19 4:16 UTC (permalink / raw) To: john stultz; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 4:16 select() to /dev/rtc0 to wait for clock tick timed out Matt Turner @ 2011-08-19 17:23 ` john stultz 2011-08-19 18:07 ` john stultz 1 sibling, 0 replies; 17+ messages in thread From: john stultz @ 2011-08-19 17:23 UTC (permalink / raw) To: Matt Turner; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 4:16 select() to /dev/rtc0 to wait for clock tick timed out Matt Turner 2011-08-19 17:23 ` john stultz @ 2011-08-19 18:07 ` john stultz 2011-08-19 19:41 ` Matt Turner 1 sibling, 1 reply; 17+ messages in thread From: john stultz @ 2011-08-19 18:07 UTC (permalink / raw) To: Matt Turner; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 18:07 ` john stultz @ 2011-08-19 19:41 ` Matt Turner 2011-08-19 19:59 ` john stultz 0 siblings, 1 reply; 17+ messages in thread From: Matt Turner @ 2011-08-19 19:41 UTC (permalink / raw) To: john stultz; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 19:41 ` Matt Turner @ 2011-08-19 19:59 ` john stultz 2011-08-19 20:06 ` Matt Turner 2011-12-30 8:31 ` Xiangfu Liu 0 siblings, 2 replies; 17+ messages in thread From: john stultz @ 2011-08-19 19:59 UTC (permalink / raw) To: Matt Turner; +Cc: linux-mips 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; } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 19:59 ` john stultz @ 2011-08-19 20:06 ` Matt Turner 2011-08-19 20:34 ` john stultz 2011-12-30 8:31 ` Xiangfu Liu 1 sibling, 1 reply; 17+ messages in thread From: Matt Turner @ 2011-08-19 20:06 UTC (permalink / raw) To: john stultz; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out @ 2011-08-19 20:34 ` john stultz 0 siblings, 0 replies; 17+ messages in thread From: john stultz @ 2011-08-19 20:34 UTC (permalink / raw) To: Matt Turner; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out @ 2011-08-19 20:34 ` john stultz 0 siblings, 0 replies; 17+ messages in thread From: john stultz @ 2011-08-19 20:34 UTC (permalink / raw) To: Matt Turner; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 20:34 ` john stultz (?) @ 2011-08-19 20:56 ` Matt Turner 2011-08-19 21:21 ` john stultz -1 siblings, 1 reply; 17+ messages in thread From: Matt Turner @ 2011-08-19 20:56 UTC (permalink / raw) To: john stultz; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 20:56 ` Matt Turner @ 2011-08-19 21:21 ` john stultz 2011-08-19 21:48 ` Matt Turner 0 siblings, 1 reply; 17+ messages in thread From: john stultz @ 2011-08-19 21:21 UTC (permalink / raw) To: Matt Turner; +Cc: linux-mips 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 21:21 ` john stultz @ 2011-08-19 21:48 ` Matt Turner 2011-08-25 17:30 ` Matt Turner 0 siblings, 1 reply; 17+ messages in thread From: Matt Turner @ 2011-08-19 21:48 UTC (permalink / raw) To: john stultz; +Cc: linux-mips [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 21:48 ` Matt Turner @ 2011-08-25 17:30 ` Matt Turner 2011-08-26 16:05 ` Atsushi Nemoto 0 siblings, 1 reply; 17+ messages in thread From: Matt Turner @ 2011-08-25 17:30 UTC (permalink / raw) To: john stultz; +Cc: linux-mips, rtc-linux, Alessandro Zummo 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-25 17:30 ` Matt Turner @ 2011-08-26 16:05 ` Atsushi Nemoto 0 siblings, 0 replies; 17+ messages in thread From: Atsushi Nemoto @ 2011-08-26 16:05 UTC (permalink / raw) To: mattst88; +Cc: johnstul, linux-mips, rtc-linux, a.zummo 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-08-19 19:59 ` john stultz 2011-08-19 20:06 ` Matt Turner @ 2011-12-30 8:31 ` Xiangfu Liu 2012-03-16 8:53 ` Xiangfu Liu 2012-03-17 1:10 ` John Stultz 1 sibling, 2 replies; 17+ messages in thread From: Xiangfu Liu @ 2011-12-30 8:31 UTC (permalink / raw) To: john stultz; +Cc: Matt Turner, linux-mips, jz47xx-kernel, rtc-linux [-- 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) = ? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-12-30 8:31 ` Xiangfu Liu @ 2012-03-16 8:53 ` Xiangfu Liu 2012-03-17 1:10 ` John Stultz 1 sibling, 0 replies; 17+ messages in thread From: Xiangfu Liu @ 2012-03-16 8:53 UTC (permalink / raw) To: john stultz; +Cc: Matt Turner, linux-mips, rtc-linux 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2011-12-30 8:31 ` Xiangfu Liu 2012-03-16 8:53 ` Xiangfu Liu @ 2012-03-17 1:10 ` John Stultz 2012-03-18 7:03 ` Xiangfu Liu 1 sibling, 1 reply; 17+ messages in thread From: John Stultz @ 2012-03-17 1:10 UTC (permalink / raw) To: Xiangfu Liu; +Cc: Matt Turner, linux-mips, jz47xx-kernel, rtc-linux 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 = { ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: select() to /dev/rtc0 to wait for clock tick timed out 2012-03-17 1:10 ` John Stultz @ 2012-03-18 7:03 ` Xiangfu Liu 0 siblings, 0 replies; 17+ messages in thread From: Xiangfu Liu @ 2012-03-18 7:03 UTC (permalink / raw) To: John Stultz Cc: Matt Turner, linux-mips, jz47xx-kernel, rtc-linux, Lars-Peter Clausen 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 = { > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-03-18 7:03 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-19 4:16 select() to /dev/rtc0 to wait for clock tick timed out Matt Turner 2011-08-19 17:23 ` john stultz 2011-08-19 18:07 ` john stultz 2011-08-19 19:41 ` Matt Turner 2011-08-19 19:59 ` john stultz 2011-08-19 20:06 ` Matt Turner 2011-08-19 20:34 ` john stultz 2011-08-19 20:34 ` john stultz 2011-08-19 20:56 ` Matt Turner 2011-08-19 21:21 ` john stultz 2011-08-19 21:48 ` Matt Turner 2011-08-25 17:30 ` Matt Turner 2011-08-26 16:05 ` Atsushi Nemoto 2011-12-30 8:31 ` Xiangfu Liu 2012-03-16 8:53 ` Xiangfu Liu 2012-03-17 1:10 ` John Stultz 2012-03-18 7:03 ` Xiangfu Liu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.