<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<atom:link href="http://dev1galaxy.org/extern.php?action=feed&amp;tid=5737&amp;type=rss" rel="self" type="application/rss+xml" />
		<title><![CDATA[Dev1 Galaxy Forum / [SOLVED] rtc clock problem]]></title>
		<link>http://dev1galaxy.org/viewtopic.php?id=5737</link>
		<description><![CDATA[The most recent posts in [SOLVED] rtc clock problem.]]></description>
		<lastBuildDate>Sun, 04 Jun 2023 13:51:30 +0000</lastBuildDate>
		<generator>FluxBB</generator>
		<item>
			<title><![CDATA[Re: [SOLVED] rtc clock problem]]></title>
			<link>http://dev1galaxy.org/viewtopic.php?pid=42483#p42483</link>
			<description><![CDATA[<p>Thank you.</p><p>My current remedy is the following.&#160; Create a file /etc/elogind/system-sleep/ntp.sh<br />with the following contents:</p><div class="codebox"><pre><code>#!/bin/sh
case $1 in
        pre)
                /etc/init.d/ntpsec stop
                /bin/sleep 1
                ;;
        post)
                /usr/sbin/ntpd -gq
                /etc/init.d/ntpsec start
                ;;
esac</code></pre></div><p>This seems to set the correct time on resume.</p>]]></description>
			<author><![CDATA[dummy@example.com (bigcat)]]></author>
			<pubDate>Sun, 04 Jun 2023 13:51:30 +0000</pubDate>
			<guid>http://dev1galaxy.org/viewtopic.php?pid=42483#p42483</guid>
		</item>
		<item>
			<title><![CDATA[Re: [SOLVED] rtc clock problem]]></title>
			<link>http://dev1galaxy.org/viewtopic.php?pid=42480#p42480</link>
			<description><![CDATA[<p>Some thoughts:<br />Correct BIOS time and non-fucntional RTC sounds contrary. Both are the same device, aren&#039;t they?</p><p>Debian shows correct time: Probably systemd-timesync forces a clock-update. ntpd could do so too with addional switches. google found e.g. <a href="https://askubuntu.com/questions/254826/how-to-force-a-clock-update-using-ntp" rel="nofollow">https://askubuntu.com/questions/254826/ … -using-ntp</a></p><p><span class="bbc">cat /proc/interrupts|grep -i rtc</span> on my 97x-based mainboard looks almost equal, only one of the four zeros is not zero. Just to mention, whatever it means.</p>]]></description>
			<author><![CDATA[dummy@example.com (delgado)]]></author>
			<pubDate>Sun, 04 Jun 2023 09:56:47 +0000</pubDate>
			<guid>http://dev1galaxy.org/viewtopic.php?pid=42480#p42480</guid>
		</item>
		<item>
			<title><![CDATA[Re: [SOLVED] rtc clock problem]]></title>
			<link>http://dev1galaxy.org/viewtopic.php?pid=42473#p42473</link>
			<description><![CDATA[<p>BTW I believe this problem is related to this particular hardware and not to devuan.&#160; I have 8 machines with different hardware at home, all running the same system, and this one is the only machine that cannot set/update the hardware clock.&#160; I am just not sure how debian managed to work around this.</p>]]></description>
			<author><![CDATA[dummy@example.com (bigcat)]]></author>
			<pubDate>Sat, 03 Jun 2023 15:39:43 +0000</pubDate>
			<guid>http://dev1galaxy.org/viewtopic.php?pid=42473#p42473</guid>
		</item>
		<item>
			<title><![CDATA[Re: [SOLVED] rtc clock problem]]></title>
			<link>http://dev1galaxy.org/viewtopic.php?pid=42472#p42472</link>
			<description><![CDATA[<div class="quotebox"><cite>trinidad wrote:</cite><blockquote><div><p>Does the board have a separate coin cell battery? Put a new one in if it does. CR2032 is the most common.</p><p>TC</p></div></blockquote></div><p>Thanks.&#160; I could but not sure this will fix the problem.&#160; I can see that the BIOS is keeping the time correctly.&#160; I unplugged it from the wall outlet for a night, and it had a correct UTC time in the BIOS when it booted in the morning.</p>]]></description>
			<author><![CDATA[dummy@example.com (bigcat)]]></author>
			<pubDate>Sat, 03 Jun 2023 15:32:29 +0000</pubDate>
			<guid>http://dev1galaxy.org/viewtopic.php?pid=42472#p42472</guid>
		</item>
		<item>
			<title><![CDATA[Re: [SOLVED] rtc clock problem]]></title>
			<link>http://dev1galaxy.org/viewtopic.php?pid=42471#p42471</link>
			<description><![CDATA[<p>Does the board have a separate coin cell battery? Put a new one in if it does. CR2032 is the most common.</p><p>TC</p>]]></description>
			<author><![CDATA[dummy@example.com (trinidad)]]></author>
			<pubDate>Sat, 03 Jun 2023 15:23:54 +0000</pubDate>
			<guid>http://dev1galaxy.org/viewtopic.php?pid=42471#p42471</guid>
		</item>
		<item>
			<title><![CDATA[[SOLVED] rtc clock problem]]></title>
			<link>http://dev1galaxy.org/viewtopic.php?pid=42469#p42469</link>
			<description><![CDATA[<p>Greetings,</p><p>I have a chimaera system which I updated to testing.&#160; It is running a linux-image-6.1.0-9-amd64 kernel.&#160; This is a fairly old machine with i3-4130T cpu and asrock tx-97x board.&#160; I always suspected that the board was somewhat defective. I had to tweak a lot of things in the BIOS to get it running without locking up randomly.</p><p>I noticed that system time is off after resume, it is usually set to the time when the machine suspended.&#160; I think I traced this to it being unable to read the hardware clock:</p><div class="codebox"><pre><code># hwclock --get --directisa

# hwclock --get 
hwclock: select() to /dev/rtc0 to wait for clock tick timed out

# cat /proc/interrupts|grep -i rtc
  8:          0          0          0          0   IO-APIC   8-edge      rtc0</code></pre></div><p>The first command simply exits, and the second one gives a select() error.&#160; I am guessing select() system call is waiting for an rtc interrupt which it never receives.</p><p>This machine used to run debian with the same kernel, and the time was set correctly after a resume.&#160; I don&#039;t know if hwclock command could read the rtc because I had no reason to investigate. </p><p>So I have two questions;<br />(1) Any ideas about the time problem above?<br />(2) Does elogind support suspend/resume hooks as described here: <a href="https://wiki.gentoo.org/wiki/Elogind#Suspend.2FHibernate_Resume.2FThaw_hook_scripts" rel="nofollow">https://wiki.gentoo.org/wiki/Elogind#Su … ok_scripts</a> and if yes, what is the location of those scripts?&#160; This would allow me to use ntpdate on resume to set a correct clock, and to restart ntpd, which at the moment refuses to function with such a large clock drift.&#160; </p><p>Thanks.</p>]]></description>
			<author><![CDATA[dummy@example.com (bigcat)]]></author>
			<pubDate>Sat, 03 Jun 2023 15:11:20 +0000</pubDate>
			<guid>http://dev1galaxy.org/viewtopic.php?pid=42469#p42469</guid>
		</item>
	</channel>
</rss>
