- How do I find which RTC module my kernel loads?
- 2 Answers 2
- Option 1: Poke the /sys filesystem
- Option 2: Have udevadm look under /sys for you
- So what about the /sys/class/rtc/rtc0/device/rtc/rtc0 ?
- Easy way to show currently loaded kernel modules in Linux
- Show currently loaded kernel modules in Linux
- Show loaded modules using lsmod command
- Check if Specific Kernel Module is Loaded
- Get Information about Specific Module
How do I find which RTC module my kernel loads?
During compilation of my kernel using a configuration file obtained from Ubuntu OS 16.04, I noticed I am compiling a lot of RTC drivers, basically every possible driver:
. snip . CC [M] drivers/rtc/rtc-bq4802.o CC [M] drivers/rtc/rtc-da9052.o CC [M] drivers/rtc/rtc-da9055.o . more of those . .
- looking in lsmod I see no RTC driver
- lshw isn’t helpful either
- lspci -v also wasn’t yielding much info.
Lower level inspection, shows a device exists:
$ ls -l /dev/rtc lrwxrwxrwx 1 root root 4 Dec 18 09:54 /dev/rtc -> rtc0
The closest I got the get more info is in /sys/class/rtc/ :
$ sudo cat /sys/class/rtc/rtc0/device/rtc/rtc0/name rtc_cmos
Doe that mean, that the only driver my kernel is using is rtc_cmos ?
- Does that mean I do not need all the other drivers?
- Does that mean that my laptop uses a CMOS compatible hardware?
- also, why does modinfo rtc_cmos return nothing?
2 Answers 2
I understand the OP got the correct answers to the narrow question, but I feel it more in SO spirit to generalize the answer, so I am posting it in hope that it would be helpful to answer the generalized question: How do I find what driver the /dev/xyz is using?.
Option 1: Poke the /sys filesystem
Provided you have sysfs mounted (normally at /sys ; but I have yet to find out a distro that does not), why do not ask the kernel itself?
$ ls -l /dev/rtc0 crw------- 1 root root 249, 0 2019-04-01 15:22:29 /dev/rtc0 ^ ^ ^ +-> character device +---+-> Major and minor node numbers.
2. Substitute the numbers into the /sys/dev path as below, ( char is for char devices, block is, you guessed it, for block devices).
$ cat /sys/dev/char/249:0/name rtc_cmos 00:00
This is the name of the kernel module that is attached to the node. Works same regardelss of whether the module is linked into kernel, or loaded via modprobe. (And 00:00 is not the time in the RTC clock. Rather, IIRC, it’s the device address or «function» on its parent driver or bus; but do not trust me on this, I remember that only vaguely).
Side note, feel free to explore this filesystem. It’s readable by non-root (except for security-sensitive parts, most of which you can read as root), entirely safe to read, and you can find a lot of hardware and low-level software configuration info there. Unlike most of /proc , most of /sys is writable, and used by programs to change the running kernel and device parameters. For one, sysctl works entirely through it. But I digress.
Option 2: Have udevadm look under /sys for you
If you have udevadm available, ask it everything it knows about the device (the program accepts both /dev and /sys paths for the device):
$ udevadm info -a /dev/rtc0 [. snip intro text. ] looking at device '/devices/pnp0/00:00/rtc/rtc0': KERNEL=="rtc0" SUBSYSTEM=="rtc" DRIVER=="" ATTR=="2019-06-27" ATTR=="1" ATTR=="64" ATTR=="rtc_cmos 00:00" ATTR=="1561605536" ATTR=="03:18:56" ATTR=="" looking at parent device '/devices/pnp0/00:00': KERNELS=="00:00" SUBSYSTEMS=="pnp" DRIVERS=="rtc_cmos" =="PNP0b00" ATTRS=="" ATTRS=="" looking at parent device '/devices/pnp0': KERNELS=="pnp0" SUBSYSTEMS=="" DRIVERS==""
The info command instructs udevadm to give out everything it knows about the device, and the -a switch is to go up the chain of parent drivers/busses. Here you see that the parent device /devices/pnp0/00:00 has the driver rtc_cmos , and is discovered/activated on the bus created by another device, pnp0 , which is the plug-and-play bus enumerator.
By the way, the names udevadm prints are also paths in the sysfs, i. e. you can see them in your normal file space by prefixing the sysfs mount point, /sys :
$ ls -l /sys/devices/pnp0/00:00/rtc/rtc0 $ ls -l /sys/dev/char/249:0/
Both these command will produce identical output.
Once caveat is, unlike «normal» file systems, sysfs does hardlink directories, so do not try to do any recursive searches in it (like find . /sys or ls -R /sys ) — these programs will just crash after struggling with the infinite looping over the filesystem.
So what about the /sys/class/rtc/rtc0/device/rtc/rtc0 ?
As you noticed, there are multiple paths from the root of sysfs down to the device parameter node. Which one is the real McCoy?
- Not every device has an interface via the /dev filesystem (or any other; there is nothing special about /dev — it’s just a tempfs; it’s the file /dev/rtc0 which is special). These you won’t find through the path /sys/dev/* .
- Not every device is part of a subsystem, this is also optional. There are not discoverable through /sys/class* . So this is also a helpful, but optional link. Note that this node is different: it must expose subsystem-specific parameters. In our case, all RTC clocks expose a well-known set of settings common to the rtc sybsystem.
- Now, /sys/devices/pnp0/00:00/rtc/rtc0 is the main, canonical path to the device sysfs node. It always corresponds to its topological location in the hierarchy of system busses and drivers: this is the instance rtc0 of the device rtc , which is addressed as 00:00 on the bus pnp0 . It does not always correspond to its physical connection; in our case, pnp0 is a virtual bus which does not connect devices to physical busses and bridges, but only discovers and enumerates them. This is the canonical name for the device (sans the /sys prefix, of course—it’s just a mount point) used by udev to uniquely identify it.
- Finally, a kernel module does not have to expose anything in sysfs. Only the modules that must be discoverable from userspace need that, strictly. But if it does, the module decides what to expose, and it’s parent and grandparents determine where in sysfs it will be under the devices root.
Easy way to show currently loaded kernel modules in Linux
This tutorial is going to teach you how to show currently loaded kernel modules in Linux. Kernel modules are pieces of code that can be loaded or unloaded from the kernel on demand. The loaded kernel modules therefore, are the ones that are currently loaded into your system’s memory and that your kernel is either utilizing or about to utilize for accomplishing a specific task.
Show currently loaded kernel modules in Linux
Show loaded modules using lsmod command
lsmod is a command-line utility that displays the presently loaded kernel modules.
Run the following command to see a list of all loaded kernel modules on your Linux system.
The command will display a list of currently loaded kernel modules with their sizes as shown below
Module Size Used by btrfs 1327104 0 blake2b_generic 20480 0 xor 24576 1 btrfs raid6_pq 114688 1 btrfs ufs 81920 0 qnx4 16384 0 hfsplus 110592 0 hfs 61440 0 minix 36864 0 ntfs 106496 0 msdos 20480 0 jfs 188416 0 xfs 1499136 0 libcrc32c 16384 2 btrfs,xfs cpuid 16384 0 vsock_loopback 16384 0 vmw_vsock_virtio_transport_common 36864 1 vsock_loopback vmw_vsock_vmci_transport 32768 2 vsock 45056 7 vmw_vsock_virtio_transport_common,vsock_loopback,vmw_vsock_vmci_transport nls_iso8859_1 16384 1 snd_ens1371 32768 4 snd_ac97_codec 139264 1 snd_ens1371 gameport 20480 1 snd_ens1371 ac97_bus 16384 1 snd_ac97_codec snd_pcm 114688 3 snd_ac97_codec,snd_ens1371 crct10dif_pclmul 16384 1 ghash_clmulni_intel 16384 0 snd_seq_midi 20480 0 aesni_intel 372736 0 snd_seq_midi_event 16384 1 snd_seq_midi crypto_simd 16384 1 aesni_intel snd_rawmidi 36864 2 snd_seq_midi,snd_ens1371 cryptd 24576 2 crypto_simd,ghash_clmulni_intel snd_seq 73728 2 snd_seq_midi,snd_seq_midi_event glue_helper 16384 1 aesni_intel snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi snd_timer 40960 3 snd_seq,snd_pcm vmw_balloon 24576 0 snd 94208 13 snd_seq,snd_seq_device,snd_timer,snd_ac97_codec,snd_pcm,snd_rawmidi,snd_ens1371 joydev 24576 0 input_leds 16384 0 serio_raw 20480 0 soundcore 16384 1 snd vmw_vmci 73728 2 vmw_balloon,vmw_vsock_vmci_transport mac_hid 16384 0 sch_fq_codel 20480 2 vmwgfx 311296 7 ttm 73728 1 vmwgfx drm_kms_helper 237568 1 vmwgfx cec 53248 1 drm_kms_helper rc_core 61440 1 cec fb_sys_fops 16384 1 drm_kms_helper syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper parport_pc 45056 0 ppdev 24576 0 lp 20480 0 parport 65536 3 parport_pc,lp,ppdev drm 548864 10 vmwgfx,drm_kms_helper,ttm ip_tables 32768 0 x_tables 49152 1 ip_tables autofs4 45056 2 crc32_pclmul 16384 0 psmouse 155648 0 mptspi 24576 2 mptscsih 45056 1 mptspi mptbase 98304 2 mptspi,mptscsih ahci 40960 0 libahci 36864 1 ahci e1000 143360 0 scsi_transport_spi 32768 1 mptspi pata_acpi 16384 0 i2c_piix4 28672 0 hid_generic 16384 0 usbhid 57344 0 hid 135168 2 usbhid,hid_generic
lsmod command basically reads the contents of the /proc/modules and prints it in a formatted manner.
Thus, you can also check currently loaded modules by just printing the contents of the /proc/modules file.
Check if Specific Kernel Module is Loaded
To list specific module, run the following command
Replace ModuleName with the name of the module you want to list.
For example, to list KVM related modules, use the command below.
kvm_intel 282624 0 kvm 663552 1 kvm_intel
Get Information about Specific Module
To get all the information about specific module, run the following command
sudo modinfo ModuleName
Replace ModuleName with the name of the module you want to list its information.
For example, to check information about the kvm kernel modules above, run the command below.
filename: /lib/modules/5.4.0-48-generic/kernel/arch/x86/kvm/kvm.ko license: GPL author: Qumranet srcversion: FB5884BFC5A986FE809B1AC depends: retpoline: Y intree: Y name: kvm vermagic: 5.4.0-48-generic SMP mod_unload sig_id: PKCS#7 signer: Build time autogenerated kernel key sig_key: 69:0F:B2:8C:24:82:6C:28:AB:28:F7:D2:E5:B8:D0:0B:2C:EF:1F:87 sig_hashalgo: sha512 signature: 5B:AF:F6:07:76:0F:C2:B9:6B:05:C4:A6:E8:58:E8:BB:63:8B:DE:4A: CC:5F:81:AF:A2:AC:7D:D0:42:1B:CA:45:EA:79:3D:11:18:F0:E6:45: 73:CE:FB:63:02:26:0E:7E:B9:28:17:03:70:84:10:65:7F:6E:DA:B2: 89:55:0B:E7:22:76:1E:EF:99:3F:79:D5:7B:E7:39:96:68:57:EE:9E: D3:9A:B6:3A:3E:39:1F:C5:4A:82:CD:36:7A:D9:22:79:12:EC:E9:F7: DC:C5:6D:B2:DE:FF:CF:63:B8:A8:E3:A0:09:39:E9:6C:3C:F7:88:5F: 2B:51:F2:CD:AA:89:68:6F:CB:19:68:5B:E7:61:E0:E0:31:12:E7:B8: D5:5D:76:14:1E:A2:40:E4:49:26:94:12:66:56:B8:AD:91:DB:EA:0F: F0:DB:08:F9:71:62:24:DC:92:BC:89:8F:2E:F8:C8:7E:56:A1:85:7C: EC:98:A8:E9:CB:EA:07:90:BC:52:21:D9:EC:0B:26:3A:53:03:AA:79: 22:D8:F2:1C:2A:91:2D:59:D3:FD:A5:C4:77:4C:C1:75:CA:54:2F:22: E4:9B:D6:85:8A:B7:B4:23:87:AE:D4:89:57:7D:77:49:95:80:BB:11: A6:A2:81:5B:93:A0:F1:9E:69:AB:CE:61:58:30:C2:5B:9E:41:09:72: E2:7E:48:60:02:18:12:A7:8B:0C:B0:83:5E:D6:8A:A2:83:20:1C:3E: 31:95:40:10:93:C0:35:17:66:4D:3E:45:11:2E:71:95:29:A2:02:90: 18:E2:5A:F2:72:94:2B:4B:E6:7A:FF:5C:E3:1D:6D:38:E0:30:35:FC: 65:35:CB:6C:36:63:E9:35:83:56:89:AD:BF:1B:BA:06:0B:E5:14:8B: F6:B0:1A:D4:13:AF:E1:CD:4D:CE:9B:DE:A6:51:C0:90:5A:19:15:CC: F2:6D:77:B0:C6:04:02:88:17:1C:A7:59:7A:6C:EB:5B:17:6B:65:82: 41:24:4E:A0:7F:8D:3F:9A:A6:16:A9:82:A2:02:32:EF:FE:09:2F:A5: 5C:C7:0E:83:01:96:EC:D2:A7:C4:79:7E:90:5B:03:63:D7:48:59:B7: 88:DC:75:CB:91:5D:88:BB:1F:D9:DE:79:A2:A3:A6:3B:53:D3:2B:47: 72:A0:A3:9F:CA:9B:DD:4B:41:23:D3:26:E0:29:0F:9C:13:6F:3E:29: 01:1D:28:D2:86:E4:E7:8B:F3:F5:A5:EB:F8:CB:A8:51:BD:5D:11:2A: 56:DC:7E:EE:5B:DB:E6:68:18:9C:23:AE:BB:BE:64:E0:E9:9F:83:A5: 01:4A:A4:6B:8F:88:97:9D:54:D3:DE:5A parm: nx_huge_pages:bool parm: nx_huge_pages_recovery_ratio:uint parm: ignore_msrs:bool parm: report_ignored_msrs:bool parm: min_timer_period_us:uint parm: kvmclock_periodic_sync:bool parm: tsc_tolerance_ppm:uint parm: lapic_timer_advance_ns:int parm: vector_hashing:bool parm: enable_vmware_backdoor:bool parm: force_emulation_prefix:bool parm: pi_inject_timer:bint parm: halt_poll_ns:uint parm: halt_poll_ns_grow:uint parm: halt_poll_ns_grow_start:uint parm: halt_poll_ns_shrink:uint
Congratulations, you have reached the end of the article. You have learned how to show currently loaded kernel modules in linux