#linux-sunxi on 2019-01-01 — irc logs at freenode.irclog.whitequark.org

15:42 <quark_> anyone here still having A64 timer issues after that applying Samuel Holland patch?

15:43 <quark_> I have seen clock jumps even after that patch maybe once in two weeks

15:46 <quark_> I also faced same issue with patched u-boot. Small backward jumps caused timeout issues

15:48 <quark_> I changed GENMASK to 9 bits instead of 10 in u-boot. At least now I'm not able to see any backward jumps.

15:48 <quark_> I'll try same with linux kernel if that helps

15:48 <apritzel_> quark_: can you try to add fsl,erratum-a008585 to your timer DT node?

15:50 <apritzel_> and how do those Linux problems manifest?

15:50 <apritzel_> is it large jumps forward in the date?

15:51 <quark_> apritzel_: yep. uptime goes like +30000 days

16:01 <quark_> apritzel_: fsl,erratum-a008585 seems to do multiple reads to those counters. I'll try enable that one.

16:08 <JohnDoe_71Rus> Has anyone tried to build an image use mainline kernel and kodi?

16:10 <apritzel_> quark_: yes, the FSL workaround is more of a sledgehammer fix

16:11 <apritzel_> quark_: but you need such a long time to see it, or do you have any shortcuts?

16:19 <quark_> apritzel_: in linux kernel side I don't have shortcuts to trigger issue. u-boot side I faced issue immediatly when using timer diff to calculate timeout

16:20 <quark_> current u-boot has that samuel holland patch included

16:21 <quark_> reading 16MB SPI flash hammers that counter for every 64bytes read to check if timeout has passed

16:23 <apritzel_> mmh, interesting, I thought that U-Boot commit be0d21795222 fixed that issue, at least for U-Boot

16:23 <apritzel_> quark_: (I guess you mean that patch)

16:25 <quark_> apritzel_: yep. that is the patch

16:25 <apritzel_> smaeul: ^^^^^ IIRC you also mentioned once that your Linux patch wasn't catching all instances, right?

16:26 <apritzel_> quark_: did you try something to read the timer more often in Linux?

16:26 <apritzel_> like a directed test or something?

16:27 <apritzel_> quark_: I used this once: https://github.com/apritzel/pine64/blob/master/tools/test_timer.c

16:28 <apritzel_> but the runtime is very short, just enough to prove the issue on any totally unpatched system

16:29 <apritzel_> quark_: as you figured, smaeul's Linux patch is a much leaner solution (compared to the FSL one), based on his previous observations

16:30 <apritzel_> but apparently it's not enough, so we might indeed need the FSL version

16:30 <quark_> apritzel_: I'll try to trigger it in linux side more often after I finish my u-boot SPI flash stuff

16:31 <apritzel_> quark_: if you just need a workaround in U-Boot, can you try to enable the FSL workaround there?

16:32 <apritzel_> CONFIG_SYS_FSL_ERRATUM_A008585

16:32 <quark_> yep that smaeul's patch is much leaner solution definetly.

16:34 <quark_> I just reduced bit mask to 9 bits. I seems to fix too for this u-boot case. of course that means counter is read more often twice or more

16:35 <apritzel_> quark_: for U-Boot we don't care about the performance impact at all

16:36 <apritzel_> quark_: but the question is if 10 bits are not enough, are we sure that 9 bits are?

16:36 <apritzel_> could be just less frequent

16:36 <quark_> yep. I was thinking same thing

16:37 <apritzel_> quark_: so you trigger it easily when loading from SPI flash?

16:38 <apritzel_> I don't remember seeing issues before with that ...

16:42 <apritzel_> quark_: can you report that on the U-Boot mailing list, please?

16:46 <quark_> apritzel_: I'm modifying sun4i_spi driver to support sun6i spi too when I noticed this one

16:50 <quark_> currently there is only SPL SPI support for A64 and that doesn't do any timeout checking

17:53 <apritzel_> quark_: ah, OK, I was wondering. Funny enough I also enhanced the driver to support both, but wasn't quite happy with the result ..

17:55 <apritzel_> wow, there are five whitequark loggers in here. Echo, echo, echo

18:06 <smaeul> apritzel_: the issue with my linux patch was related to programming CVAL... I thought I had CNTVCT figured out

18:07 <apritzel_> smaeul: so the condition with the 11 bit still holds?

18:08 <apritzel_> smaeul: I though you mentioned that you had reports about (very) rare time jumps still ...

18:08 <smaeul> or at least CVAL is the part that the allwinner workaround affects. they don't do anything with CNTPCT as far as I remember

18:09 <smaeul> apritzel_: I don't have any definite reports otherwise

18:10 <apritzel_> smaeul: OK, I see, thanks

18:10 <apritzel_> quark_ mentioned that he saw jumps once in two weeks or so

18:10 <smaeul> that's the problem... unless you're hammering CVAL/CNTPCT/CNTVCT, you really have no idea how the jump happened

18:13 <apritzel_> smaeul: Linux lately started to use the physical timer, to leave the virtual timer for guests

18:13 <apritzel_> the virtual *counter* is the just the physical counter minus CNTVOFF

18:13 <smaeul> there's also the possibility that, since this is a silicon bug with nondeterminism, the effects on my chips are different that others

18:13 <apritzel_> the *timers* are separate

18:14 <apritzel_> so unless the bug is in the virtual offset calculation, I guess the physical timer is affected as well

18:14 <smaeul> e.g. *I* have never seen jumps smaller than 2^11 cycles, but quark_ seems to be seeing 2^10 cycles

18:15 <smaeul> apritzel_: I think part of the issue is the adder used to add CNTPCT + CNTVOFF

18:15 <smaeul> because CNTVCT has a couple orders of magnitude more variation than CNTPCT

18:16 <smaeul> with https://github.com/crust-firmware/linux/commit/d4532db641c0a29fab920dc78b562df5a82d703a you can run your test on CNTPCT from userspace

18:48 <apritzel_> smaeul: but that traps and emulate, wouldn't it be better to clear ARCH_TIMER_USR_PCT_ACCESS_EN, to directly allow physical counter access from EL0?

18:49 <apritzel_> rather set than clear, I mean

18:53 <quark_> apritzel_: I managed to get SPI driver support both with quite minimal changes. 4 files changed, 101 insertions(+), 15 deletions(-)

18:55 <smaeul> apritzel_: sure :) how do I do that?

18:55 <quark_> apritzel_: and did you disable/enable clocks when claming SPI bus?

18:58 <quark_> smaeul: I'll try hammer those counters to see what kind of jumps are happening

19:21 <apritzel_> smaeul: arch_counter_set_user_access() in drivers/clocksource/arm_arch_timer.c

19:39 <smaeul> apritzel: thanks. I'll bump this up in priority

20:55 <apritzel_> smaeul: thanks, I will also try to set aside a board to do some testing