Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Resource temporarily unavailable
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.
Home |
Main Index |
Thread Index