|
From: David F. <da...@fr...> - 2007-05-01 14:33:33
|
I'm using lirc_serial / lircd, and I'm seeing strange behavior. Every
once in a while, lircd stops sending remote events to apps. This
behavior lasts for a minute or so -- then it starts working again. No
logs, no errors, nothing in dmesg.
I've run strace on it (strace -p <lircd pid>), and I can see that lircd
is getting data from /dev/lirc0 when a button is pressed on the remote
-- but it does *not* write any data out to applications waiting for
data. The machine is not particularly busy when this happens. I'm
running version 0.8.1.
So -- the questions:
Has anyone else seen this behavior?
What would be the best way to debug? I didn't see anything in the man
pages about increasing the debug level.
Should I attempt to reproduce with code from CVS?
Thanks in advance,
-Dave
--
David Frascone
...put knot yore trust inn spel chequers.
|
|
From: Jake B. <ja...@co...> - 2007-05-02 03:00:27
|
I am seeing this behaviour as well, using 0.8
captainspaulding ~ # lircd -v
lircd 0.8.0
captainspaulding ~ #
I see there is a new version of lirc :) Might have to try updating....
jake
David Frascone wrote:
> I'm using lirc_serial / lircd, and I'm seeing strange behavior. Every
> once in a while, lircd stops sending remote events to apps. This
> behavior lasts for a minute or so -- then it starts working again. No
> logs, no errors, nothing in dmesg.
>
> I've run strace on it (strace -p <lircd pid>), and I can see that lircd
> is getting data from /dev/lirc0 when a button is pressed on the remote
> -- but it does *not* write any data out to applications waiting for
> data. The machine is not particularly busy when this happens. I'm
> running version 0.8.1.
>
> So -- the questions:
> Has anyone else seen this behavior?
> What would be the best way to debug? I didn't see anything in the man
> pages about increasing the debug level.
> Should I attempt to reproduce with code from CVS?
>
> Thanks in advance,
>
>
> -Dave
>
>
--
Jacob Briggs
Systems Engineer
Core Technology Limited
Level 1, NZX Centre
11 Cable Street
Wellington
Phone +64 4 801 2252
--
object doAnythingConceivable(string whatToDo, object whatToDoItWith) { .....
|
|
From: Jake B. <ja...@co...> - 2007-05-02 01:23:33
|
I am seeing this behaviour as well, using 0.8
captainspaulding ~ # lircd -v
lircd 0.8.0
captainspaulding ~ #
I see there is a new version of lirc :) Might have to try updating....
jake
David Frascone wrote:
> I'm using lirc_serial / lircd, and I'm seeing strange behavior. Every
> once in a while, lircd stops sending remote events to apps. This
> behavior lasts for a minute or so -- then it starts working again. No
> logs, no errors, nothing in dmesg.
>
> I've run strace on it (strace -p <lircd pid>), and I can see that lircd
> is getting data from /dev/lirc0 when a button is pressed on the remote
> -- but it does *not* write any data out to applications waiting for
> data. The machine is not particularly busy when this happens. I'm
> running version 0.8.1.
>
> So -- the questions:
> Has anyone else seen this behavior?
> What would be the best way to debug? I didn't see anything in the man
> pages about increasing the debug level.
> Should I attempt to reproduce with code from CVS?
>
> Thanks in advance,
>
>
> -Dave
>
>
--
Jacob Briggs
Systems Engineer
Core Technology Limited
Level 1, NZX Centre
11 Cable Street
Wellington
Phone +64 4 801 2252
--
object doAnythingConceivable(string whatToDo, object whatToDoItWith) { .....
|
|
From: David F. <da...@fr...> - 2007-05-02 12:33:03
|
So -- confirmation that I'm not alone -- at least that's something ;)
I'll check out the cvs tree and build from source if that doesnt' fix
it, I'll start debugging.
-Dave
Jake Briggs wrote:
> I am seeing this behaviour as well, using 0.8
>
> captainspaulding ~ # lircd -v
> lircd 0.8.0
> captainspaulding ~ #
>
> I see there is a new version of lirc :) Might have to try updating....
>
> jake
>
>
> David Frascone wrote:
>> I'm using lirc_serial / lircd, and I'm seeing strange behavior.
>> Every once in a while, lircd stops sending remote events to apps.
>> This behavior lasts for a minute or so -- then it starts working
>> again. No logs, no errors, nothing in dmesg.
>>
>> I've run strace on it (strace -p <lircd pid>), and I can see that
>> lircd is getting data from /dev/lirc0 when a button is pressed on the
>> remote -- but it does *not* write any data out to applications
>> waiting for data. The machine is not particularly busy when this
>> happens. I'm running version 0.8.1.
>>
>> So -- the questions:
>> Has anyone else seen this behavior?
>> What would be the best way to debug? I didn't see anything in the
>> man pages about increasing the debug level.
>> Should I attempt to reproduce with code from CVS?
>>
>> Thanks in advance,
>>
>>
>> -Dave
>>
>>
>
--
David Frascone
A Metaphor is like a Simile.
|
|
From: David F. <da...@fr...> - 2007-05-03 13:44:47
|
This is still happening with CVS version -- any ideas where to start debugging? -Dave David Frascone wrote: > So -- confirmation that I'm not alone -- at least that's something ;) > > I'll check out the cvs tree and build from source if that doesnt' fix > it, I'll start debugging. > > -Dave > > Jake Briggs wrote: > >> I am seeing this behaviour as well, using 0.8 >> >> captainspaulding ~ # lircd -v >> lircd 0.8.0 >> captainspaulding ~ # >> >> I see there is a new version of lirc :) Might have to try updating.... >> >> jake >> >> >> David Frascone wrote: >> >>> I'm using lirc_serial / lircd, and I'm seeing strange behavior. >>> Every once in a while, lircd stops sending remote events to apps. >>> This behavior lasts for a minute or so -- then it starts working >>> again. No logs, no errors, nothing in dmesg. >>> >>> I've run strace on it (strace -p <lircd pid>), and I can see that >>> lircd is getting data from /dev/lirc0 when a button is pressed on the >>> remote -- but it does *not* write any data out to applications >>> waiting for data. The machine is not particularly busy when this >>> happens. I'm running version 0.8.1. >>> >>> So -- the questions: >>> Has anyone else seen this behavior? >>> What would be the best way to debug? I didn't see anything in the >>> man pages about increasing the debug level. >>> Should I attempt to reproduce with code from CVS? >>> >>> Thanks in advance, >>> >>> >>> -Dave >>> >>> >>> > > |
|
From: <li...@ba...> - 2007-05-03 17:17:18
|
Hi! David Frascone "da...@fr..." wrote: >>>> I'm using lirc_serial / lircd, and I'm seeing strange behavior. >>>> Every once in a while, lircd stops sending remote events to apps. >>>> This behavior lasts for a minute or so -- then it starts working >>>> again. No logs, no errors, nothing in dmesg. [...] > This is still happening with CVS version -- any ideas where to start > debugging? Here: http://www.lirc.org/html/technical.html#bugs If this is not the reason, then post your config file and mode2 data for both working and not working cases. Christoph |
|
From: David F. <da...@fr...> - 2007-05-03 17:57:10
Attachments:
lirc.tgz
|
>> This is still happening with CVS version -- any ideas where to start >> debugging? >> > > Here: http://www.lirc.org/html/technical.html#bugs > If this is not the reason, then post your config file and mode2 data for > both working and not working cases. > > Christoph > > > I do not think either of those are the problems for the following reasons: Bullet 1: I am not using lirc to transmit IR. Bullet 2: The system is not overly busy, and I do not have any IDE devices (besides a DVD rom). I guess the ethernet *could* be over-interrupting. But -- mainly this is a diskless frontend for a mythtv . . so . . if it was slamming with seconds of interrupts, the video would stop too, no? Now -- as far as config files go -- there is no difference between working and not working. Everything works great. . until it doesn't. Then for minutes, there is no response from the remote -- not even via irw. Although, strace does show events being read from the lirc device. I'm attaching the config files that I know about -- but I don't know what mode2 data is. -Dave |
|
From: <li...@ba...> - 2007-05-03 19:56:08
|
Hi! David Frascone "da...@fr..." wrote: >>> This is still happening with CVS version -- any ideas where to start >>> debugging? [...] > Bullet 1: I am not using lirc to transmit IR. > Bullet 2: The system is not overly busy, and I do not have any IDE > devices (besides a DVD rom). I guess the ethernet *could* be > over-interrupting. But -- mainly this is a diskless frontend for a > mythtv . . so . . if it was slamming with seconds of interrupts, the > video would stop too, no? No, high interrupt load might disturbe signal timings even though you don't notice any difference in system behaviour. IR timings are in micro-seconds, while you probably will only notice delays if they are in the range of milliseconds. [...] > I'm attaching the config files that I know about -- but I don't know > what mode2 data is. Run the mode2 tool. You have to stop lircd or close all lircd clients, otherwise the device will be blocked by lircd. Christoph |
|
From: David F. <da...@fr...> - 2007-05-03 20:05:16
Attachments:
mode2.out.gz
|
Christoph Bartelmus wrote: > > > Run the mode2 tool. > You have to stop lircd or close all lircd clients, otherwise the device > will be blocked by lircd. > > Do you want me to wait for a failure, then run it? Or just run it now, while it happens to be working? While working attached. -Dave |
|
From: <li...@ba...> - 2007-05-03 20:23:44
|
Hi! David Frascone "da...@fr..." wrote: [...] >> Run the mode2 tool. >> You have to stop lircd or close all lircd clients, otherwise the device >> will be blocked by lircd. >> >> > Do you want me to wait for a failure, then run it? Yes, I need to compare both cases. Christoph |
|
From: David F. <da...@fr...> - 2007-05-03 23:57:31
Attachments:
out_bad.gz
|
Attached is output from mode2 when things are *not* working Christoph Bartelmus wrote: > Hi! > > David Frascone "da...@fr..." wrote: > [...] > >>> Run the mode2 tool. >>> You have to stop lircd or close all lircd clients, otherwise the device >>> will be blocked by lircd. >>> >>> >>> > > >> Do you want me to wait for a failure, then run it? >> > > Yes, I need to compare both cases. > > Christoph > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > |
|
From: <li...@ba...> - 2007-05-04 20:51:56
|
Hi! David Frascone "da...@fr..." wrote: > Attached is output from mode2 when things are *not* working I don't see anything really bad in the output. You pressed SkipForward and Replay/SkipBackward a couple of times. lircd will decode the signals without problems. You can improve decode performance if you increase the eps value in the config file. I used 50 instead of 30. That way all signals could be decoded, otherwise some would be missed (in both good and bad cases). If you cannot come up with more information which conditions cause the problem or capture some more mode2 data which reveals the problem, then there's probably nothing I can do. Christoph |
|
From: Jake B. <ja...@co...> - 2007-05-03 22:15:48
|
Christoph Bartelmus wrote: > Here: http://www.lirc.org/html/technical.html#bugs > If this is not the reason, then post your config file and mode2 data for > both working and not working cases. > > Christoph > I am not sending IR either, and hdparm tells me that the using_dma and unmaskirq options are set on both my hdd and cdrom :( captainspaulding ~ # hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 16383/255/63, sectors = 78165360, start = 0 captainspaulding ~ # hdparm /dev/hdc /dev/hdc: IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Inappropriate ioctl for device captainspaulding ~ # lirc seems to go fine after a reboot, but after a day or two I notice that I am missing button presses :( I'll try to send the mode2 data as well :) Jake -- Jacob Briggs Systems Engineer Core Technology Limited Level 1, NZX Centre 11 Cable Street Wellington Phone +64 4 801 2252 -- object doAnythingConceivable(string whatToDo, object whatToDoItWith) { ..... |
|
From: Jake B. <ja...@co...> - 2007-05-06 22:34:02
|
Right, I feel like a right plonker. New batteries == working remote. Not saying that David Frascone doesn't have a problem, but this solved mine! I suppose that the batteries in remote last so so long, that I almost forget they are there :) I would not have thought to change them, if it were not for the fact I have a little red LED that lights up upon button press on my remote, and it was not lighting up on each button press. Sorry for wasting time! Jake Jake Briggs wrote: > Christoph Bartelmus wrote: > >> Here: http://www.lirc.org/html/technical.html#bugs >> If this is not the reason, then post your config file and mode2 data for >> both working and not working cases. >> >> Christoph >> >> > > > I am not sending IR either, and hdparm tells me that the using_dma and > unmaskirq options are set on both my hdd and cdrom :( > > captainspaulding ~ # hdparm /dev/hda > > /dev/hda: > multcount = 16 (on) > IO_support = 1 (32-bit) > unmaskirq = 1 (on) > using_dma = 1 (on) > keepsettings = 0 (off) > readonly = 0 (off) > readahead = 256 (on) > geometry = 16383/255/63, sectors = 78165360, start = 0 > captainspaulding ~ # hdparm /dev/hdc > > /dev/hdc: > IO_support = 1 (32-bit) > unmaskirq = 1 (on) > using_dma = 1 (on) > keepsettings = 0 (off) > readonly = 0 (off) > readahead = 256 (on) > HDIO_GETGEO failed: Inappropriate ioctl for device > captainspaulding ~ # > > > lirc seems to go fine after a reboot, but after a day or two I notice > that I am missing button presses :( I'll try to send the mode2 data as > well :) > > Jake > > > > -- Jacob Briggs Systems Engineer Core Technology Limited Level 1, NZX Centre 11 Cable Street Wellington Phone +64 4 801 2252 -- object doAnythingConceivable(string whatToDo, object whatToDoItWith) { ..... |