--- Log for 04.04.121 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 9 days and 10 hours ago 00.00.20 # https://gerrit.rockbox.org/r/c/rockbox/+/3288 00.00.25 # small change for whoever to look at 00.04.26 *** Saving seen data "./dancer.seen" 01.02.30 Quit ufdm (Read error: Connection reset by peer) 01.21.06 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 02.04.29 *** Saving seen data "./dancer.seen" 04.04.32 *** No seen item changed, no save performed. 04.33.22 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 05.36.52 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 06.04.08 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 06.04.36 *** No seen item changed, no save performed. 07.47.53 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 08.04.39 *** No seen item changed, no save performed. 09.26.54 # Build Server message: New build round started. Revision 4bc7bafc68, 298 builds, 10 clients. 09.39.04 Quit pamaury (Ping timeout: 246 seconds) 09.39.55 # Build Server message: Build round completed after 780 seconds. 09.39.58 # Build Server message: Revision 4bc7bafc68 result: All green 09.40.07 # Build Server message: New build round started. Revision 962d412917, 298 builds, 10 clients. 09.51.07 # Build Server message: Build round completed after 659 seconds. 09.51.09 # Build Server message: Revision 962d412917 result: All green 10.04.40 *** Saving seen data "./dancer.seen" 11.38.02 Join MrZeus [0] (~MrZeus@2a02:c7f:a0aa:4400:f943:daf4:f3e1:d705) 12.04.42 *** No seen item changed, no save performed. 12.30.08 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.35.01 Nick Guest71059 is now known as alexbobp (~alex@meowface.org) 12.35.49 # <_bilgus> g#3274 12.35.50 # Gerrit review #3274 at https://gerrit.rockbox.org/r/c/rockbox/+/3274 : Add custom action mapping to core by William Wilgus 12.36.19 # <_bilgus> I have this working If anyone wants to play around with it 12.36.39 # <_bilgus> I left some code for generating the mapfile in the commit message 12.37.24 # <_bilgus> I only tried remapping the volume + button in the WPS to WPS_PLAY but it works! 12.38.45 # <_bilgus> The plugin for generating the remap is going to be the hard part it'll need to be aware of a lot 12.40.39 # <_bilgus> oops forgot to include the new files 12.42.46 # <_bilgus> thats better :) 12.46.22 # <_bilgus> I think with the plugin it should be able to also create keymaps for plugins too 12.46.44 # <_bilgus> then we can hook the remap in the plugin get action function 12.48.13 Quit jdarnley (Quit: ZNC 1.7.1 - https://znc.in) 12.48.21 # <_bilgus> currently key remaps is only loaded on start thats probably OK but I'd like to add a way to reload (even a hook in plugin.h) 13.02.41 Join cela [0] (92c67a98@152.122.198.146.dyn.plus.net) 13.03.42 # _bilgus result of bisect on Rk27xx not recent Dec 2017. https://0bin.net/paste/ZSrRLbYb#ivELw1F7JXq37hBcYe+CvMUTfmQGW1IyyQd2yW7N4Vm 13.04.31 # Happy to test a fix. 13.04.56 # <_bilgus> it says thats the commit that broke it? 13.05.08 # <_bilgus> or thats the last taht works? 13.05.39 # yes its broke on that commit 13.05.49 # <_bilgus> thats weird 13.09.11 # <_bilgus> so enum is at least an int 13.09.29 # <_bilgus> our ints are 4 bytes and so are the longs? 13.09.55 # <_bilgus> hmm I'm not even sure how the hell 13.10.38 # <_bilgus> the no functional changes really has me going to I assume that means JH tested it 13.14.31 # <_bilgus> its just about gotta be in the source of the device 13.14.41 # <_bilgus> some wrong alignment maybe 13.18.07 # bisect history if its any help. https://0bin.net/paste/ni91v3p0#cj88vPQtQ8gbAL1TvRNxegbSBiLeXV3klJLEWuffCRR 13.23.35 # <_bilgus> that previous commit looks more likely to be the culprit TBH but its still weird 13.26.39 # <_bilgus> ok cela I'll have you a build shortly I'm gonna try aligning the memory 13.34.35 # <_bilgus> https://www.mediafire.com/folder/wyq85ijmsyqsm/RK27Generic 13.35.12 # <_bilgus> beyond that I'll have to probably start looking at the asm between them 13.43.19 # Still has the same playback issue 13.52.26 # <_bilgus> I figured.. ok ill get back with you in a few days once we have some idea of what changed 13.53.51 # ok thanks 13.53.59 Quit cela (Quit: Connection closed) 13.55.46 Join dweeber` [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) 13.55.55 # huh, so it wasn't my fault. :D 13.58.22 # _bilgus: in most ABIs long is same as int. 13.58.28 # we have no 64 bit ABIs so 13.58.31 # i expect same true here 13.58.46 Quit dweeber_ (Ping timeout: 240 seconds) 13.59.39 # that could change if we ever got an arm64 target 13.59.49 # why we need to be careful about using long though 14.00.10 # GCC will likely convert it to 64 bit on targets that have 64 bit native integers 14.00.29 # is that what we always want? 14.04.45 *** Saving seen data "./dancer.seen" 14.57.17 # long is tradtionally the same size as a pointer 14.58.08 # as long (ha!) as we don't use 'long' in any external ABI/interface I don't see that it really matters. 15.00.19 # You mean if that happens we might end up holding the short end of the stick? 15.00.56 # gevaerts: yeah, it might come back to byte us. 15.03.09 # We need to be careful so we don't burn our fingers and end up singed and charred 15.06.23 # and it will be a long long way to recovery. 16.04.47 *** No seen item changed, no save performed. 16.45.49 Join Link8__ [0] (uid277370@gateway/web/irccloud.com/x-iswbbxyfgcxjrhxo) 17.17.35 Quit ac_laptop (Ping timeout: 246 seconds) 17.39.07 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.44.21 Quit kakaka (Ping timeout: 240 seconds) 18.04.49 *** Saving seen data "./dancer.seen" 18.08.39 Quit ChanServ (shutting down) 18.13.19 Join ChanServ [0] (ChanServ@services.) 18.13.19 Mode "#rockbox +o ChanServ " by weber.freenode.net 18.22.21 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 19.23.03 Quit Strife89 (Quit: No Ping reply in 180 seconds.) 19.24.44 Join Strife89 [0] (~quassel@adsl-74-250-151-186.ags.bellsouth.net) 19.36.58 Quit lebellium (Quit: Leaving) 20.04.51 *** Saving seen data "./dancer.seen" 20.20.39 Quit MrZeus (Ping timeout: 260 seconds) 20.46.37 Quit beencubed (Quit: Leaving) 21.12.55 Quit pamaury (Ping timeout: 260 seconds) 21.29.14 Quit Link8__ (Quit: Connection closed for inactivity) 22.04.54 *** Saving seen data "./dancer.seen" 22.36.03 # <_bilgus> I'm still convinced this is an alignment problem on the Rk27xx 22.36.30 # <_bilgus> looking at the maps between the working build and broken build its literally 8 bytes off 22.38.00 # IIRC DMA onthe 27xx has some strict cacheline alignment requirements 22.39.44 # <_bilgus> I saw a commit that was supposed to handle that prior to this broken one 22.40.19 # quiestion is if all of the 27xx targets are equally afflicted 22.40.27 # <_bilgus> I padded the codec func with nops till it matched alignment with the working build lets see what that gets us 22.41.20 # <_bilgus> thing is I don't think its this function but one further down since they all arrear to be mod 4 22.42.05 # <_bilgus> I did see th etext area did not have align(4) which seems off 22.42.32 Join f1reflyylmao [0] (~f1refly@2a01:c23:8c55:d00:ed33:f381:e424:6c42) 22.42.56 # <_bilgus> the function I think is failing is part of the codec api 22.43.36 # <_bilgus> I wonder if the change to long pointer would change alignment reqs I can't imagine so 22.43.55 Quit f1refly (Ping timeout: 260 seconds) 22.43.55 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:8c55:d00:ed33:f381:e424:6c42) 22.46.26 # a pointer is a pointer.. 22.51.10 # that commit really doesn't make sense as something that would break stuff. unless the enum was optimized to something smaller than an int? 22.51.37 # and it's causing some sort of stack/variable overflow somewhere.. 22.52.11 # <_bilgus> thing is the functions actually were slightly smaller 22.52.23 # before or after? 22.52.28 # <_bilgus> after 22.52.44 # <_bilgus> I was able to add 2 nops and get it to the same size 22.53.15 # <_bilgus> I guess next I should compare the asm 22.53.20 # old toolchain for both? 22.53.33 # <_bilgus> new for both 22.53.57 # I wouldn't trust 2017-era code built with the new toolchain 22.54.16 # <_bilgus> well I assume he did the same 22.55.05 # <_bilgus> maybe I should send him the build that 'works' too and make sure it for sure works 22.55.07 # and, heh, using the CFLAGS from the appropriate era.. 22.55.29 # (ie a make reconf) 23.01.09 # _bilgus: codecbuf and the .init section overlap on this 23.01.27 # (uaually it's audiobuf..) 23.02.44 # stuff getting shifted around a hair could be enough for an errant write to trash something that we care about 23.04.59 # <_bilgus> well we can try if nothing ele it'll give us another chance at lucky alignment 23.08.04 # oh, forgot to ask, what codec(s)? 23.08.45 # <_bilgus> good question 23.08.54 # does (eg) keyclick work? that'll let us know if it's the PCM layer or the codec 23.09.08 # (ditto on voiced menus) 23.09.38 # <_bilgus> good point if the pcm buff fails itd cause thise issues 23.09.53 # If you hand over any additional builds please turn on logf at least 23.10.19 # I think by default it'll log the codec launch/return codes 23.11.13 # <_bilgus> I did test plugins i'll wait to hear back on the nop build 23.11.35 # my gut feeling is it's a PCM issue rather than codecs/etc specifically 23.13.10 # <_bilgus> what an odd commit to break on though the one prior seems so much more likely 23.14.03 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 23.16.26 # my blacklisting those IP ranges seem to have cut the traffic by half. 23.17.21 # <_bilgus> WOW 23.17.29 # <_bilgus> thats crazy! 23.17.45 # more than half. but I'll need more than a weekend to tell for sure 23.17.57 # <_bilgus> also a holidat 23.17.58 # <_bilgus> y 23.18.04 # last 48 hours are less than Friday alone. 23.18.17 # on d.r.o specifically. 23.19.27 # page hits on www are down by over 60%, though actual bandwidth not by much. git/gerrit are _wayyyy_ down. 23.19.56 # but friday was a huge huge spike (bots hitting snapshot/tag download links in violation of robots.txt..) 23.20.52 # friday as something like 15x typical traffic loads