--- Log for 12.04.121 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 17 days and 10 hours ago 00.08.08 *** Saving seen data "./dancer.seen" 00.20.26 Quit kadoban (*.net *.split) 00.20.26 Quit edhelas (*.net *.split) 00.20.26 Quit michaelni (*.net *.split) 00.20.26 Quit shrizza (*.net *.split) 00.26.48 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 00.26.48 Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) 00.41.24 Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-zvjltlxvjsvasrie) 01.21.08 Quit copper (Ping timeout: 252 seconds) 01.21.15 Join copper [0] (~copper@unaffiliated/copper) 01.26.38 Quit ac_laptop (Ping timeout: 268 seconds) 02.08.12 *** Saving seen data "./dancer.seen" 02.36.25 # speachy: i see. well it'd help if we had one... 02.39.58 Join Rower- [0] (~Rower@84.17.55.53) 02.42.18 Quit Rower (Ping timeout: 240 seconds) 02.49.02 # i suspect we're not going to be testing either mpio port 02.54.13 # gevaerts: you got any of the harder to find targets in your collection? mpio hd200, hd300? iriver H110 or H115? 02.54.37 # if you do, repairing those may be our best option for testing them 02.54.53 # or for that matter either of the m:robe ports, 100 or 500 03.05.10 Quit S|h|a|w|n (Read error: Connection reset by peer) 03.32.44 Join TheSphinX_ [0] (~briehl@srv001.nosupamu.de) 03.33.43 Quit TheSphinX^ (Ping timeout: 260 seconds) 03.33.43 Nick TheSphinX_ is now known as TheSphinX^ (~briehl@srv001.nosupamu.de) 03.59.04 Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) 04.08.13 *** Saving seen data "./dancer.seen" 04.10.58 # braewoods: I have the m:robes (assuming their batteries haven't effectively killed them). What exactly do we need tested? 04.17.15 # gevaerts: speachy wanted to test that our builds are working basically 04.17.25 # it appears someone tested the 100 already 04.17.38 # the 500 is having issues they say 04.17.57 # so we'd need a unit to find out what the issue is 04.19.43 # Someone else has a working 500 still? :) 04.20.07 # apparently 04.20.13 # they are available on ebay 04.20.15 # but 04.20.21 # why do we want to pay $80 just to test this? 04.20.37 # especially one that doesn't appear to have many users 04.20.57 # I mean, I have one here. I'll start by seeing if it still boots before thinking about testing 04.21.03 # ok 04.21.09 # you live in Europe if I recall? 04.21.13 # yes 04.21.16 # ok... 04.21.34 # it'd be nice if we had someone with time in Europe to troubleshoot it 04.21.37 # :) 04.21.46 # assuming it even still works well enough to test 04.22.11 # but i was surprised to see how big the m:robe 500 is 04.22.18 # it looks like a modern tablet 04.22.20 # It's a weird device 04.23.02 # is it touch screen only? 04.23.26 # It is 04.23.31 # i thought so 04.23.47 # how'd we ever manage to support it? i thought we didn't work well with TS 04.24.11 # It never got out of "unstable" 04.24.30 # i see 04.24.35 # weird in any case 04.26.28 # i guess speachy mainly wants to ensure no serious regressions 04.26.36 # ok, the build that's on there still works 04.26.44 # That's a start 04.27.09 # ok i'd get in touch with speachy then, since i think he's in a better position to debug it 04.27.43 # i just wish we could find the rare H110 or H115 04.27.51 # to test the new bootloader and such 04.27.55 # it should work since it works in the H120+ 04.27.57 # but 04.28.06 # Yes, those are the dangerous ones... 04.28.18 # the rare units? 04.28.44 # Well, those flashed bootloader ones without easy recovery 04.29.02 # i actually found one but maybe just luck 04.29.26 # it only works if the OF is still present and you have an original HDD installed 04.29.41 # i used it to save my bacon when i was debuggin the H320 bootloader 04.29.58 # thank you whoever wrote the reset cookie to try to boot the OF if boot hang occurred 04.31.49 # gevaerts: you can update your H120s and H320s if you want. the latest bootloader has been out for awhile and works. 04.32.04 # it fixes CF compatibility. 04.34.04 # ok, I can confirm that the current build doesn't boot on mr500 04.34.39 # ok 04.34.51 # speachy can troubleshoot the rest 04.35.04 # first thing we should check is if the problem is similar to the gigabeat S one we patched 04.35.09 # I'll try to bisect soon 04.35.21 # try from before the toolchain last year 04.35.29 # then if it boots check the stack usage of threads 04.35.46 # the gigabeat S failed to boot because of stack overflow 04.35.54 # may as well check it here just to be sure 04.35.57 # it's easy to check if you can boot 04.35.59 Join vmx [0] (~vmx@ip5f5ac633.dynamic.kabel-deutschland.de) 04.36.47 # it's likely either a toolchain issue, lcd issue, or both 04.39.52 # Oh, right... toolchains were bumped "recently", right? 04.40.55 # yes 04.41.04 # bilgus also redid LCDs which broke some stuff 04.41.16 # hard to say which is at fault here 04.41.39 # around october is when these hit 04.41.43 # of last year 04.41.48 # I think I'll try the current revision with old gcc to start witj 04.41.56 # that's not advisable 04.42.05 # we started using new GCC features 04.42.11 # I'll see :) 04.42.20 # i presume it'll fail 04.42.24 # but ok 04.42.38 # I mean, it depends on where the failures are 04.42.41 # you can also try dialing back optimizations 04.42.51 # the gigabeat S worked on -O1 but not -Os 04.43.05 # Well, I don't have the new gcc yet, so might as well try this first before upgrading that 04.43.08 # indeed it does 04.43.17 # i'd start from a revision before GCC bump 04.43.22 # just to be sure that works 04.43.31 # the build you had is probably really old 04.43.57 # the gigabeat S fix is in a device-specific thread stack, so that fix isn't copyable 04.44.03 # i know 04.44.08 # but it could be a similar problem here 04.44.21 # but no way to know until you start finding out where it first broke 04.45.16 # oh, right, the reset pin on this thing needs opening the case... 04.45.36 # ... wow that's stupid 04.45.47 # depending on where it was 04.45.54 # i might just drill a hole in the case to acces it 04.45.56 # X) 04.46.55 # worth considering :) 04.47.51 # yea if i was developing fori t 04.48.03 # i'd consider it if the reset thing was easy to access 04.48.17 # might install a button just to short the pins when i need to reset 04.49.15 # Or didn't it have one? Oh well, it's open, I can disconnect the battery :) 04.51.12 # Yes, running 7f4c696-120226... That's not a new build exactly :) 04.58.14 # _bilgus: it seems like the fixes you applied boosted the H10's write speed by about 50% 04.58.16 # weird 04.59.31 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 04.59.49 # i was getting like 5MB/s 04.59.52 # now it's like 7.5MB 05.00.05 Quit ccf-100 (Quit: Idle for 30+ days) 05.57.40 # <_bilgus> braewoods, thats a pretty good boost 06.08.17 *** Saving seen data "./dancer.seen" 06.12.23 Quit Acou_Bass (Ping timeout: 260 seconds) 06.21.30 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 06.32.54 # Looking for boot-breaking bugs does have the advantage that testing doesn't take too much time :) 06.42.37 # gevaerts: it's the only tms320 target that even made it to the "unstable" list, with daily builds and everything. 06.44.25 # It's debatable whether or not it's worth even trying to fix this but if not, there's a pile of other targets that are equally undeserving 06.44.41 # I should have a breaking revision soon. It's definitely from before the gcc update 06.45.21 # It's probably worth having a look at, but given its unstable status it shouldn't be a factor for a release decision 06.45.59 # well, it's obviously been the first report of anyone using a build less than a year old on this thing. 06.48.59 # all known issues so far are on unstable targets, or aren't regressions (eg the SSD issues on the ipods) 06.49.46 # speaking of which, seems the ipod6g still has SSD issues. probably because it has its own ATA driver and also powers down the ATA hardware/interface. 06.51.29 # Hmmm 06.54.01 # Oh, bah. I wish we'd looked earlier... 06.54.05 # I found https://www.rockbox.org/irc/log-20200512#20:03:06 again :) 06.55.17 # That concludes that the new toolchain doesn't have the problem I think? 06.56.08 # speachy: you may remember that better. I'm a bit confused after reading those logs 06.56.13 # I suppose so. But I obviously completely forgot about that too 06.56.32 # must have been from when I still had both toolchains sitting around 06.56.59 # But the report is that the current build doesn't work, so it presumably broke again after that? 06.57.22 # so that seems like some sort of linking problem 06.58.01 # Well, time to upgrade toolchains then :) 06.58.39 # the problematic commit was never reverted. 06.59.25 # (and that also explains the provenence of that build cereal_eater was using. it's something I built for him..) 06.59.46 # No, but the toolchain was upgraded, so if that fixed it the first time either something was shuffled again to break things the annoying way, or something else broke 07.02.27 # * speachy nods. 07.03.46 # re-reading this log makes me wonder if the -1 build I supplied (new toolchain, then-git master) was actually booted up. 07.04.49 # it may seem weird but i build my test builds on a server with ECC RAM 07.04.57 # i'm a bit paranoid about consistency 07.05.00 # with this kind of stuff 07.12.03 # on my systems with ECC, I average less than one detected error a year 07.13.19 # I suspect most of our builders aren't equipped with ECC. Though 2 of my 3 are. 07.13.25 # (and the main server) 07.13.58 # I take that back, all 3 are; the third is unbuffered ECC. 07.16.27 # unlikely but i like it 07.16.55 # i personally don't want to chase a phantom issue that was due to a flipped bit or something 07.18.08 # speachy: you know what i find funny on ebay? 07.18.26 # people selling stuff at inflated prices and then seeing that for the most part only the modestly priced ones sell 07.18.40 # do they not care about holding inventory indefinitely? 07.18.51 # * braewoods boggles 07.19.34 # depends on how much they paid for it. and, especially after a certian point, if you need something specific, you're going to NEED it at any price. 07.20.54 # i see these old Dell mp3 players 07.20.56 # 20GB 07.21.07 # probably some PP derivative 07.23.26 Part edhelas 07.23.34 # interesting 07.23.40 # they still provide the OF 07.23.43 # let's check the firmware 07.24.14 Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) 07.27.26 # oh 07.27.30 # not a set of files... 07.27.34 # some flash program? 07.33.14 # interesting 07.33.28 # seems someone already did research on it 07.35.24 # possible port here but probably not worth it at this point 07.53.42 # speachy: if I revert b0de98ad and build current master it boots, so still the same issue. I have no idea why there was a working build in that debug session last year... 07.53.56 # (with a fresh toolchain) 07.54.54 # https://www.ebay.com/itm/SmartDisk-FlashTrax-Gray-20-GB-Digital-Media-Player-Lightly-used/373279744026 07.54.59 # the gba sp of mp3 players 07.56.47 # gevaerts: sounds like we need a port specific workaround 07.56.55 # since nothing else seems to be bothered by it 07.56.55 # Maybe 07.57.30 # reminds me of when i was debugging H320 bootloader 07.57.39 # it was an LCD optimization that broke it 07.58.09 # since i'm not an expert on the port i ended up reintroducing the original code but only enabled for bootloader builds 07.58.26 # since i didn't know how else to fix it 08.08.21 *** Saving seen data "./dancer.seen" 08.08.35 Quit pamaury (Ping timeout: 260 seconds) 08.09.09 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.14.31 # https://paste.debian.net/1193318/ fixes the issue for me, while still having working thumb builds (which is what b0de98ad fixed). The effect is that -lfirmware is now in the link cmdline twice 08.14.53 # Of course all of this is magic, so I don't know if it breaks anything else now... 08.15.11 # hmm, I never did like that thumb-cc hack 08.16.13 # My worry isn't thumb so much as knowing that link order broke the mr500 so I'm not sure changing link order again won't break something else 08.16.44 # as Isaid in that earlier log all of this is a canary.. the RealProblem(tm) is something else 08.16.53 # Indeed 08.17.13 # maybe some sort of symbol collision 08.17.28 # so the ordering of linked libraries matters 08.19.11 # speachy: is it time to move our python scripts to 3? 08.19.26 # python2 is being phased out 08.19.29 # everything in the normal build path is python3 clean 08.19.48 # i see 08.19.50 # I retired server-side python2-specific stuff 08.20.02 # ok 08.20.21 # seems my H10 got scratched somehow during shipment or w/e 08.20.25 # weird 08.20.31 # i'll try buffing it out of the metal 08.26.58 # huh, we only use that thumb script on the original clip, m200v4 and c200v2. Ie onr remaining 2mb targets. 08.27.12 # and all it ultimately does is try compiling with and without thumb, to see which is smaller. 08.32.14 # A naive search (objdump -t and then look for g or F) finds one "duplicate" symbol between libfirmware and libunwarminder, data_abort_handler, which is weak in libfirmware.a so I would expect the later one to be used anyway? 08.33.20 # And I'd hope we're not hitting a data abort anyway 08.34.24 # So my guess is it's something else again 08.47.21 # <_bilgus> braewoods probably more likely its time on my desk 08.49.17 # <_bilgus> I vaguely remember doing it for the clip+ as well? 08.49.24 # <_bilgus> @speachy 08.50.41 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-d434-eae4-7f89-3e99.res6.spectrum.com) 08.53.15 # _bilgus: hmm? 08.59.30 # _bilgus: it just looked like someone took a razor blade to it 08.59.59 # oh well, the problem is solved so small price to pay 09.00.37 # huh seems the PPs that load entirely from their drives... 09.00.45 # don't even need the OF the way we pack it up 09.00.52 # only the rom bootloader remains OF 09.01.05 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.01.25 # _bilgus: i was just thinking though, if not for the iPod using PP so heavily, i doubt we'd have any support for it 09.01.48 # we have no cpu datasheet 09.02.03 # if not for the ipods being such a big deal back in the day 09.02.15 # we probably would have been unable to progress with it 09.02.50 # we've had to make guesses about how it works just to get what we have 09.03.06 # which makes it hard to support some targets fully depending on how they choose to use IO pins 09.08.53 # <_bilgus> no I didn't use any metal to open it up I assume it arrived sealed with packing tape on the box and duct tape on the player bubble wrap? 09.09.47 # _bilgus: yea 09.09.56 # _bilgus: in any case, don 09.09.59 # don't worry about it 09.10.03 # i don't really know how it happened 09.10.53 # the issue is solved and that's what matters 09.11.09 # i can always buy a better one if i cared that much 09.11.37 # <_bilgus> the ipods are still a big deal for now 09.11.51 # <_bilgus> still no data sheets 09.12.10 # which is funny considering the PPs we care about are no longer really used 09.12.20 # so what does holding onto them datasheets do for them 09.13.22 Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) 09.16.33 # Maybe it's just my filter bubble, but I feel like iPods (and possibly Rockbox) are having at least a little bit of a revival. It's all relative of course. Pretty much everybody is streaming...or listening to vinyl I guess ;) 09.17.09 # hahaha streaming... 09.17.14 # * braewoods goes into a tunnel 09.17.20 # "Why did my audio cut out!?" 09.17.39 # rockbox still has a niche 09.17.46 # streaming isn't going to work everywhere 09.21.05 # plus i don't want to waste my cellular data on audio streaming given how they price it in the US 09.21.54 # tbf, you can download tracks using Wifi on Spotify/Apple Music for offline listening, but yeah, there's some advantages still to "owning" your music... 09.23.19 # same reason chrome books aren't going to replace PCs for everyone 09.23.33 # or similar 09.24.30 Join ats_ [0] (~ats@cartman.offog.org) 09.24.49 Quit atsampson (Ping timeout: 258 seconds) 09.30.18 # very interesting 09.30.34 # the iriver h100 remote also works in a CD/MP3 player hybrid 09.30.36 # iriver slimx 09.47.46 Quit chris_s (Quit: Ping timeout (120 seconds)) 10.08.23 *** Saving seen data "./dancer.seen" 10.22.29 Quit massiveH (Quit: Leaving) 10.39.56 Quit akaWolf (Read error: Connection reset by peer) 10.40.18 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 10.46.22 Nick ats_ is now known as ats (~ats@cartman.offog.org) 10.50.16 Quit akaWolf (Read error: Connection reset by peer) 10.51.02 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 12.08.26 *** Saving seen data "./dancer.seen" 12.09.46 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 12.56.12 Join Soap [0] (~Soap@rockbox/staff/soap) 13.17.01 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.42.18 Quit vmx (Quit: Leaving) 14.04.35 # c 14.06.40 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 14.08.27 *** Saving seen data "./dancer.seen" 14.19.15 # Build Server message: New build round started. Revision b6fce99046, 298 builds, 10 clients. 14.33.03 # Build Server message: Build round completed after 828 seconds. 14.33.05 # Build Server message: Revision b6fce99046 result: All green 14.49.47 Join MrZeus__ [0] (~MrZeus@2a02:c7f:a0aa:4400:49fc:7eea:1fa3:615) 15.04.30 Join MrZeus [0] (~MrZeus@2a02:c7f:a0aa:4400:49fc:7eea:1fa3:615) 15.05.19 Quit MrZeus__ (Ping timeout: 260 seconds) 15.05.49 Quit dweeber (Ping timeout: 260 seconds) 15.07.43 Join dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) 15.27.29 Join MrZeus_ [0] (~MrZeus@194.37.96.137) 15.27.43 Quit MrZeus (Ping timeout: 260 seconds) 15.39.51 Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 15.40.16 Quit lebellium (Ping timeout: 252 seconds) 15.58.23 Quit speachy (Quit: WeeChat 3.0.1) 16.08.28 *** Saving seen data "./dancer.seen" 17.43.14 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.55.06 # Build Server message: New build round started. Revision c0a49d9bdf, 298 builds, 10 clients. 18.00.58 Quit lebellium_ (Quit: Leaving) 18.06.24 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 18.07.37 Quit ZincAlloy (Quit: Leaving.) 18.08.28 # Build Server message: Build round completed after 802 seconds. 18.08.30 *** Saving seen data "./dancer.seen" 18.08.30 # Build Server message: Revision c0a49d9bdf result: All green 18.12.52 Quit beencubed (Quit: Leaving) 19.03.36 Quit MrZeus_ (Read error: Connection reset by peer) 19.04.04 Join MrZeus_ [0] (~MrZeus@2a02:c7f:a0aa:4400:49fc:7eea:1fa3:615) 19.38.33 Quit pamaury (Ping timeout: 240 seconds) 19.56.13 Join beencubed [0] (~beencubed@209.131.238.248) 20.03.32 Quit ac_laptop (Ping timeout: 240 seconds) 20.08.33 *** Saving seen data "./dancer.seen" 20.29.55 Quit paulk-leonov (Ping timeout: 252 seconds) 20.30.41 Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) 20.36.11 Quit MrZeus_ (Ping timeout: 260 seconds) 20.36.46 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.39.41 Quit paulk-leonov (Ping timeout: 240 seconds) 20.40.59 Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) 21.16.41 Quit ac_laptop (Ping timeout: 240 seconds) 21.23.34 Quit cockroach (Quit: leaving) 22.08.36 *** Saving seen data "./dancer.seen" 22.23.24 Quit Ckat (Ping timeout: 268 seconds) 22.29.05 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) 22.31.40 Join f1reflyylmao [0] (~f1refly@2a01:c23:905e:7e00:9b6c:a2fe:4a40:53af) 22.34.21 Quit f1refly (Ping timeout: 260 seconds) 22.34.21 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:905e:7e00:9b6c:a2fe:4a40:53af) 22.52.22 Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 22.52.35 Quit ufdm (Ping timeout: 248 seconds) 23.14.44 Quit Saijin_Naib (Ping timeout: 258 seconds) 23.29.04 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)