Reliable incoming calls from crust

Make calls works reliably - e.g. ensure call can be picked up after coming out of crust and registers as missed call if not. Mostly working ATM.

Occasionally it breaks with mm reporting:

/dev/ttyUSB3 has been force closed

To be determined if the new 5.9.3 kernel fixes the above issue: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1678

Assigned to
1 year, 9 months ago
1 year, 6 months ago

~mil 1 year, 9 months ago

New 5.9.3 kernel doesn't solve the problem.

Replication steps:

  1. Toggle modem on (from config menu)
  2. Crust suspend
  3. Call the phone - pinephone comes out of suspend
  4. Pickup call from pinephone
  5. Hangup call from other phone

(Repeat 2-5, bug should start to appear in 2-3 runs).

~mil referenced this from #110 1 year, 8 months ago

~dodoeg 1 year, 8 months ago

I tested quite a lot recently to have reliable calls when waking up from crust, and I might have found a workaround for my Braveheart. I'm no expert with low level hardware details, so I might be incorrect on some things here below, but I'd like to see whether this is useful for others as well.

From the modem logs (read through adb shell to the modem), I think that the underlying problem to the modem disconnections, common to all the distro, is that the power provided to the modem is reduced briefly sometimes during the wakeup from crust. When this happens, the modem closes and reopens the usb connection. Apparently the host doesn't see that, and therefore the "force closed errors".

So, my initial thought was to unbind the usb connection to the modem before the sleep, in order to rebind it when exiting suspend. Doing this, whatever happens during the wakeup (i.e. whether the modem closes the connection or not), we should end up having a valid state after the wakeup. Unfortunately doing this sometimes the usb device disappears completely, and requires a modem poweroff and poweron to restore it. I'm not sure why this happens, but my wild guess is that it might be related to the host usb powersave.

So, next try was to unbind and rebind the usb device immediately when exiting from suspend. With this approach, I haven't missed a single test call in the last day. I always get the notification for the incoming call on the 3rd/4th ring. The 4g connection is also always restored properly. Also, this works in plain sxmo, without elogind, which means without ModemManager doing anything specific before/after suspend.

~dodoeg referenced this from #123 1 year, 8 months ago

~proycon 1 year, 8 months ago

Thanks for looking into this and testing it extensively. The suggested patch in https://lists.sr.ht/~mil/sxmo-devel/patches/15496 looks quite promising, I have applied it so it will make it into next release (which should be anytime now).


Maarten van Gompel (proycon) https://proycon.anaproy.nl

~proycon 1 year, 7 months ago

I think this is fixed now and can be closed right?

~reedwade 1 year, 7 months ago

It works for me yeah

~noneucat 1 year, 7 months ago*

I was having the issue of /dev/ttyUSB3 being dropped too today, but this patch seemed to break a couple of other things for me. I found that updating to the latest Crust (935017e) with a fairly recent version of u-boot (2020.07) seems to have resolved this problem, even without rebinding the USB interface. Worth a try IMO.

~noneucat 1 year, 7 months ago

Though, now I'm seeing the modem bind to ttyUSB4 and ttyUSB5 right after wakeup... so perhaps the rebind still makes sense.

~noneucat 1 year, 7 months ago*

I figured out why things were breaking haha :) On other distros, I found that incoming calls were being hung up when the usb reprobe happened. The reason why it was working fine on the sxmo image was because there is a pmOS-specific patch that patches this behavior out: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1736/diffs

~dodoeg 1 year, 7 months ago

I don't quite understand what you're saying here. Are you saying that with the latest crust you do not see modem disconnections on phone wake up anymore?

The hang up during probing is a different thing, and you would not see it anyway on sxmo, since it's not using systemd-elogind, and ModemManager is not doing any suspend/wakeup management.

~proycon referenced this from #159 1 year, 6 months ago

Register here or Log in to comment, or comment via email.