[linux-dvb] Re: Resource temporarily unavailable

[Ralph Metzler <rjkm@convergence.de>]

Karim Amrani writes:
 > I'm experiencing the 'Resource temporarily unavailable' problem too... 
 > (from time to time).
 > 
 > I'm running some test software (reading for ever packets from a PID and 
 > thus, checking the broadcast is OK) on a linux box (RH 7.1/ kernel 2.4.10 / 
 > PIII 450 MHz / 64 Mo RAM). The test program writes nothing on the disk (no 
 > recording).
 > I'm using a Hauppauge win TV DVB-S (second release) with driver version 0.9.

Which 0.9 version? Please also try the CVS release.
The normal DVB-s (not the Nova) can easily stop transmitting section
data if the data rate is too high and the internal buffers overflow. 
In newer firmwares I improved the recovery mechanism. 

 
 > In my case, the errno associated with the perror message 'Resource 
 > temporarily unavailable' is not EWOULDBLOCK but EAGAIN (value is 11).

>From /usr/src/linux/include/asm/errno.h:

#define	EWOULDBLOCK	EAGAIN	/* Operation would block */

 
 > This 'bug' appears from time to time : the software can run for days 
 > without problems but sometimes it fails. I tried to stop my program and 
 > rerun it (it then sets again the parameters (frequency, pol, PID,...)) but 
 > the error is still there (not a single byte is read from now on).
 > 
 > The only way I found (I did not look for long !) to get back to normal is 
 > to reboot the PC...

A driver reload does not help in your case?

These comments are still for the non-Nova cards.

 
Now regarding the Nova card questions:


 > At 13:54 04/01/02, Jon Folland wrote:
 > >What spec PC are you using? I think it is related to system resources rather
 > >than any particular bug. It happens to me from time to time.
 > >
 > >This error seems to be thrown by the driver when if finds that its buffer
 > >has not been written to by the device. I think it basically spin locks,
 > >waiting for something to be written. Although I could be wrong. If nothing
 > >has been written and it is not set to block it simply throws an error.
 > >
 > >Check the function DmxDevBufferRead(), below extracted from dmxdev.c:
 > >
 > >The -EWOULDBLOCK error code is causing the "Resource temporarily
 > >unavailable" error and it is thrown in the piece of code I have extracted
 > >from that function.
 > >
 > >         .....
 > >
 > >         if (non_blocking && (src->pwrite==src->pread)){
 > >                 return -EWOULDBLOCK;
 > >
 > >         .....
 > >
 > >


If this causes the error then no more data seems to be coming from the
hardware.



 > >
 > >
 > >         }-----Original Message-----
 > >From: linux-dvb-bounce@linuxtv.org
 > >[mailto:linux-dvb-bounce@linuxtv.org]On Behalf Of Paul Adriaenssens
 > >Sent: 04 January 2002 12:47
 > >To: linux-dvb@linuxtv.org
 > >Subject: [linux-dvb] Resource temporarily unavailable
 > >
 > >
 > >We are using a Hauppauge WinTV-NOVA satellite card (model 541) to test
 > >the reception of multicast data which is sent by our own IP-gateway in
 > >an endless loop.
 > >
 > >In order to receive and decode the data we use a java program which
 > >opens a MulticastSocket on the correct port of the dvb0_0 interface and
 > >receives the DatagramPackets from it.
 > >
 > >This process runs continuously to test the stability of the driver and
 > >our own FEC decoding software. It can run without any problem for
 > >several hours, even days, receiving all transmitted bytes, and then
 > >suddenly we get several of the following errors:
 > >
 > >java.net.SocketException: Resource temporarily unavailable
 > >at java.net.PlainDatagramSocketImpl.receive(Native Method)
 > >at java.net.DatagramSocket.receive(DatagramSocket.java:672)
 > >
 > >When this SocketException occurs, all bytes of the DatagramPacket get
 > >lost! We can't find any dvb kernel messages in /var/log/messages and we
 > >figured out that there is no correlation with the SNR or BER (even with
 > >BER=0 errors occured).

What does "dmesg" say?
Maybe there was an oops in the driver. Depending on your configuration
this might not show up in /var/log/messages. 


 > >Has anybody else stress tested the dvb API for multicast data reception
 > >by one of the dvb0_* interfaces?
 > >Do we need to "retune" de dvb card from time to time with "ntuxzap -c"
 > >or "szap -n" to avoid long uptime problems?
 > >Can we get more logging from the dvb API to get more details about the
 > >reason for this problem?

Nope.
I had a PC running for up to 4 weeks receiving a data stream and did
not have to retune it.


 > >We are using siemens_dvb-0.9.3 and Linux 2.4.9-13.

You definetely should also try a current CVS driver version.
If you check the CVS logs you will see that I added a lot more sanity
checks into the section reassembly code in DVB/driver/dvb_demux.c. 
Before these changes I also had the occasional segmentation
violation in the driver due to data corruption during bad weather.


Ralph



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.