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

[John Paul Adrian Glaubitz]

Hi Nick,

I have not used the regression tracker before, so let's give it a try:

#regzbot ^introduced: 795cda8338eab036013314dbc0b04aae728880ab

Adrian

On Tue, 2025-11-25 at 22:18 -0500, Nick Bowler wrote:
> Any thoughts?
> 
> 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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913