* CONFIG_DEVMEM=y breaks gettimeofday in next-20250708
[not found] <20250701-vdso-auxclock-v1-6-df7d9f87b9b8@linutronix.de>
@ 2025-07-09 12:42 ` Bert Karwatzki
2025-07-09 13:17 ` Thomas Weißschuh
0 siblings, 1 reply; 3+ messages in thread
From: Bert Karwatzki @ 2025-07-09 12:42 UTC (permalink / raw)
To: linux-kernel
Cc: Bert Karwatzki, linux-next, Thomas Weißschuh,
Thomas Gleixner
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
These errors do not occur when using v6.16-rc5 with CONFIG_DEVMEM=y, and are 100%
reproducible so are not related to the RAM error.
I bisected the issue in between
v6.16-rc5 and next-20250708 and found commit fcc8e46f768f ("vdso/gettimeofday:
Return bool from clock_gettime() helpers") as the first bad commit.
Bert Karwatzki
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708
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
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Weißschuh @ 2025-07-09 13:17 UTC (permalink / raw)
To: Bert Karwatzki; +Cc: linux-kernel, linux-next, Thomas Gleixner
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.
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?
> These errors do not occur when using v6.16-rc5 with CONFIG_DEVMEM=y, and are 100%
> reproducible so are not related to the RAM error.
>
> I bisected the issue in between
> v6.16-rc5 and next-20250708 and found commit fcc8e46f768f ("vdso/gettimeofday:
> Return bool from clock_gettime() helpers") as the first bad commit.
[0] https://lore.kernel.org/lkml/e8c6b9a7-eaa6-4947-98e1-9d6fecc958d4@samsung.com/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708
2025-07-09 13:17 ` Thomas Weißschuh
@ 2025-07-09 16:40 ` Bert Karwatzki
0 siblings, 0 replies; 3+ messages in thread
From: Bert Karwatzki @ 2025-07-09 16:40 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: linux-kernel, linux-next, Thomas Gleixner, spasswolf
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-09 16:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox