Hey Torsten, > > 2021-05-12 10:15:26.137 kernel: cdc_mbim 1-2:3.0: setting rx_max = 16384 > > 2021-05-12 10:15:26.149 kernel: cdc_mbim 1-2:3.0: NDP will be placed at end > > of frame for this device. > > 2021-05-12 10:15:26.150 kernel: cdc_mbim 1-2:3.0: cdc-wdm0: USB WDM device > > 2021-05-12 10:15:26.150 kernel: cdc_mbim 1-2:3.0 wwan0: register 'cdc_mbim' > > at usb-0000:00:14.0-2, CDC MBIM, 9e:90:a9:6f:2d:31 > > 2021-05-12 10:15:26.238 kernel: cdc_mbim 1-2:3.0 wwan0: unregister > > 'cdc_mbim' usb-0000:00:14.0-2, CDC MBIM > > 2021-05-12 10:15:29.405 kernel: cdc_mbim 1-2:3.0: setting rx_max = 16384 > > 2021-05-12 10:15:29.411 kernel: cdc_mbim 1-2:3.0: NDP will be placed at end > > of frame for this device. > > 2021-05-12 10:15:29.413 kernel: cdc_mbim 1-2:3.0: cdc-wdm0: USB WDM device > > 2021-05-12 10:15:29.414 kernel: cdc_mbim 1-2:3.0 wwan0: register 'cdc_mbim' > > at usb-0000:00:14.0-2, CDC MBIM, 9e:90:a9:6f:2d:31 > > 2021-05-12 10:15:29.464 kernel: cdc_mbim 1-2:3.0 wwan0: unregister > > 'cdc_mbim' usb-0000:00:14.0-2, CDC MBIM > > 2021-05-12 10:15:32.627 kernel: cdc_mbim 1-2:3.0: setting rx_max = 16384 > > 2021-05-12 10:15:32.640 kernel: cdc_mbim 1-2:3.0: NDP will be placed at end > > of frame for this device. > > 2021-05-12 10:15:32.641 kernel: cdc_mbim 1-2:3.0: cdc-wdm0: USB WDM device > > > ... > > Are there any known regressions for this device in newer kernels? > > I was able to identify the cause of the problem. > > Based on the discussion started in <[email protected]> > (Huawei me906s-158, March 2016) we had an udev rules in place to perform > the following actions: > > - resetting the modem by writing 0 to bConfigurationValue > - waiting 3 seconds > - reconfiguring the modem by writing 3 to bConfigurationValue > > This rule was executed when udev action != "remove" (so also on change > events).
Maybe your problem was really the "bind" events? This is not really a very recent addition, it happened some years ago, but it also gave us problems in MM, see: https://lists.freedesktop.org/archives/modemmanager-devel/2018-May/006417.html For every port "add" you'll also get a port "bind" event when the port is bound to a driver. Maybe you were running your rules on both "add" and "bind" and looking at what the rule was doing it would probably trigger an unbind/rebind and start again? something like that? > > When I run a "udevadm monitor kernel" while the driver is reprobing I > see a number of add, change, bind, unbind events. So it seems that the > timing for this events must have changed between the kernel versions to > cause problems in 5.10.29 (or some systemd-udevd behaviourial change > between versions 243 and 246). > > I have modified the rule for this special device to trigger only when > the udev action is set to "add" and the problem vanished. > Thanks a lot for replying with your discoveries! It's always nice to have open threads resolved. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
