Hello, 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 wasting time. 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 in vdr_play if (nonblock && !FREE_COND) return -EWOULDBLOCK; _J 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? > > _J > > 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 > > > > > > >
