The debian backports 4.8 standard kernel loads the module fjes on my thinkpad T460s.
How can I find out why this module is loaded, i.e. which hardware triggers loading this module?
Linux – Find out why linux kernel module was loaded
kernel-moduleslinux-kernel
Related Solutions
Well I don't believe a standard Fedora kernel package will include any modules which would trigger this taint so the question is, what other kernel modules have you installed?
Common candidates would be graphics drivers (though I think those will mostly set the "proprietary" bit) and wireless drivers.
If you can find anything in the lsmod output that you think may be a candidate then run modinfo <module-name> and see if the output includes intree: Y as any module without that will trigger the taint you are seeing.
UPDATE: The rts5139 module that you're seeing in lsmod but which doesn't seem to be on your system is probably in the initrd and is being loaded from there early in the boot process before the main filesystem is mounted.
That also explains why blacklisting won't work as you would have to rebuild the initrd with the updated blacklist. Rebuilding the initrd with dracut will cause the module to go away anyway though.
PCI ID 1022:43b9 is an AMD X370 Series Chipset USB 3.1 xHCI Controller. The PCI subsystem ID 1b21:1142 would suggest it might actually be an ASMedia ASM1042A USB 3 controller, possibly integrated into the AMD chipset.
For most USB 3.x controller chips, the appropriate driver module is xhci_pci which depends on module xhci_hcd. Both these modules are part of the standard Linux kernel, so they should be available in all modern Linux distributions. The corresponding kernel configuration options are CONFIG_USB_XHCI_PCI and CONFIG_USB_XHCI_HCD.
Many distributions include the kernel configuration file as /boot/config-<kernel version number>. So, you could run this command:
$ grep XHCI /boot/config-$(uname -r)
CONFIG_USB_XHCI_HCD=m
CONFIG_USB_XHCI_PCI=m
# CONFIG_USB_XHCI_PLATFORM is not set
Here, both xhci_hcd and xhci_pci are configured to be available as modules. If the lines would say ...=y instead, the USB 3 support would be compiled into the main kernel.
PCI ID 1022:43b5, subsystem ID 1b21:1062 is an AHCI SATA (or eSATA) controller, which is already covered by module ahci.
You can look up PCI IDs in PCI ID Repository.
If a driver has been specified by vendor/product IDs, you could use /sbin/modprobe -c | grep '<vendor ID>.*<product ID>'. If you get back a line like this, you've found a match:
alias pci:v0000<vendor ID>:d0000<product ID>sv... <module name>
This information comes from /lib/modules/modules.alias[.bin], which is generated by the depmod command from the device support information embedded in the kernel modules themselves (defined in the source code with a MODULE_DEVICE_TABLE macro). You can also use modinfo <module name> | grep alias to view the hardware support claimed by a particular module.
However, not all modules are specified by vendor/product IDs. Some drivers will cover an entire class of devices; for example, the xhci_pci module claims support of PCI base class 0x0C, subclass 0x03, interface 0x30... which maps to "Serial bus controller", "USB controller" and "XHCI" respectively. This is expressed as
alias: pci:v*d*sv*sd*bc0Csc03i30*
Note that you should not normally need to do any of these lookups manually unless you've blacklisted some modules or the auto-detection fails for some reason. For example, when the Linux kernel detects the original poster's USB 3 controller, it will cause (the equivalent of) the following command to be executed:
modprobe pci:v00001022d000043b9sv1b21sd1142bc0Csc03i30
which contains all the hardware vendor/device/class/subclass/interface IDs available for the device. If one of the wildcarded aliases on record in modprobe configuration matches this string, the respective module will get loaded automatically.
For USB devices (and indeed for any autoprobeable buses), there is a similar system of module aliases, and a USB ID repository.
If you don't have the appropriate module compiled on your system, your best bet is to use the PCI ID repository to identify the device or the chip used within it. Sometimes the repository entry identifies the Linux kernel module that will provide support for it. If that information is not present, you may need to google using the device/chip model; this will usually allow you to find any alternative/experimental driver modules that have not (yet?) been included in the standard kernel.
Best Answer
You can use lspci -v. You will need to grep (probably with -i to ignore case) for your module shown in lsmod. e.g. to find r8169:
You can change the number of lines before and after (A, B) to your liking/needs.
I found another user had the same question. There is a script here to find out.