| 00:04:00 | *** | Saving seen data "./dancer.seen" |
| 00:16:12 | | Quit Strife89 (Quit: Later!) |
| 00:16:57 | | Join Strife89 [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net) |
| 02:00 |
| 02:04:01 | *** | Saving seen data "./dancer.seen" |
| 02:42:14 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 02:53:51 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 03:00 |
| 03:31:11 | | Join prg3_ [0] (~prg@deadcodersociety/prg318) |
| 03:32:43 | | Join rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de) |
| 03:35:28 | | Join ParkerR [0] (ParkerR@znc.withg.org) |
| 03:35:28 | | Quit ParkerR (Changing host) |
| 03:35:28 | | Join ParkerR [0] (ParkerR@unaffiliated/parkerr) |
| 03:43:31 | | Quit ParkerR_ (*.net *.split) |
| 03:43:31 | | Quit rudi_s_ (*.net *.split) |
| 03:43:31 | | Quit prg3 (*.net *.split) |
| 03:43:32 | | Quit Galois (*.net *.split) |
| 04:00 |
| 04:04:02 | *** | Saving seen data "./dancer.seen" |
| 04:42:45 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 05:00 |
| 05:50:39 | | Quit koniu (Ping timeout: 268 seconds) |
| 05:54:40 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 06:00 |
| 06:04:06 | *** | Saving seen data "./dancer.seen" |
| 06:06:23 | | Quit koniu (Remote host closed the connection) |
| 06:06:49 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 06:39:42 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 06:55:55 | speachy | _bilgus: well, it only has 8MB RAM vs the X3's 32... maybe what happened is incrementally greater memory usage pushed the zip over the edge? |
| 06:56:15 | speachy | how old was the previous build (that presumably worked?) |
| 07:00 |
| 07:05:30 | _bilgus | speachy hard telling its such a specific set of actions though shouldn't take too lng to figure it out |
| 07:11:25 | _bilgus | I'm guessing its probably a race condition |
| 07:11:26 | | Quit pamaury (Ping timeout: 264 seconds) |
| 07:38:49 | | Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) |
| 07:42:22 | | Quit TheLemonMan (Remote host closed the connection) |
| 08:00 |
| 08:04:10 | *** | Saving seen data "./dancer.seen" |
| 08:07:27 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 08:09:23 | speachy | I'm considerint bumping up the codec space from 1MB to 2MB on >16MB targets |
| 08:10:00 | speachy | so these large mp4 audio books can be loaded |
| 08:10:28 | speachy | unless we can the codecs can be finagled to allocate a bit from the main buffer? |
| 08:16:39 | _bilgus | talk_buffer_set_policy(TALK_BUFFER_LOOSE); |
| 08:17:18 | _bilgus | well found something that makes the voice buffer allow shrink |
| 08:19:27 | speachy | I guess the adding-talk-to-plugins didnt' account for that case |
| 08:21:06 | _bilgus | well tbf its always been there we just are getting close to the upper limits for that 8MB |
| 08:21:26 | _bilgus | previously the talk buffer wasn't filling up all available ram |
| 08:21:46 | speachy | either way we shouldn't be panicing |
| 08:22:03 | _bilgus | wellll it could be handled more gracefully |
| 08:22:18 | _bilgus | but at least its readily apparent |
| 08:25:58 | _bilgus | YAY |
| 08:27:44 | _bilgus | It could also be made to fallback to the plugin area in these situations as well |
| 08:32:47 | fs-bluebot | Build Server message: New build round started. Revision 80be135d0d, 293 builds, 9 clients. |
| 08:33:30 | _bilgus | That one is fixed but I'm sure there are more just waiting to be discovered |
| 08:35:16 | _bilgus | This clipzip is getting pretty bad it no longer has the down button or home makes navigating the menus and playback tricky lol |
| 08:35:18 | | Quit koniu (Ping timeout: 268 seconds) |
| 08:35:55 | _bilgus | I'd go open up another but I keep hoping for one of em to come back from family for spare parts |
| 08:38:33 | speachy | c |
| 08:43:44 | fs-bluebot | Build Server message: Build round completed after 657 seconds. |
| 08:43:48 | fs-bluebot | Build Server message: Revision 80be135d0d result: All green |
| 08:44:58 | _bilgus | speachy https://github.com/Rockbox/rockbox/blob/master/firmware/rolo.c#L245 |
| 08:45:11 | _bilgus | notice anything about the return for that call? |
| 08:45:25 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 08:47:04 | speachy | we don't check for errors? |
| 08:47:17 | _bilgus | mhmm |
| 08:47:36 | _bilgus | we'll panic there for now |
| 08:48:12 | speachy | ... but that doesn't match the symptoms, which is that there's a variable delay |
| 08:48:43 | _bilgus | I figure its overwriting memory |
| 08:48:53 | speachy | also manually rolo'ing a firmware file via the browser always seems to succeed; it's only the post-usb-detach prompt |
| 08:49:47 | _bilgus | well if its not an issue I guess we won't get any panics |
| 08:50:13 | speachy | is panicing the right thing? as opposed to simply a splash error and continuing? |
| 08:51:00 | speachy | heh, also CPU_COLDFIRE | CPU_ARM | CPU_MIPS is all-inclusive now. |
| 08:53:10 | _bilgus | what point to continue there is no memory |
| 08:53:28 | speachy | s/continue/return/ |
| 08:54:12 | _bilgus | we can Idk if there is any point but I guess you could fail out then restart manually |
| 08:54:14 | speachy | at that point all we've done is overwrite the display and stop playback |
| 08:54:38 | speachy | (Assuming that core_alloc_maximum() doesn't trash anything) |
| 08:54:45 | speachy | (when it fails) |
| 08:57:45 | _bilgus | it doesn't |
| 08:59:37 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:01:08 | fs-bluebot | Build Server message: New build round started. Revision 15b4d22913, 293 builds, 9 clients. |
| 09:01:16 | speachy | what do you think about g#3164 ? |
| 09:01:18 | fs-bluebot | Gerrit review #3164 at https://gerrit.rockbox.org/r/c/rockbox/+/3164 : Clean up places that use #if defined(CPU_ARM | CPU_COLDFIRE | CPU_MIPS) by Solomon Peachy |
| 09:04:54 | | Quit koniu (Ping timeout: 268 seconds) |
| 09:05:40 | _bilgus | less ifdef is always a welcome sight |
| 09:05:46 | | Quit Saijin_Naib (Disconnected by services) |
| 09:05:50 | | Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-41f6-15f2-11ae-6f93.res6.spectrum.com) |
| 09:06:31 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 09:09:40 | speachy | we probably have other places where CPU_xxx is used instead of proper CONFIG_PLATFORM checks |
| 09:10:10 | speachy | I have to imagine that the simulator will badly break when run on an arm linux target. :) |
| 09:14:30 | fs-bluebot | Build Server message: Build round completed after 801 seconds. |
| 09:14:43 | fs-bluebot | Build Server message: Revision 15b4d22913 result: 0 errors 72 warnings |
| 09:14:44 | fs-bluebot | Build Server message: New build round started. Revision 2628155fc9, 293 builds, 9 clients. |
| 09:15:37 | speachy | _bilgus: I'll leave fixing the warnings to you. :D |
| 09:17:05 | _bilgus | bah |
| 09:17:25 | | Quit Soap_ (Read error: Connection reset by peer) |
| 09:17:50 | | Join Soap_ [0] (~Soap@rockbox/staff/soap) |
| 09:18:19 | _bilgus | I also found a few other spots |
| 09:18:42 | _bilgus | I knew that I needed to add splash.h I even did it the first time lol |
| 09:26:38 | fs-bluebot | Build Server message: Build round completed after 713 seconds. |
| 09:26:42 | fs-bluebot | Build Server message: Revision 2628155fc9 result: 0 errors 72 warnings |
| 09:26:44 | _bilgus | Ok I used the inbuilt rolo_error as I should have te first time |
| 09:27:40 | fs-bluebot | Build Server message: New build round started. Revision a4a5f5f33f, 293 builds, 9 clients. |
| 09:28:50 | _bilgus | the other two I found one is pretty important the tagcache one but it is done early enough that it'd probably never fail |
| 09:29:19 | _bilgus | the radioart one though that is a failure waiting to happen |
| 09:29:25 | _bilgus | or was.. |
| 09:31:13 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 09:33:31 | speachy | yeah |
| 09:34:40 | | Join Galois [0] (djao@efnet-math.org) |
| 09:39:03 | fs-bluebot | Build Server message: Build round completed after 684 seconds. |
| 09:39:06 | fs-bluebot | Build Server message: Revision a4a5f5f33f result: All green |
| 09:39:15 | | Quit pamaury (Ping timeout: 240 seconds) |
| 09:39:27 | speachy | I wonder if the rolo hang/delay is due to audio_stop() getting lost in the weeds? |
| 09:40:04 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:51:34 | speachy | I think I found it! g#3166 |
| 09:51:36 | fs-bluebot | Gerrit review #3166 at https://gerrit.rockbox.org/r/c/rockbox/+/3166 : rolo: use audio_hard_stop() instead of audio_stop() by Solomon Peachy |
| 10:00 |
| 10:02:00 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-41f6-15f2-11ae-6f93.res6.spectrum.com) |
| 10:03:00 | fs-bluebot | Build Server message: New build round started. Revision bcee955169, 293 builds, 9 clients. |
| 10:04:14 | *** | Saving seen data "./dancer.seen" |
| 10:05:26 | | Quit Saijin-Naib (Ping timeout: 264 seconds) |
| 10:11:22 | _bilgus | nice makes sense |
| 10:12:44 | speachy | so I guess this is a longstanding problem |
| 10:15:18 | _bilgus | so hard stop clears the queue |
| 10:15:58 | _bilgus | so its still possible that its hanging in audio_stop_playback |
| 10:16:01 | speachy | and stops the voice stuff, which was another big variable |
| 10:17:19 | fs-bluebot | Build Server message: Build round completed after 859 seconds. |
| 10:17:21 | fs-bluebot | Build Server message: Revision bcee955169 result: All green |
| 10:17:55 | _bilgus | I see a pcm buffer fade in there |
| 10:18:30 | speachy | hasn't failed on me yet |
| 10:19:01 | _bilgus | actually that function is filled with a bunch of possibly blocking things with no error codes :p |
| 10:24:42 | _bilgus | i'd think it rare but I bet in the wrong circumstance that fade in he background could potentially keep you waiting a long time |
| 10:25:22 | _bilgus | pcmbuf.c if curious |
| 10:28:17 | speachy | fading normally happens quickly though? |
| 10:30:29 | _bilgus | well its working in a tick task |
| 10:31:57 | _bilgus | same as some video fade out hangs a few years ago |
| 10:42:54 | | Quit massiveH (Quit: Leaving) |
| 10:52:18 | speachy | if our tick is shoddy that's another matter |
| 10:54:45 | _bilgus | no just the priority and nature of the coop model I think |
| 11:00 |
| 11:02:48 | speachy | well, the tick fires regardless (unless something has disabled preemption for whatever reason, which would be a pretty major bug) |
| 11:04:26 | speachy | s/preemption/interrupts/ |
| 11:11:24 | | Join amachronic [0] (5284b945@82.132.185.69) |
| 11:13:08 | amachronic | hi, it's me again... I added a panic to my fiio SD driver and it looks like there ARE unaligned RX buffers coming from the filesystem code. |
| 11:14:29 | amachronic | given the convoluted nature of the problem it seems the fix for MIPS is to always do commit_discard_dcache_range() before starting DMA. |
| 11:16:00 | speachy | ok. add it to your x1000 code, I'll add it to the existing jz47xx code. |
| 11:16:13 | amachronic | it's not a perfect fix but it seems to cover the existing code. |
| 11:16:40 | speachy | think we'll need a discard_range() after the DMA has completed just to be safe? |
| 11:17:30 | amachronic | It shouldn't be harmful, that's for sure |
| 11:18:28 | speachy | that sort of brings the discard code back to what it was before we started, do a commit only if it's unaligned |
| 11:19:17 | speachy | probably faster to do an unconditional flush than it is to do an alignment check and discard. |
| 11:19:56 | amachronic | the alignment check should be dirt cheap compared to the cost of writing dirty cachelines to memory, though. |
| 11:20:05 | speachy | so these unaligned things are going into the NAND driver? |
| 11:20:19 | amachronic | no, definitely not after all the headache. |
| 11:20:44 | amachronic | the real problem with these unaligned RX buffers lies in readwrite() in firmware/common/file.c |
| 11:20:47 | speachy | (I don't ever recall seeing a non-512B block written into the SD driver, and I'm pretty sure it was always aligned properly) |
| 11:21:23 | amachronic | the problem is that read() passes its buffer down to readwrite() which does a partial read of the 1st file sector. |
| 11:21:25 | speachy | (written or read) |
| 11:21:51 | amachronic | the buffer is then advanced by some random amount of bytes, so even if the initial buffer was aligned, it usually won't be after that. |
| 11:22:25 | amachronic | those unaligned buffers go to fat_readwrite() which calls the storage code |
| 11:22:31 | speachy | I guess nand is more random access though. SD and the like requires block-level access |
| 11:24:15 | amachronic | this isn't a problem with the size of the buffer being read, it's a problem with the alignment of the buffer pointer that gets passed. |
| 11:25:13 | | Quit Saijin_Naib (Disconnected by services) |
| 11:25:18 | | Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-41f6-15f2-11ae-6f93.res6.spectrum.com) |
| 11:25:22 | amachronic | the BMP reading code which loads the backdrop demonstrates the problem splendidly |
| 11:25:23 | speachy | and that read is < than the FS's nominal sector size |
| 11:26:33 | amachronic | the BMP code uses read() calls which aren't aligned, don't have aligned sizes, and sizes are >= 512 B |
| 11:27:02 | speachy | amachronic: I guess this is why I see bounce buffers of sorts in some of the other nand drivers.. |
| 11:27:05 | amachronic | after each read the BMP loader does some processing on the read data. |
| 11:27:51 | amachronic | because the buffer is then modified in cache, the next read() call would case the storage driver to discard the cache containing a few pixels |
| 11:28:22 | speachy | ok, makes sense. |
| 11:28:23 | amachronic | that's why changing it to a commit_discard fixes the problem. |
| 11:28:57 | speachy | (in other words, we're processing in-place across a partial cacheline) |
| 11:29:09 | amachronic | Exactly. |
| 11:29:39 | speachy | well, I'm sort of gratified to see my original cache code was actually correct in how it handled that, off-by-one at unaligned ends notwithstanding.. |
| 11:31:52 | amachronic | more correct than my fixes, but theoretically we could still have data modified while DMA is ongoing, so it's not a full fix. I think corruption is very unlikely to occur in practice though, if we just restore the original commit-if-unaligned behavior. |
| 11:33:28 | amachronic | really the file.c code has to use properly aligned bounce buffers for everything in order to definitely avoid all problems. |
| 11:33:46 | amachronic | but that's obviously not an option for targets with tiny amounts of RAM. |
| 11:34:03 | speachy | not to mention the performance impact |
| 11:34:36 | amachronic | the perf impact shouldn't be meaningful because this is what all OS's do. |
| 11:34:47 | amachronic | (Unless you use specialized APIs) |
| 11:35:47 | amachronic | but I'm not inclined to implement such buffering anyway because I think the number of true bugs it would fix is very low or zero. |
| 11:36:22 | speachy | g#3167 is a blanket flush-entire-region-if-unaligned |
| 11:36:24 | fs-bluebot | Gerrit review #3167 at https://gerrit.rockbox.org/r/c/rockbox/+/3167 : mips: Revert to commiting the cache when we're told to discard an unaligned block. by Solomon Peachy |
| 11:36:50 | speachy | guess it'll be faster to flush the first/last lines instead |
| 11:38:44 | amachronic | which would bring us back to g#3158 but changing the '<=' to '<' |
| 11:38:46 | fs-bluebot | Gerrit review #3158 at https://gerrit.rockbox.org/r/c/rockbox/+/3158 : Really fix the MIPS cache bug this time by Aidan MacDonald |
| 11:39:51 | speachy | yeah |
| 11:40:55 | speachy | oh, one situation not quite covered in 3158 −− if the total region is entirely contained within a cacheline then you could end up double-flushing the single cacheline. though it's probably effectively a no-op. |
| 11:41:09 | amachronic | yes, forgot about that |
| 11:41:32 | amachronic | I just couldn't see a concise way to avoid it and it's a degenerate case so who cares? |
| 11:42:09 | amachronic | (The second flush will indeed do nothing because the cache line is already invalid.) |
| 11:42:59 | speachy | if (end != ptr && (end != (base + size))) { ... } |
| 11:43:49 | speachy | then you can also use ptr != end instead of ptr < end for the loop. |
| 11:44:32 | amachronic | I think end != ptr is true whenever size > 0 |
| 11:44:33 | speachy | since ptr and end are always aligned and you won't pull end back before ptr from the double-flush |
| 11:44:51 | | Nick Lain_ is now known as toruvinn (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 11:45:06 | amachronic | checking for the single cacheline is more like (end - ptr) < CACHELINE_SIZE |
| 11:45:46 | speachy | ptr and end are already algined. |
| 11:46:02 | amachronic | make that <= |
| 11:46:25 | amachronic | anyway I think we're really splitting hairs here about potential performance impact of a couple cheap integer instructions. |
| 11:46:59 | amachronic | the IO time should be far longer than the time to discard the cache. |
| 11:47:47 | amachronic | so why not just keep it as simple and safe as possible? |
| 11:48:33 | speachy | I want the only difference in discard_range vs commit_discard_range to be the special case writebacks |
| 11:49:12 | speachy | see the current state of g#3167 |
| 11:49:14 | fs-bluebot | Gerrit review #3167 at https://gerrit.rockbox.org/r/c/rockbox/+/3167 : mips: Revert to commiting the cache when we're told to discard an unaligned block. by Solomon Peachy |
| 11:49:49 | speachy | if it's a single cacheline, after the flush, ptr gets pushed forward to equal end. |
| 11:49:56 | amachronic | sorry you're right |
| 11:49:57 | amachronic | just realized |
| 11:50:20 | speachy | that will short-circuit both the tail check and the loop |
| 11:50:46 | speachy | so hopefully we won't be having this conversation again tomorrow. or two months from now. |
| 11:51:41 | amachronic | yeah go ahead and commit it. Can't see any further problems |
| 11:52:16 | _bilgus | the announce plugin is kinda cool https://forums.rockbox.org/index.php/topic,53770.0.html |
| 11:58:59 | speachy | just updating comments |
| 11:59:17 | speachy | for the poor souls that have to debug this in the future |
| 12:00 |
| 12:01:29 | fs-bluebot | Build Server message: New build round started. Revision cbace906c6, 293 builds, 9 clients. |
| 12:03:10 | amachronic | anyhow thanks for your patience with my bumbling, speachy, it's much appreciated. |
| 12:03:19 | speachy | _bilgus: that's the evolution of g#2534 and FS #11541, correct? |
| 12:03:23 | fs-bluebot | https://www.rockbox.org/tracker/task/11541 Add Voice Announcement of Summary Info to WPS hotkey (patches, unconfirmed) |
| 12:03:24 | fs-bluebot | Gerrit review #2534 at https://gerrit.rockbox.org/r/c/rockbox/+/2534 : FS #11541 - Add Voice Announcement of Summary Info to WPS hotkey options by Igor B. Poretsky |
| 12:03:55 | speachy | amachronic: yes indeed, I'm glad there are more eyeballs on this stuff. |
| 12:04:16 | *** | Saving seen data "./dancer.seen" |
| 12:09:10 | _bilgus | yeah |
| 12:13:50 | speachy | _bilgus: just closed out 11541 and abandoned my attempt to rework the rework of the rework. |
| 12:14:34 | fs-bluebot | Build Server message: Build round completed after 785 seconds. |
| 12:14:38 | fs-bluebot | Build Server message: Revision cbace906c6 result: All green |
| 12:14:48 | _bilgus | it still needs some polish |
| 12:15:02 | _bilgus | and testing |
| 12:16:26 | | Quit amachronic (Quit: Connection closed) |
| 12:17:16 | speachy | _bilgus: fs#13262 is an odd one. |
| 12:17:17 | fs-bluebot | https://www.rockbox.org/tracker/task/13262 Battery indicator not working Ipod Mini 2G (bugs, unconfirmed) |
| 12:17:57 | speachy | it's not a read-the-battery problem; sometihng's getting lost on the way to the status bar |
| 12:20:34 | | Join PimpiN8 [0] (~PimpiN8@2001:1c04:3308:a500:401e:1df0:99c2:75ea) |
| 12:23:51 | _bilgus | off by 10? |
| 12:32:25 | | Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in) |
| 12:36:07 | | Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 12:43:44 | speachy | they're using a custom theme |
| 12:45:26 | _bilgus | weird I wonder if at somepoint the precision was increased and they are missing a /10 |
| 12:45:41 | _bilgus | 48 vs 4.8 |
| 12:48:32 | braewoods | speachy: do you know of any RB targets which charge from external DC other than 5V? |
| 12:48:45 | _bilgus | well when running announce_status on startup it wipes out the resume track function due to my latest patch lol |
| 12:48:52 | braewoods | every one i've seen uses 5V, either barrel jack or USB |
| 12:48:58 | braewoods | or some proprietary doo hickey |
| 12:49:29 | speachy | the old archos stuff used 6V IIRC |
| 12:49:31 | braewoods | if every target uses 5V then i will assume that in writing HID Power |
| 12:49:42 | braewoods | ah but archos is gone |
| 12:50:10 | braewoods | i was just thinking, i think the power system worth reporting through HID POwer is |
| 12:50:15 | speachy | but I'm not aware of anything else that charges externally but not 5V. |
| 12:50:30 | braewoods | single DC input of 5V |
| 12:50:37 | braewoods | whether USB or whatever is irrelevant |
| 12:50:42 | braewoods | just an implementation detail |
| 12:50:52 | braewoods | and this feeds into the battery charger |
| 12:51:08 | braewoods | how detailed i can get depends on the charger system |
| 12:51:21 | braewoods | HID Power allows you to report errors |
| 12:51:22 | braewoods | and such |
| 12:51:27 | braewoods | like temperature issues |
| 12:51:35 | braewoods | but |
| 12:51:41 | braewoods | not sure RB even has access to that |
| 12:51:46 | braewoods | so it may be left unused |
| 12:51:58 | braewoods | it would be very chip specific |
| 12:52:00 | braewoods | so |
| 12:52:11 | braewoods | i may have a very basic initial one |
| 12:52:23 | braewoods | i'll fully review HID power when i can |
| 12:52:37 | braewoods | just trying to decide the most optimal reporting system |
| 12:52:46 | braewoods | HID Power is standardized |
| 12:52:47 | speachy | keep it simple, battery status (charging/discharging), level, and estimtated time remaining. |
| 12:52:48 | braewoods | but |
| 12:53:11 | speachy | some targets dont' report voltage, only a percentage level. |
| 12:53:12 | braewoods | speachy: yea, i noticed most of our targets don't even use thermistors in their batteries |
| 12:53:39 | braewoods | so, in that case, impossible to report temperature events. |
| 12:53:44 | braewoods | and if it's that bad anyway |
| 12:53:48 | braewoods | the hardware will kick in |
| 12:53:57 | speachy | or it'll catch fire :) |
| 13:00 |
| 13:02:08 | braewoods | speachy: ah yes, the dreaded HCF |
| 13:02:25 | braewoods | anyway i just took a dump of lsusb on my pc with the wifi keyboard |
| 13:02:33 | braewoods | i'll see if i can learn how it reports its battery stats |
| 13:03:00 | braewoods | reimplementing a proprietary protocol works too if it's sufficiently popular among common hosts |
| 13:04:02 | speachy | logitech's HID+ stuff is a start |
| 13:05:10 | braewoods | it's a logitech keyboard |
| 13:05:22 | braewoods | i wanted to see if it's using HID Power or something else |
| 13:05:42 | braewoods | HID Power is mainly for UPS but |
| 13:05:51 | braewoods | so maybe not the best choice |
| 13:06:05 | braewoods | it seems it would cover our use case but i care about the bigger picture |
| 13:06:13 | braewoods | how the hosts would generally use HID power |
| 13:06:29 | _bilgus | Well there is still some general weirdness going on witht he ram in the clipzip I'm getting panics with data abort somewhere close to the voice sysytem |
| 13:06:54 | braewoods | if it would be considered as a UPS or not |
| 13:06:57 | braewoods | for the host |
| 13:07:05 | _bilgus | I'll have to look into it a bit further but something is going on |
| 13:07:06 | braewoods | instead of being an auxiliary device battery |
| 13:08:14 | speachy | look into what upower implements |
| 13:08:27 | speachy | it knows how to query battery status for some devices |
| 13:09:08 | | Nick prg3_ is now known as prg3 (~prg@deadcodersociety/prg318) |
| 13:13:08 | braewoods | speachy: indeed. i just wouldn't know what would work with Mac hosts. |
| 13:13:16 | braewoods | i have no Mac hardware. |
| 13:13:47 | speachy | I mean, work backwards from upower to find out what USB interface it's getting that info from |
| 13:14:13 | speachy | (maybe it's getting it from some Linux sysfs file, in which case find whare _that_ comes from...) |
| 13:15:30 | braewoods | huh |
| 13:15:34 | braewoods | seems it is using HID Power |
| 13:15:46 | braewoods | i found hID Power interface in the lsusb output |
| 13:16:17 | braewoods | https://dpaste.com/7EE92H7DM |
| 13:16:28 | braewoods | last one |
| 13:16:34 | braewoods | HID Power, 3 0 0 |
| 13:16:43 | braewoods | 3 1 1, 3 1 2 for the regular HID devices |
| 13:17:17 | braewoods | so if it uses anything proprietary it would be extensions to HID Power |
| 13:17:18 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 13:28:25 | | Quit PimpiN8 (Quit: Textual IRC Client: www.textualapp.com) |
| 14:00 |
| 14:04:19 | *** | Saving seen data "./dancer.seen" |
| 14:06:52 | | Quit petur (Quit: Connection reset by beer) |
| 14:57:47 | speachy | _bilgus: fs#13269 just came into being; data abort on the imageviewer plugin on the clipzip |
| 14:57:48 | fs-bluebot | https://www.rockbox.org/tracker/task/13269 Image Viewer is broken in recent builds (bugs, unconfirmed) |
| 15:00 |
| 15:40:48 | fs-bluebot | Build Server message: New build round started. Revision fb99d890a8, 293 builds, 9 clients. |
| 15:51:20 | fs-bluebot | Build Server message: Build round completed after 632 seconds. |
| 15:51:23 | fs-bluebot | Build Server message: Revision fb99d890a8 result: All green |
| 16:00 |
| 16:04:06 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 16:04:21 | *** | Saving seen data "./dancer.seen" |
| 16:05:53 | | Quit J_Darnley (Ping timeout: 260 seconds) |
| 16:08:49 | | Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) |
| 16:21:49 | | Quit chris_s (Quit: Ping timeout (120 seconds)) |
| 16:39:20 | skrzyp | Asking for a friend - is there any sort of DAP which can also act as an DAC/soundcard, but it's not being powered by Android? Doesn't really need to be compatible with Rockbox (but it's very appreciated), just not Android. |
| 16:40:39 | speachy | IIRC the FiiO M3K does. |
| 16:42:38 | speachy | as do the various hiby-based models (eros q/k, hifiwalker h2, etc) |
| 16:44:07 | speachy | chris_s: If you're willing to do some potential data corruption testing, I'd like to experiment with allowing the iflash adapters to be powered off |
| 16:49:08 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 16:50:26 | | Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) |
| 16:51:14 | fs-bluebot | Build Server message: New build round started. Revision be99033cbb, 293 builds, 8 clients. |
| 16:57:13 | | Join chris_s10 [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) |
| 16:58:49 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 17:00 |
| 17:00:31 | chris_s10 | speachy: Gladly. Re FS #13262, the battery indicator doesn't update on iFlash-based devices before g#3120 due to this line: https://github.com/Rockbox/rockbox/blob/ca4d63d4d903e3de356afb8d129ae61c660ff9b4/firmware/powermgmt.c#L654 . Just verified the behavior on my iPod4G. Could have been that user's problem. |
| 17:00:35 | fs-bluebot | https://www.rockbox.org/tracker/task/13262 Battery indicator not working Ipod Mini 2G (bugs, unconfirmed) |
| 17:00:35 | fs-bluebot | Gerrit review #3120 at https://gerrit.rockbox.org/r/c/rockbox/+/3120 : Always indicate inactive ata disk if device is solid state or doesn't support power management by Christian Soffke |
| 17:00:52 | speachy | yeah, I just noticed that one too. |
| 17:02:11 | fs-bluebot | Build Server message: Build round completed after 657 seconds. |
| 17:02:14 | fs-bluebot | Build Server message: Revision be99033cbb result: All green |
| 17:02:17 | speachy | my change to 3120 might have been a mistake. solid state drives tha support ATA powermgmt should be properly spun down. |
| 17:02:46 | speachy | as an explicit sign that we want it to be ready for shutdown |
| 17:04:22 | speachy | ata is special-cased |
| 17:06:24 | | Quit chris_s (Quit: Ping timeout (120 seconds)) |
| 17:14:19 | speachy | chris_s10: On shutdown, I'm concenred we may power off before the iflash/etc adapter has finished writing everthing. We only wait 1/4 of a second or so between telling the system to flush everything and killing power. |
| 17:15:27 | speachy | whereas we would normally wait until after the disk has spun down, making it obviously safe to kill power. |
| 17:15:48 | chris_s10 | This is purely anecdotal, but I haven't experienced any issues with that so far |
| 17:16:14 | speachy | there are some seriously slow SD cards out there... |
| 17:16:32 | chris_s10 | right |
| 17:17:15 | speachy | I just don't know how much buffering that janky CF->SD chipset actually does |
| 17:25:47 | speachy | gah. this whole storage_is_active and storage_spindown thing is a no-op except for ata. |
| 17:30:14 | | Quit lebellium (Quit: Leaving) |
| 17:37:24 | _bilgus | speachy the data aborts are probably related |
| 17:38:03 | _bilgus | I'm still tracking this one down but it appears to be a case of a use after free ATM |
| 17:39:21 | fs-bluebot | Build Server message: New build round started. Revision 56a1e87501, 293 builds, 8 clients. |
| 17:39:36 | speachy | pure happenstance it shows up now? |
| 17:46:59 | _bilgus | not sure yet lol |
| 17:47:44 | _bilgus | his build was from FEB so its likely something other than my changes today |
| 17:49:27 | fs-bluebot | Build Server message: Build round completed after 606 seconds. |
| 17:49:30 | fs-bluebot | Build Server message: Revision 56a1e87501 result: All green |
| 17:50:26 | speachy | chris_s10: g#3169 |
| 17:50:31 | fs-bluebot | Gerrit review #3169 at https://gerrit.rockbox.org/r/c/rockbox/+/3169 : WIP ata: only gate ata sleep command, not all powermgnt by Solomon Peachy |
| 17:52:05 | speachy | chris_s10: DAta corruption is quite possible. |
| 17:53:13 | speachy | we want to allow the ata interface to get powered off (ie system goes idle) after heavy writes. |
| 17:53:43 | speachy | if it does work though, we'll get some battery life back. |
| 17:54:00 | _bilgus | this is weird there is a freed handle and there should be a panic in the buflib if handle == 0 and yet it still dereferences the damn thing with predictable result |
| 17:54:08 | chris_s10 | speachy: nice, I'll give it a go :) |
| 17:56:18 | speachy | I though -1 is the infalid handle flag? |
| 17:56:55 | | Quit chris_s10 (Quit: Connection closed) |
| 18:00 |
| 18:04:24 | *** | Saving seen data "./dancer.seen" |
| 18:17:00 | _bilgus | Core_free returns 0 |
| 18:17:24 | _bilgus | thats in corealloc so only core does it |
| 19:00 |
| 19:13:48 | | Quit XDjackieXD (Ping timeout: 245 seconds) |
| 19:14:50 | | Join XDjackieXD [0] (~jackie@irc.chaosfield.at) |
| 19:14:54 | | Join ArsenArsen_ [0] (~Arsen@fsf/member/ArsenArsen) |
| 19:15:04 | | Quit ArsenArsen (Ping timeout: 245 seconds) |
| 19:15:06 | | Join fauweh_ [0] (~root@ithaqua.unzane.com) |
| 19:15:27 | | Quit pamaury (Ping timeout: 260 seconds) |
| 19:15:30 | | Quit kadoban (Ping timeout: 265 seconds) |
| 19:15:35 | | Quit tomato (Quit: Ping timeout (120 seconds)) |
| 19:15:54 | | Quit ccf-100 (Ping timeout: 246 seconds) |
| 19:15:54 | | Quit danielp3344 (Ping timeout: 246 seconds) |
| 19:16:00 | | Quit fauweh (Ping timeout: 265 seconds) |
| 19:17:09 | | Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) |
| 19:18:44 | | Join ccf-100 [0] (ccf-100mat@gateway/shell/matrix.org/x-dpxplwlwexuwthbf) |
| 19:21:05 | | Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-orwvobvmsxoskufi) |
| 19:25:51 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-cizkvrqxegufcflf) |
| 19:26:57 | | Quit aevin (Ping timeout: 264 seconds) |
| 19:27:05 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 19:42:48 | _bilgus | it looks to me like the voice file is probably getting too big |
| 19:58:30 | speachy | that's just going to get worse over time |
| 19:58:42 | speachy | some languages have much larger voice files than engrish too |
| 20:00 |
| 20:02:06 | braewoods | speachy: any ideas what i should name the new hid power thing? |
| 20:02:11 | braewoods | i could name it hid_power |
| 20:02:16 | braewoods | but that seems really long |
| 20:02:31 | braewoods | though just power seems kinda misleading |
| 20:02:46 | speachy | long names don't affect the compiler |
| 20:02:48 | braewoods | perhaps a usb battery driver? |
| 20:02:49 | braewoods | i know |
| 20:02:54 | braewoods | it's purely a cosmetic thing |
| 20:03:22 | braewoods | so what should I do? it's technically a HID but not really |
| 20:03:34 | braewoods | it's more of a device to device reporting scheme |
| 20:03:41 | braewoods | very little human input |
| 20:04:05 | braewoods | hm |
| 20:04:27 | *** | Saving seen data "./dancer.seen" |
| 20:04:28 | braewoods | i'm tempted to name battery since it's intended to report battery levels |
| 20:04:36 | braewoods | but |
| 20:04:46 | braewoods | usb_hid_power |
| 20:04:48 | braewoods | eh |
| 20:04:56 | braewoods | i guess less confusion about what it does |
| 20:05:00 | braewoods | i'll just use this |
| 20:05:19 | braewoods | the user probably won't know what the source uses anyway |
| 20:05:26 | braewoods | we can paper over it in the UI if we need to |
| 20:12:08 | speachy | hid_power is technically accurate, so that's fine in the source |
| 20:16:53 | braewoods | just funny naming and all |
| 20:16:59 | braewoods | it has little to do with HID |
| 20:17:24 | braewoods | apparently the main thing it shares is the HID interface codes |
| 20:17:31 | braewoods | from what i can gather so far |
| 20:17:41 | braewoods | still |
| 20:17:46 | speachy | yep, piggybacks on the HID structure/design |
| 20:18:01 | speachy | which is fine as it's one-way data that only slightly changes |
| 20:18:05 | braewoods | i'm tempted to name it just POWER |
| 20:18:11 | braewoods | so |
| 20:18:16 | braewoods | should i extend usb_hid instead? |
| 20:18:23 | braewoods | since it's technically a subset of that |
| 20:18:28 | | Quit mendel_munkis (Read error: Connection reset by peer) |
| 20:18:44 | braewoods | i'll poke around in the current hid source |
| 20:18:50 | _bilgus | we might want to think about loading plugin voices per plugin then |
| 20:19:11 | braewoods | i want to figure out how i will integrate the driver before i got writing the guts of it |
| 20:19:13 | _bilgus | or switch to a compressed format in mem and decode on the fly |
| 20:20:13 | _bilgus | I thought we did that already but it looks to be wav? |
| 20:25:03 | braewoods | speachy: how does rockbox uses hid mouse? |
| 20:25:14 | braewoods | it's setup for keyboard descriptors, doesn't even use one for mice. |
| 20:25:26 | braewoods | rather confusing right there |
| 20:27:47 | | Quit ac_laptop (Ping timeout: 260 seconds) |
| 20:28:03 | braewoods | hm |
| 20:28:16 | braewoods | i'll see if i can integrate HID Power into the existing HID driver first |
| 20:28:31 | braewoods | i may also make a standalone version so we can enable it exclusively for charging only mode |
| 20:29:16 | braewoods | my thinking is if i can reuse the existing HID driver i won't need to acquire extra endpoints to handle it |
| 20:29:31 | braewoods | so we can more efficiently use the available endpoints |
| 20:37:07 | braewoods | woohoo. got my new sansa fuze+ |
| 20:37:18 | braewoods | plan to use my high endurance MLC micro sd card with it |
| 20:38:11 | braewoods | once i get RB installed it's off to the development work |
| 20:46:51 | | Quit fauweh_ (Ping timeout: 265 seconds) |
| 20:47:56 | | Quit ccf-100 (Ping timeout: 240 seconds) |
| 20:48:14 | | Quit mud (Ping timeout: 258 seconds) |
| 20:49:15 | | Quit danielp3344 (Ping timeout: 240 seconds) |
| 20:49:22 | | Quit kadoban (Ping timeout: 258 seconds) |
| 20:51:16 | | Join fauweh [0] (~root@ithaqua.unzane.com) |
| 20:58:27 | | Quit fauweh (Ping timeout: 265 seconds) |
| 21:00 |
| 21:01:32 | | Join fauweh [0] (~root@ithaqua.unzane.com) |
| 21:12:47 | | Join mendelmunkis [0] (~mendelmun@ool-43568247.dyn.optonline.net) |
| 21:21:06 | _bilgus | speach y got the talk problem fixed it turns out allowing it to dump the voice file uncovered a bug where if the voice file failed to load then it would just let it continue with a bad handle |
| 21:22:22 | fs-bluebot | Build Server message: New build round started. Revision b2732222e9, 293 builds, 9 clients. |
| 21:22:57 | _bilgus | as for imageviewer its not reproducible for me so far |
| 21:23:29 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-jqhspsdmcotzpgle) |
| 21:26:11 | | Join captainkewl [0] (60f13416@pool-96-241-52-22.washdc.fios.verizon.net) |
| 21:28:47 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 21:33:23 | fs-bluebot | Build Server message: Build round completed after 661 seconds. |
| 21:33:25 | fs-bluebot | Build Server message: Revision b2732222e9 result: All green |
| 21:33:26 | | Join ccf-100 [0] (ccf-100mat@gateway/shell/matrix.org/x-nuydoyusulzbivvh) |
| 21:35:44 | | Join mud [0] (kadobanmat@gateway/shell/matrix.org/x-vshgkgtjqjjszdqu) |
| 21:37:40 | speachy | _bilgus: will it recover and try again to load the voice later? |
| 21:38:48 | | Join amachronic [0] (5284bb61@82.132.187.97) |
| 21:41:21 | braewoods | speachy: i'm suspecting it's not realistic to use the same driver for both |
| 21:41:33 | braewoods | they're probably separate for a reason |
| 21:41:42 | braewoods | though they share common bits |
| 21:41:59 | braewoods | speachy: i think the hid driver needs to be restructured so I can reuse the common bits. |
| 21:42:03 | braewoods | though how |
| 21:42:15 | braewoods | i'll figure out after I understand how to make hid power work |
| 21:42:19 | braewoods | for now i'll make it independent |
| 21:43:04 | braewoods | i think the existing hid drive needs to be renamed a bit |
| 21:43:13 | braewoods | HID_KEYBOARD or something |
| 21:43:22 | braewoods | or even hid_input |
| 21:44:59 | | Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-iaialaudtoihlpte) |
| 21:46:53 | amachronic | speachy: I believe I've found a solution to the unaligned buffer problems on MIPS after some random browsing of the codebase. It turns out the problem was already solved in Rockbox ARM ports and it's really simple. If you look into sdmmc-imx233.c and the function transfer_sectors(), unaligned transfers get split into two SD/MMC transfer commands |
| 21:46:53 | amachronic | and use memmove() to shuffle data around in the caller-provided buffer. Only one static 512-byte buffer is needed as a temporary storage and not the big buffers I had wrongly assumed we'd need further up in the filesystem code. If we do the same thing in the MIPS ports it should get rid of any future gremlins with that overlapping cacheline stuff. |
| 21:47:04 | | Join f1reflyylmao [0] (~f1refly@2a01:c22:8848:3500:70c5:504c:479b:fa8d) |
| 21:47:42 | _bilgus | speachy yes |
| 21:47:55 | | Quit f1refly (Ping timeout: 240 seconds) |
| 21:47:55 | | Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:8848:3500:70c5:504c:479b:fa8d) |
| 21:50:04 | _bilgus | but its broken atm I kinda left it disabled on accident |
| 21:53:33 | speachy | now is the reason for the bounce buffer in the sdmmc-imx233 because if cacheline alignment, or dma engine requirements? |
| 21:54:53 | amachronic | from the comments it seems as if it's because of DMA requirements, but that's a moot point. The same technique can eliminate non-cache-aligned accesses in the MIPS code. |
| 21:55:39 | amachronic | I know the x1000 does not need as many cases as imx233 because it's SD DMA engine can do unaligned accesses, so it'd only be to solve the unaligned RX buffer problem. |
| 21:56:51 | * | speachy rubs his forehead. |
| 21:56:58 | speachy | this seems ... unnecessarily complicated |
| 21:57:42 | speachy | and someting that presumably is equally an issue for most of the other dma-capable targets. |
| 21:58:58 | fs-bluebot | Build Server message: New build round started. Revision 10b6707131, 293 builds, 9 clients. |
| 21:59:21 | amachronic | (I'm just grepping the code here) −− tms320dm320/sdmmc-dm320.c is also using a similar workaround |
| 21:59:23 | | Quit captainkewl (Quit: Connection closed) |
| 21:59:42 | speachy | nand driver on the nano2g too |
| 22:00 |
| 22:00:15 | amachronic | so is as3525/sd-as3525v2.c |
| 22:00:41 | amachronic | and as3525/sd-as3525.c |
| 22:00:57 | amachronic | and also s3c2440/sd-s3c2440.c. |
| 22:01:21 | speachy | I mean, how is every storage driver not afflicted? 512 byte sectors for ATA drives; you can't just read 3 bytes 18 bytes into a sector. |
| 22:02:01 | amachronic | They are not affected because they are actually checking for these unaligned cases, fixing up the alignment by shuffling data around, and doing everything properly. |
| 22:02:28 | speachy | kinda seems to me that the right thing to do is fix this in the upper layer |
| 22:02:40 | speachy | instead of every driver having to reimplement the same thing |
| 22:03:19 | amachronic | I would agree that the upper layer is the logical place to put the fix, but in the context of old Rockbox ports maybe it made sense to push this down to the target level. |
| 22:03:35 | amachronic | and that's why we have this situation today. |
| 22:04:29 | *** | Saving seen data "./dancer.seen" |
| 22:04:39 | amachronic | but I suppose all the modern CPUs have basically the same caching and DMA setups so there's no longer a purpose in deferring responsibility to the target code. |
| 22:05:45 | speachy | amsv2 uses a 5KB realignment buffer |
| 22:08:25 | amachronic | it seems that whoever wrote that simply decided 5 KB is a good compromise between memory use and reducing the number of transfers. |
| 22:08:56 | amachronic | there's no magic in the number otherwise |
| 22:09:01 | amachronic | (as far as I can tell) |
| 22:09:31 | speachy | I'm wondering if we're likely to multi-block transfers that are unaligned. |
| 22:10:18 | amachronic | It happens with the bitmap loading code on the FiiO, but that would vary with targets depending on their screen resolution, I think |
| 22:10:20 | fs-bluebot | Build Server message: Build round completed after 682 seconds. |
| 22:10:22 | fs-bluebot | Build Server message: Revision 10b6707131 result: 0 errors 57 warnings |
| 22:10:41 | speachy | _bilgus: I think you're on another roll tonight... |
| 22:12:38 | speachy | STORAGE_WANTS_ALIGN has code specificaly to ignore alignment for bitmap buffers, heh. |
| 22:18:51 | amachronic | given that a lot of the ports seemingly haven't be touched for almost a decade, it doesn't look wise to try fixing this on the upper layer in case it breaks things. I suspect any fix at that level will be equivalent to the imx233's approach, which seems to me optimal. |
| 22:20:10 | amachronic | i would've tried to do it myself but I couldn't figure out all the sector caching code (and didn't want to) |
| 22:24:12 | speachy | I'm trying to understand the call graph, becuse everything at the filesystem and below seems to operate at the block level |
| 22:24:39 | amachronic | From my understanding, that's correct. |
| 22:26:04 | amachronic | if you only look at the FAT code you will be misled into thinking that buffers always stay aligned, because it only operates in sectors |
| 22:26:29 | speachy | readwrite() in firmware/common/file.c seems to be the meat of it. |
| 22:27:00 | amachronic | yes that's what I mentioned earlier today |
| 22:27:15 | speachy | first time I've looked into this bit of the codebase |
| 22:27:15 | amachronic | at 11:21 |
| 22:28:32 | amachronic | It's that first readwrite_partial() near the top which can cause an aligned buffer to become unaligned. But the buffer itself is provided by random callers of read() and write() so we cannot be sure it is aligned to begin with. |
| 22:29:06 | amachronic | (more specifically it's the adjustments done after readwrite_partial() which cause the problem but you see what I mean.) |
| 22:29:13 | speachy | yeah. |
| 22:30:04 | amachronic | now if we applied the same logic as imx233 _here_, we'd have a fix. |
| 22:30:48 | amachronic | only problem is I couldn't find out where to get that 512-byte buffer. It's easier at the hardware level simply because there's a finite amount of ports so it can be done statically |
| 22:32:58 | _bilgus | I think the announce plugin might need some finesse on the ClipZip its slamming that buffer hard on the first track load |
| 22:33:33 | _bilgus | since voice shares the audio buffer.. |
| 22:35:05 | | Join f1reflyylmao [0] (~f1refly@dynamic-077-008-131-029.77.8.pool.telefonica.de) |
| 22:36:19 | | Quit f1refly (Ping timeout: 258 seconds) |
| 22:36:20 | | Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-008-131-029.77.8.pool.telefonica.de) |
| 22:36:36 | amachronic | it looks like MAX_OPEN_FILES is 11, so it might be reasonable to just statically allocate 5.5 KiB of buffers, and add a pointer to those in filestr_desc. (Given the appropriate #ifdefs) |
| 22:37:22 | amachronic | rather than trying to figure out the nightmare of how to get a buffer some other way |
| 22:40:26 | speachy | amachronic: nah, I think the place to insert the shim is in transfer() in fat.c |
| 22:40:45 | speachy | and key it all on STORAGE_WANTS_ALIGNED |
| 22:41:06 | speachy | similar logic to how the amsv2 code does it, with a 10 sector buffer. |
| 22:41:59 | speachy | and if we're unaligned, incrementally transfer (and realign) 10 sectors at a time until we're done. |
| 22:42:55 | amachronic | hmm... not sure that's the best move. It would wake up the CPU much more than doing a single bulk transfer plus 1 sector. |
| 22:43:19 | amachronic | because we have to copy the same amount of memory either way. unless memmove() is drastically less efficient than memcpy(). |
| 22:45:19 | amachronic | I definitely agree that fat.c is a better place to put it. |
| 22:49:05 | amachronic | hmm after looking at the definition of memmove(), it looks like it may suck badly. |
| 22:49:41 | _bilgus | MEMMOVE IS SEVERAL X SLOWER |
| 22:49:46 | _bilgus | oops |
| 22:50:03 | _bilgus | that whole overlapping region check |
| 22:54:57 | speachy | _bilgus: line 629 of apps/talk.c, I think you left out {} around the block |
| 22:56:08 | speachy | the net result is that voiceload always fails. |
| 22:57:51 | fs-bluebot | Build Server message: New build round started. Revision 03ae4e6019, 293 builds, 9 clients. |
| 22:58:35 | _bilgus | arg sure enough |
| 23:00 |
| 23:00:30 | speachy | amachronic: g#3173 is what I'm aiming for. |
| 23:00:32 | fs-bluebot | Gerrit review #3173 at https://gerrit.rockbox.org/r/c/rockbox/+/3173 : VERY WIP: Handle unaligned reads in the fat layer. by Solomon Peachy |
| 23:04:16 | _bilgus | i THINK I'LL BACK OFF THAT TOSSING OF THE VOICE BUFFER TOO WHILE i'M AT IT |
| 23:04:26 | | Quit ac_laptop (Ping timeout: 246 seconds) |
| 23:08:16 | fs-bluebot | Build Server message: Build round completed after 627 seconds. |
| 23:08:21 | fs-bluebot | Build Server message: Revision 03ae4e6019 result: 0 errors 57 warnings |
| 23:09:49 | amachronic | speachy: There's nothing wrong with that approach. I don't think it's easy to estimate whether two storage reads + memmove or many storage reads + memcpy would consume more CPU (+ more battery power) in the end, we'd have to profile and it'd depend on the target. but it's probably minor anyway. |
| 23:11:29 | speachy | there's a lot of overhead per-request but I somehow suspect we're not doing large-ish transfers into unaligned buffers. |
| 23:12:30 | amachronic | that's my intuition too |
| 23:13:17 | speachy | using the amsv2 as inspriation, I know that target was uber-optimized |
| 23:16:05 | amachronic | if we're not doing many big unaligned transfers anyway, then we're already doing many small requests, so adding a few more can't hurt much |
| 23:21:38 | | Quit amachronic (Quit: Connection closed) |
| 23:24:15 | | Join advcomp2019_ [0] (~advcomp20@65-131-179-208.sxct.qwest.net) |
| 23:24:16 | | Quit advcomp2019_ (Changing host) |
| 23:24:16 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 23:26:00 | speachy | _bilgus: think you'll get to it tonight? I'd prefer to not have a daily build go up with completely busted voice. |
| 23:27:13 | | Quit advcomp2019 (Ping timeout: 256 seconds) |
| 23:34:40 | _bilgus | oh its up now I just want to test it once more |
| 23:34:45 | _bilgus | lol |
| 23:34:51 | _bilgus | wonder why |
| 23:36:17 | _bilgus | I decided to back off the dumping of the voice buffer it just makes it slow to talk again when it is not memory constrained |
| 23:36:52 | speachy | wonder if there's nyone else with commit rights around so we can go for a trifecta of series-of-broken-commits-by-someone-who-should-have-known-better |
| 23:38:44 | _bilgus | ouch |
| 23:39:01 | speachy | we've both done a fine job lately, eh? |
| 23:40:01 | speachy | amachronic: my realignment-in-fat-layer compiles now, at least. I'm not feeling brave enough to actually _test_ it though. |
| 23:41:38 | speachy | and on that note, it's time to turn into a pumpkin. g'nite.. |
| 23:41:52 | fs-bluebot | Build Server message: New build round started. Revision 895ed92496, 293 builds, 9 clients. |
| 23:42:03 | _bilgus | night |
| 23:43:06 | * | __builtin thinks he might have some time to revisit that SDL2 port soon... |
| 23:52:26 | fs-bluebot | Build Server message: Build round completed after 634 seconds. |
| 23:52:29 | fs-bluebot | Build Server message: Revision 895ed92496 result: All green |
icon identifies that the person is a core developer (has commit access).