| Wizzup | freemangordon: can you remind me what I had to do for libsdl(2) ? | 10:25 |
|---|---|---|
| buZz | is it me or is phoenix.maemo.org really slow | 11:23 |
| buZz | grabbing last droid4 build at 300kb/s | 11:24 |
| freemangordon | Wizzup: pull latest from debian in our repo so I can make it build on leste | 11:30 |
| freemangordon | (IIRC) :) | 11:30 |
| freemangordon | debian == salsa.$whatever.$it.$was | 11:31 |
| buZz | this 'low battery poweroff' is kinda annoying when trying to setup a fresh droid4 :P | 11:58 |
| Wizzup | ok | 12:03 |
| buZz | guess i'll just leave it on usb for longer | 12:04 |
| Wizzup | buZz: what do you observe? | 12:05 |
| buZz | maemo boots, charging led is on , i can connect to wifi, start a 'apt update' , and during it just powers off, seemingly | 12:05 |
| buZz | also, white led is blinking through the charging led now? hmm | 12:06 |
| buZz | hmmmm , maybe it just synced time during connecting to wifi and got confused? | 12:08 |
| buZz | oh, btw, last build oin phoenix. gives me on 'apt update' (after 5th time it seems to stay running now) : 'invalid signature 'maemo leste extra signing key'' | 12:09 |
| buZz | on latest image from phoenix* | 12:10 |
| buZz | i'll try upgrade & dist-upgrade, reboot, and retry apt update | 12:11 |
| buZz | ah, already a 'apt update' after the upgrade doesnt give the key error | 12:12 |
| Wizzup | buZz: not sure about the power off, that seems weird, does it do a reboot, or just reset? | 12:16 |
| Wizzup | buZz: the signing key is fixed with an update of core pkgs | 12:16 |
| buZz | it seems to do a full poweroff, its kinda weird | 12:17 |
| buZz | maybe this cable is dubious .. hmm | 12:17 |
| uvos | buZz: thats expected behavior | 14:38 |
| buZz | right, just saying its a annoying situation :) | 14:39 |
| uvos | buZz: the d4 only charges with 500mA if you load it (like apt update dose) it will be discarging the battery | 14:39 |
| uvos | buZz: if its discarging the battery while the voltage is below threshold it will power off | 14:39 |
| uvos | buZz: this is the only thing it can do to prevent damage | 14:39 |
| buZz | hmhm | 14:39 |
| buZz | well, there are alternatives :) | 14:39 |
| uvos | no | 14:39 |
| buZz | 'while (battery <2%) { echo "preventing further booting while charging to minimum capacity"; }' in rc.local or something | 14:40 |
| uvos | dosent help | 14:40 |
| uvos | and we do this | 14:40 |
| uvos | in charge-mode | 14:40 |
| Wizzup | uvos: the power off you describe, is that what buzz sees? | 14:40 |
| buZz | ah, didnt see any msg | 14:40 |
| Wizzup | uvos: it sounded like immediate power off to me | 14:40 |
| uvos | Wizzup: its working as intended | 14:40 |
| Wizzup | hmm, is there a way to see this in the logs? | 14:41 |
| uvos | Wizzup: mce powers off because the battery is discarging while below a voltage threshold | 14:41 |
| buZz | yeah often its immediate , but as i read it, it might just be dropping so low that it plops away instantly? | 14:41 |
| Wizzup | a buddy of mine had his d4 also just shut down without errors in dmesg | 14:41 |
| Wizzup | and I htink I saw it too at some point | 14:41 |
| Wizzup | maybe it's a voltage drop | 14:41 |
| uvos | Wizzup: well the led makes it obivous | 14:41 |
| buZz | what does the led say? | 14:41 |
| Wizzup | uvos: then I think it is a different behaviour | 14:41 |
| uvos | Wizzup: led on = mce is volontarly shuting down | 14:41 |
| Wizzup | buZz: I think the led should be purple | 14:41 |
| uvos | white | 14:41 |
| buZz | which color on? | 14:41 |
| Wizzup | ok, white then | 14:41 |
| buZz | uvos: once i had 'white led on' while completely powered off even | 14:42 |
| buZz | is that this behaviour? | 14:42 |
| uvos | its not off | 14:42 |
| uvos | it turns off the display immidatly | 14:42 |
| uvos | and then powers off | 14:42 |
| uvos | while the led is on its not finished | 14:42 |
| Wizzup | ok I just thought that buzz said the device powered off immediately | 14:42 |
| Wizzup | like some reset | 14:42 |
| buZz | right, just not responding to keyboard, slider or USB in/out | 14:42 |
| uvos | right | 14:42 |
| uvos | this is correct | 14:42 |
| buZz | with whiteled on | 14:42 |
| uvos | its in the processes of shutdown | 14:42 |
| Wizzup | ok | 14:42 |
| Wizzup | then it is what uvos said | 14:42 |
| buZz | uvos: it took >5 minutes? | 14:42 |
| uvos | buZz: there a kernel bug | 14:43 |
| uvos | buZz: that causes a oops on shutdown | 14:43 |
| buZz | eventually i did power+voldown | 14:43 |
| uvos | it can hang | 14:43 |
| uvos | yeah | 14:43 |
| uvos | this is a different issue | 14:43 |
| buZz | cant we keep display on with backlight off on poweroff-by-mce ? | 14:43 |
| uvos | this is the uart dirver oopsing | 14:43 |
| uvos | buZz: we dont want to | 14:43 |
| uvos | the led is your indication :) | 14:43 |
| buZz | right but its indicating things that arent clear :D | 14:43 |
| uvos | (and serial sticks around ofc) | 14:43 |
| uvos | imo its fine | 14:44 |
| uvos | ofc the kernel should not oops :P | 14:44 |
| Wizzup | maybe the led pattern could pulse or something | 14:47 |
| uvos | no not possible | 14:47 |
| uvos | and not a good idea | 14:47 |
| uvos | the led pattern has to be on untill the device is hardware off | 14:47 |
| uvos | this is long after mce dies | 14:47 |
| uvos | so mce cant be pulsing the led | 14:47 |
| uvos | the current pattern on n900/fremantle is also very dumb | 14:48 |
| uvos | it ramps down in about 1 sec | 14:48 |
| uvos | thus not telling the user anything really (ie the n900 can hang in shutdown forever and the user wont know untill he finds his battery unexpectantly empty) | 14:49 |
| uvos | we should be changing the n900 led to be like the mapphone one not the other way around | 14:49 |
| bencoh | wait, the n900 led driver has a hardware led pattern engine | 15:24 |
| uvos | right, so dose the d4, but its not used sanely on n900 | 15:26 |
| uvos | its programed to turn off the led slowly in a fixed time | 15:26 |
| uvos | this has no relation to the n900 acctually turning off | 15:26 |
| uvos | its just a meaningless/useless animation | 15:26 |
| freemangordon | uvos: not really, on n900 WD actually works, not like the one on d4 | 15:36 |
| uvos | mope | 15:36 |
| uvos | nope | 15:36 |
| freemangordon | yes, it does | 15:36 |
| uvos | n900 can and absoulty dose hang like this | 15:36 |
| uvos | i has in the past | 15:36 |
| uvos | *it | 15:36 |
| freemangordon | no way | 15:36 |
| uvos | wd can not prevent every hang | 15:36 |
| freemangordon | sure it can | 15:36 |
| uvos | no | 15:36 |
| freemangordon | I don;t know waht happens on d4 though | 15:36 |
| freemangordon | I suspect WD there is not correctly setup or something | 15:37 |
| uvos | same way it can happen on n900 (and has on older kernels) | 15:37 |
| uvos | or maybe its not set up, but that dosent change that it can still hapen with wd | 15:37 |
| freemangordon | if WD is correctly set-up (no way out), there is absolutely no way for device to hang forever | 15:38 |
| uvos | ofc there is | 15:38 |
| uvos | come one | 15:38 |
| freemangordon | no, ther eis no, this is HW engine connected to one of the reset signals | 15:38 |
| uvos | there millions of ways the wd can still be kicked while the device is stuck in some way | 15:38 |
| uvos | the d4 isent really stuck either | 15:38 |
| uvos | you can still use it over serial in this state | 15:38 |
| freemangordon | see, I am using n900 for 11 years already | 15:38 |
| uvos | its just parts of userspace that get stuck | 15:38 |
| uvos | i dont care if you have been using it for 1million years | 15:38 |
| uvos | wd is not a silver bullet | 15:38 |
| freemangordon | yeah, right | 15:39 |
| * freemangordon is out | 15:39 | |
| Wizzup | well we disable ws reset on reboot | 15:43 |
| Wizzup | s/ws/wd/ | 15:43 |
| uvos | no | 15:43 |
| Wizzup | that's why we don't have NOWAYOUT set | 15:43 |
| Wizzup | I think we do, don't we? | 15:43 |
| Wizzup | at least we hand it back to kernel I think | 15:43 |
| uvos | pretty sure it works | 15:43 |
| uvos | oh on reboot | 15:44 |
| uvos | sorry i read that wrong | 15:44 |
| uvos | yeah its disabled at some point in the reboot process | 15:44 |
| Wizzup | right | 15:46 |
| freemangordon | why do we do that? | 15:46 |
| uvos | iirc dsme get shut down | 15:46 |
| Wizzup | because our reboot with sysvinit/openrc is too slow | 15:47 |
| uvos | and then it would wd before its power off | 15:47 |
| freemangordon | dsme is not touched by openrc | 15:47 |
| freemangordon | sec | 15:47 |
| Wizzup | we even had this do not kill pids list | 15:47 |
| Wizzup | but this, what we have now, was the proper solution | 15:47 |
| Wizzup | if kernel didn't panic and keep wd alive during panic we'd be ok | 15:47 |
| freemangordon | https://github.com/maemo-leste/dsme/blob/master/debian/dsme.init#L28 | 15:48 |
| uvos | iirc from poking around in the d4 state the problem is that agetty | 15:48 |
| uvos | is in D state | 15:48 |
| uvos | because of the oops | 15:48 |
| uvos | so it cant be killed | 15:48 |
| uvos | and init just waits for it to die forever | 15:48 |
| uvos | this is becasue the tty subsystem is in unsable state after the oops | 15:48 |
| freemangordon | TBH I don;t think we shall return the WD control to the kernel | 15:49 |
| uvos | freemangordon: in this case whatever you wont help | 15:49 |
| uvos | freemangordon: if you give wd to kernel it wont reboot | 15:49 |
| uvos | freemangordon: if you keep dsme allive it wont eihter | 15:49 |
| freemangordon | no, wait | 15:49 |
| uvos | wd cant help you here | 15:49 |
| freemangordon | the point is - dsme is not killed by openrc | 15:50 |
| freemangordon | kernel starts to kill processes and dsme gets killed but init is not | 15:51 |
| freemangordon | 15 seconds afted dsme gets killed, WD reboots the device | 15:51 |
| freemangordon | or was it 1 seconds? | 15:51 |
| freemangordon | *12 | 15:52 |
| Wizzup | we're going back to a discussion we resolved before | 15:52 |
| freemangordon | did we? | 15:52 |
| Wizzup | maybe read logs and issues going back to get up to date on this | 15:52 |
| Wizzup | yes | 15:52 |
| freemangordon | ok | 15:52 |
| freemangordon | so, is it possible what you decided back then to be wrong? | 15:52 |
| uvos | that is a _terrible_ thing to do | 15:52 |
| uvos | btw | 15:52 |
| Wizzup | it could be wrong, but let's read the older issues / logs first | 15:53 |
| freemangordon | ok | 15:53 |
| uvos | the time the kernel takes to shutdown after killing everything is not determistic | 15:53 |
| freemangordon | sure, but WD timeout is controllable too, iirc | 15:53 |
| uvos | dosent help | 15:53 |
| uvos | just give wd back to the kernel | 15:53 |
| uvos | the kernl has to for intance sync disks, that might mean flushing 2gb to a really slow usb stick on pp | 15:53 |
| freemangordon | and hope for the best? | 15:53 |
| uvos | a hard time out is _bad_ | 15:54 |
| uvos | really really bad | 15:54 |
| Wizzup | freemangordon: imho this is a kernel problem | 15:54 |
| freemangordon | ok, I'll try to find the log | 15:54 |
| freemangordon | Wizzup: yeah, maybe there is some knob we can play with, maybe - "how long shall we wait for a process to die"? | 15:54 |
| Wizzup | as I understand it getty is unkillable because of oops | 15:55 |
| Wizzup | which prevents reboot | 15:55 |
| Wizzup | so maybe we can skip waiting | 15:55 |
| uvos | you could force the kenrel to just reboot | 15:55 |
| Wizzup | but if this wasn't oops but a panic the device would I think just reboot | 15:55 |
| uvos | but really | 15:55 |
| uvos | just dont panic | 15:55 |
| Wizzup | it's not a panic I think | 15:55 |
| uvos | er oops | 15:55 |
| uvos | yes | 15:55 |
| freemangordon | uvos: we can;t guarantee that | 15:55 |
| uvos | freemangordon: well you cant guarentee everything | 15:56 |
| uvos | thats just how it is | 15:56 |
| freemangordon | bullshit | 15:56 |
| uvos | fucking around with the wd dosent help it just causes more issues | 15:56 |
| freemangordon | it is reaaly not productive | 15:56 |
| freemangordon | WD is there for a reason, don;'t you think? | 15:56 |
| Wizzup | fwiw I agree with uvos here that we did the right thing with the handoff instead of hard timeou | 15:56 |
| freemangordon | which I guess differs from "lets disable WD" | 15:57 |
| uvos | right its there for the kernel to use it | 15:57 |
| uvos | the kernel dose use it | 15:57 |
| Wizzup | we don't disable it | 15:57 |
| uvos | if the kernel hangs it will wd reboot | 15:57 |
| Wizzup | it's enabled, kernel just decides it doesn't want to restart | 15:57 |
| uvos | problem is that in this case the kernel is not really hanged so its kicking the wd | 15:57 |
| Wizzup | or maybe openrc/sysvinit does, because getty is unkillable | 15:57 |
| freemangordon | ok, that's why I said " yeah, maybe there is some knob we can play with, maybe - "how long shall we wait for a process to die"?" | 15:57 |
| Wizzup | right, or we fix this oops and move on :) | 15:57 |
| Wizzup | or make it a panic, in which case the right thing happens | 15:57 |
| freemangordon | no, because we can;t prevent kernel from oopsing | 15:58 |
| freemangordon | anyway | 15:58 |
| uvos | you kan make every oops a panic | 15:58 |
| uvos | btw | 15:58 |
| uvos | so sure | 15:58 |
| uvos | you could do taht | 15:58 |
| uvos | (not right now please) | 15:58 |
| bencoh | Wizzup: I'd suggest enabling kgdb/kgdboc instead of making it a panic | 16:16 |
| bencoh | then you might be able to debug it some | 16:16 |
| bencoh | https://www.kernel.org/doc/html/v4.14/dev-tools/kgdb.html if you're interested | 16:17 |
| Wizzup | well tmlind was already looking into it | 16:23 |
| bencoh | kgdb, or the bug? | 16:26 |
| freemangordon | the bug | 16:26 |
| sicelo | I like Wizzup's suggestion of purple led for d4 shutdown notification | 20:20 |
| sicelo | Or some other noticeable color besides white. The Droid 4 has a tiny led, and for some reason the white is inconspicuous. The green works very well, so maybe purple could work good. | 20:26 |
| Wizzup | ok | 21:18 |
| Wizzup | let's see if I can get this arm build machine going :) | 21:18 |
| Wizzup | going ro restart the server that runs some of our infra momentarily | 22:09 |
| Wizzup | looks like I need to remove a disk :) | 22:54 |
| Wizzup | stuff should be back | 23:23 |
| Wizzup | ordered a disk replacement | 23:24 |
| Wizzup | should be able to replace it by tomorrow | 23:24 |
| uvos | so abook dosent show any conacts | 23:25 |
| Wizzup | (16TB disk died after 2 years, wtf) | 23:25 |
| Wizzup | uvos: do you have any? | 23:25 |
| uvos | yeah sphone can see them, so can gnome-contacts | 23:25 |
| Wizzup | I was going to look at syncing my n900 contacts to my d4, but didn't get to do it yet | 23:25 |
| Wizzup | hm, ok | 23:25 |
| uvos | i sync via dav with my android devices | 23:26 |
| uvos | anyhow | 23:26 |
| Wizzup | from leste? | 23:26 |
| Wizzup | how a line on how you do that for contacts? | 23:26 |
| Wizzup | s/how/got/ | 23:26 |
| uvos | i used gnome-contacts to set it up iirc | 23:28 |
| uvos | it created a evolution adress book and set it as default | 23:29 |
| Wizzup | btw, I have 8 more 10" mz tablets here it looks like | 23:29 |
| Wizzup | should I send any out? | 23:29 |
| uvos | not to me, mines fine | 23:29 |
| Wizzup | ok | 23:29 |
| uvos | you dont have mz609 right? | 23:29 |
| uvos | ie those are mz617? | 23:30 |
| uvos | or 615 | 23:30 |
| Wizzup | I believe so | 23:30 |
| uvos | ok | 23:30 |
| Wizzup | mz617 | 23:30 |
| uvos | ok - no interest | 23:30 |
| Wizzup | was this one https://www.ebay.com/itm/154784937697 | 23:30 |
| Wizzup | I suspect they work | 23:31 |
| Wizzup | will figure that out soon | 23:31 |
| Wizzup | I'm a bit upset one of my 16TB disks died that soon :/ | 23:31 |
| Wizzup | well at least it was a raid and all | 23:31 |
| uvos | :\ | 23:31 |
| Wizzup | waiting for the replacement so I can run 'btrfs dev replace' | 23:32 |
| Wizzup | experience thought me that just removing the missing dev and then adding one later is much, much slower | 23:32 |
| Wizzup | anwyay | 23:32 |
| Wizzup | hopefully tonight or tomorrow the 16core arm server is up :) | 23:32 |
| uvos | uvos.xyz/maserati/syncevo.txt | 23:33 |
| uvos | so thats the setup | 23:33 |
| uvos | i suspect that abook is using the wrong addressbook | 23:34 |
| uvos | it should let you choose (like sphone) and/or use the default address book | 23:34 |
| uvos | freemangordon: ^^^ | 23:34 |
| uvos | 05ec7443-1cec-421a-a6c9-2bbd2892b974 is empty | 23:34 |
| uvos | dosent work even after deating all adress books except the right one | 23:43 |
| Wizzup | does it not have a store for its own? | 23:46 |
| uvos | it dosent make one and is should respect eds default no? | 23:47 |
| uvos | ie at the very least contacts in eds default should show | 23:47 |
| Wizzup | uh, I don't think that's how it works per fmg | 23:47 |
| Wizzup | right | 23:47 |
| uvos | well thats wrong | 23:47 |
| Wizzup | not sure about that, but likely | 23:47 |
| uvos | it should not have its own it should do what its told by eds ie display the default book or the book user selects | 23:48 |
| uvos | *book the user | 23:48 |
| uvos | like the other frontends | 23:48 |
| * Wizzup cannot comment on what it should do | 23:50 | |
| Wizzup | ok, tomorrow I will setup the honeycomb | 23:50 |
| Wizzup | it seems not super hard | 23:50 |
| uvos | honeycomb? | 23:50 |
| uvos | android 3.0 | 23:50 |
| uvos | ? | 23:50 |
| uvos | ah the arm server | 23:51 |
| uvos | right | 23:51 |
| Wizzup | yes | 23:52 |
| Wizzup | 32GB 16 cores | 23:52 |
| Wizzup | got all the other components as well | 23:52 |
| uvos | well 16 fairly weak cores | 23:53 |
| uvos | anyhow cool | 23:53 |
| uvos | how will we be manageing building for both arm archs? | 23:54 |
| Wizzup | I will just make two KVM VMs | 23:56 |
| Wizzup | I think that should be fine | 23:56 |
| Wizzup | of course it will take a while because parazyd used to do it and I don't know how :) | 23:56 |
| Wizzup | but maybe I am take the ata over ethernet image and just read it from qemu for now (ofc not using ata over ethernet) | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!