Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] stability problems + closing and re-opening the frontend
Hi all,
I'm trying to nail down a stability problem with the DVB drivers. My application is basically scanning all the frequencies (get them from the NIT) in loop. For each frequency, it tunes to it, setup a few filters, gather some data, check it and close the filters. After a few frequency (an average of around 100) changes, I get nasty messages like that from my kernel (dmesg):
av7110_send_fw_cmd error
av7110_fw_cmd error
__av7110_send_fw_cmd: timeout waiting for COMMAND idle
av7110_fw_request error
StartHWFilter error
av71100: ARM crashed!
av7110_fw_cmd error
av7110_fw_cmd error
The tunning and the setup of the filters doesn't return any error, but I don't get any data out of them anymore. My application timeouts and goes to the next frequency, but that doesn't help, same problem. The noise ratio is lower that usual, so I guess it's a bad tunning.
Sometimes restarting my application is enough to fix, some other times "rmmod dvb_ttpci; modprobe dvb_ttpci" helps, but sometimes I have to reboot to have my DVB card works again.
I thought it was a problem with the frontend (I open it when the application starts and keep it open), so I tried to close the frontend and re-open it before each tune. Seems like once you closed the frontend, you cannot re-open it anymore. I get "ressource busy" message when calling open, even if I put a "sleep(2)" between the close and the open. I checked using /proc/.../fd and everything is closed at that moment (even the filters). I kill my process and start it again and everything works again.
Now my questions:
1) Do you guys have any idea on how to avoid "av71100: ARM crashed!"? I'm going to write a small piece of code that reproduces that so I can give it to you.
2) What is the problem with closing the frontend and re-opening it again from the same process?
I'm using the DVB drivers from an un-patched 2.6.4 kernel (no CVS access) on a Debian "testing". The loaded modules are:
Module Size Used by
dvb_ttpci 84844 0
stv0299 12548 0
dvb_core 61972 2 dvb_ttpci,stv0299
saa7146_vv 51680 1 dvb_ttpci
saa7146 19172 2 dvb_ttpci,saa7146_vv
v4l1_compat 14276 1 saa7146_vv
v4l2_common 6144 1 saa7146_vv
videodev 9696 1 saa7146_vv
firmware_class 10112 1 dvb_ttpci
ttpci_eeprom 2816 1 dvb_ttpci
snd 55076 0
soundcore 9856 1 snd
ohci_hcd 19620 0
ehci_hcd 26948 0
matroxfb_base 31160 0
matroxfb_DAC1064 11616 1 matroxfb_base
matroxfb_accel 5184 1 matroxfb_base
cfbcopyarea 4064 1 matroxfb_accel
cfbimgblt 3136 1 matroxfb_accel
cfbfillrect 3904 1 matroxfb_accel
matroxfb_g450 7904 1 matroxfb_base
g450_pll 7104 2 matroxfb_DAC1064,matroxfb_g450
matroxfb_misc 9984 4 matroxfb_base,matroxfb_DAC1064,matroxfb_g450,g450_pll
video_buf 21124 1 saa7146_vv
uhci_hcd 32752 0
usbcore 106076 5 ohci_hcd,ehci_hcd,uhci_hcd
joydev 10048 0
evdev 9248 0
sr_mod 16036 0
cdrom 38976 1 sr_mod
ide_scsi 15172 0
parport_pc 38752 1
lp 11172 0
parport 42504 2 parport_pc,lp
dvb_ttcpi is started with the option "hw_sections=0" the rest uses the default. I need software filtering because I need more than 8 filters and the ARM was crashing at 9 filters in hardware filtering mode.
Thanks for your help.
---
-°) Patrick Valsecchi
/\\
_\_v
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.
Home |
Main Index |
Thread Index