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: | 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)
Change History (8)
Changed 12 years ago by
Attachment: | system_info.txt added |
---|
Changed 12 years ago by
Attachment: | trace3_be_fe_2ch.bz2 added |
---|
Failure case #1, mythbackend, syslog with extra debug info
Changed 12 years ago by
Attachment: | trace4_be_fe_2ch.bz2 added |
---|
Failure case #2, mythbackend, syslog with extra debug info
Changed 12 years ago by
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
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
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
Resolution: | → Invalid |
---|---|
Status: | new → closed |
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
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.
System hardware, software and usage information