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-04

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:55speachy_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:15speachyhow old was the previous build (that presumably worked?)
07:00
07:05:30_bilgusspeachy hard telling its such a specific set of actions though shouldn't take too lng to figure it out
07:11:25_bilgusI'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:23speachyI'm considerint bumping up the codec space from 1MB to 2MB on >16MB targets
08:10:00speachyso these large mp4 audio books can be loaded
08:10:28speachyunless we can the codecs can be finagled to allocate a bit from the main buffer?
08:16:39_bilgustalk_buffer_set_policy(TALK_BUFFER_LOOSE);
08:17:18_bilguswell found something that makes the voice buffer allow shrink
08:19:27speachyI guess the adding-talk-to-plugins didnt' account for that case
08:21:06_bilguswell tbf its always been there we just are getting close to the upper limits for that 8MB
08:21:26_bilguspreviously the talk buffer wasn't filling up all available ram
08:21:46speachyeither way we shouldn't be panicing
08:22:03_bilguswellll it could be handled more gracefully
08:22:18_bilgusbut at least its readily apparent
08:25:58_bilgusYAY
08:27:44_bilgusIt could also be made to fallback to the plugin area in these situations as well
08:32:47fs-bluebotBuild Server message: New build round started. Revision 80be135d0d, 293 builds, 9 clients.
08:33:30_bilgusThat one is fixed but I'm sure there are more just waiting to be discovered
08:35:16_bilgusThis 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_bilgusI'd go open up another but I keep hoping for one of em to come back from family for spare parts
08:38:33speachyc
08:43:44fs-bluebotBuild Server message: Build round completed after 657 seconds.
08:43:48fs-bluebotBuild Server message: Revision 80be135d0d result: All green
08:44:58_bilgusspeachy https://github.com/Rockbox/rockbox/blob/master/firmware/rolo.c#L245
08:45:11_bilgusnotice anything about the return for that call?
08:45:25 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
08:47:04speachywe don't check for errors?
08:47:17_bilgusmhmm
08:47:36_bilguswe'll panic there for now
08:48:12speachy... but that doesn't match the symptoms, which is that there's a variable delay
08:48:43_bilgusI figure its overwriting memory
08:48:53speachyalso manually rolo'ing a firmware file via the browser always seems to succeed; it's only the post-usb-detach prompt
08:49:47_bilguswell if its not an issue I guess we won't get any panics
08:50:13speachyis panicing the right thing? as opposed to simply a splash error and continuing?
08:51:00speachyheh, also CPU_COLDFIRE | CPU_ARM | CPU_MIPS is all-inclusive now.
08:53:10_bilguswhat point to continue there is no memory
08:53:28speachys/continue/return/
08:54:12_bilguswe can Idk if there is any point but I guess you could fail out then restart manually
08:54:14speachyat that point all we've done is overwrite the display and stop playback
08:54:38speachy(Assuming that core_alloc_maximum() doesn't trash anything)
08:54:45speachy(when it fails)
08:57:45_bilgusit doesn't
08:59:37 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:00
09:01:08fs-bluebotBuild Server message: New build round started. Revision 15b4d22913, 293 builds, 9 clients.
09:01:16speachywhat do you think about g#3164 ?
09:01:18fs-bluebotGerrit 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_bilgusless 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:40speachywe probably have other places where CPU_xxx is used instead of proper CONFIG_PLATFORM checks
09:10:10speachyI have to imagine that the simulator will badly break when run on an arm linux target. :)
09:14:30fs-bluebotBuild Server message: Build round completed after 801 seconds.
09:14:43fs-bluebotBuild Server message: Revision 15b4d22913 result: 0 errors 72 warnings
09:14:44fs-bluebotBuild Server message: New build round started. Revision 2628155fc9, 293 builds, 9 clients.
09:15:37speachy_bilgus: I'll leave fixing the warnings to you. :D
09:17:05_bilgusbah
09:17:25 Quit Soap_ (Read error: Connection reset by peer)
09:17:50 Join Soap_ [0] (~Soap@rockbox/staff/soap)
09:18:19_bilgusI also found a few other spots
09:18:42_bilgusI knew that I needed to add splash.h I even did it the first time lol
09:26:38fs-bluebotBuild Server message: Build round completed after 713 seconds.
09:26:42fs-bluebotBuild Server message: Revision 2628155fc9 result: 0 errors 72 warnings
09:26:44_bilgusOk I used the inbuilt rolo_error as I should have te first time
09:27:40fs-bluebotBuild Server message: New build round started. Revision a4a5f5f33f, 293 builds, 9 clients.
09:28:50_bilgusthe 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_bilgusthe radioart one though that is a failure waiting to happen
09:29:25_bilgusor was..
09:31:13 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
09:33:31speachyyeah
09:34:40 Join Galois [0] (djao@efnet-math.org)
09:39:03fs-bluebotBuild Server message: Build round completed after 684 seconds.
09:39:06fs-bluebotBuild Server message: Revision a4a5f5f33f result: All green
09:39:15 Quit pamaury (Ping timeout: 240 seconds)
09:39:27speachyI 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:34speachyI think I found it! g#3166
09:51:36fs-bluebotGerrit 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:00fs-bluebotBuild 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_bilgusnice makes sense
10:12:44speachyso I guess this is a longstanding problem
10:15:18_bilgusso hard stop clears the queue
10:15:58_bilgusso its still possible that its hanging in audio_stop_playback
10:16:01speachyand stops the voice stuff, which was another big variable
10:17:19fs-bluebotBuild Server message: Build round completed after 859 seconds.
10:17:21fs-bluebotBuild Server message: Revision bcee955169 result: All green
10:17:55_bilgusI see a pcm buffer fade in there
10:18:30speachyhasn't failed on me yet
10:19:01_bilgusactually that function is filled with a bunch of possibly blocking things with no error codes :p
10:24:42_bilgusi'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_bilguspcmbuf.c if curious
10:28:17speachyfading normally happens quickly though?
10:30:29_bilguswell its working in a tick task
10:31:57_bilgussame as some video fade out hangs a few years ago
10:42:54 Quit massiveH (Quit: Leaving)
10:52:18speachyif our tick is shoddy that's another matter
10:54:45_bilgusno just the priority and nature of the coop model I think
11:00
11:02:48speachywell, the tick fires regardless (unless something has disabled preemption for whatever reason, which would be a pretty major bug)
11:04:26speachys/preemption/interrupts/
11:11:24 Join amachronic [0] (5284b945@82.132.185.69)
11:13:08amachronichi, 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:29amachronicgiven 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:00speachyok. add it to your x1000 code, I'll add it to the existing jz47xx code.
11:16:13amachronicit's not a perfect fix but it seems to cover the existing code.
11:16:40speachythink we'll need a discard_range() after the DMA has completed just to be safe?
11:17:30amachronicIt shouldn't be harmful, that's for sure
11:18:28speachythat sort of brings the discard code back to what it was before we started, do a commit only if it's unaligned
11:19:17speachyprobably faster to do an unconditional flush than it is to do an alignment check and discard.
11:19:56amachronicthe alignment check should be dirt cheap compared to the cost of writing dirty cachelines to memory, though.
11:20:05speachyso these unaligned things are going into the NAND driver?
11:20:19amachronicno, definitely not after all the headache.
11:20:44amachronicthe real problem with these unaligned RX buffers lies in readwrite() in firmware/common/file.c
11:20:47speachy(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:23amachronicthe problem is that read() passes its buffer down to readwrite() which does a partial read of the 1st file sector.
11:21:25speachy(written or read)
11:21:51amachronicthe 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:25amachronicthose unaligned buffers go to fat_readwrite() which calls the storage code
11:22:31speachyI guess nand is more random access though. SD and the like requires block-level access
11:24:15amachronicthis 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:22amachronicthe BMP reading code which loads the backdrop demonstrates the problem splendidly
11:25:23speachyand that read is < than the FS's nominal sector size
11:26:33amachronicthe BMP code uses read() calls which aren't aligned, don't have aligned sizes, and sizes are >= 512 B
11:27:02speachyamachronic: I guess this is why I see bounce buffers of sorts in some of the other nand drivers..
11:27:05amachronicafter each read the BMP loader does some processing on the read data.
11:27:51amachronicbecause 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:22speachyok, makes sense.
11:28:23amachronicthat's why changing it to a commit_discard fixes the problem.
11:28:57speachy(in other words, we're processing in-place across a partial cacheline)
11:29:09amachronicExactly.
11:29:39speachywell, 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:52amachronicmore 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:28amachronicreally the file.c code has to use properly aligned bounce buffers for everything in order to definitely avoid all problems.
11:33:46amachronicbut that's obviously not an option for targets with tiny amounts of RAM.
11:34:03speachynot to mention the performance impact
11:34:36amachronicthe perf impact shouldn't be meaningful because this is what all OS's do.
11:34:47amachronic(Unless you use specialized APIs)
11:35:47amachronicbut 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:22speachy g#3167 is a blanket flush-entire-region-if-unaligned
11:36:24fs-bluebotGerrit 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:50speachyguess it'll be faster to flush the first/last lines instead
11:38:44amachronicwhich would bring us back to g#3158 but changing the '<=' to '<'
11:38:46fs-bluebotGerrit review #3158 at https://gerrit.rockbox.org/r/c/rockbox/+/3158 : Really fix the MIPS cache bug this time by Aidan MacDonald
11:39:51speachyyeah
11:40:55speachyoh, 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:09amachronicyes, forgot about that
11:41:32amachronicI just couldn't see a concise way to avoid it and it's a degenerate case so who cares?
11:42:09amachronic(The second flush will indeed do nothing because the cache line is already invalid.)
11:42:59speachyif (end != ptr && (end != (base + size))) { ... }
11:43:49speachythen you can also use ptr != end instead of ptr < end for the loop.
11:44:32amachronicI think end != ptr is true whenever size > 0
11:44:33speachysince 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:06amachronicchecking for the single cacheline is more like (end - ptr) < CACHELINE_SIZE
11:45:46speachyptr and end are already algined.
11:46:02amachronicmake that <=
11:46:25amachronicanyway I think we're really splitting hairs here about potential performance impact of a couple cheap integer instructions.
11:46:59amachronicthe IO time should be far longer than the time to discard the cache.
11:47:47amachronicso why not just keep it as simple and safe as possible?
11:48:33speachyI want the only difference in discard_range vs commit_discard_range to be the special case writebacks
11:49:12speachysee the current state of g#3167
11:49:14fs-bluebotGerrit 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:49speachyif it's a single cacheline, after the flush, ptr gets pushed forward to equal end.
11:49:56amachronicsorry you're right
11:49:57amachronicjust realized
11:50:20speachythat will short-circuit both the tail check and the loop
11:50:46speachyso hopefully we won't be having this conversation again tomorrow. or two months from now.
11:51:41amachronicyeah go ahead and commit it. Can't see any further problems
11:52:16_bilgusthe announce plugin is kinda cool https://forums.rockbox.org/index.php/topic,53770.0.html
11:58:59speachyjust updating comments
11:59:17speachyfor the poor souls that have to debug this in the future
12:00
12:01:29fs-bluebotBuild Server message: New build round started. Revision cbace906c6, 293 builds, 9 clients.
12:03:10amachronicanyhow thanks for your patience with my bumbling, speachy, it's much appreciated.
12:03:19speachy_bilgus: that's the evolution of g#2534 and FS #11541, correct?
12:03:23fs-bluebothttps://www.rockbox.org/tracker/task/11541 Add Voice Announcement of Summary Info to WPS hotkey (patches, unconfirmed)
12:03:24fs-bluebotGerrit 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:55speachyamachronic: yes indeed, I'm glad there are more eyeballs on this stuff.
12:04:16***Saving seen data "./dancer.seen"
12:09:10_bilgusyeah
12:13:50speachy_bilgus: just closed out 11541 and abandoned my attempt to rework the rework of the rework.
12:14:34fs-bluebotBuild Server message: Build round completed after 785 seconds.
12:14:38fs-bluebotBuild Server message: Revision cbace906c6 result: All green
12:14:48_bilgusit still needs some polish
12:15:02_bilgusand testing
12:16:26 Quit amachronic (Quit: Connection closed)
12:17:16speachy_bilgus: fs#13262 is an odd one.
12:17:17fs-bluebothttps://www.rockbox.org/tracker/task/13262 Battery indicator not working Ipod Mini 2G (bugs, unconfirmed)
12:17:57speachyit'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_bilgusoff 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:44speachythey're using a custom theme
12:45:26_bilgusweird I wonder if at somepoint the precision was increased and they are missing a /10
12:45:41_bilgus48 vs 4.8
12:48:32braewoodsspeachy: do you know of any RB targets which charge from external DC other than 5V?
12:48:45_bilguswell when running announce_status on startup it wipes out the resume track function due to my latest patch lol
12:48:52braewoodsevery one i've seen uses 5V, either barrel jack or USB
12:48:58braewoodsor some proprietary doo hickey
12:49:29speachythe old archos stuff used 6V IIRC
12:49:31braewoodsif every target uses 5V then i will assume that in writing HID Power
12:49:42braewoodsah but archos is gone
12:50:10braewoodsi was just thinking, i think the power system worth reporting through HID POwer is
12:50:15speachybut I'm not aware of anything else that charges externally but not 5V.
12:50:30braewoodssingle DC input of 5V
12:50:37braewoodswhether USB or whatever is irrelevant
12:50:42braewoodsjust an implementation detail
12:50:52braewoodsand this feeds into the battery charger
12:51:08braewoodshow detailed i can get depends on the charger system
12:51:21braewoodsHID Power allows you to report errors
12:51:22braewoodsand such
12:51:27braewoodslike temperature issues
12:51:35braewoodsbut
12:51:41braewoodsnot sure RB even has access to that
12:51:46braewoodsso it may be left unused
12:51:58braewoodsit would be very chip specific
12:52:00braewoodsso
12:52:11braewoodsi may have a very basic initial one
12:52:23braewoodsi'll fully review HID power when i can
12:52:37braewoodsjust trying to decide the most optimal reporting system
12:52:46braewoodsHID Power is standardized
12:52:47speachykeep it simple, battery status (charging/discharging), level, and estimtated time remaining.
12:52:48braewoodsbut
12:53:11speachysome targets dont' report voltage, only a percentage level.
12:53:12braewoodsspeachy: yea, i noticed most of our targets don't even use thermistors in their batteries
12:53:39braewoodsso, in that case, impossible to report temperature events.
12:53:44braewoodsand if it's that bad anyway
12:53:48braewoodsthe hardware will kick in
12:53:57speachyor it'll catch fire :)
13:00
13:02:08braewoodsspeachy: ah yes, the dreaded HCF
13:02:25braewoodsanyway i just took a dump of lsusb on my pc with the wifi keyboard
13:02:33braewoodsi'll see if i can learn how it reports its battery stats
13:03:00braewoodsreimplementing a proprietary protocol works too if it's sufficiently popular among common hosts
13:04:02speachylogitech's HID+ stuff is a start
13:05:10braewoodsit's a logitech keyboard
13:05:22braewoodsi wanted to see if it's using HID Power or something else
13:05:42braewoodsHID Power is mainly for UPS but
13:05:51braewoodsso maybe not the best choice
13:06:05braewoodsit seems it would cover our use case but i care about the bigger picture
13:06:13braewoodshow the hosts would generally use HID power
13:06:29_bilgusWell 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:54braewoodsif it would be considered as a UPS or not
13:06:57braewoodsfor the host
13:07:05_bilgusI'll have to look into it a bit further but something is going on
13:07:06braewoodsinstead of being an auxiliary device battery
13:08:14speachylook into what upower implements
13:08:27speachyit knows how to query battery status for some devices
13:09:08 Nick prg3_ is now known as prg3 (~prg@deadcodersociety/prg318)
13:13:08braewoodsspeachy: indeed. i just wouldn't know what would work with Mac hosts.
13:13:16braewoodsi have no Mac hardware.
13:13:47speachyI mean, work backwards from upower to find out what USB interface it's getting that info from
13:14:13speachy(maybe it's getting it from some Linux sysfs file, in which case find whare _that_ comes from...)
13:15:30braewoodshuh
13:15:34braewoodsseems it is using HID Power
13:15:46braewoodsi found hID Power interface in the lsusb output
13:16:17braewoodshttps://dpaste.com/7EE92H7DM
13:16:28braewoodslast one
13:16:34braewoodsHID Power, 3 0 0
13:16:43braewoods3 1 1, 3 1 2 for the regular HID devices
13:17:17braewoodsso 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:47speachy_bilgus: fs#13269 just came into being; data abort on the imageviewer plugin on the clipzip
14:57:48fs-bluebothttps://www.rockbox.org/tracker/task/13269 Image Viewer is broken in recent builds (bugs, unconfirmed)
15:00
15:40:48fs-bluebotBuild Server message: New build round started. Revision fb99d890a8, 293 builds, 9 clients.
15:51:20fs-bluebotBuild Server message: Build round completed after 632 seconds.
15:51:23fs-bluebotBuild 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:20skrzypAsking 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:39speachyIIRC the FiiO M3K does.
16:42:38speachyas do the various hiby-based models (eros q/k, hifiwalker h2, etc)
16:44:07speachychris_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:14fs-bluebotBuild 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:31chris_s10speachy: 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:35fs-bluebothttps://www.rockbox.org/tracker/task/13262 Battery indicator not working Ipod Mini 2G (bugs, unconfirmed)
17:00:35fs-bluebotGerrit 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:52speachyyeah, I just noticed that one too.
17:02:11fs-bluebotBuild Server message: Build round completed after 657 seconds.
17:02:14fs-bluebotBuild Server message: Revision be99033cbb result: All green
17:02:17speachymy change to 3120 might have been a mistake. solid state drives tha support ATA powermgmt should be properly spun down.
17:02:46speachyas an explicit sign that we want it to be ready for shutdown
17:04:22speachyata is special-cased
17:06:24 Quit chris_s (Quit: Ping timeout (120 seconds))
17:14:19speachychris_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:27speachywhereas we would normally wait until after the disk has spun down, making it obviously safe to kill power.
17:15:48chris_s10This is purely anecdotal, but I haven't experienced any issues with that so far
17:16:14speachythere are some seriously slow SD cards out there...
17:16:32chris_s10right
17:17:15speachyI just don't know how much buffering that janky CF->SD chipset actually does
17:25:47speachygah. 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_bilgusspeachy the data aborts are probably related
17:38:03_bilgusI'm still tracking this one down but it appears to be a case of a use after free ATM
17:39:21fs-bluebotBuild Server message: New build round started. Revision 56a1e87501, 293 builds, 8 clients.
17:39:36speachypure happenstance it shows up now?
17:46:59_bilgusnot sure yet lol
17:47:44_bilgushis build was from FEB so its likely something other than my changes today
17:49:27fs-bluebotBuild Server message: Build round completed after 606 seconds.
17:49:30fs-bluebotBuild Server message: Revision 56a1e87501 result: All green
17:50:26speachychris_s10: g#3169
17:50:31fs-bluebotGerrit 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:05speachychris_s10: DAta corruption is quite possible.
17:53:13speachywe want to allow the ata interface to get powered off (ie system goes idle) after heavy writes.
17:53:43speachyif it does work though, we'll get some battery life back.
17:54:00_bilgusthis 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:08chris_s10speachy: nice, I'll give it a go :)
17:56:18speachyI 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_bilgusCore_free returns 0
18:17:24_bilgusthats 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_bilgusit looks to me like the voice file is probably getting too big
19:58:30speachythat's just going to get worse over time
19:58:42speachysome languages have much larger voice files than engrish too
20:00
20:02:06braewoodsspeachy: any ideas what i should name the new hid power thing?
20:02:11braewoodsi could name it hid_power
20:02:16braewoodsbut that seems really long
20:02:31braewoodsthough just power seems kinda misleading
20:02:46speachylong names don't affect the compiler
20:02:48braewoodsperhaps a usb battery driver?
20:02:49braewoodsi know
20:02:54braewoodsit's purely a cosmetic thing
20:03:22braewoodsso what should I do? it's technically a HID but not really
20:03:34braewoodsit's more of a device to device reporting scheme
20:03:41braewoodsvery little human input
20:04:05braewoodshm
20:04:27***Saving seen data "./dancer.seen"
20:04:28braewoodsi'm tempted to name battery since it's intended to report battery levels
20:04:36braewoodsbut
20:04:46braewoodsusb_hid_power
20:04:48braewoodseh
20:04:56braewoodsi guess less confusion about what it does
20:05:00braewoodsi'll just use this
20:05:19braewoodsthe user probably won't know what the source uses anyway
20:05:26braewoodswe can paper over it in the UI if we need to
20:12:08speachyhid_power is technically accurate, so that's fine in the source
20:16:53braewoodsjust funny naming and all
20:16:59braewoodsit has little to do with HID
20:17:24braewoodsapparently the main thing it shares is the HID interface codes
20:17:31braewoodsfrom what i can gather so far
20:17:41braewoodsstill
20:17:46speachyyep, piggybacks on the HID structure/design
20:18:01speachywhich is fine as it's one-way data that only slightly changes
20:18:05braewoodsi'm tempted to name it just POWER
20:18:11braewoodsso
20:18:16braewoodsshould i extend usb_hid instead?
20:18:23braewoodssince it's technically a subset of that
20:18:28 Quit mendel_munkis (Read error: Connection reset by peer)
20:18:44braewoodsi'll poke around in the current hid source
20:18:50_bilguswe might want to think about loading plugin voices per plugin then
20:19:11braewoodsi want to figure out how i will integrate the driver before i got writing the guts of it
20:19:13_bilgusor switch to a compressed format in mem and decode on the fly
20:20:13_bilgusI thought we did that already but it looks to be wav?
20:25:03braewoodsspeachy: how does rockbox uses hid mouse?
20:25:14braewoodsit's setup for keyboard descriptors, doesn't even use one for mice.
20:25:26braewoodsrather confusing right there
20:27:47 Quit ac_laptop (Ping timeout: 260 seconds)
20:28:03braewoodshm
20:28:16braewoodsi'll see if i can integrate HID Power into the existing HID driver first
20:28:31braewoodsi may also make a standalone version so we can enable it exclusively for charging only mode
20:29:16braewoodsmy thinking is if i can reuse the existing HID driver i won't need to acquire extra endpoints to handle it
20:29:31braewoodsso we can more efficiently use the available endpoints
20:37:07braewoodswoohoo. got my new sansa fuze+
20:37:18braewoodsplan to use my high endurance MLC micro sd card with it
20:38:11braewoodsonce 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_bilgusspeach 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:22fs-bluebotBuild Server message: New build round started. Revision b2732222e9, 293 builds, 9 clients.
21:22:57_bilgusas 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:23fs-bluebotBuild Server message: Build round completed after 661 seconds.
21:33:25fs-bluebotBuild 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:40speachy_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:21braewoodsspeachy: i'm suspecting it's not realistic to use the same driver for both
21:41:33braewoodsthey're probably separate for a reason
21:41:42braewoodsthough they share common bits
21:41:59braewoodsspeachy: i think the hid driver needs to be restructured so I can reuse the common bits.
21:42:03braewoodsthough how
21:42:15braewoodsi'll figure out after I understand how to make hid power work
21:42:19braewoodsfor now i'll make it independent
21:43:04braewoodsi think the existing hid drive needs to be renamed a bit
21:43:13braewoodsHID_KEYBOARD or something
21:43:22braewoodsor even hid_input
21:44:59 Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-iaialaudtoihlpte)
21:46:53amachronicspeachy: 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:53amachronicand 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_bilgusspeachy 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_bilgusbut its broken atm I kinda left it disabled on accident
21:53:33speachynow is the reason for the bounce buffer in the sdmmc-imx233 because if cacheline alignment, or dma engine requirements?
21:54:53amachronicfrom 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:39amachronicI 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:58speachythis seems ... unnecessarily complicated
21:57:42speachyand someting that presumably is equally an issue for most of the other dma-capable targets.
21:58:58fs-bluebotBuild Server message: New build round started. Revision 10b6707131, 293 builds, 9 clients.
21:59:21amachronic(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:42speachynand driver on the nano2g too
22:00
22:00:15amachronicso is as3525/sd-as3525v2.c
22:00:41amachronicand as3525/sd-as3525.c
22:00:57amachronicand also s3c2440/sd-s3c2440.c.
22:01:21speachyI 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:01amachronicThey 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:28speachykinda seems to me that the right thing to do is fix this in the upper layer
22:02:40speachyinstead of every driver having to reimplement the same thing
22:03:19amachronicI 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:35amachronicand that's why we have this situation today.
22:04:29***Saving seen data "./dancer.seen"
22:04:39amachronicbut 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:45speachyamsv2 uses a 5KB realignment buffer
22:08:25amachronicit seems that whoever wrote that simply decided 5 KB is a good compromise between memory use and reducing the number of transfers.
22:08:56amachronicthere's no magic in the number otherwise
22:09:01amachronic(as far as I can tell)
22:09:31speachyI'm wondering if we're likely to multi-block transfers that are unaligned.
22:10:18amachronicIt happens with the bitmap loading code on the FiiO, but that would vary with targets depending on their screen resolution, I think
22:10:20fs-bluebotBuild Server message: Build round completed after 682 seconds.
22:10:22fs-bluebotBuild Server message: Revision 10b6707131 result: 0 errors 57 warnings
22:10:41speachy_bilgus: I think you're on another roll tonight...
22:12:38speachySTORAGE_WANTS_ALIGN has code specificaly to ignore alignment for bitmap buffers, heh.
22:18:51amachronicgiven 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:10amachronici 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:12speachyI'm trying to understand the call graph, becuse everything at the filesystem and below seems to operate at the block level
22:24:39amachronicFrom my understanding, that's correct.
22:26:04amachronicif 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:29speachyreadwrite() in firmware/common/file.c seems to be the meat of it.
22:27:00amachronicyes that's what I mentioned earlier today
22:27:15speachyfirst time I've looked into this bit of the codebase
22:27:15amachronicat 11:21
22:28:32amachronicIt'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:06amachronic(more specifically it's the adjustments done after readwrite_partial() which cause the problem but you see what I mean.)
22:29:13speachyyeah.
22:30:04amachronicnow if we applied the same logic as imx233 _here_, we'd have a fix.
22:30:48amachroniconly 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_bilgusI think the announce plugin might need some finesse on the ClipZip its slamming that buffer hard on the first track load
22:33:33_bilgussince 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:36amachronicit 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:22amachronicrather than trying to figure out the nightmare of how to get a buffer some other way
22:40:26speachyamachronic: nah, I think the place to insert the shim is in transfer() in fat.c
22:40:45speachyand key it all on STORAGE_WANTS_ALIGNED
22:41:06speachysimilar logic to how the amsv2 code does it, with a 10 sector buffer.
22:41:59speachyand if we're unaligned, incrementally transfer (and realign) 10 sectors at a time until we're done.
22:42:55amachronichmm... 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:19amachronicbecause we have to copy the same amount of memory either way. unless memmove() is drastically less efficient than memcpy().
22:45:19amachronicI definitely agree that fat.c is a better place to put it.
22:49:05amachronichmm after looking at the definition of memmove(), it looks like it may suck badly.
22:49:41_bilgusMEMMOVE IS SEVERAL X SLOWER
22:49:46_bilgusoops
22:50:03_bilgusthat whole overlapping region check
22:54:57speachy_bilgus: line 629 of apps/talk.c, I think you left out {} around the block
22:56:08speachythe net result is that voiceload always fails.
22:57:51fs-bluebotBuild Server message: New build round started. Revision 03ae4e6019, 293 builds, 9 clients.
22:58:35_bilgusarg sure enough
23:00
23:00:30speachyamachronic: g#3173 is what I'm aiming for.
23:00:32fs-bluebotGerrit 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_bilgusi 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:16fs-bluebotBuild Server message: Build round completed after 627 seconds.
23:08:21fs-bluebotBuild Server message: Revision 03ae4e6019 result: 0 errors 57 warnings
23:09:49amachronicspeachy: 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:29speachythere's a lot of overhead per-request but I somehow suspect we're not doing large-ish transfers into unaligned buffers.
23:12:30amachronicthat's my intuition too
23:13:17speachyusing the amsv2 as inspriation, I know that target was uber-optimized
23:16:05amachronicif 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:00speachy_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_bilgusoh its up now I just want to test it once more
23:34:45_bilguslol
23:34:51_bilguswonder why
23:36:17_bilgusI 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:52speachywonder 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_bilgusouch
23:39:01speachywe've both done a fine job lately, eh?
23:40:01speachyamachronic: my realignment-in-fat-layer compiles now, at least. I'm not feeling brave enough to actually _test_ it though.
23:41:38speachyand on that note, it's time to turn into a pumpkin. g'nite..
23:41:52fs-bluebotBuild Server message: New build round started. Revision 895ed92496, 293 builds, 9 clients.
23:42:03_bilgusnight
23:43:06*__builtin thinks he might have some time to revisit that SDL2 port soon...
23:52:26fs-bluebotBuild Server message: Build round completed after 634 seconds.
23:52:29fs-bluebotBuild Server message: Revision 895ed92496 result: All green

Previous day | Next day