Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
joerg is now known as DocScrutinizer
DocScrutinizer is now known as joerg
Daanct12 has quit [Remote host closed the connection]
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 264 seconds]
macros_ has joined #maemo-leste
Twig has joined #maemo-leste
mardy has joined #maemo-leste
rafael2k has joined #maemo-leste
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 244 seconds]
xmn has quit [Quit: ZZZzzz…]
rafael2k_ is now known as rafael2k
uvos has joined #maemo-leste
ceene has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
Pali has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
pere has quit [Ping timeout: 244 seconds]
Pali has quit [Ping timeout: 250 seconds]
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
pere has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
<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
Livio has quit [Quit: leaving]
<uvos>
this also bugs me to high heven, and if you try and debug it, it goes away ususaly
<uvos>
(seams timeing sensitve + only happens if you disable debug output via uart)
<freemangordon>
here it happens every time I reboot or poweroff
<uvos>
right
<uvos>
but if you enable more kernel debug options it goes away
<freemangordon>
ah
<uvos>
and if you dont suspend the console
<freemangordon>
well, I guess printk() to the rescue
<uvos>
(ie keep loging to uart it also gos away)
<freemangordon>
sure it is PM enabled
<uvos>
i think its directly related to kernel consoles usage of the uart device
<uvos>
but idk really
<freemangordon>
me neither
<freemangordon>
I can try and put some printks around that function
<freemangordon>
later on
<rafael2k>
hi all
<rafael2k>
I made a PR for the pine64 kernel, in order to address Wizzup issue with lost usbnet...
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
pere has quit [Ping timeout: 244 seconds]
<Wizzup>
rafael2k: thanks
<rafael2k>
Wizzup: do you have a ETA to build this?
<rafael2k>
I will bypass this and already make the PR for 5.15.68 soon
<Wizzup>
did you update the pr, or is it the same from 2-3 days ago?
<rafael2k>
I will start compiling 5.15.68 now
<Wizzup>
ah ok
<Wizzup>
7 days ago even :)
<rafael2k>
In a couple of days I should have 5.15.68 tested and ready
<Wizzup>
ok, will merge momentarily, do I need to re-tag
<rafael2k>
no
<rafael2k>
same source
<rafael2k>
I mean, dunno what you mean by re-tag, but it applies to the same kernel source as previous kernel
<Wizzup>
building
<rafael2k>
: )
<rafael2k>
as it was a trivial change, I did not build myself
<rafael2k>
so there is a change I did some mistake and build crashes applying the patches
<rafael2k>
*chance
<rafael2k>
for 5.15.68 I'm building and testing, as it is a kernel version bump... better make sure
<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
<Wizzup>
ok
ceene has quit [Ping timeout: 265 seconds]
alex1216 has joined #maemo-leste
pere has joined #maemo-leste
<rafael2k>
Wizzup, compiling 5.15.68 here... I think the PR will fail, sorry - confirm to me it fails, I do another PR
<Wizzup>
ok
<Wizzup>
I will be afk for a few hours soon
Livio has quit [Ping timeout: 264 seconds]
<rafael2k>
editing patches by hand never works, as next patches get "fuzz" and build fail... aaarrrgggg
<freemangordon>
I already did, because it was loaded before x11, so it was never setting dpms on
norayr has joined #maemo-leste
<uvos>
that should not matter
<uvos>
xorg iself sets dpms on on boot
<uvos>
moving display causes some artifacts wrt tklock
<freemangordon>
yes, but you have code that is never going to be executed
<freemangordon>
so, it should be before tklock?
<uvos>
at least yeah
<uvos>
there are other interactions too
<freemangordon>
ok, will put it like that
<freemangordon>
hmm
<freemangordon>
ok
<uvos>
also moving the oder in general is a bad idea xD
<uvos>
there be drangons there
<freemangordon>
what about inactivity?
<uvos>
what about it?
<freemangordon>
it should be beore display too, right>
<freemangordon>
?
<freemangordon>
and inhinit as well
<freemangordon>
*inhibit
<uvos>
when inhibit comes is pretty irrelivant
<uvos>
inactivitiy should stay in the same relation
<uvos>
about the code in x11
<uvos>
its only about setting dpms on if mce crashes
<uvos>
or is restarted while x11 is running
<uvos>
on boot mce starts before x11 anyhow
<freemangordon>
I agree, but it still will not be executed
<uvos>
so it wont do anything
<uvos>
it will print extra warning even
<uvos>
ok
<uvos>
sure
<freemangordon>
I already moved and it started to behave correctly
<freemangordon>
like, if you restart mce screen gets unlocked
<freemangordon>
and unblanked
<uvos>
pretty sure that worked before
<uvos>
but maybe it broke at some point..
Livio has quit [Ping timeout: 246 seconds]
<freemangordon>
so I think display shall be the last of x11, startup, als, inactivity, inhibit
<freemangordon>
otherwise we risk those modules to start too late and to miss event
<uvos>
sure
<freemangordon>
ok, will reorder
<uvos>
but chainging the order at all risks unforseen consequences
<uvos>
so test very thoughly
<freemangordon>
well, that is what -devel is for :)
<freemangordon>
sure
<uvos>
also note that 10-maemo.ini or whatever overrides mce.ini
<uvos>
modules wise
<freemangordon>
this is what I am changing
<uvos>
ok
<uvos>
also change mce.ini too ofc
<freemangordon>
hmm, ok
<uvos>
mce installs 10-maemo.ini
<freemangordon>
won't be able to test
<uvos>
only if systemui is available
<freemangordon>
yeaaah, that's way better :)
<freemangordon>
uvos: yes, this fixes it
<uvos>
ok
<norayr>
uvos, the battery? i changed the battery and put it to charge, meanwhile while charging it rebooted. without even touching it.
<norayr>
armenia, but i get everything via mail forwarders in usa, britain, germany.
<norayr>
i'll try to use it after it charges a little bit.
<norayr>
i blacklisted everyhhing back so i don't understand what is happening? i also don't remember dropping droid.
<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.
<uvos>
hmm wierd
<norayr>
i'll take a look at the logs, and i have dmesg with some strange, maybe irrelevant errocs.
<uvos>
do you have ramoops?
<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
<norayr>
or when android boots.
<uvos>
no i mean ramoops is a storage where linux writes dmesg too on crash
<norayr>
i thought it is an error in dmesg, related to ram
<freemangordon>
uvos: do you want PR or shall I push to master directly?
<uvos>
freemangordon: push
<norayr>
where is that storage?
<freemangordon>
ok
<uvos>
but note that i added a fix just now
<freemangordon>
yep, pulled
<uvos>
norayr: /var/log/pstore/
* norayr
checking
<freemangordon>
uvos: pushed
<freemangordon>
shall I make a release?
<uvos>
if you like, but i hope to fix the other issue tomorrow
<uvos>
but taging 2 releases isent a big deal either
<freemangordon>
ok, no hurry, I have the fix locally
<norayr>
i see these things in ramoops:(i also saw it in dmesg)
<norayr>
omap-mcbsp 40124000.mcbsp: CLKS: could not clk_get() prcm_fck
<norayr>
i have those right now too:
<norayr>
[Fri Sep 23 01:22:32 2022] omap-mcbsp 40124000.mcbsp: CLKS: could not clk_get() prcm_fck
<norayr>
not sure it is relevant.
<uvos>
thats normal
<norayr>
last things in the ramoops are
<norayr>
printk: console [ttyS2] disabled
<norayr>
sysrq: Changing Loglevel
<norayr>
sysrq: Loglevel set to 0
<uvos>
right you have to stop it from disabeling logging
<uvos>
and retest
<norayr>
when i was unscrewing the battery, the contact was okay.
<norayr>
so i don't understand.
<norayr>
but now it seems it would already crash several times in my hands.
<norayr>
i ran pidgin, i played nebulous.
<uvos>
the contacts being at fault is fairly unlikey
<norayr>
so i guess it works now.
<uvos>
if it crashes while undistrubed
<norayr>
but i need to learn this ramoops
<norayr>
and also maybe i will be able to use it on droid3
<uvos>
dosent work on d4
<uvos>
er d3
<norayr>
oh
<uvos>
the ramoops is mapped to a region thats beyond the d3s memory
<norayr>
eh.
<uvos>
easy fix realy, but no one is working on the d3 atm
<norayr>
it would halt for 15 times already, my droid, and it didn't yet.
<norayr>
i think maybe it's not contacts, it's the battery.
<norayr>
but can battery be in the state where it drops the voltage suddenly even when seemingly well charged?
<norayr>
i don't know.
<uvos>
sure
<norayr>
ok looks like it works. i'll update on what is going on.
<uvos>
its internal resistance can be to high
<uvos>
d4 reacts by crashing to that
<uvos>
so that would track
<norayr>
the battery was this 'x-longer', made in china, 1730 mah/6.4wh, and i put the same thing inside now.
<norayr>
volts 3.7 vdc it says
<norayr>
on the battery
<norayr>
'cameron sino' logo.
<norayr>
could it be that lapdock affected the battery in some bad way?
<uvos>
NO
<norayr>
it doesn't crash now.
<norayr>
such a relive.
<norayr>
i just enjoy using it.
<sicelo>
welcome to droid 4 :-p
* uvos
cries in having broken 3 d4s
<sicelo>
broken them how?
akossh has quit [Quit: Leaving.]
<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)
<norayr>
eh.
<uvos>
mostly they are very sturdy i seams
<uvos>
*it
<uvos>
accidents aside
<norayr>
i need to buy good batteries, but no idea how.
<uvos>
i dont think you can buy any
<uvos>
you can only make them
<uvos>
ie adapt other cells
<norayr>
omg
<norayr>
Capacity of this battery is also 37% but i dont thik i ever used it.