Bug 106623 - ublox L200 fails if plugged in after ModemManager starts
Summary: ublox L200 fails if plugged in after ModemManager starts
Status: RESOLVED FIXED
Alias: None
Product: ModemManager
Classification: Unclassified
Component: plugins (show other bugs)
Version: git master
Hardware: Other Linux (All)
: medium normal
Assignee: ModemManager bug user
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-22 22:56 UTC by Martin Kelly
Modified: 2018-06-04 18:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
debug log (12.80 KB, text/plain)
2018-05-22 22:56 UTC, Martin Kelly
Details
debug log (94.87 KB, text/plain)
2018-05-29 18:30 UTC, Martin Kelly
Details

Description Martin Kelly 2018-05-22 22:56:58 UTC
Created attachment 139686 [details]
debug log

Hi,

I noticed that the most recent commit to the ublox plugin (3e469e7b8055a0a11abc8304ec44c3df39e74d3d, "u-blox: don't run quick AT procedure if READY_DELAY not configured") has broken my ublox L200. If I revert this commit and plugin the device, it registers correctly. But with this commit, I instead get the attached log (from running with the --debug option) and ModemManager gives up without setting up the device.

Notably, this occurs only if you do the following:

- Start ModemManager without the device plugged in
- Then plugin the device

If instead, you plugin the device and *then* start ModemManager, then everything works OK.

This is on Debian Stretch.
Comment 1 Martin Kelly 2018-05-22 23:08:52 UTC
Update: This actually isn't caused by that commit; sorry for the confusion. Looks like this is an issue both with and without the commit.
Comment 2 Aleksander Morgado 2018-05-23 06:59:46 UTC
What's the PID of the device?

Can you edit "/lib/udev/rules.d/77-mm-ublox-port-types.rules" and add the following line:

ATTRS{idVendor}=="1546", ATTRS{idProduct}=="<PID>", ENV{ID_MM_UBLOX_PORT_READY_DELAY}="20"

And then:
$ sudo udevadm control --reload
$ sudo udevadm trigger

And recheck.
Comment 3 Martin Kelly 2018-05-23 19:01:39 UTC
Yep, I'll check this when I'm back in front of the hardware tomorrow.
Comment 4 Martin Kelly 2018-05-24 18:46:21 UTC
Your suggestion was correct; it was just missing a rules entry for the L2.

martin@columbia:~/ModemManager$ lsusb | grep U-Blox
Bus 003 Device 092: ID 1546:1146 U-Blox AG

Adding this line to the rules file fixes it:

ATTRS{idVendor}=="1546", ATTRS{idProduct}=="1146", ENV{ID_MM_UBLOX_PORT_READY_DELAY}="20"
Comment 5 Martin Kelly 2018-05-24 18:49:29 UTC
Note that depending on its networking configuration, the L2 can register as several different USB IDs: 1141, 1143, and 1146:

https://www.u-blox.com/sites/default/files/TOBY-L2-MPCI-L2_SysIntegrManual_%28UBX-13004618%29.pdf
(page 43)
Comment 6 Aleksander Morgado 2018-05-27 07:24:45 UTC
Hey, before we add those udev rules... could you gather debug logs for me from ModemManager when trying to reproduce the problem and the udev rules are added? See https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/

Need to understand whether just a timeout is needed, or if the modem really sends the +READY URC
Comment 7 Martin Kelly 2018-05-29 18:30:38 UTC
Created attachment 139837 [details]
debug log
Comment 8 Aleksander Morgado 2018-06-02 14:43:43 UTC
Hey, thanks for the debug log. So the TOBY-L200 doesn't send any +READY URC, but it still needs at least 9s (per your log) to show the AT capable parser. Let's go on and apply the udev tag in the same way, even if no +READY URC is sent, it will just be as if we wait 20s before going on.
Comment 9 Aleksander Morgado 2018-06-02 14:51:57 UTC
Fixed in git master, will be included in MM 1.8
Comment 10 Martin Kelly 2018-06-04 18:27:06 UTC
Thanks! 20 seconds also agrees with the suggestion in the datasheet for how long to wait, so that's likely a good value to pick.

Small note: this behavior (and the USB ID) is the same on both the Toby L200 and L201 (I tested them both), so your comment in the udev rules should probably include both of them, just to prevent confusion.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.