--- Log for 31.07.113 Server: pratchett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 5 hours ago 00.02.12 Join Horscht [0] (~Horscht@xbmc/user/horscht) 00.20.07 *** Saving seen data "./dancer.seen" 00.25.43 Quit Horscht (Quit: quit) 00.35.35 Quit bertrik (Read error: Connection reset by peer) 00.39.25 Join n1s [0] (~n1s@rockbox/developer/n1s) 00.44.23 Quit petur (Quit: Leaving) 00.46.23 Join peter2323 [0] (~5fc3809a@www.haxx.se) 00.46.28 # i 00.46.29 # hi 00.48.06 # I am trying to install Rockbox v3.13 on an iaudio x5v and don´t get it to work.. 00.48.36 # the bootloader works and loads the rockbox base software 00.49.02 # then I get the rockbox logo on my device color display but it never loads the meny 00.49.20 # but I do get the corrent menu on the externa lcd display 00.50.29 # when I am lucky it starts to build up the header line on the display containing the small icons like battery level etc 00.50.40 # but then it gets stuck 00.50.43 # any clue? 00.54.13 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130725195523]) 00.54.14 Join krabador [0] (~krabador_@unaffiliated/krabador) 00.57.05 Quit ender` (Quit: Live your Life in such a way that the Westboro Baptist Church will want to picket your funeral.) 01.04.23 Quit peter2323 (Quit: CGI:IRC (Ping timeout)) 01.07.40 Quit ruskie (Read error: Operation timed out) 01.12.34 # who spots the bug? http://codepad.org/O6nXCpWp 01.23.19 # TheSeven: what does it do ? 01.23.39 # memmove 01.23.44 # (aliased to memcpy) 01.23.51 # it seems to lock up somewhere and I don't get why 01.30.58 # looks horrible ^^ 01.31.08 # did you write it ? 01.31.22 # I guess not, not out of the blue without comments 01.31.31 # it doesn't even optimize the "dragging" cases 01.32.09 # it's just pre-align + handle blocks + handle tail, falling back to bytewise copy if the alignment of src/dest is different 01.32.23 # and that duplicated for the forward and backward cases of course 01.33.20 # if you take a closer look it's actually fairly easy to understand - much easier than our division algorithm etc. 01.34.13 # rather trivial implementation I should say then ^^ If you have an commented version I buy it, otherwise that will wait until tomorrow ? Can't you test it in an emulator ? 01.34.55 # * TheSeven decides to just go to sleep then 01.43.51 Quit n1s (Quit: Ex-Chat) 02.20.11 *** Saving seen data "./dancer.seen" 02.27.29 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 02.34.20 Quit theunleet (Quit: CGI:IRC (Ping timeout)) 02.50.10 Join amayer [0] (~amayer@72.25.20.69) 02.57.08 Quit krabador (Quit: Sto andando via) 02.58.58 Join krabador [0] (~krabador_@unaffiliated/krabador) 03.02.20 Quit pamaury (Read error: Connection reset by peer) 03.04.04 Join tjb0607 [0] (~tjb0607@208.100.159.243) 03.11.17 Quit tjb0607 (Ping timeout: 260 seconds) 03.39.23 Quit rasher (Changing host) 03.39.23 Join rasher [0] (~rasher@rockbox/developer/rasher) 03.48.43 Join tjb0607 [0] (~tjb0607@208.100.159.243) 04.20.12 *** Saving seen data "./dancer.seen" 04.20.33 Quit krabador (Write error: Connection reset by peer) 04.24.33 Quit amayer (Quit: Leaving) 04.24.33 Quit pixelma (Disconnected by services) 04.24.34 Quit amiconn (Disconnected by services) 04.24.35 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.24.36 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.24.37 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.24.40 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.43.49 Join Jinx [0] (~Jinx@unaffiliated/jinx) 05.01.10 Quit tjb0607 (Quit: Segmentation fault) 05.14.57 Join Strife89 [0] (~Strife89@adsl-98-80-233-212.mcn.bellsouth.net) 05.15.28 Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) 05.22.56 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 05.43.14 Quit TheSeven (Disconnected by services) 05.43.15 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.20.16 *** Saving seen data "./dancer.seen" 06.24.22 Quit Strife89 (Quit: Vamoose!) 07.51.52 Quit DuperMan (Disconnected by services) 07.51.56 Join Doops [0] (~Duper@93-172-139-102.bb.netvision.net.il) 07.53.43 Quit saratoga (Quit: Page closed) 08.15.37 Quit Scromple (Read error: Connection reset by peer) 08.20.19 *** Saving seen data "./dancer.seen" 08.24.41 Join Scromple [0] (~Simon@161.43.73.67) 08.33.11 Join ender` [0] (krneki@foo.eternallybored.org) 09.00.46 Join Scr0mple [0] (~Simon@161.43.73.67) 09.00.46 Quit Scromple (Read error: Connection reset by peer) 09.04.26 Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) 09.04.35 Quit kevku (Ping timeout: 260 seconds) 09.06.36 Join Scromple_ [0] (~Simon@161.43.73.67) 09.09.30 Quit Scr0mple (Ping timeout: 264 seconds) 09.10.49 Quit Scromple_ (Ping timeout: 245 seconds) 09.12.16 Join Scromple [0] (~Simon@161.43.73.67) 09.16.00 Quit Scromple (Read error: Connection reset by peer) 09.16.12 Quit [Saint] (Remote host closed the connection) 09.21.32 Join Scromple [0] (~Simon@161.43.73.67) 09.29.16 Join petur [0] (~petur@rockbox/developer/petur) 09.32.25 Join [Saint] [0] (~saint@rockbox/user/saint) 09.35.26 # [Saint]: how's your skin coming together? 09.36.53 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 09.38.04 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 09.38.07 Quit bluebrother (Disconnected by services) 09.39.37 # theme* 09.39.48 Quit fs-bluebot (Ping timeout: 248 seconds) 09.41.07 Join fs-bluebot [0] (~fs-bluebo@g231123158.adsl.alicedsl.de) 09.52.31 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 09.53.50 Quit Doops (Ping timeout: 268 seconds) 10.00.12 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.17.27 # [Saint]: when you asked what I changed in my theme, I don't know if I mentionned this: I use different colors for the metadata, for easy parsing by the brain, so that the eyes immediately latch on to what matters, and differentiates the less important data from the rest 10.17.49 # that means one special color (blue), the default color (black), and two "less important" colors (shades of gray) 10.18.17 # makes it easier to know what's playing, with only a quick glance at the display 10.20.22 *** Saving seen data "./dancer.seen" 10.36.32 Quit vsync_ (Quit: WeeChat 0.3.2) 10.36.53 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.41.49 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 10.44.34 Quit JdGordon (Ping timeout: 245 seconds) 10.50.30 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.57.31 Quit ps-auxw (Ping timeout: 260 seconds) 11.07.16 # copper: about the performance of sd card, I might have a value, I need to do some tests 11.07.23 # s/value/clue 11.07.44 # nice 11.08.10 # I asked, because I can't think of a reason the card reader would be so slow 11.08.46 # I remember a similar issue with the card reader of the Acer Aspire One 11.09.00 # something about changing the "frequency" (of what, I can't remember) 11.09.25 # at least something could probably be optimised, I don't know if it's response for the whole slowdown, we'll see. Yeah the sd card should be able to sustain ~20MB/s max, so we have room 11.09.37 # *sd card reader 11.10.11 # is there such a thing as an "sdxc" reader? as opposed to a plain sdhc reader 11.31.07 # no 11.33.24 Quit pamaury (Read error: Operation timed out) 11.40.05 # copper: there could be in theory, but in practise nobody ever bothered to limit SDHC to the maximum capacity it was supposed to have 11.40.25 # it would be an entirely arbitrary limitation, i.e. you would have had to add *extra* code to your firmware to limit it 11.42.37 # well, okay, i guess that's the other way around: there is such a thing as an SDXC reader, i.e. one that definitely works with SDXC and has been tested, but SDHC readers in practise can read SDXC cards :) 11.42.50 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 12.10.40 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.20.24 *** Saving seen data "./dancer.seen" 12.38.52 # Torne: actually I have a USB card reader that only "sees" 32GB of my 64GB microsdxc card 12.40.52 # yah, that's the notional limit. C_SIZE is supposed to be capped at 65374 for SDHC, which is 32GB-512KB 12.41.20 # so your reader's firmware must have actually followed the spec rigorously and implemented a cap :) 12.44.21 Quit [Saint] (Remote host closed the connection) 12.45.28 Join [Saint] [0] (~saint@rockbox/user/saint) 12.56.44 # Torne: do card readers need anything special, specific, to read and write at the card's full speed? 13.00.32 # yes 13.00.47 # well, sort of 13.00.56 Quit Zambezi (Remote host closed the connection) 13.00.57 # UHS cards need a reader that's able to do UHS to run at their max speed 13.01.22 # also, some readers just suck. 13.01.36 # and won't go as fast as the card is capable of even though they support the same spec version :) 13.01.42 # https://en.wikipedia.org/wiki/Secure_Digital#Ultra-High_Speed 13.03.13 Quit rdn (Remote host closed the connection) 13.07.46 # hmmm, how do I know if my laptop reader is capable of it? 13.08.09 # no idea. 13.08.18 # your card probably isn't UHS, though :) 13.08.20 # unless it says it is 13.08.26 # they are generally labelled, as wikipedia notes 13.09.14 # it is 13.09.19 # UHS-I 13.09.40 # well, i have no idea 13.10.13 # also see the UHS104/DDR50/etc stuff, which further modifies UHS-I and also needs to be supported by the reader 13.12.12 # hmmm 13.12.48 # my laptop's card reader is a USB2 device, so I won't be able to get high speeds with the "extreme" cards 13.13.14 # I would need a USB3 device 13.32.17 # though I guess it wouldn't improve on the write speed, since I'm not even reaching half of what USB2 can do 13.32.33 # it's a Class 10 card, but I'm getting at most 7-8 MB/s 13.33.13 # and I assume that the UHS bit wouldn't improve on that 13.56.39 Quit kevku (Ping timeout: 245 seconds) 14.04.40 # copper: "class 10" kinda doesn't really mean anything at the end of the day, though. lots of class 10 cards never hit 10MB/s in *any* reader no matter what you do :) 14.05.22 # sony ericson beath this :> 14.05.26 # *beats 14.05.35 # reader ofc 14.05.40 # 8.5MB/s actually 14.05.46 # not quite the promised 10MB/s 14.06.49 # it's a hell of a lot better than my previous 32GB microsdhc card that managed about 2MB/s 14.07.02 # what a pos 14.07.39 # maybe 3MB/s 14.08.11 # <[7]> pamaury: is that better? :) http://codepad.org/smKMLe4Z 14.12.17 # [7]: much better :) sitll buggy ? 14.12.39 # <[7]> I'll have to test 14.12.56 # <[7]> I completely re-copy&pasted the backwards version in the process, didn't want to re-type all the comments 14.13.06 # <[7]> so I might have possibly squashed a bug by accident 14.13.29 # do you really need to write it in assembly ? 14.17.34 # which version is b uggy ? size optimised or performance optimised ? 14.18.09 # <[7]> performance 14.18.30 # <[7]> and I don't think gcc is clever enough to generate memcpy based on ldm/stm instructions 14.18.53 # <[7]> on top of that the C version seems to be buggy as well for misaligned buffers, and I don't get why 14.19.08 # <[7]> but I don't really care as this only seems to happen on armv6 which I have the assembly version for anyway 14.20.27 *** Saving seen data "./dancer.seen" 14.30.17 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.41.53 # [7]: on surface I don't see anything suspicous in the code, I guess that was expected 14.42.25 # is it really necessary to optimise the copy for the 16, 12, 8 and 4 bytes cases ? 14.58.25 # <[7]> look at the rockbox memcpy, that's even more complicated and also optimizes unaligned copying cases etc. 15.00.57 # <[7]> the 16 byte case could easily be removed, but that would save just 8 instructions 15.01.17 # <[7]> the other cases are necessary to properly take care of the tail 15.01.49 # <[7]> sure, one could roll those up, but that would make especially small memcpy calls rather inefficient 15.02.32 # yeah I know the rockbox is more optimise but it works :) 15.03.06 # it's just a suggestion reduce what is not necessary to find the bug 15.09.33 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 15.16.13 Quit Galois (Remote host closed the connection) 15.16.33 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 15.45.58 Quit mikroflops (Quit: <(^_^)>) 15.53.58 Quit [Saint] (Ping timeout: 268 seconds) 16.00.10 Join [Saint] [0] (~saint@rockbox/user/saint) 16.20.31 *** Saving seen data "./dancer.seen" 16.35.02 # website down? 16.36.30 Quit pamaury (Ping timeout: 246 seconds) 16.41.23 # yes, zagor is on it 16.44.05 # Is Zagor too heavy? ;) 16.44.53 # hum the homepage has not been updated yet. 16.48.51 Join ikeboy [0] (~dell@ool-435622d3.dyn.optonline.net) 17.00.25 Join Zagor [0] (~bjst@178.174.215.13) 17.00.25 Quit Zagor (Changing host) 17.00.25 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 17.00.28 # updated for what? 17.04.03 Join krabador [0] (~krabador_@unaffiliated/krabador) 17.12.45 # changes have been commited (YP-R0 removed from unusable targets, Creative players added etc) 17.25.26 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.29.45 Quit Zagor (Quit: Leaving) 17.36.26 Quit ikeboy (Quit: Ex-Chat) 17.44.49 Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) 17.50.57 Quit petur (Quit: Nettalk6 - www.ntalk.de) 17.53.23 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.03.22 Quit Scall (Ping timeout: 240 seconds) 18.20.27 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 18.20.33 *** Saving seen data "./dancer.seen" 18.43.44 Join pretty_function [0] (~sigBART@123.252.215.120) 18.48.41 Quit ruskie (Read error: Operation timed out) 19.04.24 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.11.01 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 19.19.35 Join ikeboy [0] (~dell@ool-435622d3.dyn.optonline.net) 19.23.36 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 19.32.42 Quit krabador (Ping timeout: 250 seconds) 19.42.52 Quit ikeboy (Quit: Ex-Chat) 19.48.00 Join robin0800 [0] (~Robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 19.58.17 Quit pretty_function (Remote host closed the connection) 19.58.53 Join pretty_function [0] (~sigBART@123.252.215.120) 20.00.29 Quit robin0800 (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 20.00.51 Join robin0800 [0] (~Robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 20.03.33 Quit pretty_function (Remote host closed the connection) 20.12.00 Quit lebellium (Read error: No route to host) 20.12.30 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 20.20.36 *** Saving seen data "./dancer.seen" 20.21.06 Join Scall [0] (~chat@unaffiliated/scall) 20.54.42 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130729175331]) 21.07.52 Quit onder` (Ping timeout: 264 seconds) 21.10.32 Join onder` [0] (~onder@24.244.89.228) 21.29.58 Quit dewlap (Ping timeout: 245 seconds) 21.32.16 # <[7]> pamaury: if you're curious, this is the C implementation, which seems to be buggy as well: http://codepad.org/eMAJTaBt 21.33.21 # <[7]> I can't see how that could possibly be broken, but it somehow screws up unaligned copys on ARMv6 (works on v4 and v5 though) 21.35.45 # <[7]> and the assembly one locks up on a call to memcpy(0x2200ad60, 0x22006d60, 0x4000) 21.36.08 # <[7]> i.e. trivial forward copy case 21.36.27 # <[7]> everything aligned properly, nice size, should only excercise the main 32 byte loop 21.37.05 # wait, taht C code doesn't work for *unaligned* copies 21.37.06 # ? 21.37.09 # that makes no sense :) 21.39.21 # if you want a fast memmove steal the one from symbian, though 21.39.50 # that's probably about as good as it's possible to get on ARM (tuned appropriately for each arch version) 21.40.49 # <[7]> er, i mean backwards 21.40.57 # oh 21.40.59 # * Torne looks again :) 21.41.28 # <[7]> the C one screws up the data in the process (that one's going forward) 21.41.34 # <[7]> the ASM one locks up (going backward) 21.41.48 # no, i meant the c one, i haven't seen the asm one 21.42.03 # <[7]> asm one is here (that's what I'm debugging currently): http://codepad.org/smKMLe4Z 21.42.31 # by locks up i assume you mean infinite loop and you don't have a debugger? :) 21.45.25 # <[7]> exactly that 21.45.47 # <[7]> I should probably try this out on my cortex m4 devboard where I can singlestep it 21.46.33 # i may be confused but the memcpy args you gave above aren't backward 21.50.42 # <[7]> dest > src should trigger a backward copy for memmove, right? 21.51.29 # no 21.51.35 # only if it actually overlaps 21.51.45 # any decent implementation will avoid copying backward unless absolutely required 21.51.53 # because it's super duper slow on many chips 21.51.57 # no matter how carefully you align stuff 21.52.19 # wait 21.52.53 # the C one only goes backward if they overlap, but the asm one doesn't check that 21.52.56 # so it's kinda dumb :) 21.55.40 Quit Rower (Quit: Hmmm...) 21.59.50 # <[7]> looks like it's the return statement that screws up the ASM version 21.59.57 # <[7]> no idea why, but it jumps into nowhere 22.01.26 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 22.01.47 # because it forgets to save r0 and lr before it jumps to the backward implementation :) 22.01.51 # it only does that on the forward path 22.02.13 # <[7]> wow. i'm blind. 22.02.27 # <[7]> that was just too trivial 22.02.29 # but yeah you almost certainly want to check for overlap, not just src < dest 22.02.38 # because copying backwards suuuuuucks on many systems' memories 22.02.44 # and so you want to avoid it wherever possible 22.03.07 # <[7]> doubt it will matter on cortex m3/m4... but possibly on arm9/arm11? 22.03.21 # also a max-performance memcpy() on any remotely modern ARM needs to use PLD and take care of cache alignment as well as word alignment 22.03.35 # i.e. you should be copying 32 byte *cache lines* not just 32 byte chunks 22.03.38 # and aggressively preloading them 22.03.52 # obviously only matters on systems with cache 22.03.57 # but it makes a *lot* of difference on those ;) 22.04.14 # <[7]> doubt I have any of those architectures covered by that code 22.04.35 # if i can dig up the symbian memcpy you are welcome to it 22.04.38 Join Nephiel [0] (~0288d783@www.haxx.se) 22.04.44 # it's ifdef'ed for arch version, presence of cache/pld, etc 22.04.47 # <[7]> only archs implemented so far are arm9/arm11 and cortex m 22.04.58 # and it's *probably* the fastest implementation that exists for the chips it was tuned on 22.05.04 # which is a fairly wide range, though not cortex-M :) 22.05.22 # <[7]> those don't have a cache, so I doubt it will matter at all 22.05.25 # <[7]> anyway, being a guru, can you tell me why that C implementation with __attribute__((weak)) wins against the ASM one? 22.05.56 # no, i saw your comment about that 22.06.07 # if they have the right symbol types in the object file, i can't imagine why the linker could do the wrong thing 22.06.15 # huh 22.06.23 # actually one wild thought: are they in differently named sections? 22.06.28 # e.g. because of -ffunction-sections 22.06.40 # not sure that matters but it's the only thing that occurs to me 22.07.28 # <[7]> yes, they are 22.07.36 # failing that i would look at the symbol tables of the objects in detail, with objdump/readelf, not nm 22.07.39 # ah 22.07.40 # <[7]> but the caller is in yet another section, so I really don't get it 22.07.50 # try having htem in the same section anyway 22.07.53 # just to test 22.08.16 # <[7]> hm... actually they should both end up in .text.memmove IIUC 22.08.22 # well look :) 22.08.28 # <[7]> the weak alias for memcpy would probably be in .text.memcpy though 22.09.00 # nm's interpretation of symbols is rather.. old fashioned and doesn't allow for lots of interesting possibilities (the information isn't *wrong*, it's just.. missing depth) 22.09.04 # look with readelf 22.09.15 # it's much more informative about exactly what is in the symbol table 22.10.27 # oh, just one additional thing before i go to do something else: copying backwards may be slower even on systems with no cache, because they may still have a small preload buffer 22.10.45 # * Torne shrugs ;) 22.12.41 Quit y4n (Quit: Do you like hurting other people?) 22.12.50 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 22.20.38 *** Saving seen data "./dancer.seen" 22.28.49 # <[7]> Torne: I have a feeling that -flto is responsible for the weak symbol problem 22.35.38 Quit kevku (Ping timeout: 260 seconds) 22.44.05 Quit Nephiel (Quit: CGI:IRC) 23.09.19 Quit thomasjfox (Ping timeout: 268 seconds) 23.31.02 Quit amayer (Quit: Leaving) 23.38.40 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 23.41.38 Join rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com) 23.49.02 Join dewlap [0] (~dewlap@2001:5c0:1000:a::97b)