lircd / irw 100% CPU

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

lircd / irw 100% CPU

Craig Treleaven
Hi:

I’m trying to test lirc on OS X.  I’m using an HDHomerun Dual as the receiver which forwards IR over UDP.  I’ve used essentially this setup with MythTV and lirc 0.9.0 for several years.  However, irw only shows 1 or 2 button presses.  The lircd daemon jumps from using 0% CPU to 100% of a core.

craigtreleaven$ irw
000040040d00010c 00 MENU veq2249
000040040d00010c 01 MENU veq2249
^C


I’ve tried various options to get more detail in the logs ( loglevel = trace2 in lirc_options.conf, etc) but I’m not seeing anything helpful.

from lircd.log:
Oct  4 17:15:31.233111 CT-MBP11.local lircd: Info: lircd:  Opening log, level: Info
Oct  4 17:15:31.250710 CT-MBP11.local lircd: Info: Initial device: 5000
Oct  4 17:15:31.250763 CT-MBP11.local lircd: Info: Initial device: 5000
Oct  4 17:15:31.250803 CT-MBP11.local lircd: Info: lircd:  Opening log, level: Info
Oct  4 17:15:31.252900 CT-MBP11.local lircd: Notice: Running as user _lirc
Oct  4 17:15:31.253077 CT-MBP11.local lircd: Info: Using remote: veq2249.
Oct  4 17:15:31.253489 CT-MBP11.local lircd: Notice: lircd(udp) ready, using /opt/local/var/run/lirc/lircd
Oct  4 17:15:36.298895 CT-MBP11.local lircd: Notice: accepted new client on /opt/local/var/run/lirc/lircd
Oct  4 17:16:52.119626 CT-MBP11.local lircd: Notice: caught signal


I’d be grateful for suggestions on how to debug this.

Craig


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 04/10/16 23:25, Craig Treleaven wrote:
> Hi:
>
> I’m trying to test lirc on OS X.  I’m using an HDHomerun Dual as the receiver which forwards IR over UDP.  I’ve used essentially this setup with MythTV and lirc 0.9.0 for several years.  However, irw only shows 1 or 2 button presses.  The lircd daemon jumps from using 0% CPU to 100% of a core.
>
> craigtreleaven$ irw
> 000040040d00010c 00 MENU veq2249
> 000040040d00010c 01 MENU veq2249
> ^C

Hm... the first step would be to use mode2(1) (with the udp driver) to
check if it returns something reasonable. See the configuration guide.

The 100% load is definitely sign of an error. The basic problem is that
more and more of the basic IR device handling is moved into the LInux
kernel, which by definition  isn't portable.

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven
> On Oct 5, 2016, at 11:48 AM, Alec Leamas <[hidden email]> wrote:
>
> On 04/10/16 23:25, Craig Treleaven wrote:
>> Hi:
>>
>> I’m trying to test lirc on OS X.  I’m using an HDHomerun Dual as the receiver which forwards IR over UDP.  I’ve used essentially this setup with MythTV and lirc 0.9.0 for several years.  However, irw only shows 1 or 2 button presses.  The lircd daemon jumps from using 0% CPU to 100% of a core.
>>
>> craigtreleaven$ irw
>> 000040040d00010c 00 MENU veq2249
>> 000040040d00010c 01 MENU veq2249
>> ^C
>
> Hm... the first step would be to use mode2(1) (with the udp driver) to
> check if it returns something reasonable. See the configuration guide.
>
> The 100% load is definitely sign of an error. The basic problem is that
> more and more of the basic IR device handling is moved into the LInux
> kernel, which by definition  isn't portable.

OK, mode2 seems to work using my lirc_options.conf file:

$ mode2
Using driver udp on device 5000
Trying device: 5000
Using device: 5000
space 499712
pulse 3477
space 1647
pulse 488
space 427
pulse 427
space 1281


I pressed a dozen buttons and got hundreds of lines of output.  CPU usage for mode2 was zero afterwards.

