lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <35bd11bf-23fa-4ce9-96fb-d10ad6cd546e@leemhuis.info>
Date: Thu, 6 Nov 2025 11:25:55 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Nick Bowler <nbowler@...conx.ca>, Esben Haabendal <esben@...nix.com>
Cc: linux-kernel@...r.kernel.org, regressions@...ts.linux.dev,
 linux-rtc@...r.kernel.org, stable@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: PROBLEM: hwclock busted w/ M48T59 RTC (regression)

Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

Just wondering: was this fixed in between? Just asking, as I noticed the
culprit was backported to various stable/longterm series recently

Ciao, Thorsten

On 10/23/25 15:39, Nick Bowler wrote:
> On Thu, Oct 23, 2025 at 07:21:21AM +0000, Esben Haabendal wrote:
>> On Thursday, 23 October 2025 at 06:45, Nick Bowler <nbowler@...conx.ca> wrote:
>>
>>> After a stable kernel update, the hwclock command seems no longer
>>> functional on my SPARC system with an ST M48T59Y-70PC1 RTC:
>>>
>>> # hwclock
>>> [...long delay...]
>>
>> I assume this is 10 seconds long.
> 
> Yeah, about that.
> 
>>> hwclock: select() to /dev/rtc0 to wait for clock tick timed out
>>
>> And this is 100% reproducible, or does it sometimes work and sometimes fail?
> 
> It fails every time.
> 
>> Are you using the util-linux hwclock command? Which version?
> 
> hwclock from util-linux 2.40.2
> 
>> Do you have CONFIG_RTC_INTF_DEV_UIE_EMUL enabled?
> 
> No, this option is not enabled.
> 
>> Can you run `hwclock --verbose`, both with and without the reverted commit,
>> and send the output from that?
> 
> 6.18-rc2 (broken):
> 
>   # hwclock --verbose
>   hwclock from util-linux 2.40.2
>   System Time: 1761226454.799573
>   Trying to open: /dev/rtc0
>   Using the rtc interface to the clock.
>   Last drift adjustment done at 1657523820 seconds after 1969
>   Last calibration done at 1657523820 seconds after 1969
>   Hardware clock is on UTC time
>   Assuming hardware clock is kept in UTC time.
>   Waiting for clock tick...
>   hwclock: select() to /dev/rtc0 to wait for clock tick timed out
>   ...synchronization failed
> 
> 6.18-rc2 w/ revert (working):
> 
>   # hwclock --verbose
>   hwclock from util-linux 2.40.2
>   System Time: 1761226685.238753
>   Trying to open: /dev/rtc0
>   Using the rtc interface to the clock.
>   Last drift adjustment done at 1657523820 seconds after 1969
>   Last calibration done at 1657523820 seconds after 1969
>   Hardware clock is on UTC time
>   Assuming hardware clock is kept in UTC time.
>   Waiting for clock tick...
>   ioctl(3, RTC_UIE_ON, 0): Input/output error
>   Waiting in loop for time from /dev/rtc0 to change
>   ...got clock tick
>   Time read from Hardware Clock: 2025/10/23 13:38:06
>   Hw clock time : 2025/10/23 13:38:06 = 1761226686 seconds since 1969
>   Time since last adjustment is 103702866 seconds
>   Calculated Hardware Clock drift is 0.000000 seconds
>   2025-10-23 09:38:05.239100-04:00
> 
> Thanks,
>   Nick
> 


#regzbot poke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