On 07/31/2012 02:35 AM, John Stultz wrote:
> So CAI Qian noticed recent boot trouble on a machine that had its CMOS
> clock configured for the year 8200.
> See: http://lkml.org/lkml/2012/7/29/188
In case anyone was wondering, the system's date was very much screwed up:
│ System Time ..
On 07/30/2012 11:35 PM, John Stultz wrote:
I've also only been able to lightly test. If you want to try this out
you can add the following to timekeeping_init after the
read_persistent_clock() call:
now.tv_sec = 19646928LL;
Prarit noted that I implemented these patches against 3.5 (w
On 07/31/2012 02:54 AM, James Courtier-Dutton wrote:
On 31 July 2012 07:35, John Stultz wrote:
So CAI Qian noticed recent boot trouble on a machine that had its CMOS
clock configured for the year 8200.
See: http://lkml.org/lkml/2012/7/29/188
While running with a crazy CMOS clock isn't advised,
On 07/31/2012 04:31 AM, Josh Boyer wrote:
These should be CC'd to stable, right? CAI hit this with a 3.5-rcX
kernel, and the hrtimer stuff was backported to 3.4 and before I
thought.
Yes. But I'm just looking for feedback on the approach for now, this
isn't for submission yet.
thanks
-john
On Tue, Jul 31, 2012 at 2:35 AM, John Stultz wrote:
> So CAI Qian noticed recent boot trouble on a machine that had its CMOS
> clock configured for the year 8200.
> See: http://lkml.org/lkml/2012/7/29/188
>
> While running with a crazy CMOS clock isn't advised, and a simple
> "don't do that" might
On 31 July 2012 07:35, John Stultz wrote:
> So CAI Qian noticed recent boot trouble on a machine that had its CMOS
> clock configured for the year 8200.
> See: http://lkml.org/lkml/2012/7/29/188
>
> While running with a crazy CMOS clock isn't advised, and a simple
> "don't do that" might be reason
6 matches
Mail list logo
