# [solved] lirc dies sporadically in kernel 2.6

## oscarwild

Hi folks,

i've been successfully using lirc for several years now with kernel 2.4, and never experienced trouble in any way until I changed to kernel 2.6 some months ago. I haven't ever since been able to keep lirc running for longer than about 2 days without a manual restart.

Most of the threads I read in the gentoo forums deal with how to get lirc installed in conjunction with kernel 2.6. But that's not my question; I managed to do that in several ways:

- love-sources, that already contain a lirc patch

- manually applied several different lirc patches to gentoo-dev-sources

- used the current CVS snapshot with unpatched gentoo-dev-sources (that's the way recommended by the lirc website! There's really _no_ need to patch the kernel anymore!)

- modified the latest lirc ebuild in order to compile and correctly install the driver modules (should give the same result as CVS install).

*EACH* of these approaches works (the obvious difference was, that the kernel patches provided the device node /dev/lircd when the CVS shapshots provided /dev/lrc/lircX). But regardless of kind of installation, suddenly the lirc daemon stops processing incoming remote signal,  then I've to kill lircd, unload and reload the kernel modules (lirc_dev and lirc_serial), afterwards it works for some hours again and so on.

When the failure occurs, the lirc daemon doesn't die for some reason. It simply stops processing the remote signal... The fatal thing about it: there's no note in any way about a lirc failure in the log files! I'm absolutely clueless what to try next... 

I heard about a unresolved "spinlock issue", but can't do anything with this information (wtf is a spinlock?).

So, is there anyone out there experiencing similar behaviour? Probably, even found out why this occurs and how to solve it??

Thanks in advance for your advice!

My setup:

- currently gentoo-dev-sources 2.6.7-r13 (tried 2.6.2, 2.6.4, 2.6.5 as well, also gave love-sources in several versions a try without any effect)

- kernel patched for em8300 in order to support my dxr3 video-out board

- lirc 0.7.0 pre6 (modified ebuild that compiles/installs the kernel modules, also tried pre5 and pre4)

- homebrew receiver on the serial port (lirc_serial module)Last edited by oscarwild on Wed Sep 29, 2004 7:30 pm; edited 1 time in total

----------

## Tasslehoff

This doesnt help solve your problem , though I am confirming I have the same problem.  

I am using gentoo-dev-sources-2.6.5-r1 my remote is for the Hauppage 350 pvr.  It will be working great and just stop with no warning or errors.  I checked lsof to see if anything is blocking /dev/lirc and nothing is.

----------

## oscarwild

Thanks for your response, Tasslehoff!

What lirc driver does your Hauppauge remote use?

I suppose it's not the lirc_serial module, so we could exclude it when looking for the failure cause.

----------

## oscarwild

*bump*

----------

## dvh

Not sure if I can help or not, but I use LIRC with a Hauppauge 250 and the grey remote.  I'm not aware that my LIRC stops working (maybe I have not gone long enough without a reboot), but I do know that LIRC only works until I stop the mythtv frontend.  If I restart, then it no longer works.  Same behavior with irw.

I am using kernel 2.6.7 with some form of lirc patch (something.2.6.5.something) and the latest lirc from portage.  I am aware of lirc/kernel issues, but I don't understand them.  From your post, I have learned that the kernel *patch* provided the device link.  If I use the CVS version, that will provide a different device link?  What would change in my myth setup to accomodate that?  I would be happy to try this to see if I can duplicate your issue if I can make the CVS work once, but I need your help to set up for the CVS lirc.

-dvh

----------

## oscarwild

hi dvh,

first of all, thanks for your response.

As it seems to me, I've found the reason for my lirc problem as well as a solution  :Very Happy: 

A long time ago I had to provide four serial interfaces. When I replaced my peripherals by USB ones, some kernel configuration had been left, which enabled extended serial support (interrupt sharing and interrupt auto detection):

```

CONFIG_SERIAL_8250_EXTENDED=y

CONFIG_SERIAL_8250_SHARE_IRQ=y

CONFIG_SERIAL_8250_DETECT_IRQ=y

```

Running kernel 2.4.x, this has never been an issue, so I forgot about it.

When upgrading to 2.6, I reused as much of my old configuration, and run into that lirc trouble. Three days ago I  deactivated CONFIG_SERIAL_8250_EXTENDED, and my lirc has been running happily ever after  :Very Happy:  Well, I really hope, this didn't just happen by chance, and tomorrow I'll end up restarting day by day again, but till now it seems to run quite stable!

Nevertheless, about your lirc trouble (which I don't think is caused by the same reason):

There's no need for any kernel patch at all anymore (maybe a wording of mine lead to misunderstanding; sorry, English ain't my first language  :Embarassed: ).

