On Tuesday 18 July 2006 03:44, Oliver Endriss wrote: > Oliver Endriss wrote: > > Hi, > > > > I did some tests and I can reproduce the bug with an Activy GR card... > > > > Andrew de Quincey wrote: > > > On Friday 07 July 2006 22:56, Oliver Endriss wrote: > > > > Andrew de Quincey wrote: > > > > > On Tuesday 04 July 2006 22:04, Oliver Endriss wrote: > > > > > > Andrew de Quincey wrote: > > > > > > > Sure, I reduced it to: > > > > > > > > > > > > > > saa7146_write(budget->dev, MC1, MASK_20); // DMA3 off > > > > > > > saa7146_write(budget->dev, MC1, (MASK_04 | MASK_20)); /* DMA3 > > > > > > > on */ > > > > > > > > Ok, if we cannot fix it otherwise, your patch should execute exactly > > > > these 2 lines. There should be a FIXME comment explaining why the > > > > patch has been added. I still hope that we can find the real bug. ;-) > > > > > > Yup. > > > > > > > > > Hm - this means that DMA3 has either not been started or is > > > > > > stuck. > > > > > > > > > > > > Does it make a difference if you add both lines at the end of > > > > > > start_ts_capture? > > > > > > > > > > Nope no difference. I'd already tried this by stopping+starting > > > > > dvbtraffic before I tuned... it doesn't help (I did try again tho > > > > > adding the code to the driver to make sure). > > > > > > > > > > To recap: > > > > > > > > > > 1) start dvbtraffic > > > > > > > > > > -- IRQs are received from the saa7146. > > > > Hm - does your frontend deliver garbage data while not tuned? > > My card does not generate VPE interrupts here. > > > > > > > 2) tune and lock > > > > > > > > > > -- The IRQs suddenly halt for no reason. > > > > Data transfer does not start here. Strange. > > > > > > > 3) restart dvbtraffic > > > > > > > > > > -- IRQs start again and everything works fine thereafter. > > > > Confirmed. > > > > > > > And all only the very first time DMA is started on cold boot. > > > > > > > > Very strange. I don't understand why it happens only once. > > > > > > > > Basically, it looks like an initialization problem. On the other > > > > hand, the data transfer was working and stops later. > > > > > > > > Imho this does not look like a saa7146 bug. A hw bug should show up > > > > anytime, not only once after booting. > > > > > > > > Did you check the budget->feeding stuff? At the first glance it looks > > > > strange to me that stop_ts_capture decrements budget->feeding > > > > unconditionally, while start_ts_capture checks before incrementing. > > > > > > I don't see how that would break only on a cold boot though... I can > > > reboot the machine as many times as I want after that and it works > > > perfectly every time. > > > > There might be a difference: > > The frontend might be in a different state (tuned?) during warm boot. > > > > I'll do more testing. Stay tuned. > > Please try the attached patch. It should fix your problem. > > Now DMA transfers will be started if (and only if) > - frontend has lock > - feeding > 0 > > If it works for you I will commit it to HG. Hi, glad to hear you could replicate it. Your patch works perfectly for me here. I am assuming my frontend does indeed deliver garbage since I get those IRQs. It must be being filtered out in the kernel though, because it does not end up in userspace. > > P.S.: > This patch might also fix some infamous video data stream broken errors > with vdr. yeah - I remember trying to investigate that a few years back and getting nowhere.. it sounds very similar. Here's hoping :) _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
