Fedora 19 assistance on modprobe /etc/modprobe.d/ .conf file being ignored

dennismccloud at earthlink.net dennismccloud at earthlink.net
Mon Feb 24 23:56:29 UTC 2014


I need some assistance in troubleshooting problem with passing a modprobe parameter to the lirc_zilog module.

I'm running Fedora 19 with the most recent updates:

# uname -r
3.12.11-201.fc19.x86_64

I have a file /etc/modprobe.d/lirc_zilog.conf file that contains the following:

# cat /etc/modprobe.d/lirc_zilog.conf
options lirc_zilog tx_only=1

This file previously worked to disable the IR receive mode on the lirc_zilog module but something seems to have changed to prevent this from happening.

The above parameter is being ignored since the lirc_zilog module is running both transmit and receive.

Here is the command to receive IR signals:

#irw
00000000000017b5 00 play Hauppauge
00000000000017b5 01 play Hauppauge
00000000000017b5 02 play Hauppauge

The lirc_zilog module is being loaded at system boot time:

# lsmod | grep lirc
lirc_zilog             22473  0
i2c_core               38476  8 drm,i915,i2c_i801,hdpvr,lirc_zilog,drm_kms_helper,i2c_algo_bit,videodev
lirc_dev               19504  1 lirc_zilog
rc_core                26896  1 lirc_dev

The systemd-modules-load.service appears to have completed normally:

# systemctl status systemd-modules-load.service
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since Mon 2014-02-24 18:06:33 EST; 1min 46s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 214 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)

Feb 24 18:06:32 divo systemd[1]: Starting Load Kernel Modules...

The tx_only option is a valid option for lirc_zilog:

# modinfo lirc_zilog
filename:       /lib/modules/3.12.11-201.fc19.x86_64/kernel/drivers/staging/media/lirc/lirc_zilog.ko
alias:          lirc_pvr150
license:        GPL
author:         Gerd Knorr, Michal Kochanowicz, Christoph Bartelmus, Ulrich Mueller, Stefan Jahn, Jerome Brock, Mark Weaver, Andy Walls
description:    Zilog/Hauppauge infrared transmitter driver (i2c stack)
depends:        i2c-core,lirc_dev
staging:        Y
intree:         Y
vermagic:       3.12.11-201.fc19.x86_64 SMP mod_unload
signer:         Fedora kernel signing key
sig_key:        FC:A0:01:2C:8A:A6:A3:A0:0F:CC:4E:16:E4:8C:17:FD:D9:C6:31:21
sig_hashalgo:   sha256
parm:           minor:Preferred minor device number (int)
parm:           debug:Enable debugging messages (bool)
parm:           tx_only:Only handle the IR transmit function (bool)

I can manually unload the lirc_zilog module and manually reload lirc_zilog with the tx_only=1 option and lirc_zilog module works as desired with IR receive disabled.

I've tried various filenames.conf and the different directories (/lib/modprobe.d) for modprobe without success.

If I run dmesg and grep for IR, I see that lirc_zilog is probing for IR Rx and IR Tx.

[Mon Feb 24 18:06:34 2014] lirc_zilog: probing IR Rx on Hauppage HD PVR I2C (i2c-8)
[Mon Feb 24 18:06:34 2014] lirc_zilog: probe of IR Rx on Hauppage HD PVR I2C (i2c-8) done. Waiting on IR Tx.
[Mon Feb 24 18:06:34 2014] lirc_zilog: probe of IR Rx on Hauppage HD PVR I2C (i2c-8) done
[Mon Feb 24 18:06:34 2014] lirc_zilog: probing IR Tx on Hauppage HD PVR I2C (i2c-8)
[Mon Feb 24 18:06:34 2014] lirc_zilog: IR unit on Hauppage HD PVR I2C (i2c-8) registered as lirc0 and ready
[Mon Feb 24 18:06:34 2014] lirc_zilog: probe of IR Tx on Hauppage HD PVR I2C (i2c-8) done

Previously when the tx_only=1 option was being properly processes, the lirc_zilog module was only probing for IR Tx.

Looking at the systemd entries from dmesg doesn't give any hints for why the lirc_zilog.conf options file isn't being read.

Looking at the output from journalctl -b doesn't provide any clues.

I've exhausted my ability to troubleshoot the systemd-modules-load.service to see the details of what is going on during the boot process.

I need help with how to enable debug on the systemd-modules-load process or help of where to look next to resolve this issue.

Thanks in advance for any assistance you can provide.


More information about the users mailing list