On 05/05/2017 03:00 PM, David De Graaf wrote: > On 05/05/17 15:03, Rami Rosen wrote: >> Hi, >>> You probably meant lsinitrd (not lsmod). >> Yes, this is true; "lsinitrd" (from the dracut package) show the >> contents of the initramfs image. >> If you see that r8712u there and want to avoid loading it in boot >> time, I believe >> you have 2 options: >> >> 1) Add "rd.driver.blacklist=r8712u" to the kernel command line and >> reboot. >> >> 2) Remove it from initramfs, and then recreate the initramfs image >> without it, this is doable (I believe it can be done with dracut >> and/or tar/cpio) ; I did such things in the past. You should be able >> to find howtos on the web about this procedure. >> >> Regards and good luck! >> >> Rami Rosen >> http://ramirose.wix.com/ramirosen > Thanks to all - Gordon, Ahmad, Rami, and Rick Stevens by direct email, > for your > suggestions. However, like Lazarus rising from the dead, r8712u remains > with me. > 1 - lsinitrd showed lots of stuff, but no mention of r8712u. > 2 - I ran 'rmmod r8712u', verified it was gone, and ran dracut to > recreate initramfs. > After rebooting, r8712u was again loaded. > 3 - I added Rami's kernel boot option. r8712u is still loaded. > 4 - I examined dmesg carefully. r8712u gets loaded at the very end, > after a lot of other stuff. > The command line comes up early (showing the blacklist): > > [ 0.000000] Linux version 4.10.12-200.fc25.x86_64 > (mockbuild@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) (gcc version 6.3.1 20161221 > (Red Hat 6.3.1-1) (GCC) ) #1 SMP Sat Apr 22 03:03:34 UTC 2017 > [ 0.000000] Command line: > BOOT_IMAGE=/boot/vmlinuz-4.10.12-200.fc25.x86_64 > root=UUID=fab2b5ec-a433-4ab2-bff5-f1c0d06a7e9f ro quiet selinux=0 > net.ifnames=0 audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau > video=vesa:off LANG=en_US.UTF-8 rd.driver.blacklist=r8712u > > The plugged-in USB wireless adapter is found fairly soon: > > [ 1.214566] usb 2-2: New USB device found, idVendor=0bda, idProduct=8172 > [ 1.214569] usb 2-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 1.214570] usb 2-2: Product: RNX-180UBE > [ 1.214571] usb 2-2: Manufacturer: Manufacturer Realtek > [ 1.214572] usb 2-2: SerialNumber: 00e04c000001 > > The r92su module appears much later: > > [ 13.728579] r92su 2-2:1.0: Realtek RTL81XX rev C CUT, rf:1T2R is > registered a > s 'phy0'. > > And the r8712u module shows up in the last two lines, much later: > > [ 46.982424] r8712u: module is from the staging directory, the quality > is unknown, you have been warned. > [ 46.983330] usbcore: registered new interface driver r8712u > > All this leads me to speculate that whatever mechanism matches the > vend:prod > with drivers is what's doing this. Is this NetworkManager being too > clever by half? > Such a search will, indeed, turn up both the r92su and r8712u modules. > modinfo shows that both claim to support my wireless adapter: > Bus 002 Device 002: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU > 802.11n WLAN Adapter > > I just wish I knew with certainty why the r92su module is picked. > That's what I want to happen, but I can't tell why it is happening, > since the /etc/modprobe.d/wireless.conf file seems to be somewhat ignored. > > Surely, it can't be all that unusual to have more than one driver > claiming to support > a particular hardware item. How is such a choice resolved? What if the > choice is > wrong, or merely undesired? The blacklist will prevent the module from being used since the aliases and PCI ID claims are ignored due to the blacklist. The module will load (forced by udev's rules), but modprobe is run after that and all the module will do is occupy RAM because of the blacklist. At least that's the way I read it. I could be totally wrong. That being said, I decided to dig a little deeper into dracut. It appears that this is not a dracut issue since dracut only seems to include wired network modules as part of the initrd. A lot of dracut's module configurations are managed by scripts and such in the /usr/lib/dracut/modules.d directory. There is a "90kernel-network-modules/module-setup.sh" script in there that explicitly excludes wireless network modules (and a couple of others such as ISDN drivers). I assume they're counting on the post- boot udev/modprobe voodoo to handle the rest of it. After all, the initrd is really only there to get the system booted. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Grabel's Law: 2 is not equal to 3--not even for large values of 2. - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
