| 00:03:30 | *** | Saving seen data "./dancer.seen" |
| 00:31:55 | | Quit ac_laptop (Ping timeout: 240 seconds) |
| 02:00 |
| 02:03:32 | *** | Saving seen data "./dancer.seen" |
| 02:45:09 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 03:00 |
| 03:05:06 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 03:11:27 | | Join paulk-leonov-spa [0] (~paulk-leo@196.109.29.93.rev.sfr.net) |
| 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] (~paulk-leo@vpn-0-22.aquilenet.fr) |
| 03:49:49 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 04:00 |
| 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:00 |
| 05:15:05 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
| 06:00 |
| 06:03:36 | *** | Saving seen data "./dancer.seen" |
| 06:57:46 | | Join MrZeus__ [0] (~MrZeus@194.37.96.151) |
| 07:00 |
| 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:00 |
| 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] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 08:48:10 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 08:49:10 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-75f1-84d9-4acc-2114.res6.spectrum.com) |
| 08:53:51 | | Quit jdarnley (Ping timeout: 246 seconds) |
| 08:54:36 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 09:00 |
| 09:27:27 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 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:00 |
| 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 |
| 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] (~J_Darnley@d51a44418.access.telenet.be) |
| 11:26:40 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 11:29:44 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 11:30:56 | | Quit Stanley00 (Ping timeout: 240 seconds) |
| 11:31:18 | | Quit J_Darnley (Ping timeout: 245 seconds) |
| 12:00 |
| 12:00:58 | | Join Lain_ [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 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] (~quassel@adsl-74-250-153-79.ags.bellsouth.net) |
| 12:06:58 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 12:06:58 | | Join xcin [0] (~x@159.203.132.140) |
| 12:06:58 | | Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 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:00 |
| 13:07:13 | | Quit jdarnley (Ping timeout: 276 seconds) |
| 13:10:33 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 14:00 |
| 14:00:50 | * | speachy pokes at bluebot, looking for a sign of life. |
| 14:01:33 | | Join vitt13 [0] (~vitt13@85.174.196.233) |
| 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@209.2.65.77) |
| 14:24:11 | _bilgus | yea 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 | _bilgus | I think and or we should start posting some videos for new features and help topics to hype it up a bit |
| 14:29:21 | _bilgus | I and or we lol |
| 14:31:48 | speachy | in our copious free time |
| 14:32:24 | _bilgus | hehe Idea is to recruit others ;P looks like you did some of that :) |
| 14:33:09 | speachy | speaking of that, look at g#3155 |
| 14:33:23 | speachy | might explain some of the lingering X3 wonkiness |
| 14:34:16 | _bilgus | hell yeah |
| 14:36:10 | | Join fs-bluebot [0] (~fs-bluebo@55d4a316.access.ecotel.net) |
| 14:36:24 | _bilgus | sounds like MIPS is almost as picky about alignments as ARM |
| 14:37:07 | speachy | the code's a tad more verbose, but the not-covering-last-cacheline is a major oops on my part |
| 14:37:09 | _bilgus | oh you said of cache line size thats even worse |
| 14:38:14 | | Quit ubervison (Remote host closed the connection) |
| 14:39:16 | _bilgus | oh Aiden nice catch |
| 15:00 |
| 15:06:27 | speachy | gotta love those off-by-one errors. :/ |
| 15:19:05 | speachy | (I wonder if this might be the cause of the rolo "hang") |
| 15:23:40 | _bilgus | quite possibly |
| 15:24:44 | _bilgus | though I htought that ws working fine after one of your commits |
| 15:29:24 | | Quit vitt13 (Quit: Leaving) |
| 15:29:44 | speachy | no, it's wildly nondeterministic still. |
| 15:50:30 | fs-bluebot | Build 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 |
| 16:00:41 | | Join amachronic [0] (5284bab0@82.132.186.176) |
| 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:55 | amachronic | speachy: 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:55 | amachronic | the caller supposed to ensure alignment, or is this just unintended? |
| 16:06:54 | speachy | Hmm. IIRC there are no alignment rquirements to read/write() |
| 16:07:33 | amachronic | That 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:28 | amachronic | If 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:49 | amachronic | And that would overwrite data read in by DMA, which is bad. |
| 16:08:53 | fs-bluebot | Build Server message: Build round completed after 1103 seconds. |
| 16:08:56 | fs-bluebot | Build Server message: Revision 74a3d1f5be result: All green |
| 16:10:02 | | Quit amachronic (Quit: Connection closed) |
| 16:10:20 | | Join amachronic [0] (5284bab0@82.132.186.176) |
| 16:15:06 | speachy | amachronic: when I was adding DMA to the jz4760's SD and USB drivers, the buffers handed in were always properly aligned |
| 16:15:53 | speachy | can you give some more context where you're seeing these alignment issues? |
| 16:16:06 | amachronic | the only reason I discovered this is because I passed in an unaligned buffer to write() while debugging my NAND code. |
| 16:16:26 | amachronic | it was 4 bytes into a cacheline and the result was the last 4 bytes written to the SD card were garbled |
| 16:16:46 | speachy | the 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:59 | amachronic | oh... I think I know the problem here |
| 16:19:11 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-75f1-84d9-4acc-2114.res6.spectrum.com) |
| 16:19:13 | amachronic | the storage code doesn't actually use STORAGE_ALIGN, it uses CACHEALIGN |
| 16:20:47 | amachronic | so the danger is plugins etc. not using CACHEALIGN and potentially corrupting the SD card |
| 16:20:53 | speachy | yeah |
| 16:23:25 | speachy | the reason for the discrepancy is probably best summarized as "yay, technical baggage" |
| 16:23:54 | amachronic | yep, there's also STORAGE_NEEDS_ALIGN defined in 3 targets but not used anywhere. |
| 16:24:43 | amachronic | given the current usage of STORAGE_WANTS_ALIGN it seems best to remove it to get rid of confusion |
| 16:24:54 | amachronic | it seems as if STORAGE_ALIGN = CACHEALIGN anyway |
| 16:25:21 | speachy | I ssupect STORAGE_ALIGN way predates CACHEALIGN |
| 16:26:27 | | Join daswf852 [0] (~daswf852@unaffiliated/dwf) |
| 16:29:46 | speachy | IIRC our first two major platforms lacked D$ entirely. |
| 16:32:39 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 16:33:16 | | Quit akaWolf (Ping timeout: 276 seconds) |
| 16:33:22 | speachy | amachronic: 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@139.64.244.18) |
| 16:34:39 | | Join copper [0] (~copper@unaffiliated/copper) |
| 16:34:39 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 16:35:47 | amachronic | thanks, checking it out now |
| 16:37:03 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 16:43:54 | | Quit ac_laptop (Ping timeout: 246 seconds) |
| 17:00 |
| 17:06:10 | fs-bluebot | Build Server message: New build round started. Revision 0f439bee99, 293 builds, 9 clients. |
| 17:22:20 | | Quit lebellium (Quit: Leaving) |
| 17:22:50 | fs-bluebot | Build Server message: Build round completed after 1000 seconds. |
| 17:22:53 | fs-bluebot | Build Server message: Revision 0f439bee99 result: All green |
| 17:37:21 | fs-bluebot | Build 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@186.2.247.129) |
| 17:46:17 | | Join bonfire_ [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) |
| 17:47:08 | | Quit bonfire (Ping timeout: 245 seconds) |
| 17:53:13 | | Quit bonfire_ (Ping timeout: 276 seconds) |
| 17:57:09 | fs-bluebot | Build Server message: Build round completed after 1189 seconds. |
| 17:57:16 | fs-bluebot | Build Server message: Revision cde5ae755f result: All green |
| 17:57:22 | | Join PimpiN8 [0] (~PimpiN8@178.239.173.176) |
| 17:58:37 | amachronic | speachy: replied to your review |
| 17:59:32 | amachronic | looks all good to me, but there's a small issue of buttons/keymaps |
| 18:00 |
| 18:03:51 | *** | Saving seen data "./dancer.seen" |
| 18:10:20 | speachy | amachronic: not such a small issue in the end |
| 18:12:00 | speachy | wrt 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:21 | speachy | well worth experimenting with after things are otherwise stable |
| 18:19:16 | amachronic | in 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:50 | amachronic | presumably Rockbox can run with a ridiculously low CPU speed −− like 100-200 MHz? |
| 18:27:42 | braewoods | speachy: 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:59 | braewoods | i would like to see RB 4.x with improved USB features |
| 18:28:11 | braewoods | (on supported targets) |
| 18:28:57 | braewoods | but usb audio seems really hard after reading the spec |
| 18:29:09 | braewoods | i might look at it again after hid power |
| 18:29:27 | braewoods | i want to try a low difficulty project first |
| 18:29:34 | braewoods | so i can learn more about USB |
| 18:42:49 | speachy | that will be much simpler, yeah. |
| 18:44:44 | speachy | _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:38 | amachronic | speachy: I caused a bug trying to fix that cache bug, just pushed a patch |
| 18:56:51 | amachronic | (another stupid off by one error basically, grr) |
| 18:57:41 | speachy | wow, I missed that too. didn't cause my X3 to blow up during my light testing.. |
| 18:58:18 | fs-bluebot | Build Server message: New build round started. Revision 8cb4c18310, 293 builds, 9 clients. |
| 18:58:35 | amachronic | yeah, 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:54 | amachronic | turns out this nand code is good at finding cache bugs |
| 18:58:56 | _bilgus | as long as you keep it under 4 tries you are still doing better than I lol |
| 19:00 |
| 19:02:04 | speachy | hey, we're all doing our part to keep the buildservers warm |
| 19:02:58 | amachronic | i think that original cache bug must've came from "See MIPS Run" |
| 19:03:14 | amachronic | I knew I had seen that loop somewhere else |
| 19:15:00 | fs-bluebot | Build Server message: Build round completed after 1003 seconds. |
| 19:15:03 | fs-bluebot | Build Server message: Revision 8cb4c18310 result: All green |
| 19:25:26 | | Quit PimpiN8 (Quit: Textual IRC Client: www.textualapp.com) |
| 19:44:10 | | Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 19:49:53 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 19:53:47 | | Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) |
| 20:00 |
| 20:03:53 | *** | Saving seen data "./dancer.seen" |
| 20:06:36 | amachronic | another cache bug, another fix |
| 20:06:50 | amachronic | hopefully 3rd time's the charm |
| 20:08:06 | * | speachy chuckles. |
| 20:09:53 | speachy | I 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:50 | speachy | also 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:04 | amachronic | you're right on both counts, but discard_dcache_range is already annoying enough as it is without a THIRD special case |
| 20:15:48 | amachronic | I was just thinking that discarding a non-cache-aligned range is probably a bug... |
| 20:16:32 | amachronic | '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:07 | amachronic | so maybe I should just get rid of those special cases and put a panic in discard_dcache_range instead. |
| 20:17:53 | amachronic | or have I just gotten my brain fried and can't think straight? |
| 20:18:44 | speachy | well yes and no. if your RX DMA buffer is smaller than the cacheline size then that's an insta-panic. |
| 20:19:46 | speachy | (or rather, its final cacheline) |
| 20:20:26 | speachy | it's up to the programmer to not cause somethign else to write into that discarded area. |
| 20:20:34 | amachronic | yeah 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:51 | amachronic | (in my case there was a mutex adjacent to that small buffer) |
| 20:20:52 | speachy | (or cause it to be read back in after you've discarded it) |
| 20:21:48 | speachy | when 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:22 | speachy | and the low-level discard code will have to trust the caller knows what they're doing |
| 20:23:05 | amachronic | I 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:17 | amachronic | I don't think this is happening in practice because of how the buffers are typically allocated in Rockbox |
| 20:23:37 | speachy | yes, buffers tend to be out of the "heap" while stuff like mutexes tend to be static |
| 20:23:54 | amachronic | so 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:14 | speachy | so 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:43 | speachy | ew, DMAing into the stack, therein lies madness. |
| 20:25:03 | amachronic | yes probably not a good idea now that I've thought about it |
| 20:27:26 | speachy | discarding (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:56 | amachronic | what if the CPU can read ahead into the cache speculatively? |
| 20:28:31 | speachy | you'd ideally mark the region as noncacheable |
| 20:28:50 | | Join saratoga [0] (620acd42@cpe-98-10-205-66.rochester.res.rr.com) |
| 20:29:11 | amachronic | ie. "normal" OSs like Linux are immune to these issues because they map DMA buffers to uncached addresses. |
| 20:29:12 | speachy | (I assume the MMU in this thing can do that but we're only setting up the bare minimum on that front..) |
| 20:29:45 | speachy | I'm fairly sure the cache in these things can't speculatively read ahead. |
| 20:30:20 | speachy | but the X1000 (unlike its predecessors) has an actual L2 so I could be wrong |
| 20:31:06 | amachronic | I 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:00 | amachronic | so I figure all DMA buffers must be mapped to uncached space or else we have to discard before AND after DMA finishes. |
| 20:32:30 | amachronic | (1st discard is needed to prevent CPU flushing out bogus data, 2nd discard to get rid of speculative read-ahead) |
| 20:35:03 | speachy | not 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:15 | speachy | but 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:35 | amachronic | seems like jz47xx is not using the MMU either... "map_address" isn't used anywhere |
| 20:38:48 | speachy | the x1000's memory controller doesn't prefetch anything. mips32 has an explicit preferch instruction. |
| 20:39:36 | amachronic | explicit prefetch is just an optimization though |
| 20:39:41 | speachy | yeah |
| 20:40:33 | speachy | https://training.mips.com/basic_mips/PDF/Caches.pdf |
| 20:40:53 | amachronic | considering 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:16 | speachy | so flushing (or discarding) before the DMA and discarding after the DMA looks to be the safest strategy. Other than going full MMU. |
| 20:43:51 | amachronic | that'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:44:02 | speachy | yep. |
| 20:49:23 | | Quit Stanley00 (Remote host closed the connection) |
| 20:52:55 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 20:54:28 | speachy | even 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:45 | amachronic | it was only debug code... so lesson learned |
| 20:55:46 | speachy | I'm coming around to thinking that discard_dcache_range() shouldn't try to writeback things if it's unaligned. |
| 20:56:34 | speachy | it'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:02 | amachronic | easy solution is to just ensure discard_dcache_range() is only ever called on fully cache-aligned ranges |
| 20:57:33 | speachy | tbh I'm pretty sure it is, thanks to CACHE_ALIGNed buffers elsewhere. |
| 20:58:22 | speachy | this 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:54 | amachronic | OK, then just get rid of those special cases |
| 20:59:11 | amachronic | I don't think the original behavior of falling back to commit_discard_dcache_range() was correct either. |
| 20:59:51 | speachy | that was my doing −− in isolation you're correct, but but in the context of the code that called it, it worked. |
| 21:00 |
| 21:00:11 | amachronic | The correct thing is never store any data next to a DMA buffer cacheline |
| 21:00:26 | amachronic | which I think all the jz47xx code satisfied. |
| 21:00:34 | amachronic | so the problems here are all mine. |
| 21:02:15 | amachronic | I think if jz47xx buffers were done correctly, the commit_discard_cache_range() call was unnecessary even for an unaligned address. |
| 21:02:35 | amachronic | since 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 (leguin.freenode.net (Nickname regained by services))) |
| 21:03:06 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 21:03:38 | speachy | well, 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 (leguin.freenode.net (Nickname regained by services))) |
| 21:04:04 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 21:04:05 | speachy | but 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:21 | speachy | (which is us wearing a different hat) |
| 21:06:37 | amachronic | It'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:45 | speachy | so 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:49 | amachronic | Now it's one thing to trust the low-level code to do the right thing. |
| 21:07:24 | amachronic | but 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:47 | speachy | that's the joy of rockbox; if it breaks we get to keep both pieces. |
| 21:08:07 | speachy | and 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:10 | speachy | I 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] (~quassel@adsl-74-250-153-79.ags.bellsouth.net) |
| 21:14:48 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 21:15:35 | | Join ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen) |
| 21:15:44 | amachronic | since the problem should only be with RX buffers, shouldn't that reduce the amount of possible offending code considerably? |
| 21:15:52 | speachy | yep |
| 21:17:19 | | Join skrzyp [0] (~skrzyp@skrzyp.net) |
| 21:18:38 | speachy | so can you respin g#3159 and re-do it to be a straight discard, with no periphery checks? |
| 21:18:40 | fs-bluebot | Gerrit review #3159 at https://gerrit.rockbox.org/r/c/rockbox/+/3159 : Third try fixing MIPS cache code by Aidan MacDonald |
| 21:18:50 | amachronic | yep |
| 21:25:57 | speachy | g#3160 is my double-discarding the cache on RX operations |
| 21:25:59 | fs-bluebot | Gerrit review #3160 at https://gerrit.rockbox.org/r/c/rockbox/+/3160 : mips: re-discard the dcache after RX DMA operations by Solomon Peachy |
| 21:26:01 | | Quit Stanley00 (Remote host closed the connection) |
| 21:26:11 | speachy | and 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@198.46.152.45) |
| 21:37:02 | | Quit spectrumanalyst (Client Quit) |
| 21:38:56 | | Join spectrumanalyst [0] (~admin@198.46.152.45) |
| 21:41:38 | amachronic | looks like storage, USB, and recording are really the only things with public APIs that can accept RX buffers. |
| 21:42:15 | amachronic | seems like storage always passes in dir cache buffers (definitely aligned correctly) |
| 21:42:31 | amachronic | audio recording isn't implemented on jz47xx targets |
| 21:42:45 | amachronic | which seems to leave usb_drv_recv |
| 21:45:40 | fs-bluebot | Build Server message: New build round started. Revision b82298ae2c, 293 builds, 9 clients. |
| 21:48:56 | speachy | well, time to find out how right I am. |
| 21:59:32 | fs-bluebot | Build Server message: Build round completed after 832 seconds. |
| 21:59:34 | fs-bluebot | Build Server message: Revision b82298ae2c result: All green |
| 21:59:35 | fs-bluebot | Build Server message: New build round started. Revision de53965e3f, 293 builds, 9 clients. |
| 22:00 |
| 22:03:57 | *** | Saving seen data "./dancer.seen" |
| 22:08:41 | amachronic | I 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:40 | amachronic | I'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:42 | fs-bluebot | Build Server message: Build round completed after 787 seconds. |
| 22:12:44 | fs-bluebot | Build Server message: Revision de53965e3f result: All green |
| 22:19:25 | | Quit Stanley00 () |
| 22:24:26 | _bilgus | Huh 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@186.2.247.129) |
| 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 | _bilgus | I 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 | _bilgus | ah 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:00 |
| 23:01:28 | braewoods | _bilgus: yea, i found that out earlier. |
| 23:01:30 | speachy | didn't replace the correct one, eh? |
| 23:01:44 | braewoods | _bilgus: it's a handful of targets though |
| 23:01:56 | braewoods | gigabeat S series and some later sansa devices support it |
| 23:03:19 | | Quit XDjackieXD_ (Ping timeout: 272 seconds) |
| 23:03:31 | braewoods | ah |
| 23:03:33 | braewoods | 13 ports have RDS |
| 23:03:42 | braewoods | ipods mainly |
| 23:04:14 | _bilgus | with 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 | _bilgus | ah but only with voice enabled |
| 23:06:58 | _bilgus | hmm thats not good |
| 23:09:24 | | Quit bonfire (Quit: Leaving) |
| 23:14:06 | | Join XDjackieXD [0] (~jackie@tureis.comfix.cc) |
| 23:14:53 | speachy | _bilgus: that sequence doesn't make the X3 go boom |
| 23:15:04 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-75f1-84d9-4acc-2114.res6.spectrum.com) |
| 23:16:51 | speachy | (using default engrish voice) |
| 23:17:27 | speachy | sounds like a bit of historical builds are in order.. |
| 23:19:05 | speachy | abebc6b9ac is the only thing in the last month that has anything do do with playlists. |
| 23:24:43 | _bilgus | perhaps 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] (~Saijin_Na@2603-7081-1d05-7230-41f6-15f2-11ae-6f93.res6.spectrum.com) |
icon identifies that the person is a core developer (has commit access).