PPP does not fully respond to calls while in suspend.

[henrythemouse]

Using an uptodate Mobian on a pinephonepro.

Just wondered if my ppp would answer a call if it was in suspend. While it does respond to a call it doesn't fully respond. I wakes up to the lock screen. The work around I use is to avoid suspend if I want to receive calls. In my case I leave the phone plugged in and power settings set to disable suspend when 'plugged in'. Which is likely not good for the battery. If anyone has a fix or workaround for this I'd appreciate it if you'd pass it on.

The steps I used to reproduce the results:

TEST SUSPEND
    1) set to suspend at 5 minutes
    2) got sound dialing vm
        wait for 7 minutes for ppp to suspend
    3) use power button to wake from suspend
        got sound dialing vm
       I call the phone, it rings and has voice
    4) wait for 7 minutes for ppp to suspend
    5) I call the phone, phone doesn't ring,
        it wakes to lock screen 
        phone does go to voice mail
        I close the call
    6) open phosh (closing lock screen)
    7) call phone, calls app opens, phone rings
        got sound

The logs are taken right after the call attempt woke up the lock screen (via ssh) [Link removed]

[Biktorgj]

Beware with logs as they might have personal information!

Both the Modem and ModemManager know about that second call that gets unanswered, it looks like gnome-calls doesn't get the message from ModemManager to show the UI. This didn't happen three weeks ago, so I guess something broke upstream somewhere...

If you leave gnome-calls open before suspending does the UI show?

[henrythemouse]

If you leave gnome-calls open before suspending does the UI show?

No, still the same response.

BTW, is there a way I can contact you privately?

[Biktorgj]

If you leave gnome-calls open before suspending does the UI show?

No, still the same response.

BTW, is there a way I can contact you privately?

Sure! Feel free to contact me in matrix (same nick :)), or get by the matrix room

[MungFuSensei]

openqti.log numbers censored dmesg-modem.log dmesg-pinephonepro.log

Pinephone-Pro, 0.6.5, sxmo/pmos. Calls work fine as long as the phone has not been suspended. When receiving calls from suspend, the only thing that happens is that the screen blinks on and off, modemmanager doesn't see the incoming call at all.

Furthermore, after suspend, I have to restart the modem and/or modemmanager for certain things to work, like dtmf tones when checking voicemail.

EDIT: Found this in a log regarding dtmf tones

2022/05/15 17:09:30 sxmo_hook_lisgd [DEBUG]: error: couldn't send dtmf to call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Connected: Cannot run sequence: 'Could not open serial device ttyUSB2: it has been forced close''

[Biktorgj]

@MungFuSensei I still don't have a functional PPP yet, hopefully it will arrive soon, but I can see what's happening there, not sure why though:

[   48.169333] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_SUSPEND_EVENT received

^^^ Here you suspended the phone. I can tell it's too soon because at the 48 second mark from boot eg25-manager can't possibly have pushed the AGPS data, so here we have the first problem. It shouldn't affect what comes next though. After the modem is started, eg25-manager sets a suspend inhibitor until it's done sending that data to the modem, but I think sxmo bypasses it and if you tell it to suspend it will still do it no matter what

[   62.476655] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_REMOTE_WAKEUP_EVENT received
[   62.480039] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_RESUME_EVENT received
[   62.483605] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_SUSPEND_EVENT received
[   62.484368] android_work: android_work: sent missed DISCONNECT event
[   62.491989] mdm_auxpcm_mode_put: mdm_auxpcm_mode = 1 ucontrol->value = 0
[   62.494785] mdm_sec_auxpcm_mode_put: mdm_sec_auxpcm_mode = 1 ucontrol->value = 0
[   62.559900] i2c-msm-v2 78b6000.i2c: error timeout on polling for valid state. check core_clk
[   62.564269] afe_open: port_id 0x100c rate 16000
[   62.572920] afe_open: port_id 0x100d rate 16000
[   62.937830] udc_irq: Interrupt: Reset
[   62.938069] isr_reset_handler: Reset interrupt... 
[   62.938177]  ... while suspended 
[   62.938372] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_RESUME_EVENT received
[   62.938725] diag: USB channel diag disconnected
[   62.971576] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_SUSPEND_EVENT received
[   62.971931] android_work: android_work: did not send uevent (0 0 00000000)
[   63.112524] udc_irq: Interrupt: Reset
[   63.112763] isr_reset_handler: Reset interrupt... 
[   63.112873]  ... while suspended 
[   63.113062] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_RESUME_EVENT received
[   63.113597] android_work: android_work: did not send uevent (0 0 00000000)
[   63.229075] udc_irq: Interrupt: Reset
[   63.229305] isr_reset_handler: Reset interrupt... 
[   63.229414]  ... while awake 
[   63.355689] android_usb gadget: high-speed config #1: 86000c8.android_usb
[   63.355971] diag: USB channel diag connected

Here it wakes up from suspend, resets the usb port (twice?) but, more important, fails to set up some register in the audio codec, as I can see 2c-msm-v2 78b6000.i2c: error timeout on polling for valid state. check core_clk. That's the point where you get no audio.

