<apritzel>
smaeul: nice! any indications on the outliers? So far all my jumps are with the lowest 11 bits clear or set
<smaeul>
it was the same for me. one user reported jumps with 10 bits, so I bumped it down prior to submission. the files linked above have 656659 examples of 9-bit anomalies
<smaeul>
so far no 8-bit anomalies, but it would be good to get some more testing from people where mainline is not enough
<apritzel>
but it's not the lowest 9 bits? (looking at some frank.txt file)
<apritzel>
(or I don't understand the numbers in there)
<smaeul>
those are raw cntvct readings
<smaeul>
and it is always the lowest 9 bits set/cleared
<smaeul>
(I wrote a script to verify this)
cnxsoft has joined #linux-sunxi
<apritzel>
very good
<apritzel>
I have a bare metal test now
<apritzel>
running straight from U-Boot, disguising itself as a Linux kernel
<apritzel>
I am just connecting two boards so that I don't need to keep my laptop running overnight ;-)
<smaeul>
one improvement I made was actually to reduce CPU load by adding random delays. for some reason, even without cpuidle or cpufreq, this makes the bug trigger more
<smaeul>
when running at max throughput, I've found that either the bug triggers during a run or it doesn't, regardless of test duration (i.e. it doesn't start failing halfway through)
<apritzel>
CPU load is no problem in my case at all, but still I see the frequency of the bug varying
<apritzel>
same here
<apritzel>
some boots never trigger the issue, in the other cases it triggers immediately and stays that way
mripard has quit [Ping timeout: 240 seconds]
<smaeul>
if anyone wants to run the tool, the three useful tests are 1) ./timer_test -Cc (CNTVCT with the existing workaround) 2) same, but load the module and turn off CNTVCT trapping, 3) load the module, turn off CNTPCT trapping, and run ./timer_test -Ccp
<smaeul>
er, for 2) you want ./timer_test -Ccs and 3) ./timer_test -Ccps
<smaeul>
that way you do the same filtering as the kernel (but avoid the overhead of the context switch)
<smaeul>
apritzel: do you plan to release your tool?
<apritzel>
my latest run (~1U << 30 mrs pairs) showed 851191825 +0 read, 155547056 +1 reads and 25151 "11-bit jumps" (nothing else)
<apritzel>
eventually yes, just need to clean up the embarrassing hack parts ;-)
camus has joined #linux-sunxi
<smaeul>
jernej: about your link, it's not good for mainline, because the threshold is too low if the CPU is running at 24 MHz
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
shailangsa has quit [Ping timeout: 252 seconds]
<apritzel>
smaeul: the threshold there is 16, right?
<apritzel>
with 24 MHz I always got 6 ticks difference, so it should be fine?
<apritzel>
(I put some comments there)
<smaeul>
with that code?
<apritzel>
with two mrs back to back, bare metal
<apritzel>
and CPUX_CLK_SRC_SEL = OSC24M
<smaeul>
ok, nevermind my comment then
<apritzel>
smaeul: but I agree that your version is much better
<smaeul>
(now try CPUX_CLK_SRC_SEL = OSC32K ;-) )
<apritzel>
I briefly thought about it ;-)
<apritzel>
it would be good if we get those people to confirm that 9 bit solve the issue
<smaeul>
yes, I will comment on the PR
<apritzel>
funny enough that PR is a patch to a patch ...
<smaeul>
and of course neither patch bothered to update the comment :)
ganbold has joined #linux-sunxi
<apritzel>
indeed, saw that as well. and the commit message is as terse as usual
apritzel has quit [Ping timeout: 240 seconds]
jstefanop has joined #linux-sunxi
shailangsa has joined #linux-sunxi
jstein has quit [Quit: quit]
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 260 seconds]
victhor has quit [Ping timeout: 268 seconds]
<tuxd3v>
Set Powered for hci0 failed with status 0x11 (Invalid Index)
<tuxd3v>
after some 100-150 retries bluetooth works.. omg
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
apritzel has joined #linux-sunxi
buzzmarshall has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 268 seconds]
camus has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus is now known as kaspter
gsz has joined #linux-sunxi
<anarsoul|2>
sounds like something's up with power
<anarsoul|2>
likely you need to add some delay after power up
reinforce has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
hlauer has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
cmeerw has quit [Ping timeout: 260 seconds]
mripard has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
jstefano_ has joined #linux-sunxi
jstefanop has quit [Read error: Connection reset by peer]
gumblex has quit [Ping timeout: 250 seconds]
gumblex has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jbrown has quit [Ping timeout: 260 seconds]
jstefano_ has quit [Ping timeout: 268 seconds]
Splitice has quit [Quit: Connection closed]
prefixcactus has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 240 seconds]
jbrown has joined #linux-sunxi
Tooniis has quit [Ping timeout: 245 seconds]
<tuxd3v>
anarsoul|2, it could be.. but how much, and also were..that is the million dollar question :)
<tuxd3v>
I will continue investigating..
<apritzel>
tuxd3v: do you have some (older?) setup where it works reliably?
<apritzel>
or was it always a gamble at best?
<tuxd3v>
apritzel, I know what you mean :)
Tooniis has joined #linux-sunxi
<tuxd3v>
but unfortunatly I don't have any :(
<tuxd3v>
I go trial and error..
<tuxd3v>
I need to check the voltage regulators if they add some delays or not and were..
<apritzel>
my theory is that some of the WiFi resources (regulator / reset) are also needed for BT, so if you could remove those WiFi bits from a working setup and this breaks BT, this would be proof
jstefanop has quit [Remote host closed the connection]
<mmarc__>
On Allwinner H6 with mali-t720, probing fails, because all gpu registers are read as having value 0x80. I feel this indicates some generic problem. Maybe gpu has failed to power on?
tnovotny has joined #linux-sunxi
<apritzel>
mmarc__: which board/device? Does it have a PMIC? There is a "mali-supply" DT property, needed in the &gpu node, do you have that?
<mmarc__>
Yes, mali-supply = <0x14>;
prefixcactus has quit [Ping timeout: 260 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel>
mmarc__: and which node has "phandle = <0x14>;"?
<mmarc__>
regulator-max-microvolt = <0x107ac0>;
<mmarc__>
dcdcc {
<mmarc__>
regulator-enable-ramp-delay = <0x7d00>;
<mmarc__>
regulator-min-microvolt = <0xc5c10>;
<mmarc__>
regulator-name = "vdd-gpu";
<mmarc__>
phandle = <0x14>;
<mmarc__>
};
JohnDoe_71Rus has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<plaes>
megi: yeah, looks like their plan got somehow out before the proper "escape"
ganbold_ has quit [Ping timeout: 265 seconds]
warpme_ has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
<tuxd3v>
hello anybody knows how to calibrate BogoMIPS to allwinner H3?
mmarc__ has quit [Remote host closed the connection]
<KotCzarny>
why would you want to do that?
<KotCzarny>
it's just speed of cpu multiplied by some number
<tuxd3v>
KotCzarny, because I wanted too :0
<KotCzarny>
pointless, but you can always modify the sources somewhere i guess
mmarc__ has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 268 seconds]
jstein has joined #linux-sunxi
<mmarc__>
So the regulator is there, but surprisingly all registers are 0x80. Maybe there is something else I should look at in the device tree?
<mmarc__>
This is CherryPi H6
shailangsa has quit [Ping timeout: 246 seconds]
mmarc__ has quit [Remote host closed the connection]