Re: funny lirc behavior

[Karl B. <ka...@tu...>]

Hi Dan,

You have the right idea.  select() is supposed to wait until some new 
data or event
takes place.  If you look in the lirc_serial.c code you will find a 
related select()
routine.  In this routine, it just looks to see if new data is in the queue.
Data is collected in the queue when an interrupt occurs.

You didn't say if you are using the homebrew serial-port hardware.  Lets 
assume you are.
Notice that when lircd gets a client, it causes the lirc_serial.c driver 
to start
using the interrupts.  You can see this by:
cat /proc/interrupts
You should see a line with lirc_serial in it, probably IRQ 4 registered and
the count of how many interrupts have come in.  This count of interrupts
you can use to troubleshoot.

Notice when everthing is working OK, that this count increases.
Does it increase when things are not working?

Notice how the /proc/interrupts entry goes away when all the lircd
clients are removed.  So lircd is causing the driver to shut down its
hardware.  When a client returns, the driver re-initializes the interrupt
and serial hardware.  This may account for the behavior you are seeing.

You may want to look over your interrupt settings.  Is any other
device sharing this interrupt?  Any odd settings relating to the serial port
or IRQ's in the BIOS setup?  You might want to try a different serial
port if you have one.  Does /proc/interrupts for lirc_serial increment
during the error condition?

If that fails, there may be some verbose settings which could be turned
on to troubleshoot further.


Karl.

Dan Eriksen wrote:

>Hello.
>
>	I would appreciate if anyone could tell me why the following might hang? This line is in the waitfordata routine.
>
>ret=select(maxfd+1,&fds,NULL,NULL,NULL);
>
>	I am thinking this is where lircd talks to the kernel module? If so, this would indicate I am having problems in the kernel module and not lircd. As you can surely tell, I am not really a coder, but I have done some.
>
>	Lircd will still remove clients and if all clients detach, it returns to return to functional operation again. As explained below, after a (seemingly) random period of time (either using or not using) lirc, it hangs on this line.
>
>Thanks,
>Dan Eriksen
>
>On Wed, 6 Mar 2002 11:36:01 -0500
>Dan Eriksen <er...@ca...> wrote:
>
>>	I have built a home-brew receiver and have been using it for about a year now. I have never had any problems with it until now. I upgraded my aging P-II 266 to an Athlon 1700+ (err... 1466Mhz) with a KT266A board. Ever since this upgrade, it has behaved funny.
>>	Lirc works fine at first, but after some time (of an app using it) it will stop reporting button presses. irw will not show anything is being pressed. As soon as I close all programs that use lirc, I can start any lirc app and it will work again (for a limited time). It's kind of hard to believe that my hardware upgrade would cause this seamingly unrelated behavior. If I run an app, but not use lirc, it will still crap-out after some time. When I press buttons more frequently (playing a DVD), it craps-out sooner.
>>	I thought that upgrading my lirc version would help (it didn't). I then did a new Linux From Scratch install (was going to happen anyways, I didn't do it to solve this problem ;), and a new install of lirc, but same problem.
>>
>>Any pointers? Thank-you for your time.
>>
>
>