<tmlind>
freemangordon: n_gsm had three pending fixes between rc5 to rc6.. i slightly updated your two patches, folded in your timeout change, and ended up with one sof flush fix.. also managed to fix kfef issues reloading the modules several times and few other minor fixes
<tmlind>
freemangordon: i also finally dropped patch "drm/omap: Fix shmem write-combined buffer handling", so far no issues so i guess it's not needed and may be left over from the old ddk-1.9 hacks
Daanct12 has quit [Quit: Quitting]
mardy has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
<tmlind>
sorry i mean n_gsm to flush dlci0 sabm, not sof
<tmlind>
looks like stellarium fps has gone down again though, now about 4fps from i think 6fps, was around 12fps initially with ddk-1.17
Twig has joined #maemo-leste
ceene has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
tmlind: great ill rebase our stuff on your pending then ;)
<tmlind>
yeah v6.1 should be the lts release too
<tmlind>
uvos__: you don't happen to have voltage measurements for the d4 touchscreen lines? :)
<tmlind>
we could avoid some warnings configuring it's regulators..
<tmlind>
1.8v vio seems to be always enabled and i don't see android tweaking it
<tmlind>
i think the 2.8'ish analog voltage for the touchscree is cpcap vhvio, (very high vio?)
<tmlind>
and probably the 1.8v vio is sone of the unconfigured cpcap sw supplies
<uvos__>
no, but could try and find it on xt875, it has most things fairly acessable while powerd up
<tmlind>
uvos__: ok whenever you happen to have it open and booted, the touchscreen controller has some online pdf with the pinout
<tmlind>
probably surface mount though
<uvos__>
yeah its a really common chip
<uvos__>
might be a via close by
<tmlind>
if the vio is not 1.8V, it might be one of the configured cpcap regulators near 1.8v that are always on..
<tmlind>
there's the analog voltage for the device, and then the io voltage
<uvos__>
yeah i know, standart setup for sutch a chip ;)
<tmlind>
yeah
<tmlind>
measuring cpcap would require soldering off the shield on some device.. and we don't know the pins for it either, but measuring voltages would provide some clues still. solderging off everything from a board and having it x-rayed would provide traces as suggested earlier by somebody :)
alex1216 has joined #maemo-leste
<uvos__>
desoldering one cann is not big issue
<tmlind>
well soldering off everything would allow scanning the circuit board for the traces
<uvos__>
i dont have an xray tho :P
<tmlind>
hehe yeah
<tmlind>
would be fun to put together an unofficial schematics pdf though :)
<tmlind>
quite a bit we already know from the android sources that we already have configured for linux, just some traces are really a mystery
<uvos__>
sure yeah, well theres most of the hw end stuff
<uvos__>
that linux dosent interact with
<tmlind>
anyways, we could add a fixed regulator for 1.8v vio to avoid some regulator warnings
<uvos__>
like all the modem stuff
<tmlind>
modem power on and off works with linux though
<sicelo>
send a d4 to Doc. he x-rayed the n900 :p
<uvos__>
sure but theres lots of traces between the chips that make up the lcm2.0 ,pde,
<uvos__>
*modem
<uvos__>
etc
<tmlind>
yeah sure
<tmlind>
lcm2.0 uses the second instance of pmic inside the cpcap that we've left unconfigured fyi
<uvos__>
yeah i know
<tmlind>
sicelo: interesting, so can Doc also unsolder everything?
<uvos__>
i have played with its userspace cpcap interface while mainline is running
<uvos__>
to figure out how the leds work xD
<tmlind>
uvos__: yeah sure :)
<uvos__>
tmlind: i mean if destroying the device is no issue i can probubly clean a board off with the reflow oven
<tmlind>
ideally i'd like to just do dmesg -lerr,warn to make sure things work with no errors and warnings..
<uvos__>
ie remove everything
<uvos__>
chips included
<sicelo>
tmlind: i would wonder if he still has time ...
<tmlind>
uvos__: yeah would be best to solder off everything from some hw b donor that's partially broken :)
<tmlind>
then just scanning both sides already provides some traces
<uvos__>
its like a 6 layer pcb tho
<uvos__>
but yeah
<tmlind>
sicelo: afaik there are circuit board shops that do x-rays on regular bases to make sure no crossed connections etc
<sicelo>
nice
<tmlind>
Wizzup: got some broken d4 hw b donor mobo for tracing the connections? i guess bying a mobo off ebay for $10 is another option
<tmlind>
Wizzup, __uvos: there are $10 mobos on ebay right now fyi if no other donor is found :)
<tmlind>
oh well, i need to get busy here, bbl later tonight
<uvos__>
dosent need to be hwb
<uvos__>
the mobos are all the same
<uvos__>
they all have hwa in the silkscreen
<uvos__>
the difference is only the chips and the molds for the case
<uvos__>
well one chip
<tmlind>
ok
Twig has quit [Remote host closed the connection]
<buZz>
does stellarium support the accelerometer etc?
norayr has left #maemo-leste [Error from remote client]
alex1216 has quit [Ping timeout: 268 seconds]
<buZz>
meh, chargecounter was >850 , phone shutdown with white led, but chargefull after reboot is still 650, ffs
<sicelo>
:-)
<sicelo>
d4/cpcap is a lot of 'fun'
<buZz>
such a annoying dance :D
<sicelo>
what's chargecounter btw?
<buZz>
cant wait to get some fresh battery inside it
<buZz>
afaik it keeps 'how many ma has battery supplied since 100%'
<sicelo>
i am not sure ... i think it just counts from anywhere to anywhere. i might be wrong though
<buZz>
i dont believe so, during charge its negative
<sicelo>
i.e. 850 in it doesn't really mean 850mAh. the charge full is the delta between what it was at 100 and what it is at empty (or so)
<sicelo>
yes @negative ...
<buZz>
i do think its what we use to keep track
<buZz>
but could be wrong
<sicelo>
yes it tracks (counts) the coulombs. i just mean that the count itself isn't a 'usable' value iirc, but you keep track of the delta between its highest and lowest, something like that
xmn has quit [Ping timeout: 260 seconds]
<buZz>
still havent found a vendor selling new rightsize lipo that are 3.8/4.35v
alex1216 has joined #maemo-leste
<buZz>
i've considered making a 'powerbank' to dock the d4 in
<buZz>
just 2x 18650 or something, would make it silly thick
<buZz>
:)
<buZz>
maybe even 4x 18650 could fit in the 13cm width
<buZz>
and just use the pogopins interface to expand the battery
<buZz>
with 4x parallel, they should at least be able to source enough current to not get drops from 3.6v to 'oo lets powerdown device!'
<buZz>
hehe
* buZz
hands out fresh pizza slices
akossh has joined #maemo-leste
<Wizzup>
tmlind: I don't have a dead one but can send a live one
<Wizzup>
tmlind: any chance you had a look at the MASTER_USBOSTHS issue with the modem shutting down, and that calling usbhs_omap_remove() ? (sorry if a bad summary)
<Wizzup>
uvos__: great @ kernel
<uvos__>
the value of the charge counter itself is indeed meaninless on its own
<uvos__>
it can be 10 1000 -1000 or whatever really
<uvos__>
its only capapble of telling you the delta during a single boot
<uvos__>
Wizzup: i gues that wold be sending it to me not tmlind, however we need to know where it could be xrayed first
<Wizzup>
are there services that do this?
<uvos__>
sure
<uvos__>
but $$$$ i presume
<Wizzup>
wonder how much
<uvos__>
also we need to find one close to whomever wants to clean the chips off the pcb
<uvos__>
i can do that, but yeah
<uvos__>
buZz: im not sure what you think its wrong with the nexus 4 battery
<uvos__>
its a pretty mutch perfect replacement
<buZz>
i asked which battery you ment and didnt get a reply before :) can i order and mod that 'now' ? will it be a new cell?
<buZz>
and its not 4.35v i think?
<uvos__>
yes
<uvos__>
i is 4.35 iirc (i dont use it like that)
<uvos__>
its the one that fits in the nexus 4, i dont remeber the code rn but its in the irc history
<buZz>
ah, nice, hv cells have about 10-20% more capacity (if used like hv)
<uvos__>
no
<buZz>
ok
<uvos__>
they dont
<buZz>
ok chemistry is lying then :P
<uvos__>
the higher capacity comes from the higher nominal voltage
<uvos__>
so if you charge it to 4.2 you dont loose the advantage
<buZz>
plus lower empty voltage
<uvos__>
as the carge end voltage is not the gain here
<uvos__>
the higher nominal voltage is
<uvos__>
anyhow polarcell makes them
<uvos__>
they are new (ish at least)
<uvos__>
mine is from 2018 i think
* buZz
opens ebay
<uvos__>
or 19
<uvos__>
bought in 2020
<uvos__>
or 21 maybe
<uvos__>
something like that
<buZz>
oo 2250mAh even , nice
<uvos__>
well mine dose 1900 ish mah
<uvos__>
so its a lie a bit
<buZz>
gee, 20euro though
<buZz>
expensive battery :D costs almost 'another d4' hehe
<uvos__>
d4s have become more expensive
<uvos__>
so no
<uvos__>
but yes expensive
<Wizzup>
last I checked I couldn't even find one for sale
<buZz>
gee
<buZz>
you bought em all Wizzup !
<buZz>
end of a era
<buZz>
lol
<Wizzup>
I wish there was a way to advertise on ebay that you want to buy something
<uvos__>
craiglist
<uvos__>
*s
<buZz>
lol, for 40-50 i could buy a whole nexus4
<uvos__>
might be worth a shot really
<buZz>
uvos__: do you use craigslist outside of US?
<uvos__>
no
danielinux has quit [Ping timeout: 255 seconds]
<buZz>
oh ok
<Wizzup>
no, but the d4's are only *in* the us
<uvos__>
thats the point
<buZz>
right
<buZz>
ok, clear
alex1216 has quit [Quit: WeeChat 2.3]
<buZz>
so BL-T5 is the nexus4 battery
<buZz>
almost even looks like the d4 battery connection? but i assume it requires modding
<uvos__>
yes you need to replace everything but the cell itself
<buZz>
ait, ordered one
<buZz>
uvos__: so it will gain the nvram/whatever storage from the original cell too? nice!
<buZz>
i can take stepbystep pics of modding such battery, or a timelapse, or maybe a whole 5min (editted) video?
<uvos__>
freemangordon did that by harvesting the pcb from a eb41
<uvos__>
i have not, i used my custom adaper pcb
<uvos__>
i presume you can film whatever you want :P
<uvos__>
that would be good for others ofc
akossh has quit [Read error: Connection reset by peer]
<buZz>
i will do a harvest from the italian? 'new' battery i got, its barely 400mAh as-is
<buZz>
(was just a new sticker around a old cell)
<buZz>
alright, a friend is going to help photo&videorecord the mod
<buZz>
photos for the wiki, video for whatever
<buZz>
he's excited for such nobel documentation to be made, lol
akossh has joined #maemo-leste
alex1216 has joined #maemo-leste
DPA has quit [Read error: Software caused connection abort]
<Wizzup>
uvos__: probably craiglist is not a bad idea
peetah has quit [Quit: -]
DPA has joined #maemo-leste
peetah has joined #maemo-leste
norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
<uvos__>
Wizzup: *craigslist
<uvos__>
Wizzup: yes, if you have some address people cand send stuff too permanently
<uvos__>
Wizzup: archive.org i presume
<Wizzup>
or colleages
danielinux has joined #maemo-leste
<Wizzup>
tmlind: is there any way to get the old (pre kernel console detaching from serial for pm reasons) behaviour for chasing bugs?
<Wizzup>
instead of running say dmesg -w from a tty
<Wizzup>
I feel, and this is just a feeling, that I'd normally see 'more' on serial
<uvos__>
the pm script detachtes the konsole
<uvos__>
just add console= parameter to cmdline and comment the line in the pm script
<uvos__>
ofc this breaks pm
<Wizzup>
uvos__: so how do we change pm problems?
<Wizzup>
uvos__: I -believe- that this was possible before this change in the kernel
<uvos__>
i dont think ret while the uart is not idle (and kernel console keeps it active) was ever possible
<uvos__>
iiuc its is possible possible in the hw sense tho
<Wizzup>
maybe I misunderstand then, I just thought that I was doing pm testing often with kernel console on serial, but it's been a while now
<uvos__>
at some point we removed the console= parameter from cmdline causeing there to be no kernel output even before the pm script loads
<uvos__>
maybe you remember that
DPA has quit [Ping timeout: 256 seconds]
<Wizzup>
hmm
<buZz>
meh, trojita seems to have corrupted something in its storage and doesnt seem to recover itself, lets see if/where i can delete caches
<uvos__>
buZz: hmm
<uvos__>
buZz: ~/.local/share/trojita i think
<uvos__>
or close to it
<buZz>
yeah somewhere, just dont want to delete profile
<buZz>
weird, i have /home/user/.local/.local/*
<buZz>
hmm and no files there, boo
DPA has joined #maemo-leste
rafael2k has joined #maemo-leste
<buZz>
i bet its ./.cache/flaska.net/trojita/imap.cache.sqlite
<buZz>
yep
<buZz>
just moved it away, it made a new one at launching
<sicelo>
Wizzup... re-ip address issue on gprs: part of the issue is that ip addresses persist in gconf. i think they should be flushed when a gprs session is torn
<sicelo>
or, if they have persisted (e.g. due to unclean shutdown of system), before using them next time, check first to see if network/ofono didn't send different
<uvos__>
why save it at all?
<uvos__>
the ip is only valid as long as gprs is active and gprs is active for less than system lifetime at a time, saveing the ip to disk at all seams like a contrivance
<sicelo>
i guess saving was implemented in case some (lucky?) soul has static IP addresses on gprs
<Wizzup>
no, it's just saved because that's how it is passed to the ipv4 module currently
<Wizzup>
we can have the gprs module do its own ipv4 as an alternative
<Wizzup>
at least that's what it was before fmg changed it
<Wizzup>
maybe it's different now
<uvos__>
something something gconf as ipc...
<Wizzup>
I think it can be done differently, and maybe it already is, I haven't checked
<Wizzup>
in any case, trying to reproduce a hang I had yesterday
<Wizzup>
was playing a video in mpv and at some point the audio started looping and it reset shortly after, nothing in pstore
<uvos__>
i get those often
<uvos__>
> 1 day
<uvos__>
when in active use
<uvos__>
its stable when not
<Wizzup>
it kind of reminded me of a long time ago when we were trying to debug a problem of reset while playing music, but then the screen was off and the device in my pocket
<uvos__>
that happend when lightly loaded
<uvos__>
or idle
<uvos__>
this is opposit
<uvos__>
i think it got mutch worse with the lasst round of xorg patches
<uvos__>
those where now dmabuf fds are created mutch more often
<uvos__>
makes me belive its pvr/omapdrm
<Wizzup>
well, it's playing with -vo xv --loop
<Wizzup>
so we'll find out I guess :)
<uvos__>
also the problem where chargemode or xorg hangs
<uvos__>
i think these are relatd
<Wizzup>
yes but it does not reset from that
<uvos__>
yeah but i kinda think its related
<Wizzup>
or maybe the wd is not set up to dsme then
<Wizzup>
no, it must be for x
<uvos__>
no kernel just dosen hang
<uvos__>
just dri is non functional after that
<uvos__>
ie just the pvr/omapdrm driver breaks
<uvos__>
the xv loop is probubly the least usefull way to test this if my theory is correct
<uvos__>
since i think its related to buffer creation
<uvos__>
and that dosent create any
<Wizzup>
well, but it just happened mid-way while I was watching/listening, not touching anyting
<Wizzup>
I am just trying to reproduce what happened to me yesterday
<uvos__>
yeah ok
<Wizzup>
and it's a relatively easy/lazy way to test it :)
<uvos__>
may theorys also dont have to be correct :P
<Wizzup>
just leave it here on psu
<uvos__>
give it a low voltage maybe
<uvos__>
3.6V
<Wizzup>
I need to get a better psu here, it's noisy and measure is not accurate :(
<uvos__>
ok
<Wizzup>
yeah I can do that, just afraid to turn the knobs
<Wizzup>
so I'd power it down and re-try
<Wizzup>
it's on 3.9V atm
<uvos__>
i also kinda get the fealing it happens more often when battery is low
<Wizzup>
mhm
xmn has joined #maemo-leste
<freemangordon>
tmlind: sorry, I am on a business trip till thursday
<freemangordon>
however, it turned out that modem poweroff patch is not needed at least on d4
<freemangordon>
where off current is already fine
<freemangordon>
if you still want the patch, I think uvos__ has it
<freemangordon>
tmlind: regarding GPU rendering - sometimes d4 has to be power-cycled to recover from low FPS
<freemangordon>
seems to be somehow related with low battery
<freemangordon>
BlagovestPetrov[: Wizzup: Please, when you porting to chimaera, make sure beowulf-devel and master branches match
<Wizzup>
yeah, I've done this
<freemangordon>
I ran on projects that have differences a couple of times
<BlagovestPetrov[>
I will check this :)
<freemangordon>
thanks!
<Wizzup>
freemangordon: I was thinking of just merging most of -devel to non-devel
<Wizzup>
maybe it's also time we just merge the phone stuff to non-devel
<Wizzup>
it's not that buggy anymore I think
<freemangordon>
yeah, why nbot
<freemangordon>
*not
* freemangordon
is afk
alex1216 has quit [Quit: WeeChat 2.3]
uvos__ has quit [Ping timeout: 260 seconds]
<Wizzup>
uvos: I imported mce-dev for now
elastic_1 has joined #maemo-leste
elastic_dog has quit [Killed (calcium.libera.chat (Nickname regained by services))]
uvos__ has joined #maemo-leste
<uvos__>
for me phone stuff is still terribly buggy
<uvos__>
i cant send sms at all ever (this broke with freemangordon's rounds of ofono bugfixing, wich did improve everything else)
<uvos__>
ofono allways fails to find an operator on first start
<uvos__>
and needs to be restarted
<uvos__>
ofono will randomly fail to make the modem search for an operator when the operator is lost
<uvos__>
untill it is restarted
<Wizzup>
uvos__: which device?
<uvos__>
d4
<Wizzup>
I have not seen this on the d4
<Wizzup>
but I do have some issues on the bionic
<uvos__>
i also had to add the apn by hand
<uvos__>
because icd failed to figure it out itself
<uvos__>
so really nothing works on my end besides calls _P
<uvos__>
:P
<uvos__>
the operator loosing is related to gsm only / gsm only sim
<uvos__>
btw
<uvos__>
freemangordon was able to repo this by forcing gsm
<Wizzup>
ah, right
<Wizzup>
my bionic actually refuses to go on 3g :)
<Wizzup>
but the d4 has no problems with it
<uvos__>
that expected
<uvos__>
its antenna is horrid for umts bands
<Wizzup>
I got it to work somewhat with some change
<uvos__>
ok
<Wizzup>
idk y d4 has full bars...
<uvos__>
d4 was desgned for umts
<Wizzup>
I think it's some nvram thing
<uvos__>
as its a global phone
<uvos__>
binoic was not
<uvos__>
its antenna design is different
<uvos__>
global = advertised global roaming
<uvos__>
the bionic ist just not optimized for umts bands
<Wizzup>
well, it worked before, I think it's a config thing
<uvos__>
there was someone on xda who hooked up the antenna to a vna
<uvos__>
Wizzup: ok it should work
<uvos__>
just poor range
<Wizzup>
right
<uvos__>
depends on what band of umts too ofc
<Wizzup>
right
<uvos__>
oh and the issue that the icd conetion dialog breaks compleatly if the cellular module is installed but the dummy module is not installed and the cellular module is unable to provide a network still exists
<uvos__>
so installing the cellular icd module will break wifi on every phone with no sim
<Wizzup>
I'm going to look at organising the github issues a bit differently
<BlagovestPetrov[>
but python-gconf is in maemo beowulf
pere has quit [Ping timeout: 248 seconds]
<tmlind>
Wizzup, __uvos: here's what i did on bionic for tmo 3g voice calls, see the untested value below that just might get you signal with wcdma 900
<tmlind>
tcmdrw 1143=b1ff0000 # NV_WCDMA_1900_VGA_GAIN_OFFSET_I, tmo 3g, xt910 default value
<uvos>
Wizzup: maybe just target removeing them entirely
<uvos>
the bindings then
<Wizzup>
I was thinking we would do this with gtk3
<uvos>
anyhow a list would be good
<Wizzup>
we can just get this from looking at debian/control
<uvos>
sure if you have all repos cloned
<uvos>
presumably BlagovestPetrov[ will have
<Wizzup>
the more annoying thing might be that this might make it impossible to use gconf from python 3 :D
<uvos>
thats why i was asking him
<uvos>
well gconf also has to go so..
<Wizzup>
this easily adds up to weeks or work, I'd rather first complete the gtk3 port theming wise
<Wizzup>
and then we can look at just migration away from gtk2 perhaps
<Wizzup>
and then suddenly everything will be easier
<uvos>
sure im not suggesting any timeframe for anything
<Wizzup>
(Ithink)
<Wizzup>
right
<Wizzup>
yeah I fully agree :)
Pali has joined #maemo-leste
<BlagovestPetrov[>
I would propose migrating directly to Qt if the menu and other widgets works :D
<BlagovestPetrov[>
gtk4 is even worse
<uvos>
way to mutch work
<Wizzup>
and also more resource intensive
<uvos>
than gtk3?
<uvos>
doubt
<Wizzup>
:(
<uvos>
anyhow at that point your better off throwing away hildon entirely and writeing a wayland comp.
<uvos>
from scratch
<Wizzup>
which will be years or work to get at the same point :)
<uvos>
right
<Wizzup>
we just want to support both gtk and qt
<Wizzup>
with gtk3 we were mostly there, but not all the way, qt5 needs mostly some bugfixing and the keyboard
<uvos>
the main thing i would hope for from gtk3 is scaling support
<uvos>
that really kills hildon on anything modern
<Wizzup>
we have a problem with theming in general too though
<Wizzup>
I mean gtk2 vs gtk3
<Wizzup>
nothing is compatible
<uvos>
yeah
<uvos>
they threw away the theming engine
<uvos>
and then proceeded to break the new one every release
<uvos>
so now theres only one gtk theme that works ok
<uvos>
:P
<uvos>
not to mention the efforts to push everyone into csds
<uvos>
since those totaly work great for an app that needs to work on a phone and desktop :P
<BlagovestPetrov[>
I'm not against GTK but I am. It was a good framework but their decisions are insane. Also, most of the new Gnome apps are self painting the window frame
<uvos>
eh idk i never liked gobject at all
<uvos>
lovey erros happen due to the lack of type checking at compiletime
<BlagovestPetrov[>
C is not for GUI..
norayr has left #maemo-leste [Disconnected: closed]
<uvos>
right if your going to be so deeply object oriented just use c++ already
<BlagovestPetrov[>
that's their main problem and that's why there are projects like Vala :)
<tmlind>
buZz: i think stellarium supports sensors maybe on android only? not sure
<uvos>
tmlind no
<tmlind>
Wizzup: i might have a dead d4 mobo somewhere in my boxes but won't be able to check for a few weeks
<Wizzup>
tmlind: if you know, could you refresh my memory on my question regarding getting certain oops/panics on console and if that was easier before the kernel console detaching for pm business?
<uvos>
it supports remote sensors on linux at least
<tmlind>
uvos: ok
<uvos>
tmlind: at the very least you could run the remote sensor thingy on the d4 too
<uvos>
and have it work over localhost
<tmlind>
Wizzup: what are you trying to capture?
<tmlind>
uvos: i'm happy with stellarium and keyboard :) so far no need for sensors
<Wizzup>
tmlind: I am trying to reproduce some reset and want to make sure the ability for me to see any panic/oops on serial is the highest
<uvos>
tmlind: hang and reboot during heavy load
<Wizzup>
I somehow feel (but maybe this is just a feeling) that it was easier before the console detaching
<Wizzup>
I stopped the detaching for now, but ofx during idle tests that doesn't work
<Wizzup>
ofx->ofc
<tmlind>
Wizzup: ok just echo Y > console in the sysfs and uart won't get idled and uart should always print out errors
<Wizzup>
do we ever enter RET then?
<tmlind>
Wizzup: also echo 9 > /proc/sysrq-trigger for the loglevel
<tmlind>
Wizzup: no not with a console attached
<Wizzup>
ok, I just seem to recall before all of that we did idle with serial attached, but I might recall wrong
<Wizzup>
probably recall wrong
<tmlind>
Wizzup: if you want to trace idle, you need to use pstore if you have a hang.. but seems like enabling the modem will often prevent watchdog reset from booting properly
<uvos>
tmlind: well thats an important clue
<uvos>
the hang isent related to the modem
<tmlind>
Wizzup: yeah it used to work somehow, but kernel serial console no longer does any pm because if was flakey
<Wizzup>
tmlind: ok, so my memory isn't totally failing me
<tmlind>
uvos: at least i think it's the modem that somehow affects watchdog reset not booting properly, not sure
<uvos>
well the reset works fine
<uvos>
it reboots
<uvos>
so this is not the case here then?
<tmlind>
not with pstore enabled, there's something with either pm enabled or modem enabled where echo c > /proc/sysrq-trigger watchdog reset hangs the system before getting into the bootloader
<uvos>
or what is the symptom of not "booting properly"?
<uvos>
a double reset?
<tmlind>
incomplete reset where bootloader hangs before showing anything
<uvos>
ok
<uvos>
hmm hard to catch that
<tmlind>
but i'm not sure what exactly causes it to fail, not changing the soc reset time for pstore makes the issue go away, but ddr is reset and no pstore log
<tmlind>
i don't see how the modem being enabled triggers it though..
<uvos>
probubly bug in mbm that is not happy with some state not clearing because the reset time is to low
<uvos>
if id have to guess
<tmlind>
yeah something like that
<buZz>
tmlind: sounds like libiio for stellarium could be welcome
<tmlind>
Wizzup: no i have not had a chance to debug modem disconnecting issue, totally forgot about that
<tmlind>
buZz: yeah i guess pointing to the sky and having the map move would be cool
<tmlind>
freemangordon: ok i'll check stellarium fps after reboot when i get a chance
<buZz>
tmlind: killerfeature for such application :)
<Wizzup>
tmlind: no, I had a vim open with you remarks to that's how I remembered :D
<Wizzup>
your remarks*
<Wizzup>
I moved them to a github issue
<tmlind>
heh ok
norayr has left #maemo-leste [Error from remote client]
<Wizzup>
the annoying thing about the bug is that it recurs many times per second so it fills up fs entirely
<tmlind>
Wizzup: which bug is that?
<Wizzup>
the one where modem disappears and there's invalid access
<Wizzup>
maybe it is lower battery, maybe something else
<Wizzup>
it seems to happen to me when I charge my phone in my car, but also when I don't and use bluetooth from it for a while
<Wizzup>
I don't know if the modem disappearing is ultimately a hw problem
<Wizzup>
uvos: iirc this is for the n900, best to check with sicelo, but default I think should be keep
<Wizzup>
uvos: without this the n900 resets on modem use
<uvos>
this looks really ugly
<uvos>
is there some work with upstream here?
<Wizzup>
so the problem is that it's unclear to me if dma was ever used on the n900
<tmlind>
Wizzup: we should have phy-mapphone-mdm6600 driver get an interrupt on modem offline, and then disable the usb phy
<Wizzup>
uvos: I did sent some mails to the list, but I believe it seemed to me that people were waiting for me to do more :p
<tmlind>
i don't think we do anything with the interrupt right now
<Wizzup>
tmlind: would that allow for the modem to come back?
<sicelo>
yes the patch is still needed, so it should be kept
norayr has joined #maemo-leste
<sicelo>
where's the kernel config used for the kernel by the way?
<tmlind>
Wizzup: it would allow phy-mapphone-mdm6600 wait for modem to come back, then re-add the phy
<Wizzup>
tmlind: that makes a lot of sense to me
norayr has left #maemo-leste [Error from remote client]
<tmlind>
of course nothing protects from the invalid register access while the phy is being unloaded..
<tmlind>
uvos: can't get sudo sh -c "echo c > /proc/sysrq-trigger" to fail so far with v6.1 kernel, so far it has rebooted every time now..
<tmlind>
Wizzup: maybe add some printk to phy-mapphone-mdm6600.c on state changes if you have it reproducable?
<uvos>
its camera shy
norayr has joined #maemo-leste
<tmlind>
yeah
<Wizzup>
tmlind: semi reproducible yeah, I just need to go on a drive in the car :)
<Wizzup>
I might wait for uvos to pkg 6.1
<tmlind>
Wizzup: hmm phy_mdm6600_status() already prints the changed status with dev_info, maybe check your loglevel?
<tmlind>
if that does not trigger, then there might be a bug detecting changed status
norayr has left #maemo-leste [Error from remote client]
mardy has quit [Quit: WeeChat 3.5]
<tmlind>
Wizzup: also, if you just want the system to hang when it happens and reboot, you could comment out postcore_initcall_sync(omap_l3_init) in drivers/bus/omap_l3_noc.c
norayr has joined #maemo-leste
<tmlind>
then an invalid device access will hang without producing the l3 irq
<tmlind>
and then after a watchdog reset, you can check the files in /sys/fs/pstore
<tmlind>
if the watchdog reboot works..
pere has quit [Ping timeout: 256 seconds]
norayr has left #maemo-leste [Error from remote client]
* tmlind
zzz
<buZz>
can i stop charging through sysfx?
<buZz>
sysfs*
<buZz>
maybe setting constant_charge_voltage to 0?
<uvos>
we need to merge more stuff
<uvos>
why isent the d3 dts in mainline for instance
<uvos>
buZz: yes
<buZz>
oooo then i could make a autocalibrater
<uvos>
sure
<buZz>
put d4 on charger, run script, wait till fullycharged, stop charger, wait till capacity_level: low, turn on charger
<uvos>
Wizzup: nerf compaction interval to 120s instead of 500ms
<uvos>
do we still need this?
<buZz>
uvos: if i want to document batterymod fully, i also need 'obvious' evidence, that was my intention with it
<uvos>
the do we still need this was directed at Wizzup