| 00:02:50 | massa | pamaury: I boot to original apple firmware and then connect the device to PC - so I always have to power down and up after an upload |
| 00:03:12 | pamaury | massa: ok |
| 00:05:22 | pamaury | massa: I think I found the problem |
| 00:05:48 | massa | pamaury: the crash is persistent - I uploaded the zip here: http://www.mohrenclan.de/rockbox/ipodvideo_with_g%231499_2017-01-15_23-58.zip |
| 00:06:06 | massa | (map and so on is included) |
| 00:08:39 | pamaury | massa: can you changes those this line: in apps/gui/skin_engine/skin_parser.c: |
| 00:08:49 | pamaury | change skin_buffer = ALIGN_UP(skin_buffer, 2); /* align on 4-byte boundary */ |
| 00:08:49 | pamaury | into skin_buffer = ALIGN_UP(skin_buffer, 4); /* align on 4-byte boundary */ |
| 00:08:55 | pamaury | (ie 2 becomes 4) |
| 00:09:10 | pamaury | massa: what is the backtrace you see ? |
| 00:10:12 | | Join shmibs [0] (~shmibs@shmibbles.me) |
| 00:11:47 | massa | pamaury: http://www.mohrenclan.de/rockbox/Rockbox_ipodvideo_crash.jpg |
| 00:16:19 | pamaury | yeah that sounds about right |
| 00:16:28 | pamaury | can you try with the change I suggested in skin_parser.c ? |
| 00:16:44 | massa | it's building |
| 00:19:47 | [Saint] | ParkerR: Our threading model pisses off the Android Run Time as it doesn't like external calls. There's an almighty great hack up on gerrit that pushes what it's bitching about into the button queue, but it makes the user experience less than desirable. |
| 00:21:49 | [Saint] | The Dalvik Run Time was much more forgiving in this regard. Google has been on a slow march to making using the Native Development Kit unreasonably annoying for years. |
| 00:21:59 | massa | pamaury: with the change it works again :-) |
| 00:23:34 | ParkerR | [Saint], Ahh |
| 00:24:46 | Bilgus | [Saint], I think I figured out why the choice of tables was made for the time values that have a large range.. Memory, the whole list gets loaded at once, I suppose this is for list acceleration to work properly |
| 00:25:53 | pamaury | massa: great |
| 00:25:57 | pamaury | I upaded the gerrit task |
| 00:26:14 | Bilgus | I find that strange for contiguous integer values though |
| 00:26:31 | | Quit xorly (Ping timeout: 260 seconds) |
| 00:29:22 | pamaury | massa: thanks for your time |
| 00:29:25 | pamaury | going to bed now :) |
| 00:29:37 | * | massa likes what pamaury did today :-) |
| 00:30:12 | massa | I'm also going to bed now - have to work tomorrow - actually today ;-) |
| 00:30:24 | massa | Bye everybody! |
| 00:30:35 | __builtin | bye! |
| 00:30:39 | | Quit massa () |
| 00:34:05 | chrisjj | __builtin So what has to happen for this change to reach the master? |
| 00:35:42 | __builtin | well, after it's been +2'd you need to submit it |
| 00:37:51 | | Join Strife1989 [0] (~quassel@adsl-98-67-59-222.mcn.bellsouth.net) |
| 00:40:55 | chrisjj | massa: All four of you sim binaries run here (Win 7 Pro 64-bit) inc. play audio etc. |
| 00:41:09 | chrisjj | OOI, what's your purpose with the 64-bit variants? |
| 00:41:28 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 00:41:31 | *** | Saving seen data "./dancer.seen" |
| 00:42:13 | | Quit pamaury (Remote host closed the connection) |
| 00:43:22 | | Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-15-142.telecom.by) |
| 00:48:28 | | Quit ender` (Quit: A man should live forever or die trying. — Spider Robinson) |
| 00:49:00 | | Quit girafe (Read error: Connection reset by peer) |
| 00:58:04 | | Quit Galois (Ping timeout: 252 seconds) |
| 00:59:23 | [Saint] | Perhaps even more annoyingly, the 'almighty great hack' to push threading into the button queue only works on Android between 5.0 and 6.1.1 |
| 00:59:55 | [Saint] | 7.0+ adds further levels of craziness for anyone unfortunate enough to dare use native code in their application. |
| 01:00 |
| 01:01:47 | [Saint] | chrisjj: I....what? |
| 01:01:47 | [Saint] | I know damn well I'm going to regret asking this, but what on Earth do you mean regarding a "purpose" for 64bit native binaries? |
| 02:00 |
| 02:23:19 | | Quit Senji (Ping timeout: 252 seconds) |
| 02:26:16 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:41:33 | *** | Saving seen data "./dancer.seen" |
| 02:43:28 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 02:56:21 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
| 03:00 |
| 03:05:36 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 03:22:12 | | Join zoid [0] (~zoid@unaffiliated/taxationistheft) |
| 03:22:40 | zoid | Does Rockbox support video playback? |
| 03:29:58 | | Quit snow_bckspc (Quit: User was destroyed by a weapon of mass destruction.) |
| 03:30:45 | | Join snow_bckspc [0] (~snow_bcks@ganon.dot-server.net) |
| 03:47:01 | | Join clockwork [0] (461dac7c@gateway/web/freenode/ip.70.29.172.124) |
| 03:47:35 | | Quit clockwork (Client Quit) |
| 04:00 |
| 04:07:19 | | Join Strife89 [0] (~quassel@adsl-98-80-191-141.mcn.bellsouth.net) |
| 04:08:10 | | Quit Strife1989 (Ping timeout: 240 seconds) |
| 04:10:35 | | Quit idonob_ (Ping timeout: 240 seconds) |
| 04:16:30 | soap | for certain definitions of the word "video" |
| 04:16:49 | soap | https://www.rockbox.org/wiki/PluginMpegplayer |
| 04:17:24 | soap | zoid, |
| 04:40:16 | | Quit mc2739 (Ping timeout: 260 seconds) |
| 04:41:35 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:15:08 | | Join _mt__ [0] (~MT@2601:482:4402:7b60:f44b:bcda:8e41:edd5) |
| 05:16:27 | | Quit _mt_ (Ping timeout: 256 seconds) |
| 05:22:41 | | Quit _mt__ (Ping timeout: 256 seconds) |
| 05:29:07 | | Join _mt_ [0] (~MT@2601:482:4402:7b60:8025:71f8:9d38:6cf7) |
| 05:41:41 | | Join alyssa [0] (~alyssa@unaffiliated/alyssa) |
| 05:42:16 | | Part alyssa |
| 06:00 |
| 06:06:53 | | Quit _mt_ (Ping timeout: 256 seconds) |
| 06:08:35 | | Quit bray90820 (Ping timeout: 256 seconds) |
| 06:14:14 | zoid | Thanks soap |
| 06:15:58 | | Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) |
| 06:23:41 | | Quit TheSeven (Ping timeout: 258 seconds) |
| 06:24:02 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:41:39 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:05:43 | | Join idonob_ [0] (~Owner@50.67.32.65) |
| 07:32:51 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 07:43:39 | parchd | morning |
| 07:54:16 | comradekingu | soap: how cool |
| 08:00 |
| 08:01:31 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 08:01:31 | | Quit pixelma (Quit: .) |
| 08:01:42 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
| 08:01:45 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
| 08:15:38 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 08:25:40 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:41:40 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:13:58 | | Join petur [0] (~petur@91.183.48.77) |
| 09:13:58 | | Quit petur (Changing host) |
| 09:13:58 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:14:26 | | Quit xorly (Ping timeout: 260 seconds) |
| 09:39:29 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:44:17 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 09:52:34 | | Quit idonob_ (Ping timeout: 240 seconds) |
| 09:54:58 | | Join idonob_ [0] (~Owner@50.67.32.65) |
| 09:55:15 | | Quit xorly (Ping timeout: 240 seconds) |
| 10:00 |
| 10:02:13 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 10:09:28 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:f130:e0b0:3ab9:cebf) |
| 10:15:00 | | Join Senji [0] (~Senji@85.187.103.250) |
| 10:16:13 | | Quit pamaury (Ping timeout: 256 seconds) |
| 10:19:47 | | Quit krnlyng (Ping timeout: 258 seconds) |
| 10:21:42 | gevaerts | bah |
| 10:21:52 | gevaerts | Guess which commit broke checkwps |
| 10:22:50 | gevaerts | jhMikeS: can you have a look at checkwps? It's apparently been broken since "rework filesystem" |
| 10:22:54 | | Quit MrZeus (Read error: Connection reset by peer) |
| 10:31:23 | | Join MrZeus [0] (~MrZeus@81.144.218.162) |
| 10:32:58 | | Join krnlyng [0] (~liar@77.117.40.122.wireless.dyn.drei.com) |
| 10:41:43 | *** | Saving seen data "./dancer.seen" |
| 10:48:07 | | Quit petur (Read error: Connection reset by peer) |
| 10:48:17 | | Quit paulk-blaze (Remote host closed the connection) |
| 10:48:18 | | Join petur [0] (~petur@91.183.48.77) |
| 10:48:18 | | Quit petur (Changing host) |
| 10:48:18 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 10:50:18 | | Join MrZeus_ [0] (~MrZeus@81.144.218.162) |
| 10:53:40 | | Quit MrZeus (Ping timeout: 240 seconds) |
| 10:54:06 | jhMikeS | gevaerts: sure |
| 10:54:10 | | Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) |
| 10:55:00 | jhMikeS | gevaerts: what's happening? |
| 10:59:11 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 11:00 |
| 11:00:21 | | Join xorly [0] (~xorly@193.85.203.185) |
| 11:00:25 | | Quit elensil (Ping timeout: 256 seconds) |
| 11:02:38 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 11:05:17 | | Quit xorly (Ping timeout: 252 seconds) |
| 11:06:14 | | Join xorly [0] (~xorly@193.85.203.185) |
| 11:09:28 | gevaerts | jhMikeS: looks like open_utf8() in skin_parser.c:2468 is failing, returning -3 |
| 11:10:07 | | Quit petur (Read error: Connection reset by peer) |
| 11:12:30 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:12:53 | * | gevaerts looks at sim_open() |
| 11:12:56 | jhMikeS | gevaerts: is it supposed to run with a simulated tree or as completely native |
| 11:13:03 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:f130:e0b0:3ab9:cebf) |
| 11:13:19 | jhMikeS | open could be hooked to the wrong stuff |
| 11:14:10 | | Quit Bray90820 (Ping timeout: 240 seconds) |
| 11:14:14 | gevaerts | simulated, I think |
| 11:14:20 | | Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) |
| 11:15:34 | gevaerts | OK, so what's going on is that ospath in sim_open() is now suddenly relative |
| 11:16:22 | | Quit bzed (Ping timeout: 256 seconds) |
| 11:17:12 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 11:17:58 | | Join petur [0] (~petur@91.183.48.77) |
| 11:17:58 | | Quit petur (Changing host) |
| 11:17:58 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 11:18:41 | gevaerts | As in, I pass /tmp/wavy/wps/wavy.wps to checkwps, and it ends up looking for ./tmp/wavy/wps/wavy.wps |
| 11:18:42 | jhMikeS | hmmm, I see a '.' being prepended |
| 11:19:05 | jhMikeS | there's probably a reason, like no base dir being provided |
| 11:19:26 | jhMikeS | sim_root_dir |
| 11:20:29 | gevaerts | That one probably should be / instead of . I guess |
| 11:20:57 | gevaerts | Or would that break relative paths? |
| 11:21:00 | * | gevaerts tries |
| 11:21:52 | jhMikeS | just ""? |
| 11:22:36 | | Quit pamaury_ (Ping timeout: 248 seconds) |
| 11:22:37 | gevaerts | or "" work |
| 11:22:46 | jhMikeS | "" will just prepend nothing |
| 11:23:16 | gevaerts | "/" or "" work for absolute paths, neither work for relative. I don't actually know if relative has ever worked there in that way though |
| 11:23:17 | | Quit petur (Read error: Connection reset by peer) |
| 11:23:43 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 11:24:48 | gevaerts | Right, sim_get_os_path doesn't do relative paths at all |
| 11:26:47 | * | gevaerts tries to figure out if the themesite uses absolute paths |
| 11:29:12 | jhMikeS | normally it simulates in the simdisk directory and so rejects them |
| 11:29:45 | jhMikeS | and relative bits that would take you above the sim root would be clipped |
| 11:30:09 | * | gevaerts nods |
| 11:30:47 | jhMikeS | not even sure why it builds that file for an external utility anyway |
| 11:31:14 | gevaerts | Looks like things work fine for checkwps if I comment out the absolute path check |
| 11:31:30 | gevaerts | Maybe add an #ifndef __PCTOOL__ around that? |
| 11:31:30 | | Quit TorC (Read error: Connection reset by peer) |
| 11:31:44 | gevaerts | The database tool presumably will have similar issues |
| 11:33:11 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 11:36:15 | | Quit Senji (Ping timeout: 240 seconds) |
| 11:37:19 | gevaerts | jhMikeS: http://paste.debian.net/908951/ makes things work for me. Not sure if that's a clean enough fix, and I have no idea if the database tool was broken or gets fixed (I don't actually know how it works...) |
| 11:37:59 | gevaerts | I'm not sure if I want to get into bypassing sim_*() for checkwps and database though, IIRC that set of macros is poisonous and bites if you don't spend a week on them |
| 11:38:54 | jhMikeS | which? |
| 11:39:23 | jhMikeS | you mean the ones that map regular posix calls to sim_*? |
| 11:39:48 | gevaerts | Yes |
| 11:40:26 | gevaerts | I have vague but not very nice memories of those from when the app builds were added |
| 11:40:35 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:9812:c041:b256:ada3) |
| 11:40:39 | jhMikeS | I'm pretty sure I spent well over a week on them. It was completely redone |
| 11:41:12 | gevaerts | Ah, then you know what they were like :) |
| 11:41:38 | jhMikeS | indeed |
| 11:41:46 | | Quit petur (Read error: Connection reset by peer) |
| 11:41:49 | * | jhMikeS has seen some shit |
| 11:42:13 | | Join petur [0] (~petur@91.183.48.77) |
| 11:42:13 | | Quit petur (Changing host) |
| 11:42:13 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 11:42:43 | gevaerts | If you can make __PCTOOL__ (i.e. database and checkwps) easily use straight open(), go for it. Otherwise, I think just disabling that path_is_absolute() check for them is probably find |
| 11:42:47 | gevaerts | *fine |
| 11:42:50 | jhMikeS | I'm trying to discern the true intent of using sim api functions |
| 11:43:35 | jhMikeS | since really it only enforces native target-like behavior to parsing a path |
| 11:45:47 | jhMikeS | then again, maybe you want that if parsing is supposed to be in the context of running on a target |
| 11:48:14 | jhMikeS | you're supposed to run the tool with the cwd being "root"? |
| 11:48:28 | gevaerts | Hmmm, database probably still needs a sim_root_dir of ".". It's supposed to be run from the target directory |
| 11:49:03 | gevaerts | checkwps on the other hand can (or could) be run from anywhere |
| 11:49:30 | gevaerts | So for database the current behaviour is probably correct |
| 11:49:33 | jhMikeS | it sounds like it shouldn't be using sim_ functions at all |
| 11:51:10 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 11:56:31 | | Join Senji [0] (~Senji@85.187.103.250) |
| 12:00 |
| 12:00:22 | jhMikeS | maybe it should be an app build instead of a sim? |
| 12:02:08 | | Quit Senji (Ping timeout: 258 seconds) |
| 12:04:40 | gevaerts | checkwps as an app build does indeed work |
| 12:05:24 | gevaerts | But again, not sure about database. I *think* that one needs to have the sim's concept of a root directory |
| 12:05:40 | gevaerts | Which means we have to split up __PCTOOL_ for those |
| 12:08:55 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 12:13:21 | | Quit ZincAlloy (Quit: Leaving.) |
| 12:14:42 | jhMikeS | why? |
| 12:15:17 | gevaerts | I don't know for sure :) |
| 12:16:01 | gevaerts | I mean, I'm assuming that the database stores pathnames, and those pathnames have to be absolute within the context of the rockbox root |
| 12:16:26 | gevaerts | I don't know if they will be correct if the sim logic isn't used |
| 12:16:41 | jhMikeS | true |
| 12:16:52 | gevaerts | Anyway, assuming the database has to remain on sim logic, http://paste.debian.net/908960/ seems to fix things for me |
| 12:16:57 | pamaury | It would be logical that the database stores absolute name and wps store relative names. |
| 12:17:25 | gevaerts | that moves checkwps to app logic and leaves database on sim logic |
| 12:17:52 | gevaerts | (and re-adds win32 support for both, which is of course untested) |
| 12:19:31 | jhMikeS | I'm still trying to figure out how the old checkwps got its sim root |
| 12:20:38 | gevaerts | By accident, probably :) |
| 12:20:59 | gevaerts | Did it actually use the sim_*() functions? |
| 12:21:04 | jhMikeS | is APPLICATION defined when building those? |
| 12:21:51 | gevaerts | It isn't *now* |
| 12:22:08 | | Quit paulk-blaze (Quit: Leaving) |
| 12:22:27 | jhMikeS | wait, so they used to define APPLICATION |
| 12:22:28 | jhMikeS | ? |
| 12:23:10 | gevaerts | No idea :) |
| 12:23:37 | gevaerts | I know it's not defined now, but I didn't check the old code |
| 12:26:53 | jhMikeS | no need for sim_root_dir would explain it because it just defined as a noop |
| 12:27:03 | jhMikeS | was defined |
| 12:41:45 | *** | Saving seen data "./dancer.seen" |
| 12:46:27 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
| 12:48:37 | | Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
| 12:50:55 | jhMikeS | gevaerts: Previously, CheckWPS didn't include sim file code at all |
| 12:51:24 | jhMikeS | it actually shouldn't be there |
| 12:53:44 | jhMikeS | and the database tool doesn't seem to even compile becauase of some multivolume junk |
| 12:54:43 | * | jhMikeS is of course refers to a checkout of the revision just before big FS code change |
| 12:57:10 | jhMikeS | sim_* was SIMULATOR || DBTOOL |
| 13:00 |
| 13:02:01 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 13:11:43 | jhMikeS | gevaerts: who does the honors? you did the patch and I think it's right |
| 13:14:29 | gevaerts | jhMikeS: go ahead. I'm a bit busy... |
| 13:18:12 | jhMikeS | np |
| 13:31:39 | fs-bluebot | Build Server message: New build round started. Revision 4f7fea2, 255 builds, 13 clients. |
| 14:00 |
| 14:02:42 | | Quit xorly (Ping timeout: 245 seconds) |
| 14:27:36 | gevaerts | jhMikeS: looks like the themesite can properly check themes again! (and then promptly die, but I claim that that's not checkwps' fault) |
| 14:31:29 | | Quit TorC (Read error: Connection reset by peer) |
| 14:33:12 | | Join xorly [0] (~xorly@193.85.203.185) |
| 14:34:02 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 14:40:46 | jhMikeS | haha |
| 14:41:48 | *** | Saving seen data "./dancer.seen" |
| 14:56:27 | chrisjj | Chrisjj |
| 15:00 |
| 15:01:37 | * | chrisjj sees http://themes.rockbox.org/ This site can’t be reached themes.rockbox.org took too long to respond. |
| 15:02:24 | chrisjj | Which is no real surprise since forums. and themes have gone down just about every day for the last month. |
| 15:02:49 | chrisjj | What exactly is the DoS attack that's been blames for this? |
| 15:03:23 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:c9df:62a2:1d87:d501) |
| 15:04:07 | chrisjj | And who would want to attack rockbox.org anyway? |
| 15:06:31 | gevaerts | There is no DoS attack |
| 15:17:34 | | Quit wodz (Quit: Ex-Chat) |
| 15:17:54 | Bilgus | but but but oh yeah https://www.rockbox.org/irc/log-20161219#04:30:27 |
| 15:24:04 | chrisjj | OK, so people variously are saying it is DoS, and it is not a D-DoS, and it is not an attack, and it is triggering an Apache bug, and it might get fixed in a month or so. |
| 15:24:44 | * | chrisjj hopes forum users are sufficiently patient. |
| 15:32:37 | | Quit petur (Read error: Connection reset by peer) |
| 15:47:39 | pamaury | scorche: what is the apache bug ? It is because of an old apache installation or bad config ? |
| 15:48:34 | gevaerts | pamaury: at this point I somehow doubt it's an apache issue |
| 15:49:29 | gevaerts | What I've seen the last few days is that if I run a script (over an ssh login) that produces a large amount of output, the server dies |
| 15:49:59 | pamaury | dies as in ? reboots ? freeze ? |
| 15:50:24 | gevaerts | My connection freezes and new connections time out |
| 15:50:50 | chrisjj | What, no watchdog to reset the server?? :-) |
| 15:52:09 | pamaury | gevaerts: that sounds like a hardware problem potentially |
| 15:53:23 | gevaerts | Or possibly a bad network driver, but yes, given that it used to work fine and that there has not been a major OS upgrade, hardware is not unlikely |
| 15:53:27 | | Join petur [0] (~petur@91.183.48.77) |
| 15:53:27 | | Quit petur (Changing host) |
| 15:53:27 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 15:55:10 | pamaury | would a migration be complicated ? I don't mind hosting it if it helps. Because the forums are down a lot these days |
| 15:56:12 | gevaerts | Not sure if that's needed. I believe scorche also uses the server for other things, so if it's hardware he presumably also would like to see it fixed |
| 15:59:19 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 16:00 |
| 16:00:10 | chrisjj | I have a theory on why memDFS battery_bench.txt (ZEN charging an empty battery) only ever gets one entry. The watchdog is rebooting the device after the first one, leaving the device with screen looking exactly the same, but with the BB plugin stopped. |
| 16:04:04 | pamaury | chrisjj: did you benchmark lcd sleep vs no lcd sleep ? |
| 16:05:14 | chrisjj | No. I'm still trying trying to benchmark memDFS. And failing due to BSoPO. |
| 16:06:10 | chrisjj | If your lcd* are on the same base, I think the same problem will prevent me benchmarking them too. |
| 16:06:22 | __builtin | chrisjj: what the heck is a "BSoPO"? |
| 16:06:40 | chrisjj | Black Screen of Power Off. |
| 16:07:32 | chrisjj | ZEN builds since Dec are mysteriously spontaneously going to power-off state after anything from 3min to 3hr after clean boot. |
| 16:08:02 | chrisjj | Depends on some variables, but I haven't pinpointed them |
| 16:08:38 | pamaury | chrisjj: instead of benchmarking memdfs, then it would be better to find the offending commit don't you think ? |
| 16:08:57 | chrisjj | Be my guest! :-) |
| 16:09:01 | chrisjj | Or tell me how to. |
| 16:10:09 | pamaury | what is the last know working commit again ? |
| 16:10:12 | pamaury | *known |
| 16:10:14 | chrisjj | Re my theory at [15:00], I have no idea what's angering the watchdog. Not memDFS it seems - the same issue shows on non-memDFS build be68b6a7b-170109. And though most BSoPO have appeared in playback, there's no playback in the case. Device is doing nothing but charging. |
| 16:11:42 | chrisjj | The last known (to me) /build/ free from BSoPO is lcd_fix - 45697a0bf-161212. |
| 16:12:41 | chrisjj | And yes I agree, finding the offender should be the priority. |
| 16:14:43 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 16:17:12 | * | chrisjj testing IRC after wrinkle |
| 16:17:28 | * | chrisjj wonders how many pamaury clones exist. |
| 16:18:52 | pamaury_ | chrisjj: ok, so we are clear: I will send you builds with modified source, where the modification is g#1503 (disable watchdog) so you can't complain about watchdog |
| 16:18:53 | fs-bluebot | Gerrit review #1503 at http://gerrit.rockbox.org/r/1503 : imx233: disable watchdog for debugging (DON'T PUSH) by Amaury Pouly |
| 16:20:15 | chrisjj | Thanks. |
| 16:20:18 | chrisjj | Feature suggestion: Setting to disable reset on watchdog. |
| 16:20:47 | chrisjj | 'Cos I know I am not the only one who will want this for ZEN testing. |
| 16:22:12 | * | pamaury_ notes that g#1503 is untested and does not promise in any possible way that this could achieve what he claims |
| 16:22:13 | fs-bluebot | Gerrit review #1503 at http://gerrit.rockbox.org/r/1503 : imx233: disable watchdog for debugging (DON'T PUSH) by Amaury Pouly |
| 16:23:36 | pamaury_ | chrisjj: please test https://www.dropbox.com/s/6rhrcf7z430vsjn/rockbox_zen_cd8b33327_nowdt.zip?dl=0 |
| 16:24:53 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 16:29:51 | chrisjj | OK, but to save me time adding a another device to the set, first could you help me confirm my theory of [15:00]? |
| 16:31:10 | chrisjj | I.e. how can I determine whether a default-settings ZEN on charge on PC in non-USB-mode is getting watchdog reboots? |
| 16:31:40 | chrisjj | Not that default settings means backlight slept. |
| 16:31:41 | pamaury_ | I can send you a build with HEAD + no watchdog if that helps |
| 16:31:51 | pamaury_ | if that's what you want |
| 16:32:38 | chrisjj | Perhaps the answer is: You would see the BL text for sure. (I don't know, since I know no way to test by manually angering the watchdog in this state.) |
| 16:33:57 | chrisjj | Thanks, but if there's an answer I can apply without changing any of the current four test devices, it would be good. |
| 16:34:53 | chrisjj | s/Thanks, but/Thanks for that build offer, but/ |
| 16:35:38 | pamaury_ | chrisjj: what about starting the device, plug usb with a holding a key so that you get charging but still rockbox. If the watchdog triggers, device reboots into bootloader usb mode |
| 16:36:19 | chrisjj | Ah, I should have thought of that. Thanks.Trying... |
| 16:37:08 | | Quit paulk-collins (Quit: Leaving) |
| 16:40:25 | | Quit pamaury_ (Ping timeout: 256 seconds) |
| 16:41:49 | *** | Saving seen data "./dancer.seen" |
| 16:57:41 | chrisjj | pamaury: I verified it using button reset to simulate watchdog reset). I.e. With Shortcut button held, connect to PC, wait for RB main menu. Press reset. Verify bootloader text appears and remains. |
| 16:58:41 | pamaury | of course |
| 16:58:57 | * | chrisjj is leaving nothing to chance. |
| 16:59:22 | chrisjj | I verified it using a playback that normally triggers a BSoPO. I.e. With Shortcut button held, connect to PC, wait for RB main menu, set a WMA playing. Wait for Verify bootloader text to appear and remain. Success. |
| 17:00 |
| 17:00:19 | chrisjj | (I think that also confirms somewhat that BSoPO is reset on watchdog. On internal power, it goes to power-off. On external power, it reboots.) |
| 17:01:37 | chrisjj | I tried this test on the [15:00] theory re charging... but got no BL. i.e. no watchdog reset. BUT this differs from the original instances in that the charge level is high. |
| 17:02:01 | chrisjj | I shall empty a battery and retry. |
| 17:03:03 | chrisjj | The comment the other day that firmware upgraders often require full charge got me thinking. |
| 17:03:05 | pamaury | it could also be a hard crash of the hardware |
| 17:03:41 | pamaury | a VDDD or other power rail brownout can do that |
| 17:04:12 | chrisjj | Any known way that this watchdog angering could occur at low charge and not high? |
| 17:05:09 | chrisjj | E.g. on a switch from the OF charger to the RB BL charger, or RB app charger? |
| 17:05:28 | pamaury | chrisjj: I am not sure I see the point of obsessing on memdfs since obviously there is a problem and we don't even know if it is caused by mem dfs or something else |
| 17:05:51 | chrisjj | I'm not obsessing on memDFS. This BSoPO is all over recent builds. |
| 17:05:54 | pamaury | removing mem dfs from the equation can only make it simpler |
| 17:06:10 | chrisjj | I have done. Problem remained. |
| 17:06:27 | pamaury | I sent you a build with no watchdog, did you test it ? |
| 17:06:44 | chrisjj | Not yet. As I said, I'm trying to conserve devices. |
| 17:07:27 | chrisjj | I have only six free for RB testing and am about to send you two. |
| 17:09:16 | pamaury | I don't understand what you are trying to do by testing a build that we know fail |
| 17:11:16 | chrisjj | I'm trying to find the conditions under which evasive fail can be reproduced, so that I/someone can do the bisect you suggested, to locate the culprit change. |
| 17:12:06 | chrisjj | If you know a better way, do say. |
| 17:12:07 | pamaury | I still don't understand: strart the device, play a huge playlist, check in 6 hours if the device is still running |
| 17:13:27 | pamaury | and check battery_bench and/or the running time in the system menu |
| 17:13:46 | pamaury | (since on reset, battery bench will not restart and the running time will be cleared) |
| 17:14:22 | chrisjj | That's proven insufficient. E.g. I had that test fail, then pass under possibly changed conditions, then fail on a builds from you differing in (probably only) an LCD fix. |
| 17:15:35 | pamaury | then what do you suggest ? Unless you have a 100 reliable way of triggering the bug, that's called real life debugging I'm afraid |
| 17:15:42 | pamaury | * 100% |
| 17:16:04 | chrisjj | I had avoided battery bench since that looks like a (possibly the) condition causing the BSoOD, but I am near to eliminating that possibility so can hopefully return to it. |
| 17:16:28 | chrisjj | Are you sure running time is reliably cleared by watchdog reset? |
| 17:17:48 | pamaury | unless I'm mistaken it's the running time since the device booted (ie not the cumulative runtime) so yes, it starts at 0 when rockbox loads and starts counting, it's not a hardware thing |
| 17:18:06 | pamaury | but otherwise by playback wouldn't be enough ? |
| 17:18:20 | chrisjj | FWIW (not much) the manual does not accord and IIRC (while forums down) I've seen comment saying Running Time does not work as expected. |
| 17:18:35 | pamaury | if the device resets, playback is not restarted |
| 17:18:55 | pamaury | thus: playback => no reset, no playback => reset/crash |
| 17:19:12 | chrisjj | Sorry, our [16:18]'s crossed and my [16:18] was about Running Time, not playback. |
| 17:19:36 | pamaury | I'm saying that I don't understand why you don't simply use playback |
| 17:19:51 | pamaury | that's clearly the best way to determine if a crashed happened imo |
| 17:20:29 | * | chrisjj powers-on ZEN, immediately reads Running Time, sees 14m |
| 17:20:52 | * | chrisjj powers-on second ZEN, immediately reads Running Time, sees 1h19m |
| 17:20:55 | pamaury | then maybe it's the cumulative running time |
| 17:21:12 | gevaerts | I believe (not sure!) it should be the time since it was last charged |
| 17:21:28 | pamaury | ah that would make sense |
| 17:21:58 | gevaerts | IIRC it's stored in nvram, which is simulated on most targets, which means it might not be updated if the device crashes |
| 17:22:02 | pamaury | manual says: |
| 17:22:05 | pamaury | Running Time: |
| 17:22:05 | pamaury | This item shows the cumulative overall runtime of your player since you either disconnected it from charging (in Rockbox) or manually reset this item. A manual reset is done through pressing any button, followed by pressing Select or Right. |
| 17:22:13 | * | chrisjj sees Top Time 1h18m, clear Top Top, resets unit, power-on, sees Top Time 1h18m. |
| 17:22:41 | * | chrisjj remains unimpressed by Running Time and Top Time, but will try power-down not reset. |
| 17:23:21 | * | gevaerts remains unimpressed by lots of things |
| 17:23:44 | * | chrisjj sees Top Time 1h18m, clears Top Top, powers-off, power-on, sees Top Time 1h18m. |
| 17:26:25 | * | chrisjj clears Running Time, clears Top Time, returns to main menu, powers-off, powers-on and sees Running Time and Top Time at 0h 0m Xs. Phew. |
| 17:28:23 | chrisjj | pamaury, Top Top is not updated if the device resets, so I'm guess yes you're right in suggesting it does not update in the device crashes. |
| 17:28:28 | * | pamaury thinks chrisjj hasn't answered the question of why playback isn't a reliable way of knowing if the devivce crashed |
| 17:28:33 | chrisjj | s/Top Top/Top Time/ |
| 17:29:28 | * | chrisjj assumes he wasn't sufficiently clear that the device can crash even when not playing. |
| 17:30:15 | chrisjj | However, we can see how far we get with playback. |
| 17:32:25 | pamaury | if the device can crash when no playing then it crash when playing |
| 17:32:36 | pamaury | *it can crash when playing |
| 17:33:34 | pamaury | I can't see how playing music makes it more likely to not trigger the bug, quite the opposite in fact |
| 17:34:22 | | Quit petur (Quit: Connection reset by beer) |
| 17:35:38 | chrisjj | I'll test more. |
| 17:35:48 | chrisjj | me goes AFK. |
| 17:39:38 | pixelma | well, if Running Time is currently that (1h18m) then if you reset Top Time it'll be set to current Running Time, that's to be expected |
| 17:47:42 | | Join Senji [0] (~Senji@85.187.103.250) |
| 18:00 |
| 18:00:11 | | Quit pamaury (Remote host closed the connection) |
| 18:17:51 | | Join Guest38272 [0] (2e7df91b@gateway/web/freenode/ip.46.125.249.27) |
| 18:41:51 | *** | Saving seen data "./dancer.seen" |
| 18:46:27 | | Quit xorly (Ping timeout: 240 seconds) |
| 18:48:56 | | Join duo8 [0] (~ZNC-SRV-H@116.96.90.249) |
| 18:51:39 | | Quit cc___ (Quit: WeeChat 1.6) |
| 18:55:58 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 18:59:05 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 19:00 |
| 19:08:09 | | Quit parchd (Ping timeout: 240 seconds) |
| 19:09:38 | | Part Guest38272 |
| 19:15:45 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
| 19:17:48 | | Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) |
| 19:19:56 | lebellium | gevaerts: thanks for the theme site |
| 19:20:21 | gevaerts | Oh, it's back up? |
| 19:20:39 | | Quit JdGordon (Ping timeout: 240 seconds) |
| 19:20:48 | lebellium | yep |
| 19:21:54 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 19:25:08 | gevaerts | The good thing is that I don't have to touch it anymore, so it might not die :) |
| 19:26:05 | lebellium | that's a good fix |
| 19:27:12 | __builtin | has anyone seen http://images.agptek.us/image/RockerUserManual.pdf yet? |
| 19:28:29 | __builtin | it doesn't look like it's running rockbox |
| 19:28:59 | lebellium | it was unclear if it should at release time |
| 19:30:54 | lebellium | I assume the question is: does it have the sufficient SoC for a future port |
| 19:32:09 | lebellium | "Gapless Playback: Set On/Off" I never understood why you'd like to set off gapless |
| 19:38:39 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 20:00 |
| 20:01:07 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 20:04:54 | pamaury | is the build server dead ? |
| 20:05:10 | pamaury | ah not it's just the bot |
| 20:06:32 | | Quit cc___ (Quit: WeeChat 1.6) |
| 20:07:09 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 20:08:49 | | Quit munch (Changing host) |
| 20:08:49 | | Join munch [0] (pls@unaffiliated/munch) |
| 20:08:49 | | Quit munch (Changing host) |
| 20:08:49 | | Join munch [0] (pls@gateway/shell/elitebnc/x-hjjqdjfndwontqqf) |
| 20:12:21 | * | pamaury is on a commit spree |
| 20:13:49 | lebellium | it will probably be hard to break your own record :) |
| 20:13:59 | __builtin | we should probably stage a Turing test just to make sure pamaury's human :P |
| 20:28:50 | pamaury | [Saint]: I know you care about settings, would you mind telling me what you think about g#1486 ? |
| 20:28:52 | fs-bluebot | Gerrit review #1486 at http://gerrit.rockbox.org/r/1486 : Implement speaker enable/disable on jack (un)plug by Amaury Pouly |
| 20:30:57 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
| 20:41:55 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:10:39 | __builtin | petur: your build client seems to be acting up, could you take a look? http://build.rockbox.org/shownewlog.cgi?rev=2bc5173;type=samsungyh820sim |
| 21:10:42 | __builtin | whois petur |
| 21:11:29 | | Join ungali [0] (ungali@162-202-67-158.lightspeed.livnmi.sbcglobal.net) |
| 21:11:29 | | Quit ungali (Changing host) |
| 21:11:29 | | Join ungali [0] (ungali@unaffiliated/ungali) |
| 21:24:52 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 21:31:40 | | Quit ungali (Remote host closed the connection) |
| 21:37:25 | | Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) |
| 21:58:57 | | Quit tchan (Ping timeout: 240 seconds) |
| 22:00 |
| 22:11:22 | petur | __builtin: I don't understand what's going on, I can do that sim build manually |
| 22:31:23 | | Quit skapazzo (Quit: leaving) |
| 22:31:33 | | Quit petur (Quit: Leaving) |
| 22:41:57 | *** | Saving seen data "./dancer.seen" |
| 22:45:33 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 22:46:24 | | Quit idonob_ (Ping timeout: 260 seconds) |
| 22:47:59 | | Join idonob_ [0] (~Owner@50.67.32.65) |
| 23:00 |
| 23:08:22 | chrisjj | pixelma, You'd think so, wouldn't you? Until you actually try it and find that resetting Top Time sets it's display to 0h0m0s, not Running Time. |
| 23:09:32 | chrisjj | And on ZEN doesn't itself set the variable at all. If the device crashes and gets reset by watchdog, or you power-off, your change is lost. |
| 23:11:31 | chrisjj | Workaround: after resetting Top Time, press Back twice. Once is insufficient. |
| 23:16:19 | pamaury | if you reset the top time, it will get reset to 0 but set to running time on the next update, which is basically as soon as you leave the system menu apparently |
| 23:16:35 | pamaury | of course on reset you loose everything, which is not very surprising |
| 23:25:52 | | Part robertd1 |
| 23:35:57 | pixelma | chrisjj: according to your description that happened after you also reset current Running Time as suspected |
| 23:36:05 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 23:49:06 | | Quit Senji (Ping timeout: 255 seconds) |
| 23:51:39 | | Quit pamaury (Ping timeout: 256 seconds) |
icon identifies that the person is a core developer (has commit access).