lirc is making a loop when is loaded, and it doesn't work

Bug #269743 reported by RCM
12
Affects Status Importance Assigned to Milestone
lirc (Ubuntu)
Fix Released
Undecided
Mario Limonciello

Bug Description

Binary package hint: lirc

Well, I've installed lirc, and I've configured it with dpkg. This happens when the configuration is for the it_87 module (which is the module for my hardware), but not with other modules:

rrr@m-laptop:~# /etc/init.d/lirc start
 * Loading LIRC modules [ OK ]
timeout waiting for devices to be ready
 * Unable to load LIRC kernel modules. Verify your
 * selected kernel modules in /etc/lirc/hardware.conf
rrr@m-laptop:~# /etc/init.d/lirc restart
 * Stopping remote control daemon(s): LIRC [fail]
 * Loading LIRC modules [ OK ]
timeout waiting for devices to be ready
 * Unable to load LIRC kernel modules. Verify your
 * selected kernel modules in /etc/lirc/hardware.conf

My /etc/lirc/hardware.conf:

# /etc/lirc/hardware.conf
#
#Chosen Remote Control
REMOTE="ITE IT8712/IT8705 CIR port"
REMOTE_MODULES="lirc_dev lirc_it87"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc0"
REMOTE_LIRCD_CONF=""
REMOTE_LIRCD_ARGS=""

#Chosen IR Transmitter
TRANSMITTER="Custom"
TRANSMITTER_MODULES=""
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""

#Enable lircd
START_LIRCD="true"

#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD="false"

#Try to load appropriate kernel modules
LOAD_MODULES="true"

# Default configuration files for your hardware if any
LIRCMD_CONF=""

#Forcing noninteractive reconfiguration
#If lirc is to be reconfigured by an external application
#that doesn't have a debconf frontend available, the noninteractive
#frontend can be invoked and set to parse REMOTE and TRANSMITTER
#It will then populate all other variables without any user input
#If you would like to configure lirc via standard methods, be sure
#to leave this set to "false"
FORCE_NONINTERACTIVE_RECONFIGURATION="false"
START_LIRCMD=""

syslog:

Sep 13 10:04:20 m-laptop kernel: [ 1952.802644] lirc_dev: IR Remote Control driver registered, at major 61
Sep 13 10:04:20 m-laptop kernel: [ 1952.844076] lirc_dev: lirc_register_plugin: sample_rate: 0
Sep 13 10:04:20 m-laptop kernel: [ 1952.929928] lirc_dev: lirc_register_plugin: sample_rate: 0
Sep 13 10:04:20 m-laptop kernel: [ 1953.095369] lirc_dev: lirc_register_plugin: sample_rate: 0
Sep 13 10:04:20 m-laptop kernel: [ 1953.231510] lirc_dev: lirc_register_plugin: sample_rate: 0
Sep 13 10:04:20 m-laptop kernel: [ 1953.376776] lirc_dev: lirc_register_plugin: sample_rate: 0
Sep 13 10:04:20 m-laptop kernel: [ 1953.514307] lirc_dev: lirc_register_plugin: sample_rate: 0
.........................................[it continuous...]
Sep 13 10:14:04 m-laptop kernel: [ 2447.872698] lirc_dev: lirc_register_plugin: sample_rate: 0

Related branches

Revision history for this message
RCM (rcmenclave) wrote :
Revision history for this message
Mario Limonciello (superm1) wrote :

So from what it looks like here, this is a very ugly race condition rearing it's head. lirc-it87 gets loaded, and creates /dev/lirc0. Well udev sees this happen and offers to restart lirc. lirc-it87 bails out because it can't find the device. udev sees this again and says hey!, lets restart lirc. Endless cycle. I think the interim solution is going to have to be, don't allow anything to be modprobed when we are called by udev. Just assume the USB devices were handled by hotplugging.

Revision history for this message
Mario Limonciello (superm1) wrote :

OK well i've got a fix in bzr #25 for this. Thanks for reporting!

Changed in lirc:
assignee: nobody → superm1
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lirc - 0.8.3-0ubuntu2

---------------
lirc (0.8.3-0ubuntu2) intrepid; urgency=low

  * debian/patches/25_upstream_2.6.26.patch:
    - Fix lirc-modules-source compilation on 2.6.26 by pulling some
      patches from CVS (LP: #247233)
  * debian/rules:
    - Install original modules back into proper location for
      intrepid kernel (LP: #242216)
  * debian/patches/37_msi_tv_anywhere.dpatch:
    - Create patch for supporting MSI TV @anywhere remote. (LP: #241830)
  * debian/lirc.postinst:
    - Correct path to look for module in Intrepid.
    - Ask for a path when using dvico remotes. (LP: #238032)
    - Don't accidentally overwrite lircd.conf and hardware.conf
      when things haven't really changed at all. (LP: #206609)
  * debian/lirc.init.d:
    - Don't allow udev to put us into endless spinning loops. Instead
      pray that module hotplugging worked for all things USB. (LP: #269743)
  * debian/lirc.fdi:
    - Include this FDI file to prevent in kernel support for the
      saa7134 when LIRC is installed. (LP: #204960, #164627)
  * debian/rules:
    - Install FDI file.
  * debian/lirc.install:
    - List FDI file.
  * debian/patches/22_hauppauge_novat_500.dpatch:
    - Adapt to include alternative numeric keys. (LP: #224080)
  * debian/patches/25_upstream_2.6.27.dpatch:
    - Update to content that is currently sitting in Ubuntu GIT
      tree.

 -- Mario Limonciello <email address hidden> Wed, 24 Sep 2008 12:02:17 -0500

Changed in lirc:
status: Fix Committed → Fix Released
Revision history for this message
Thomas Weissel (xapient) wrote :

so if this bug is fixed.. why is it still not possible to start lirc at boottime.. i have to add an entry to rc.local

/etc/inti.d/lirc restart

it has to be "restart" because "start" simply says :

 * Loading LIRC modules [ OK ]
 * Starting remote control daemon(s) : LIRC [fail]

(thats the same problem that occurs at boot time when having lirc in /etc/rcX.d)

it seems like lircd is already running... but why is it? even if i remove input-lirc and lirc from the runlevel directories and try to start lirc with sudo /etc/inti.d/lirc start it can't start the "lircd"

i did no special configuration.. just installed lirc from the repos.. i know this buggy behaivior since several ubuntu versions - why is it that no one else seems to bother?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.