freemangordon | tmlind: please, give me some hint where and what to look for, this drives me nuts every time I reboot/poweroff the device (d4): https://pastebin.com/aMwWGfzG | 11:42 |
---|---|---|
uvos | this also bugs me to high heven, and if you try and debug it, it goes away ususaly | 12:21 |
uvos | (seams timeing sensitve + only happens if you disable debug output via uart) | 12:21 |
freemangordon | here it happens every time I reboot or poweroff | 12:22 |
uvos | right | 12:22 |
uvos | but if you enable more kernel debug options it goes away | 12:22 |
freemangordon | ah | 12:22 |
uvos | and if you dont suspend the console | 12:22 |
freemangordon | well, I guess printk() to the rescue | 12:22 |
uvos | (ie keep loging to uart it also gos away) | 12:22 |
freemangordon | sure it is PM enabled | 12:22 |
uvos | i think its directly related to kernel consoles usage of the uart device | 12:23 |
uvos | but idk really | 12:23 |
freemangordon | me neither | 12:23 |
freemangordon | I can try and put some printks around that function | 12:24 |
freemangordon | later on | 12:24 |
rafael2k | hi all | 12:57 |
rafael2k | I made a PR for the pine64 kernel, in order to address Wizzup issue with lost usbnet... | 12:58 |
Wizzup | rafael2k: thanks | 13:07 |
rafael2k | Wizzup: do you have a ETA to build this? | 13:15 |
rafael2k | I will bypass this and already make the PR for 5.15.68 soon | 13:16 |
Wizzup | did you update the pr, or is it the same from 2-3 days ago? | 13:17 |
rafael2k | I will start compiling 5.15.68 now | 13:17 |
Wizzup | ah ok | 13:17 |
Wizzup | 7 days ago even :) | 13:17 |
rafael2k | In a couple of days I should have 5.15.68 tested and ready | 13:17 |
Wizzup | ok, will merge momentarily, do I need to re-tag | 13:17 |
rafael2k | no | 13:17 |
rafael2k | same source | 13:17 |
rafael2k | I mean, dunno what you mean by re-tag, but it applies to the same kernel source as previous kernel | 13:18 |
Wizzup | building | 13:18 |
rafael2k | : ) | 13:18 |
rafael2k | as it was a trivial change, I did not build myself | 13:19 |
rafael2k | so there is a change I did some mistake and build crashes applying the patches | 13:19 |
rafael2k | *chance | 13:19 |
rafael2k | for 5.15.68 I'm building and testing, as it is a kernel version bump... better make sure | 13:20 |
rafael2k | I plan also to roll out soon a new patchset for the cameras, but I prefer to do it after we have the new kernel tested, usbnet fixed, and may be the high iowait freemangordon is experiencing fixed too | 13:24 |
Wizzup | ok | 13:24 |
rafael2k | Wizzup, compiling 5.15.68 here... I think the PR will fail, sorry - confirm to me it fails, I do another PR | 13:39 |
Wizzup | ok | 13:40 |
Wizzup | I will be afk for a few hours soon | 13:41 |
rafael2k | editing patches by hand never works, as next patches get "fuzz" and build fail... aaarrrgggg | 13:42 |
Wizzup | yes it failed https://phoenix.maemo.org/job/pine64-kernel-source/82/console | 13:43 |
rafael2k | ok, thanks | 13:43 |
rafael2k | I will fix | 13:43 |
rafael2k | and do another PR | 13:43 |
sicelo | rafael2k: any special reason why it's 5.15 and not some other version? | 16:23 |
freemangordon | rafael2k: you can just do quilt refresh, and fuzz will be fixed | 16:38 |
freemangordon | uvos: I am confused: https://pastebin.com/7JhQryxD | 16:47 |
freemangordon | why display is off? | 16:47 |
freemangordon | exactly 20 seconds after I press power button while in charge mode | 16:47 |
freemangordon | I put traces in display_blank/display_dim from display.c | 16:48 |
freemangordon | the are not called | 16:48 |
freemangordon | is it possible that Xorg turns the screen off? | 16:49 |
rafael2k | https://github.com/maemo-leste/pine64-kernel/pull/9 | 16:50 |
rafael2k | PP kernel bump to 5.15.68 ^ | 16:50 |
freemangordon | hmm, lemme reinstall mce, that can;t be tru | 16:56 |
freemangordon | *true | 16:56 |
rafael2k | sicelo: yes, cause 5.15 is LTS, and Mobian does a good job maintaining the PP patchset | 16:57 |
rafael2k | freemangordon: I kind of know it... but my lazyness is way to big | 16:58 |
rafael2k | fixed by hand the fuzziness | 16:58 |
freemangordon | :D | 16:58 |
rafael2k | :P | 16:58 |
freemangordon | I see | 16:58 |
rafael2k | Wizzup: need to sync branch mobian-5.15 to HEAD | 16:59 |
rafael2k | https://gitlab.com/mobian1/devices/sunxi64-linux/ | 16:59 |
rafael2k | branch mobian-5.15, or tag mobian/5.15.68+sunxi64-1 | 17:00 |
rafael2k | I also mirrored it here, just in case: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 | 17:01 |
rafael2k | https://github.com/rafael2k/sunxi64-linux/tree/mobian/5.15.68+sunxi64-1 | 17:01 |
freemangordon | uvos: who turns off the display while in charge mode? | 17:02 |
freemangordon | yep, ok, it seems this is dpms that behaves | 17:13 |
uvos | freemangordon: chargemode itself | 17:50 |
uvos | but also nothing | 17:50 |
uvos | beacuse sdls drm backend dosent blank (i think its just not implemented for this backend but i dident check, may also be bug) | 17:51 |
uvos | anyhow i intend to just implement charging sdl to drm blank itself | 17:51 |
uvos | as a stopgap it just turns off the backlight atm, so that the display is still on "behind" that is a known problem | 17:52 |
uvos | https://github.com/IMbackK/drm_blankscreen/blob/master/main.c | 17:53 |
uvos | thats me expieramenting with the interface | 17:53 |
uvos | i just have to copy that code over to charging_sdl and integrate it | 17:53 |
freemangordon | uvos: right. ok, I have to cook some dinner first and then will put some traces in x11 module | 18:01 |
freemangordon | maybe it shall turn the display on on startup | 18:02 |
uvos | im pretty sure mce turns the display on when it runs | 18:02 |
uvos | very sure, i remember implementing it | 18:03 |
freemangordon | ok, will see | 18:03 |
freemangordon | uvos: right, but it seems x11 module is loaded too late | 18:30 |
freemangordon | Sep 22 18:02:37 localhost mce[2726]: display: Sending display status: on | 18:31 |
freemangordon | Sep 22 18:02:37 localhost mce[2726]: Loading module: x11-ctrl from /usr/lib/mce/modules | 18:31 |
freemangordon | lemme load x11 before display to see if it will fix it | 18:31 |
freemangordon | nope, does not make any difference | 18:41 |
uvos | there is no way xorg starts with dpms off | 18:46 |
freemangordon | I wonder where this 20 seconds timeout comes from | 18:46 |
uvos | freemangordon: btw i havent had time to look at it really | 19:13 |
uvos | but another thing i thought of wrt mce is: | 19:13 |
uvos | so mce seams pretty wedged/busy by dbus requests | 19:13 |
uvos | all of the timers in mce are inherently racy | 19:13 |
uvos | if they expire before mce gets around to canceling them, simply because its to busy before they expire | 19:14 |
uvos | they will take effect even when they where supposed to be canceled a long time ago | 19:14 |
uvos | this is a big general problem in mce because it uses a lot of timers | 19:15 |
norayr | my droid4 is not good... it shuts down very very often. | 19:35 |
norayr | and it started since i started using the lapdock. i wonder what could i damage. | 19:36 |
norayr | that's not software, it also shuts down while loading android. | 19:36 |
norayr | and i blacklisted back the modules. | 19:36 |
norayr | and i don't have a feeling that the contact of the battery is bad. | 19:56 |
norayr | i have a feeling it is good. :/ | 19:56 |
freemangordon | uvos: we can overcome this by using g_timeout_add_full() and setting high enough priority | 19:58 |
freemangordon | but I dont; thing this is our issue | 19:58 |
uvos | freemangordon: no that would not help | 20:10 |
uvos | the problem is that external triggers cancle timers | 20:10 |
uvos | these events get queued, when the system is busy they dont get executed untill the timer expires and its event gets queued | 20:11 |
uvos | now the timer expirey event is in the que, and the timer itself being canceled by the event ahead of it is immaterial | 20:12 |
uvos | it will execute either way | 20:12 |
uvos | this has caused _alot_ off issues in the past i have had to fix | 20:13 |
uvos | norayr: :( | 20:16 |
uvos | norayr: is there a reson in the logs for the power off maybe? | 20:25 |
norayr | hmmm... i was seeing some strang things in dmesg | 21:03 |
norayr | but it is like hardware thing, it shuts down when it is in the hand. | 21:03 |
norayr | but i think it is not shutting down when it is on the table. no it is shutting down. | 21:03 |
norayr | yes it is shutting down on the table. | 21:03 |
norayr | i'll change the battery and will see :/ | 21:05 |
norayr | where do you buy batteries? | 21:05 |
uvos | norayr: where do you live? | 21:37 |
uvos | i can just send you one to test | 21:37 |
uvos | i have plenty old old ones that work but are a bit weak | 21:38 |
uvos | so giveing one away that i know works fine is no issue | 21:38 |
freemangordon | uvos: why queues are not being executed? | 21:40 |
freemangordon | isn't it under our control to prioritize them? | 21:40 |
uvos | its just the ususal g_main_loop, mce dosent prioritize anything so it just processes events in the order it gets them | 21:41 |
uvos | mce is quite slow, because of all the sync io | 21:42 |
freemangordon | but datapipes are not events | 21:42 |
uvos | so it gets overloaded fairly easily | 21:42 |
uvos | i know | 21:42 |
freemangordon | and mainloop events can bi given priorities | 21:42 |
uvos | but everything external goes though events | 21:42 |
freemangordon | that's what I am saying | 21:42 |
uvos | sure but due to the datapipes | 21:42 |
uvos | its pretty spagetty how someting ends up somehwere when processing an event | 21:43 |
freemangordon | ah, yeah | 21:43 |
freemangordon | but I think we have deterministic behaviour otherwise | 21:43 |
freemangordon | albeit complicated | 21:43 |
uvos | well no | 21:43 |
freemangordon | ah, so you mean that we have timer expiry event in the queue and we trying to cancel it is a noop? | 21:44 |
uvos | lets say we get 20 dbus events that ask for the display state (you know totaly inventing something here that dosent occure in the logs ever) | 21:44 |
freemangordon | ok | 21:44 |
uvos | then mce ends up with a in a huge mess of events, that then trigger a huge mess of dataippes | 21:44 |
uvos | this stalls mce for several s maybe | 21:45 |
freemangordon | really? | 21:45 |
uvos | i dont know in this specific case | 21:45 |
freemangordon | hmm, but whay so low performance? | 21:45 |
uvos | but yes it has in other cases | 21:45 |
uvos | it waits _alot_ for other stuff though sync io | 21:45 |
freemangordon | hmm... | 21:45 |
uvos | its also pretty slow for idk why reasons | 21:46 |
uvos | like its to slow to process the d4 ts in real time | 21:46 |
uvos | nokia made it throw away all touch screen events for 1 s after it gets one | 21:46 |
uvos | thats extramly nessecary | 21:46 |
uvos | i removed that once | 21:46 |
uvos | it gets wedged for seconds after a swipe on d5 | 21:46 |
uvos | *4 | 21:46 |
uvos | just processing input events | 21:46 |
freemangordon | I see | 21:46 |
freemangordon | ok, will have a look at that, this sounds really strange | 21:47 |
freemangordon | shouldn;t be that slow | 21:47 |
freemangordon | if it is, then we have some design issue | 21:47 |
freemangordon | which we shall fix by changing the design if needed | 21:47 |
uvos | anyhow, if this is the issue idk | 21:47 |
uvos | its just been the issue in the past | 21:47 |
freemangordon | but, I don;t think this is the reason for blanking startup issue | 21:48 |
freemangordon | have some other things to do atm, will put more traces later on | 21:48 |
freemangordon | I plan to start 1s timer that reads brightness | 21:48 |
freemangordon | to see after what event in log it gets 0 | 21:49 |
freemangordon | uvos: it is display_unblank() that blanks it :) | 22:26 |
freemangordon | first time it is called with cached_brightness=7 and set_brightness=0 | 22:27 |
freemangordon | and that in turn dims the display | 22:28 |
freemangordon | ugh, no | 22:29 |
freemangordon | it is not that | 22:29 |
freemangordon | uvos: OMG: https://github.com/maemo-leste/mce/blob/master/src/modules/display.c#L244 | 22:43 |
uvos | yeah i know | 22:43 |
uvos | the value is a percentage | 22:43 |
freemangordon | that's calculated as 0 when new_brightness is 5 | 22:43 |
uvos | the valiue gets filtered to a real value later | 22:44 |
uvos | no | 22:44 |
uvos | so the way this works is that it should be a percentage here | 22:44 |
freemangordon | set_brightness is set to 0, so display_unblank() sets brightness to 0 | 22:44 |
uvos | and theres a table | 22:44 |
uvos | that converts it later | 22:44 |
freemangordon | I put traces, lemme show it to you | 22:45 |
uvos | in the same pipe | 22:45 |
freemangordon | later on it calls update_brightness_fade(0) | 22:45 |
freemangordon | see https://pastebin.com/VbQHcVnx | 22:46 |
freemangordon | search for display_brightness_trigger 5 | 22:46 |
uvos | so | 22:47 |
uvos | what are you printing there? | 22:47 |
freemangordon | where? | 22:47 |
uvos | display_brightness_trigger 5 | 22:47 |
uvos | the 5 | 22:47 |
freemangordon | 5 is data | 22:47 |
freemangordon | new_brightness | 22:48 |
freemangordon | and few lines below I print re-calculated new_brightness | 22:48 |
freemangordon | lemme pastebin the code | 22:48 |
uvos | so something is setting it in pannel units | 22:49 |
uvos | instead of percentage | 22:49 |
freemangordon | https://pastebin.com/N7WPNZrG | 22:49 |
freemangordon | agree | 22:49 |
uvos | https://github.com/maemo-leste/mce/blob/d4604c30e5734af7b17e907f767267a83f52c731/src/modules/filter-brightness-als-iio.c#L137 | 22:49 |
uvos | this guy is reponsable for filtering the percentage to pannel units, ususally | 22:50 |
freemangordon | maybe it is not loaded | 22:50 |
uvos | could be yeah | 22:50 |
uvos | it might be loaded to late | 22:50 |
freemangordon | it shoudl be clear in the logs | 22:50 |
freemangordon | Sep 22 23:39:00 localhost mce[2731]: Loading module: filter-brightness-als-iio from /usr/lib/mce/modules | 22:51 |
freemangordon | when it is already too late | 22:51 |
uvos | just shove it earlier then | 22:52 |
freemangordon | lemme put display at the end :) | 22:52 |
uvos | and see if it goes away | 22:52 |
freemangordon | mhm | 22:52 |
uvos | i would avoid moving display | 22:52 |
freemangordon | I already did, because it was loaded before x11, so it was never setting dpms on | 22:52 |
uvos | that should not matter | 22:53 |
uvos | xorg iself sets dpms on on boot | 22:53 |
uvos | moving display causes some artifacts wrt tklock | 22:53 |
freemangordon | yes, but you have code that is never going to be executed | 22:53 |
freemangordon | so, it should be before tklock? | 22:53 |
uvos | at least yeah | 22:54 |
uvos | there are other interactions too | 22:54 |
freemangordon | ok, will put it like that | 22:54 |
freemangordon | hmm | 22:54 |
freemangordon | ok | 22:54 |
uvos | also moving the oder in general is a bad idea xD | 22:54 |
uvos | there be drangons there | 22:54 |
freemangordon | what about inactivity? | 22:54 |
uvos | what about it? | 22:54 |
freemangordon | it should be beore display too, right> | 22:55 |
freemangordon | ? | 22:55 |
freemangordon | and inhinit as well | 22:55 |
freemangordon | *inhibit | 22:55 |
uvos | when inhibit comes is pretty irrelivant | 22:55 |
uvos | inactivitiy should stay in the same relation | 22:55 |
uvos | about the code in x11 | 22:56 |
uvos | its only about setting dpms on if mce crashes | 22:57 |
uvos | or is restarted while x11 is running | 22:57 |
uvos | on boot mce starts before x11 anyhow | 22:57 |
freemangordon | I agree, but it still will not be executed | 22:57 |
uvos | so it wont do anything | 22:57 |
uvos | it will print extra warning even | 22:57 |
uvos | ok | 22:57 |
uvos | sure | 22:57 |
freemangordon | I already moved and it started to behave correctly | 22:57 |
freemangordon | like, if you restart mce screen gets unlocked | 22:58 |
freemangordon | and unblanked | 22:58 |
uvos | pretty sure that worked before | 22:58 |
uvos | but maybe it broke at some point.. | 22:58 |
freemangordon | so I think display shall be the last of x11, startup, als, inactivity, inhibit | 22:58 |
freemangordon | otherwise we risk those modules to start too late and to miss event | 22:59 |
uvos | sure | 22:59 |
freemangordon | ok, will reorder | 22:59 |
uvos | but chainging the order at all risks unforseen consequences | 22:59 |
uvos | so test very thoughly | 22:59 |
freemangordon | well, that is what -devel is for :) | 22:59 |
freemangordon | sure | 22:59 |
uvos | also note that 10-maemo.ini or whatever overrides mce.ini | 23:00 |
uvos | modules wise | 23:00 |
freemangordon | this is what I am changing | 23:00 |
uvos | ok | 23:00 |
uvos | also change mce.ini too ofc | 23:00 |
freemangordon | hmm, ok | 23:01 |
uvos | mce installs 10-maemo.ini | 23:01 |
freemangordon | won't be able to test | 23:01 |
uvos | only if systemui is available | 23:01 |
freemangordon | yeaaah, that's way better :) | 23:05 |
freemangordon | uvos: yes, this fixes it | 23:06 |
uvos | ok | 23:07 |
norayr | uvos, the battery? i changed the battery and put it to charge, meanwhile while charging it rebooted. without even touching it. | 23:09 |
norayr | armenia, but i get everything via mail forwarders in usa, britain, germany. | 23:10 |
norayr | i'll try to use it after it charges a little bit. | 23:10 |
norayr | i blacklisted everyhhing back so i don't understand what is happening? i also don't remember dropping droid. | 23:11 |
norayr | i only remember it started as i started ho put it in to the lapdock. but back then i thought it is because i whitelisted drivers. | 23:12 |
uvos | hmm wierd | 23:12 |
norayr | i'll take a look at the logs, and i have dmesg with some strange, maybe irrelevant errocs. | 23:12 |
uvos | do you have ramoops? | 23:13 |
norayr | no didn't notice it in dmesg. i was afraid that ds ram but it happens just when droid tries to boot even, at the stage of kexecboot screen | 23:14 |
norayr | or when android boots. | 23:14 |
uvos | no i mean ramoops is a storage where linux writes dmesg too on crash | 23:14 |
norayr | i thought it is an error in dmesg, related to ram | 23:15 |
freemangordon | uvos: do you want PR or shall I push to master directly? | 23:15 |
uvos | freemangordon: push | 23:15 |
freemangordon | ok | 23:15 |
norayr | where is that storage? | 23:15 |
uvos | but note that i added a fix just now | 23:15 |
freemangordon | yep, pulled | 23:15 |
uvos | norayr: /var/log/pstore/ | 23:18 |
* norayr checking | 23:20 | |
freemangordon | uvos: pushed | 23:20 |
freemangordon | shall I make a release? | 23:20 |
uvos | if you like, but i hope to fix the other issue tomorrow | 23:21 |
uvos | but taging 2 releases isent a big deal either | 23:21 |
freemangordon | ok, no hurry, I have the fix locally | 23:21 |
norayr | i see these things in ramoops:(i also saw it in dmesg) | 23:25 |
norayr | omap-mcbsp 40124000.mcbsp: CLKS: could not clk_get() prcm_fck | 23:25 |
norayr | i have those right now too: | 23:26 |
norayr | [Fri Sep 23 01:22:32 2022] omap-mcbsp 40124000.mcbsp: CLKS: could not clk_get() prcm_fck | 23:26 |
norayr | not sure it is relevant. | 23:26 |
uvos | thats normal | 23:26 |
norayr | last things in the ramoops are | 23:27 |
norayr | printk: console [ttyS2] disabled | 23:27 |
norayr | sysrq: Changing Loglevel | 23:27 |
norayr | sysrq: Loglevel set to 0 | 23:27 |
uvos | right you have to stop it from disabeling logging | 23:27 |
uvos | and retest | 23:27 |
norayr | when i was unscrewing the battery, the contact was okay. | 23:36 |
norayr | so i don't understand. | 23:36 |
norayr | but now it seems it would already crash several times in my hands. | 23:36 |
norayr | i ran pidgin, i played nebulous. | 23:36 |
uvos | the contacts being at fault is fairly unlikey | 23:36 |
norayr | so i guess it works now. | 23:36 |
uvos | if it crashes while undistrubed | 23:36 |
norayr | but i need to learn this ramoops | 23:36 |
norayr | and also maybe i will be able to use it on droid3 | 23:36 |
uvos | dosent work on d4 | 23:37 |
uvos | er d3 | 23:37 |
norayr | oh | 23:37 |
uvos | the ramoops is mapped to a region thats beyond the d3s memory | 23:37 |
norayr | eh. | 23:37 |
uvos | easy fix realy, but no one is working on the d3 atm | 23:37 |
norayr | it would halt for 15 times already, my droid, and it didn't yet. | 23:37 |
norayr | i think maybe it's not contacts, it's the battery. | 23:38 |
norayr | but can battery be in the state where it drops the voltage suddenly even when seemingly well charged? | 23:38 |
norayr | i don't know. | 23:38 |
uvos | sure | 23:38 |
norayr | ok looks like it works. i'll update on what is going on. | 23:39 |
uvos | its internal resistance can be to high | 23:39 |
uvos | d4 reacts by crashing to that | 23:39 |
uvos | so that would track | 23:39 |
norayr | the battery was this 'x-longer', made in china, 1730 mah/6.4wh, and i put the same thing inside now. | 23:40 |
norayr | volts 3.7 vdc it says | 23:40 |
norayr | on the battery | 23:40 |
norayr | 'cameron sino' logo. | 23:40 |
norayr | could it be that lapdock affected the battery in some bad way? | 23:42 |
uvos | NO | 23:42 |
norayr | it doesn't crash now. | 23:42 |
norayr | such a relive. | 23:42 |
norayr | i just enjoy using it. | 23:42 |
sicelo | welcome to droid 4 :-p | 23:47 |
* uvos cries in having broken 3 d4s | 23:49 | |
sicelo | broken them how? | 23:49 |
uvos | 1. overvoltage, oops 2. display cable died from fatigue (this was my d4 from 2012 that i used as a main android device for 8 years), 3. display cable broke again (sand ingression this time) | 23:51 |
norayr | eh. | 23:54 |
uvos | mostly they are very sturdy i seams | 23:55 |
uvos | *it | 23:55 |
uvos | accidents aside | 23:55 |
norayr | i need to buy good batteries, but no idea how. | 23:55 |
uvos | i dont think you can buy any | 23:58 |
uvos | you can only make them | 23:58 |
uvos | ie adapt other cells | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!