joerg has quit [Ping timeout: 248 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 260 seconds]
macros_ has joined #maemo-leste
mardy has joined #maemo-leste
norayr has joined #maemo-leste
Pali has joined #maemo-leste
<freemangordon> Wizzup: uvos: is it save to remove/insert sim card while droid4 is powered?
Twig has joined #maemo-leste
Pali has quit [Ping timeout: 244 seconds]
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
uvos has joined #maemo-leste
xmn has quit [Ping timeout: 244 seconds]
pere has joined #maemo-leste
<uvos> freemangordon: yes
norayr has left #maemo-leste [Error from remote client]
Livio has quit [Ping timeout: 268 seconds]
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
norayr has joined #maemo-leste
<Wizzup> freemangordon: so there are several radio interfaces and what ended up happening is that it'd reset the tech to NULL when it iterated over the interfaces
<Wizzup> iirc it was probably cdma or something (I'd have to check the logs)
<Wizzup> so this simple checks if the radio tech is set to anything sensible
<Wizzup> s/NULL/-1/
<Wizzup> simple->simply
<uvos> whats wrong with haveing those? they may work in some contires after all
<Wizzup> uvos: huh?
<Wizzup> the problem is that ofono will report no technology in dbus because it nukes the good one
<Wizzup> if you're in a cdma place with no 2g then it will use the cdma tech
<uvos> ok then i read that wrong
<uvos> i sounded to me like you nixed them
<Wizzup> freemangordon: so one of the ofono problems that I think are maybe at the root of the problems: on the d4, when you boot with a sim that has a pin, it just will not detect the sim until you issue some operation, like SetProperty Online true, or just restart ofono (and even then it won't always pick it up)
<Wizzup> on the bionic this particular problem with pin doesn't exist
<Wizzup> similarly there are other problems I think with messages to ofono "getting lost", or at least they don't make it all the way to the right handlers
<Wizzup> for example when I set the context to active, it sometimes just times out, unless in the meantime I poke ofono in some other way, like by sending a sms to my other phone number
<Wizzup> what might be worth trying it setting up the 'regular' qmi modem driver which uses usb only (and uses a lot of pm and doesn't idle well) to see if that shows any of these problems
<Wizzup> I don't know how to do it anymore, but can try to help to figure it out
<freemangordon> Wizzup: do you know a way to re-create the issue without rebooting the device?
<Wizzup> no
<Wizzup> there are definitely other issues, but not as reproducible as this one
<freemangordon> did you try to re-plug the card?
<Wizzup> I did not
<Wizzup> like if you restart ofono, it will only pick up the modem some of the time
<freemangordon> ok
<Wizzup> and if you set Online to false and then back to true, I think it just aborts
<freemangordon> hmm
<Wizzup> but that's likely a separate problem
<uvos> i think you can reboot the modem via the at interface
<uvos> maybe tmlind remembers
<uvos> that might simulate a system reboot (if you also restart ofono)
<Wizzup> I suppose you can unload and reload the kernel module
<uvos> i dont know if that reboots the modem
<Wizzup> it definitely powers it, not sure about unload
<freemangordon> which module?
<uvos> motorolamodem
<freemangordon> Wizzup: I see no issues here doing offline<->online
<freemangordon> but sim has no pin
<Wizzup> maybe it's powered false/true
<freemangordon> ok
* freemangordon tries
<Wizzup> let me try now
<uvos> i dont think powerd fals true dose anything
<uvos> at least it dosent change power consumption
<Wizzup> well it makes it abort iirc
<uvos> (which cfun dose)
<uvos> sure but i mean in terms of affecting the modem firmware
<freemangordon> not here (abort)
<Wizzup> root@maindroid:~# mdbus2 -s org.ofono /motmdm_0 org.ofono.Modem.SetProperty Powered false
<Wizzup> ^R
<Wizzup> [ERR]: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
<Wizzup> root@maindroid:~# mdbus2 -s org.ofono /motmdm_0 org.ofono.Modem.SetProperty Powered false
<Wizzup> [ERR]: There is no method with name org.ofono.Modem.SetProperty on path /motmdm_0!
<Wizzup> this -might- be expected, perhaps
<freemangordon> well, I am using ofono scripts
<Wizzup> no, ofono is gone
<freemangordon> enable-modem and disable-modem
<Wizzup> fyi there is /var/log/maemo/ofonod.log
<freemangordon> but they do the same IIUC
<Wizzup> you can check if they set powered?
<freemangordon> lemme check
<Wizzup> Aug 25 11:30:16 localhost ofonod[2878]: Aborting (signal 11) [/usr/sbin/ofonod]
<freemangordon> Wizzup: you mean the scripts?
<freemangordon> modem.SetProperty("Powered", dbus.Boolean(0), timeout = 120)
<Wizzup> I don't use the scripts, but I doubt it makes a difference, it's just dbus
<freemangordon> this is disable-modem
<freemangordon> ok, lemme set pin to that card
<Wizzup> I doubt the pin matters to the abort
<Wizzup> but yeah, ok
<freemangordon> it does not abort here
<freemangordon> maybe different initial state?
<freemangordon> like modem is opnline?
<freemangordon> *online
<freemangordon> or, could you attach gdb and provide backtrace? that might give me a clue how to repro
<Wizzup> the modem is online yeah
<freemangordon> nope. makes no difference
<Wizzup> it took two tries for me just now
<freemangordon> well, lemme put sim with pin
<Wizzup> (see backtrace above btw)
<Wizzup> looks like it might get RSSI after the modem is off or something silly
<Wizzup> could relate to our mce mapphone module
<uvos> well mce only disables rssi
<freemangordon> no matter what, it should not segfault
<Wizzup> sure
<uvos> it segfaults here to
<uvos> doing this btw
<uvos> i gues it might be because disable-modem dosent do anything really
<freemangordon> it does
<uvos> you can still talk to the modem via qmicli
<freemangordon> sets powerd ot off
<uvos> right
<uvos> but the modem dosent care
<uvos> if you connect gsm via qmicli "powering it off" via ofono dosent even dissconnect the connection
<Wizzup> so debugging wise there's etting n_gsm.debug to 0xff
<Wizzup> and there's the ofono logs that can be made very verbose
<freemangordon> ok, but I want to repro first
<uvos> i had to power the modem, online it, enter pin and have it be connected to an operator
<uvos> before the segfault via off
<Wizzup> yeah and there's the rssi msg in my backtrace
<Wizzup> so maybe it relates to locking the device too
<Wizzup> (which I do often)
<uvos> i can do the whole seqence with out ever locking the device
<uvos> so mce should not have issued any modem commands at all in that timespan
<freemangordon> uvos: does it happen wwith sim without pin?
<uvos> no idea
<freemangordon> ok, seems ofono does not detect hot-pluggin a card with pin
<Wizzup> not even sure if the modem does
<uvos> in android it dose
<Wizzup> if you remove the '#' you'll see all modem msgs /etc/modprobe.d/gps.conf:#options n_gsm debug=0xff
<uvos> takse a couple of second or so tho
<uvos> so maybe its just becuase android querys something and kicks the modem
<freemangordon> I have no /etc/modprobe.d/gps.conf
<Wizzup> freemangordon: sure, make it :)
<Wizzup> for the record:
<Wizzup> # cat /etc/modprobe.d/gps.conf
<Wizzup> #options n_gsm debug=0xff
<Wizzup> options gnss_motmdm rate_ms=1000
<freemangordon> your statement (uncomment line...) implied I shoud already have one :)
<uvos> Wizzup: how manny seconds should the sphone window stay (after call)
<uvos> 5s?
<Wizzup> freemangordon: sry
<Wizzup> uvos: yeah that's a start I think
<freemangordon> why it should auto-close at all?
<uvos> id prefer it to auto-close eventually
<freemangordon> ok, but why?
<uvos> so i dont have to do anything when remote hangs up
<freemangordon> at least make that an option
<freemangordon> it is like if conversation closes 5s after last message
<freemangordon> or if the remote party goes offline
<uvos> i mean a call is totaly different
<uvos> your unlikely to immidatly call a person you just called again
<freemangordon> it is not, but lets not go into that :)
<uvos> besides you cant even do that with this window
<freemangordon> yous, you should be presented with last calls window ;)
<uvos> (where talking about the window that shows the mute and hangup buttons here)
<freemangordon> this is how every dialer around works
<uvos> it looses validity immidatly when your not in a call
<freemangordon> yes, and you shoudl be presented with last calls
<freemangordon> anyway
<uvos> im not sure what dialer works like this
<uvos> maybe the fremantle one
<freemangordon> yes
<freemangordon> when GF is back, I will check what andoid one does
<Wizzup> fremantle will close itself if it's not open and you got called
<freemangordon> sure?
<Wizzup> otherwise it will stay open at the window is just a stacked window
<freemangordon> ok
<Wizzup> freemangordon: the dial window specifically yes
<Wizzup> err not dial
<Wizzup> but the call window
<freemangordon> yeah "in-call"
<freemangordon> ok
<uvos> same with android
<uvos> it kicks you back to the last window
<uvos> (either contacts or the dialer or nothing)
<freemangordon> ok
<uvos> so the only thing sphone dose different is that the dialer closes
<uvos> (also the delay is missing, android has a delay to)
<uvos> so you can look at the call time presumably
<freemangordon> mhm
<uvos> anyhow delay is now 5 sec
<uvos> we can also not close the dailer
<uvos> if you like
<uvos> Wizzup: ?
<freemangordon> all dialeres around do it, so I think it makses sense
<freemangordon> a typo day?
<uvos> wat si tpo?
<Wizzup> uvos: I think if the window is not open, and you get called, then no window ought to remain
<Wizzup> (after 5s)
<uvos> right
<Wizzup> if it's open, I'd keep it open
<uvos> ok
<uvos> rn it closes as soon as you press call
<Wizzup> so ideally it would stack :)
<freemangordon> typo? umm... when you type something wrongly, that's a typo
<Wizzup> freemangordon: I think it was a joke
<freemangordon> ah
<freemangordon> I didn;t even see how it was typed :D
<freemangordon> I am so used to how uvos type here :p
<Wizzup> idk most of it is typo free
<freemangordon> anyway, it seems n_gsm report at least SIM removal
<Wizzup> right
<Wizzup> it might take a bit to report sim insertion maybe?
<freemangordon> lemme put back
<uvos> bren si realy god at dicodeig
<uvos> ok ill remove the close
<uvos> but this makes the call button have very little feedback
<freemangordon> yep, insertion is reported too
<uvos> any ideas on feedback?
<freemangordon> yep, ofono issue, deffinitely
<freemangordon> will do some work work and will se what I can do about it
<uvos> its good that its not the modem fw
<freemangordon> mhm
<Wizzup> uvos: if you close the call yourself it can hang up sooner
<Wizzup> s/hang up/close/
<uvos> sure that fixes the feedback on the hangup button
<uvos> but not the call button
<uvos> when you press call, nothing happens for a while
<uvos> as ofono needs to be contacted and then sphone has to spawn a new window
<uvos> hildon also needs to rotate, takes about 1.5 seconds or so
<uvos> all in
<Wizzup> sometimes the button hangs for 30s because of ofono timeouts :P
<freemangordon> Wizzup: hmm, which ofono branch to use?
<freemangordon> beowulf-devel?
<Wizzup> let me look
<Wizzup> maemo-ofono should be ok
<freemangordon> ok
<freemangordon> ok, but why is that not in -devel?
<Wizzup> I think it is
<freemangordon> maybe that's the reason why it does not segfault her
<freemangordon> *here
<Wizzup> we have same ofono everywhere
<Wizzup> maybe you're looking at a different repo?
<freemangordon> url = git@github.com:maemo-leste-upstream-forks/ofono.git
<Wizzup> ii ofono 1:1.34.0-1+2m7.1 armhf Mobile telephony stack (daemon)
<Wizzup> ofono (1:1.34.0-1) unstable; urgency=medium
<Wizzup> looks like the right version to me
<Wizzup> what version do you have?
<freemangordon> 1:1.34.0-1+2m7.1
<Wizzup> so I think you have the same version as maemo-ofono as maemo/beowulf-devel
<freemangordon> but, git diff shows differences between beowulf-devel and maemo-ofono branches
<freemangordon> unless I am doing something wrong
<Wizzup> your beowulf-devel or origin/beowulf-devel
<freemangordon> umm...
<freemangordon> oh :)
<Wizzup> $ git diff --stat origin/maemo/beowulf-devel..origin/maemo-ofono | wc 0 0 0
<freemangordon> yeah, it is better now
<Wizzup> :)
<freemangordon> there is beowulf-devel branch I think we shall delete
<freemangordon> but anyway
<Wizzup> ah yeah
<Wizzup> heh
<freemangordon> may I delete that?
<Wizzup> sure
norayr has quit [Ping timeout: 260 seconds]
<buZz> heh, never noticed that rightclicking actually works on touch? at least in chromium
<buZz> just holding touchscreen
<uvos> some apps implement this
<uvos> firefox to
<uvos> but its not a universal thing
<freemangordon> uvos: can I send AT commends to the modem?
<freemangordon> somehow
<uvos> freemangordon: well
<uvos> freemangordon: sorta
<uvos> freemangordon: so the modem dosent really have a at interface
<uvos> freemangordon: it has a interface that uses commands that start with at :P
<freemangordon> ah
<uvos> (its really quirky)
<uvos> its on one of the usb ttys
<uvos> sec
<freemangordon> do we have it documented somewhere?
<freemangordon> (commands set)
<uvos> no
<uvos> we dont know what it supports
<freemangordon> as I have the feeling that unsolicited messages shall be enabled
<uvos> besides messing with android
<uvos> and seeing what it sends
<freemangordon> do we have a log somewhere?
<uvos> its very customized by motorola
<freemangordon> ok
<freemangordon> but do we have a log from android boot and communication with the modem
<uvos> somewhere yeah
<uvos> yeah
<uvos> anyhow its on /dev/gsmtty1
<uvos> mostly the modem wants you to controll it via qmi
<uvos> really
<uvos> realy pali probubly knows best
<uvos> he wrote a hacked version of ofono that uses the at interface to do sms and calls
<uvos> it never worked very well
<uvos> but he probubly knows which at commands work and in how far they dfo
<uvos> or maybe it was pavel
<uvos> i dont quite remember
<freemangordon> pavel
<freemangordon> hmm, AT+QSIMDET
<freemangordon> uvos: anyway, do you have that andoid log around to share?
<uvos> freemangordon: im looking for it
<freemangordon> ok
<uvos> i found this
<uvos> stringed from some android libarary iirc
<uvos> libmoto*ril.so
<uvos> if you want to re something
<uvos> no debug symbols tho
<uvos> so good luck :P
<freemangordon> thanks
l_bratch has quit [Quit: Leaving]
<Wizzup> probably not needed though?
<freemangordon> hmm, AT+UNSOL
<freemangordon> uvos: so, how to send command while ofono is running?
<uvos> printf 'U1234AT+UNSOL=1\r' > /dev/gsmtty1
<uvos> U1234+UNSOL:OK
<uvos> works fine here
<freemangordon> ok
<uvos> new sphone is on the way btw
<uvos> @Wizzup
<uvos> besides the other things the missed calls from the distant past are also fixed
<freemangordon> hmm, not good
<freemangordon> either FW or kernel issue
<freemangordon> (missing sim events)
<Wizzup> uvos: thx
<Wizzup> freemangordon: hm, maybe that is why we don't see it on bionic
<freemangordon> could you capture dmesg log when removing SIM (with n_gsm debug=0xff)
norayr has joined #maemo-leste
<Wizzup> I've never tried this
<Wizzup> I can try
<Wizzup> (later today)
<freemangordon> ok
<freemangordon> tmlind: do you have some android boot log with modem commands tracing?
xmn has joined #maemo-leste
<tmlind> freemangordon: i recall you can trace them with logcat if using lineageos kernel
<freemangordon> do I need serial attached?
<tmlind> freemangordon: no, adb is enough
<freemangordon> ok, but isn't it too late?
<tmlind> freemangordon: you also want to probably enable ts27010 debug if looking at the modem commands
<tmlind> freemangordon: pretty sure logcat shows you the boot time messages too
<freemangordon> ok, now I have to dig what is ts27010 and how to enable debug :)
<freemangordon> tmlind: does current mainline modem driver use apwake gpio?
<tmlind> let me try to find my notes
<tmlind> freemangordon: adb shell 'echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level'
<tmlind> that allows you to see the ts27010 serial mux packets to the modem
<freemangordon> ok, but my concern is that maybe no irq is used from BP->AP
<tmlind> freemangordon: not sure if we use the apwake gpio.. the gpios are in the dts file
<freemangordon> perhaps that's why we need to send something in order to receive unsol events
* freemangordon checks gpio number in android kernel
<tmlind> yeah maybe
<tmlind> see also what phy-cpcap-usb.c is already doing, maybe it already handles it
<tmlind> no sorry, wrong phy driver.. the mdm6600 phy driver
<freemangordon> ok
<tmlind> phy-mapphone-mdm6600.c
<freemangordon> ok
<tmlind> freemangordon: some mdm6600 gpios need to be remuxed to input after initial bootup to use them
<freemangordon> yep, I see the comments in phy driver
<freemangordon> but I have to figure out what exactly gpio is needed
<tmlind> maybe apwake remuxed to input after boot if not done already?
<tmlind> that should be gpio_149
<freemangordon> mdm6600-wake does not increase on SIM insert/remove
<tmlind> i see /* Reconfigure mode1 GPIO as input for OOB wake */ so modem should already be waking up the soc
<freemangordon> p, li { white-space: pre-wrap; } /* Reconfigure mode1 GPIO as input for OOB wake */
<freemangordon> yep
<freemangordon> that's exactly "mdm6600-wake"
<freemangordon> what is "mode1"?
<tmlind> it could be there's some handler missing in ofono and the message comes from uart just fine
<tmlind> mode pins tell what usb mode to boot it to i think
<freemangordon> I see nothing in n_gsm traces
<freemangordon> (re missing handler)
<freemangordon> shall I write a simple test program that opens /dev/gsmtty1 and reads?
<tmlind> ok then maybe sim insert does not trigger anything? it takes really long time with android too to see the sim sometimes
<freemangordon> ok, but sim remove?
<tmlind> don't remember if that produces anything
<freemangordon> in android?
<freemangordon> hmm
<tmlind> if you modprobe n_gsm debug=0xff, then you should see the raw packets in dmesg
<freemangordon> that's why I did
<tmlind> so probably no need to read /dev/gsmtty1
<freemangordon> nothing comes
<freemangordon> unless you "kick" it by sending some command
<tmlind> weird
<freemangordon> hmm, wait
<freemangordon> see the note before phy_mdm6600_wakeirq_thread
<freemangordon> "Just use it for debug info only..."
<tmlind> yeah maybe that triggers and means check status
<freemangordon> mhm
<freemangordon> looks like
<tmlind> oh so you see it trigger when inserting a sim then?
<freemangordon> no, because it is dev_dbg
<freemangordon> I am trying to find how to see dev_dbg messages
<tmlind> #define DEBUG at the top, set loglevel to 8 or smaller i think
<tmlind> or just change dev_dbg to dev_info temporarily..
<freemangordon> what about "echo 'file phy-mapphone-mdm6600.c +p'>/sys/kernel/debug/dynamic_debug/control"?
<tmlind> yeah that might work
<freemangordon> ugh, no dynamic_debug it seems :(
<tmlind> ok
<freemangordon> but I see irqs increasing
<tmlind> i need to go deal with feeding, let's hope the oob gpio works :) bbl
<freemangordon> :)
<freemangordon> hmm, seems inserting seems gets registered by ofono
<freemangordon> it just takes lots of time
<freemangordon> or, it could be because I enabled unsol messages
* freemangordon checks
ikmaak2 has joined #maemo-leste
ikmaak has quit [Ping timeout: 252 seconds]
ikmaak2 is now known as ikmaak
* tmlind waiting for a pizza
* uvos intercepts pizza
<freemangordon> tmlind: do you know, where in ofono I shall send 'U1234AT+UNSOL=1' command?
<freemangordon> it seems this has to be send after every unsol even in order to receive the next one
<tmlind> no idea, seems it needs a new handler in ofono
<freemangordon> umm, why handler?
<freemangordon> the handler is there
<freemangordon> I just need to send that command when tty is opened
<tmlind> but something needs to parse the unsol message, then kick the usb interface
<freemangordon> the parser is already there
<tmlind> ah
<tmlind> ok then acking it is needed sounds like
<freemangordon> see receive_notify in sim.c
<freemangordon> but, I think before receiving the first notify, the ^^^ commend shall be send
<freemangordon> to enable unsol events
<freemangordon> hmm, maybe you are right and this is ACK, lemme try
<tmlind> afc, only on d4 right now, can't grep
<freemangordon> ok
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
<tmlind> fyi to avoid implementing full modem support over serial at commands, we just kick the usb interface and let the existing code handle things..
<freemangordon> umm... I am not sure I understand
<tmlind> ofono has good qmi support over usb
<freemangordon> ok
<tmlind> bbl
<freemangordon> lets first see that what I think is needed works
mardy_2nd has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
Livio has quit [Ping timeout: 268 seconds]
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
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
mardy_2nd has quit [Quit: WeeChat 3.5]
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
<freemangordon> ok, it seems AT+UNSOL=1 shall be send only once
<freemangordon> ugh, why it needs 5 minut6es to report sim present?
<freemangordon> hmm, not, this command must be send every time
<Wizzup> freemangordon: modem startup time maybe
<freemangordon> no
<freemangordon> 10 minutes after boot
<freemangordon> if there is no AT+UNSOL=1, SIM insertion is not reported
<Wizzup> not sure how that works
<Wizzup> do you have a bionic as well?
<freemangordon> if there is, it is reported maybe a minute after it is inserted
<freemangordon> no
<Wizzup> uvos suggested we could try older or newer fw
<freemangordon> lemme first see if I can make it work properly on d4
<Wizzup> :)
<freemangordon> I just have to find the proper place to put it
<freemangordon> (command)
<freemangordon> and I am sure it will work
<freemangordon> well, sure(tm) :)
Livio has quit [Ping timeout: 260 seconds]
<Wizzup> :)
<freemangordon> ugh, callback in ofono was not called :(
<freemangordon> oh, PEBCAK
<tmlind> freemangordon: so are you seeing AT+UNSOL=1 do anything?
<freemangordon> still hard to say
<tmlind> heh
<freemangordon> yeah, seems ofono has bug so callback does not get called when sim insert is reported
<freemangordon> investigation ATM
<tmlind> usually if the modem has something it produces several WAKEUP on the dlci1
<tmlind> freemangordon: maybe enable status notifications on dlci1 with AT+SCRN=1, then insert sim and see you that produces any new messages?
<tmlind> most likely it will just enable network status notfications though
<freemangordon> lemme first fix ofono bug
<tmlind> oh ok
<freemangordon> tmlind: hmm, why g_at_chat_register() in sim.c is called with expect_pdu set to true?
<tmlind> just a sec.. hmm maybe the sim detection i added only works with bionic firmware? there's a difference in the line break characters between bionic and d4..
<tmlind> forgot the details on the expect_pdu, may be related to the different line breaks too
<tmlind> or could be bug :)
<Wizzup> it works in bionic I can confirm
<tmlind> oh ok, might be the line break issue then
<tmlind> freemangordon: hmm maybe i used the pdu to strip out the moto U1234 packet id's
<tmlind> some more info on the varying line breaks in "gatsyntax: Allow '\n' to terminate line"
<tmlind> if d4 produces ~+MSIM= but ofono is not parsing it and bionic is, chances are it's somehow related to the packet line breaks
<tmlind> hmm or i guess d4 may produce ~+MSIM on a different dlci rather than /dev/gsmtty10 on bionic, seems unlikely though
<Wizzup> Does n_gsm debug where the command goes?
<freemangordon> no, it is there
<freemangordon> tmlind: ^^^
<freemangordon> maybe ofono cannot parse the pdu
<freemangordon> pasring results in G_AT_SYNTAX_RESULT_LINE:
Twig has quit [Ping timeout: 260 seconds]
<freemangordon> not G_AT_SYNTAX_RESULT_PDU
<tmlind> ok
<tmlind> btw, i've noticed that doing ifdown wlan0 can hang the device at some point
<freemangordon> I guess a0000000871002ff47f00189000001ff is the PDU in question?
<tmlind> not sure
<tmlind> ok yeah so the notification is there, and ofono can't parse it somehow
<freemangordon> mhm
<freemangordon> on card remove:
<freemangordon> U0003~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.
<freemangordon> this is parsed correctly
<tmlind> the pdu is the raw packet, but if there's no U1234 in the beginning, then pdu parsing will fail
<freemangordon> why 1234?
<tmlind> oh but the packet id is there, U0004 in your pastebin, never mind
<freemangordon> U0004~+MSIM=1,0,a0000000871002ff47f00189000001ff,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.
<freemangordon> on connect
<tmlind> ok
<freemangordon> hmm, unplug has one more 'parameter' at the end
<freemangordon> U0003~+MSIM=0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.
<freemangordon> U0004~+MSIM=1,0,a0000000871002ff47f00189000001ff,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.
<tmlind> maybe try reverting or tweaking "gatsyntax: Allow '\n' to terminate line" and see if that helps on d4?
<freemangordon> ok
<tmlind> freemangordon: actually rather try reverting "gatsyntax: Allow terminating a PDU with a new line" on d4 and see if that helps
<tmlind> probably the reason for using pdu parsing rather than line parsing was the varying line breaks..
<freemangordon> ugh
<freemangordon> "~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n"
<freemangordon> there are 2 line feeds
<freemangordon> why do we need "gatsyntax: Allow terminating a PDU with a new line"?
<freemangordon> tmlind: I see this is your commit, where did you see the issue it fixes?
Twig has joined #maemo-leste
<freemangordon> ok, I am confused
<freemangordon> in dmesg there is only one 0x0a
<freemangordon> tmlind: is it possible that tty add new lines becasue of some "terminal line size" or something?
<freemangordon> *adds
<freemangordon> ~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 len is 87
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<freemangordon> ok, terminal seems to be opened in raw mode
<freemangordon> so, where that additional line feed comes from?!?
Livio has quit [Ping timeout: 244 seconds]
<freemangordon> oh, I see why
<freemangordon> data comes from the modem on 2 packets
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
norayr has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
<tmlind> ok, yeah different on d4 and bionic
<freemangordon> hmm, how to connect adb?
<freemangordon> I already enabled "developer options" or whatever
<tmlind> enable usb debugging too?
<freemangordon> yeah
<freemangordon> tmlind: there is no /sys/module/ts27010mux/parameters/debug_level
<freemangordon> ugh
<freemangordon> I had to connect as root
<tmlind> it's only there on lineageos kernels, not with the stock kernel
<tmlind> not enabled in .config for the stock kernel i believe
<freemangordon> I am on lineageos
<tmlind> hmm weird
<freemangordon> I was not connecting as root
<freemangordon> as root, it is there
<tmlind> oh ok
<freemangordon> is there such thing as modprobe.d on android?
<tmlind> so for the ofono serial read/write, the long term solution is to stop using gatchat and instead use ell to parse the raw packet data
<tmlind> uvos might know how to enable loading modules
<freemangordon> tmlind: well, I see no '\r' at the end of the string
<tmlind> heh annoying
<freemangordon> and I think this is th eissue
Twig has quit [Ping timeout: 260 seconds]
<freemangordon> tmlind: I want to set ts27010mux parameter early in the boot process
<tmlind> kernel cmdline?
<freemangordon> if I only know how to modify it :)
<tmlind> you can tweak that in droid4-kexecboot boot.cfg i think
<freemangordon> like, this is some weird bootloader here
<freemangordon> where is that? any idea?
<freemangordon> mmcblk1p13?
<tmlind> so droid4-kexecboot has an option to boot to stock android distro
<freemangordon> this is what I use
<freemangordon> and it boots to lineageos
<tmlind> if you edit that boot.cfg file, it just does pivot root to the stock
<freemangordon> but, where is that boot.cfg located?
<tmlind> hmm where do you have lineageos installed/
<tmlind> ?
<freemangordon> that's how I got the device :)
<freemangordon> I guess Wizzup installed it for me
<tmlind> ok
<tmlind> so which boot option did you select for android in the bootloader menu? the "boot to stock android" one?
<freemangordon> yes
<tmlind> so mount the boot partition from android, and edit the boot.cfg file for that menu entry and you should be able to tweak the cmdline
<tmlind> mount the bootloader partition i mean
<freemangordon> which one is that?
<freemangordon> /dev/mmcblk1p14 ?
<freemangordon> this is marked as boot
joerg has quit [Excess Flood]
<tmlind> /dev/mmcblk1p13
<tmlind> but looking at /boot/boot.cfg the cmdline is just "stock", so it's in the boot script instead
<freemangordon> mount /dev/block/mmcblk1p13 /mnt/boot
<freemangordon> mount: '/dev/block/mmcblk1p13'->'/mnt/boot': Operation not supported on transport endpoint
<freemangordon> :(
<tmlind> oh and looking at sbin/preinit.sh, it just does pivot_root so no way to tweak the cmdline
joerg has joined #maemo-leste
<freemangordon> hmm, wait
<freemangordon> flight mode shall do the trick
<tmlind> yeah for modem communication
<tmlind> and you could tweak mmcblk1p13 sbin/preinit.sh to enable debug before the pivot_root
xmn_ has joined #maemo-leste
xmn has quit [Ping timeout: 252 seconds]
<tmlind> or you could add a lineageos kexec menu to the boot.cfg on your micro-sd card with a custom cmdline
<tmlind> hmm actually i forgot if kernel cmdline even works properly with the android stuff..
<freemangordon> I cannot mount mmcblk1p13
<freemangordon> from android that is
<tmlind> ok
<tmlind> you can mount it from m-l kernel though :p
<freemangordon> well, yeah :)
<tmlind> or check your micro-sd partitions for boot/boot.cfg file and yeah you can tweak the cmdline there
<tmlind> multiple boot.cfg file are ok with kexecboot
<tmlind> but if there's no lineage os kexec entry configured, don't bother wasting time with that
<freemangordon> ok
<freemangordon> tmlind: still, do you have any clue where that additional '\n' comes from?
<freemangordon> for sure the modem does not send it
<freemangordon> but it gets read from the tty
<freemangordon> and this additional \n breaks it
<freemangordon> hmm, it seems android pings the modem every 3 seconds
<freemangordon> 0416~+RSSI=0,22,99,99,0,0,0
<freemangordon> etc
<tmlind> that's with U1234AT+SCRN=1 set for status notifications
<freemangordon> ah
<tmlind> i thought the extra \n comes from d4 firmware?
<freemangordon> anyway, I don;t see "UNSOL" commend used
<freemangordon> no
<freemangordon> it sends \n at the end
<tmlind> maybe it's a \r in the middle?
<freemangordon> but, there is one more \n that comes from somewhere else
<freemangordon> no, it is \n
<tmlind> is it not in the n_gsm debug=0xff packet dump?
<freemangordon> it is not
<tmlind> weird
<tmlind> you sure?
<freemangordon> see https://pastebin.com/xVgthPBJ
<freemangordon> there is only one 0a
<freemangordon> and this is printed by gdb:
<freemangordon> "~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n"
<tmlind> not sure why the firmware sends it in multiple pieces, but it's packet data with a size and checksum so should not matter from ts27010 point of view
<freemangordon> you mean from n_gsm POV guess
<freemangordon> right, and it seems to process it correctly
<tmlind> yeah
<tmlind> so does ofono see the middle \n there too?
<freemangordon> only ofono sees it
<freemangordon> and that's why it fails to parese
<freemangordon> *parse
<tmlind> hmm
<freemangordon> hmm ONOCR
<tmlind> so doing ngsm 10 AT+MSIM? shows the sim with no line break in the middle
<freemangordon> cfmakeraw does not set that flag
<tmlind> where 10 is dlci10
<freemangordon> so it seems tty outputs \n at col 0 for some reason
<tmlind> so also with ngsm 10 AT+MSIM? the dmesg shows the data returned in two pieces
<tmlind> ngsm is my script for doing the commands fyi that adds the U1234
<freemangordon> tmlind: lemme try to set ONOCR
<tmlind> if ngsm 10 AT+MSIM? returns sim data to the terminal with no line break, why would ofono see the line break?
<tmlind> the line break in the middle i mean
<freemangordon> where is ngsm script?
<tmlind> my ngsm script is just:
<tmlind> timeout 3 /bin/cat /dev/gsmtty${1} &
<tmlind> busybox usleep 100000
<tmlind> printf "U%04i%s\r" $(date +%M%S) ${2} > /dev/gsmtty${1}
<tmlind> first param is the dlci number, second is the AT command without the U1234
<freemangordon> yes, it sees it correctly
<freemangordon> so no idea what's going on with ofono
<tmlind> well ofono reads also dlci10, i suspect the middle \n is only in the dmesg
<freemangordon> there is no \n in dmesg
<freemangordon> 'middle \n' that is
<freemangordon> it is only int the ofono vars
<tmlind> weird
<freemangordon> mhm
<tmlind> added by gatchat based on some timeout?
<freemangordon> I was not able to find any place where '\n' is appended or set
<freemangordon> lemme attach gdb again
<tmlind> gdb on ofono?
<freemangordon> mhm
<tmlind> ok
<freemangordon> see https://pastebin.com/4X79tuXs
<freemangordon> this is ...
<freemangordon> ridiculous
<freemangordon> received_data is a callback to g_io_add_watch_full
<tmlind> not sure if the ngsm packet in two pieces can even be decoded properly until both pieces have arrived :)
<freemangordon> the packet is there, it is just that there is some additional \n in the middle
<freemangordon> "U0003~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n",
<tmlind> maybe it's some n_gsm.c bug
<freemangordon> this is the whole packet
<freemangordon> could be, but how to track
<tmlind> and why would the ngsm script not see it?
<freemangordon> mhm
<freemangordon> I think it is some termio thing
<tmlind> sometimes the ngsm 10 AT+MSIM? data comes back in three pieces looking at dmesg
<freemangordon> yes, but it seems n_gsm manages to gather it
<freemangordon> or not?
<tmlind> yeah output from the script is just fine as is the whole packet in dmesg after the pieces
<freemangordon> mhm
<tmlind> could it be some uncleared buffer in ofono?
<freemangordon> could be
<freemangordon> lemme try to find
<tmlind> also check in your dmesg the parsed packet after "<-- 10) C: UIH(F)" is fine when ofono has a problem
<freemangordon> alredy did
<freemangordon> *already
<freemangordon> it is fine
<tmlind> ok, so is the ofono extra \n always in the same place?
<freemangordon> not sure
<freemangordon> still debugging
<tmlind> to me it seems the parsed packet from kernel should be ok with no extra \n in between, well should
<tmlind> maybe it somehow depends on the read size?
<tmlind> fixed line lenght in ofono? :)
<tmlind> wrapt to 80 chars? :)
<tmlind> 92 chars?
<freemangordon> ok, it gets correct data from g_io_channel_read_chars
<freemangordon> lemme continue debugging
<tmlind> hmm we skip past the first five chars in the pdu to ignore the U1234, maybe the math goes wrong there for the buffer size
<freemangordon> what the? this time it is ok
<tmlind> weird
<tmlind> maybe i introduced a hard to find bug with the p->hdrlen changes
<freemangordon> maybe it it gets read in chunks
<freemangordon> or rather - the bug appears when data is read in chunks
<freemangordon> and someone appends '\n'
<tmlind> a good reason to replace gatchat with raw read and write functions using ell
<tmlind> maybe the change i did for at_chat_handle_command_response() fails to find anything if read in chunks
<freemangordon> will see
<tmlind> resp = strstr(line, p->delimiter);
<tmlind> won't find the delimter and gatchat goes doing what it does
<freemangordon> why response?
<freemangordon> this is unsolicited message
<tmlind> hmm
<freemangordon> hmm, modem does not report events anymore, rebooting
<tmlind> not sure but probably gatchat is parsing all the data coming from the line, it's been a while
<freemangordon> btw, it seems qmimodem received sim insertion notificationm
<tmlind> ok, zzz time here, ttyl
<freemangordon> gn
mardy has quit [Quit: WeeChat 2.8]
<Wizzup> btw, lenovo has an arm thinkpad laptop now
<Wizzup> seems kinda nice, without fans
<Wizzup> mostly random remark but yeah it's kinda cool
Langoor_ has quit [Ping timeout: 240 seconds]
l_bratch has joined #maemo-leste
<uvos> is it tho? arm devices are still a clusterf**k compeard to x86 based ones no?
<uvos> wrt standarization allowing a common kernel to work.
<uvos> at least its sill that way with cromebooks
<uvos> is this different?
xes_ has joined #maemo-leste
<Wizzup> uvos: seems like 5.20 supports it
<Wizzup> not sure about everything
<Wizzup> but could potentially be a nice build machine too
Pali has quit [Ping timeout: 260 seconds]
xes_ has quit [Quit: WeeChat 3.5]
tk has quit [Ping timeout: 244 seconds]
isabelle_ has joined #maemo-leste
crab_ has joined #maemo-leste
elastic_dog has quit [*.net *.split]
crab has quit [*.net *.split]
isabelle has quit [*.net *.split]
elastic_dog has joined #maemo-leste
isabelle_ is now known as isabelle
uvos has quit [Ping timeout: 252 seconds]
tk has joined #maemo-leste
Livio has quit [Ping timeout: 252 seconds]
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
Langoor has joined #maemo-leste