* 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