Please remove the patch from your kernel. Emerge the lirc-0.7.0_pre7-r1 ebuild instead, which is available regularily in the portage tree. It will create the required device nodes as soon as you load the module (in my case, it's lirc_serial, don't know what's neccessary for your hauppauge remote). However, the device nodes may look different compared to the nodes created by the kernel patch (/dev/lirc/0 instead of /dev/lirc od /dev/lirc0 etc.), so you'll need to edit the /etc/conf.d/lircd file. For me, the line following did the job:

```
LIRCD_OPTS="-d /dev/lirc/0"
```

An other way of getting lirc installed is by CVS, but I wouldn't recommend when you're fine with the ebuild  :Smile: 

Let me know if you're experiencing trouble, you're welcome!

----------

## dvh

thanks for the response...will try your advice.  BTW, I aready have the lirc version you recommended installed, but I don't get the device node as you suggest.  I get a different node "/dev/lirc/lirc0".  Is this the device that the kernel patch will attempt to create?  Should I not see both?

-dvh

----------

## oscarwild

Hi dvh,

 *Quote:*   

> I am using kernel 2.6.7 with some form of lirc patch (something.2.6.5.something) and the latest lirc from portage

 

If I get you right, you're using the kernel patch AND the lirc driver from portage simultaneously? I wonder how you got both installed without an error. I could imagine, that in your case the kernel patch provides the kernel modules when the lirc daemon comes from the ebuild - and are obviously in a kind of compatibility conflict. 

What you really need, is the kernel modules as well as the lirc daemon from portage. The kernel patch basically is to provide the kernel modules for lirc, and only had been neccessary, when 0.7.0 wasn't available, but has been obsolete now for several months. Lirc 0.7.0 provides the same kernel modules (or actually newer ones), and even better, without the need to manipulate the kernel sources. I'm really wondering why there are still patches available.

So, first make sure you're using lirc 0.7.0 exclusively. No matter, if the device nodes are called /dev/lirc/lirc0 or /dev/lirc/0, the structure changed a bit, and even seems to be different between CVS and ebuild.

Simply modprobe the neccessary module (is there a lirc_hauppauge module?), check what device node has been created and respectively modify your /etc/conf.d/lircd file.

----------

## dvh

Yes, you have it rightI have both installed.  I looked through all of the directories under /lib/*kernel-name* and I have found two sets of lirc-related modulesone set is located in /lib/*kernel-name*/kernel/drivers/char/lirc, with filenames lirc_dev and lirc_i2c.  Another set (with the same filenames) is located in /lib/*kernel-name*/misc.  Those in the misc directory have a time stamp that makes me think they were created from my last emerge lirc, while the other pair looks like it came from the kernel build.  Now I have no idea which are being used.  But, if your speculation about the device node names changing slightly is true, then I must be still using the old modules, as I have not needed to change the /etc/conf.d/lircd contents.

When I get home, I will try to relocate/rename one set (probably the kernel set) and see if all still load appropriately.  BTW, these get loaded with the ivtv (PVR-250 drivers) modules as dictated by the modules.conf.  The names lirc_dev and lirc_i2c were dictated by a Hauppauge setup howto, so I think that these are the Hauppauge drivers.

Thanks again for your help.  Using a variety of (good and bad) information from many sources, I have assembled my current mythtv setup, but in this case, the result is a somewhat patchwork solution that I did not fully understand.  With your guidance, I think I finally am close to understanding this

-dvh

----------

## dvh

...update...I eliminated the kernel modules as I described above, leaving only those that appeared to be from an "emerge lirc".  As you predicted, this resulted in a different device node structure "/dev/lirc/0", and changing /etc/conf.d/lircd to indicate the correct device leads to success!

Looks like I can now build a new kernel, emerge lirc, and have a working system without patching.  Thanks again for the help.

-dvh

----------

## oscarwild

you're welcome, good luck  :Smile: 

----------

## dvh

I have built kernel 2.6.8-r3, lirc-0.7.0_pre7, and ivtv ck113a (for PVR-250), AND, I have added the latest CVS mythtv, and all appears to be working!  no need to patch anything in the above list.  I do have one remaining (somewhat confusing) issue however...maybe someone out there has a simple answer...

In theory, the ivtv module config file (/etc/modules.d/ivtv) should only require these two lines:

alias char-major-81 videodev

alias char-major-81-0 ivtv

however, my lirc does not load properly and connect with mythtv unless I also add:

alias char-major-61 lirc_i2c

add above ivtv lirc_dev lirc_i2c

These lines were required for earlier ivtv versions, but should (again, IAW other posts I have read) no longer be required.  I must be missing some other configuration that would force the lirc modules to be loaded when I need them, IF the recommendation for the ivtv config is accurate.  Does anyone have an idea of what I might be missing?

-dvh

----------

## oscarwild

Hi dvh,

I've heard about an issue with lirc and the devfs, which still might be not fully supported yet.

I can confirm, that the lirc modules are not started by the kernel autoloader as expected. As a work-around I added them (in my case: lirc_dev and lirc_serial) to /etc/modules.autoload.d/kernel-2.6.

----------

