RE: [Xen-devel] SOLVED - more bizarre rtc behaviour...

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

I put some debug statements in hwclock, and it told me that the CMOS
clock was _not_ in BCD mode. That one machine is a proliant 1600. Two
other proliant 1600's I have were in BCD mode, as were a few other linux
machines I had lying around.

I then hacked a bit further and had it write to the status register to
force it back into BCD mode.

And suddenly all is well again. It looks like Linux can handle a non-BCD
mode cmos clock in theory, but in practice something about it is
seriously broken.

James

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
> Sent: Wednesday, 28 December 2005 16:34
> To: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] more bizarre rtc behaviour...
> 
> >
> > > I have now noticed that with the rtc module loaded it
> > > exhibits the behaviour I described, but if I unload the rtc
> > > module, it all works fine. The underlying hardware clock
> > > appears to be fine.
> >
> > The rtc module isn't particularly useful in a xen environment. Any
> idea
> > what in user space is using /dec/rtc ?
> >
> 
> Nothing is loading it automatically, I just tried loading it as dom0
is
> SMP, and the linux config recommends using rtc.ko in an SMP
environment.
> I thought maybe that could be explaining my rtc kernel errors.
> 
> It just occurred to me that the counting sequence appeared to be a
> mismatched BCD HEX problem.... something about rtc is forcing an
> interpretation of a HEX value as BCD (or maybe my bios is storing
> something as HEX that should be BCD?), eg:
> 
> HEX | DEC | BCD
>  00 |  00 |  00
>  01 |  01 |  01
> ...............
>  08 |  08 |  08
>  09 |  09 |  09
>  0a |  10 |  00
>  0b |  11 |  11
>  0c |  12 |  12
>  0d |  13 |  13
>  0e |  14 |  14
>  0f |  15 |  15
>  10 |  16 |  10
>  11 |  17 |  11
> ...............
>  3a |  58 |  40
>  3b |  59 |  41
>  00 |  00 |  00
> 
> Could Xen be responsible for that in any way?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel