Re: Modemmanager/Sierra Wireless MC8781 fails assert when no SIM is inserted



> > ...
> > > 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]