[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libreboot] Reading the hardware clock

From: Daniel Tarrero
Subject: Re: [Libreboot] Reading the hardware clock
Date: Mon, 01 Feb 2016 10:04:26 +0100

oh! that's sounds good :)

so there seem to be a problem in libreboot, already solved in nightly
build, that causes this "reading clock" problem regression (because it
was working till the last update).

Weird for me that you had to set "gfx_uma_size" and this help with the
issue. Probably the memory assigned to graphics and clock are one
following the other; that could explain why a close definition of
graphics UMA allow you to read hw clock. I dont really know!

The workaround is not bad (usign directisa with hwclock script), and u
can keep your current "buggy" kernel and make this command/script run
somewhere in the boot process. This isn't perfect; time should be read
in the very early boot process.

With a fresh "nightly build" of libreboot this problem seem to be
solved, so i will give it a try (and when usign systemd this seem the
best way to solve this). 


El vie, 29-01-2016 a las 17:44 +0100, Dominic Westreicher escribió:
> Hello,
> I have had the same Problem, it occured with Linux 5.3.
> The thing that helped in my case was using the latest nightly of Libreboot.
> I don't know which change was responsible for it. I went and flashed it, 
> then starting nvramtool, getting a checksum error there, i set a 
> Parameter (gfx_uma_size which was always resetting to 32 M for me).
> After rebooting the system was able to read/write the clock again and 
> the parameter was saved.
> Maybe that helps.
> Am 2016-01-29 um 16:16 schrieb Bruno Dantas:
> > Thanks, Alarig.
> >
> > While I'm not a fan of systemd, I do not want to make big changes to my 
> > init system just to fix this one issue. I'd rather "surgically" fix this 
> > problem and leave all the working parts of the init system alone.
> >

reply via email to

[Prev in Thread] Current Thread [Next in Thread]