--- Log for 27.10.120 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 20 hours ago 00.00.52 Quit S|h|a|w|n (Remote host closed the connection) 00.04.37 Join Stanley|00 [0] (~stanley00@unaffiliated/stanley00) 00.07.10 Quit Stanley00 (Ping timeout: 260 seconds) 00.20.01 Quit TheSeven (Disconnected by services) 00.20.11 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 00.33.37 # <_bilgus> everything 01.09.57 *** Saving seen data "./dancer.seen" 03.10.00 *** No seen item changed, no save performed. 04.15.43 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 04.46.16 Quit pamaury (Ping timeout: 256 seconds) 04.48.27 Join petur [0] (~petur@199.59.5.11) 04.48.27 Quit petur (Changing host) 04.48.27 Join petur [0] (~petur@rockbox/developer/petur) 04.54.47 Quit Rondom (Remote host closed the connection) 04.54.56 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 05.09.13 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 05.10.03 *** Saving seen data "./dancer.seen" 05.44.49 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.50.29 # _bilgus that's a lot of things ! 06.32.06 Quit Stanley|00 (Remote host closed the connection) 07.10.05 *** Saving seen data "./dancer.seen" 07.22.32 Join wodz_home [0] (~wodz@89-64-78-138.dynamic.chello.pl) 07.26.05 # speachy: I have working prototype of bt support. Currently it is commandline which can initiate discovery (and filter results for a2dp_sink capability), pair and connect (using default agent), connect AudioSink. Then with help of parametrized asound.conf pcm entry I am able to aplay -D to bt headset. 07.26.21 # wodz_home: oh, niiice. 07.27.27 # when you do the aplay -D, can you include a --dump-hw-params to see what the raw capabilities are? 07.28.09 # (since they are presumably going to be different than the native pcm codec..) 07.28.14 # The chalanges are: 1) It is based on gdbus. Agptek firmware provides this lib, no problem but rockbox building process will need to be tweaked. 2) No UI. 3) Not tested with our alsa pcm driver) 07.28.22 # sure, wait a sec 07.29.12 # bilgus is sorta working on a prototype UI, keeps getting distracted by our past sins. :) 07.31.31 # HW Params of device "bluetooth:ADDRESS=80:C7:55:63:59:D6": 07.31.31 # -------------------- 07.31.31 # ACCESS: MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED 07.31.31 DBUG Enqueued KICK wodz_home 07.31.31 # FORMAT: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE 07.31.31 # SUBFORMAT: STD 07.31.33 # SAMPLE_BITS: [4 64] 07.31.35 # FRAME_BITS: [4 640000] 07.31.37 # CHANNELS: [1 10000] 07.31.39 # RATE: [4000 4294967295) 07.31.41 # PERIOD_TIME: (10666 256000] 07.31.43 # PERIOD_SIZE: (42 1099511628) 07.31.47 # PERIOD_BYTES: (21 4294967295) 07.31.49 # PERIODS: (0 78536545) 07.31.51 # BUFFER_TIME: [1 4294967295] 07.31.53 # BUFFER_SIZE: [512 3298534882] 07.31.55 # BUFFER_BYTES: [256 4294967295] 07.31.57 # TICK_TIME: ALL 07.31.59 # -------------------- 07.32.01 # ALSA lib audio/pcm_bluetooth.c:2056:(audioservice_recv) Too short (0 bytes) IPC packet from bluetoothd 07.32.03 # aplay: set_params:1166: Unable to install hw params: 07.32.05 # ACCESS: RW_INTERLEAVED 07.32.07 # FORMAT: S16_LE 07.32.09 # SUBFORMAT: STD 07.32.11 # SAMPLE_BITS: 16 07.32.13 # FRAME_BITS: 32 07.32.17 # CHANNELS: 2 07.32.19 # RATE: 44100 07.32.21 # PERIOD_TIME: (46439 46440) 07.32.23 # PERIOD_SIZE: 2048 07.32.25 # PERIOD_BYTES: 8192 07.32.27 # PERIODS: 3 07.32.29 # BUFFER_TIME: (139319 139320) 07.32.31 # BUFFER_SIZE: 6144 07.32.33 # BUFFER_BYTES: 24576 07.32.35 # TICK_TIME: 0 07.33.01 # speachy: ^ 07.33.04 # so in other words, the alsa bluetooth lib will translate from anything to whatever the hw needs. 07.33.14 # seems so 07.33.25 # but it's probably best to lock it to 44 &| 48 KHz. 07.36.09 # wodz_home: our pcm alsa driver should allow the device to be changed at runtime now. There's no real provision for hw caps feedback still. 07.37.42 # but do we need this considering bluetooth alsa device can ingest anything? 07.40.22 # more of a cpu optimization. no sense in rendering at 192KHz with full DSP if it's going to get thrown out 07.40.52 # and on that note, time to see the dentist. 07.40.56 # ahh, I am not used to hires files 08.30.31 Quit prof_wolfff (Ping timeout: 256 seconds) 08.33.06 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 08.37.53 Quit Stanley00 (Ping timeout: 260 seconds) 08.38.52 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:dd7d:4237:a88a:8a76) 08.39.23 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) 08.49.19 Quit kugel (Ping timeout: 265 seconds) 09.10.06 *** Saving seen data "./dancer.seen" 09.41.07 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.49.47 Join kugel [0] (~kugel@ip5b41481c.dynamic.kabel-deutschland.de) 09.49.47 Quit kugel (Changing host) 09.49.47 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.05.46 Quit akaWolf (Read error: Connection reset by peer) 10.06.10 Join akaWolf [0] (~akaWolf@akawolf.org) 10.34.00 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 10.38.09 # braewoods: I've fixed one of the other traps, but the pile in the skinning code concerns me. On the arm side we're not triggering the same trap-ish asm behavior, which makes me suspect there's a deeper root cause we need to find/fix. 10.38.34 Quit Stanley00 (Ping timeout: 256 seconds) 10.39.04 # speachy: perhaps. 10.39.34 # (ie the theme/skin/whatever pointers can't legitimately be null, or badness will happen) 10.41.19 # this might be releated to the theme reload segfault that bilgus ran into on the rocker 10.41.57 # maybe the m68k code gen notices these more 10.42.06 # since it seems to trigger TRAPs for those 10.42.30 # trap #7 specifically 10.42.45 # but we don't use traps so it needs to be disabled in some cases where this is legit behavior 10.43.07 # but those are few 10.43.22 # mostly stuff that needs direct HW access 10.43.47 # speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2917/ <-- i removed the extra whitespace in this patch 10.44.37 # i'll look for more traps later but i was just investigating whether the bootloaders might have the same problem 10.44.39 # they don't. 10.44.58 # they're low level stuff so i thought it should be investigated 10.44.58 # aha! found a 'udf' in the nano2g disasm, same place. 10.45.06 # udf? 10.45.14 # the other targets I was looking at were 1/2bit screens 10.45.20 # 'undefined' instruction 10.45.29 # so it's not m68k-specific. 10.45.34 # ok, gonna try an experiment. 10.46.19 # iirc, the LK's issue with this GCC additions was code like 10.46.20 # backing off before the viewport rework, and see if it still generates the trap/udf 10.46.35 # (const struct ...* foo) 10.46.42 # size_t x = foo->size; 10.46.48 # if(foo == NULL) { ... } 10.46.51 # it would omit the if 10.46.59 # assumes foo cannot be null 10.47.12 # yeah. 10.47.14 # checking after a dereference 10.47.29 Quit pamaury (Quit: Konversation terminated!) 10.48.04 # yeah, it's there prior to the viewport rejigger. 10.48.05 # if you're doing embedded, it doesn't matter so much, but in userspace C, it's illogical to do that. 10.48.56 # so the odds are good that this has been a problem for all mips and hosted arm for a while now. 10.49.20 # and coldfire was just the first to expose it in an obvious instruction? 10.49.55 # well, you tripped over it in the flash tool (which is a rare legitimate use for null pointer dereferences) 10.52.56 # the stuff you found in the skin code is clearly due to bugs. 10.53.19 # the trick is unwinding the tortuous path the gcc optimizer used to make that determination 10.55.20 # Build Server message: New build round started. Revision 61f6987, 293 builds, 9 clients. 10.57.18 # a bunch of plugins have 'trap #15' in 'em 10.58.36 # i'm going to look through gcc source code. what does it use traps for? 10.59.06 # it's intended to trigger an exception that will halt the code 10.59.18 # the os/etc can choose to ignore it in theory 10.59.43 # for RB though it means there's something serious going on probably 10.59.53 # since we don't use TRAPS and don't have "processes" 11.00.06 # so it is effectively a crash point 11.01.04 # well, we _could_ handle it if we wrote the appropriate handler, but yeah, it's a deliberate crash point because the code will deliberately dereference a known-null pointer. 11.02.55 # so these are masking a legit bug. maybe it's as simple as a pointer that's initialized to null but has a code path that can follow it before it's been initialized. 11.03.14 # newer gcc has better diagnostics over this stuff. 11.08.36 # speachy: man embedded stuff like compiler guts seems to be poorly documented 11.08.43 # like why it uses trap #7 11.09.05 # i find it in the source but no explaination how GCC chooses to use it 11.09.16 # it's probably in a motorola architecture document somewher 11.09.28 # actually 11.09.37 # or that was the trap used by example source code 11.09.40 # traps are entirely up to the ABI implementor how they are used 11.09.52 # the Amigas used the 68k differently 11.09.56 # traps 11.09.59 # even 11.10.07 *** Saving seen data "./dancer.seen" 11.10.53 # hazard a guess, it has meaning to Linux m68k 11.11.40 # ok. Linux uses trap #0 for m68k 11.11.43 # for system calls 11.12.41 # Build Server message: Build round completed after 1042 seconds. 11.12.44 # Build Server message: Revision 61f6987 result: 5 errors 0 warnings 11.13.40 # i guess this is similar to the x86_64 syscall instruction or the i386 int 0x80 instruction 11.14.06 Quit massiveH (Quit: Leaving) 11.14.37 # used some hand-coded ASM before but honestly i prefer working with C. juggling registers always made be a bit nervous. lol 11.15.13 # look at g#2918 11.15.15 # Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : WIP: Fix potential null pointer dereferences by Solomon Peachy 11.15.29 # this is what I had to change to get rid of the trap generated by a single function 11.16.19 # wow 11.17.28 # the basic premise is that list->token isn't guaranteed to be not-null 11.17.40 # (or rather, it's guaranteed to be null for some situations) 11.18.09 # is GCC just better at finding obscure situations? 11.18.34 # each version gets better yet. 11.19.53 # consider that skins require parsing user-supplied data, and yes, there's major openings for shenanigans 11.20.16 # now the risk of actual malfesance is pretty low on these things, but still. 11.22.14 # so yeah, I don't want to enable no-delete-null-pointer-checks globally just yet 11.24.53 # most of them don't even have networking so what would one gain from an exploit? 11.25.03 # the worst they can do it delete everything 11.25.18 # we dont' care about exploits but we do care about crashes and data corruption. 11.27.05 # speachy: there's also a trap7 somewhere in the bootup sequence. i've reliably triggered it if i insert USB cable too soon or something. 11.27.25 # there's a trap in the dircache code 11.27.36 # ah. 11.29.50 # look at 2918 again, the dircache 11.30.49 # if idx >=0, get_idx_dcvolp() will return NULL. but the loop terminates at idx = 0. 11.32.32 # is the loop off-by-one, or should vol be checked for NULL? 11.32.37 # ..I don't know. 11.34.53 # braewoods: so congratulations, you stumbled into an entire network of rabbit holes. 11.35.53 # even with that first change I made in the skin_data_free_buflib_allocs(), the actual bug might be that list->token isn't being set when it should be. 11.41.29 # <_bilgus> that seq fault happens when a sbs is applied I can tell its a NULL but still haven't found who exactly, bc its hard to track stuff through the theme engine 11.41.52 # _bilgus: I'm attacking it from the other direction, I think. :/ 11.43.22 # <_bilgus> awesome maybe between us both we wil; find it, It really feels like deja vu 11.43.42 # <_bilgus> like I've chased and fixed this before 11.45.52 # unfortunately i don't think i can help there 11.46.01 # the rest of RB is somewhat beyond me right now 11.46.26 # it's best solved by someone that knows that code already 11.46.30 # this is the first time I've seen any of this code too 11.46.46 # but its original authors are long gone 11.46.54 # leaving just us to pick up the pieces 11.47.15 # <_bilgus> and tromp through it till we understand it 11.47.35 # i may join you once i finish my current goals 11.47.37 # (and the process create as many bugs as we fix) 11.47.43 # <_bilgus> so the loast one was AA thay was g#2540 11.47.45 # Gerrit review #2540 at http://gerrit.rockbox.org/r/2540 : mips: Adjust stack sizes by Solomon Peachy 11.47.46 # (if we're lucky) 11.48.57 # <_bilgus> sorry thats g#2077 11.48.59 # Gerrit review #2077 at http://gerrit.rockbox.org/r/2077 : Fix skin_engine.c Album Art never dealloc'd on theme change by William Wilgus 11.49.16 # <_bilgus> there should be one more 12.02.35 # speachy: g#2919 g#2920 12.02.39 # Gerrit review #2919 at http://gerrit.rockbox.org/r/2919 : iriver_flash: remove trailing whitespaces by James Buren 12.02.39 # Gerrit review #2920 at http://gerrit.rockbox.org/r/2920 : iriver_flash: make cfi_read_id use FB directly by James Buren 12.03.18 # funny story. when i started with frugalware i'm the reason they ended up adding whitespace checks to their lint scripts. i didn't understand what that meant at the time. 12.16.56 Join toffe82 [0] (~kvirc@maf.wirelesstcp.net) 12.23.25 # Build Server message: New build round started. Revision bee736f, 293 builds, 9 clients. 12.26.25 # <_bilgus> ok I traced it down to the backdrop code I need to look at it and see exactly why, maybe its not restoring the proper buffer 12.27.02 Quit wodz_home (Ping timeout: 258 seconds) 12.33.02 Part toffe82 ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") 12.34.58 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 12.36.05 # _bilgus: if you're going through the relevant code do you mind taking a look at FS#12899? 12.36.07 # http://www.rockbox.org/tracker/task/12899 [fuze+] screen jumps navigating in upside-down mode (bugs, new) 12.39.41 Quit Stanley00 (Ping timeout: 258 seconds) 12.43.55 # Build Server message: Build round completed after 1231 seconds. 12.43.56 # Build Server message: Revision bee736f result: 7 errors 0 warnings 12.44.58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.05.30 Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) 13.07.08 Quit tchan (Ping timeout: 272 seconds) 13.10.09 *** Saving seen data "./dancer.seen" 13.14.22 # <_bilgus> mendel_munkis, doubt its related but I have one to test so i'll put it on the list 13.16.49 Quit tchan1 (Quit: WeeChat 2.8) 13.17.08 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 13.20.40 # man that was different 13.21.13 # this noob came into #learnprogramming about a C# question. their issue is they didn't understand they had to initialize the list they were trying to add elements to before they could add to it. 13.21.27 # it was embedded in another class so they assumed it was already initialized 13.21.55 # i'm no C# expert but i still can help with elementary questions like that. 13.41.27 # ok, g#2918 updated. All known traps/etc in the core are fixed. 13.41.31 # Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : WIP: Fix multiple null pointer dereferences by Solomon Peachy 14.06.46 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 14.08.40 # <_bilgus> speachy does this fix the issue I'm currently chasing? 14.09.27 # _bilgus: no idea. 14.10.30 # <_bilgus> oh I should probably check then 14.12.34 # <_bilgus> atm its in the backdrop code Idk if someone references it after its freed it has a ref counter and doesn't seem to be getting freed early buttt 14.14.11 # <_bilgus> no dice was wort a try ;P 14.19.41 # <_bilgus> I'm pretty sure gcc is rightfully concerned though 14.20.35 # I've fixed everything but one case in the lua plugin and one case in the wmapro codec. 14.24.04 # <_bilgus> oh whats the one in lua I'm normally pretty good about that 14.24.43 # it's in luaG_runerror 14.25.29 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 14.28.14 # <_bilgus> oh thats lua core then 14.30.00 Quit Airwave (Quit: WeeChat 2.3) 14.35.54 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 14.40.24 Quit Stanley00 (Ping timeout: 240 seconds) 14.49.30 # Build Server message: New build round started. Revision 7dbfda6, 293 builds, 9 clients. 14.52.47 Quit pamaury (Ping timeout: 265 seconds) 15.04.35 # Build Server message: Build round completed after 906 seconds. 15.04.37 # Build Server message: Revision 7dbfda6 result: All green 15.10.11 *** Saving seen data "./dancer.seen" 15.18.22 # <_bilgus> Speachy I just found it 15.18.41 # <_bilgus> well I just fond why I need to figure out who 15.19.19 # <_bilgus> I bounded the elems in fb_get_address and crash is gone 15.19.44 # <_bilgus> now who is calling the fb with values outside the screen size? 15.24.17 # <_bilgus> lcd_color_common ln 81 return fb->fb_ptr + (element % fb->elems); 15.24.48 # <_bilgus> I'll be back later and try to figure out who and what 15.25.53 Quit petur (Quit: Connection reset by beer) 15.26.47 # <_bilgus> could also be someone expecting a bigger buffer than is currently selected but it should be kinda easy to figure out whom 15.34.05 Join Airwave [0] (~Airwave@ti0006a400-0518.bb.online.no) 15.44.20 # speachy: next time i need to do is find out if flash operations works the same in the H300... 15.44.49 # start with some semi-safe tests to see if erase / program works in unused regions 15.45.13 # the ROM this time around is much larger than the OF uses 15.45.32 # it only uses around 63% of the space 15.45.55 # gives RB plenty of space at least 15.46.09 # around 1.9 MB of space 15.46.11 # if flashed to rom 15.46.15 # for both the ram/rom images 15.46.32 # they're currently around 700KB 15.46.40 # more than enough for future expansion 15.46.50 # provided the H300s survive that long. :> 15.47.42 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.08.38 Join wodz_home [0] (~wodz@89-64-78-138.dynamic.chello.pl) 16.14.18 # ok, I'd appreciate it if g#2918 can be sanity-checked. 16.14.20 # Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : Fix multiple potential null pointer dereferences by Solomon Peachy 16.19.56 # by me? 16.20.25 # by anyone other than myself. in the last iteration I caught a couple of logic goofs. 16.22.36 # so the problem with get_file_serialhash was... 16.22.39 # idx can be 0? 16.23.15 # the problem is the final line; get_idx_dcvolp() returns NULL for idx=0 16.23.40 # so idx is invalid if 0? 16.23.45 # yeah. 16.24.12 # so why do we put >= then? 16.24.18 # the idea is that when you get into negative indexes, it refers directly to the storage volume rather than the directory level. '0' is the root directory of that volume. 16.24.24 # (if I understand the code correctly) 16.24.40 # i see. 16.24.47 # 0 should still be valid then 16.24.49 Quit pamaury (Ping timeout: 264 seconds) 16.25.08 # so your entry at level 0 is the root dir, and will have ->up pointing at a negative number. 16.25.28 # because it has no real parent directory 16.25.33 # exactly 16.25.46 # so negatives are a sentinel value 16.25.51 # a substitute for null 16.26.09 # yup, they're a sentinel that's translated by get_idx_dcvolp() 16.26.42 # so that gets called on a negative value then 16.26.57 # reversi seems simple 16.27.27 # the classic null coalesce check 16.27.31 # or so 16.27.38 # if(p && p->... 16.28.18 # just remembered how you can trigger branching with boolean AND/OR due to how C uses them 16.28.34 # it has to use branching to achieve short-circuit evaluation 16.29.15 # i mean at least if there's possible side-effects 16.29.43 # side-effect free expressions you can choose to branch or not; execution of them or not doesn't matter (at least at the symbolic level) 16.30.06 # still... no idea what compilers actually choose to do 16.30.24 # i still find short-circuit very valuable. i can't imagine programming without it. 16.30.54 # mostly it's used to conditionally perform a check or so that may be hazardous to perform if its assumptions are violated 16.31.26 # ah. 16.31.32 # chessbox pl_malloc 16.31.36 # let me guess... 16.31.53 # it's checking for possible memory exhaustion now 16.31.57 # instead of assuming it always works 16.33.41 # speachy: one criticism that probably won't matter for this too much. your code introduces a new problem, at least if this pl_malloc works the way i suspect it does 16.33.51 # memory leaks if any of these fail 16.34.05 # of course it may be moot if rockbox can reclaim it when the plugin exits 16.34.19 # yeah, rockbox does reclaim it upon plugin termination 16.34.57 # but if the malloc fails it's crashy crashy town anyway, so at least we'll be a little more robust now. 16.35.21 # (ie it's a legit bug, whether or not we care is another matter) 16.35.28 # you can't guarantee execution there so it's probably better to crash the plugin rather than RB itself 16.35.47 # there's not much you can do once you hit OOM situations 16.36.02 # it's better to avoid it but 16.36.05 # tbh it would be quite challenging to OOM the chesbox plugin 16.36.06 # only so much you can do. 16.36.24 # yea... it's better to preallocate instead of relying on malloc if you can. 16.36.31 # but the flexibility malloc offers is sometimes worth the cost 16.36.55 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 16.36.57 # it's a port of an existing codebase, so yeah. 16.37.16 # i mainly prefer stack/fixed allocations whenever possible due to their high efficiency with ram usage 16.37.51 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.37.56 # speachy: is recursion used much in RB? i would hope not due to the limited stack size. 16.38.10 # it's the most common way to cause stack overflow 16.38.17 # it's not used much. 16.38.29 # iterative solutions are usually better 16.38.31 # but again, plugins tend to contain substantial 3rd-party code 16.38.41 # i see. 16.38.47 # our stacks are a lot more limited than our heap 16.38.57 # like 256K or so? 16.39.06 # that was the IRAM for coldfire 16.39.07 # or so 16.39.18 # it seems the stack is allocated out of the fast RAM segments if any 16.39.29 # IRAM on the coldfire is ~48K. 16.39.34 # Oh 16.39.36 # 0xc000 16.39.38 # right 16.39.40 # ok 16.39.45 # I think our main stack is 8K. 16.40.04 # so need to be careful about large string buffers and such 16.40.06 # the codec stack goes there too for speed 16.40.40 # since the coldfire doesn't have a data cache. 16.40.46 # on Linux i routinely use large ass string buffers 16.40.56 # 4K or so 16.41.01 # that would utterly crush RB 16.41.03 # lol 16.41.27 # i guess since when the systems i program for on the desktop have 1+ GB RAM 16.41.36 # i don't tend to consider 4K a lot to as kfor. 16.41.37 Quit Stanley00 (Ping timeout: 264 seconds) 16.41.43 # and process stack limits are like 8MB 16.41.45 # so 16.41.49 # your desktop CPU has more cache than a typical rockbox target has RAM. :) 16.42.53 # i'm still using ivy bridge laptops that have been fully maxed out 16.42.59 # 16G RAM, SSDs. 16.51.33 Quit Barlow (Quit: leaving) 16.58.41 Quit funman (*.net *.split) 16.58.49 Join funman [0] (~fun@chui-pas.net) 17.01.18 # speachy: in statusbar-skinned... seems fine but i noticed it could be an application of the ternary operator 17.02.04 # it seems to just depends on the value of one variable and you want it set in either case 17.02.26 # i often use the GNU extension to the ternary operator at times 17.02.40 # char* s = foo ?: "" 17.02.42 # etc 17.02.51 # empty string if null 17.08.06 # speachy: i think i need to rework the method the flash routines use for waiting for the FLASH to signal completion. 17.08.14 # it uses code that's totally different from the datasheet. 17.08.39 # the datasheets say you need to inspect either the toggle bit or data poll pin 17.09.08 # and the method is the same for both erase/program 17.09.24 # so i think i will make it into a subroutine to reduce code duplication 17.10.13 *** Saving seen data "./dancer.seen" 17.12.08 Join Barlow [0] (~barlow@unaffiliated/barlow) 17.22.08 Quit pamaury (Ping timeout: 265 seconds) 17.54.02 Quit funman (Changing host) 17.54.02 Join funman [0] (~fun@rockbox/developer/funman) 18.24.31 # speachy: a patch about WMA Pro. So 2000's :D 18.33.38 # I started pulling in upstream fixes after the obvious source of the trap continuted to elude me 18.34.07 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 18.35.04 Quit wodz_home (Ping timeout: 256 seconds) 18.38.09 # speachy: suggestions for how I can delay 1 us? 18.38.23 # udelay(1) ? :) 18.38.31 # that's a RB feature? 18.38.35 # most targets have a udelay() function 18.38.43 # (probably all) 18.39.19 Quit Stanley00 (Ping timeout: 260 seconds) 18.39.43 # just the datasheet for the newer rom chip says to delay 1us after completion to allow the chip to resume normal operation 18.39.55 Quit Rower (Ping timeout: 246 seconds) 18.39.57 # so i plan to wait for both cases since it won't hurt the older one 18.40.42 # sleep works for larger units 18.40.49 # but is rather limited for really small ones 18.41.24 # it doesn't appear coldfire has one 18.41.26 # hm 18.41.34 # testing that assumption 18.42.16 Quit lebellium (Quit: Leaving) 18.43.02 Quit emacsomancer (Read error: Connection reset by peer) 18.44.08 # thought so 18.44.11 # no udelay 18.44.57 # some have it most don't 18.45.11 # it's alls mips or arm ones 18.45.33 # i guess i'm not surprised. there's usually no need for something like usleep in the regular software. 18.46.32 # rofl this is weird looking 18.46.40 # the PP system header has... 18.46.48 # the same macro definitions on both ends of the conditionals 18.46.53 # what's up with that? 18.47.42 # I believe the term for that is "technical baggage" 18.48.21 # i see. 18.54.59 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) 19.10.14 *** Saving seen data "./dancer.seen" 19.19.59 # hm 19.20.05 # need to find a way to delay in microseconds 19.20.08 # instead of nanoseconds 19.20.11 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 19.20.11 # * braewoods facepalms. 19.20.20 # 1 us 19.20.21 # not ms 19.20.30 # but rb's normal sleep is 19.20.50 # at best 19.20.52 # 10 ms 19.20.56 # in smallest unit 19.21.01 # 10,000 us 19.29.09 # <__builtin> we have udelay 19.29.43 # i'd use it but it's not available on coldfire 19.29.47 # <__builtin> although I think it's target-specific 19.30.15 # honestly i'm surprised it's not exported as a standard function. 19.30.24 # it can be very usefu 19.30.34 # like if you need to wait for hardware 19.31.47 # to do a delay loop i need... 19.31.52 # 4 instructions 19.32.14 # whatever CF uses for comparison 19.32.20 # an integer register 19.32.35 # add, cmp, jmp... 19.32.45 # jmp if not equal 19.32.48 # or w/e 19.32.53 # so i guess 19.32.55 # 3 19.45.12 Quit pixelma (Ping timeout: 260 seconds) 19.45.12 Quit amiconn (Ping timeout: 260 seconds) 20.04.57 Join amiconn [0] (jens@rockbox/developer/amiconn) 20.05.54 Join pixelma [0] (marianne@rockbox/staff/pixelma) 20.12.12 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 20.12.12 Join fs-bluebot [0] (~fs-bluebo@55d46dc5.access.ecotel.net) 20.14.38 Quit fs-bluebot_ (Ping timeout: 272 seconds) 20.15.54 Quit bluebrother^ (Ping timeout: 272 seconds) 20.33.42 Quit MrZeus (Read error: No route to host) 20.35.11 Join MrZeus [0] (~MrZeus@90.203.212.4) 20.52.23 Quit livvy (Ping timeout: 240 seconds) 21.00.37 Quit vvrng (Ping timeout: 246 seconds) 21.10.15 *** Saving seen data "./dancer.seen" 21.49.00 Quit MrZeus (Ping timeout: 272 seconds) 21.59.12 # Build Server message: New build round started. Revision a5a19a3, 293 builds, 9 clients. 22.16.52 Join saratoga [0] (620acd42@cpe-98-10-205-66.rochester.res.rr.com) 22.18.52 # Build Server message: Build round completed after 1180 seconds. 22.18.54 # Build Server message: Revision a5a19a3 result: 3 errors 0 warnings 22.18.55 # Build Server message: New build round started. Revision bcbf8bb, 293 builds, 8 clients. 22.38.59 # Build Server message: Build round completed after 1204 seconds. 22.39.00 # Build Server message: Revision bcbf8bb result: All green 22.42.41 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 22.42.42 Quit Stanley00 (Remote host closed the connection) 22.43.19 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 22.53.54 # speachy: https://gerrit.rockbox.org/#/c/rockbox/+/2925 22.55.49 # strange time. first time i ever really used volatile. 22.55.50 Quit beencubed (Quit: Leaving) 23.10.17 *** Saving seen data "./dancer.seen" 23.15.16 # wow a WMA commit, that takes me back 23.20.23 # WMA? 23.24.44 # Oh. 23.57.39 # saratoga: didn't fix the "bug" I was hunting but I figured fixing a few CVEs and generally making things more robust wouldn't hurt.