| 00:04:43 | saratoga | speachy which bug? |
| 00:06:04 | speachy | saratoga: a trap gcc inserts because it thinks there's a null pointer dereference going on. |
| 00:07:58 | speachy | was able to fix nearly all of the traps, and one was definitely a real bug, with nearly all the rest in the skin/theme code. |
| 00:08:09 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 00:08:14 | saratoga | the decoder is fairly modified from the original ffmpeg version |
| 00:08:21 | saratoga | its quite possible something we broke |
| 00:08:41 | saratoga | where does gcc insert traps? |
| 00:08:59 | speachy | gcc 4.9 enables -fdelete-null-pointer-checks by default |
| 00:09:45 | speachy | and if its optimizer determines that you're dereferencing a null pointer, it deliberately bails. |
| 00:10:00 | speachy | (because that's nominally illegal) |
| 00:10:40 | fs-bluebot | Build Server message: New build round started. Revision 41a6da6, 293 builds, 8 clients. |
| 00:10:46 | saratoga | but it doesn't tell you where in the code it thinks there is a null pointer? |
| 00:10:48 | speachy | aand this ^^ will globally disable it |
| 00:11:20 | speachy | the -Wnull-dereference (?) wasn't added until GCC6. :/ |
| 00:12:24 | speachy | there was a lot of teeth gnashing over this back in the day, but I'd thought we were generally okay due to some of our targets being on gcc4.9 for a while now. apparently not entirely.. |
| 00:13:17 | speachy | when we update to GCC6 or newer we can flip that back on again and see what the improved diagnostics tell us |
| 00:13:39 | speachy | I have a suspicion that some of our sim builds are going to turn yellow |
| 00:13:58 | speachy | but I'll clean that mess up in the morning. |
| 00:14:44 | braewoods | speachy: i'm surprised you turned it on globally. |
| 00:16:06 | speachy | braewoods: arm and m68k didn't flag the same things. of the remaining stuff, they agreed only about lua. |
| 00:16:18 | braewoods | I see. |
| 00:16:45 | braewoods | strange how GCC is |
| 00:16:48 | Stanley00 | I got an issue when plugin usb on m5 and using original usb-hiby.c, it will show PANIC: mount 0 when unplug and exit usb mode |
| 00:16:49 | speachy | and the ones I saw in (eg) the SDL plugins seemed to be false positives. |
| 00:16:52 | braewoods | that feature was new in GCC9 afaik |
| 00:17:00 | braewoods | 4.9 |
| 00:17:06 | braewoods | so it probably has issues |
| 00:17:41 | speachy | so god only knows what other target-dependent heisenbugs there were lurking. |
| 00:18:20 | speachy | eg m68k complained about wmapro, but arm complained about libflac |
| 00:19:08 | | Quit [7] (Disconnected by services) |
| 00:19:15 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 00:19:27 | speachy | (granted slightly different -O flags for each...) |
| 00:22:46 | speachy | meanwhile, the theme stuff in g#2918 is probably legit. reversi is a false positive. |
| 00:22:47 | fs-bluebot | Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : Fix multiple potential null pointer dereferencess by Solomon Peachy |
| 00:23:36 | | Quit Stanley00 (Read error: Connection reset by peer) |
| 00:24:04 | speachy | (especially in the face of malicious or simply badly-coded themes.. makes sense to not crash, if possible) |
| 00:24:07 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 00:25:17 | saratoga | whats the MIPS FPU useful for in our code? |
| 00:27:28 | | Quit prof_wolfff (Ping timeout: 265 seconds) |
| 00:30:44 | speachy | it isn't, though there is one codec that's able to use FP. Oh, and I think Quake requires FP too. |
| 00:31:09 | speachy | on native targets our threading code isn't FP-aware at all. |
| 00:31:31 | speachy | I have a half-started patch to change that, but I keep finding larger fires to fight. |
| 00:32:30 | braewoods | speachy: floating point? |
| 00:32:49 | braewoods | what do threads have to do with floating point? |
| 00:44:21 | saratoga | which codec can use FP? |
| 00:45:02 | saratoga | a few still have the fp code paths, but i'm not sure they still work since we gutted them pretty badly |
| 00:49:54 | fs-bluebot | Build Server message: Build round completed after 2353 seconds. |
| 00:49:56 | fs-bluebot | Build Server message: Revision 41a6da6 result: 0 errors 48 warnings |
| 01:00 |
| 01:07:19 | | Quit saratoga (Remote host closed the connection) |
| 01:09:35 | __builtin | the SDL plugins and puzzles all use floating-point |
| 01:10:20 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:39:51 | DEBUG | EOF from server (Connection reset by peer) (snapshot: netstuff.c line 545) |
| 02:39:51 | *** | Cleanup |
| 02:39:51 | *** | Cleanup |
| 02:39:51 | *** | No seen item changed, no save performed. |
| 02:39:51 | *** | Exit |
| 02:39:52 | *** | Started Dancer V4.16 |
| 02:39:52 | *** | Connected to irc.freenode.net on port 6667 |
| 02:39:52 | *** | Logfile for #rockbox started |
| 02:39:53 | Mode | "logbot :+i" by logbot |
| 02:39:54 | Ctcp | Version from freenode-connect!frigg@freenode/utility-bot/frigg |
| 02:39:59 | *** | Server message 501: 'logbot :Unknown MODE flag' |
| 02:40:00 | | Join logbot [0] (~rockbox@stuffed.shaftnet.org) |
| 02:40:00 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 02:40:00 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 02:40:00 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 02:40:00 | | Join fs-bluebot [0] (~fs-bluebo@55d46dc5.access.ecotel.net) |
| 02:40:00 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 02:40:00 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 02:40:00 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 02:40:00 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
| 02:40:00 | | Join Barlow [0] (~barlow@unaffiliated/barlow) |
| 02:40:00 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 02:40:00 | | Join Airwave [0] (~Airwave@ti0006a400-0518.bb.online.no) |
| 02:40:00 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 02:40:00 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 02:40:00 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 02:40:00 | | Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) |
| 02:40:00 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 02:40:00 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 02:40:00 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 02:40:00 | | Join Galois [0] (djao@efnet-math.org) |
| 02:40:00 | | Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) |
| 02:40:00 | | Join igitoor [0] (igitur@unaffiliated/contempt) |
| 02:40:00 | | Join t0mato [0] (~t0mato@193.32.127.159) |
| 02:40:00 | | Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de) |
| 02:40:00 | | Join mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 02:40:00 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 02:40:00 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 02:40:00 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 02:40:00 | | Join _bilgus [0] (~bilgus@65.186.35.190) |
| 02:40:00 | | Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) |
| 02:40:00 | | Join Strife89 [0] (sid399903@gateway/web/irccloud.com/x-frywjzoyenhdxjms) |
| 02:40:00 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 02:40:00 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 02:40:00 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 02:40:00 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 02:40:00 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 02:40:00 | | Join speachy [0] (~speachy@209.2.65.77) |
| 02:40:00 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 02:40:00 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 02:40:00 | | Join ps-auxw [0] (~arneb@p548c6f52.dip0.t-ipconnect.de) |
| 02:40:00 | | Join Slasherii [0] (~miipekk@itu.ihme.org) |
| 02:40:00 | | Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) |
| 02:40:00 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 02:40:00 | | Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com) |
| 02:40:00 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 02:40:00 | | Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-ibzwjrmlfzihcpnq) |
| 02:40:00 | | Join heredoc [0] (heredoc@2a01:7e01::f03c:91ff:fec1:de1d) |
| 02:40:00 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 02:40:00 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-aggpelywdczulgkq) |
| 02:40:00 | | Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-tpncpihvtlasucfq) |
| 02:40:00 | | Join efqw [0] (uid412670@gateway/web/irccloud.com/x-cjmgdgoswnanyjsg) |
| 02:40:00 | | Join fauweh [0] (~root@ithaqua.unzane.com) |
| 02:40:00 | | Join toruvinn [0] (~toruvinn@87-205-132-1.adsl.inetia.pl) |
| 02:40:00 | | Join APLU [0] (~mulx@2a03:7220:8081:2900::1) |
| 02:40:00 | | Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) |
| 02:40:00 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 02:40:00 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 02:40:00 | | Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) |
| 02:40:00 | | Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods) |
| 02:40:00 | | Join genevino [0] (~genevino@m2m.pm) |
| 02:40:00 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 02:40:00 | | Join TheSphinX^ [0] (~briehl@srv001.nosupamu.de) |
| 02:40:00 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 02:40:00 | | Join dys [0] (~dys@aurora.ydns.eu) |
| 02:40:00 | | Join Soap [0] (~Soap@rockbox/staff/soap) |
| 02:40:00 | | Join vup [0] (~~~~@46.101.193.235) |
| 02:40:00 | | Join alexbobp [0] (~alex@meowface.org) |
| 02:40:00 | | Join Xeha [0] (~Xeha@unaffiliated/xeha) |
| 02:40:00 | | Join XDjackieXD [0] (~jackie@irc.chaosfield.at) |
| 02:40:00 | | Join skrzyp [0] (~skrzyp@skrzyp.net) |
| 02:40:00 | | Join klock [0] (~freeklock@unaffiliated/klock) |
| 02:40:00 | | Join jerwin [0] (~flippy-fl@unaffiliated/flippy) |
| 02:40:00 | | Join ArsenArsen [0] (~Arsen@kshare/developer/ArsenArsen) |
| 02:40:00 | | Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com) |
| 02:40:00 | | Join sh4 [0] (shapeless@unaffiliated/sh4) |
| 02:40:00 | | Join ecs [0] (esawady@d2evs.net) |
| 02:40:00 | | Join asaba [0] (~asaba@103.113.159.184) |
| 02:40:00 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 02:40:00 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
| 02:40:00 | | Join lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com) |
| 02:40:00 | | Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi) |
| 02:40:00 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 02:40:00 | | Join Topy44 [0] (OOvo1SKgJD@bellatrix.uberspace.de) |
| 02:40:00 | | Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) |
| 02:40:00 | | Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) |
| 02:40:00 | | Join amdj [0] (~aaron@freenode/staff/atheme.amdj) |
| 02:40:00 | | Join prg318 [0] (~prg@deadcodersociety/prg318) |
| 02:40:00 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 02:40:00 | | Join bleb [0] (~cm@unaffiliated/bleb) |
| 02:40:00 | | Join aevin [0] (~brootvors@unaffiliated/aevin) |
| 02:40:00 | | Join user890104 [0] (~Venci@freemyipod.org) |
| 02:40:00 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 02:40:00 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 02:40:00 | | Join copper [0] (~copper@unaffiliated/copper) |
| 02:40:00 | | Join plum [0] (~plum@unaffiliated/plum) |
| 02:40:00 | | Join @ChanServ [0] (ChanServ@services.) |
| 02:40:00 | | Join trfl [0] (~ed@static.59.110.40.188.clients.your-server.de) |
| 02:40:00 | | Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) |
| 02:40:00 | | Join blackyus- [0] (~blackyus1@ip189.ip-144-217-213.net) |
| 02:40:00 | | Join xcin [0] (~x@159.203.132.140) |
| 02:40:00 | | Join rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de) |
| 02:42:35 | | Join vvrng [0] (~vvrng@m91-128-94-73.cust.tele2.hr) |
| 03:00 |
| 03:28:23 | | Join petur [0] (~petur@199.59.5.11) |
| 03:28:23 | | Quit petur (Changing host) |
| 03:28:23 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 03:55:58 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 03:57:26 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 03:58:08 | | Quit Moarc (Client Quit) |
| 04:00 |
| 04:00:02 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 04:00:54 | | Quit Moarc (Client Quit) |
| 04:02:47 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 04:02:55 | | Quit Moarc (Client Quit) |
| 04:38:37 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 04:39:56 | *** | Saving seen data "./dancer.seen" |
| 04:40:52 | | Quit Moarc (Client Quit) |
| 04:43:02 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 05:00 |
| 05:37:12 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 05:55:26 | _bilgus | Well I found the Theme change crash a single uniniatialized variable called stride |
| 06:00 |
| 06:02:21 | | Quit Oksana (Ping timeout: 258 seconds) |
| 06:10:52 | | Quit pixelma (Quit: .) |
| 06:10:52 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 06:13:26 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 06:13:27 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 06:39:59 | *** | Saving seen data "./dancer.seen" |
| 06:41:43 | | Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) |
| 06:48:36 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 07:00 |
| 07:25:32 | | Quit pamaury (Ping timeout: 265 seconds) |
| 07:26:41 | | Quit bzed (Remote host closed the connection) |
| 07:26:57 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 07:34:14 | | Quit johnb7 (Ping timeout: 265 seconds) |
| 07:44:17 | wodz | Eh. I was hoping to run valgrind on Rocker to trace memory leaks and such. I was able to crosscompile it but when run it hits out-of-memory condition. |
| 07:51:23 | fs-bluebot | Build Server message: New build round started. Revision 621e363, 293 builds, 8 clients. |
| 07:53:22 | wodz | and kernel on rocker is compiled without swap support |
| 07:59:07 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 08:00 |
| 08:03:17 | speachy | braewoods: when we switch threads, the CPU state (eg registers) needs to be stored so it can be restored later. |
| 08:03:45 | speachy | braewoods: that needs to include the FPU state, or different threads that try to use the FPU will trash each other. |
| 08:08:04 | | Quit Stanley00 () |
| 08:09:54 | speachy | saratoga: the only FP-using codec (to my knowledge) is the recently-added one that adds support for the obscure ZX Spectrum chiptunes .VTX format. |
| 08:10:56 | speachy | (I only committed it so I could use it as a test case to work out target/platform-level FP bugs and FP-aware threading) |
| 08:11:54 | speachy | wodz: I have to imagine that the uisim on a host pc would get us 90% of the way there wrt valgrind. |
| 08:12:32 | wodz | speachy: I am debuging bluetooth stuff so not really |
| 08:13:17 | speachy | wodz: wellllllll... a $5 dongle turns any PC into a bluetooth-enabled one. :D |
| 08:13:20 | fs-bluebot | Build Server message: Build round completed after 1317 seconds. |
| 08:13:23 | fs-bluebot | Build Server message: Revision 621e363 result: All green |
| 08:14:50 | wodz | speachy: The catch is agptek uses bluez4, while all distros from last 5 or so years bluez5. This two have incompatible dbus api |
| 08:15:15 | speachy | well, it was a nice idea while it lasted. |
| 08:17:52 | wodz | hmm, In theory I could setup weezy in chroot to play. It was the last debian shiping bluez4 |
| 08:19:07 | wodz | wheezy I mean |
| 08:21:13 | speachy | _bilgus: wrt your comments on 2918, I only fixed up stuff that could lead to a direct nullptr dereference. |
| 08:21:57 | speachy | (using gcc's "helpful" silent insertion of trap/udf as a guide where to look....) |
| 08:22:33 | _bilgus | hmm not sure hth it determined that but uh ok |
| 08:22:54 | _bilgus | the double pointer one though? |
| 08:23:34 | speachy | the double pointer wasn't flagged but I agree it should be checked explicitly. as skin_render_viewport() doesn't check first. |
| 08:24:52 | _bilgus | as far as I can tell lebillums issue is fixed by the two of these patches together |
| 08:25:33 | _bilgus | probably the 'questionable areas' |
| 08:26:07 | _bilgus | I'll mark the FS as Needs Tested |
| 08:30:08 | _bilgus | I can't believe how long I looked for that bug for what it was I only caught it once I set the sim to crash on FB overrun |
| 08:31:13 | _bilgus | I found it impossible to trace on the Rocker and actually make sense of what address |
| 08:32:21 | speachy | _bilgus: wrt skin_tokens.c:740, what do you mean by "these"? |
| 08:33:51 | _bilgus | element and params but if your trap is gone then no worries? |
| 08:34:26 | speachy | ok, params. adding that check. |
| 08:35:15 | _bilgus | get_token_value should probably explictly check too |
| 08:35:21 | speachy | already added |
| 08:36:06 | _bilgus | its amazing how that bit of extra pointer checking makes this code much more palatable lol |
| 08:36:33 | _bilgus | First time I looked at that mess I was like WTF have I gotten myselft into |
| 08:37:06 | _bilgus | I chased that bug from one end through the other I probably should have left all the logfs |
| 08:37:10 | speachy | IMO all of these are legit needed, if only for crash prevention for theme developers |
| 08:37:36 | _bilgus | Yeah that was my thought too the theme engine is v. unforgiving |
| 08:39:00 | _bilgus | ok so mendel has a screen flipping issue on the fuze+ I guess I'll investigate that for a bit |
| 08:40:00 | *** | Saving seen data "./dancer.seen" |
| 08:40:57 | _bilgus | ah ok so the sbs kinda pushes in at the bottom before if flips to the top |
| 08:44:12 | _bilgus | I think this might be a good case for the improved viewport code I think we can do it in rb directly |
| 08:49:55 | | Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:857e:c3d:75f3:53b) |
| 08:50:29 | speachy | _bilgus: you assigned #13249 to Daniel Stenberg |
| 08:50:49 | speachy | and then fixed it. guess I should have scrolled to the next page of my mailbox |
| 08:53:34 | _bilgus | yeah my name isn't in the list so when I try it does badger |
| 08:54:55 | _bilgus | assign to me works so no worries |
| 09:00 |
| 09:01:42 | _bilgus | oh well the fuze+ issue is with the device directly |
| 09:02:29 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:05:20 | _bilgus | ok so If I cange the internal one everything that uses mem set will probably draw wrong so I guess I need to rejigger only when the final copy to the device lcd happens |
| 09:05:26 | fs-bluebot | Build Server message: New build round started. Revision a605cdf, 293 builds, 8 clients. |
| 09:06:00 | _bilgus | (lcd_get_address) |
| 09:32:18 | fs-bluebot | Build Server message: Build round completed after 1612 seconds. |
| 09:32:21 | fs-bluebot | Build Server message: Revision a605cdf result: All green |
| 09:37:21 | _bilgus | mendel_munkis, see response in FS |
| 09:42:33 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 09:49:37 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:51:36 | | Quit johnb7 (Ping timeout: 256 seconds) |
| 09:55:53 | braewoods | speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2925/ ? |
| 09:56:21 | speachy | braewoods: tested? |
| 09:56:35 | braewoods | not yet. |
| 09:56:57 | braewoods | i'll need to write some temporary code for that. |
| 09:57:15 | braewoods | i'll test it on an unused memory region to see how well it works. |
| 09:57:28 | speachy | the others were mechanical changes; this is functionally different. given the bricking risk of bugs in flash code, this needs to be tested first. |
| 09:57:48 | braewoods | i was planning on it in any case |
| 09:58:04 | braewoods | let me see |
| 09:58:08 | braewoods | ok. it's over here. |
| 09:59:02 | braewoods | i'll write some short code to erase an unused region |
| 10:00 |
| 10:01:26 | speachy | (we don't want some poor user to be the first to test this. granted, "Some poor user" probably won't be trying to flash their 15-year-old iriver device) |
| 10:02:34 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 10:29:51 | speachy | oh, in other news, I ordered a couple of those "Cherry Pi" boards that sport an Allwinner V3s SoC. |
| 10:40:04 | *** | Saving seen data "./dancer.seen" |
| 10:44:18 | speachy | a nicer form factor to work with than the PineCubes |
| 10:45:15 | | Quit massiveH (Quit: Leaving) |
| 10:46:21 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
| 10:59:49 | | Quit johnb7 (Ping timeout: 258 seconds) |
| 11:00 |
| 11:08:43 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 11:27:21 | | Join johnb3 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 11:36:12 | braewoods | speachy: one thing to note about ARM... unlike x86 it does heavily benefit from code compiled with the latest compatible instruction sets |
| 11:36:45 | braewoods | i worked with it a few times in the past and setting the compiler architecture for it was very helpful |
| 11:37:48 | speachy | braewoods: we already use target-appropriate compiler options; anything more than that will require more hand-written asm. :) |
| 11:58:11 | efqw | speachy: I found the issue with mass storage on the m3k |
| 11:58:35 | speachy | hmm? |
| 11:59:21 | efqw | rb is loading the correct modules but it immediately unloads them for some reason |
| 12:00 |
| 12:00:14 | efqw | I tried the exact same insmod commands from usb-fiio.c in the console and it works just fine |
| 12:01:07 | efqw | (verified them with the stock player binary too) |
| 12:01:34 | speachy | rockbox unloads them when usb_enabled(false) is called. |
| 12:02:01 | mendel_munkis | _bilgus: thank you. but I can't find the broken memset cal to which you are referring. |
| 12:03:40 | efqw | https://www.irccloud.com/pastebin/dO8UESfI/ |
| 12:03:52 | efqw | this is what happens when I plug in the USB cable |
| 12:05:24 | efqw | https://www.irccloud.com/pastebin/AIc5K9V5/ |
| 12:05:50 | efqw | on the computer side it's clear that the module has been unloaded immeidately |
| 12:06:14 | efqw | *immediately |
| 12:24:32 | | Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) |
| 12:26:43 | | Quit tchan (Ping timeout: 256 seconds) |
| 12:28:24 | | Quit pamaury (Ping timeout: 260 seconds) |
| 12:29:17 | braewoods | speachy: huh. reminds me of a weird issue i had once where the usb printer kernel module was causing issues when cups wanted to control the usb printer directly. i had to unload it. there seemed to be some kind of conflict going on. |
| 12:29:38 | speachy | efqw: the rockbox code is pretty consistent; it would only trigger the unload if we received an event saying it had been unplugged. |
| 12:30:25 | speachy | braewoods: could be the classic usblp driver vs the libusb-based cups backend. the latter being far more flexible. |
| 12:32:13 | braewoods | i saved some space at one of desktops in our home by replacing the giant tower with a newer small desktop box that is now mounted to the monitor |
| 12:32:33 | braewoods | they never used the full capabilities of the old one so this is a good compromise |
| 12:32:40 | | Quit johnb7 (Ping timeout: 246 seconds) |
| 12:40:05 | *** | Saving seen data "./dancer.seen" |
| 12:51:57 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 12:55:44 | | Quit tchan1 (Ping timeout: 240 seconds) |
| 13:00 |
| 13:05:16 | efqw | but I have no idea why it's receiving the unplug event in the first place |
| 13:05:42 | efqw | the screen still shows the USB plug icon instead of the rb menu |
| 13:06:08 | efqw | so rb thinks it's both plugged in and unplugged? |
| 13:06:41 | _bilgus | mendel_munkis, there is no broken memcpy? |
| 13:14:02 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 13:15:34 | mendel_munkis | I must have misunderstood you. Did you figure out what the issue with the statusbar is? |
| 13:15:50 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 13:20:05 | | Quit johnb7 (Ping timeout: 240 seconds) |
| 13:20:29 | braewoods | _bilgus: they said memset, not memcpy? |
| 13:20:38 | _bilgus | the device writes a register to enable screen flipping ie. its native screen flippin, I was saying we will need to make a custom memcpy that flips/rotates/transform |
| 13:21:10 | _bilgus | essentially a blitter |
| 13:22:05 | _bilgus | sorry had memset on my mind when I typed that |
| 13:26:23 | braewoods | memset is mainly used for zero-initialize... |
| 13:26:32 | braewoods | never did understand why any other values would be used |
| 13:26:43 | fs-bluebot | Build Server message: New build round started. Revision c85d8e2, 293 builds, 8 clients. |
| 13:29:33 | mendel_munkis | braewoods: to initialize to some other value? |
| 13:29:54 | _bilgus | braewoods, sometimes you need values other than zero i'm sure you could find a few places around most c code bases |
| 13:30:07 | mendel_munkis | _bilgus: I already disproved that it's the native flipping that's broken. ie if the register is set without rockbox relizing everything works fine. |
| 13:31:22 | _bilgus | oh? it didn't look like it did anything but set the register I'll do a text search for it again |
| 13:32:53 | mendel_munkis | That's why I was thinking it was something in the viewports. |
| 13:34:21 | braewoods | mendel_munkis: obviously but i've never seen it. |
| 13:38:22 | _bilgus | mendel_munkis, is this triggered by the button flip part? |
| 13:38:45 | mendel_munkis | oh wait that's weird. I did another test. and it happens whenever it's uside down regardless of RB settings |
| 13:39:12 | mendel_munkis | when the register is set upside down |
| 13:40:08 | _bilgus | I think its prob an error in the device or maybe something missing but uh no clue |
| 13:41:59 | _bilgus | I think its an important feature for that target though so I might see about adding it manually |
| 13:42:25 | _bilgus | after I get the other stuff off my list |
| 13:42:56 | fs-bluebot | Build Server message: Build round completed after 974 seconds. |
| 13:43:01 | fs-bluebot | Build Server message: Revision c85d8e2 result: All green |
| 13:50:14 | | Quit tchan (Ping timeout: 260 seconds) |
| 13:52:52 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 13:53:45 | mendel_munkis | "When a window area is set by registers R50h ~R53h, only the addressed DRAM area is updated based on I/D [1:0] and AM bits setting." If I'm reading that correctly when lcd_update_rect() is not the whole screen it will preform an update with the correct orientation in a mirrored location. |
| 13:55:14 | _bilgus | sounds right to me |
| 13:55:47 | mendel_munkis | so I should be able to fix it with an if in update_rect will try that in a few. |
| 13:56:05 | mendel_munkis | thanks for the help. |
| 13:56:28 | mendel_munkis | although I wonder if the speed cost woul be significant. |
| 13:57:47 | _bilgus | in the blitter? it would add a bit of slowdown extra if branch and maybe slightly less optimized than std memcpy |
| 13:58:07 | _bilgus | or you mean the device native method? |
| 13:58:13 | mendel_munkis | I'm not touching thememcopy justthe rectangle coords. |
| 13:58:26 | mendel_munkis | in the dvice drive. |
| 13:58:44 | _bilgus | I think thats untenable ultimately |
| 14:00 |
| 14:20:22 | | Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) |
| 14:36:23 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 14:38:48 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 14:40:09 | *** | Saving seen data "./dancer.seen" |
| 14:47:45 | | Quit johnb7 (Ping timeout: 240 seconds) |
| 14:52:40 | | Part edhelas |
| 14:53:52 | | Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) |
| 14:55:54 | lebellium | _bilgus: following your comment in FS #13249, I wanted to try the latest build but now my YP-R1 crashes at startup |
| 14:55:56 | fs-bluebot | http://www.rockbox.org/tracker/task/13249 SBS Info viewport not refreshing when used as a conditional (bugs, requires testing) |
| 14:56:12 | lebellium | fresh install, my theme not loaded |
| 14:56:52 | lebellium | it crashes on the rockbox splash screen |
| 14:57:14 | _bilgus | eh crap and its not happening in the sim either right? |
| 14:57:36 | speachy | lebellium: did the previous nightly build work? |
| 14:58:02 | lebellium | Don't know about the UI sim as I'm using Windows and the latest rasher version is dated 2018. |
| 14:58:10 | lebellium | I can try the previous nightly build |
| 14:58:17 | _bilgus | ok i'll try sim |
| 15:00 |
| 15:01:21 | lebellium | f62eee569c-201027 is working |
| 15:02:28 | speachy | but 41a6da6 does not? |
| 15:05:00 | lebellium | it does work too |
| 15:07:42 | speachy | there are only three commits since then. One can't be responsible for the crash, leaving only two. |
| 15:08:21 | speachy | lebellium: http://www.shaftnet.org/~pizza/rb-r1.zip |
| 15:10:29 | _bilgus | I see it I think |
| 15:10:55 | lebellium | speachy: crash |
| 15:11:00 | _bilgus | no nm |
| 15:11:16 | speachy | and there's no working sim for the R1 yet. |
| 15:11:43 | lebellium | I usually use the Onda VX sim |
| 15:11:56 | lebellium | but if the issue is really specific to the YP-R1, it doesn't help |
| 15:14:09 | speachy | ok, found a bug in a touchscreen path in the work I did. |
| 15:14:24 | _bilgus | R0 sim doesn't crash |
| 15:14:40 | speachy | lebellium: download the new build, same url |
| 15:16:35 | _bilgus | sbs doesn't show properly in the R0 sim |
| 15:17:54 | lebellium | speachy: crash |
| 15:19:50 | speachy | I wonder if checkwps works |
| 15:22:28 | speachy | what theme, the stock cabbiev2? |
| 15:23:39 | lebellium | fresh install so yes |
| 15:25:31 | speachy | any address? |
| 15:25:53 | lebellium | you mean a panic screen? no |
| 15:26:29 | _bilgus | so is it crashing at with a605cdf? |
| 15:28:06 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
| 15:29:19 | | Join petur2 [0] (~petur@199.59.5.111) |
| 15:29:20 | lebellium | I don't know which builds speachy uploaded and made me test but I didn't try a605cdf, I tested the latest build c85d8e2865 and the previous nightly build |
| 15:29:36 | speachy | _bilgus: the last one I sent him was a605cdf |
| 15:29:43 | speachy | (plus one additional fix) |
| 15:29:59 | | Quit petur2 (Client Quit) |
| 15:30:31 | _bilgus | shit that means something doesn't like the answer it got |
| 15:30:47 | _bilgus | 'A patently wrong answer |
| 15:31:44 | | Quit petur (Ping timeout: 240 seconds) |
| 15:32:24 | * | braewoods patents all the wrong answers. |
| 15:32:39 | braewoods | Now I can profit from other people's mistakes! |
| 15:32:52 | _bilgus | just saying it was gettin a bunk pointer before |
| 15:33:00 | | Quit p3tur (Ping timeout: 272 seconds) |
| 15:33:02 | braewoods | _bilgus: so you debunked it? |
| 15:33:04 | braewoods | :) |
| 15:33:24 | _bilgus | cleary still bunk^ |
| 15:34:07 | speachy | but what's different about the R1? (other than touchscreen and possibly a higher res screen) |
| 15:36:07 | _bilgus | The real question is how many more turns of phrase can I use in this conversation, yeah good point speachy I know it won't work right but what if you disable TS |
| 15:36:45 | speachy | lebellium: if we disable touch, you can still reset and load new software into the device, right? |
| 15:37:33 | lebellium | yes |
| 15:37:43 | lebellium | with the physical power and volume buttons |
| 15:37:59 | speachy | ok. gimme a few to do a touch-less build |
| 15:38:07 | lebellium | there is no bootloader screen to choose between Rockbox and OF |
| 15:38:14 | lebellium | it's done with the volume button |
| 15:40:17 | speachy | _bilgus: the uisim is definitely showing the statusbar viewport all wonky. |
| 15:40:38 | speachy | hmm. |
| 15:40:43 | _bilgus | yeah I think I know whats going on the default vp needs defaults |
| 15:41:08 | speachy | well, the main menu vp is suppoed to take the default vp and shrink it by the sb size |
| 15:41:31 | speachy | (does this happen on actual targets, or just the sim?) |
| 15:42:32 | _bilgus | so far just the sim |
| 15:42:48 | speachy | might be due to the sim code not picking up a #define that I moved. |
| 15:42:51 | _bilgus | I should try the rocker sim as well |
| 15:43:17 | mendel_munkis | I am not noticing an delay in normal usage. Is there anything that uses a lot of update_rect() close together? |
| 15:43:28 | _bilgus | themes |
| 15:45:55 | speachy | lebellium: new build, same URL |
| 15:46:19 | _bilgus | if you want a wholly arbitrary (between targets) use that rliimg lua script and put in a few lines to get iterations especially on the twist demo |
| 15:50:12 | mendel_munkis | I don't see any delays, but that may just be me |
| 15:50:26 | mendel_munkis | it's on gerrit |
| 15:52:01 | speachy | _bilgus: it's broken on real targets too. |
| 15:52:29 | _bilgus | huh I'll try another |
| 15:52:40 | speachy | _bilgus: the viewport/sb I mean |
| 15:52:46 | _bilgus | yeah |
| 15:53:04 | lebellium | speachy: crash |
| 15:53:09 | speachy | backing out today's changes. |
| 15:53:11 | _bilgus | would almost have to be the changes I made today but I swear they are more sane! |
| 15:53:18 | speachy | _bilgus: could be mine! |
| 15:53:37 | _bilgus | yours are even more sane!! |
| 15:54:07 | speachy | _bilgus: when was the last time you sacrified a goat to the elder gods? |
| 15:55:16 | _bilgus | had to been like last week |
| 15:55:30 | speachy | okay. it's either a605cdf or c85d8e |
| 15:56:33 | _bilgus | i'll let you know shortly |
| 15:56:51 | speachy | I'm unzipping it to real hardware now |
| 15:57:36 | speachy | it's mine |
| 15:57:40 | speachy | (wtf?) |
| 15:59:37 | _bilgus | I would have bet $$ it was me |
| 15:59:59 | _bilgus | so there is a bad pointer would be my guess or there is a logic error |
| 16:00 |
| 16:00:38 | speachy | the logic error might actually be in the original code |
| 16:06:15 | speachy | I think I know what it is. |
| 16:08:52 | speachy | nope. |
| 16:09:08 | speachy | I will revert this if I can't figure it out within a couple of hours. |
| 16:20:40 | | Quit lemon_jesus (Ping timeout: 256 seconds) |
| 16:35:01 | _bilgus | don't revert just yet I think I should probably just go through and get some logfs set up its just so very hard to trace this stuff through the engine |
| 16:38:52 | _bilgus | all those NULL checks we could just put an intermediate function to return NULL on the failed check |
| 16:39:24 | speachy | I'm going to try and isolate it to a specific change. |
| 16:40:10 | *** | Saving seen data "./dancer.seen" |
| 16:40:49 | _bilgus | logf use macro that points back to NULL logf use our intermediate and log all |
| 16:48:20 | | Quit Rower (Ping timeout: 260 seconds) |
| 16:49:22 | speachy | ok, isolated to skin_[display|parser|render|tokens].c |
| 16:50:35 | _bilgus | get_token_value is recursive |
| 16:50:53 | speachy | yeah, that's probably where things are bad but I'm being systematic here |
| 16:53:10 | _bilgus | maybe there is a void or null skin token we could return |
| 16:55:40 | _bilgus | yeah don't let me mess up your process I do see a few things i'd like to clean up in there later |
| 16:56:16 | speachy | down to just skin_parser or skin_tokens |
| 16:56:49 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 16:58:16 | speachy | ok, it's the changes in skin_parser.c |
| 16:59:28 | | Join beencubed [0] (~beencubed@209.131.238.248) |
| 17:00 |
| 17:02:29 | speachy | specifically the changes to skin_find_item() |
| 17:02:48 | speachy | lebellium: I have a new image up for you to try |
| 17:03:17 | _bilgus | I would have figured line 2530 |
| 17:03:34 | speachy | this is purely the statusbar going wonky |
| 17:03:50 | speachy | I don't know if it's related or not, but I figure it's at least something I can reproduce |
| 17:04:44 | _bilgus | re skin_data_free_buflib_allocs, I notice we kill all the buffers here I wonder if the caller deselects all the viewports |
| 17:04:49 | speachy | huh, I missed that L2530 thing |
| 17:06:25 | speachy | the change that probabaly caused the sb to break is the explicit itemlabel=null at the top of the loop |
| 17:07:04 | speachy | which means that we still have a valid itemlabel even if we didn't match anything on that iteration. |
| 17:07:24 | _bilgus | ln 1739 looks suspect |
| 17:08:26 | _bilgus | no nm sorry i see what its protecting |
| 17:12:10 | _bilgus | re line 1963 does gcc say how it processes for statemenst is it hopefully always short circuits |
| 17:15:38 | _bilgus | braewoods, any clue? gcc behavior 'for(' statement invocation short; circuit if conditional doesn't match guaranteed? |
| 17:16:44 | speachy | for executes the first statement, then after each iteration it executes the increment statement, then it performs the test. |
| 17:17:31 | speachy | ie stmt1 ; do { .... stmt3;} while (stmt2); |
| 17:17:48 | | Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) |
| 17:20:59 | _bilgus | ok as long as its that always |
| 17:22:27 | lebellium | speachy: same URL, |
| 17:22:28 | lebellium | ? |
| 17:22:32 | speachy | GCC short-ciruits the tests from L->R, ie the first failure will terminate. |
| 17:22:35 | speachy | lebellium: yes |
| 17:23:47 | | Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) |
| 17:26:21 | lebellium | crash |
| 17:28:32 | speachy | well, drat. |
| 17:28:50 | speachy | it crashes on the log screen, right? what's the version string it shows? |
| 17:29:58 | speachy | s/log/logo/ |
| 17:30:25 | lebellium | it crashes on the logo screen with 2bc621a26bM-201028 displayed |
| 17:30:35 | speachy | thanks |
| 17:34:27 | _bilgus | speachy gcc statusbar-skinned.c line 138 did you mention this? |
| 17:34:39 | _bilgus | already.. |
| 17:35:39 | speachy | that was one of the changes I'd backed out in an earlier build I sent him |
| 17:41:32 | speachy | lebellium: new image, same place. |
| 17:42:50 | _bilgus | I'm really interested to see the final issue because this code looks fine otherwise |
| 17:43:51 | speachy | _bilgus: the statusbar issue cause is still unknown; I've backed out the offending changes (haven't pushed yet) but the problem is somewhere higher in the call stack. |
| 17:45:11 | | Quit tchan1 (Quit: WeeChat 2.8) |
| 17:45:13 | lebellium | 91ccb246e7M-201028 crash |
| 17:45:27 | | Join tchan [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) |
| 17:45:27 | | Quit tchan (Changing host) |
| 17:45:27 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 17:45:49 | speachy | _bilgus: ^^ was backing out the L2530 change. |
| 17:51:20 | speachy | aha, found the logic goof in skin_find_item. |
| 17:51:41 | speachy | the check for token being valid doesn't apply to the UIVP/VP cases. |
| 17:54:08 | fs-bluebot | Build Server message: New build round started. Revision 8c8284b, 293 builds, 8 clients. |
| 17:54:46 | speachy | now we're down to just that crash on the yp-r1 |
| 17:54:57 | speachy | lebellium: new image up, same place |
| 17:57:32 | lebellium | crash |
| 17:59:16 | | Quit klock (*.net *.split) |
| 17:59:16 | | Quit __builtin (*.net *.split) |
| 17:59:16 | | Quit benedikt93 (*.net *.split) |
| 17:59:17 | | Quit blackyus- (*.net *.split) |
| 17:59:17 | | Quit shrizza (*.net *.split) |
| 17:59:32 | | Join blackyus17 [0] (~blackyus1@ip189.ip-144-217-213.net) |
| 17:59:37 | | Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) |
| 17:59:40 | | Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) |
| 17:59:54 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
| 18:00 |
| 18:00:02 | | Join klock [0] (~freeklock@unaffiliated/klock) |
| 18:03:23 | speachy | ok. new image. |
| 18:03:48 | speachy | I'm systematically excluding chunks of the patch to try and narrow down which avenue it's coming from. |
| 18:03:56 | speachy | lebellium: ^^ |
| 18:04:24 | _bilgus | yeah I hate when it comes to that |
| 18:06:26 | | Quit Moarc (Ping timeout: 265 seconds) |
| 18:07:02 | | Join Moarc_ [0] (~chujko@a105.net128.okay.pl) |
| 18:07:08 | lebellium | crash 8c8284bbe6M-201028 |
| 18:09:51 | speachy | ok, that narrows it down to the changes in skin_parser and skin_renderer |
| 18:09:51 | fs-bluebot | Build Server message: Build round completed after 842 seconds. |
| 18:09:51 | fs-bluebot | Build Server message: Revision 8c8284b result: 2 errors 0 warnings |
| 18:10:24 | _bilgus | on the fuzeV2 I get a crash that points to somewhere in skin_engine |
| 18:13:48 | speachy | lebellium: new image up |
| 18:16:21 | Airwave | speachy: I just tried the latest newest build from https://build.rockbox.org/. Still experiencing the issue with borders around top bar elements and most of the main screen |
| 18:16:49 | lebellium | works :) |
| 18:16:59 | speachy | Airwave: the one that just finished? (8c284b) |
| 18:17:10 | speachy | lebellium: okay! we're getting somewhere. :D |
| 18:17:15 | Airwave | speachy: Correct |
| 18:17:32 | speachy | Airwave: this was on the Rocker? |
| 18:17:37 | Airwave | Yes |
| 18:18:38 | Airwave | Huh if I go into the now playing screen and go back, it's fine |
| 18:19:00 | Airwave | But after reboot it's back |
| 18:19:29 | speachy | lebellium: new one up. |
| 18:20:15 | Airwave | How do I do a screenshot? There's no option for it in the debug menu |
| 18:21:06 | _bilgus | Airwave is this clean build? |
| 18:21:19 | Airwave | _bilgus: What does that mean? |
| 18:21:34 | _bilgus | like did you rename the .rockbox directory first |
| 18:21:56 | _bilgus | clean install |
| 18:22:07 | _bilgus | sorry bad with wordz today |
| 18:22:12 | Airwave | No |
| 18:22:14 | lebellium | speachy: crash |
| 18:23:15 | braewoods | well that was good |
| 18:23:29 | braewoods | the other H320 I got was not really working even when plugged in |
| 18:23:31 | braewoods | blah blah |
| 18:23:34 | braewoods | replaced battery |
| 18:23:38 | braewoods | works fine now |
| 18:24:09 | speachy | lebellium: new one up again. |
| 18:26:19 | lebellium | works |
| 18:26:46 | speachy | we're down to just 6 diff chunks in a single file. |
| 18:27:51 | speachy | new one up. |
| 18:28:54 | _bilgus | crazy |
| 18:29:38 | lebellium | works |
| 18:30:45 | Airwave | speachy: Let me know if I could provide some help debugging this issue |
| 18:32:29 | speachy | lebellium: again, please. |
| 18:33:04 | speachy | whoops. |
| 18:33:06 | speachy | hang on |
| 18:33:23 | speachy | okay, re-uploaded. |
| 18:33:43 | speachy | will report as 72ad226ebf (no 'M') |
| 18:35:32 | lebellium | works |
| 18:39:30 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 18:40:11 | speachy | lebellium: and again. |
| 18:40:13 | *** | Saving seen data "./dancer.seen" |
| 18:40:26 | speachy | this should narrow it down to a single chunk. |
| 18:41:11 | lebellium | good news, 'cause it's really time to go to bed now :D |
| 18:41:29 | speachy | does that mean it works? |
| 18:41:30 | | Quit bluebrother (Disconnected by services) |
| 18:41:35 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 18:41:40 | | Join fs-bluebot_ [0] (~fs-bluebo@55d44bbc.access.ecotel.net) |
| 18:42:06 | lebellium | it does |
| 18:42:25 | | Quit fs-bluebot (Ping timeout: 240 seconds) |
| 18:45:39 | speachy | _bilgus: it's the changes to skin_data_free_buflib_allocs() |
| 18:46:23 | speachy | lebellium: do you have time for one more? |
| 18:46:30 | lebellium | last one |
| 18:47:23 | speachy | okay, it's up |
| 18:49:09 | lebellium | 8c8284bbe6M-201028 works |
| 18:49:39 | speachy | okay! |
| 18:50:01 | speachy | I'll have a proper fix for this committed soon. |
| 18:50:17 | lebellium | great, let's see tomorrow |
| 18:50:24 | lebellium | thanks for your help and good night |
| 18:51:48 | | Quit lebellium (Quit: Leaving) |
| 18:53:35 | fs-bluebot_ | Build Server message: New build round started. Revision a5a8e00, 293 builds, 8 clients. |
| 18:54:27 | speachy | _bilgus: see g#2930 for the $%#@! fix. it's what's building now. Probably will fix the crash you saw on the FuzeV2 as well. |
| 18:54:29 | fs-bluebot_ | Gerrit review #2930 at http://gerrit.rockbox.org/r/2930 : Fix a crash introduced in a605cdf70 by Solomon Peachy |
| 18:55:03 | speachy | Airwave: please try this build when it completes, it might actually fix everyone's problems. |
| 19:00 |
| 19:04:11 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 19:08:49 | _bilgus | speachy we both missed that |
| 19:10:01 | fs-bluebot_ | Build Server message: Build round completed after 985 seconds. |
| 19:10:03 | fs-bluebot_ | Build Server message: Revision a5a8e00 result: 220 errors 0 warnings |
| 19:16:28 | Airwave | speachy: Oh nice, will do |
| 19:18:33 | _bilgus | speachy fixed |
| 19:19:42 | _bilgus | I saw a few other things I wanted to clean up |
| 19:21:39 | braewoods | erm. did something change in the rockbox code? my latest test build for H300 has a statusbar that's glitching out. |
| 19:22:37 | _bilgus | its fixed at head except the 220 errors |
| 19:23:04 | braewoods | i just did a pull and build this in the last 15 minutes. |
| 19:23:13 | braewoods | is it newer than that? |
| 19:24:11 | _bilgus | yes^ |
| 19:24:22 | _bilgus | the errors are all checkwps |
| 19:26:54 | | Part edhelas |
| 19:27:35 | | Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) |
| 19:28:31 | braewoods | speachy: good thing you insisted on those tests. |
| 19:28:41 | braewoods | speachy: for some reason i only had partial success with my program pass. |
| 19:28:51 | braewoods | only 2 words got written in the region |
| 19:29:04 | braewoods | strange. |
| 19:29:09 | braewoods | looks like i got some debugging to do. |
| 19:39:10 | fs-bluebot_ | Build Server message: New build round started. Revision c7fb319, 293 builds, 8 clients. |
| 19:39:16 | speachy | okay, that'll fix checkwps |
| 19:47:23 | _bilgus | Awesome! |
| 19:53:13 | _bilgus | sorry speachy I'm the one that suggested that |
| 19:53:46 | braewoods | i'm going to start over on that change to the write code |
| 19:53:49 | braewoods | flash modify |
| 19:53:55 | braewoods | start by testing the old one |
| 19:54:41 | _bilgus | and also how did it not crash when skin_buffer was NULL? |
| 19:55:28 | _bilgus | ah nm I see it |
| 19:55:36 | _bilgus | 0[0] = 0 |
| 19:55:54 | _bilgus | wow that is subtle |
| 19:56:05 | | Quit pamaury (Ping timeout: 240 seconds) |
| 19:56:58 | _bilgus | I like how its not hidden behind macros and abstraction now though |
| 19:59:19 | fs-bluebot_ | Build Server message: Build round completed after 1209 seconds. |
| 19:59:20 | fs-bluebot_ | Build Server message: Revision c7fb319 result: All green |
| 20:00 |
| 20:03:31 | braewoods | _bilgus: i'm still getting a glitching status bar from HEAD. |
| 20:06:26 | | Quit michaelni (Ping timeout: 256 seconds) |
| 20:18:41 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:857e:c3d:75f3:53b) |
| 20:18:56 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 20:22:19 | | Quit MrZeus (Ping timeout: 272 seconds) |
| 20:31:54 | speachy | braewoods: on the main screen or wps? and on the hxxx targets? |
| 20:36:18 | speachy | stock theme? |
| 20:38:54 | speachy | braewoods: ok, I see it in the sim |
| 20:39:03 | speachy | _bilgus: it's not the problem I'd introduced. |
| 20:39:33 | speachy | the statusbar and the remote are glitching together. |
| 20:40:02 | speachy | I see bits of the sb paint into the remote, and perhaps vice versa? |
| 20:40:15 | *** | Saving seen data "./dancer.seen" |
| 20:40:37 | _bilgus | there is probably something getting the wrong buffer then is that the h120 sim? |
| 20:40:43 | speachy | h320 |
| 20:41:14 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 20:41:15 | speachy | hitting the stop button shows the splash paint onto both screens |
| 20:41:20 | _bilgus | ok I'll start searching for that after I get done with this patch |
| 20:41:41 | | Join fs-bluebot [0] (~fs-bluebo@55d4437e.access.ecotel.net) |
| 20:41:44 | speachy | I'm operating under the assumption here that this isn't due to my hackery. |
| 20:42:16 | _bilgus | ugh I would say I'm frustrated but eh not really its a damn complex system |
| 20:42:47 | _bilgus | i'm glad its getting updated too bc lets face it only the codecs are worse |
| 20:44:05 | | Quit bluebrother^ (Ping timeout: 240 seconds) |
| 20:44:15 | _bilgus | oh wait the h320 the one with the massive screen? I saw that in testing and then it disappeared in a later patch so I figured it was fixed but maybe I broke it again |
| 20:44:16 | speachy | welllllll, I dunno. if you treat the codecs as a black box they're straightforward. internally they're spaghetti. |
| 20:44:20 | | Quit fs-bluebot_ (Ping timeout: 268 seconds) |
| 20:44:33 | speachy | no, it has the same screen size as the h120.. just full color |
| 20:44:37 | braewoods | _bilgus: it's glitching along the top edge. |
| 20:44:47 | braewoods | in the normal menus |
| 20:44:55 | braewoods | what you get when you first bootup |
| 20:45:12 | braewoods | currently i'm experimenting with trying to figure out this flash stuff |
| 20:45:41 | _bilgus | nbd if I can reproduce it in the sim its easy |
| 20:45:50 | _bilgus | well not easy but at least faster |
| 20:46:22 | _bilgus | I spend more time compiling than I do coding on this laptop think I might have to drag my rig here |
| 20:47:41 | speachy | _bilgus: if I revert c85d8e2865 it is glitch-free |
| 20:50:38 | braewoods | speachy: yum. spaghetti. |
| 20:59:41 | _bilgus | UNFORTUNATELY THAT ONE FIXES THE OTHER ISSUE SO I'LL HAVE TO LOOK CLOSELY |
| 20:59:50 | _bilgus | sorry |
| 20:59:58 | braewoods | _bilgus: tilt. |
| 21:00 |
| 21:05:51 | speachy | might be the hardcoded screens[SCREEN_MAIN] in skin_backdrop_set_buffer() ? |
| 21:13:45 | | Quit paulk-leonov (Ping timeout: 246 seconds) |
| 21:31:14 | _bilgus | shouldn't be it only needs screen if the VP is NULL and that vp is part of the skin_viewport struct |
| 21:37:27 | _bilgus | g#2931 kcoks off 2.5k but I think it might be broken I wasn't expecting that kind of size decrease I'll get back to it |
| 21:37:28 | fs-bluebot | Gerrit review #2931 at http://gerrit.rockbox.org/r/2931 : Skin_engine optimize element switch by William Wilgus |
| 21:37:41 | _bilgus | knocks* |
| 21:39:08 | Airwave | speachy: Problem is still present on c7fb319151 :-( |
| 21:42:30 | _bilgus | Airwave this was the rocker and which theme? |
| 21:44:15 | Airwave | _bilgus: https://themes.rockbox.org/index.php?themeid=2054&target=agptekrocker |
| 21:46:54 | | Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) |
| 21:47:22 | _bilgus | hmm let me check at head but the version from a few hours ago does not show it |
| 21:48:57 | _bilgus | ah nm I see them in between the icons? |
| 21:50:25 | _bilgus | @airwave |
| 21:53:55 | _bilgus | speachy after further review I feel you are probably right about set_vp_buffer |
| 21:55:15 | | Quit MrZeus_ (Ping timeout: 268 seconds) |
| 21:57:15 | _bilgus | the changes I made in that same commit tie it to screen types |
| 22:00 |
| 22:02:50 | Airwave | _bilgus: Yeah in between the icons |
| 22:03:01 | Airwave | And around part of the main screen showing the menu options |
| 22:03:13 | _bilgus | ok I know what I'm looking for now I'll track it down |
| 22:03:29 | Airwave | If you try going into Now Playing and then back you'll see how it's supposed to look |
| 22:03:45 | Airwave | Nice, let me know if I can help in any way |
| 22:15:18 | braewoods | speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2932/ |
| 22:15:25 | braewoods | speachy: tested working on my iriver h320 |
| 22:16:43 | _bilgus | nice sounds like progress |
| 22:17:10 | _bilgus | and mendel_munkis figured out the fuze+ screen flip Issue it appears |
| 22:17:42 | braewoods | i'll be doing some more rework on this module but one problem at a time |
| 22:18:26 | braewoods | it seems to consistently erase and reprogram 64K sectors in an unused region |
| 22:18:27 | braewoods | just fine |
| 22:18:52 | braewoods | i switched patterns every time i did a retest and it produced new results in the ROM dump |
| 22:23:11 | _bilgus | you might want to set some checksumming |
| 22:23:32 | _bilgus | even a simple xor over the buffer would be enough |
| 22:25:56 | braewoods | _bilgus: eh? |
| 22:26:23 | braewoods | i just did basic tests with constant values. why would i use a checksum? |
| 22:27:19 | _bilgus | to check for run len errors |
| 22:27:57 | braewoods | _bilgus: i still don't follow... |
| 22:28:15 | braewoods | anyway the original code was doing checksums where it added everything up |
| 22:28:16 | _bilgus | and really random data would be better checksummed in and again out |
| 22:29:00 | _bilgus | well you said it'd brick the device so I'd got a bit further to make sure everything is going right |
| 22:29:22 | braewoods | _bilgus: ... yes, the original code does that already? |
| 22:29:30 | braewoods | it's still in effect. |
| 22:29:38 | _bilgus | ah ok |
| 22:29:48 | braewoods | i'm just revisiting it all from the bottom-up. |
| 22:29:55 | braewoods | making sure stuff works as expected |
| 22:30:03 | braewoods | for the H320 then i will retest on an H120 |
| 22:30:19 | _bilgus | a wise decision you already found that trap stuff I HAD NO IDEA it was possible |
| 22:30:51 | _bilgus | oh h320 is fixed with this patch i'll try to include Airwaves issue in it |
| 22:32:17 | _bilgus | I had to go back to setting a NULL buffer but I just set both screen viewports to default so you have to reselet the viewport to a screen to ensure NULL buffers don't get released into the wild |
| 22:32:35 | _bilgus | which the skin engine does already |
| 22:32:57 | _bilgus | reselect |
| 22:33:15 | braewoods | basically the flash commands are nearly identical between the H120 and H320 |
| 22:33:18 | braewoods | slight difference |
| 22:33:26 | braewoods | so i needed to rework them |
| 22:33:41 | braewoods | i mostly did that to switch to an officially sanctioned method of waiting for rom completion |
| 22:33:54 | braewoods | as in, it's one of the two methods supported by the flash |
| 22:34:06 | braewoods | toggle bit was the easiest to implement |
| 22:34:41 | _bilgus | no clue what toggle bit is |
| 22:35:01 | _bilgus | setting and waiting for it to clear? |
| 22:35:06 | braewoods | Not at all. |
| 22:35:24 | braewoods | You keep checking DQ6 (the bit/pin that toggles) until it stops changing. |
| 22:35:37 | braewoods | via reading from a special memory locaiton |
| 22:36:04 | braewoods | https://www.rockbox.org/wiki/pub/Main/DataSheets/SST39VF320X_driver_example.txt |
| 22:36:11 | braewoods | checks |
| 22:36:13 | braewoods | Check_Toggle_Ready |
| 22:36:37 | braewoods | it's the bit masked in 0x0040 |
| 22:36:48 | braewoods | the data pins start at DQ0 |
| 22:36:52 | braewoods | and DQ6 is the 7th bit |
| 22:36:56 | braewoods | ergo, 0x40 |
| 22:37:31 | braewoods | i was stumped at first then i realized the datasheet starts it from 0 |
| 22:37:33 | braewoods | lol |
| 22:37:51 | _bilgus | what an odd method the must have broken out a connection off the transistor driving the flash write |
| 22:38:13 | braewoods | it's available in both data sheets for the 2 ROM chips |
| 22:38:17 | braewoods | so i intend to just use that |
| 22:38:27 | _bilgus | hell yeah ref code is king |
| 22:38:40 | braewoods | just the newer one asks you to wait 1 US after the toggle bit is done |
| 22:38:45 | _bilgus | compared to that I assume RE stuff lol |
| 22:39:02 | braewoods | the old code did... |
| 22:39:07 | braewoods | != 0xffff for erases |
| 22:39:09 | _bilgus | probably wise in both |
| 22:39:14 | braewoods | and == data for writes |
| 22:39:18 | braewoods | i didn't feel that was too safe |
| 22:39:43 | braewoods | it worked but it didn't feel like it was the proper method since it wasn't how it actually worked |
| 22:40:17 | *** | Saving seen data "./dancer.seen" |
| 22:40:31 | braewoods | the only other caveat i might have issues with is |
| 22:40:43 | braewoods | whether the lowest 32K is write protected or not. |
| 22:40:49 | braewoods | the new chip supports it |
| 22:40:55 | braewoods | err 64k |
| 22:41:09 | braewoods | but it has to be enabled by the PCB designers |
| 22:41:11 | braewoods | so |
| 22:41:19 | braewoods | i have *no* idea if it is actually in effect |
| 22:41:28 | braewoods | only way to know is to try it |
| 22:41:46 | braewoods | if it is then i have a problem i need to overcome |
| 22:41:57 | braewoods | but as was said, it's hazardous |
| 22:42:01 | _bilgus | well little risk of brick if not so thats good I guess |
| 22:42:11 | braewoods | but i need to know |
| 22:42:15 | braewoods | either way |
| 22:42:31 | braewoods | and the official routine for it will fuck me over if it's wrong |
| 22:42:34 | braewoods | and it is WP |
| 22:42:38 | braewoods | it assumes it isn't |
| 22:42:40 | braewoods | so |
| 22:42:43 | _bilgus | I wonder if we could xray something like that |
| 22:42:45 | braewoods | i need to find out if it is |
| 22:43:06 | _bilgus | assuming the density wasn't too high it'd probably work |
| 22:43:13 | braewoods | anyway |
| 22:43:18 | braewoods | i'll be testing that later |
| 22:43:28 | braewoods | i need to be able to restore the boot sector if it does work |
| 22:43:33 | _bilgus | be able to trace the pcb non destructively |
| 22:43:55 | _bilgus | I guess the next thing is find someone willing to do that |
| 22:44:10 | braewoods | i'm just going to take the risk and find out |
| 22:44:17 | braewoods | i have some ideas for how to minimize my risks |
| 22:44:32 | _bilgus | I'm saying if it is then how to find the proper pin |
| 22:44:37 | braewoods | oh. |
| 22:44:38 | braewoods | right. |
| 22:44:41 | braewoods | but one thing at a time. |
| 22:44:55 | _bilgus | yeah carts dont work too well infront |
| 22:45:05 | braewoods | i have to confirm it is even a problem |
| 22:45:17 | braewoods | just because the chip has it doesn't mean it is active |
| 22:45:38 | braewoods | the DS states that the WP# is only active if connected AND held low |
| 22:45:44 | braewoods | otherwise it is high high internally |
| 22:46:03 | braewoods | held high |
| 22:46:07 | _bilgus | lol it appears your issue and Airwaves are one in the same |
| 22:46:50 | _bilgus | nice back to my quest to knock off some of the size bloat from the past week |
| 22:47:40 | | Quit paulk-leonov (Ping timeout: 260 seconds) |
| 22:55:12 | | Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) |
| 22:55:36 | | Quit prof_wolfff (Ping timeout: 260 seconds) |
| 23:00 |
| 23:03:00 | fs-bluebot | Build Server message: New build round started. Revision c5c17fa, 293 builds, 8 clients. |
| 23:03:22 | _bilgus | Airwave, it should be fixed when this build round completes |
| 23:03:37 | _bilgus | please verify at your leisure |
| 23:04:03 | Airwave | _bilgus: Nice, I'll test it out tomorrow. Thanks for the work on this! |
| 23:04:45 | | Quit cockroach (Quit: leaving) |
| 23:05:01 | _bilgus | No problem we appreciate all the testing and dealing with our construction mess |
| 23:06:49 | Airwave | Issues pop up sometimes, but mostly it's very stable in my experience |
| 23:07:04 | braewoods | there we go. just erased the test region so the bits are back to normal. |
| 23:08:43 | mendel_munkis | I would appreciate it if someone with a fuze+ can confirm that g#2928 doesn't case a noticeable screen slowdown. |
| 23:08:45 | fs-bluebot | Gerrit review #2928 at http://gerrit.rockbox.org/r/2928 : Fuze+: Fix misplaced rectangle when lcd_flip set by Moshe Piekarski |
| 23:11:20 | braewoods | _bilgus: it's no longer glitching out |
| 23:11:56 | _bilgus | good now lets hope thats the last of this |
| 23:12:30 | _bilgus | mendel_munkis, its not my DD but I'll try it out back and forth |
| 23:12:48 | mendel_munkis | thanks. |
| 23:13:40 | _bilgus | I assume the code path hasn't diverged so much that I need to try two diff builds or should I look at old vs new too? |
| 23:15:14 | mendel_munkis | I am refering to old vs new. turning on or off flip shouldn't have an effect on the performance. |
| 23:15:38 | | Quit paulk-leonov (Ping timeout: 264 seconds) |
| 23:16:17 | | Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) |
| 23:22:08 | fs-bluebot | Build Server message: Build round completed after 1149 seconds. |
| 23:22:10 | fs-bluebot | Build Server message: Revision c5c17fa result: All green |
| 23:22:12 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:28:20 | _bilgus | ok so then between builds |
icon identifies that the person is a core developer (has commit access).