I used a tool on MacOS (Activity Monitor >> sample) to look at where lircd was spending it’s time.  It appears it is in a tight loop calling libsystem_kernel.dylib.  Is it maybe trying to read data from UDP that has already been retrieved?  I can supply the reports that were produced if you’d like.

Craig


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 05/10/16 19:04, Craig Treleaven wrote:
>> On Oct 5, 2016, at 11:48 AM, Alec Leamas <[hidden email]> wrote:
>>
>> On 04/10/16 23:25, Craig Treleaven wrote:

>
> OK, mode2 seems to work using my lirc_options.conf file:
>

>
> I pressed a dozen buttons and got hundreds of lines of output.  CPU usage for mode2 was zero afterwards.
>
> I used a tool on MacOS (Activity Monitor >> sample) to look at where lircd was spending it’s time.  It appears it is in a tight loop calling libsystem_kernel.dylib.  Is it maybe trying to read data from UDP that has already been retrieved?  I can supply the reports that were produced if you’d like.
>

This is hairy, MacOS stuff. Just from the name of the function one might
guess it's something  related to the dynamic loading of the driver. But
it's just a shot in the dark.

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven
> On Oct 6, 2016, at 1:37 AM, Alec Leamas <[hidden email]> wrote:
>
> On 05/10/16 19:04, Craig Treleaven wrote:
>>> On Oct 5, 2016, at 11:48 AM, Alec Leamas <[hidden email]> wrote:
>>>
>>> On 04/10/16 23:25, Craig Treleaven wrote:
>
>>
>> OK, mode2 seems to work using my lirc_options.conf file:
>>
>
>>
>> I pressed a dozen buttons and got hundreds of lines of output.  CPU usage for mode2 was zero afterwards.
>>
>> I used a tool on MacOS (Activity Monitor >> sample) to look at where lircd was spending it’s time.  It appears it is in a tight loop calling libsystem_kernel.dylib.  Is it maybe trying to read data from UDP that has already been retrieved?  I can supply the reports that were produced if you’d like.
>>
>
> This is hairy, MacOS stuff. Just from the name of the function one might guess it's something  related to the dynamic loading of the driver. But it's just a shot in the dark.

Following is a portion of the output from Activity Monitor’s sampling (while the CPU was pegged):

Call graph:
    2653 Thread_8537947   DispatchQueue_1: com.apple.main-thread  (serial)
      2593 start  (in libdyld.dylib) + 1  [0x7fff9395f5c9]
      + 2593 main  (in lircd) + 1329  [0x10e9c4fd4]
      +   2304 poll  (in libsystem_kernel.dylib) + 10,0  [0x7fff919505c2,0x7fff919505b8]

Of 2653 samples taken, the current function was poll in 2304 cases.  In daemons/lircd.cpp, I see poll called at line 402 (0.9.4 branch).  I’m functionally illiterate in c++ and don’t know how this code works.  Could it be related though?


Also I saw in the man page for irw that it does essentially the same as netcat. However, I get the following error trying to use netcat:

$ nc -u /opt/local/var/run/lirc/lircd
/opt/local/var/run/lirc/lircd: forward host lookup failed: Unknown host

Not sure what this means.  The socket is there:

$ sudo ls -al /opt/local/var/run/lirc/lircd
Password:
srw-rw-rw-  1 root  admin  0  7 Oct 08:24 /opt/local/var/run/lirc/lircd

Thanks for all your help.

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 07/10/16 15:09, Craig Treleaven wrote:

> Of 2653 samples taken, the current function was poll in 2304 cases.  In daemons/lircd.cpp, I see poll called at line 402 (0.9.4 branch).  I’m functionally illiterate in c++ and don’t know how this code works.  Could it be related though?

Somehow, yes. poll() is a kernel call, which  basically blocks until
there is input available (similar to read, but can wait for data at more
than one socket). However, the poll() call is assumed to sleep until
there is data, so that should not be the cause of any  100% load. I
actually find some hints that macos isn't that good at handling tight
poll() loops, but I can't say it's a fact.

Can you see if the 100% load is in userspace or in kernel?


> Also I saw in the man page for irw that it does essentially the same as netcat. However, I get the following error trying to use netcat:
>
> $ nc -u /opt/local/var/run/lirc/lircd
> /opt/local/var/run/lirc/lircd: forward host lookup failed: Unknown host

the lower-case -u switch is for using udp. You want uppercase -U, for
the unix socket ;)


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven

> On Oct 7, 2016, at 11:37 AM, Alec Leamas <[hidden email]> wrote:
>
>
>
> On 07/10/16 15:09, Craig Treleaven wrote:
>
>> Of 2653 samples taken, the current function was poll in 2304 cases.  In daemons/lircd.cpp, I see poll called at line 402 (0.9.4 branch).  I’m functionally illiterate in c++ and don’t know how this code works.  Could it be related though?
>
> Somehow, yes. poll() is a kernel call, which  basically blocks until there is input available (similar to read, but can wait for data at more than one socket). However, the poll() call is assumed to sleep until there is data, so that should not be the cause of any  100% load. I actually find some hints that macos isn't that good at handling tight poll() loops, but I can't say it's a fact.
>
If poll is being called with a zero sleep timeout (or a very small interval), that would lead to the tight loop, no?  As I mentioned earlier, lircd uses 0% CPU until the first keypress on the remote and then uses 100% afterwards.  Could it be that the timeout interval is getting clobbered after the first poll returns with data?  There is a comment in the code about the timeout but I’m not sure how to interpret it.  

The read_timeout function, that calls poll(), seems to be used in 3 different spots

1) in get_peer_message with timeout = 0
2) twice in  get_command.  First with timeout = 0 and then with timeout = 5

Strange, I would have expected timeout to be -1 somewhere?!?

> Can you see if the 100% load is in userspace or in kernel?
>
Sorry, I don’t know how to do this.  How would you do it on Linux?  Maybe I can find an OS X equivalent.

>
>> Also I saw in the man page for irw that it does essentially the same as netcat. However, I get the following error trying to use netcat:
>>
>> $ nc -u /opt/local/var/run/lirc/lircd
>> /opt/local/var/run/lirc/lircd: forward host lookup failed: Unknown host
>
> the lower-case -u switch is for using udp. You want uppercase -U, for the unix socket ;)

Ah, my version doesn’t like -U:

n$ nc -U /opt/local/var/run/lirc/lircd
nc: illegal option -- U
nc -h for help

I see there are a couple of ‘super-charged’ version of netcat.  Is it worth installing another?

Thanks again,

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 07/10/16 18:25, Craig Treleaven wrote:

> The read_timeout function, that calls poll(), seems to be used in 3 different spots
>
> 1) in get_peer_message with timeout = 0
> 2) twice in  get_command.  First with timeout = 0 and then with timeout = 5
>
> Strange, I would have expected timeout to be -1 somewhere?!?

As things are defined, 0 means "wait forever". This is rather well
tested and should not be a problem.

>> Can you see if the 100% load is in userspace or in kernel?
> Sorry, I don’t know how to do this.  How would you do it on Linux?  Maybe I can find an OS X equivalent.

On linux the time command displays total, userspace and kernel time.

> I see there are a couple of ‘super-charged’ version of netcat.  Is it worth installing another?

Not really, as long as mode2 works as excpected.

According to [1], the macos version of poll() has been broken. No idea
what this means. This could be a problem, since one of the changes
between 0.9.0 and 0.9.4 is that select() has been replaced by poll()
because of other problems w select().



Cheers!

--alec

[1] https://daniel.haxx.se/docs/poll-vs-select.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven

> On Oct 7, 2016, at 12:38 PM, Alec Leamas <[hidden email]> wrote:
>
>
>
> On 07/10/16 18:25, Craig Treleaven wrote:
>
>> The read_timeout function, that calls poll(), seems to be used in 3 different spots
>>
>> 1) in get_peer_message with timeout = 0
>> 2) twice in  get_command.  First with timeout = 0 and then with timeout = 5
>>
>> Strange, I would have expected timeout to be -1 somewhere?!?
>
> As things are defined, 0 means "wait forever". This is rather well tested and should not be a problem.
>

