lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <45BEA162.3030204@teksavvy.com>
Date:	Mon, 29 Jan 2007 20:37:38 -0500
From:	Yavuz Onder <yavuz@...savvy.com>
To:	linux-kernel@...r.kernel.org
CC:	yavuz@...savvy.com
Subject: Re: 2.6.19.2: bad reads/writes from/to CMOS clock


I have since found out that SMP kernels should(must?) have Enhanced RTC 
support built-in.

It is stated in kernel config help for Enhanced RTC support, and I found 
a number of references on the net as well.

Now I wonder why selecting SMP does not set Enhanced RTC support to "Y" 
automatically?

I am building a kernel right now, and will monitor for a week or so, 
then come back and report if it removes the problem.

Yavuz

yavuz@...savvy.com wrote:
> Hi everyone,
>
> I am running 2.6.19.2 kernel from kernel.org.
>
> This is my first SMP kernel. 
>
> The problem I describe below has not happend with non-SMP kernels ever...
>
> I have installed my new AMD64 x2 4800 CPU just a few days ago. My mobo is Asus A8N SLI
> (Nvidia chipset).
>
> My problem with this new setup is that my CMOS clock is thrown off by varying 
> amounts of time. I have seen system times as long as ten months into future, and as
> long as 25 days in the past. At the moment my system clock has correct 
> hh:mm:ss, but it shows the date Jan 1st, instead of correct 25th.
>
> In last few days have systematically checked CMOS clock after shutdown and before
> boot-up.
>
> I have observed CMOS clock set to a wrong value, immediately after shutdown. 
> I also ended up with a wrong system time following a boot after verifying 
> correctness of the CMOS clock.
>
> Problem does not happen 100% of the time. But 6-7 times in a week is bad 
> enough. 
>
> I searched mailing list archives, and found some NMI-RTC race condition discussion, 
> and some other discussions about timers not running, clock ticks being missed
> etc. But they were all at least one year old. The fixes to those should have found
> their way into 2.6.19 kernels.
>
> I would appreciate any ideas on how to follow-up on this problem. 
>
> I am eager to try things, collect data as needed. Just tell me what to do.
>
> Thanks in advance.
>
>
>
>
> Yavuz Onder
>
>   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