libera/#maemo-leste/ Thursday, 2022-09-22

freemangordontmlind: 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/aMwWGfzG11:42
uvosthis also bugs me to high heven, and if you try and debug it, it goes away ususaly12:21
uvos(seams timeing sensitve + only happens if you disable debug output via uart)12:21
freemangordonhere it happens every time I reboot or poweroff12:22
uvosright12:22
uvosbut if you enable more kernel debug options it goes away12:22
freemangordonah12:22
uvosand if you dont suspend the console12:22
freemangordonwell, I guess printk() to the rescue12:22
uvos(ie keep loging to uart it also gos away)12:22
freemangordonsure it is PM enabled12:22
uvosi think its directly related to kernel consoles usage of the uart device12:23
uvosbut idk really12:23
freemangordonme neither12:23
freemangordonI can try and put some printks around that function12:24
freemangordonlater on12:24
rafael2khi all12:57
rafael2kI made a PR for the pine64 kernel, in order to address Wizzup issue with lost usbnet...12:58
Wizzuprafael2k: thanks13:07
rafael2kWizzup: do you have a ETA to build this?13:15
rafael2kI will bypass this and already make the PR for 5.15.68 soon13:16
Wizzupdid you update the pr, or is it the same from 2-3 days ago?13:17
rafael2kI will start compiling 5.15.68 now13:17
Wizzupah ok13:17
Wizzup7 days ago even :)13:17
rafael2kIn a couple of days I should have 5.15.68 tested and ready13:17
Wizzupok, will merge momentarily, do I need to re-tag13:17
rafael2kno13:17
rafael2ksame source13:17
rafael2kI mean, dunno what you mean by re-tag, but it applies to the same kernel source as previous kernel13:18
Wizzupbuilding13:18
rafael2k: )13:18
rafael2kas it was a trivial change, I did not build myself13:19
rafael2kso there is a change I did some mistake and build crashes applying the patches13:19
rafael2k*chance13:19
rafael2kfor 5.15.68 I'm building and testing, as it is a kernel version bump... better make sure13:20
rafael2kI 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 too13:24
Wizzupok13:24
rafael2kWizzup, compiling 5.15.68 here... I think the PR will fail, sorry - confirm to me it  fails, I do another PR13:39
Wizzupok13:40
WizzupI will be afk for a few hours soon13:41
rafael2kediting patches by hand never works, as next patches get "fuzz" and build fail... aaarrrgggg13:42
Wizzupyes it failed https://phoenix.maemo.org/job/pine64-kernel-source/82/console13:43
rafael2kok, thanks13:43
rafael2kI will fix13:43
rafael2kand do another PR13:43
sicelorafael2k: any special reason why it's 5.15 and not some other version?16:23
freemangordonrafael2k: you can just do quilt refresh, and fuzz will be fixed16:38
freemangordonuvos: I am confused: https://pastebin.com/7JhQryxD16:47
freemangordonwhy display is off?16:47
freemangordonexactly 20 seconds after I press power button while in charge mode16:47
freemangordonI put traces in display_blank/display_dim from display.c16:48
freemangordonthe are not called16:48
freemangordonis it possible that Xorg turns the screen off?16:49
rafael2khttps://github.com/maemo-leste/pine64-kernel/pull/916:50
rafael2kPP kernel bump to 5.15.68 ^16:50
freemangordonhmm, lemme reinstall mce, that can;t be tru16:56
freemangordon*true16:56
rafael2ksicelo: yes, cause 5.15 is LTS, and Mobian does a good job maintaining the PP patchset16:57
rafael2kfreemangordon: I kind of know it... but my lazyness is way to big16:58
rafael2kfixed by hand the fuzziness16:58
freemangordon:D16:58
rafael2k:P16:58
freemangordonI see16:58
rafael2kWizzup: need to sync branch mobian-5.15 to HEAD16:59
rafael2khttps://gitlab.com/mobian1/devices/sunxi64-linux/16:59
rafael2kbranch mobian-5.15, or tag mobian/5.15.68+sunxi64-117:00
rafael2kI also mirrored it here, just in case: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.1517:01
rafael2khttps://github.com/rafael2k/sunxi64-linux/tree/mobian/5.15.68+sunxi64-117:01
freemangordonuvos: who turns off the display while in charge mode?17:02
freemangordonyep, ok, it seems this is dpms that behaves17:13
uvosfreemangordon: chargemode itself17:50
uvosbut also nothing17:50
uvosbeacuse sdls drm backend dosent blank (i think its just not implemented for this backend but i dident check, may also be bug)17:51
uvosanyhow i intend to just implement charging sdl to drm blank itself17:51
uvosas a stopgap it just turns off the backlight atm, so that the display is still on "behind" that is a known problem17:52
uvoshttps://github.com/IMbackK/drm_blankscreen/blob/master/main.c17:53
uvosthats me expieramenting with the interface17:53
uvosi just have to copy that code over to charging_sdl and integrate it17:53
freemangordonuvos: right. ok, I have to cook some dinner first and then will put some traces in x11 module18:01
freemangordonmaybe it shall turn the display on on startup18:02
uvosim pretty sure mce turns the display on when it runs18:02
uvosvery sure, i remember implementing it18:03
freemangordonok, will see18:03
freemangordonuvos: right, but it seems x11 module is loaded too late18:30
freemangordonSep 22 18:02:37 localhost mce[2726]: display: Sending display status: on18:31
freemangordonSep 22 18:02:37 localhost mce[2726]: Loading module: x11-ctrl from /usr/lib/mce/modules18:31
freemangordonlemme load x11 before display to see if it will fix it18:31
freemangordonnope, does not make any difference18:41
uvosthere is no way xorg starts with dpms off18:46
freemangordonI wonder where this 20 seconds timeout comes from18:46
uvosfreemangordon: btw i havent had time to look at it really19:13
uvosbut another thing i thought of wrt mce is:19:13
uvosso mce seams pretty wedged/busy by dbus requests19:13
uvosall of the timers in mce are inherently racy19:13
uvosif they expire before mce gets around to canceling them, simply because its to busy before they expire19:14
uvosthey will take effect even when they where supposed to be canceled a long time ago19:14
uvosthis is a big general problem in mce because it uses a lot of timers19:15
norayrmy droid4 is not good... it shuts down very very often.19:35
norayrand it started since i started using the lapdock. i wonder what could i damage.19:36
norayrthat's not software, it also shuts down while loading android.19:36
norayrand i blacklisted back the modules.19:36
norayrand i don't have a feeling that the contact of the battery is bad.19:56
norayri have a feeling it is good. :/19:56
freemangordonuvos: we can overcome this by using g_timeout_add_full() and setting high enough priority19:58
freemangordonbut I dont; thing this is our issue19:58
uvosfreemangordon: no that would not help20:10
uvosthe problem is that external triggers cancle timers20:10
uvosthese events get queued, when the system is busy they dont get executed untill the timer expires and its event gets queued20:11
uvosnow the timer expirey event is in the que, and the timer itself being canceled by the event ahead of it is immaterial20:12
uvosit will execute either way20:12
uvosthis has caused _alot_ off issues in the past i have had to fix20:13
uvosnorayr: :(20:16
uvosnorayr: is there a reson in the logs for the power off maybe?20:25
norayrhmmm... i was seeing some strang things in dmesg21:03
norayrbut it is like hardware thing, it shuts down when it is in the hand.21:03
norayrbut i think it is not shutting down when it is on the table. no it is shutting down.21:03
norayryes it is shutting down on the table.21:03
norayri'll change the battery and will see :/21:05
norayrwhere do you buy batteries?21:05
uvosnorayr: where do you live?21:37
uvosi can just send you one to test21:37
uvosi have plenty old old ones that work but are a bit weak21:38
uvosso giveing one away that i know works fine is no issue21:38
freemangordonuvos: why queues are not being executed?21:40
freemangordonisn't it under our control to prioritize them?21:40
uvosits just the ususal g_main_loop, mce dosent prioritize anything so it just processes events in the order it gets them21:41
uvosmce is quite slow, because of all the sync io21:42
freemangordonbut datapipes are not events21:42
uvosso it gets overloaded fairly easily21:42
uvosi know21:42
freemangordonand mainloop events can bi given priorities21:42
uvosbut everything external goes though events21:42
freemangordonthat's what I am saying21:42
uvossure but due to the datapipes21:42
uvosits pretty spagetty how someting ends up somehwere when processing an event21:43
freemangordonah, yeah21:43
freemangordonbut I think we have deterministic behaviour otherwise21:43
freemangordonalbeit complicated21:43
uvoswell no21:43
freemangordonah, so you mean that we have timer expiry event in the queue and we trying to cancel it is a noop?21:44
uvoslets 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
freemangordonok21:44
uvosthen mce ends up with a in a huge mess of events, that then trigger a huge mess of dataippes21:44
uvosthis stalls mce for several s maybe21:45
freemangordonreally?21:45
uvosi dont know in this specific case21:45
freemangordonhmm, but whay so low performance?21:45
uvosbut yes it has in other cases21:45
uvosit waits _alot_ for other stuff though sync io21:45
freemangordonhmm...21:45
uvosits also pretty slow for idk why reasons21:46
uvoslike its to slow to process the d4 ts in real time21:46
uvosnokia made it throw away all touch screen events for 1 s after it gets one21:46
uvosthats extramly nessecary21:46
uvosi removed that once21:46
uvosit gets wedged for seconds after a swipe on d521:46
uvos*421:46
uvosjust processing input events21:46
freemangordonI see21:46
freemangordonok, will have a look at that, this sounds really strange21:47
freemangordonshouldn;t be that slow21:47
freemangordonif it is, then we have some design issue21:47
freemangordonwhich we shall fix by changing the design if needed21:47
uvosanyhow, if this is the issue idk21:47
uvosits just been the issue in the past21:47
freemangordonbut, I don;t think this is the reason for blanking startup issue21:48
freemangordonhave some other things to do atm, will put more traces later on21:48
freemangordonI plan to start 1s timer that reads brightness21:48
freemangordonto see after what event in log it gets 021:49
freemangordonuvos: it is   display_unblank() that blanks it :)22:26
freemangordonfirst time it is called with   cached_brightness=7 and set_brightness=022:27
freemangordonand that in turn dims the display22:28
freemangordonugh, no22:29
freemangordonit is not that22:29
freemangordonuvos: OMG: https://github.com/maemo-leste/mce/blob/master/src/modules/display.c#L24422:43
uvosyeah i know22:43
uvosthe value is a percentage22:43
freemangordonthat's calculated as 0 when new_brightness is 522:43
uvosthe valiue gets filtered to a real value later22:44
uvosno22:44
uvosso the way this works is that it should be a percentage here22:44
freemangordonset_brightness is set to 0, so display_unblank() sets brightness to 022:44
uvosand theres a table22:44
uvosthat converts it later22:44
freemangordonI put traces, lemme show it to you22:45
uvosin the same pipe22:45
freemangordonlater on it calls   update_brightness_fade(0)22:45
freemangordonsee https://pastebin.com/VbQHcVnx22:46
freemangordonsearch for display_brightness_trigger 522:46
uvosso22:47
uvoswhat are you printing there?22:47
freemangordonwhere?22:47
uvosdisplay_brightness_trigger 522:47
uvosthe 522:47
freemangordon5 is data22:47
freemangordonnew_brightness22:48
freemangordonand few lines below I print re-calculated new_brightness22:48
freemangordonlemme pastebin the code22:48
uvosso something is setting it in pannel units22:49
uvosinstead of percentage22:49
freemangordonhttps://pastebin.com/N7WPNZrG22:49
freemangordonagree22:49
uvoshttps://github.com/maemo-leste/mce/blob/d4604c30e5734af7b17e907f767267a83f52c731/src/modules/filter-brightness-als-iio.c#L13722:49
uvosthis guy is reponsable for filtering the percentage to pannel units, ususally22:50
freemangordonmaybe it is not loaded22:50
uvoscould be yeah22:50
uvosit might be loaded to late22:50
freemangordonit shoudl be clear in the logs22:50
freemangordonSep 22 23:39:00 localhost mce[2731]: Loading module: filter-brightness-als-iio from /usr/lib/mce/modules22:51
freemangordonwhen it is already too late22:51
uvosjust shove it earlier then22:52
freemangordonlemme put display at the end :)22:52
uvosand see if it goes away22:52
freemangordonmhm22:52
uvosi would avoid moving display22:52
freemangordonI already did, because it was loaded before x11, so it was never setting dpms on22:52
uvosthat should not matter22:53
uvosxorg iself sets dpms on on boot22:53
uvosmoving display causes some artifacts wrt tklock22:53
freemangordonyes, but you have code that is never going to be executed22:53
freemangordonso, it should be before tklock?22:53
uvosat least yeah22:54
uvosthere are other interactions too22:54
freemangordonok, will put it like that22:54
freemangordonhmm22:54
freemangordonok22:54
uvosalso moving the oder in general is a bad idea xD22:54
uvosthere be drangons there22:54
freemangordonwhat about inactivity?22:54
uvoswhat about it?22:54
freemangordonit should be beore display too, right>22:55
freemangordon?22:55
freemangordonand inhinit as well22:55
freemangordon*inhibit22:55
uvoswhen inhibit comes is pretty irrelivant22:55
uvosinactivitiy should stay in the same relation22:55
uvosabout the code in x1122:56
uvosits only about setting dpms on if mce crashes22:57
uvosor is restarted while x11 is running22:57
uvoson boot mce starts before x11 anyhow22:57
freemangordonI agree, but it still will not be executed22:57
uvosso it wont do anything22:57
uvosit will print extra warning even22:57
uvosok22:57
uvossure22:57
freemangordonI already moved and it started to behave correctly22:57
freemangordonlike, if you restart mce screen gets unlocked22:58
freemangordonand unblanked22:58
uvospretty sure that worked before22:58
uvosbut maybe it broke at some point..22:58
freemangordonso I think display shall be the last of x11, startup, als, inactivity, inhibit22:58
freemangordonotherwise we risk those modules to start too late and to miss event22:59
uvossure22:59
freemangordonok, will reorder22:59
uvosbut chainging the order at all risks unforseen consequences22:59
uvosso test very thoughly22:59
freemangordonwell, that is what -devel is for :)22:59
freemangordonsure22:59
uvosalso note that 10-maemo.ini or whatever overrides mce.ini23:00
uvosmodules wise23:00
freemangordonthis is what I am changing23:00
uvosok23:00
uvosalso change mce.ini too ofc23:00
freemangordonhmm, ok23:01
uvosmce installs 10-maemo.ini23:01
freemangordonwon't be able to test23:01
uvosonly if systemui is available23:01
freemangordonyeaaah, that's way better :)23:05
freemangordonuvos: yes, this fixes it23:06
uvosok23:07
norayruvos, the battery? i changed the battery and put it to charge, meanwhile while charging it rebooted. without even touching it.23:09
norayrarmenia, but i get everything via mail forwarders in usa, britain, germany.23:10
norayri'll try to use it after it charges a little bit.23:10
norayri blacklisted everyhhing back so i don't understand what is happening? i also don't remember dropping droid.23:11
norayri 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
uvoshmm wierd23:12
norayri'll take a look at the logs, and i have dmesg with some strange, maybe irrelevant errocs.23:12
uvosdo you have ramoops?23:13
norayrno 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 screen23:14
norayror when android boots.23:14
uvosno i mean ramoops is a storage where linux writes dmesg too on crash23:14
norayri thought it is an error in dmesg, related to ram23:15
freemangordonuvos: do you want PR or shall I push to master directly?23:15
uvosfreemangordon: push23:15
freemangordonok23:15
norayrwhere is that storage?23:15
uvosbut note that i added a fix just now23:15
freemangordonyep, pulled23:15
uvosnorayr: /var/log/pstore/23:18
* norayr checking23:20
freemangordonuvos: pushed23:20
freemangordonshall I make a release?23:20
uvosif you like, but i hope to fix the other issue tomorrow23:21
uvosbut taging 2 releases isent a big deal either23:21
freemangordonok, no hurry, I have the fix locally23:21
norayri see these things in ramoops:(i also saw it in dmesg)23:25
norayromap-mcbsp 40124000.mcbsp: CLKS: could not clk_get() prcm_fck23:25
norayri 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_fck23:26
norayrnot sure it is relevant.23:26
uvosthats normal23:26
norayrlast things in the ramoops are23:27
norayrprintk: console [ttyS2] disabled23:27
norayrsysrq: Changing Loglevel23:27
norayrsysrq: Loglevel set to 023:27
uvosright you have to stop it from disabeling logging23:27
uvosand retest23:27
norayrwhen i was unscrewing the battery, the contact was okay.23:36
norayrso i don't understand.23:36
norayrbut now it seems it would already crash several times in my hands.23:36
norayri ran pidgin, i played nebulous.23:36
uvosthe contacts being at fault is fairly unlikey23:36
norayrso i guess it works now.23:36
uvosif it crashes while undistrubed23:36
norayrbut i need to learn this ramoops23:36
norayrand also maybe i will be able to use it on droid323:36
uvosdosent work on d423:37
uvoser d323:37
norayroh23:37
uvosthe ramoops is mapped to a region thats beyond the d3s memory23:37
norayreh.23:37
uvoseasy fix realy, but no one is working on the d3 atm23:37
norayrit would halt for 15 times already, my droid, and it didn't yet.23:37
norayri think maybe it's not contacts, it's the battery.23:38
norayrbut can battery be in the state where it drops the voltage suddenly even when seemingly well charged?23:38
norayri don't know.23:38
uvossure23:38
norayrok looks like it works. i'll update on what is going on.23:39
uvosits internal resistance can be to high23:39
uvosd4 reacts by crashing to that23:39
uvosso that would track23:39
norayrthe battery was this 'x-longer', made in china, 1730 mah/6.4wh, and i put the same thing inside now.23:40
norayrvolts 3.7 vdc it says23:40
norayron the battery23:40
norayr'cameron sino' logo.23:40
norayrcould it be that lapdock affected the battery in some bad way?23:42
uvosNO23:42
norayrit doesn't crash now.23:42
norayrsuch a relive.23:42
norayri just enjoy using it.23:42
sicelowelcome to droid 4 :-p23:47
* uvos cries in having broken 3 d4s23:49
sicelobroken them how?23:49
uvos1. 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
norayreh.23:54
uvosmostly they are very sturdy i seams23:55
uvos*it23:55
uvosaccidents aside23:55
norayri need to buy good batteries, but no idea how.23:55
uvosi dont think you can buy any23:58
uvosyou can only make them23:58
uvosie adapt other cells23:58

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!