Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#10318 closed Bug Report - General (Invalid)

Mythbackend-tuner communication locks up on HVR-2250

Reported by: Bob Williams <bob.williams@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - ATSC Version: 0.24-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Sporadically and infrequently, a scheduled recording will start successfully then fail during a recording. From that point forward, mythbackend cannot communicate with either tuner in the Hauppauge HVR-2250 until powerdown. The syslog message is "Event timed out". Subsequent recordings while power remains on, cannot start and so also fail. Even if only one tuner is used/active, both tuners stop communications. Mythbackend continues running just fine performing tasks except for accessing the tuner.

This problem usually seems to happen when a station seriously fades out. Less frequently it seems to happen on strong stations - but even a strong signal could have a dropout. The frustrating aspect of this problem is reproducing it more frequently. I have tried disconnecting/reconnecting the antenna and using a poor hand held antenna where I can make the signals easily drop out, but I cannot seem to reliably induce the problem. Some channels seem more susceptible. I live in the San Francisco Bay Area and channels 22.1 and 42.3 are my usual choices for showing the problem the quickest. I record about 4 hours per day of OTA ATSC, and see this failure about once per week or two. When I choose 22.1 or 42.3 I sometimes have failures withing 10 minutes but it often takes hours.

Once locked up, I have tried stopping mythbackend with initctl then running dvb-apps tools like azap which also fail as they cannot communicate with the tuner. Stopping, then starting mythbackend with initctl does not make the problem go away. I have discovered no other way to restore tuner communcation other than powerdown. I have noticed this problem since the initial installation.

As I was suspicious of the LinuxTV saa7164 driver, I tried the dvb-apps tools (after power-on) each in separate terminals (as follows) but I have NEVER seen a failure, despite many dropouts in the logs and many recorded hours:

azap -r ThisTV | tee t0.log

azap -a 1 -r KRCB-DT | tee t1.log

cp /dev/dvb/adapter0/dvr0 t0.mpg

cp /dev/dvb/adapter1/dvr0 t1.mpg

Because of this behavior, I'm submitting this to MythTV first, even though I understand it could be in the drivers. Another possibility is that the Hauppauge 2250 on-board firmware, loaded during wake-up, has failed, but I haven't figured out how to check its status.

I have written a mini logic analyzer (C code) and redirected the rsyslogd to it so I can capture a substantial log of the failure around the event; these are attached. I also turned on the debug flags for saa7164, s5h1411, and tda18271 modules.

Please let me know if I can assist you with more information, log files or help. I'd be happy to run more tests here or try something out. I suspect this may not be an easy problem to track down and fix.

I love my MythTV and I hope the problem can be resolved. Thanks, -Bob Williams

attachments:

system_info.txt - my system hardware/software/usage.

trace3_be_fe_2ch.gz & trace4_be_fe_2ch.gz - syslog failure cases using mythbackend.

traceOK_azap_2ch.gz - syslog using azap - I can't make this fail.

Attachments (4)

system_info.txt (1.2 KB) - added by Bob Williams <bob.williams@…> 12 years ago.
System hardware, software and usage information
trace3_be_fe_2ch.bz2 (142.4 KB) - added by Bob Williams <bob.williams@…> 12 years ago.
Failure case #1, mythbackend, syslog with extra debug info
trace4_be_fe_2ch.bz2 (161.1 KB) - added by Bob Williams <bob.williams@…> 12 years ago.
Failure case #2, mythbackend, syslog with extra debug info
traceOK_azap_2ch.bz2 (138.9 KB) - added by Bob Williams <bob.williams@…> 12 years ago.
Case using azap, syslog with extra debug info, can't get to fail, ever

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by Bob Williams <bob.williams@…>

Attachment: system_info.txt added

System hardware, software and usage information

Changed 12 years ago by Bob Williams <bob.williams@…>

Attachment: trace3_be_fe_2ch.bz2 added

Failure case #1, mythbackend, syslog with extra debug info

Changed 12 years ago by Bob Williams <bob.williams@…>

Attachment: trace4_be_fe_2ch.bz2 added

Failure case #2, mythbackend, syslog with extra debug info

Changed 12 years ago by Bob Williams <bob.williams@…>

Attachment: traceOK_azap_2ch.bz2 added

Case using azap, syslog with extra debug info, can't get to fail, ever

comment:1 Changed 12 years ago by beirdo

You might need to use master rather than 0.24. I don't remember when we tweaked the code for better support, but I haven't had any issues with my HVR-2250 in at least a year that I can recall.

comment:2 Changed 12 years ago by Bob Williams <bob.williams@…>

I have more information but I'm still not able to find a reliable way to replicate this problem I'm seeing. This problem may have nothing to do with weak/fading signals as I can see it on stronger channels. But it is still rare.

After looking at many more debug outputs, I have found that what happens is all interrupts from the saa7164 seem to mysteriously stop - at least the deferred interrupt handler is never called and the saa7164 in /proc/interrupts no longer advances. Is there a way to check for masked interrupts? The saa7164 command/data ring buffers continue to operate normally after this with read/write pointers advancing except for the get-ring read pointer as no interrupt is seen to drain the buffer in the driver.

I noticed that MythTV uses open/poll/read for getting dvr0 data so I wrote my own "copy" program using polling similarly for use in place of "cp" when using azap. But I still can't get the azap method to fail.

I will continue to examine stuff. It is painful for me to do a build/compile but maybe I'll get to that at some point, maybe on a new partition or using chroot (I'm far from an expert in this). Once again, if you have suggestions on things I can look at or do, please let me know. I know you really need a way to reproduce this but I haven't found it yet - not giving up.

comment:3 Changed 12 years ago by danielk

Resolution: Invalid
Status: newclosed

Bob, I've found a that while sometimes a little painful in the wallet, switching motherboard manufacturers can be an effective way to avoid interrupt problems.

I'm closing this as invalid as it appears to be either a kernel driver bug or hardware bug, rather than a MythTV bug.

comment:4 Changed 12 years ago by Bob Williams <bob.williams@…>

So I finally found the problem. It has nothing to do with MythTV as you suspect. The problem was in the NVidia ION driver. Versions before 275.19 have a potential pci interrupt problem as identified in a changelog. I'm posting this only in case someone else finds this useful.

Note: See TracTickets for help on using tickets.