zzz: PREFLIST fix and improved

Wary 102 testers CHLee and rerwin reported on issues with the PREFLIST variable, in the case of the 8139cp module getting loaded instead of 8139too. Forum posts:


/etc/rc.d/MODULESCONFIG has a PREFLIST variable:
#PREFLIST: sometimes there are two hits, that is, two modules match the same

#'modalias' (that is, they are both claiming the same hardware). In such a case,
#here we can specify a preference. Each entry here is of the form
#'module1:module2' where module2 is the preferred choice.
#101218 format can have multiple ':', ex: 8139cp:8139too:8139xx (last is most preferred).
#note, list needs a space char at beginning and at end.
#w471 removed: ath5k:ath_pci martian_dev:ltserial r8169:r8101
#101209: added 8139cp:8139too
PREFLIST=' 8139cp:8139too rtl8180:r8180 rtl8187:r8187 rt2500usb:rt73usb orinoco_nortel:hostap_plx orinoco_plx:hostap_plx orinoco_tmd:hostap_plx orinoco_pci:hostap_pci bcm43xx:ssb prism54:p54pci tulip:dmfe option:hso hcfpcihw:hsfpcibasic2 dgcusbdcp:cdc_acm slamr:snd_intel8x0m '

The script /sbin/pup_event_backend_modprobe manages loading of modules and reads the above variable, and chooses the second variable if they both claim the same hardware -- that was broken, now fixed.

I have also extended it to support multiple ':' delimiters, as suggested by rerwin. Comment:

#101218 format can have multiple ':', ex: 8139cp:8139too:8139xx (last is most preferred).

Rerwin also wondered if 8139cp should be blocked entirely, however I was uncertain if this should be done for the one modalias in which 8139cp and 8139too do not claim the same hardware.

This is the new code in pup_event_backend_modprobe:
#101218 bugfix, improve...

#preferences list, ex rt2500usb and rt73usb both hits, then choose latter...
PREFHIT="`echo -n "$PREFLIST" | tr ' ' '\n' | grep "$modPATTERN"`"
if [ "$PREFHIT" != "" ];then
#note, rc.sysinit deletes all blacklist*.conf...
PREFMODS="`echo -n "$PREFHIT" | cut -f 2-9 -d ':' | tr ':' ' '`"
for PREFMOD in $PREFMODS #format can have multiple ':', ex: 8139cp:8139too:8139xx (last is most preferred).
echo "blacklist $MODULE" > /etc/modprobe.d/blacklist-${MODULE}.conf
xMODULE="`/sbin/modprobe --show-depends $MODALIAS 2>/dev/null | tail -n 1 | rev | cut -f 1 -d '/' | rev | cut -f 1 -d '.' | tr '\-' '_'`"
[ "$xMODULE" = "" ] && rm -f /etc/modprobe.d/blacklist-${MODULE}.conf
[ -f /etc/modprobe.d/blacklist-${MODULE}.conf ] && rm -f /etc/modprobe.d/blacklist-${MODULE}.conf

Posted on 18 Dec 2010, 7:10


Posted on 20 Dec 2010, 8:03 by 01micko
Modems masquerading as CD drives
With all the work you are doing with 3G modems has the modem showed up on the desktop as a CD drive at all? I expect that the E160E you have been testing may not as it doesn't need to be switched.
My oldish (now) E169 shows up as a CD drive, even in the drive wizard. I was using Universal Installer and it thought my modem was the cd drive, so I had to run the drive wizard to get around that.
Is there a way, through device ID I guess, to blacklist these modems from being recognised as CD drives? I'm sure it would cause some noobie confusion and frustration.

Posted on 20 Dec 2010, 8:38 by BarryK
Re 3G cd drive
Yes, my Huawei E160-E does display a CD icon.

I thought about it, and decided that it will not cause confusion ...probably.

When I plug in my E160-E, a message pops up informing that a 3G modem is plugged in, then when the /dev/ttyUSB* nodes appear another popup informs modem ready for use.
So, the appearance of the CD icon should not deter a user from going ahead and using the modem.

I would like to know of other 3G modems that do not need to be switched, as I need to create a special udev rule for them. So far I only have my E160-E modem, ids 12d1:140c.