| 00:01:55 | *** | Saving seen data "./dancer.seen" |
| 00:19:16 | | Quit Romster (Ping timeout: 252 seconds) |
| 00:23:54 | | Join Romster [0] (~romster@user/romster) |
| 00:42:29 | | Quit advcomp2019 (Read error: Connection reset by peer) |
| 00:42:52 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 01:00 |
| 01:12:28 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:49c1:bcff:9db4:f4aa) |
| 02:00 |
| 02:01:59 | *** | Saving seen data "./dancer.seen" |
| 02:04:21 | | Quit lebellium (Quit: Leaving) |
| 02:27:31 | desowin | Coverity Scan reported 915 issues, to view click add me to project at https://scan.coverity.com/projects/rockbox |
| 02:32:10 | desowin | sorting by impact, CID#353480 is real file handle leak when load_voicefile_index() returns false when file does exist but has malformed header, the fd is never closed |
| 04:00 |
| 04:02:03 | *** | Saving seen data "./dancer.seen" |
| 04:12:23 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 04:15:24 | | Quit advcomp2019 (Ping timeout: 252 seconds) |
| 04:27:20 | | Quit ufdm (Read error: Connection reset by peer) |
| 04:27:28 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 04:35:31 | | Quit Romster (Ping timeout: 268 seconds) |
| 04:37:12 | | Join Romster [0] (~romster@user/romster) |
| 04:41:52 | | Join bittin [0] (~bittin@user/bittin) |
| 04:41:58 | bittin | https://www.youtube.com/watch?v=HJDY1FXuJPQ some Rockbox love on Youtube |
| 05:00 |
| 05:35:36 | | Part bittin (Leaving) |
| 05:55:05 | | Quit ufdm (Read error: Connection reset by peer) |
| 05:55:17 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 06:00 |
| 06:02:05 | *** | Saving seen data "./dancer.seen" |
| 06:09:00 | | Quit ufdm (Read error: Connection reset by peer) |
| 06:52:24 | speachy | _bilgus: no, because when path is null pathsize is 0, so the memcpy() does nothing. |
| 06:54:02 | speachy | Going to the URL you mentioned it claims no builds were succsssfully analyzed.. don't have a way of looking at that report. |
| 07:00 |
| 07:03:04 | speachy | (didn't get an invite email either, FWIW) |
| 07:03:16 | speachy | desowin: ^^ |
| 07:10:32 | speachy | but if the most severe issue is a fd leak, then we're doing better than I'd expected. |
| 07:33:31 | speachy | (a leak in a called-once-at-startup error path!) |
| 07:37:55 | desowin | there are a bunch of out of bounds accesses... |
| 07:39:29 | Arsen | I suspect such a bug is behind what I'm debugging |
| 07:39:55 | Arsen | I may try to afford a USB sniffer to look into this further, as I said, but I'm not sure how viable that is, since as a student I have no income at all |
| 07:40:25 | desowin | if you study computer science, check if your faculty has one |
| 07:42:33 | desowin | when I was student, there was Ellisys USB Explorer 200 that I could access |
| 07:42:40 | Arsen | I will when I go back there, I finished up my work for this year and I'm with my parents rn |
| 07:43:13 | Arsen | there's two unis in near proximity to me so I'll try on both, I know EE and CE students on both too |
| 07:47:25 | speachy | there's a bunch of USB 2.0 LeCroy Conquest units on ebay right now, but they're still $500ish. |
| 07:50:36 | desowin | OpenVizsla is probably the cheapest, with fairly good Wireshark support (of course, my opinion is biased as I wrote the dissector and ovextcap) |
| 07:51:47 | desowin | for students, university equipment would be most affordable |
| 07:53:44 | gevaerts | Back in the very early days of my work on rockbox I happened to have a CATC (now LeCroy) box on my desk at work. It did help a lot... |
| 07:57:06 | speachy | A couple years back I picked up an ITI1480A unit for a specific debug task, and it paid for itself by pointing the finger squarely away from me. :D |
| 07:58:04 | speachy | I was disappointed that their attempt to crowdfund a USB3.0 version of it failed miserably... |
| 07:58:48 | gevaerts | We (rockbox) do own a https://www.mqp.com/usb480.htm but (a) I don't know who has it currently (maybe pamaury?) and (b) it's not great, but if we find it it could be sent over to whoever needs it |
| 07:59:40 | speachy | huh, did not know that |
| 08:00 |
| 08:02:08 | *** | Saving seen data "./dancer.seen" |
| 08:06:16 | speachy | I have an openvizla board here; if I can get it to work I'll donate it to the rockbox cause. |
| 08:07:32 | desowin | is the ftdi programmed with OpenVizsla VID/PID or defaults? |
| 08:08:04 | desowin | because well, if it's programmed then it is trivial to get it running nowadays |
| 08:08:27 | desowin | (if not, then it's not a big deal unless there are still some soldering issues) |
| 08:09:20 | speachy | I think it's the latter, actually. that's why I got it for so cheap. |
| 08:09:49 | desowin | quick way to tell is to plug it and check how it enumerates (if at all) |
| 08:09:49 | speachy | I didn't have the time to debug it at the time but I still have it (and a second bare PCB) |
| 08:10:32 | desowin | when my colleague at work assembled one manually, the FTDI and RAM chips had to be resoldered |
| 08:10:41 | speachy | doesn't appear to enumerate at all. |
| 08:10:59 | speachy | (got it five years ago, so..) |
| 08:11:19 | desowin | suprisingly the USB transceiver got soldered correctly first try |
| 08:12:38 | desowin | silly question, but you plug it with the connector on the side where there's just one connector (to capture host)? |
| 08:13:28 | speachy | yes. the second time. :D |
| 08:14:10 | speachy | could also be the cable. one of my cats has this annoying habit of chewing on cables when I don't pay attention to her. |
| 08:15:05 | speachy | I'll take it into the lab at work and try to probe the FTDI chip during any downtime |
| 08:16:29 | speachy | aaand on that note, time to scoot. |
| 08:16:33 | * | speachy waves. |
| 08:16:36 | | Quit speachy (Quit: WeeChat 3.0.1) |
| 08:42:42 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 08:48:57 | | Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 09:00 |
| 09:14:24 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 09:47:26 | | Join Telehubis [0] (~Telehubis@dynamic-78-10-123-181.ssp.dialog.net.pl) |
| 09:56:05 | Telehubis | I managed to compile the code (what an achievement! ;- ) ). Searched for Shanling Q1 bootloader that Im after but in the bootloader its not there. Do I use a wrong complier? (used ARM) |
| 10:00 |
| 10:02:09 | *** | Saving seen data "./dancer.seen" |
| 10:02:19 | | Quit Telehubis (Quit: Connection closed) |
| 10:19:49 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 10:21:13 | amachronic | Telehubis: you need a MIPS compiler. in configure pick the Q1 and then 'b' for bootloader |
| 10:24:45 | | Join Telehubis [0] (~Telehubis@dynamic-78-10-123-181.ssp.dialog.net.pl) |
| 10:26:40 | Telehubis | amachronic: dang, I think MIPS is currently not building under WIndows... (thats the info I found on compile Rockbox page)... Then need to wait untill it will be available :- ) |
| 10:31:38 | amachronic | if ARM builds then MIPS should.... Did you try compiling it? (Also you need to use the MIPS native toolchain, not hosted.) |
| 10:32:37 | | Quit massiveH (Quit: Leaving) |
| 10:32:57 | rb-bluebot | Build Server message: New build round started. Revision 6f042e91dd, 303 builds, 8 clients. |
| 10:40:12 | amachronic | Telehubis: that statement on the wiki is 2 years old for no reason I can find so idk, maybe it's no longer applicable. |
| 10:42:19 | amachronic | I can give you a bootloader later today −− I'm happy to release it as-is, just let me merge g#3589 first |
| 10:42:21 | rb-bluebot | Gerrit review #3589 at https://gerrit.rockbox.org/r/c/rockbox/+/3589 : jztool: add support for Shanling Q1 and Eros Q by Aidan MacDonald |
| 10:42:58 | Telehubis | amachronic: thanks! |
| 10:43:42 | munkis | is there any easy way to tell which build a builder last participated in? |
| 10:45:17 | rb-bluebot | Build Server message: Build round completed after 740 seconds. |
| 10:45:19 | rb-bluebot | Build Server message: Revision 6f042e91dd result: All green |
| 10:45:34 | munkis | just noticed that uzziyah isn't building and am trying to figureout why. |
| 10:56:59 | rb-bluebot | Build Server message: New build round started. Revision 740a50687f, 303 builds, 8 clients. |
| 11:00 |
| 11:02:55 | | Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 11:03:08 | | Quit munkis (Ping timeout: 252 seconds) |
| 11:03:10 | | Nick mendel_munkis is now known as munkis (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 11:10:03 | rb-bluebot | Build Server message: Build round completed after 783 seconds. |
| 11:10:05 | rb-bluebot | Build Server message: Revision 740a50687f result: All green |
| 11:11:46 | spork | speachy: the old dev builds page without all the voice files is a but more readable |
| 11:21:17 | | Quit Ckat (Ping timeout: 268 seconds) |
| 11:21:56 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 11:25:30 | | Quit munkis (Ping timeout: 240 seconds) |
| 11:26:56 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 11:41:42 | _bilgus | g#3593 now has the other issues fixed it compiles but I havent tested it |
| 11:41:45 | rb-bluebot | Gerrit review #3593 at https://gerrit.rockbox.org/r/c/rockbox/+/3593 : talk.c check for 0 talk clips file descriptor leaks & announce_status fix typo by William Wilgus |
| 11:42:23 | _bilgus | desowin, thanks |
| 11:45:32 | amachronic | bilgus, do you remember the reason for this stack business in battery bench? g#2625 |
| 11:45:34 | rb-bluebot | Gerrit review #2625 at https://gerrit.rockbox.org/r/c/rockbox/+/2625 : Battery_Bench use plugin buffer for thread stack, stop scrolling by William Wilgus |
| 11:46:01 | amachronic | i got a stkov battery bench after a while when I tried running it on the q1 |
| 11:46:29 | amachronic | gonna try reverting back to the static stack because I found this huge stack created a weird problem on the debug screen |
| 11:46:43 | amachronic | but i am guessing there is some other bug afoot too |
| 11:48:03 | _bilgus | wanna say it was the fuze+ that was creating dumps that were ovfl the stack rather than keep increasing it I just made it take over the plugin buffer |
| 11:51:10 | _bilgus | that plugin is TSR so its likely some weird context switch or a race |
| 11:52:00 | _bilgus | wouldn't rule out others either, next thing would be is it just lasting too long and ovfl the run buffer? |
| 11:52:16 | amachronic | okay I'll have to figure out the cause it because stkov with a 2mb stack definitely can't happen. |
| 11:52:54 | _bilgus | It probably needs logic to dump when the buffer is full IIRC it doesnt have that |
| 11:53:36 | amachronic | when i tried seeing the stack usage it caused audio to massively drop out |
| 11:53:54 | amachronic | it turns out we check stack usage by scanning the entire stack with IRQs disabled |
| 11:54:07 | _bilgus | that might be because it uses a sentinel |
| 11:54:37 | _bilgus | figure you are reading the whole buffer for the picket fence |
| 11:54:44 | amachronic | yeah |
| 11:55:01 | amachronic | the usage is so small it shows up as 0% though so I doubt the stkov is genuine |
| 11:55:20 | _bilgus | so better idea is probably limit that to something reasonable with a max_stack too |
| 11:58:23 | _bilgus | might also double check my logic here gThread.stack = (long *) buf + buf_size; /* stack grows towards *buf |
| 11:58:37 | _bilgus | L659 |
| 11:58:57 | _bilgus | wouldn't be the first time I assumed wrong on stack direction |
| 12:00 |
| 12:02:11 | *** | Saving seen data "./dancer.seen" |
| 12:04:02 | amachronic | it's correct, the kernel wants the top of the stack / lowest address |
| 12:04:39 | amachronic | random aside: we're not aligning our stacks on MIPS to 8 bytes. |
| 12:05:05 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 12:05:41 | amachronic | i wonder, does GCC follow the sysv ABI and could this cause any problpems? |
| 12:05:43 | Telehubis | amachronic: to be honest after few tries I think I also need to wait for jztool support for Q1 ;- ) |
| 12:07:03 | amachronic | Telehubis: i've commited it but I haven't made builds or tested on windows yet |
| 12:07:30 | _bilgus | amachronic, I've run into a lot of alignment problems but usually its ARM |
| 12:09:22 | Telehubis | amachronic: sure. I just dont have exp. in Linux. Maybe its also bacause I run "Unix subsystem" dont know... |
| 12:14:11 | amachronic | stkov panic happens only if something writes to the very top of the stack |
| 12:14:41 | amachronic | so something must be written out of bounds right beyond the end of the plugin |
| 12:17:59 | amachronic | hmm, it seems rockbox already has some gdb stub for ARM. Maybe I should add one for mips. |
| 12:18:45 | amachronic | has anybody used gdb stub in recent times or is it bitrotted / unreliable? |
| 12:23:21 | _bilgus | assume latter lol |
| 12:23:57 | amachronic | it got added 2006 and not touched since :( |
| 12:24:32 | amachronic | maybe i can do a quick hack to dump pc when something touches that memory |
| 12:24:39 | amachronic | / |
| 12:27:30 | braewoods | _bilgus: question for you. i acquired a rare hd300 and there's no official battery but it does appear to be socketed. any ideas how i can find a compatible replacement, socket wise? i assume i'd need to take measurements of the socket or so |
| 12:31:43 | _bilgus | might get lucky, ive made my own with various connectors even hand made copper ones used white kneed-able epoxy to encapsulate the connectors it even still plugs / unplug with proper prep/masking |
| 12:32:54 | _bilgus | other than that look through digikey or even EDA libraries thats how I found the pheonix connector spacing |
| 12:33:58 | | Quit Telehubis (Quit: Connection closed) |
| 12:33:59 | braewoods | i was thinking of using caliper |
| 12:34:01 | braewoods | calipers |
| 12:34:17 | braewoods | in any case for now it's a future problem |
| 12:34:32 | braewoods | the old battery looks like this, from the wiki |
| 12:34:37 | braewoods | https://www.rockbox.org/wiki/pub/Main/InsideMPIOHD300/7.jpg |
| 12:35:07 | braewoods | it's a little weird in that it connects from the top not the side |
| 12:35:44 | _bilgus | problem is w/o the original you don't know how the protect circuit works |
| 12:35:49 | _bilgus | assum an ntc |
| 12:36:01 | braewoods | it has none afaik. it's just 2 pin. |
| 12:36:09 | _bilgus | if it works w/o it thats status quo it seems |
| 12:36:48 | braewoods | very slow charging right now |
| 12:36:49 | _bilgus | so you are just constrained by the l/w/h of the pack you can buy all day long |
| 12:37:04 | braewoods | yea i'll look into it |
| 12:37:18 | _bilgus | I usually look through cell phone boxes |
| 13:00 |
| 13:04:03 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:3109:34d3:47a1:1c02) |
| 13:34:11 | braewoods | _bilgus: what's the typical cut off voltage for rockbox targets? i've seen some lithium can go to around 3V but devices are free to cut out sooner |
| 13:34:45 | braewoods | i assume they want to be > 3.3V so they can use a buck converter or so |
| 13:34:58 | braewoods | since a lot of electronics use 3.3V internally |
| 13:41:15 | | Quit amachronic (Quit: amachronic) |
| 14:00 |
| 14:02:12 | *** | Saving seen data "./dancer.seen" |
| 14:09:35 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 14:12:55 | amachronic | i think I found the reason for the stkov panic |
| 14:13:37 | amachronic | various bits of the core call plugin_get_buffer(), like the playlist viewer |
| 14:14:27 | amachronic | i managed to reproduce reliably by running battery bench & then removing a song from the current playlist |
| 14:23:12 | | Quit emacsomancer (Ping timeout: 268 seconds) |
| 14:26:15 | | Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 14:26:29 | | Quit munkis (Remote host closed the connection) |
| 14:35:37 | | Join emacsomancer [0] (~emacsoman@c-174-52-88-123.hsd1.ut.comcast.net) |
| 14:37:22 | amachronic | fixed battery bench: g#3597 |
| 14:37:24 | rb-bluebot | Gerrit review #3597 at https://gerrit.rockbox.org/r/c/rockbox/+/3597 : Fix battery_bench bug by using a static buffer for stack by Aidan MacDonald |
| 14:38:19 | amachronic | it looks like announce_status is the only other TSR plugin and it has the same problem, but it uses the plugin buffer for more than just stack |
| 14:40:25 | amachronic | the only other way this could happen is if a function in the plugin API indirectly causes a double-allocation of the plugin buffer, but I haven't checked that yet. |
| 14:41:21 | | Join yang [0] (~yang@user/yang) |
| 15:00 |
| 15:01:26 | | Quit amachronic (Ping timeout: 268 seconds) |
| 15:01:48 | | Quit emacsomancer (Ping timeout: 255 seconds) |
| 15:31:50 | | Join emacsomancer [0] (~emacsoman@136.60.143.85) |
| 15:37:01 | | Quit emacsomancer (Quit: WeeChat 3.2) |
| 15:38:11 | | Join emacsomancer [0] (~emacsoman@136.60.143.85) |
| 15:38:16 | braewoods | _bilgus: at least i was able to find the dimensions by looking up the battery part #. |
| 15:38:32 | braewoods | i'll see what i find later |
| 15:38:44 | braewoods | first i want to confirm it still even powers on with the current battery |
| 15:38:56 | braewoods | very slow charging in any case |
| 15:57:12 | | Quit emacsomancer (Ping timeout: 245 seconds) |
| 15:57:40 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 16:00 |
| 16:02:15 | *** | Saving seen data "./dancer.seen" |
| 16:10:42 | braewoods | well this is one weird player |
| 16:10:49 | braewoods | i thought the input was busted |
| 16:11:03 | braewoods | turns out, half of it pressure activated and the rest is touch |
| 16:20:56 | _bilgus | amachronic, oh that is not great.. |
| 16:21:20 | _bilgus | the plugin buffer is taken over even with that static buffer |
| 16:21:49 | _bilgus | it just so happens you aren't taking enough to hit the bug |
| 16:22:08 | amachronic | really? how does that happen? |
| 16:22:11 | braewoods | _bilgus: what's the issue? a conflict between who owns the plugin buffer? |
| 16:22:33 | braewoods | i thought the plugin buffer was off limits to anything other than plugins |
| 16:22:59 | _bilgus | well except in the case of those TSRs you wouldn't normally notice |
| 16:23:36 | braewoods | and the benchmark is a background program? |
| 16:23:52 | _bilgus | I'll have to look but what can possibly happen is we could make get_plugin_buffer a bit smarter |
| 16:24:06 | braewoods | sounds like we need a way to move them to a dedicated memory region |
| 16:24:15 | _bilgus | yeah battery bench and my announce plugin are TSR |
| 16:24:34 | braewoods | why aren't they in rockbox core then? that would probably solve the issue |
| 16:25:09 | braewoods | i was under the impression the plugins all exitted when they close |
| 16:25:12 | braewoods | i guess not |
| 16:25:17 | amachronic | if it helps, i've converted announce_status to avoid the plugin buffer too |
| 16:25:34 | amachronic | but if the plugin buffer is used anyway... |
| 16:25:56 | _bilgus | I'd rather get rid of those core uses of the plugin buffer and either make the users plugins or push them into core_alloc or some hybrid |
| 16:26:01 | | Join emacsomancer [0] (~emacsoman@136.60.128.68) |
| 16:26:28 | amachronic | it should be safe as long as two threads don't use the plugin buffer at the same time |
| 16:26:35 | _bilgus | yeah plugins get copied into the plugin_buf then remaining is allowed for our use |
| 16:26:46 | amachronic | which we can detect by adding a 'free_plugin_buffer' API |
| 16:27:01 | amachronic | so if somebody tries to get_plugin_buffer before freeing it we panic |
| 16:27:04 | braewoods | we need a real solution, not some hack for the handful of TSRs currently existing. what if we want to add more later? |
| 16:27:13 | amachronic | this is not a TSR issue. |
| 16:27:18 | braewoods | oh? |
| 16:27:29 | amachronic | tsr just exposes it. |
| 16:27:41 | _bilgus | ^ |
| 16:27:59 | braewoods | so what do we need? a way to shrink the plugin buffer area when a TSR is run? |
| 16:28:00 | amachronic | if a plugin API indirectly calls some function which uses the plugin buffer this could affect many more plugins. |
| 16:28:13 | amachronic | malloc() ;) |
| 16:28:20 | _bilgus | well I think itd be ok just to mark it as in use |
| 16:28:26 | braewoods | i could emulate malloc on top of core_alloc |
| 16:28:34 | amachronic | more seriously I do not think we need malloc or change to core_alloc. |
| 16:28:44 | braewoods | but yea, more overhead |
| 16:29:16 | | Quit emacsomancer (Read error: Connection reset by peer) |
| 16:30:07 | _bilgus | I'll have a look in core see just how much abuse we are talking but likely this has been happening for a long while we just get lucky |
| 16:31:13 | amachronic | i'd assume most uses are safe since battery_bench and announce_tsatus bugs are recent changes |
| 16:32:15 | _bilgus | bat bench is old |
| 16:32:25 | amachronic | g#3599 |
| 16:32:27 | rb-bluebot | Gerrit review #3599 at https://gerrit.rockbox.org/r/c/rockbox/+/3599 : Fix announce_status usage of plugin buffer by Aidan MacDonald |
| 16:33:00 | amachronic | bat bench is old, but prior to your change it used a static stack so it was unaffected |
| 16:33:10 | _bilgus | won't hurt |
| 16:33:33 | _bilgus | no that static stack resides in the plugin buffer |
| 16:33:55 | _bilgus | have a loop at how load plugin works in plugin.c |
| 16:33:58 | _bilgus | look* |
| 16:33:58 | amachronic | yeah but get_plugin_buffer accounts for the size of the binary |
| 16:34:15 | amachronic | so if you use a static buffer it's skipped over and you get the unallocated part |
| 16:34:28 | _bilgus | should when you call get_plugin_buffer as well I think |
| 16:35:03 | _bilgus | other thing might be someone abusing that alloc too |
| 16:37:07 | _bilgus | no you are indeed right it wouldn't store the state and it just returns the whole remaining |
| 16:37:55 | | Join _amachronic [0] (~amachroni@user/amachronic) |
| 16:39:03 | _bilgus | so really there is no tracking of in use and it will continually return the remaining buffer |
| 16:39:17 | _bilgus | ick |
| 16:40:29 | | Quit amachronic (Read error: Connection reset by peer) |
| 16:43:46 | _bilgus | braewoods, usually each target has a table for showing the battery remaining but charging setpoints are usually hardwired except a few targets where you can set them |
| 16:44:27 | _bilgus | the clip+ and zip have several settings for trigger points and rate of charge IIRC |
| 16:50:58 | | Quit lebellium (Quit: Leaving) |
| 16:51:44 | | Quit reductum (Quit: WeeChat 2.8) |
| 16:56:40 | | Quit mendel_munkis (Remote host closed the connection) |
| 16:57:04 | | Join mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 17:00 |
| 17:16:55 | _amachronic | Telehubis: q1 bootloader build is here: https://drive.google.com/drive/folders/1F4OhAVqKPcp879CykFCN5WL9ncYfPrvm |
| 17:19:26 | _amachronic | speachy: ^^^ i've updated jztool and added the q1 bootloader, the m3k bootloader is unchanged. add those to d.r.o whenever you like, thanks. |
| 17:24:45 | | Join emacsomancer [0] (~emacsoman@136.60.128.68) |
| 17:40:40 | | Join speachy [0] (~speachy@209.2.65.77) |
| 17:40:40 | | Quit speachy (Changing host) |
| 17:40:40 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 17:40:40 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 17:51:45 | | Quit _amachronic (Quit: _amachronic) |
| 17:52:45 | | Quit emacsomancer (Quit: WeeChat 3.2) |
| 17:53:50 | | Join emacsomancer [0] (~emacsoman@136.60.128.68) |
| 18:00 |
| 18:02:19 | *** | Saving seen data "./dancer.seen" |
| 18:12:57 | | Join reductum [0] (~reductum@2603-8000-b400-8764-dea6-32ff-fe16-a622.res6.spectrum.com) |
| 18:35:05 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 18:54:38 | | Quit cockroach (Ping timeout: 255 seconds) |
| 18:54:52 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 19:00 |
| 19:19:25 | | Join Riviera [0] (Riviera@user/riviera) |
| 19:24:41 | braewoods | _bilgus: in any case, i'm going to have to replace it now. i broke the old ones terminals. lol |
| 19:25:01 | braewoods | while i'm at it i may as well see if i can reliably trigger the failsafe |
| 19:25:14 | rb-bluebot | Build Server message: New build round started. Revision 966e210e6d, 303 builds, 8 clients. |
| 19:25:22 | braewoods | i want to investigate the possibility of releasing an updated bootloader |
| 19:25:56 | braewoods | coldfire ports all have a failsafe that boots the OF |
| 19:26:04 | braewoods | but it can be tricky to trigger it |
| 19:32:34 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:36:17 | rb-bluebot | Build Server message: Build round completed after 663 seconds. |
| 19:36:19 | rb-bluebot | Build Server message: Revision 966e210e6d result: All green |
| 19:36:22 | rb-bluebot | Build Server message: New build round started. Revision b91ad60d63, 303 builds, 7 clients. |
| 19:36:29 | | Quit cockroach (Quit: leaving) |
| 19:36:49 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 19:49:05 | rb-bluebot | Build Server message: Build round completed after 763 seconds. |
| 19:49:07 | rb-bluebot | Build Server message: Revision b91ad60d63 result: All green |
| 20:00 |
| 20:02:21 | *** | Saving seen data "./dancer.seen" |
| 20:48:46 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:00 |
| 21:15:53 | | Quit Piece_Maker (Ping timeout: 258 seconds) |
| 21:17:29 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 22:00 |
| 22:02:23 | *** | Saving seen data "./dancer.seen" |
| 22:26:24 | | Quit cockroach (Quit: leaving) |
| 22:41:22 | speachy | I'm re-running the analyzer using the X3ii's sim build; it'll pull in the full set of (simmable) plugins and have full color, which ought to flag many more issues. |
| 22:51:19 | speachy | https://www.shaftnet.org/~pizza/scan-build-223915 |
| 23:00 |
| 23:12:52 | braewoods | wow. i'd have never guessed reading bits was this slow. |
| 23:25:10 | | Quit Airwave (Quit: WeeChat 2.3) |
| 23:33:00 | | Quit mendel_munkis (Ping timeout: 255 seconds) |
| 23:54:43 | | Quit dconrad (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).