[linux-dvb] Re: we might be losing multicast packets
jhall at maoz.com
Mon Feb 14 11:27:19 CET 2005
I commented all of the locations in which it was safe to do so where
EAGAIN was returned in the driver either by EAGAIN or EWOULDBLOCK. There
are some places where I didn't mark because to do so might impact
functionality or cause a hefty rewrite of the code and introduction of new
variables. It would help to know where the section filtering code is
because if I need to rewrite something for debugging I don't want to be
On a probably unrelated note, I happened to have this modified driver
running while using vdr and consistently saw a marker in av7110_av.c
if (nonblock && !FREE_COND)
In the new year, Jeremy Hall wrote:
> oh I know the group is correct etc.
> I'm looking, but don't see an fcntl call, for example, right now there is
> nothing being transmitted on the group, and so my app is sitting waiting
> for data on a read call. It will continue to sit there until data packets
> are ready.
> I remember a similar discussion about returning EAGAIN because we had just
> seen a buffer overflow, but I don't remember all the specifics. When is
> it acceptable to return EAGAIN when not using nonblocking i/o?
> In the new year, Johannes Stezenbach wrote:
> > Jeremy Hall wrote:
> > > On a different stream, no matter what the RECV buffer size is, I get
> > >
> > > recvfrom: resource temporarily unavailable
> > Well, that's hardly a DVB related error when you read from a network
> > socket. EAGAIN means you are using O_NONBLOCK and there is no data.
> > > and now when I look at my ifconfig stats, I see that there are 3 errors,
> > > all three of them framing errors, although I have seen resource
> > > temporarily unavailable many more times than 3.
> > If ifconfig shows incoming packets, but your app is not getting any,
> > then maybe the address is wrong or something. Try tcpdump.
> > Johannes
More information about the linux-dvb