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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
