Hi,
I am doing some investigations into a problem that has been reported
with RTC on some Dell Machines. It seems to be relate exclusively to
machines that have the 8208CA ICH3 I/O Hub. I have been able to
reproduce this on a Dell 8400, which I have access to today while I am
on holidays. The output of lspci -v -x is attached.
For reference this problem is being tracked at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277298
There are various user-space work arounds for this problem, but I would
like to offer what I have discovered from a brief poke-around in rtc.c.
An strace of hwclock looks a bit like this
open("/dev/rtc", O_RDONLY|O_LARGEFILE);
ioctl(3, RTC_UIE_ON, 0);
read(3, ...
the read never returns.
If my reading of the code is correct, what is occuring is that
rtc_read() is in its do/while loop, waiting to be rescheduled. This
should occur once an interupt is handled by rtc_interrupt(), but I guess
that this is not occuring. Any insights into why this might be happening
would be more than welcome.
The kernel in question is Ubuntu's 2.6.8.1, the rtc.c is identical from
what was in linus' tree this morning. The config is also attached.
Please CC me on replies
Thanks
--
Horms
At a glance this sounds like the case of having the HPET enabled causes
the RTC IRQ functionality to become crippled or non-functional. The
concept of hwclock using alarm or similar to handle broken and
misconfigured hardware is a sensible idea.
Paul.
--- Horms <[email protected]> wrote:
> Hi,
>
> I am doing some investigations into a problem that has been reported
> with RTC on some Dell Machines. It seems to be relate exclusively to
> machines that have the 8208CA ICH3 I/O Hub. I have been able to
> reproduce this on a Dell 8400, which I have access to today while I am
> on holidays. The output of lspci -v -x is attached.
>
> For reference this problem is being tracked at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277298
>
> There are various user-space work arounds for this problem, but I would
> like to offer what I have discovered from a brief poke-around in rtc.c.
>
> An strace of hwclock looks a bit like this
>
> open("/dev/rtc", O_RDONLY|O_LARGEFILE);
> ioctl(3, RTC_UIE_ON, 0);
> read(3, ...
>
> the read never returns.
>
> If my reading of the code is correct, what is occuring is that
> rtc_read() is in its do/while loop, waiting to be rescheduled. This
> should occur once an interupt is handled by rtc_interrupt(), but I guess
> that this is not occuring. Any insights into why this might be happening
> would be more than welcome.
>
> The kernel in question is Ubuntu's 2.6.8.1, the rtc.c is identical from
> what was in linus' tree this morning. The config is also attached.
>
> Please CC me on replies
>
> Thanks
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Tue, May 03, 2005 at 08:25:41PM -0700, Paul Gortmaker wrote:
> At a glance this sounds like the case of having the HPET enabled causes
> the RTC IRQ functionality to become crippled or non-functional. The
> concept of hwclock using alarm or similar to handle broken and
> misconfigured hardware is a sensible idea.
Thanks for the advice. I guess I was holding onto an idea
that it could be fixed in the kernel - but you are right,
the user-space work around is a simple solution to this
buggy hardware.
--
Horms