Comment 26 for bug 1326954

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

(In reply to Adrian Perez de Castro from comment #10)
> I also have this issue, with a Fujitsu S936 laptop which includes an EM7305.
> After adding the udev rules in the post at 0xf8.org (modifying them to fit
> use the USB identifier that shows in my laptop, 1199:9041), the “mbim-proxy”
> program seems to hang in some kind of loop, chewing 80% of CPU time according
> to “top”. Here are the details of my configuration:
>
> - Arch Linux
> - ModemManager 1.6.4
> - NetworkManager 1.4.4
> - libmbim 1.14.0
> - Kernel 4.9.5
>
> I will be posting the output from “lsusb -v -d 1199:9041” as an attachment.

I believe you misread what the rules in the blogpost are doing :) I think the rules try to force the device into QMI mode, instead of the MBIM mode that would be picked up by default. This was a better choice for the Dell modem at that time because there wasn't support for running QMI commands over MBIM, and the Dell modem really required the FCC Auth command; but that is no longer the case, as MM already handles QMI over MBIM automatically as well as the FCC auth command for the Dell device.

Anyway, in your case it seems the rules didn't work as expected because you're still in MBIM mode, which is the one I would anyway suggest. I believe you can remove all the udev rules, as the kernel (or usb_modeswitch, it depends) should choose the MBIM configuration as preferred automatically.

That said, could you gather MM and mbim-proxy debug logs? I'd like to check whether the issue is exactly the same one:

$> sudo systemctl stop ModemManager
$> sudo killall -9 mbim-proxy
$> sudo /usr/libexec/mbim-proxy --verbose > /tmp/mbim-proxy.log 2>&1 &
$> sudo /usr/sbin/ModemManager --debug > /tmp/mm.log 2>&1 &
(and retry reproducing the issue)