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

00:01:50***Saving seen data "./dancer.seen"
00:05:08_bilgus_ah got it thankfully daniel documented it
00:15:02 Quit Saijin_Naib (Ping timeout: 258 seconds)
01:30:37 Quit Huntereb (Read error: Connection reset by peer)
01:33:26 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57)
01:33:44 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:811f:4ad4:93cb:16f9)
01:37:58 Quit ZincAlloy (Ping timeout: 246 seconds)
01:43:39 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:811f:4ad4:93cb:16f9)
01:47:57 Quit ZincAlloy (Ping timeout: 250 seconds)
01:52:20 Join ZincAlloy [0] (
01:56:46 Quit ZincAlloy (Ping timeout: 260 seconds)
02:00:05_bilgus_think I've got it g#3264
02:01:52***Saving seen data "./dancer.seen"
02:48:40 Quit Stanley00 ()
04:01:55***Saving seen data "./dancer.seen"
04:50:52 Quit Huntereb (Read error: Connection reset by peer)
04:52:16 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7::69)
05:17:44 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:50:38 Quit Huntereb (Read error: Connection reset by peer)
05:52:19 Join Huntereb [0] (
05:54:39 Quit SammysHP (Quit: *wuff*)
05:55:05 Join SammysHP [0] (
06:02:00***Saving seen data "./dancer.seen"
06:32:51speachy_bilgus_: so the fact that H10 somehow triggered this but not the ipods is sheer luck?
06:37:49speachyand this can be attributed to the compiler mis-optimizing things?
06:56:29speachyI confess I don't understand what you're trying to accomplush on L262-263; what's the point of reading the value if you're just going to set all bits except for the DIRTY bit anyway?
06:59:25speachyit seems the only practical difference is that you're setting addresss for each cacheline to all 1s
07:26:44_bilgus_speachy the address doesn't matter as far as not crashing but those unused bits I suspect
07:27:14_bilgus_but which ones bit 21 or bit 24-31??
07:27:59_bilgus_I also didn't appear to need to clear the dirty bit as they all 'SHOULD BE' valid once they get to me
07:52:22speachywe don't want them marked dirty going to invalid addresses. I don't know how the CPU would handle that
08:02:01***No seen item changed, no save performed.
08:03:10_bilgus_I'm going to try and dump the status register now and figure out what those unused bits are coming through as
08:13:21speachyyeah. still strange how this only seems to screw upthe H10
08:13:37speachyis there something else special about it vs the ipods? RAM size?
08:14:28 Join Saijin_Naib [0] (
08:15:38_bilgus_ffff009f so it normally has the upper filled with ones
08:16:07_bilgus_I think they are both 32 bit but I wonder how much is silent corruption
08:16:13_bilgus_32 MB
08:16:29*speachy nods.
08:25:26speachyas an aside, I know one of the designers of the ARM7TDMI core.
08:33:52_bilgus_of I guess i read that backwards out of the file LE right?
08:38:49_bilgus_but if that the case then later it has them filled
08:39:17_bilgus_maybe I better format the file output
08:41:40 Quit Saijin_Naib (Disconnected by services)
08:41:44 Join Saijin-Naib [0] (
08:41:44 Quit Saijin-Naib (Read error: Connection reset by peer)
08:41:52 Join Saijin_Naib [0] (
08:56:32 Quit Saijin_Naib (Disconnected by services)
08:56:35 Join Saijin-Naib [0] (
09:04:49 Join massiveH [0] (
09:13:24 Join Saijin_Naib [0] (
09:15:32 Quit Saijin-Naib (Ping timeout: 258 seconds)
09:15:57_bilgus_Looks to me that the upper bits are always 0 and I don't see anything amiss in the data either maybe its still alignment fooling me??
09:20:43speachyif you did a printf on a 32-bit field (using #x) the output is BE for human consumption
09:21:19speachyif you're looking at 4 one-byte %02x fields, then it's LE
09:22:51 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
09:42:53 Quit Saijin_Naib (Ping timeout: 252 seconds)
09:44:12_bilgus_I got it but whats odd is this last line 0x0xf0005ff0 0xC00000 000000 0x00C00000
09:45:47_bilgus_that is a zero address marked valid and dirty
09:47:20_bilgus_maybe instead of filling the cache by pulling addresses I should try filling it manually
09:51:45_bilgus_another at 390 but marked valid and clean
09:52:19_bilgus_those should be either filled or that 20 bit 1FFFF
10:02:05***Saving seen data "./dancer.seen"
10:02:55speachyso to refill the cache just do what we did with the init code?
10:03:28speachyso that last entry is odd, yeah
10:03:42speachy..well, 0 _is_ technically a valid address
10:06:40_bilgus_yeah but we init off of 0x2000
10:07:06_bilgus_was 0x1000 your patch doesn't matter but who wuld be putting it in there an ISR?
10:07:34_bilgus_they are both odd but for different reasons
10:08:05_bilgus_actually i'm gonna try init with the code that invalidates it
10:08:13_bilgus_well pseudo invalidates it?
10:08:56speachyISR vector table starts at 0x0
10:09:54speachybut I don't see why that would ever get marked as dirty
10:10:11speachywell, unless we have a null pointer dereference + write somewhere.
10:16:11_bilgus_possible but why only here
10:21:10_bilgus_ok initializing it like we invalidate there are no longer any 0 addresses but I can't say that fixed it till I run it like 10 more times to be sure
10:23:54_bilgus_oddly I don't see any of the invalidated entries this run either
10:24:46braewoodsdoes armv4 not have a MMU?
10:25:15speachyarmv4 can have a MMU, but these specifically do not.
10:25:22braewoodsi see
10:25:39braewoodstoo bad, that might help with catching issues
10:26:21braewoodsan MMU to protect RB from being overwritten by user applications or so would be nice
10:27:35_bilgus_yeah this is kinda weird too I no longer see any invalidated entries through multiple runs
10:30:17_bilgus_well I guess I'm getting somewhere even with code size changes it hasn't crashed
10:39:55 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
10:45:22 Quit massiveH (Quit: Leaving)
10:53:22 Join Saijin_Naib [0] (
10:58:45 Quit Saijin_Naib (Disconnected by services)
10:58:49 Join Saijin-Naib [0] (
11:27:45 Quit Saijin-Naib (Ping timeout: 252 seconds)
11:42:49 Join ac_laptop [0] (~ac_laptop@
11:47:41 Quit ac_laptop (Ping timeout: 246 seconds)
11:57:33 Quit kakaka (Ping timeout: 240 seconds)
11:58:28 Join ac_laptop [0] (~ac_laptop@
12:02:09***Saving seen data "./dancer.seen"
12:09:28 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu)
12:17:28 Join MrZeus [0] (~MrZeus@
12:49:20braewoodsspeachy: how fast is the sequential read speed on your fiio m3k?
12:49:29braewoodsnot sure how fast the newer players are
12:49:39speachyno clue
12:49:50braewoodsoh i see
12:50:01braewoodsi usually benchmark my units to get an idea of how fast they are under the best circumstances
12:50:32braewoodsi've never seen higher than 13MB/s, i saw that in H120s and HDD1630s that were CF modded
12:50:45braewoodsjust weird seeing stuff slower than that
13:09:35 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:8c09:6ea:e145:2a6a)
13:11:28 Join lebellium [0] (
13:29:21 Quit ac_laptop (Ping timeout: 260 seconds)
13:31:10 Join ac_laptop [0] (~ac_laptop@
13:36:09 Quit ac_laptop (Ping timeout: 252 seconds)
14:02:13***Saving seen data "./dancer.seen"
14:07:01 Quit atsampson (Ping timeout: 245 seconds)
14:08:00 Join atsampson [0] (
14:15:45 Nick funman_ is now known as funman (~fun@rockbox/developer/funman)
14:37:04 Quit J_Darnley (Ping timeout: 246 seconds)
14:41:37 Join J_Darnley [0] (
14:46:33 Quit J_Darnley (Ping timeout: 252 seconds)
14:46:37 Join jdarnley [0] (
15:15:26 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
15:35:22 Join Saijin_Naib [0] (
15:35:53 Quit Saijin_Naib (Read error: Connection reset by peer)
15:36:16 Join Saijin_Naib [0] (
15:39:26 Join PimpiN8 [0] (~PimpiN8@
15:47:22 Quit Saijin_Naib (Read error: Connection reset by peer)
15:49:55 Join Saijin_Naib [0] (
16:02:16***Saving seen data "./dancer.seen"
16:06:57 Quit Saijin_Naib (Read error: Connection reset by peer)
16:08:33 Join Saijin_Naib [0] (
16:10:17 Quit Saijin_Naib (Read error: Connection reset by peer)
16:12:30 Join Saijin_Naib [0] (
16:12:40 Quit Saijin_Naib (Read error: Connection reset by peer)
16:14:18 Join Saijin_Naib [0] (
16:41:03 Quit Saijin_Naib (Ping timeout: 250 seconds)
16:53:33 Quit pamaury (Ping timeout: 246 seconds)
16:55:30 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
17:34:25 Quit advcomp2019 (Ping timeout: 276 seconds)
17:34:30 Quit lebellium (Quit: Leaving)
18:02:19***Saving seen data "./dancer.seen"
18:08:40 Quit ZincAlloy (Quit: Leaving.)
18:38:30 Join Soap_ [0] (~Soap@rockbox/staff/soap)
18:39:18 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:41:03 Join mulp [0] (~plum@unaffiliated/plum)
18:41:22 Quit Soap (Read error: Connection reset by peer)
18:41:22 Quit dys (Ping timeout: 265 seconds)
18:43:13 Quit Galois (Ping timeout: 240 seconds)
18:43:13 Quit plum (Ping timeout: 240 seconds)
18:43:14 Nick mulp is now known as plum (~plum@unaffiliated/plum)
19:05:42 Join ac_laptop [0] (~ac_laptop@
20:02:20***Saving seen data "./dancer.seen"
20:15:09 Quit pamaury (Ping timeout: 246 seconds)
20:30:29 Quit MrZeus (Ping timeout: 252 seconds)
20:38:55 Quit ac_laptop (Ping timeout: 252 seconds)
22:02:24***Saving seen data "./dancer.seen"
22:15:59 Quit bonfire (Quit: Leaving)
22:16:38 Quit cockroach (Ping timeout: 246 seconds)
22:27:10 Quit Strife89 (Quit: No Ping reply in 180 seconds.)
22:27:26 Join Strife89 [0] (
22:32:47 Join f1reflyylmao [0] (
22:33:24 Quit f1refly (Ping timeout: 246 seconds)
22:33:25 Nick f1reflyylmao is now known as f1refly (
22:56:36 Join JanC_ [0] (~janc@lugwv/member/JanC)
22:56:44 Quit JanC (Killed ( (Nickname regained by services)))
22:56:44 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC)
23:04:09 Join Galois [0] (
23:26:22 Join advcomp2019 [0] (
23:26:22 Quit advcomp2019 (Changing host)
23:26:22 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)

Previous day | Next day