From my man page for poll:

"If timeout is greater than zero, it specifies a maximum interval (in milliseconds) to wait for any file descriptor to become ready.  If timeout is zero, then poll() will return without blocking. If the
     value of timeout is -1, the poll blocks indefinitely."


>>> Can you see if the 100% load is in userspace or in kernel?
>> Sorry, I don’t know how to do this.  How would you do it on Linux?  Maybe I can find an OS X equivalent.
>
> On linux the time command displays total, userspace and kernel time.
>
OK.  Unfortunately we’re going away for the weekend and it will probably be Monday before I can give this a try.

>> I see there are a couple of ‘super-charged’ version of netcat.  Is it worth installing another?
>
> Not really, as long as mode2 works as excpected.
>
> According to [1], the macos version of poll() has been broken. No idea what this means. This could be a problem, since one of the changes between 0.9.0 and 0.9.4 is that select() has been replaced by poll() because of other problems w select().
>
>
>
> Cheers!
>
> --alec
>
> [1] https://daniel.haxx.se/docs/poll-vs-select.html

That link refers to OS X 10.3 and 10.4: ~10 years ago!  Hard to believe it would be left “broken” for all that time.

Craig


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 07/10/16 19:15, Craig Treleaven wrote:

>
>> On Oct 7, 2016, at 12:38 PM, Alec Leamas <[hidden email]> wrote:
>
>>
>> As things are defined, 0 means "wait forever". This is rather well tested and should not be a problem.
>>
>
> From my man page for poll:
>
> "If timeout is greater than zero, it specifies a maximum interval (in milliseconds) to wait for any file descriptor to become ready.  If timeout is zero, then poll() will return without blocking. If the
>      value of timeout is -1, the poll blocks indefinitely."

Indeed. However, the read_timeout() code maps a 0 timeout argument to a
a -1 poll() one (this is because we used to use select() which have
other definitions, and kept the read_timeout interface stable).

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Kyle McKay-4
In reply to this post by Craig Treleaven
On October 7, 2016 23:51:12 PDT, Alec Leamas wrote:

> On 07/10/16 19:15, Craig Treleaven wrote:
>>
>>> On Oct 7, 2016, at 12:38 PM, Alec Leamas <[hidden email]>  
>>> wrote:
>>
>>>
>>> As things are defined, 0 means "wait forever". This is rather well  
>>> tested and should not be a problem.
>>>
>>
>> From my man page for poll:
>>
>> "If timeout is greater than zero, it specifies a maximum interval  
>> (in milliseconds) to wait for any file descriptor to become ready.  
>> If timeout is zero, then poll() will return without blocking. If the
>>     value of timeout is -1, the poll blocks indefinitely."
>
> Indeed. However, the read_timeout() code maps a 0 timeout argument  
> to a a -1 poll() one (this is because we used to use select() which  
> have other definitions, and kept the read_timeout interface stable).

This may be of interest.  From the Mac man page for poll:

> BUGS
>      The poll() system call currently does not support devices.

You can't use poll with devices on Mac OS X.  You can see for yourself  
at [1].

--Kyle

[1] <https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/poll.2.html 
 >

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 09/10/16 10:30, Kyle J. McKay wrote:
> On October 7, 2016 23:51:12 PDT, Alec Leamas wrote:

>
> This may be of interest.  From the Mac man page for poll:
>
>> BUGS
>>      The poll() system call currently does not support devices.
>
> You can't use poll with devices on Mac OS X.  You can see for yourself
> at [1].

Indeed... What do you think, would reverting to select(2) work? I don't
see the corresponding note in that manpage?

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Kyle McKay-4
On Oct 9, 2016, at 01:45, Alec Leamas wrote:

