| Age | Commit message (Collapse) | Author |
|---|
|
Looks like the preprocessor doesn't choke when using #if WITH_UDEV and
it isn't defined to any value, but anyway, better explicitly say that
we're checking if it's defined or not.
|
|
Since commit e9d0989ed069, the MMDevice may be removed from the
tracking hash table when the support check operation fails to create a
modem object.
If this failure happens due to the port probe cancellations requested
during the udev removal event for a given device port, we would end up
using an already disposed object and triggering a segfault.
This fix just makes sure a full valid reference to the MMDevice object
is kept around until we're done using it.
[mm-base-manager.c:216] device_removed(): (usbmisc/cdc-wdm1): released by device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4'
[mm-plugin-manager.c:1131] device_context_port_released(): [plugin manager] task 5: port released: cdc-wdm1
[mm-base-manager.c:216] device_removed(): (tty/ttyACM0): released by device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4'
[mm-plugin-manager.c:1131] device_context_port_released(): [plugin manager] task 5: port released: ttyACM0
[mm-base-manager.c:221] device_removed(): Removing empty device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4'
[mm-plugin-manager.c:1219] device_context_cancel(): [plugin manager) task 5: cancellation requested
[mm-plugin-manager.c:979] device_context_continue(): [plugin manager] task 5: no more ports to probe
[mm-plugin-manager.c:813] device_context_complete(): [plugin manager] task 5: finished in '0.090510' seconds
[mm-base-manager.c:172] device_support_check_ready(): Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.4': Operation was cancelled
[mm-base-manager.c:223] device_removed(): Device support check has been cancelled
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x00007ffff6543c50 in g_str_hash () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff6543c50 in g_str_hash () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff6542b2d in () at /usr/lib/libglib-2.0.so.0
#2 0x0000000000439675 in device_removed (self=0x770900, kernel_device=0x763e60) at mm-base-manager.c:225
#3 0x0000000000439e70 in handle_uevent (client=0x769c20, action=0x81d910 "remove", device=0x7fffe4001c40, user_data=0x770900) at mm-base-manager.c:415
#4 0x00007ffff54c61c8 in ffi_call_unix64 () at /usr/lib/libffi.so.6
#5 0x00007ffff54c5c2a in ffi_call () at /usr/lib/libffi.so.6
#6 0x00007ffff682d7ae in g_cclosure_marshal_generic ()
at /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff682cf75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#8 0x00007ffff683ef82 in () at /usr/lib/libgobject-2.0.so.0
#9 0x00007ffff6847bcc in g_signal_emit_valist ()
at /usr/lib/libgobject-2.0.so.0
#10 0x00007ffff6847faf in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff7023c74 in () at /usr/lib/libgudev-1.0.so.0
#12 0x00007ffff655445a in g_main_context_dispatch ()
at /usr/lib/libglib-2.0.so.0
#13 0x00007ffff6554810 in () at /usr/lib/libglib-2.0.so.0
#14 0x00007ffff6554b32 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#15 0x0000000000437bf5 in main (argc=2, argv=0x7fffffffeb28) at
main.c:180
(gdb) fr 2
#2 0x0000000000439675 in device_removed (self=0x770900, kernel_device=0x763e60) at mm-base-manager.c:225
225 g_hash_table_remove (self->priv->devices, mm_device_get_uid (device));
(gdb) p mm_device_get_uid (device)
$1 = (const gchar *) 0x0
(gdb) p *device
$3 = {parent = {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0}, priv = 0x7feb20}
|
|
If the device support check fails, either with an error, or afterwards
when trying to create a modem object, we must remove the MMDevice from
the tracking table of devices, so that a manual scan request
afterwards re-scans all ports.
https://bugs.freedesktop.org/show_bug.cgi?id=100157
|
|
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
|
|
This commit enables a new core ModemManager daemon option, so that automatic
detection of available modems is totally disabled: '--no-auto-scan'. Note that
this option also replaces the previously used '--test-no-auto-scan' option,
which was only used during tests.
Along with the new ModemManager option, a new ReportKernelEvent() method in
the API is defined, which allows notifying the daemon of which interfaces it
should be accessing, as well as the main details of each interface. The only
mandatory parameters in the new method are 'action' (add/remove), 'name' (the
name of the interface) and 'subsystem' (the subsystem of the interface).
The mmcli tool has support for using the new api method via several new options:
* The '--report-kernel-event' option allows specifying device ports one by
one, and is a direct mapping of the ReportKernelEvent() method:
$ sudo mmcli --report-kernel-event="action=add,name=wwan0,subsystem=net"
$ sudo mmcli --report-kernel-event="action=add,name=cdc-wdm0,subsystem=usbmisc"
* The '--report-kernel-event-auto-scan' option uses udev monitoring to notify
events automatically to the daemon. This allows to operate in a way
equivalent to the default daemon operation (with implicit auto-scan).
Worth noting that the ReportKernelEvent() method is only usable when
'--no-auto-scan' is explicitly used in the daemon. An error will be reported if
the method is tried while standard udev monitoring is enabled (implicit if
auto scan isn't explicitly disabled in the daemon).
If mmcli is going to be used only to report 'real time' events, an optional
'--initial-kernel-events=[PATH]' may be given in the ModemManager call to
automatically process a set of port kernel events one by one on boot. The file
may e.g. contain:
action=add,name=wwan0,subsystem=net
action=add,name=cdc-wdm0,subsystem=usbmisc
|
|
Instead of relying constantly on GUdevDevice objects reported by GUdev, we now
use a new generic object (MMKernelDevice) for which we provide an initial GUdev
based backend.
|
|
All ports of the same modem reported by the kernel will all be associated with
a common 'uid' (unique id), which uniquely identifies the physical device. This
logic was already in place, what we do now is avoid calling it the 'sysfs
path' of the physical device, because we may not want to use that to identify
a device.
This logic now also enables the possibility of "naming" the modems in a unique
way by setting the "ID_MM_PHYSDEV_UID" property in the "usb_device" that owns
all the ports.
E.g. a custom device has 4 modems in 4 different USB ports. The device path of
each USB device will always be the same, so the naming rules could go like this:
$ vim /usr/lib/udev/rules.d/78-mm-naming.rules
ACTION!="add|change|move", GOTO="mm_naming_rules_end"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.1", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-1"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.2", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-2"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.3", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-3"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.4", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-4"
LABEL="mm_naming_rules_end"
Each of the modems found will have a unique UID retrieved from the previous list
of rules. Then, "mmcli" has also been updated to allow using the UID instead of
the modem DBus path or index, e.g.:
$ sudo mmcli -m USB-MODEM-1
/org/freedesktop/ModemManager1/Modem/0 (device id '988d83252c0598f670c2d69d5f41e077204a92fd')
-------------------------
Hardware | manufacturer: 'ZTE CORPORATION'
| model: 'MF637'
| revision: 'BD_W7P673A3F3V1.0.0B04'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: '356516027657837'
-------------------------
System | device: 'USB-MODEM-1'
| drivers: 'option'
| plugin: 'ZTE'
| primary port: 'ttyUSB5'
| ports: 'ttyUSB5 (at)'
...
$ sudo mmcli -m USB-MODEM-1 --enable
...
|
|
|
|
|
|
Don't g_strdup() the physdev string to store it in the hash table; instead store
the original string right away as it is already created with g_strdup_printf().
Reported by: Yunlian Jiang <yunlian@chromium.org>
https://code.google.com/p/chromium/issues/detail?id=515929
|
|
This message gets printed for all netdevs and ttys, including most
machines normal ethernet/Wi-Fi interfaces. It seems a bit less critical
than 'warning' level would indicate.
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:19.0': not supported by any plugin
ModemManager[32097]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0': not supported by any plugin
|
|
|
|
device_added() might be called in response to a "change" or "move" attempt that
might have changed a candidate device to a non-candidate one.
|
|
Just so that we don't have same header names in src/ and /libmm-glib.
|
