[mythtv-users] zilog-rx-i2c high cpu usage, lirc_zilog errors

[Jarod Wilson]

On Jun 8, 2011, at 5:12 PM, Jarod Wilson wrote:

> On Jun 5, 2011, at 10:17 AM, Jarod Wilson wrote:
> 
>> On Jun 4, 2011, at 1:55 PM, Chris Payne wrote:
>> 
>>>> Things are working well, one last detail is that I am seeing high cpu usage from this related process:
>>>> 
>>>> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>> 1645 root      20   0     0    0    0 R 99.2  0.0   1238:40 zilog-rx-i2c-1
>>>> 
>>>> And some messages whenever the channel change script runs:
>>>> 
>>>> Jun  3 19:00:02 hptv lircd-0.9.0[1649]: accepted new client on /var/run/lirc/lircd1
>>>> Jun  3 19:00:02 hptv lircd-0.9.0[1649]: removed client
>>>> Jun  3 19:00:02 hptv kernel: [28087.235192] lirc_zilog: i2c_master_recv failed with -5 -- keeping last read buffer
>>>> Jun  3 19:00:02 hptv kernel: [28087.248190] lirc_zilog: i2c_master_recv failed with -5 -- keeping last read buffer
>>>> Jun  3 19:00:03 hptv lircd-0.9.0[1649]: accepted new client on /var/run/lirc/lircd1
>>>> Jun  3 19:00:03 hptv lircd-0.9.0[1649]: removed client
>>>> Jun  3 19:00:03 hptv kernel: [28088.148469] lirc_zilog: i2c_master_recv failed with -5 -- keeping last read buffer
>>>> Jun  3 19:00:03 hptv kernel: [28088.161470] lirc_zilog: i2c_master_recv failed with -5 -- keeping last read buffer
>>>> 
>>>> Which I am still investigating.
>>> 
>>> I've seen similar reported recently on the #linuxtv irc channel. Do you have
>>> just one hdpvr, or are there two? Guess I need to do some investigation, but
>>> my hdpvr recently got promoted from devel toy to being in use in my production
>>> mythtv setup, which complicates things. Maybe I should see about just getting
>>> another one...
>>> 
>>> 
>>> I have just the one HDPVR, and even though it is just a loaner for now, it has been pressed into production. (Implicit approval from the significant other, if nothing else.) I do have access in between recordings/viewings if there is anything you would like tested.
>>> 
>>> For the record, my setup is Fedora 15 with updates
>>> Was using ATrpm builds, but I had to rebuild Myth rpms from git source a couple days ago to get H.264 support capture support.
>>> 
>>> Let me know if you need anything else, thanks in advance.
>> 
>> No, that pretty well covers it. I'll have to steal my hdpvr out of production.
>> That'll be easier once the Stanley Cup Playoffs are over (its recording the
>> games that are on Versus HD), which should be RSN. I guess I could try to
>> reproduce the issue with other zilog-based hardware too... Anyway, looking at
>> this issue has been added to my TODO list.
> 
> I'm able to reproduce the problem with an hvr-1950, so I don't have to worry
> about my hdpvr now. I was talking to Andy Walls about this issue last night,
> and he reminded me of something that you can do that'll at least get rid of
> the cpu usage issue for now... Load lirc_zilog with tx_only=1, and the rx
> thread that is spinning will never get launched (this assumes of course
> that you're not using the rx portion of the hdpvr).
> 
> Anyway, digging into the problem right now to try to isolate exactly where
> its spinning.

Isolated and solved. Just a set_current_state() call that needs to
happen a touch sooner (i.e., before calling schedule_timeout()).
Will push the patch upstream shortly, with stable cc'd.

-- 
Jarod Wilson
jarod at wilsonet.com