> On 09/10/16 10:30, Kyle J. McKay wrote:
>> On October 7, 2016 23:51:12 PDT, Alec Leamas wrote:
>
>>
>> This may be of interest.  From the Mac man page for poll:
>>
>>> BUGS
>>>     The poll() system call currently does not support devices.
>>
>> You can't use poll with devices on Mac OS X.  You can see for  
>> yourself
>> at [1].
>
> Indeed... What do you think, would reverting to select(2) work? I  
> don't see the corresponding note in that manpage?

The last time I played with lirc on Mac OS X was with lirc-0.8.6.  It  
built and ran just fine and talked to my USB IR device with no issues  
whatsoever.  I presume that version was still using select?  However,  
since it was a USB device, was the select/poll code even involved?

But yes, select works just fine on devices on Mac OS X (or macOS or OS  
X or whatever nom-du-jour you like for it ;).

I previously submitted a patch [1] for squishyball [2] that switched  
it from poll to select when __APPLE__ is defined in order to get it  
working on Mac OS X, so I suspect doing the same thing will also work  
fine for lirc.

--Kyle

[1] <https://trac.xiph.org/changeset?new=18873%40trunk%2Fsquishyball&old=18872%40trunk%2Fsquishyball 
 >
[2] https://directory.fsf.org/wiki/Squishyball

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 09/10/16 12:10, Kyle J. McKay wrote:
> On Oct 9, 2016, at 01:45, Alec Leamas wrote:
>>> Indeed... What do you think, would reverting to select(2) work? I
>> don't see the corresponding note in that manpage?
>
> The last time I played with lirc on Mac OS X was with lirc-0.8.6.  It
> built and ran just fine and talked to my USB IR device with no issues
> whatsoever.  I presume that version was still using select?  However,
> since it was a USB device, was the select/poll code even involved?

Short answer: yes:

> But yes, select works just fine on devices on Mac OS X (or macOS or OS X
> or whatever nom-du-jour you like for it ;).

So, it seems we have a plan. One question: What exactly is 'devices' in
this context?

Currently, there is 18 poll() calls in various parts, while trivial it's
still some work. Also, the root cause for the change was some segfaults
for devices > 1024 inn lircrcd; if possible, I'd prefer to use poll here.

> I previously submitted a patch [1] for squishyball [2] that switched it
> from poll to select when __APPLE__ is defined in order to get it working
> on Mac OS X, so I suspect doing the same thing will also work fine for
> lirc.

Since we have the old code available, it might be possible to revert.
Will file a bug to track this issue.


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Kyle McKay-4
On Oct 9, 2016, at 04:24, Alec Leamas wrote:

> So, it seems we have a plan. One question: What exactly is 'devices'  
> in this context?

I believe that Mac OS X poll works on sockets, pipes and regular files  
and does not work on any character device at all (such as a serial  
port).

> Currently, there is 18 poll() calls in various parts, while trivial  
> it's still some work. Also, the root cause for the change was some  
> segfaults for devices > 1024 inn lircrcd; if possible, I'd prefer to  
> use poll here.

You might be stuck with #ifdef __APPLE__ in some places.  From the  
select man page:

> COMPATIBILITY
>      select() now returns with errno set to EINVAL when nfds is  
> greater
>      than FD_SETSIZE.  Use a smaller value for nfds or compile with
>      -D_DARWIN_UNLIMITED_SELECT.

To support greater than FD_SETSIZE (which is 1024 on Darwin) nfds, the  
_DARWIN_UNLIMITED_SELECT define must be set when compiling and either  
FD_SETSIZE defined larger as well or a suitably large enough array of  
int32_t cast to an (fd_set *) must be used with the various FD_XXX  
macros.

On the other hand, it may not be necessary to support nfds > 1024 on  
Darwin in which case the EINVAL result should take care of it.  
Besides, select is probably not very efficient with large nfds values  
anyway.

> Since we have the old code available, it might be possible to  
> revert. Will file a bug to track this issue.

It looks to me like 0.9.3 was the first release that switched the  
daemons from select to poll and 0.9.4 was the first release that  
switched the plugins from select to poll.  Is that correct?