[  497.715897] mdm_auxpcm_mode_put: mdm_auxpcm_mode = 1 ucontrol->value = 0
[  497.718536] mdm_sec_auxpcm_mode_put: mdm_sec_auxpcm_mode = 1 ucontrol->value = 0
[  497.751234] afe_open: port_id 0x100c rate 16000
[  497.758832] afe_open: port_id 0x100d rate 16000

Here comes the second call, that apparently works as expected, or at least doesn't spit out any errors

I wonder...

If you repeatedly suspend the phone and call it, do you get that i2c error message on every call? Or just the first one then nothing works anymore? Instead of rebooting the modem, can you try rebooting only modemmanager? It's obvious from the message you posted that ModemManager sees the port vanishing, though if persist is set to 1 that shouldn't happen, but I remember that happening in arch (maybe it's something I should check when I get my PPP functional again)

[djselbeck]

If arch is using megi kernel it is because https://megous.com/git/linux/tree/drivers/usb/core/quirks.c?h=orange-pi-5.18-20220521-1759#n519 it prevents persist from working

You can workaround it by adding usbcore.quirks=2c7c:0125:e to kernel commandlinee

check later that cat /sys/bus/usb/devices/1-1/quirks is 0x0

[djselbeck]

Are calls signalled over the ttyUSB interfaces? If that is the case it might be because usb_wwan serial driver does not register a reset_resume function and the tty interfaces are not persisted.

[djselbeck]

I can confirm that

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index e60425bbf537..08fb844c534b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2176,6 +2176,7 @@ static struct usb_serial_driver option_1port_device = {
 #ifdef CONFIG_PM
        .suspend           = usb_wwan_suspend,
        .resume            = usb_wwan_resume,
+       .reset_resume            = usb_wwan_resume,
 #endif
 };

With this applied my PPP wakes up from suspend and signals the call

[whipplej5]

If arch is using megi kernel it is because https://megous.com/git/linux/tree/drivers/usb/core/quirks.c?h=orange-pi-5.18-20220521-1759#n519 it prevents persist from working

You can workaround it by adding usbcore.quirks=2c7c:0125:e to kernel commandlinee

check later that cat /sys/bus/usb/devices/1-1/quirks is 0x0

How do I add this to the kernel command line (pinephone Pro running arch)?

[Biktorgj]

I guess it will be probably similar to what you'd need to do in Mobian: Go to /etc/u-boot-menu.d/pinephonepro.conf, append the quirk to the command line parameters, and run u-boot-update afterwards to it recreates /boot/extlinux/extlinux.conf automatically

[CodePhase]

I have been having this problem for the longest time and decided to finally collect some logs. I enabled this quirk and rebooted the phone but it didn't help. I am running Mobian Phosh and have their latest 5.19 kernel installed that includes a few work arounds but the phone is still unable to receive calls from suspend.

dmesg-modem.txt dmesg-pinephone.txt eg25-manager.log modemmanager.log networkmanager.log openqti.log

I noticed when a call is received and the phone wakes up from suspend, the modem icon on the lock screen disappears and only comes back once the call is at or nearly at voicemail. A second call to the PPP works after the phone has woken up and the mobile network icon is back.

[Biktorgj]

Hi @CodePhase, you're hitting a ModemManager bug, it's been lingering for a few weeks but I have no idea if it has been yet fixed upstream.

From your log:

Aug 30 09:30:51 mobian systemd[1]: ModemManager.service: Main process exited, code=killed, status=11/SEGV
Aug 30 09:30:51 mobian systemd[1]: ModemManager.service: Failed with result 'signal'.
Aug 30 09:30:51 mobian systemd[1]: ModemManager.service: Consumed 1.088s CPU time.

ModemManager is dying on resume, that's why the icon disappears...

[CodePhase]

Thanks @Biktorgj it seems that maybe the bug is with glib >= 2.73.2 from this bug report: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/621. I'll be sure to keep an eye on it. I wonder if downgrading glib to 2.72 would work around this problem until a proper solution is implemented and distributed.

[CodePhase]

Ok, I've now installed the ModemManager fix package from Mobian that addresses https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/621. I now see that the cellular strength icon is present when the phone wakes when receiving a call but there is still no opportunity to answer the call since nothing is displayed and no missed call is logged.

I'm wondering if this is related to the eg25 bug https://gitlab.com/mobian1/eg25-manager/-/issues/15. Receiving a second call immediately after the first one fails works since I'm guessing everything is initialized by then. I tried that here and that should be evident in the log files:

dmesg-modem.txt dmesg-pinephone.txt eg25-manager.log modemmanager.log openqti.log

[via]

@CodePhase on mobian, the patch that @djselbeck provided above (adding the reset_resume callback) has been the key to a phone that wakes from suspend for me. The phone reliably wakes from suspend with it, and reliably does not without it.

[CodePhase]

@via looks like that patch just made it into Mobian with this merge request getting accepted and merged today: https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/merge_requests/28. Hopefully it'll be in the Mobian repos in a few days. Thanks for letting me know what the issue is!

[CodePhase]

FYI, I installed the newest kernel from the Mobian repos (5.19.11+rockchip-3) and I seem to now receive calls while the phone is in suspend so this issue looks to be resolved!

[neovalis]

it's working for me too!!!