[dvblast-devel] error: couldn't read from DVR device (Value too large for defined data type)

[Honza Petrouš]

2013/7/3 Georgi Chorbadzhiyski <gf at unixsol.org>:
> Around 07/03/2013 03:26 PM, Honza Petrouš scribbled:
>> 2013/7/3 Georgi Chorbadzhiyski <gf at unixsol.org>:
>>> I'm using digital devices S2 card with these drivers on linux 3.7.1
>>>
>>> [    5.384924] Latest git patches (needed if you report a bug to linux-media at vger.kernel.org):
>>> [    5.384924]  8b2aea7878f64814544d0527c659011949d52358 [media] em28xx: prefer bulk mode on webcams
>>> [    5.384924]  a3efa1cc0e067675ffa2d2c357cbe1da0db4653b [media] em28xx: make the logs reflect the specific chip name
>>> [    5.384924]  aa51496b21542855e779a78bf33384002f01acb6 [media] em28xx: display the isoc/bulk mode
>>> [    5.384924]  experimental: 9b79c0d0acf1607158e1bdb70fe913059894bfd5 experimental: Add workaround for CAM write errors.
>>> [    5.384924]  ngene-octopus-test: a8742d5952072f2237cdf28ae4cbb78fa6039f80 ddbridge: Add Digital Devices Cine S2 V6.5
>>> [    5.414058] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
>>> [    5.414546] DDBridge driver detected: Digital Devices Cine S2 V6 DVB adapter
>>>
>>> Couple of days ago one of the transponders that I'm using began to log these errors from
>>> time to time:
>>>
>>> Jul  3 00:26:19 live4 dvblast/00_39_12524_H_30000_bulsat: error: couldn't read from DVR device (Value too large for defined data type)
>>> Jul  3 00:53:18 live4 dvblast/00_39_12524_H_30000_bulsat: error: couldn't read from DVR device (Value too large for defined data type)
>>> Jul  3 04:52:18 live4 dvblast/00_39_12524_H_30000_bulsat: error: couldn't read from DVR device (Value too large for defined data type)
>>> Jul  3 05:31:17 live4 dvblast/00_39_12524_H_30000_bulsat: error: couldn't read from DVR device (Value too large for defined data type)
>>> Jul  3 05:32:19 live4 dvblast/00_39_12524_H_30000_bulsat: error: couldn't read from DVR device (Value too large for defined data type)
>>>
>>> It is happening only on this transponder [1] (the machine reads 12 others as well but
>>> they are fine). What could possibly be the reason? Is it too much data coming and the
>>> driver can't handle it? If I lower down MAX_READ_ONCE could this help?
>>
>> Yes, it happens when kernel's dvb ringbuffer gets overwritten by too
>> much incomming data.
>> Try to change a buffer size by ioctl DMX_SET_BUFFER_SIZE.
>
> I don't think that would help. It is already set to:
>
> #define DVR_BUFFER_SIZE 40*188*1024 /* bytes */
>
> which is far bigger than the length of data that we try to read.
>
> We use readv() on 50 (MAX_READ_ONCE), 188 byte packets.
>
> From dvb.c:
>     245     if ( (i_len = readv(i_dvr, p_iov, MAX_READ_ONCE)) < 0 )
>     246     {
>     247         msg_Err( NULL, "couldn't read from DVR device (%s)",
>     248                  strerror(errno) );
>     249         i_len = 0;
>     250     }
>

But I don't see any other reason for such errno.
I understand that it is not easy to track on production system,
but I still think it must be some bottleneck in consumer
processing.

BTW, one hint - can you check for values in p_iov->iov_len?
Google found some issues when iov_len was > MAX_INT32
on filesystems not supporting LARGE_FILES (64bit operations).

/Honza

/Honza