Hey, > Attached is a log of a modem detection failure I have on my system. This > platform is pretty similar to my legacy platform, but there are some > differences: > > * Now running 5.10 series kernels on both. > * The board has WiFi, which means a lot more of the PCI subsystem gets exposed > in user space, which may be relevant for udev etc. > * There's additional LAN ports and a WAN port - again, not directly relevant > to > modem detection, but might have some effects with udev too. > * Subtle differences in USB hardware setup. There's a "USB passthrough" mode > on > this board, and sometimes this seems to misbehave. In one instance I saw the > modem reported twice in lsusb, although this seems to have been a one-off. > > In this log, I've disabled PPP, and out of desperation, DHCP too, to limit > the churn. This problem appears 100% of the time at start up, and is only > resolved by a restart of ModemManager, or a cycling of the USB interfaces > (which the top-level monitoring script will eventually do, but takes some > minutes in practice). > > The misdetection can happen on the legacy platform, but having disabled PPP > and extra plugins it seems to be pretty rare. > > Let me know if there's extra debug I can provide. >
The misdetection will happen regardless of whether you disable PPP or other plugins, because it depends exclusively on how quick the ports of a device are exposed by the kernel. In your case (timing more or less): * 1675449157.916842: ttyUSB0 detected * 1675449158.692125: ttyUSB1 detected * 1675449159.415647: ttyUSB2 detected * 1675449160.178757: ttyUSB3 detected * 1675449163.204415: ModemManager decides no more ports are expected, because the "extra probing time" has elapsed. The "extra probing time" is the amount of time ModemManager waits for a port to be notified since the last port notification on the same device. For openwrt this is 3 seconds (1.5s when using udev), see https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/src/mm-plugin-manager.c#L726 * 1675449163.515492: wwan0 detected * 1675449163.604525: cdc-wdm0 detected So in your case, it looks like we needed around 300ms more as "extra probing time". This issue is very very very dependent on the setup, and increasing this timeout value unconditionally for everyone will make device detection slower in cases where it wouldn't be needed. We should definitely make this value configurable, e.g. via a udev tag, so that users can adjust it if using slow systems. Another way to approach this issue would be by forcing a full device reprobe if we end up finding new ports added after we decided there may not be more notified, as in your case. I believe I already tried to do something like that months ago when we first discussed your issues, and I drafted a patch, but which is totally untested and may actually not work at all, here: https://gitlab.freedesktop.org/aleksm/ModemManager/-/commit/1ac4b7099b8835599f9131bf9f2ef6a7964c09ed Would be good to revisit that approach maybe, as it would be independent of the timing. -- Aleksander
