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). Regards, D 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. > > > >
