Re: PROBLEM: hwclock busted w/ M48T59 RTC (regression)

[Thorsten Leemhuis]

Lo!

On 11/26/25 04:18, Nick Bowler wrote:
> Any thoughts?

Not really, just a vague idea (and reminder, this is not my area or
expertise, I'm just tracking regressions):

Two fixes were proposed for the culprit, see:

https://lore.kernel.org/all/BN0PR08MB69510928028C933749F4139383D1A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
https://lore.kernel.org/all/BN0PR08MB6951415A751F236375A2945683D1A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

Wondering if they might help. Esben might have an idea, but in case
Esben does not reply maybe just give them a spin if you have a minute.

Ciao, Thorsten

> The problem is still present in 6.18-rc7 and reverting the commit
> indicated below still fixes it.
> 
> I am also seeing the same failure on a totally different system with
> Dallas DS1286 RTC, which is also fixed by reverting this commit.
> 
> Since the initial report this regression has been further backported
> to all the remaining longterm kernel series.
> 
> Thanks,
>   Nick
> 
> On Thu, Oct 23, 2025 at 12:45:13AM -0400, Nick Bowler wrote:
>> Hi,
>>
>> 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...]
>>   hwclock: select() to /dev/rtc0 to wait for clock tick timed out
>>
>> On prior kernels, there is no problem:
>>
>>   # hwclock
>>   2025-10-22 22:21:04.806992-04:00
>>
>> I reproduced the same failure on 6.18-rc2 and bisected to this commit:
>>
>>   commit 795cda8338eab036013314dbc0b04aae728880ab
>>   Author: Esben Haabendal <esben@xxxxxxxxxx>
>>   Date:   Fri May 16 09:23:35 2025 +0200
>>   
>>       rtc: interface: Fix long-standing race when setting alarm
>>
>> This commit was backported to all current 6.x stable branches,
>> as well as 5.15.x, so they all have the same regression.
>>
>> Reverting this commit on top of 6.18-rc2 corrects the problem.
>>
>> Let me know if you need any more info!
>>
>> Thanks,
>>   Nick
> 
>