[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