Regarding the packet loss problem I wrote back to Eutelsat later on last
year after I implemented the fix in the fidbirq routine which
eliminated packet loss problems (at least for one other who reported
it, see mailing list archive in May 2002).
The 0.9.4 drivers (they are from late 2001) of course never had that fix.
That fix originally only was in the old CVS at Convergence and later our
drivers at www.metzlerbros.de.
So I should try getting your drivers from www.metzlerbros.de working ?
You might have read about the fiddling around in the IRQ routine during the last few weeks. Maybe you have more luck with one of those.yes. Are you talking about "[linux-dvb] vpeirq() instead of fidbirq()" ? But I don't know how to use that. Maybe someone else working on that can help me out.
Some don't make much sense (i.e. they do not fix the original
problem). The one using the VPE interrupt sounds most promising but I did not try it myself yet.
> >How high is your data rate?We have our own PID. It can go higher of course with more $$$. But today, it's 256kb/s.
> >
> "How low" you mean. We rent a dedicated 256kb/s rate from eutelsat for > sending our file around. Not that high.
How high is the data rate on the PID you use? I mean the complete PID, not just your part.
> Do you know what this is ? While I'm sending data (or a little after the > data is received) my PC crashes, blinking leds, and all... (sorry for > posting this again).
> > [...]
> [<d88dc664>] StartHWFilter [dvb-ttpci] 0xd4
> [<d88a1db9>] dvb_net_filter_set [dvb-core] 0x360
Yes, that bug is known.
set_multicast_list() in network drivers is called during IRQ.
The sleeping in calls to the ARM causes the crash.
The cleanest way to solve this would be by using the interruptible work queues of the newer 2.5.x kernels.
AFAIK, in 2.4.x there is only one interruptible task queue which is
shared with all other processes. Maybe here a "network multicast filter setting thread" would be better.
Ooow ! That's chineese for me... lol. But I get the idea.
Okay.Btw., this bug also can occur in other drivers, since functions in dvb_sw_demux.c can go to sleep when waiting for a semaphore.