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 2021-03-03

00:03:30***Saving seen data "./dancer.seen"
00:31:55 Quit ac_laptop (Ping timeout: 240 seconds)
02:03:32***Saving seen data "./dancer.seen"
02:45:09 Join lebellium [0] (
03:05:06 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
03:11:27 Join paulk-leonov-spa [0] (
03:11:33 Quit paulk-leonov (Ping timeout: 246 seconds)
03:16:58 Quit paulk-leonov-spa (Ping timeout: 256 seconds)
03:21:49 Join paulk-leonov [0] (
03:49:49 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
04:03:35***Saving seen data "./dancer.seen"
04:31:48 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
04:39:19 Quit ubervison (Quit: Leaving)
05:15:05 Quit S|h|a|w|n (Read error: Connection reset by peer)
06:03:36***Saving seen data "./dancer.seen"
06:57:46 Join MrZeus__ [0] (~MrZeus@
07:34:12 Quit Stanley00 (Remote host closed the connection)
07:34:51 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
07:39:20 Quit Stanley00 (Ping timeout: 256 seconds)
07:55:01 Quit pamaury (Ping timeout: 272 seconds)
08:03:37***Saving seen data "./dancer.seen"
08:29:09 Quit Saijin_Naib (Remote host closed the connection)
08:33:30 Quit ufdm (Read error: Connection reset by peer)
08:33:47 Join ufdm [0] (
08:48:10 Join massiveH [0] (
08:49:10 Join Saijin_Naib [0] (
08:53:51 Quit jdarnley (Ping timeout: 246 seconds)
08:54:36 Join J_Darnley [0] (
09:27:27 Join jdarnley [0] (
09:29:13 Quit J_Darnley (Ping timeout: 245 seconds)
09:42:02 Quit Huntereb (Ping timeout: 264 seconds)
09:44:05 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57)
10:03:41***Saving seen data "./dancer.seen"
10:16:41 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
10:28:22 Quit massiveH (Quit: Leaving)
11:00:09 Quit blbro[m] (Quit: Idle for 30+ days)
11:11:16 Quit jdarnley (Ping timeout: 256 seconds)
11:22:40 Join J_Darnley [0] (
11:26:40 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
11:29:44 Join jdarnley [0] (
11:30:56 Quit Stanley00 (Ping timeout: 240 seconds)
11:31:18 Quit J_Darnley (Ping timeout: 245 seconds)
12:00:58 Join Lain_ [0] (
12:01:05 Quit Strife89 (*.net *.split)
12:01:05 Quit mikroflops (*.net *.split)
12:01:05 Quit xcin (*.net *.split)
12:01:06 Quit Acou_Bass (*.net *.split)
12:01:20 Quit CR0W (*.net *.split)
12:01:20 Quit toruvinn (*.net *.split)
12:03:44***Saving seen data "./dancer.seen"
12:06:58 Join Strife89 [0] (
12:06:58 Join mikroflops [0] (
12:06:58 Join xcin [0] (~x@
12:06:58 Join Acou_Bass [0] (
12:06:58 Join CR0W [0] (~narf@unaffiliated/em64t)
12:41:21 Quit Romster (Ping timeout: 264 seconds)
12:42:36 Join Romster [0] (~romster@unaffiliated/romster)
12:51:51 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc)
13:07:13 Quit jdarnley (Ping timeout: 276 seconds)
13:10:33 Join J_Darnley [0] (
14:00:50*speachy pokes at bluebot, looking for a sign of life.
14:01:33 Join vitt13 [0] (~vitt13@
14:03:47***Saving seen data "./dancer.seen"
14:08:59 Quit tomato (K-Lined)
14:09:00 Quit MrZeus__ (K-Lined)
14:09:39 Quit speachy (Quit: WeeChat 3.0)
14:12:05 Quit koniu (Ping timeout: 268 seconds)
14:14:11 Join speachy [0] (~speachy@
14:24:11_bilgusyea its weaird when he isn't here
14:24:37 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
14:28:55 Quit TheLemonMan (Ping timeout: 240 seconds)
14:29:07_bilgusI think and or we should start posting some videos for new features and help topics to hype it up a bit
14:29:21_bilgusI and or we lol
14:31:48speachyin our copious free time
14:32:24_bilgushehe Idea is to recruit others ;P looks like you did some of that :)
14:33:09speachyspeaking of that, look atg#3155
14:33:23speachymight explain some of the lingering X3 wonkiness
14:34:16_bilgushell yeah
14:36:10 Join fs-bluebot [0] (
14:36:24_bilgussounds like MIPS is almost as picky about alignments as ARM
14:37:07speachythe code's a tad more verbose, but the not-covering-last-cacheline is a major oops on my part
14:37:09_bilgusoh you said of cache line size thats even worse
14:38:14 Quit ubervison (Remote host closed the connection)
14:39:16_bilgusoh Aiden nice catch
15:06:27speachygotta love those off-by-one errors. :/
15:19:05speachy(I wonder if this might be the cause of the rolo "hang")
15:23:40_bilgusquite possibly
15:24:44_bilgusthough I htought that ws working fine after one of your commits
15:29:24 Quit vitt13 (Quit: Leaving)
15:29:44speachyno, it's wildly nondeterministic still.
15:50:30fs-bluebotBuild Server message: New build round started. Revision 74a3d1f5be, 293 builds, 9 clients.
15:55:09 Quit Saijin_Naib (Read error: Connection reset by peer)
15:57:55 Quit pamaury (Ping timeout: 240 seconds)
16:00:41 Join amachronic [0] (5284bab0@
16:02:27 Quit 94KAAA9XE ()
16:03:41 Join Tsesarevich [0] (sid83162@fluxbuntu/founder/joejaxx)
16:03:50***Saving seen data "./dancer.seen"
16:04:55amachronicspeachy: I wanted to ask you (or really anyone who knows the answer) about buffer alignments on the rockbox file API, it seems they do not respect the STORAGE_WANTS_ALIGN macro. If you pass in an unaligned buffer to read() or write() it seems to get passed directly down to the target's storage API (breaking the storage alignment requirements). Is
16:04:55amachronicthe caller supposed to ensure alignment, or is this just unintended?
16:06:54speachyHmm. IIRC there are no alignment rquirements to read/write()
16:07:33amachronicThat could be a big problem then, because I think there's no correct way to do DMA if the buffer is not aligned to a cache line.
16:08:28amachronicIf data in the same cacheline as the DMA buffer's start is modified, it will have to be written back along with some initial portion of the DMA buffer
16:08:49amachronicAnd that would overwrite data read in by DMA, which is bad.
16:08:53fs-bluebotBuild Server message: Build round completed after 1103 seconds.
16:08:56fs-bluebotBuild Server message: Revision 74a3d1f5be result: All green
16:10:02 Quit amachronic (Quit: Connection closed)
16:10:20 Join amachronic [0] (5284bab0@
16:15:06speachyamachronic: when I was adding DMA to the jz4760's SD and USB drivers, the buffers handed in were always properly aligned
16:15:53speachycan you give some more context where you're seeing these alignment issues?
16:16:06amachronicthe only reason I discovered this is because I passed in an unaligned buffer to write() while debugging my NAND code.
16:16:26amachronicit was 4 bytes into a cacheline and the result was the last 4 bytes written to the SD card were garbled
16:16:46speachythe only STORAGE_ALIGN_ATTR tags I see in the code are all in NAND FTL code
16:18:00 Quit daswf852 (Remote host closed the connection)
16:18:59amachronicoh... I think I know the problem here
16:19:11 Join Saijin_Naib [0] (
16:19:13amachronicthe storage code doesn't actually use STORAGE_ALIGN, it uses CACHEALIGN
16:20:47amachronicso the danger is plugins etc. not using CACHEALIGN and potentially corrupting the SD card
16:23:25speachythe reason for the discrepancy is probably best summarized as "yay, technical baggage"
16:23:54amachronicyep, there's also STORAGE_NEEDS_ALIGN defined in 3 targets but not used anywhere.
16:24:43amachronicgiven the current usage of STORAGE_WANTS_ALIGN it seems best to remove it to get rid of confusion
16:24:54amachronicit seems as if STORAGE_ALIGN = CACHEALIGN anyway
16:25:21speachyI ssupect STORAGE_ALIGN way predates CACHEALIGN
16:26:27 Join daswf852 [0] (~daswf852@unaffiliated/dwf)
16:29:46speachyIIRC our first two major platforms lacked D$ entirely.
16:32:39 Join ac_laptop [0] (~ac_laptop@
16:33:16 Quit akaWolf (Ping timeout: 276 seconds)
16:33:22speachyamachronic: just sent the initial review; really a bunch of minor comments.
16:33:37 Quit advcomp2019 (*.net *.split)
16:33:38 Quit nast (*.net *.split)
16:33:38 Quit copper (*.net *.split)
16:33:39 Quit rasher (*.net *.split)
16:33:47 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
16:34:35 Quit J_Darnley (Ping timeout: 240 seconds)
16:34:39 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
16:34:39 Join nast [0] (~nast@
16:34:39 Join copper [0] (~copper@unaffiliated/copper)
16:34:39 Join rasher [0] (~rasher@rockbox/developer/rasher)
16:35:47amachronicthanks, checking it out now
16:37:03 Join J_Darnley [0] (
16:43:54 Quit ac_laptop (Ping timeout: 246 seconds)
17:06:10fs-bluebotBuild Server message: New build round started. Revision 0f439bee99, 293 builds, 9 clients.
17:22:20 Quit lebellium (Quit: Leaving)
17:22:50fs-bluebotBuild Server message: Build round completed after 1000 seconds.
17:22:53fs-bluebotBuild Server message: Revision 0f439bee99 result: All green
17:37:21fs-bluebotBuild Server message: New build round started. Revision cde5ae755f, 293 builds, 9 clients.
17:38:27 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
17:38:27 Quit TheLemonMan (Client Quit)
17:38:52 Join ac_laptop [0] (~ac_laptop@
17:46:17 Join bonfire_ [0] (
17:47:08 Quit bonfire (Ping timeout: 245 seconds)
17:53:13 Quit bonfire_ (Ping timeout: 276 seconds)
17:57:09fs-bluebotBuild Server message: Build round completed after 1189 seconds.
17:57:16fs-bluebotBuild Server message: Revision cde5ae755f result: All green
17:57:22 Join PimpiN8 [0] (~PimpiN8@
17:58:37amachronicspeachy: replied to your review
17:59:32amachroniclooks all good to me, but there's a small issue of buttons/keymaps
18:03:51***Saving seen data "./dancer.seen"
18:10:20speachyamachronic: not such a small issue in the end
18:12:00speachywrt clocks −− since we're able to have everything on a single PLL that's probably going to save more power than clocking down two PLLs. But who knows.. on the X3 all of the work I did to reclock things barely budged the battery life needle, perhaps because the power and audio circuitry dwarfed anything the main SoC did.
18:12:21speachywell worth experimenting with after things are otherwise stable
18:19:16amachronicin terms of power savings, I think clocking down the main CPU will be the biggest impact. I might be wrong but I don't think the OF does so
18:19:50amachronicpresumably Rockbox can run with a ridiculously low CPU speed −− like 100-200 MHz?
18:27:42braewoodsspeachy: i should be able to start looking at HID power later this week. i ordered a unit from amazon i should get soon.
18:27:59braewoodsi would like to see RB 4.x with improved USB features
18:28:11braewoods(on supported targets)
18:28:57braewoodsbut usb audio seems really hard after reading the spec
18:29:09braewoodsi might look at it again after hid power
18:29:27braewoodsi want to try a low difficulty project first
18:29:34braewoodsso i can learn more about USB
18:42:49speachythat will be much simpler, yeah.
18:44:44speachy_bilgus: the X3's rolo "hang" is really just some sort of timeout that's not properly triggering. This time it took about 10s, last time it was instantaneous, time before that at least a minute before I whacked reset
18:56:38amachronicspeachy: I caused a bug trying to fix that cache bug, just pushed a patch
18:56:51amachronic(another stupid off by one error basically, grr)
18:57:41speachywow, I missed that too. didn't cause my X3 to blow up during my light testing..
18:58:18fs-bluebotBuild Server message: New build round started. Revision 8cb4c18310, 293 builds, 9 clients.
18:58:35amachronicyeah, it only occurs if you try to discard one cache line... under certain conditions... which happened when using NAND DMA to read 2 bytes from flash
18:58:54amachronicturns out this nand code is good at finding cache bugs
18:58:56_bilgusas long as you keep it under 4 tries you are still doing better than I lol
19:02:04speachyhey, we're all doing our part to keep the buildservers warm
19:02:58amachronici think that original cache bug must've came from "See MIPS Run"
19:03:14amachronicI knew I had seen that loop somewhere else
19:15:00fs-bluebotBuild Server message: Build round completed after 1003 seconds.
19:15:03fs-bluebotBuild Server message: Revision 8cb4c18310 result: All green
19:25:26 Quit PimpiN8 (Quit: Textual IRC Client:
19:44:10 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC:
19:49:53 Join St3ak [0] (
19:53:47 Join bonfire [0] (
20:03:53***Saving seen data "./dancer.seen"
20:06:36amachronicanother cache bug, another fix
20:06:50amachronichopefully 3rd time's the charm
20:08:06*speachy chuckles.
20:09:53speachyI vaguely recall that the addresses didn't need to be explicitly aligned in the cache discard/flush instructions; it would just truncate things.
20:11:50speachyalso if the size of region you want to discard is larger than the cache, it's faster to just discard the whole cache.
20:13:04amachronicyou're right on both counts, but discard_dcache_range is already annoying enough as it is without a THIRD special case
20:15:48amachronicI was just thinking that discarding a non-cache-aligned range is probably a bug...
20:16:32amachronic'cause if the CPU data is wrong, we can't choose to flush out only the "good" parts of the cache line and discard the "bad" parts
20:17:07amachronicso maybe I should just get rid of those special cases and put a panic in discard_dcache_range instead.
20:17:53amachronicor have I just gotten my brain fried and can't think straight?
20:18:44speachywell yes and no. if your RX DMA buffer is smaller than the cacheline size then that's an insta-panic.
20:19:46speachy(or rather, its final cacheline)
20:20:26speachyit's up to the programmer to not cause somethign else to write into that discarded area.
20:20:34amachronicyeah but my point is, if the RX buffer is smaller than a cacheline size, there might be _useful_ data that someone else has stored in the rest of the cacheline.
20:20:51amachronic(in my case there was a mutex adjacent to that small buffer)
20:20:52speachy(or cause it to be read back in after you've discarded it)
20:21:48speachywhen we're handed a region to DMA that's within a larger buffer, it can be a perfectly legal DMA even if it's unaligned within the cacheline
20:22:22speachyand the low-level discard code will have to trust the caller knows what they're doing
20:23:05amachronicI agree the DMA would be legal,  and obviously it's programmer's job to make sure the discarded range is correct, but the compiler might place things at an adjacent address within the cacheline.
20:23:17amachronicI don't think this is happening in practice because of how the buffers are typically allocated in Rockbox
20:23:37speachyyes, buffers tend to be out of the "heap" while stuff like mutexes tend to be static
20:23:54amachronicso the only reason I'm hitting this bug is because I'm using the NAND controller DMA to write into unsigned integers on the stack and static buffers.
20:24:14speachyso that would seem to indicate that any static buffer you care about needs to be at least CACHELINE_SIZE bytes, and explicitly aligned.
20:24:43speachyew, DMAing into the stack, therein lies madness.
20:25:03amachronicyes probably not a good idea now that I've thought about it
20:27:26speachydiscarding (vs writeback) is really just a performance optimization. it's up to the programmer to make sure nothing else tries to access the dma buffer (+surroundings) while the DMA is in process. so discard at the start of the RX, and assume nothing else mucked with that code.
20:27:56amachronicwhat if the CPU can read ahead into the cache speculatively?
20:28:31speachyyou'd ideally mark the region as noncacheable
20:28:50 Join saratoga [0] (
20:29:11amachronicie. "normal" OSs like Linux are immune to these issues because they map DMA buffers to uncached addresses.
20:29:12speachy(I assume the MMU in this thing can do that but we're only setting up the bare minimum on that front..)
20:29:45speachyI'm fairly sure the cache in these things can't speculatively read ahead.
20:30:20speachybut the X1000 (unlike its predecessors) has an actual L2 so I could be wrong
20:31:06amachronicI haven't tested myself either, but I ran into weird issues with the SD code where the DMA buffer got filled with garbage near the beginning, and this was the only explanation I could come up with
20:32:00amachronicso I figure all DMA buffers must be mapped to uncached space or else we have to discard before AND after DMA finishes.
20:32:30amachronic(1st discard is needed to prevent CPU flushing out bogus data, 2nd discard to get rid of speculative read-ahead)
20:35:03speachynot sure where I'd even be able to look that stuff up. the generic cache discard/wb is part of the mips32 core.
20:36:15speachybut the MIPS core really does expect you to use the MMU to set up the "Cacheability and Coherencey Attribute"
20:36:26 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
20:38:35amachronicseems like jz47xx is not using the MMU either... "map_address" isn't used anywhere
20:38:48speachythe x1000's memory controller doesn't prefetch anything. mips32 has an explicit preferch instruction.
20:39:36amachronicexplicit prefetch is just an optimization though
20:40:53amachronicconsidering side-channel cache attacks on intel/AMD/ARM chips (all doing this kind of read-ahead too), it seems unwise to assume that CPUs only load an address into cache when explicitly referenced from program code
20:43:16speachyso flushing (or discarding) before the DMA and discarding after the DMA looks to be the safest strategy. Other than going full MMU.
20:43:51amachronicthat's what I've concluded. really we're just supposed to use the MMU like a real OS and not worry about this crap.
20:49:23 Quit Stanley00 (Remote host closed the connection)
20:52:55 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
20:54:28speachyeven with these discard/flush games there's nothing to guarantee some other part of the codebase isn't doing something stupid. like putting a mutex in the same cacheline as the DMA buffer.
20:55:45amachronicit was only debug code... so lesson learned
20:55:46speachyI'm coming around to thinking that discard_dcache_range() shouldn't try to writeback things if it's unaligned.
20:56:34speachyit's debatable which set of bugs is worse −− the stuff that gets witten that you didn't want, or stuff doesn't get written that you want.
20:57:02amachroniceasy solution is to just ensure discard_dcache_range() is only ever called on fully cache-aligned ranges
20:57:33speachytbh I'm pretty sure it is, thanks to CACHE_ALIGNed buffers elsewhere.
20:58:22speachythis is hotpath code though, so we really do want to keep it as fast as possible and get rid of special case tests.
20:58:54amachronicOK, then just get rid of those special cases
20:59:11amachronicI don't think the original behavior of falling back to commit_discard_dcache_range() was correct either.
20:59:51speachythat was my doing −− in isolation you're correct, but but in the context of the code that called it, it worked.
21:00:11amachronicThe correct thing is never store any data next to a DMA buffer cacheline
21:00:26amachronicwhich I think all the jz47xx code satisfied.
21:00:34amachronicso the problems here are all mine.
21:02:15amachronicI think if jz47xx buffers were done correctly, the commit_discard_cache_range() call was unnecessary even for an unaligned address.
21:02:35amachronicsince there would be no useful data in the adjacent areas anyway.
21:03:06 Nick amiconn is now known as Guest64274 (jens@rockbox/developer/amiconn)
21:03:06 Join amiconn_ [0] (jens@rockbox/developer/amiconn)
21:03:06 Quit Guest64274 (Killed ( (Nickname regained by services)))
21:03:06 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn)
21:03:38speachywell, we can't control the buffers handed down to us from up high.
21:03:55 Quit St3ak (Ping timeout: 240 seconds)
21:04:04 Join pixelma_ [0] (marianne@rockbox/staff/pixelma)
21:04:04 Quit pixelma (Killed ( (Nickname regained by services)))
21:04:04 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma)
21:04:05speachybut we have to trust the caller knows what it's doing.
21:04:05 Quit ArsenArsen (Ping timeout: 260 seconds)
21:04:19 Quit skrzyp (Ping timeout: 276 seconds)
21:04:21speachy(which is us wearing a different hat)
21:06:37amachronicIt's definitely _possible_ to store useful data in the same cacheline as the DMA buffer, but ONLY if that data is not modified while the DMA is ongoing.
21:06:45speachyso the big question −− do a commit_discard_range() prior to DMA, and a discard_range afterwards, or trust everything and just discard_range at the outset.
21:06:49amachronicNow it's one thing to trust the low-level code to do the right thing.
21:07:24amachronicbut the low-level code just gets things handed down from high up (even plugins) and has no way to enforce proper data layout.
21:07:47speachythat's the joy of rockbox; if it breaks we get to keep both pieces.
21:08:07speachyand why we're all paid the big bucks to make sure it's done correctly
21:11:40 Quit Strife89 (Remote host closed the connection)
21:13:10speachyI don't want to panic but if we are getting unaligned rx buffers I'd really like to know.
21:13:21 Join Strife89 [0] (
21:14:48 Join St3ak [0] (
21:15:35 Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen)
21:15:44amachronicsince the problem should only be with RX buffers, shouldn't that reduce the amount of possible offending code considerably?
21:17:19 Join skrzyp [0] (
21:18:38speachyso can you resping#3159 and re-do it to be a straight discard, with no periphery checks?
21:18:40fs-bluebotGerrit review #3159 at : Third try fixing MIPS cache code by Aidan MacDonald
21:25:57speachyg#3160 is my double-discarding the cache on RX operations
21:25:59fs-bluebotGerrit review #3160 at : mips: re-discard the dcache after RX DMA operations by Solomon Peachy
21:26:01 Quit Stanley00 (Remote host closed the connection)
21:26:11speachyand fixed a bug in the jz4740 usb code too.
21:27:25 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
21:34:49 Quit spectrumanalyst (Quit: Bye!)
21:35:35 Join spectrumanalyst [0] (~admin@
21:37:02 Quit spectrumanalyst (Client Quit)
21:38:56 Join spectrumanalyst [0] (~admin@
21:41:38amachroniclooks like storage, USB, and recording are really the only things with public APIs that can accept RX buffers.
21:42:15amachronicseems like storage always passes in dir cache buffers (definitely aligned correctly)
21:42:31amachronicaudio recording isn't implemented on jz47xx targets
21:42:45amachronicwhich seems to leave usb_drv_recv
21:45:40fs-bluebotBuild Server message: New build round started. Revision b82298ae2c, 293 builds, 9 clients.
21:48:56speachywell, time to find out how right I am.
21:59:32fs-bluebotBuild Server message: Build round completed after 832 seconds.
21:59:34fs-bluebotBuild Server message: Revision b82298ae2c result: All green
21:59:35fs-bluebotBuild Server message: New build round started. Revision de53965e3f, 293 builds, 9 clients.
22:03:57***Saving seen data "./dancer.seen"
22:08:41amachronicI think it should be possible to use the Index Load Tag cache op to figure out if the CPU prefetches data into the cache.
22:10:40amachronicI'll try doing this sometime but it's too late right now, got to call it quits for today.
22:10:56 Quit amachronic (Quit: Connection closed)
22:12:42fs-bluebotBuild Server message: Build round completed after 787 seconds.
22:12:44fs-bluebotBuild Server message: Revision de53965e3f result: All green
22:19:25 Quit Stanley00 ()
22:24:26_bilgusHuh m y clip zip has RDS sttion info WOW I didn't know we supported that
22:24:27 Quit ac_laptop (Quit: WeeChat 3.0)
22:24:47 Join ac_laptop [0] (~ac_laptop@
22:29:28 Quit ac_laptop (Ping timeout: 276 seconds)
22:37:50 Quit ats_ (Ping timeout: 264 seconds)
22:38:08 Quit saratoga (Quit: Connection closed)
22:47:46 Quit Saijin_Naib (Read error: Connection reset by peer)
22:50:29_bilgusI thought voice files were build with dailies now? I'm getting an Incompatible version message even with the build listed above the voice files?
22:52:58_bilgusah its the us lang file that is broken
22:54:31 Join f1reflyylmao [0] (~f1refly@2a01:c22:8402:5f00:8838:4772:e6d9:a4bb)
22:55:41 Quit f1refly (Ping timeout: 258 seconds)
22:55:41 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:8402:5f00:8838:4772:e6d9:a4bb)
23:01:28braewoods_bilgus: yea, i found that out earlier.
23:01:30speachydidn't replace the correct one, eh?
23:01:44braewoods_bilgus: it's a handful of targets though
23:01:56braewoodsgigabeat S series and some later sansa devices support it
23:03:19 Quit XDjackieXD_ (Ping timeout: 272 seconds)
23:03:33braewoods13 ports have RDS
23:03:42braewoodsipods mainly
23:04:14_bilguswith the latest build on the clip zip if I start playback, stop with power button got to plugin 2048 and use the playback control to resume playback I get PANIC playlist_resume() OOM
23:06:47_bilgusah but only with voice enabled
23:06:58_bilgushmm thats not good
23:09:24 Quit bonfire (Quit: Leaving)
23:14:06 Join XDjackieXD [0] (
23:14:53speachy_bilgus: that sequence doesn't make the X3 go boom
23:15:04 Join Saijin_Naib [0] (
23:16:51speachy(using default engrish voice)
23:17:27speachysounds like a bit of historical builds are in order..
23:19:05speachyabebc6b9ac is the only thing in the last month that has anything do do with playlists.
23:24:43_bilgusperhaps voice isn't givimg back the buffer like it should
23:34:05 Quit Saijin_Naib (Remote host closed the connection)
23:51:00 Join Saijin_Naib [0] (

Previous day | Next day