[PATCH powerd] Look in /var/lock/ppp for LCK..ttyUSB* also.

Jerry Vonau jvonau at shaw.ca
Tue May 29 17:36:30 EDT 2012


On Tue, 2012-05-29 at 21:20 +0200, Sascha Silbe wrote:
> Jerry Vonau <jvonau at shaw.ca> writes:
> 
> [Hack to prevent suspend while GSM connection is in use]
> > How could we have dbus delay suspend while the ppp connection is
> > becoming active?
> 
> You need to extend powerd-dbus/nm_monitor.c to monitor other device
> types (GSM in this case) in addition to WLAN devices. See the
> NetworkManager 0.8 D-Bus API [1] and libnm-glib 0.8 API [2] for Fedora
> 14 or NM 0.9 D-Bus API [3] and libnm-glib 0.9 API [4] for Fedora
> 17. While most of nm_monitor.c only talks about WLAN devices, the WLAN
> specific code is limited to a few checks to ignore non-WLAN devices (in
> device_added_cb(), device_removed_cb() and examine_device()).
> 
> If you only want to inhibit suspend while the PPP connection gets
> established, all you need to do is to modify the checks mentioned above
> to allow NM_DEVICE_TYPE_MODEM in addition to
> NM_DEVICE_TYPE_WIFI. However, that's unlikely to do what you really
> want, as at least on XO-1 and XO-1.5 the USB ports get powered down
> during suspend, so you'd loose the GSM connection right after it got
> established. On XO-1.75 that problem may be fixed, but I wouldn't bet on
> most GSM modems to implement waking the host on incoming packets
> properly or even at all. We're still having trouble with the WLAN chips
> in this regard, even after several years of using the same two chips
> (USB8388 in XO-1, SD8686 in XO-1.5 and XO-1.75). GSM modems are an order
> of magnitude more problematic, so it's probably best to just inhibit
> suspend on all systems as long as a GSM connection is active. You can
> change that in check_device_state():
> 
> diff --git i/powerd-dbus/nm_monitor.c w/powerd-dbus/nm_monitor.c
> index fb10555..d33d8aa 100644
> --- i/powerd-dbus/nm_monitor.c
> +++ w/powerd-dbus/nm_monitor.c
> @@ -16,8 +16,11 @@ typedef struct DeviceHandle {
>  
>  static void check_device_state(NMDevice *device, DeviceHandle *handle, gboolean *suspend_ok)
>  {
> -       if (handle->state >= NM_DEVICE_STATE_PREPARE &&
> -               handle->state < NM_DEVICE_STATE_ACTIVATED) {
> +       if ((handle->state >= NM_DEVICE_STATE_PREPARE &&
> +            handle->state < NM_DEVICE_STATE_ACTIVATED) ||
> +           (handle->state == NM_DEVICE_STATE_ACTIVATED &&
> +            NM_IS_DEVICE_MODEM(device))
> +                   ) {
>                 g_message("%d: device %p state %d inhibits suspend", (int)time(0),
>                         device, handle->state);
>                 *suspend_ok = FALSE;
> 
> Untested, for NM 0.9 only. For NM 0.8 you need to check both
> NM_IS_GSM_DEVICE and NM_IS_CDMA_DEVICE. Since all of those are macros,
> a simply #ifdef NM_IS_DEVICE_MODEM should be enough to distinguish
> between NM 0.8 and NM 0.9; no need for autoconf magic.
> 
> 
> In addition, you'll want to inhibit suspend while the GSM modem is
> trying to register with the cellular network provider. For that you'll
> need to monitor ModemManager (similar to the monitoring of
> wpa-supplicant that powerd theoretically does for WLAN devices). Check
> out the ModemManager 0.5 API [5] (F14 and F17).
> 
> For monitoring whether the modem is currently trying to register to the
> mobile phone network provider, you can use the GetRegistrationInfo() and
> RegistrationInfo() signal (enumeration MM_MODEM_GSM_NETWORK_REG_STATUS).
> 
> 
> The approach detailed above is the high-tech solution that upstream
> should have in the long term. In the meantime you'll probably get best
> results using USB based suspend inhibit. This is what I use:
> 
> {{{
> sascha.silbe at mimosa:~$ grep -A2 GSM /etc/olpc-powerd/flags/usb-inhibits 
> # GSM modems are very slow to (re)establish a connection and practically
> # unusable with aggressive suspend
> class=commc
> sascha.silbe at mimosa:~$ 
> }}}
> 
> Plug in the GSM modem to use it (you'll have to explicitly establish the
> connection as NM 0.9 regressed over NM 0.8 w.r.t. automatic connection
> for GSM devices), remove it when you're done. Stable connection (as far
> as possible over GSM) while in use, no power draw while disconnected.
> 
> I haven't checked whether class=commc works for all (or most) GSM
> modems. Caveat emptor.
> 

Thanks for the detailed explanation, off to do some reading.

Jerry 

> Sascha
> 
> [1] http://projects.gnome.org/NetworkManager/developers/api/08/spec-08.html
> [2] http://projects.gnome.org/NetworkManager/developers/libnm-glib/08/
> [3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
> [4] http://projects.gnome.org/NetworkManager/developers/libnm-glib/09/
> [5] http://projects.gnome.org/NetworkManager/developers/mm-spec-05.html





More information about the Devel mailing list