--- Log for 30.03.121 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 10 hours ago 00.01.50 *** Saving seen data "./dancer.seen" 00.05.08 # <_bilgus_> ah got it thankfully daniel documented it 00.15.02 Quit Saijin_Naib (Ping timeout: 258 seconds) 01.30.37 Quit Huntereb (Read error: Connection reset by peer) 01.33.26 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57) 01.33.44 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:811f:4ad4:93cb:16f9) 01.37.58 Quit ZincAlloy (Ping timeout: 246 seconds) 01.43.39 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:811f:4ad4:93cb:16f9) 01.47.57 Quit ZincAlloy (Ping timeout: 250 seconds) 01.52.20 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 01.56.46 Quit ZincAlloy (Ping timeout: 260 seconds) 02.00.05 # <_bilgus_> think I've got it g#3264 02.01.52 *** Saving seen data "./dancer.seen" 02.48.40 Quit Stanley00 () 04.01.55 *** Saving seen data "./dancer.seen" 04.50.52 Quit Huntereb (Read error: Connection reset by peer) 04.52.16 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7::69) 05.17.44 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.50.38 Quit Huntereb (Read error: Connection reset by peer) 05.52.19 Join Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com) 05.54.39 Quit SammysHP (Quit: *wuff*) 05.55.05 Join SammysHP [0] (~SammysHP@faol.sammyshp.de) 06.02.00 *** Saving seen data "./dancer.seen" 06.32.51 # _bilgus_: so the fact that H10 somehow triggered this but not the ipods is sheer luck? 06.37.49 # and this can be attributed to the compiler mis-optimizing things? 06.56.29 # I confess I don't understand what you're trying to accomplush on L262-263; what's the point of reading the value if you're just going to set all bits except for the DIRTY bit anyway? 06.59.25 # it seems the only practical difference is that you're setting addresss for each cacheline to all 1s 07.26.44 # <_bilgus_> speachy the address doesn't matter as far as not crashing but those unused bits I suspect 07.26.50 # <_bilgus_> 'unused' 07.27.14 # <_bilgus_> but which ones bit 21 or bit 24-31?? 07.27.59 # <_bilgus_> I also didn't appear to need to clear the dirty bit as they all 'SHOULD BE' valid once they get to me 07.28.08 # <_bilgus_> buttt....... 07.52.22 # we don't want them marked dirty going to invalid addresses. I don't know how the CPU would handle that 08.02.01 *** No seen item changed, no save performed. 08.03.10 # <_bilgus_> I'm going to try and dump the status register now and figure out what those unused bits are coming through as 08.13.21 # yeah. still strange how this only seems to screw upthe H10 08.13.37 # is there something else special about it vs the ipods? RAM size? 08.14.28 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 08.15.38 # <_bilgus_> ffff009f so it normally has the upper filled with ones 08.16.07 # <_bilgus_> I think they are both 32 bit but I wonder how much is silent corruption 08.16.13 # <_bilgus_> 32 MB 08.16.29 # * speachy nods. 08.25.26 # as an aside, I know one of the designers of the ARM7TDMI core. 08.33.52 # <_bilgus_> of I guess i read that backwards out of the file LE right? 08.38.49 # <_bilgus_> but if that the case then later it has them filled 08.39.17 # <_bilgus_> maybe I better format the file output 08.41.40 Quit Saijin_Naib (Disconnected by services) 08.41.44 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 08.41.44 Quit Saijin-Naib (Read error: Connection reset by peer) 08.41.52 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 08.56.32 Quit Saijin_Naib (Disconnected by services) 08.56.35 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 09.04.49 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.13.24 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 09.15.32 Quit Saijin-Naib (Ping timeout: 258 seconds) 09.15.57 # <_bilgus_> Looks to me that the upper bits are always 0 and I don't see anything amiss in the data either maybe its still alignment fooling me?? 09.20.43 # if you did a printf on a 32-bit field (using #x) the output is BE for human consumption 09.20.48 # %x 09.21.19 # if you're looking at 4 one-byte %02x fields, then it's LE 09.22.51 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 09.42.53 Quit Saijin_Naib (Ping timeout: 252 seconds) 09.44.12 # <_bilgus_> I got it but whats odd is this last line 0x0xf0005ff0 0xC00000 000000 0x00C00000 09.45.47 # <_bilgus_> that is a zero address marked valid and dirty 09.47.20 # <_bilgus_> maybe instead of filling the cache by pulling addresses I should try filling it manually 09.49.42 # <_bilgus_> context https://pastebin.com/0skBQfLW 09.51.45 # <_bilgus_> another at 390 but marked valid and clean 09.51.51 # <_bilgus_> weirrrdd 09.52.19 # <_bilgus_> those should be either filled or that 20 bit 1FFFF 10.02.05 *** Saving seen data "./dancer.seen" 10.02.55 # so to refill the cache just do what we did with the init code? 10.03.28 # so that last entry is odd, yeah 10.03.42 # ..well, 0 _is_ technically a valid address 10.06.40 # <_bilgus_> yeah but we init off of 0x2000 10.07.06 # <_bilgus_> was 0x1000 your patch doesn't matter but who wuld be putting it in there an ISR? 10.07.34 # <_bilgus_> they are both odd but for different reasons 10.08.05 # <_bilgus_> actually i'm gonna try init with the code that invalidates it 10.08.13 # <_bilgus_> well pseudo invalidates it? 10.08.56 # ISR vector table starts at 0x0 10.09.54 # but I don't see why that would ever get marked as dirty 10.10.11 # well, unless we have a null pointer dereference + write somewhere. 10.16.11 # <_bilgus_> possible but why only here 10.21.10 # <_bilgus_> ok initializing it like we invalidate there are no longer any 0 addresses but I can't say that fixed it till I run it like 10 more times to be sure 10.23.54 # <_bilgus_> oddly I don't see any of the invalidated entries this run either 10.24.46 # does armv4 not have a MMU? 10.25.15 # armv4 can have a MMU, but these specifically do not. 10.25.22 # i see 10.25.39 # too bad, that might help with catching issues 10.26.21 # an MMU to protect RB from being overwritten by user applications or so would be nice 10.27.35 # <_bilgus_> yeah this is kinda weird too I no longer see any invalidated entries through multiple runs 10.30.17 # <_bilgus_> well I guess I'm getting somewhere even with code size changes it hasn't crashed 10.30.30 # <_bilgus_> BBL 10.39.55 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 10.45.22 Quit massiveH (Quit: Leaving) 10.53.22 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 10.58.45 Quit Saijin_Naib (Disconnected by services) 10.58.49 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 11.27.45 Quit Saijin-Naib (Ping timeout: 252 seconds) 11.42.49 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 11.47.41 Quit ac_laptop (Ping timeout: 246 seconds) 11.57.33 Quit kakaka (Ping timeout: 240 seconds) 11.58.28 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 12.02.09 *** Saving seen data "./dancer.seen" 12.09.28 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 12.17.28 Join MrZeus [0] (~MrZeus@194.37.96.151) 12.49.20 # speachy: how fast is the sequential read speed on your fiio m3k? 12.49.29 # not sure how fast the newer players are 12.49.39 # no clue 12.49.50 # oh i see 12.50.01 # i usually benchmark my units to get an idea of how fast they are under the best circumstances 12.50.32 # i've never seen higher than 13MB/s, i saw that in H120s and HDD1630s that were CF modded 12.50.45 # just weird seeing stuff slower than that 13.09.35 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:8c09:6ea:e145:2a6a) 13.11.28 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.29.21 Quit ac_laptop (Ping timeout: 260 seconds) 13.31.10 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 13.36.09 Quit ac_laptop (Ping timeout: 252 seconds) 14.02.13 *** Saving seen data "./dancer.seen" 14.07.01 Quit atsampson (Ping timeout: 245 seconds) 14.08.00 Join atsampson [0] (~ats@cartman.offog.org) 14.15.45 Nick funman_ is now known as funman (~fun@rockbox/developer/funman) 14.37.04 Quit J_Darnley (Ping timeout: 246 seconds) 14.41.37 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 14.46.33 Quit J_Darnley (Ping timeout: 252 seconds) 14.46.37 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be) 15.15.26 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 15.35.22 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 15.35.53 Quit Saijin_Naib (Read error: Connection reset by peer) 15.36.16 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 15.39.26 Join PimpiN8 [0] (~PimpiN8@178.239.173.176) 15.47.22 Quit Saijin_Naib (Read error: Connection reset by peer) 15.49.55 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 16.02.16 *** Saving seen data "./dancer.seen" 16.06.57 Quit Saijin_Naib (Read error: Connection reset by peer) 16.08.33 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 16.10.17 Quit Saijin_Naib (Read error: Connection reset by peer) 16.12.30 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 16.12.40 Quit Saijin_Naib (Read error: Connection reset by peer) 16.14.18 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c5ca-9dc1-a2a7-0ae8.res6.spectrum.com) 16.41.03 Quit Saijin_Naib (Ping timeout: 250 seconds) 16.53.33 Quit pamaury (Ping timeout: 246 seconds) 16.55.30 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 17.34.25 Quit advcomp2019 (Ping timeout: 276 seconds) 17.34.30 Quit lebellium (Quit: Leaving) 18.02.19 *** Saving seen data "./dancer.seen" 18.08.40 Quit ZincAlloy (Quit: Leaving.) 18.38.30 Join Soap_ [0] (~Soap@rockbox/staff/soap) 18.39.18 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 18.41.03 Join mulp [0] (~plum@unaffiliated/plum) 18.41.22 Quit Soap (Read error: Connection reset by peer) 18.41.22 Quit dys (Ping timeout: 265 seconds) 18.43.13 Quit Galois (Ping timeout: 240 seconds) 18.43.13 Quit plum (Ping timeout: 240 seconds) 18.43.14 Nick mulp is now known as plum (~plum@unaffiliated/plum) 19.05.42 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.02.20 *** Saving seen data "./dancer.seen" 20.15.09 Quit pamaury (Ping timeout: 246 seconds) 20.30.29 Quit MrZeus (Ping timeout: 252 seconds) 20.38.55 Quit ac_laptop (Ping timeout: 252 seconds) 22.02.24 *** Saving seen data "./dancer.seen" 22.15.59 Quit bonfire (Quit: Leaving) 22.16.38 Quit cockroach (Ping timeout: 246 seconds) 22.27.10 Quit Strife89 (Quit: No Ping reply in 180 seconds.) 22.27.26 Join Strife89 [0] (~quassel@adsl-74-250-141-224.ags.bellsouth.net) 22.32.47 Join f1reflyylmao [0] (~f1refly@dynamic-077-001-095-102.77.1.pool.telefonica.de) 22.33.24 Quit f1refly (Ping timeout: 246 seconds) 22.33.25 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-001-095-102.77.1.pool.telefonica.de) 22.56.36 Join JanC_ [0] (~janc@lugwv/member/JanC) 22.56.44 Quit JanC (Killed (niven.freenode.net (Nickname regained by services))) 22.56.44 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 23.04.09 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 23.26.22 Join advcomp2019 [0] (~advcomp20@65-131-187-233.sxct.qwest.net) 23.26.22 Quit advcomp2019 (Changing host) 23.26.22 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)