New finding! Data_receive_error bit is indeed related to the frontend. On a non-working box, I closed the frontend, and rezaps the frontend. It gets successfully locked but still no interrupts are generated. 0x20c reads 0x100 (Data_receive_error set). Redoing the whole thing again results in the same value read at 0x20c. So my question becomes; On what conditions does FC2 set the Data_receive_error bit? But I've seen that the Data_receive_error bit being set doesn't always stop generating interrupts. In fact, most of the time it works just fine. Should we focus on stv0299.c instead of FC2 chipset? I don't know. What are the ways to recover from this state other than reloading the driver? All these questions are too hw specific, which is not described at length elsewhere, and without which I'm stuck. Q-ha. On 5/3/05, Johannes Stezenbach <js@xxxxxxxxxxx> wrote: > Q-ha Park wrote: > > Ok, I have to admit that I haven't updated the kernel and the driver > > since I have to stick with 2.4.x kernels for some time and the latest > > cvs version won't compile with 2.4. I'll probably move to the newer > > versions (or backport the latest linuxdvb to 2.4), but I want to track > > down this problem to make sure the same problem won't occur again. > > > > Actually I have some interesting register dumps common to all boxes > > with the same problem. > > > > After the flexcop chipset stopped generating interrupts even with the > > good signal status, the register 0x20c (Status register : reading this > > register deasserts INTA) is read 0x00000100 (Data_receive_error). But > > shouldn't this register have been already cleared in the interrupt > > handler? Is this normal that this bit can be still set and the > > interrupt is not generated? All 8 boxes I tested resulted in the same > > register values on 0x20c. And reading this register didn't make the > > flexcop to generate interrupts again. > > > > Is there anything I could do to debug it further (in both s/w and h/w wise)? > > The description of the Data_receive_error bit says that it is an error > in the frontend, but the frontend is completely reinitialized > when you close the device, wait dvb_shutdown_timeout seconds (default: 5), > and then reopen it. So more likely the error is in the TS-interface > of the Flexcop. > > Can you check if register 0x214 (TS input config) changes between > the working/non-working state? > > If that's not it, then we may need to reset the TS interface. I don't > know how, though, maybe we need to ask btti for help. > > Johannes >
