> > ... > > > modem-manager[3878]: <info> [1311508930.212757] [mm-serial-port.c:938] > > > mm_serial_port_close(): (ttyUSB0) serial port closed > > > modem-manager[3878]: <debug> [1311508930.213324] [mm-manager.c:687] > > > supports_callback(): (tty/ttyUSB0): plugin 0x9542d20 (Cinterion) existing > > > 0x9542f20 (Sierra) info->best 0x9542f20 (Sierra) > > > ** > > > ERROR:mm-manager.c:688:supports_callback: code should not be reached > > > > I think that Dan already found a situation like this one in git > > master... or was it another one? > > > > In general, we should try to limit the cases where modems get probed by > > the plugins which support RS232 modems (those without a exclusive > > udev-reported vendor ID filter). These plugins (Cinterion in this case) > > shouldn't probe modems that have a udev-reported vendor ID 'owned' by > > some other plugin. > > > > Will try to prepare a fix for that. > > Yeah; though the real fix is to fix the probing code so that it works as > intended and multiple plugins can say they *might* support the modem. > Then they get asked in order if they do and each returns a supports > "value". The plugin with the highest value for the port gets the port. > Other ports from the same modem automatically get given to the plugin > that had the highest value for the first port of the modem to finish > probing. Something in there is broken. >
Is that a real use case at the end? All plugins for usb modems do the udev-reported vendor ID check before even starting to probe... so currently (as far as I can tell) there is no plugin saying it might support some modem from other vendor. But yes, I agree that something there is broken :-) will try to understand what that is. -- Aleksander _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list