--Kyle

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven
In reply to this post by Alec Leamas
> On Oct 9, 2016, at 7:24 AM, Alec Leamas <[hidden email]> wrote:
>
> Since we have the old code available, it might be possible to revert.
> Will file a bug to track this issue.
>
I can apply patches and test with my UDP setup.  Let me know how I can help.

Craig

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven
In reply to this post by Alec Leamas
> On Oct 9, 2016, at 7:24 AM, Alec Leamas <[hidden email]> wrote:
>
> On 09/10/16 12:10, Kyle J. McKay wrote:
> ...
>> But yes, select works just fine on devices on Mac OS X (or macOS or OS X
>> or whatever nom-du-jour you like for it ;).
>
> So, it seems we have a plan. One question: What exactly is 'devices' in
> this context?
>
> Currently, there is 18 poll() calls in various parts, while trivial it's
> still some work. Also, the root cause for the change was some segfaults
> for devices > 1024 inn lircrcd; if possible, I'd prefer to use poll here.
>
>> I previously submitted a patch [1] for squishyball [2] that switched it
>> from poll to select when __APPLE__ is defined in order to get it working
>> on Mac OS X, so I suspect doing the same thing will also work fine for
>> lirc.
>
> Since we have the old code available, it might be possible to revert.
> Will file a bug to track this issue.

Thinking about this a little…

On Mac, none of the Linux kernal drivers are ever going to be accessible.  The only devices that are currently thought to work are:

1) UDP such as from the older HDHomerun models
2) Network (believed to work)
3) IguanaIR (used to work, no reports in several years)
4) SonyIR (based on commits last year adding support)

I don’t know all the places you are seeing poll() calls, but I would think that a bunch of them have to be irrelevant on the Mac operating system.

Hope this helps to pare down the work.

Craig


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 12/10/16 14:57, Craig Treleaven wrote:
 >> On Oct 9, 2016, at 7:24 AM, Alec Leamas <[hidden email]> wrote:
 >>
 >> On 09/10/16 12:10, Kyle J. McKay wrote:
 >> ...
 >>> But yes, select works just fine on devices on Mac OS X (or macOS or
OS X
 >>> or whatever nom-du-jour you like for it .

Found [1] which seems to sort out this situation  (?)

 > Thinking about this a little…
 >
 > On Mac, none of the Linux kernal drivers are ever going to be
accessible.  The only devices that are currently thought to work are:
 >
 > 1) UDP such as from the older HDHomerun models
 > 2) Network (believed to work)
 > 3) IguanaIR (used to work, no reports in several years)
 > 4) SonyIR (based on commits last year adding support)

Enclosing a patch [2] reverting some (not all) uses of poll, using the
old 0.9.2 code. I have no idea if this might work, here are all sorts of
dragons, part of the code (notably in lircd.cpp) is extremely hairy.
That said:
   - This patch is not acceptable upstream, you will need to maintain it
     downstream if it solves the macos problem.
   - A proper fix would be to add some kind of common abstraction for
     poll()/select. The really proper fix would be that apple fixed
     their poll().
   - Many drivers are not patched, see the patch comment.


Cheers!

--alec

[1] https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
[2] http://paste.fedoraproject.org/450338/14765103

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Alec Leamas


On 15/10/16 07:55, Alec Leamas wrote:

>
> Enclosing a patch [2] reverting some (not all) uses of poll,

The patch contained some cruft. Updated patch:
http://paste.fedoraproject.org/450343/76511161


--cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lircd / irw 100% CPU

Craig Treleaven
> On Oct 15, 2016, at 2:01 AM, Alec Leamas <[hidden email]> wrote:
>
> On 15/10/16 07:55, Alec Leamas wrote:
>
>>
>> Enclosing a patch [2] reverting some (not all) uses of poll,
>
> The patch contained some cruft. Updated patch: http://paste.fedoraproject.org/450343/76511161

I was able to apply the patch cleanly but my build now fails running ‘data2hwdb’.  I hope I’ve pasted the relevant portion to:

http://paste.fedoraproject.org/450511/76538762/

Does LIRC support parallel make?

Thanks for your help so far.

Craig
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
12
Loading...