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).

#rockbox log for 2021-03-31

00:02:28***Saving seen data "./dancer.seen"
01:27:01 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:b0d4:a6a1:a33)
01:28:44 Quit pixelma (Quit: .)
01:28:44 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
01:31:10 Join pixelma [0] (~marianne@rockbox/staff/pixelma)
01:31:10 Join amiconn [0] (~jens@rockbox/developer/amiconn)
01:31:12 Quit ZincAlloy (Ping timeout: 246 seconds)
01:33:32 Join ufdm_ [0] (
01:35:14 Quit ufdm (Read error: Connection reset by peer)
01:37:32 Join ZincAlloy [0] (
01:42:01 Quit ZincAlloy (Ping timeout: 260 seconds)
01:54:08 Join ZincAlloy [0] (
01:59:05 Quit ZincAlloy (Ping timeout: 268 seconds)
02:02:31***Saving seen data "./dancer.seen"
03:15:38 Quit kakaka (Remote host closed the connection)
03:16:07 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu)
03:22:48 Join berber [0] (
03:32:16 Quit ufdm_ (Remote host closed the connection)
03:32:34 Join ufdm_ [0] (
04:02:32***Saving seen data "./dancer.seen"
04:39:41 Quit akaWolf (Ping timeout: 240 seconds)
05:09:31 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
05:28:21 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:51:12 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
06:02:35***Saving seen data "./dancer.seen"
07:21:44 Quit pamaury (Quit: No Ping reply in 180 seconds.)
07:26:00 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
07:47:02 Join MrZeus [0] (~MrZeus@
08:02:39***Saving seen data "./dancer.seen"
08:13:21 Join dweeber_ [0] (
08:15:13 Quit dweeber (Ping timeout: 252 seconds)
08:24:43 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
08:48:48 Quit ufdm_ (Quit: Leaving)
08:52:18 Join massiveH [0] (
08:54:33 Join ufdm [0] (
09:19:15speachy_bilgus_: saw the latest rev of the PP cache flush. talk about an expensive op!
09:20:57speachy(4K loop iterations to fully invalidate the cache....)
09:24:57 Quit pamaury (Ping timeout: 260 seconds)
09:25:41 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
09:31:49_bilgus_yeah thats odd that we were only doing like 1/2 I'm not sure the implications but it is no more or less crashy
09:33:41_bilgus_but that volatile is the key why, No F-ing idea. still alignment?? cache contention?
09:34:34_bilgus_it is stable AF though code changes are not changinging it and I haven't seen a usb unplug data abort in the last 20x
09:39:16speachyhow often do we actually do a complete cache discard on these things?
09:39:26speachyhopefully not before every rx dma..
09:52:46_bilgus_it could be a mirror too I'll have to look tongiht
10:02:41***Saving seen data "./dancer.seen"
10:20:54braewoodsthe samsung native players got some real usability issues
10:21:03braewoodsin terms of upgrades or so
10:21:19braewoodstheir choice of HDD interface has a tendency of disconnecting from the slightest movement
10:21:38braewoodsso getting it to recognize it reliably is a PITA
10:21:47braewoodsnot one i'd recommend to a new user
10:22:31braewoodsthe other units that use ribbon cables have a retention bracket
10:22:37braewoodsnot true here
10:22:57braewoodsoh well
10:27:25braewoods_bilgus_: all i know about volatile is it forces the compiler to re-read a location instead of reusing a cached value
10:27:31braewoodsor so
10:27:37braewoodsdisables optimizations to a degree
10:28:06braewoodsit's most often used for special memory regions that can change outside of the knowledge of the compiler
10:28:37braewoodsbut no idea why it would matter here
10:42:20 Quit massiveH (Quit: Leaving)
11:32:55 Quit ufdm (Quit: Leaving)
12:02:44***Saving seen data "./dancer.seen"
12:15:59 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:3075:a015:3cfd:6586)
12:21:24 Join ufdm [0] (
13:21:29 Join lebellium [0] (
13:22:46 Quit _bilgus_ (Ping timeout: 246 seconds)
13:30:53 Join _bilgus [0] (
13:52:58 Quit jdarnley (Ping timeout: 240 seconds)
13:55:33 Join J_Darnley [0] (
13:56:21 Quit advcomp2019 (Ping timeout: 246 seconds)
14:02:47***Saving seen data "./dancer.seen"
14:25:40 Join advcomp2019 [0] (
14:25:41 Quit advcomp2019 (Changing host)
14:25:41 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
14:33:04_bilgushaha speachy its only 1024 status entries I just saw the 4k part its 4k / 4 bytes size of entry only 1k actual entries
14:37:52_bilgusand no not mirrored and it is the case in the original code as well AFAICT by 512x16/4
14:39:45_bilgusstepped by 4 bytes = 512
14:41:52speachythat sounds a lot more sane
14:42:20 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
14:42:23speachy8k cache w/ 16-byte lines == 512 entries
14:54:04 Quit advcomp2019 (Read error: Connection reset by peer)
15:13:31 Join advcomp2019 [0] (
15:13:31 Quit advcomp2019 (Changing host)
15:13:31 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
16:02:51***Saving seen data "./dancer.seen"
16:12:28 Quit _bilgus (Read error: Connection reset by peer)
16:13:15 Join _bilgus [0] (
16:29:30 Join MrZeus_ [0] (~MrZeus@
16:32:58 Quit MrZeus (Ping timeout: 240 seconds)
16:39:31 Join MrZeus__ [0] (~MrZeus@
16:43:13 Quit MrZeus_ (Ping timeout: 265 seconds)
17:43:24_bilgusspeachy the only thing is that the other 512 entries have valid & changing data
17:43:44 Join ac_laptop [0] (~ac_laptop@
17:47:50 Join PimpiN8 [0] (~PimpiN8@2001:1c04:3308:a500:d5b8:7ae7:dfab:af01)
18:02:55***Saving seen data "./dancer.seen"
18:04:22_bilgus ah speachy I know whts going on here
18:04:33_bilgus8k cache for each core
18:05:09_bilgusso we need to look at the current owner and invalidate the proper one
18:06:42speachyugh, yeah, two caches, but.. are they accessible from each others' address space?
18:06:54speachyI suppose if they're on the AHB they must be
18:07:03_bilgusno clue but I assume so
18:07:43_bilgusso I sure hope its laid out as status 1 x 512 status 2 x 512
18:08:05speachywe could do a uniproc build and see which one is populated
18:08:29_bilgusboth set of lines have valid bits and changing data
18:08:57_bilgusoh you mean to see how its laid out
18:08:59_bilgusgot ya
18:09:13_bilgusfill it with junk and disable one core
18:09:39_bilgusok that'll take me a few any pointers how to lock out the core just while loop
18:09:49speachyIIRC in the one cpu case the second core is held in reset
18:23:57speachy...this could explain a lot of wonkiness..
18:24:09 Quit ZincAlloy (Quit: Leaving.)
18:24:11speachyif we're not re-initializing the correct cpu's cache
18:30:52speachyour threading model doesn't guarantee a specific core will handle any given operation..
18:35:25 Quit lebellium (Quit: Leaving)
18:42:16 Quit ac_laptop (Quit: WeeChat 3.0)
18:42:40 Join ac_laptop [0] (~ac_laptop@
18:49:36_bilgus#define FORCE_SINGLE_CORE
18:50:10_bilgusI should also do that with HEAD and see if it works properly
18:52:05speachyit worked when I was trying to debug the updated toolchain
18:52:19speachydon't see why it wouldn't now. :)
19:04:13_bilguslooks to me they go 512 512 but the second half is not totally clear
19:04:34_bilgusbut it has mostly the valid invalid bits..
19:04:58_bilgus1FFFF address..
19:07:28speachyso all of our cache code needs to care about IF_COP() or not.
19:08:27 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:26:47braewoods_bilgus: so it's some kind of race condition?
19:38:39 Quit pamaury (Ping timeout: 246 seconds)
20:02:59***Saving seen data "./dancer.seen"
20:27:58 Quit MrZeus__ (Ping timeout: 240 seconds)
21:01:42 Quit cockroach (Quit: leaving)
21:31:31_bilgusbraewoods, It appears so
21:31:39_bilgusso far my POC works
21:32:23_bilgusnow to figure out how to integrate it into that IF_COP define
21:34:05_bilgusoh and test the cache data for mismatches
21:36:29_bilgusNow I really wonder why the ipods were fine
21:41:08 Quit _bilgus (Read error: Connection reset by peer)
21:41:15 Join _bilgus [0] (
21:56:32braewoodsbluebrother: got it finally
22:03:00***Saving seen data "./dancer.seen"
22:28:42 Join f1reflyylmao [0] (
22:32:25 Quit f1refly (Ping timeout: 268 seconds)
22:32:26 Nick f1reflyylmao is now known as f1refly (
22:49:11 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
23:30:18braewoods_bilgus: new mystery.
23:30:31braewoodsdevelopment rockbox doesn't work on the gigabeat S i bought from bluebrother
23:45:31braewoodsi'll look into in awhile
23:46:52_bilgusthe gigabeast was probably broken by the toolchain it has a lot of quirks IIRC
23:47:13_bilgusthis was an eventful week
23:47:34_bilgusthanks for sending me the h10 :P don't send more lol
23:49:58braewoodsi'll look into it
23:54:04braewoodsnot surprising we didn't get complaints about the gigabeat S
23:54:12braewoodsit's a very rare unit
23:54:33braewoodsin any case i'll try a build later
23:54:42braewoodsi just hate having to go backwards
23:54:49braewoodsit usually means making a whole new toolchain
23:55:03 Quit ac_laptop (Ping timeout: 268 seconds)
23:56:10_bilgusthats why vms are nice
23:56:22_bilgusassuming you ave enough space to store em
23:56:39braewoods_bilgus: indeed
23:56:49braewoodsi'll do a custom build of 3.15 and see if that works first of all
23:57:05braewoodsi think bluebrother wanted me to finish the gigabeat S port
23:57:16braewoodsfirst gotta get it booting again
23:57:22braewoodsi suspect more LCD breakage
23:57:37braewoodswe'll see
23:58:03braewoodsthis unit has no reset button but it has battery disconnect switch
23:58:07braewoodsclose enough
23:58:29braewoodsanywho time to order some parts to make this useable with what i got at home

Previous day | Next day