Re: [PATCH 4/8] time: Condense timekeeper.xtime into xtime_sec

John Stultz [off-list ref] writes:

I'm not very familiar w/ the iBook hardware, but does it use a 
clocksource, or does it use arch_gettimeoffset()?

clocksource: timebase mult[3640e38e] shift[24] registered

I suspect that the casting has avoided clipping some strange values from 
the persistent clock.

That's my guess as well.

Could you try with the following patch against Linus' HEAD? I suspect it 
will let the box resume (although it will seem as though no time was 
spent in resume) and then let me know what the JDB lines print out?

JDB: suspend_time: 1345491706:0  resume_time: 1345491737:0
JDB: Trying to add: 31:0

(Looks reasonable.)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

On 08/20/2012 12:45 PM, Andreas Schwab wrote:

John Stultz [off-list ref] writes:

quoted

I'm not very familiar w/ the iBook hardware, but does it use a
clocksource, or does it use arch_gettimeoffset()?

clocksource: timebase mult[3640e38e] shift[24] registered

quoted

I suspect that the casting has avoided clipping some strange values from
the persistent clock.

That's my guess as well.

quoted

Could you try with the following patch against Linus' HEAD? I suspect it
will let the box resume (although it will seem as though no time was
spent in resume) and then let me know what the JDB lines print out?

JDB: suspend_time: 1345491706:0  resume_time: 1345491737:0
JDB: Trying to add: 31:0

(Looks reasonable.)

Huh.  Yea, that looks fine.  And without the 
__timekeeping_inject_sleeptime() call, the system resumed ok?

Thanks for the testing!  I'll keep looking here.
-john