Barry - and anyone needing to correct the 8139 issue immediately,
The reason the preference of 8139too over 8139cp is ignored is an error in /sbin/pup_event_backend_modprobe. Line 127 is
Code: Select all
if [ "$xMODULE" = "$PREFHIT" ];then
But a trace I made of a different case shows the following:
MODULE: dgcusbdcp PREFHIT: dgcusbdcp:cdc_acm PREFMOD: cdc_acm
The correct statement for that line is:
Code: Select all
if [ "$xMODULE" = "$PREFMOD" ];then
This should work for most (normal) cases.
But the story gets messier if a module has an "install" entry in the modprobe configuration files, causing the algorithm to fail. The module in my case has such a configuration statement, which shows up in the output from "modprobe --show_depends". The resulting name of the preferred module is a fragment of the install statement!
xMODULE: modprobe __ignore_install cdc_acm
which is an edited fragment of
Code: Select all
install cdc_acm /sbin/modprobe dgcusbdcp; /sbin/modprobe --ignore-install cdc_acm
The entire statement as it appears in "show_depends" is
Code: Select all
install /sbin/modprobe dgcusbdcp; /sbin/modprobe --ignore-install cdc_acm
Only the module name -- the part we need -- is missing from the "show_depends" copy.
EDIT (after a night's sleep):This conflict, for me, is a result of the preference failure. With the fix -- and after "erasing" the detected modem -- the dgc config file (and its 'install') would have been absent, since the preference would prevail. So far, the install-preference conflict does not appear to be a problem. But we need to keep it in mind whenever considering using an "install" statement for a module that is also a "preferred" alternative. /EDIT
I am concerned, too, that the current preference logic ignores the possibility that more than two modules may claim a device. The HSF, slamr and intel onboard-modem chips all have modaliases for the same modem. And on top of that, the device might also need agrmodem, although that is not in a modalias, but in a udev rule.
EDIT: I am also concerned that the 8139cp problem is addressed by only the preference treatment. There are 2 modaliases referencing 8139cp:
Code: Select all
alias pci:v00000357d0000000Asv*sd*bc*sc*i* 8139cp
alias pci:v000010ECd00008129sv*sd*bc*sc*i* 8139too
alias pci:v000010ECd00008138sv*sd*bc*sc*i* 8139too
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139cp
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139too
The first will not be overridden by the preference function. I believe the way to handle that is to create a PCI_OVERRIDES
entry for it in MODULESCONFIG:
Code: Select all
PCI_OVERRIDES='
(none) 0x0000127a 0x00004321 #Rockwell riptide modem not supported by driver
8139too 0x00000357 0x0000000a #override 8139cp
'
This along with the preference can replace the old 8139 logic omitted from the zzz package, that made the substitution for all loading of 8139cp. This change depends on whether 8139cp should actually be used for the first modalias.
In addition, to be consistent, perhaps the preference should be eliminated and replaced by another override for the remaining modalias, which is what the old logic accomplished:
Code: Select all
8139too 0x000010ec 0x00008139 #override 8139cp
Richard