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 2020-09-05

00:00:44 Quit Huntereb (Ping timeout: 258 seconds)
00:02:14 Quit ac_laptop (Ping timeout: 256 seconds)
00:11:28 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
00:23:15 Quit __Bilgus (Remote host closed the connection)
00:41:28***Saving seen data "./dancer.seen"
01:01:20 Quit Oksana (Read error: Connection reset by peer)
02:41:30***Saving seen data "./dancer.seen"
02:46:18 Join johnb4 [0] (
03:32:24 Quit johnb4 (Ping timeout: 240 seconds)
03:43:28 Quit pamaury (Ping timeout: 256 seconds)
03:44:08 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
04:41:32***Saving seen data "./dancer.seen"
04:50:30 Join johnb4 [0] (
04:53:01 Quit pamaury (Ping timeout: 264 seconds)
04:59:23 Quit johnb4 (Ping timeout: 240 seconds)
05:12:11 Join berasmerah [0] (~xyz@
05:12:35 Part berasmerah
05:12:38 Join berasmerah [0] (~xyz@
05:14:14berasmerahhello, uhm i have problem when compiling from git for my mini 2g.
05:14:16berasmerahcollect2: ld returned 1 exit status
05:14:16berasmerahmake: *** [/home/berasmerah/rockbox/tools/root.make:250: /home/berasmerah/rockbox/build/rockbox.elf] Error 1
05:14:51berasmerahos: debian 10
05:15:22 Quit S|h|a|w|n (Read error: Connection reset by peer)
05:18:41 Quit berasmerah (Remote host closed the connection)
05:18:42 Join pamaury [0] (
05:18:42 Quit pamaury (Changing host)
05:18:42 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:19:05 Join berasmerah [0] (~xyz@
05:24:39 Quit berasmerah (Ping timeout: 258 seconds)
06:10:30 Join johnb2 [0] (
06:41:36***Saving seen data "./dancer.seen"
06:49:00 Quit johnb2 (Quit: Nettalk6 -
07:10:45 Join MrZeus [0] (
07:56:43 Join johnb4 [0] (
08:05:48 Join lebellium [0] (
08:08:01 Quit mendelmunkis (Ping timeout: 264 seconds)
08:12:56 Join mendelmunkis [0] (
08:31:19 Quit mendelmunkis (Read error: Connection reset by peer)
08:32:20 Join mendelmunkis [0] (
08:41:38***Saving seen data "./dancer.seen"
08:51:00 Quit johnb4 (Ping timeout: 256 seconds)
09:48:34 Join __Bilgus [0] (41ba23be@
10:32:13 Join johnb4 [0] (
10:41:40***Saving seen data "./dancer.seen"
10:42:34 Quit __Bilgus (Remote host closed the connection)
10:59:07 Quit pamaury (Quit: Konversation terminated!)
11:09:35 Join __Bilgus [0] (41ba23be@
11:10:14__BilgusCrash Haas surround
12:00:49 Quit johnb4 (Ping timeout: 264 seconds)
12:26:11speachy__Bilgus: I wonder if our asm memset is busted. should be easy enough to test..
12:26:51speachydid you confirm that the pointer returned by core_get_data() has at least SURROUND_BUFSIZE bytes to spare?
12:27:43 Join johnb2 [0] (
12:38:14 Join bonfire [0] (
12:41:41***Saving seen data "./dancer.seen"
12:44:34 Join beencubed [0] (~beencubed@
12:56:18 Quit t0mato (Quit: Ping timeout (120 seconds))
13:03:40 Quit johnb2 (Quit: Nettalk6 -
13:10:56 Join t0mato [0] (~t0mato@
13:12:31speachy oh wait, you marked this as applying to all targets
13:18:39 Quit __Bilgus (Remote host closed the connection)
13:21:21 Join ac_laptop [0] (~ac_laptop@
13:27:28 Join PimpiN8 [0] (~PimpiN8@
13:35:35 Join __BIlgus [0] (41ba23be@
13:35:58__BIlgusyes all targets
13:36:46__BIlguswellclipzip and the xduoo..
13:36:48speachymakes me think we have more than one thing using the same handle.
13:37:36__BIlgusmost likely just making it the bigger of the two
13:37:58__BIlgusbut it wasn't related to the xduoo and its slightly specific to repro
13:39:42 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
13:40:41 Join johnb4 [0] (
13:42:26speachyis handle == 0 legal? if so, L124 is off-by-one.
13:45:59speachyhmm, handle == 0 is not legal.
13:55:19 Quit johnb4 (Ping timeout: 246 seconds)
14:01:46__BIlgusoh then theres another bug just above
14:01:48__BIlgusstatic void surround_buffer_free(void){ if (handle < 0) return;
14:05:47speachyin the guts of buflib_alloc, a handle of 0 is an error, but the function then returns -1.
14:08:59__BIlguslooks like buflib_free() will happily free a handle that == 0
14:12:01braewoodsaka null?
14:13:19speachyno.. wait, this is convoluted logic. handle == 0 appearas legal after all.
14:14:15speachy'handle' is an index into a table, and 0 is a legal index.
14:15:11speachyso L124 needs to be >= 0
14:17:25speachydo you know what the stack trace is for this crash?
14:18:09speachyseems logical that if the memset() wasn't barfing then the surround_process() function would.
14:18:37speachyI mean they both would behave the same, as they both use the full buffer allocation
14:20:09speachyit might be taht the allocation is failing and nothing is checking the return codes.
14:21:04__BIlguswhen I looked at the pc it was memcpy
14:21:12speachyie not checking sound_configure()'s return code
14:21:41speachyand another code path might end up invoking a flush() call, which blindly calls memset on a handle of -1.
14:21:56__BIlgusTLB Exeception Logd or Ifetch 0xffffb58c at 0x80000570stack at 0x800036a4
14:22:15speachyadding a if (handle > -1) wrapper around the memset() might be all that's needed
14:23:18__BIlgusyeah and I'd have caught that if I'd looked at buflib instead of that free function above, I must be needing glasses or something I tell you
14:24:27speachyI'm distracting myself with this stuff to take my mind off the debacle that was this morning's automotive repair attempt
14:26:12speachyit's allocating a 31372-byte buffer.
14:26:42speachythe root cause might be that there's just not enough buflib available to do both things at once.
14:28:43 Quit __BIlgus (Remote host closed the connection)
14:41:44***Saving seen data "./dancer.seen"
15:58:13 Join johnb4 [0] (
15:59:15 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
16:02:24 Quit johnb4 (Ping timeout: 240 seconds)
16:04:48 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:28:59 Quit t0mato (Quit: Ping timeout (120 seconds))
16:32:13 Join _Bilgus_ [0] (41ba23be@
16:40:29 Join t0mato [0] (~t0mato@
16:41:47***Saving seen data "./dancer.seen"
16:45:00 Join PimpiN8 [0] (~PimpiN8@
16:45:13 Quit PimpiN8 (Client Quit)
16:47:23 Join johnb4 [0] (
17:03:49 Quit johnb4 (Ping timeout: 264 seconds)
17:07:43 Join Inclement_Death [0] (
17:07:54 Quit Ckat (Ping timeout: 256 seconds)
17:17:58 Quit Lonoxmont (Ping timeout: 246 seconds)
17:19:46 Join Lonoxmont [0] (
17:26:17 Quit Inclement_Death ()
18:17:00fs-bluebot_Build Server message: New build round started. Revision 8188588, 280 builds, 7 clients.
18:17:17 Quit lebellium (Quit: Leaving)
18:20:35 Quit pamaury (Ping timeout: 240 seconds)
18:23:25speachyhmm. g#2736 doesn't fix fs#13238
18:23:28fs-bluebot_ Haas surround + timestretch causes crash (bugs, new)
18:27:56_Bilgus_I still got the crash unless I commented out the memset I figured it was a size mismatch between the two but you know my track recor over the last two days says otherwise LOL
18:31:33 Quit ac_laptop (Quit: WeeChat 2.9)
18:31:57 Join ac_laptop [0] (~ac_laptop@
18:39:49fs-bluebot_Build Server message: Build round completed after 1370 seconds.
18:39:53fs-bluebot_Build Server message: Revision 8188588 result: All green
18:39:54fs-bluebot_Build Server message: New build round started. Revision d015165, 280 builds, 7 clients.
18:41:48***Saving seen data "./dancer.seen"
18:43:14speachyso it doesn't happen with hass only, or timestretch only?
18:44:35 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
18:46:07speachyI'm thinking this is a use-after-free situation −− something else is (incorrectly) freeing that handle id.
18:47:38 Quit _Bilgus_ (Remote host closed the connection)
18:49:00speachyhave you built this with buflib debug turned on?
18:50:12 Join __BILGUS [0] (41ba23be@
18:51:01__BILGUSspeachy no, I just figured out it wasnt only the xduoo and went back to the branch i'm working on
18:51:41__BILGUSit doesn't appear to happen with either alone and AFAICT its only in that order
18:52:50speachyand only if you're actively playing something
18:55:31fs-bluebot_Build Server message: Build round completed after 936 seconds.
18:55:32fs-bluebot_Build Server message: Revision d015165 result: All green
19:06:49 Quit ac_laptop (Ping timeout: 264 seconds)
19:20:12 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
19:21:08 Join fs-bluebot [0] (
19:23:04 Quit fs-bluebot_ (Ping timeout: 240 seconds)
19:23:28 Quit bluebrother^ (Ping timeout: 260 seconds)
19:44:22speachy__BILGUS: Did you intend to commit the VBAT ADC initialization changes?
19:44:53__BILGUSyes I have another patch in teh works taht will do it
19:45:32speachyok. I'm carrying a bunch of those changes locally, just checking to see if I should bother separating them into a commit
19:50:08speachyincluding an attempt to re-do the udelay()-on-hw-timer
19:50:33speachycurrently hanging on startup. :)
19:51:01 Quit t0mato (Quit: Ping timeout (120 seconds))
20:00:51 Join t0mato [0] (~t0mato@
20:05:52 Quit sakax (Quit: Leaving)
20:17:22speachyok, g#2738 is ready. hw udelay() on a dedicated timer peripheral
20:17:54speachyit overflows a bit under 22ms though
20:22:14speachyI don't think that's inherently a problem; nothing in the jz47xx family has a driver that uses long udelays.
20:26:15 Quit __BILGUS (Remote host closed the connection)
20:27:12fs-bluebotBuild Server message: New build round started. Revision 2dadb8c, 280 builds, 8 clients.
20:28:39 Join __Bilgus [0] (41ba23be@
20:35:46speachythe asm lcd bitdelay() function in the lcd code is 50ns at 600MHz. 62.5ns at our current 480mhz. 156ns at 192mhz.
20:36:56speachy(best case, assuming the branch doesn't incur a pipeline penalty)
20:37:39speachyso we could make the lcd code marginally faster if we wanted.
20:41:37 Quit MrZeus (Ping timeout: 264 seconds)
20:41:51***Saving seen data "./dancer.seen"
20:42:30speachymight be able to marginally speed up the USB code a bit too; there's a dcache flush that seems to be superfluous.
20:42:59__Bilguslcd code is plenty fast if anything it needs a slower clock
20:43:28speachygiven that it's bitbanging the faster we make it run the more time there is for something else to get done..
20:43:54fs-bluebotBuild Server message: Build round completed after 1002 seconds.
20:43:55fs-bluebotBuild Server message: Revision 2dadb8c result: All green
20:44:04__Bilgusitd be better to write combine I think
20:44:34__Bilgustriple buffer that too assuming ram to spare
20:45:41speachylet me know what you think about 2738. It seems to work properly for me, but I said that about the first two iterations. :)
20:48:49__BilgusI already think its much better I was quite pleased
20:50:09 Join ac_laptop [0] (~ac_laptop@
20:58:17 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
21:15:57 Quit livvy (Remote host closed the connection)
21:59:36 Quit cockroach (Quit: leaving)
22:07:31speachyok, I'll go and push it then
22:09:59fs-bluebotBuild Server message: New build round started. Revision 53142ae, 280 builds, 7 clients.
22:12:13 Quit ac_laptop (Ping timeout: 264 seconds)
22:27:32fs-bluebotBuild Server message: Build round completed after 1053 seconds.
22:27:33fs-bluebotBuild Server message: Revision 53142ae result: All green
22:29:16 Quit Lonoxmont (Ping timeout: 256 seconds)
22:30:22 Join Lonoxmont [0] (
22:41:52***Saving seen data "./dancer.seen"
22:52:46 Quit t0mato (Quit: Ping timeout (120 seconds))
23:09:47 Quit [7] (Ping timeout: 260 seconds)
23:10:15 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23:10:52 Join t0mato [0] (~t0mato@

Previous day | Next day