Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2013-07-31

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:28peter2323i
00:46:29peter2323hi
00:48:06peter2323I am trying to install Rockbox v3.13 on an iaudio x5v and donĀ“t get it to work..
00:48:36peter2323the bootloader works and loads the rockbox base software
00:49:02peter2323then I get the rockbox logo on my device color display but it never loads the meny
00:49:20peter2323but I do get the corrent menu on the externa lcd display
00:50:29peter2323when I am lucky it starts to build up the header line on the display containing the small icons like battery level etc
00:50:40peter2323but then it gets stuck
00:50:43peter2323any 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:00
01:04:23 Quit peter2323 (Quit: CGI:IRC (Ping timeout))
01:07:40 Quit ruskie (Read error: Operation timed out)
01:12:34TheSevenwho spots the bug? http://codepad.org/O6nXCpWp
01:23:19pamauryTheSeven: what does it do ?
01:23:39TheSevenmemmove
01:23:44TheSeven(aliased to memcpy)
01:23:51TheSevenit seems to lock up somewhere and I don't get why
01:30:58pamaurylooks horrible ^^
01:31:08pamaurydid you write it ?
01:31:22pamauryI guess not, not out of the blue without comments
01:31:31TheSevenit doesn't even optimize the "dragging" cases
01:32:09TheSevenit's just pre-align + handle blocks + handle tail, falling back to bytewise copy if the alignment of src/dest is different
01:32:23TheSevenand that duplicated for the forward and backward cases of course
01:33:20TheSevenif you take a closer look it's actually fairly easy to understand - much easier than our division algorithm etc.
01:34:13pamauryrather 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:00
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:00
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:00
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:00
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:00
06:20:16***Saving seen data "./dancer.seen"
06:24:22 Quit Strife89 (Quit: Vamoose!)
07:00
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:00
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
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:26copper[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:37coppertheme*
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
10:00:12 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
10:17:27copper[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:49copperthat means one special color (blue), the default color (black), and two "less important" colors (shades of gray)
10:18:17coppermakes 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:00
11:07:16pamaurycopper: about the performance of sd card, I might have a value, I need to do some tests
11:07:23pamaurys/value/clue
11:07:44coppernice
11:08:10copperI asked, because I can't think of a reason the card reader would be so slow
11:08:46copperI remember a similar issue with the card reader of the Acer Aspire One
11:09:00coppersomething about changing the "frequency" (of what, I can't remember)
11:09:25pamauryat 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:37pamaury*sd card reader
11:10:11copperis there such a thing as an "sdxc" reader? as opposed to a plain sdhc reader
11:31:07pamauryno
11:33:24 Quit pamaury (Read error: Operation timed out)
11:40:05Tornecopper: 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:25Torneit would be an entirely arbitrary limitation, i.e. you would have had to add *extra* code to your firmware to limit it
11:42:37Tornewell, 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:00
12:10:40 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
12:20:24***Saving seen data "./dancer.seen"
12:38:52copperTorne: actually I have a USB card reader that only "sees" 32GB of my 64GB microsdxc card
12:40:52Torneyah, that's the notional limit. C_SIZE is supposed to be capped at 65374 for SDHC, which is 32GB-512KB
12:41:20Torneso 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:44copperTorne: do card readers need anything special, specific, to read and write at the card's full speed?
13:00
13:00:32Torneyes
13:00:47Tornewell, sort of
13:00:56 Quit Zambezi (Remote host closed the connection)
13:00:57TorneUHS cards need a reader that's able to do UHS to run at their max speed
13:01:22Tornealso, some readers just suck.
13:01:36Torneand won't go as fast as the card is capable of even though they support the same spec version :)
13:01:42Tornehttps://en.wikipedia.org/wiki/Secure_Digital#Ultra-High_Speed
13:03:13 Quit rdn (Remote host closed the connection)
13:07:46copperhmmm, how do I know if my laptop reader is capable of it?
13:08:09Torneno idea.
13:08:18Torneyour card probably isn't UHS, though :)
13:08:20Torneunless it says it is
13:08:26Tornethey are generally labelled, as wikipedia notes
13:09:14copperit is
13:09:19copperUHS-I
13:09:40Tornewell, i have no idea
13:10:13Tornealso see the UHS104/DDR50/etc stuff, which further modifies UHS-I and also needs to be supported by the reader
13:12:12copperhmmm
13:12:48coppermy laptop's card reader is a USB2 device, so I won't be able to get high speeds with the "extreme" cards
13:13:14copperI would need a USB3 device
13:32:17copperthough I guess it wouldn't improve on the write speed, since I'm not even reaching half of what USB2 can do
13:32:33copperit's a Class 10 card, but I'm getting at most 7-8 MB/s
13:33:13copperand I assume that the UHS bit wouldn't improve on that
13:56:39 Quit kevku (Ping timeout: 245 seconds)
14:00
14:04:40Tornecopper: "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:22Belzebubsony ericson beath this :>
14:05:26Belzebub*beats
14:05:35Belzebubreader ofc
14:05:40copper8.5MB/s actually
14:05:46coppernot quite the promised 10MB/s
14:06:49copperit's a hell of a lot better than my previous 32GB microsdhc card that managed about 2MB/s
14:07:02copperwhat a pos
14:07:39coppermaybe 3MB/s
14:08:11[7]pamaury: is that better? :) http://codepad.org/smKMLe4Z
14:12:17pamaury[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:29pamaurydo you really need to write it in assembly ?
14:17:34pamaurywhich 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:53pamaury[7]: on surface I don't see anything suspicous in the code, I guess that was expected
14:42:25pamauryis 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
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:32pamauryyeah I know the rockbox is more optimise but it works :)
15:03:06pamauryit'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
16:00:10 Join [Saint] [0] (~saint@rockbox/user/saint)
16:20:31***Saving seen data "./dancer.seen"
16:35:02lebelliumwebsite down?
16:36:30 Quit pamaury (Ping timeout: 246 seconds)
16:41:23Bagderyes, zagor is on it
16:44:05gevaertsIs Zagor too heavy? ;)
16:44:53lebelliumhum the homepage has not been updated yet.
16:48:51 Join ikeboy [0] (~dell@ool-435622d3.dyn.optonline.net)
17:00
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:28copperupdated for what?
17:04:03 Join krabador [0] (~krabador_@unaffiliated/krabador)
17:12:45lebelliumchanges 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:00
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:00
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
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:00
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:05Tornewait, taht C code doesn't work for *unaligned* copies
21:37:06Torne?
21:37:09Tornethat makes no sense :)
21:39:21Torneif you want a fast memmove steal the one from symbian, though
21:39:50Tornethat'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:57Torneoh
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:48Torneno, 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:31Torneby 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:33Tornei 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:29Torneno
21:51:35Torneonly if it actually overlaps
21:51:45Torneany decent implementation will avoid copying backward unless absolutely required
21:51:53Tornebecause it's super duper slow on many chips
21:51:57Torneno matter how carefully you align stuff
21:52:19Tornewait
21:52:53Tornethe C one only goes backward if they overlap, but the asm one doesn't check that
21:52:56Torneso 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:00
22:01:26 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu)
22:01:47Tornebecause it forgets to save r0 and lr before it jumps to the backward implementation :)
22:01:51Torneit 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:29Tornebut yeah you almost certainly want to check for overlap, not just src < dest
22:02:38Tornebecause copying backwards suuuuuucks on many systems' memories
22:02:44Torneand 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:21Tornealso 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:35Tornei.e. you should be copying 32 byte *cache lines* not just 32 byte chunks
22:03:38Torneand aggressively preloading them
22:03:52Torneobviously only matters on systems with cache
22:03:57Tornebut 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:35Torneif i can dig up the symbian memcpy you are welcome to it
22:04:38 Join Nephiel [0] (~0288d783@www.haxx.se)
22:04:44Torneit'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:58Torneand it's *probably* the fastest implementation that exists for the chips it was tuned on
22:05:04Tornewhich 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:56Torneno, i saw your comment about that
22:06:07Torneif they have the right symbol types in the object file, i can't imagine why the linker could do the wrong thing
22:06:15Tornehuh
22:06:23Torneactually one wild thought: are they in differently named sections?
22:06:28Tornee.g. because of -ffunction-sections
22:06:40Tornenot sure that matters but it's the only thing that occurs to me
22:07:28[7]yes, they are
22:07:36Tornefailing that i would look at the symbol tables of the objects in detail, with objdump/readelf, not nm
22:07:39Torneah
22:07:40[7]but the caller is in yet another section, so I really don't get it
22:07:50Tornetry having htem in the same section anyway
22:07:53Tornejust to test
22:08:16[7]hm... actually they should both end up in .text.memmove IIUC
22:08:22Tornewell look :)
22:08:28[7]the weak alias for memcpy would probably be in .text.memcpy though
22:09:00Tornenm'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:04Tornelook with readelf
22:09:15Torneit's much more informative about exactly what is in the symbol table
22:10:27Torneoh, 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:00
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)

Previous day | Next day