From: Bert Karwatzki <spasswolf@web•de>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix•de>
Cc: linux-kernel@vger•kernel.org, linux-next@vger•kernel.org,
Thomas Gleixner <tglx@linutronix•de>,
spasswolf@web•de
Subject: Re: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708
Date: Wed, 09 Jul 2025 18:40:15 +0200 [thread overview]
Message-ID: <5222dd9170d60b2ae93e24ce5d103c44cc1e36ea.camel@web.de> (raw)
In-Reply-To: <20250709150929-7198f921-5b85-461a-acc1-ccc04e9adbab@linutronix.de>
Am Mittwoch, dem 09.07.2025 um 15:17 +0200 schrieb Thomas Weißschuh:
> Hi Bert,
>
> On Wed, Jul 09, 2025 at 02:42:15PM +0200, Bert Karwatzki wrote:
> > Recently I found that my RAM has an error (memtest86+ reproducibly reports
> > a failing address) (this error may lead to random crashes every few days).
> > To further investigate the issue I tried using memtester which needs access
> > to /dev/mem and so I recompiled linux next-20250708 with CONFIG_DEMEM=y
> > and found a strange and unusual side effect:
> >
> > a) the time displayed by xfce is stuck at 1.1.1970 01:00 (UTC + 1)
> > b) most certificates in firefox-esr fail to work due to the date being 1.1.1970
> > (this includes www.google.de, www.duckduckgo.com, wikipedia and youtube and many more)
> > c) some certificates in firefox-esr still work (kernel.org, xkcd.com, www.spiegel.de)
> > d) the shell built-in time (and also /usr/bin/time) fail to work, e.g.
> > $ time sleep 5
> > real 0m0,000s
> > user 0m0,000s
> > sys 0m0,002s
> > (even though it actually take 5 seconds for this)
> > e) date still works correctly, e.g.
> > $ date
> > Mi 9. Jul 11:51:20 CEST 2025
> > f) This example program
> >
> > #include <stdlib.h>
> > #include <stdio.h>
> > #include <sys/time.h>
> >
> > int main()
> > {
> > int ret;
> > struct timeval tv;
> > struct timezone tz;
> >
> > ret = gettimeofday(&tv, &tz);
> > printf("gettimeofday returns ret = %d, tv.tv_sec = %lu tv.tv_usec = %lu\n", ret, tv.tv_sec, tv.tv_usec);
> >
> > return 0;
> > }
> >
> > gives the following output on affected versions:
> >
> > $
> > gettimeofday returns ret = 0, tv.tv_sec = 0 tv.tv_usec = 0
>
> Thanks for the report. Can you try the fix posted by Marek [0]?
> It looks like the same issue where the vDSO fastpath is unavailable on your
> hardware but I broke the check for it.
Yes, this fixes the issue for me.
> If it is the same issue it still leaves the question why the fastpath is
> broken by CONFIG_DEVMEM. Can you describe your setup a bit?
> Are there any entries in dmesg about the tsc or the clocksource subsystem?
I use a MSI Alpha 15 B5EEK/MS-158L amd64 laptop (AMD Ryzen 7 5800H) running debian sid. When booting
without "tsc=unstable" I get this message in dmesg (this is from next-20250708 with CONFIG_DEVMEM=y):
[ C7] clocksource: timekeeping watchdog on CPU7: Marking clocksource 'tsc' as unstable because the skew is too large:
[ C7] clocksource: 'hpet' wd_nsec: 495997815 wd_now: 36f24f3 wd_last: 302c799 mask: ffffffff
[ C7] clocksource: 'tsc' cs_nsec: 497721239 cs_now: 1ea2752100 cs_last: 1e43b3e700 mask: ffffffffffffffff
[ C7] clocksource: Clocksource 'tsc' skewed 1723424 ns (1 ms) over watchdog 'hpet' interval of 495997815 ns (495 ms)
[ C7] clocksource: 'hpet' (not 'tsc') is current clocksource.
[ C7] tsc: Marking TSC unstable due to clocksource watchdog
[ T233] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
[ T233] sched_clock: Marking unstable (4040049255, 1223348)<-(4058551237, -15591933)
I usually boot with "tsc=unstable" but the issue occurs there, too. I can't say yet why
this only occurs with CONFIG_DEVMEM=y.
Bert Karwatzki
prev parent reply other threads:[~2025-07-09 16:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250701-vdso-auxclock-v1-6-df7d9f87b9b8@linutronix.de>
2025-07-09 12:42 ` CONFIG_DEVMEM=y breaks gettimeofday in next-20250708 Bert Karwatzki
2025-07-09 13:17 ` Thomas Weißschuh
2025-07-09 16:40 ` Bert Karwatzki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5222dd9170d60b2ae93e24ce5d103c44cc1e36ea.camel@web.de \
--to=spasswolf@web$(echo .)de \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=tglx@linutronix$(echo .)de \
--cc=thomas.weissschuh@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox