Re: EM7565 failing if host reboots whithout power cycling the modem
Aleksander Morgado writes: > Are we sure this is not an issue in the xhci driver itself? Maybe the > specific combination of modem and xhci controller triggers some corner > case that is not fully implemented correctly in xhci? > Last time I found something similar it took me 2 weeks of reading the > USB standard to come up with the fix > (45ba2154d12fc43b70312198ec47085f10be801a). Thanks for the pointer. Impressive detective work there. But you should know that I'm too lazy to do any hard work like that. > Did you report this at the LKML already? Maybe they have some hints on > how to best handle this. No, I haven't. You're right. This could very well be an issue with the xhci host driver. I was thinking that it might be related to the specific quirks for this old and rather rare controller. But it could very well be a generic issue too, which just doesn't show up with other implementations because theyr are more forgiving or whatever. I'll try linux-usb and Mathias next. Bjørn
Re: EM7565 failing if host reboots whithout power cycling the modem
Hey! On Sun, Mar 19, 2023 at 11:40 AM Bjørn Mork wrote: > > This is not an issue caused by ModemManager or any of the host drivers. > Nut I don't know where else to ask. And this documents the issue for my > next Google search :-) > Hahaha, been there. > I'm using a Sierra Wireless EM7565 connected to the USB3 port of a > Linksys WRT1900ACv1 "Mamba" (Marvell Armada 370/XP SoC), which has an > Etron EJ168 PCIe connected xhci controller. The system runs a recent > OpenWrt build (v5.15 kernel) with ModemManager. > > This works fine after the initial power-on or after physically > reconnecting the modem each time the host is rebooted. But it fails > consistently if I reboot the host without disconnecting the modem. > > The xhci driver will then log these messages while MM is probing the > modem: > > [ 78.014486] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.021419] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.028341] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.035270] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.043035] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.049973] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.056886] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.063808] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.070723] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.077633] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.084552] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.092256] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.099154] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 78.106082] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.007691] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.014629] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.021554] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.028474] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.035391] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.042306] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.049212] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.056669] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.063590] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.070504] xhci_hcd :01:00.0: WARN Successful completion on short TX > [ 81.077411] xhci_hcd :01:00.0: WARN Successful completion on short TX > > > and probing eventually fails. Likewise with any attempt to use mbimcli > etc. The /dev/cdc-wdm0 device appears dead. So I assume those warnings > are real errors, masked by the XHCI_TRUST_TX_LENGTH quirk applied to > this xhci device a decade ago. Are we sure this is not an issue in the xhci driver itself? Maybe the specific combination of modem and xhci controller triggers some corner case that is not fully implemented correctly in xhci? Last time I found something similar it took me 2 weeks of reading the USB standard to come up with the fix (45ba2154d12fc43b70312198ec47085f10be801a). Did you report this at the LKML already? Maybe they have some hints on how to best handle this. -- Aleksander
Re: modem terminates call when accepted remotely
Hoola Héctor! > > > First of all, I would like to thank you all your effort to develop and > maintain this API as it’s being very useful to us for handling modem > connections in our embedded devices. > > I'm really glad to see GMV is using all this :) I worked at Elecnor/Deimos Space in a past life! > We are facing an issue with ModemManager 1.16.2 (libmm-glib) and RC7620 > SIERRA modem. > > Sometimes, after starting a call to another SIM card device (mobile > phone), the call gets into “terminated” state (seen by ModemManager) in the > moment the call is accepted by the remote device, while it remains active > at this remote point. > > The call state becomes “dialing”, then “ringing-out”, and finally > “terminated” so there is no option to finish the call from ModemManager > side as it’s seen as already terminated. > > > This is definitely a bug to fix. That transition to "terminated" shouldn't happen when the callee picks up the call. Can you get MM debug logs while reproducing the issue? Also, is this using AT or QMI? > We managed to actually finish the call (remote side too) by the use of > ”mm_modem_voice_hangup_all_sync” function (defined in mm-modem-voice.h), > but it’s only available since ModemManager 1.12 Version. > > 1.18 or 1.20 you mean I guess. Either way, the solution is to avoid getting into that wrong terminated state I think. > Some of our devices are using other hardware and older versions of > ModemManager (1.10) and we have never been able to reproduce this issue so > we didn’t need to make use of “mm_modem_voice_hangup_all_sync” function. > > Could be due to some update in recent versions. We did include the call list management logic as well as the waiting call setup logic. Maybe some of that is not working as expected in your Sierra modem. > I would like to know if this issue has been already reported, and if so, > if it has been resolved or if it’s related to the hardware we installed on > our device or, on the other hand, if has something to do with the > ModemManager version being used. > > > Don't recall an issue like this, truth be told. Cheers -- Aleksander
Re: initial bearer apn
> > How is the initial-attach-ip-type decided in the NM MR you shared? I've seen > in a network in New Zealand where initial-attach-iptype has to be IPV4 and > then it can be changed to IPV4V6 during connection establishment. > I assume this could happen if the APN used during connection is different to the one used during initial attach? But this is definitely interesting; do you happen to have debug logs of MM on that setup to confirm your assumption? > Also, modem might have already gone through registration process before > "--3gpp-set-initial-eps-bearer-settings" is called. So when are we supposed > to call "mmcli --3gpp-set-initial-eps-bearer-settings"? > Yes, the modem always boots and attempts to register in the network automatically, that's the default. For initial attach it would use whatever it had configured. If you're using a device that comes with carrier-specific configs, the default config may already be the correct one for you. If you are using a generic firmware, there could be no explicit initial attach APN configured by default, but the network may be fine with providing you the correct one during the initial attach. You will need to use "--3gpp-set-initial-eps-bearer-settings" if e.g. you're not able to automatically register in the network and you know for sure the network you're trying to attach is the expected one. ModemManager dumps some warnings when attach failures happen, and we should definitely try to update the DBus API to expose those there as well (see https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/715) -- Aleksander
