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