v4l2 api compliance test

v4l2 api compliance test

[Carl Karsten]

I am using my current problem as a reason to improve the overall v4l2 
development process.  So if it seems overkill for my problem, it might be.  But 
before I go putting effort into fixing what is there, I better make sure it 
doesn't already exist somewhere else.

Background on my problem:

I am helping debug a v4l2 driver, which really means report bugs about it.  My 
ultimate goal is to use it with transcode's import_v4l2 module, but that needs 
some work too.

Reporting bugs on the driver is a bit frustrating because we don't have a stable 
test platform.  I thought had found here:
http://www.video4linux.org/browser/v4l2-apps/test/
But after spending the day with those apps, I am not sure how to apply them to 
testing the driver and get useful tests.

I think a README should be in this dir, and mention vivi, the test driver.  it 
is the obvious counterpart for developing tests.  So that is my current focus: 
get a test app that will run against vivi and give expected results.

Here is what I found from the various apps int he test dir:

driver-test doesn't do much.  I am hoping to replace it.

ioctl-test looks pretty good for what it is, but could use a little work on 
making the results easier to understand.

In documenting the tests, something just caused my test box to go to sleep.
[ 2067.460263] vivi/0: [d6cb2180/4] timeout
[ 2067.460267] vivi/0: [d6cb2480/5] timeout
[ 2215.838800] vivi: open called (minor=0)
[ 2388.964289] vivi: open called (minor=0)
[ 2477.927340] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[ 2480.753620] Syncing filesystems ... done.
[ 2480.753887] PM: Preparing system for mem sleep
[ 2480.754414] Freezing user space processes ... (elapsed 0.03 seconds) done.
[ 2480.792622] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[ 2480.792745] PM: Entering mem sleep
[ 2480.792750] Suspending console(s)

That was freaky.  Hopefully I'll figure out how that happened and report it.

v4l-info
...
         fmt.pix.colorspace      : unknown

Which may explain why ./pixfmt-test doesn't find any supported formats.

./vbi-test
V4L2 call: ret=-1: sampling_rate=0, samples_per_line=0, sample_format=0, 
offset=0, start=0/0, count=0/0
good?

lib$ vim v4l2_driver.c
This seems to have 1/2 the code I need.  a main with some command line parameter 
support, spin though the cap.capabilities, make sure the ones that are supported 
  don't error, and maybe make sure the ones that aren't do.

So, before I go any further,  comments?

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Mauro Carvalho Chehab]

On Sat, 01 Mar 2008 01:45:24 -0600
Carl Karsten <carl@personnelware.com> wrote:

> Here is what I found from the various apps int he test dir:
> 
> driver-test doesn't do much.  I am hoping to replace it.

The idea of this is to check if a driver is compliant with V4L2 specs.
For example, several webcam drivers returns wrong buffer sizes to userspace.
This testing program should do some basic configuration of the board and start
capture, warning about non-compliance.

This program already warns about some issues, but I didn't have time to finish
it.

Ideally, it should implement all ioctls from the API, and test the possible 
different configuration, helping to stress a driver.

Some options may be added to it, to select a fast test or a more detailed and
longer one.

> ioctl-test looks pretty good for what it is, but could use a little work on 
> making the results easier to understand.

This is my first trial on writing a testing code. It just dumbly runs the V4L
ioctls. Since it doesn't do anything coherent, this may produce weird results
on real drivers. The debug printk's at the driver may help to see if everything
is ok.

> In documenting the tests, something just caused my test box to go to sleep.
> [ 2067.460263] vivi/0: [d6cb2180/4] timeout
> [ 2067.460267] vivi/0: [d6cb2480/5] timeout
> [ 2215.838800] vivi: open called (minor=0)
> [ 2388.964289] vivi: open called (minor=0)
> [ 2477.927340] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
> [ 2480.753620] Syncing filesystems ... done.
> [ 2480.753887] PM: Preparing system for mem sleep
> [ 2480.754414] Freezing user space processes ... (elapsed 0.03 seconds) done.
> [ 2480.792622] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> [ 2480.792745] PM: Entering mem sleep
> [ 2480.792750] Suspending console(s)
> 
> That was freaky.  Hopefully I'll figure out how that happened and report it.

This is really weird. vivi doesn't implement any suspend code.
> 
> v4l-info
> ...
>          fmt.pix.colorspace      : unknown
> 
> Which may explain why ./pixfmt-test doesn't find any supported formats.

v4l-info uses the old V4L1 API (and V4L2). Maybe, some format were not correctly
translated by v4l1-compat.
> 
> ./vbi-test
> V4L2 call: ret=-1: sampling_rate=0, samples_per_line=0, sample_format=0, 
> offset=0, start=0/0, count=0/0
> good?

vivi doesn't implement vbi. Returning an error seems OK.

> 
> lib$ vim v4l2_driver.c
> This seems to have 1/2 the code I need.  a main with some command line parameter 
> support, spin though the cap.capabilities, make sure the ones that are supported 
>   don't error, and maybe make sure the ones that aren't do.
> 
> So, before I go any further,  comments?

Please, feel free to improve the tools. Unfortunately, nobody yet had time to
dedicate on improving the testing tools.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Carl Karsten]

Mauro Carvalho Chehab wrote:
> On Sat, 01 Mar 2008 01:45:24 -0600
> Carl Karsten <carl@personnelware.com> wrote:
> 
>> Here is what I found from the various apps int he test dir:
>>
>> driver-test doesn't do much.  I am hoping to replace it.
> 
> The idea of this is to check if a driver is compliant with V4L2 specs.
> For example, several webcam drivers returns wrong buffer sizes to userspace.
> This testing program should do some basic configuration of the board and start
> capture, warning about non-compliance.
> 
> This program already warns about some issues, but I didn't have time to finish
> it.
> 
> Ideally, it should implement all ioctls from the API, and test the possible 
> different configuration, helping to stress a driver.
> 
> Some options may be added to it, to select a fast test or a more detailed and
> longer one.
> 
>> ioctl-test looks pretty good for what it is, but could use a little work on 
>> making the results easier to understand.
> 
> This is my first trial on writing a testing code. It just dumbly runs the V4L
> ioctls. Since it doesn't do anything coherent, this may produce weird results
> on real drivers. The debug printk's at the driver may help to see if everything
> is ok.
> 
>> In documenting the tests, something just caused my test box to go to sleep.
>> [ 2067.460263] vivi/0: [d6cb2180/4] timeout
>> [ 2067.460267] vivi/0: [d6cb2480/5] timeout
>> [ 2215.838800] vivi: open called (minor=0)
>> [ 2388.964289] vivi: open called (minor=0)
>> [ 2477.927340] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
>> [ 2480.753620] Syncing filesystems ... done.
>> [ 2480.753887] PM: Preparing system for mem sleep
>> [ 2480.754414] Freezing user space processes ... (elapsed 0.03 seconds) done.
>> [ 2480.792622] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
>> [ 2480.792745] PM: Entering mem sleep
>> [ 2480.792750] Suspending console(s)
>>
>> That was freaky.  Hopefully I'll figure out how that happened and report it.
> 
> This is really weird. vivi doesn't implement any suspend code.
>> v4l-info
>> ...
>>          fmt.pix.colorspace      : unknown
>>
>> Which may explain why ./pixfmt-test doesn't find any supported formats.
> 
> v4l-info uses the old V4L1 API (and V4L2). Maybe, some format were not correctly
> translated by v4l1-compat.
>> ./vbi-test
>> V4L2 call: ret=-1: sampling_rate=0, samples_per_line=0, sample_format=0, 
>> offset=0, start=0/0, count=0/0
>> good?
> 
> vivi doesn't implement vbi. Returning an error seems OK.
> 
>> lib$ vim v4l2_driver.c
>> This seems to have 1/2 the code I need.  a main with some command line parameter 
>> support, spin though the cap.capabilities, make sure the ones that are supported 
>>   don't error, and maybe make sure the ones that aren't do.
>>
>> So, before I go any further,  comments?
> 
> Please, feel free to improve the tools. Unfortunately, nobody yet had time to
> dedicate on improving the testing tools.

These 2 issues are thwarting my efforts to write my tester:

1. memory leak:
valgrind ./capture --userp -d /dev/video1
==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.

2. capabilities mismatch:
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Andy Walls]

On Sun, 2008-11-02 at 18:32 -0600, Carl Karsten wrote:
> Mauro Carvalho Chehab wrote:
> > On Sat, 01 Mar 2008 01:45:24 -0600
> > Carl Karsten <carl@personnelware.com> wrote:
> >
> > 
> > Please, feel free to improve the tools. Unfortunately, nobody yet had time to
> > dedicate on improving the testing tools.
> 
> These 2 issues are thwarting my efforts to write my tester:
> 
> 1. memory leak:
> valgrind ./capture --userp -d /dev/video1
> ==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.
> 
> 2. capabilities mismatch:
> ./capture --userp -d /dev/video1
> VIDIOC_QBUF error 22, Invalid argument
> 
> details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples

I'm not sure why a memory leak on abnormal termination is worrisome for
you.  It looks like init_userp() allocated a bunch of "buffers", which
has to happen for a program to use user pointer mode of v4l2.  The
function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF
ioctl() call fails.  free() is only called by uninit_device().  Since
the alternate flow of the program through errno_exit() to termination
doesn't call free() on "buffers", you should have a process heap memory
leak on error exit.

Since this is userspace, a memory leak from the process heap doesn't
hang around when the process terminates - no big deal.  You could
equally gripe that the program didn't close it's file descriptors with
the driver on errno_exit() - but process termination cleans those up
too.

Regards,
Andy

> Carl K


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Carl Karsten]

Andy Walls wrote:
> On Sun, 2008-11-02 at 18:32 -0600, Carl Karsten wrote:
>> Mauro Carvalho Chehab wrote:
>>> On Sat, 01 Mar 2008 01:45:24 -0600
>>> Carl Karsten <carl@personnelware.com> wrote:
>>>
>>>
>>> Please, feel free to improve the tools. Unfortunately, nobody yet had time to
>>> dedicate on improving the testing tools.
>> These 2 issues are thwarting my efforts to write my tester:
>>
>> 1. memory leak:
>> valgrind ./capture --userp -d /dev/video1
>> ==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.
>>
>> 2. capabilities mismatch:
>> ./capture --userp -d /dev/video1
>> VIDIOC_QBUF error 22, Invalid argument
>>
>> details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples
>
> I'm not sure why a memory leak on abnormal termination is worrisome for
> you.  It looks like init_userp() allocated a bunch of "buffers", which
> has to happen for a program to use user pointer mode of v4l2.  The
> function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF
> ioctl() call fails.  free() is only called by uninit_device().  Since
> the alternate flow of the program through errno_exit() to termination
> doesn't call free() on "buffers", you should have a process heap memory
> leak on error exit.
>
> Since this is userspace, a memory leak from the process heap doesn't
> hang around when the process terminates - no big deal.

Are you sure about that?

if I run
./capture --userp -d /dev/video1
VIDIOC_QBUF error 22, Invalid argument

enough I can't run the valid modes:

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
read error 12, Cannot allocate memory

juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
mmap error 12, Cannot allocate memory

although free still shows lots:

juser@dhcp186:~/vga2usb/v4l.org/examples$ free
             total       used       free     shared    buffers     cached
Mem:       1033388     282340     751048          0      31012      98208
-/+ buffers/cache:     153120     880268
Swap:       859436          0     859436


> You could
> equally gripe that the program didn't close it's file descriptors with
> the driver on errno_exit() - but process termination cleans those up
> too.

I am personally interested in anything that makes it harder for me to determine
if a driver is misbehaving.

In addition, I would think that the API's example code should be a squeaky clean
example of how real code should be written, given it is often used as a starting
point.  If problems are identified, they should at least be noted, better yet
removed.

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Andy Walls]

On Sun, 2008-11-02 at 21:23 -0600, Carl Karsten wrote:
> Andy Walls wrote:
> > On Sun, 2008-11-02 at 18:32 -0600, Carl Karsten wrote:
> >> Mauro Carvalho Chehab wrote:
> >>> On Sat, 01 Mar 2008 01:45:24 -0600
> >>> Carl Karsten <carl@personnelware.com> wrote:
> >>>
> >>>
> >>> Please, feel free to improve the tools. Unfortunately, nobody yet had time to
> >>> dedicate on improving the testing tools.
> >> These 2 issues are thwarting my efforts to write my tester:
> >>
> >> 1. memory leak:
> >> valgrind ./capture --userp -d /dev/video1
> >> ==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.
> >>
> >> 2. capabilities mismatch:
> >> ./capture --userp -d /dev/video1
> >> VIDIOC_QBUF error 22, Invalid argument
> >>
> >> details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples
> >
> > I'm not sure why a memory leak on abnormal termination is worrisome for
> > you.  It looks like init_userp() allocated a bunch of "buffers", which
> > has to happen for a program to use user pointer mode of v4l2.  The
> > function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF
> > ioctl() call fails.  free() is only called by uninit_device().  Since
> > the alternate flow of the program through errno_exit() to termination
> > doesn't call free() on "buffers", you should have a process heap memory
> > leak on error exit.
> >
> > Since this is userspace, a memory leak from the process heap doesn't
> > hang around when the process terminates - no big deal.
> 
> Are you sure about that?

About the process heap, yes.

> if I run
> ./capture --userp -d /dev/video1
> VIDIOC_QBUF error 22, Invalid argument
> 
> enough I can't run the valid modes:
> 
> juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
> read error 12, Cannot allocate memory

The capture app would output "Out of memory" if the calloc() call for
the --read option buffers failed.  This is some global/kernel resource
that has been exhausted.


> juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
> mmap error 12, Cannot allocate memory

Ditto for this.  This message can only happen at the end of init_mmap()
when the mmap call fails.  Thus an allocation of some sort of kernel
global resource/space failed.


I don't know what could be exhausting those kernel resources when using
the userp option.  The failed ioctl()'s calls to the vivi driver would
be a place to start looking.


> although free still shows lots:
> 
> juser@dhcp186:~/vga2usb/v4l.org/examples$ free
>              total       used       free     shared    buffers     cached
> Mem:       1033388     282340     751048          0      31012      98208
> -/+ buffers/cache:     153120     880268
> Swap:       859436          0     859436
> 

Perhaps you could look at /proc/meminfo between runs and see if
something is gradually being exhausted.  Vmalloc address space
exhaustion is what I'd look for.



> > You could
> > equally gripe that the program didn't close it's file descriptors with
> > the driver on errno_exit() - but process termination cleans those up
> > too.
> 
> I am personally interested in anything that makes it harder for me to determine
> if a driver is misbehaving.

Ah, eliminating unknowns.  OK.


> In addition, I would think that the API's example code should be a squeaky clean
> example of how real code should be written, given it is often used as a starting
> point.  If problems are identified, they should at least be noted, better yet
> removed.

I can't say I disagree. 

Regards,
Andy

> Carl K
> 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Carl Karsten]

>>>> details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples
>>> I'm not sure why a memory leak on abnormal termination is worrisome for
>>> you.  It looks like init_userp() allocated a bunch of "buffers", which
>>> has to happen for a program to use user pointer mode of v4l2.  The
>>> function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF
>>> ioctl() call fails.  free() is only called by uninit_device().  Since
>>> the alternate flow of the program through errno_exit() to termination
>>> doesn't call free() on "buffers", you should have a process heap memory
>>> leak on error exit.
>>>
>>> Since this is userspace, a memory leak from the process heap doesn't
>>> hang around when the process terminates - no big deal.
>> Are you sure about that?
> 
> About the process heap, yes.
> 
>> if I run
>> ./capture --userp -d /dev/video1
>> VIDIOC_QBUF error 22, Invalid argument
>>
>> enough I can't run the valid modes:
>>
>> juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
>> read error 12, Cannot allocate memory
> 
> The capture app would output "Out of memory" if the calloc() call for
> the --read option buffers failed.  This is some global/kernel resource
> that has been exhausted.


> 
> 
>> juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
>> mmap error 12, Cannot allocate memory
> 
> Ditto for this.  This message can only happen at the end of init_mmap()
> when the mmap call fails.  Thus an allocation of some sort of kernel
> global resource/space failed.


so more likely a driver problem?

> 
> 
> I don't know what could be exhausting those kernel resources when using
> the userp option.  The failed ioctl()'s calls to the vivi driver would
> be a place to start looking.
> 
> 
>> although free still shows lots:
>>
>> juser@dhcp186:~/vga2usb/v4l.org/examples$ free
>>              total       used       free     shared    buffers     cached
>> Mem:       1033388     282340     751048          0      31012      98208
>> -/+ buffers/cache:     153120     880268
>> Swap:       859436          0     859436
>>
> 
> Perhaps you could look at /proc/meminfo between runs and see if
> something is gradually being exhausted.  Vmalloc address space
> exhaustion is what I'd look for.
> 

I ran this script:

http://linuxtv.org/v4lwiki/index.php/Test_Suite#memory_leak_2

and put all the meminfo's into a spreadsheet:

http://spreadsheets.google.com/ccc?key=pIfz0wOzPtW1-oZkXXbvcLA&hl=en

I don't see any columns growing or shrinking, so not sure what to make of it.

> 
> 
>>> You could
>>> equally gripe that the program didn't close it's file descriptors with
>>> the driver on errno_exit() - but process termination cleans those up
>>> too.
>> I am personally interested in anything that makes it harder for me to determine
>> if a driver is misbehaving.
> 
> Ah, eliminating unknowns.  OK.
> 

bingo.

> 
>> In addition, I would think that the API's example code should be a squeaky clean
>> example of how real code should be written, given it is often used as a starting
>> point.  If problems are identified, they should at least be noted, better yet
>> removed.
> 
> I can't say I disagree. 
> 

so assuming the problem is with capture.c, who do I tell?  (i know where to send
anything else it might be: v4l list.

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Mauro Carvalho Chehab]

On Tue, 04 Nov 2008 19:15:10 -0600
Carl Karsten <carl@personnelware.com> wrote:


> 
> so assuming the problem is with capture.c, who do I tell?  (i know where to send
> anything else it might be: v4l list.

Carl,

If you find a trouble, please feel free to submit us a fix.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Carl Karsten]

Andy Walls wrote:
> On Sun, 2008-11-02 at 21:23 -0600, Carl Karsten wrote:
>> Andy Walls wrote:
>>> On Sun, 2008-11-02 at 18:32 -0600, Carl Karsten wrote:
>>>> Mauro Carvalho Chehab wrote:
>>>>> On Sat, 01 Mar 2008 01:45:24 -0600
>>>>> Carl Karsten <carl@personnelware.com> wrote:
>>>>>
>>>>>
>>>>> Please, feel free to improve the tools. Unfortunately, nobody yet had time to
>>>>> dedicate on improving the testing tools.
>>>> These 2 issues are thwarting my efforts to write my tester:
>>>>
>>>> 1. memory leak:
>>>> valgrind ./capture --userp -d /dev/video1
>>>> ==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.
>>>>
>>>> 2. capabilities mismatch:
>>>> ./capture --userp -d /dev/video1
>>>> VIDIOC_QBUF error 22, Invalid argument
>>>>
>>>> details: http://linuxtv.org/v4lwiki/index.php/Test_Suite#Bugs_in_Examples
>>> I'm not sure why a memory leak on abnormal termination is worrisome for
>>> you.  It looks like init_userp() allocated a bunch of "buffers", which
>>> has to happen for a program to use user pointer mode of v4l2.  The
>>> function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF
>>> ioctl() call fails.  free() is only called by uninit_device().  Since
>>> the alternate flow of the program through errno_exit() to termination
>>> doesn't call free() on "buffers", you should have a process heap memory
>>> leak on error exit.
>>>
>>> Since this is userspace, a memory leak from the process heap doesn't
>>> hang around when the process terminates - no big deal.
>> Are you sure about that?
> 
> About the process heap, yes.
> 
>> if I run
>> ./capture --userp -d /dev/video1
>> VIDIOC_QBUF error 22, Invalid argument
>>
>> enough I can't run the valid modes:
>>
>> juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --read -d /dev/video1
>> read error 12, Cannot allocate memory
> 
> The capture app would output "Out of memory" if the calloc() call for
> the --read option buffers failed.  This is some global/kernel resource
> that has been exhausted.
> 
> 
>> juser@dhcp186:~/vga2usb/v4l.org/examples$ ./capture --mmap -d /dev/video1
>> mmap error 12, Cannot allocate memory
> 
> Ditto for this.  This message can only happen at the end of init_mmap()
> when the mmap call fails.  Thus an allocation of some sort of kernel
> global resource/space failed.
> 
> 
> I don't know what could be exhausting those kernel resources when using
> the userp option.  The failed ioctl()'s calls to the vivi driver would
> be a place to start looking.
> 
> 
>> although free still shows lots:
>>
>> juser@dhcp186:~/vga2usb/v4l.org/examples$ free
>>              total       used       free     shared    buffers     cached
>> Mem:       1033388     282340     751048          0      31012      98208
>> -/+ buffers/cache:     153120     880268
>> Swap:       859436          0     859436
>>
> 
> Perhaps you could look at /proc/meminfo between runs and see if
> something is gradually being exhausted.  Vmalloc address space
> exhaustion is what I'd look for.
> 

I forgot to sort it - now I see:

HighFree go from 72608 to 252
VmallocUsed from 6440 to 109724
VmallocChunk from 103620 to 336

I hope this sheds some light on where to look.

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Andy Walls]

On Wed, 2008-11-05 at 00:46 -0600, Carl Karsten wrote:
> Andy Walls wrote:
> > On Sun, 2008-11-02 at 21:23 -0600, Carl Karsten wrote:
> >> Andy Walls wrote:
> >>> On Sun, 2008-11-02 at 18:32 -0600, Carl Karsten wrote:
> >>>> Mauro Carvalho Chehab wrote:
> >>>>> On Sat, 01 Mar 2008 01:45:24 -0600
> >>>>> Carl Karsten <carl@personnelware.com> wrote:
> >>>>>
> >>>>>

> > 
> > Perhaps you could look at /proc/meminfo between runs and see if
> > something is gradually being exhausted.  Vmalloc address space
> > exhaustion is what I'd look for.
> > 
> 
> I forgot to sort it - now I see:
> 
> HighFree go from 72608 to 252
> VmallocUsed from 6440 to 109724
> VmallocChunk from 103620 to 336
> 
> I hope this sheds some light on where to look.

The driver is leaking kernel vmalloc address space.  Since the
VIDIOC_QBUF ioctl() calls are happening in a loop for --userp, many may
be succeeding before you get the notification of one failing.

There are also likely other leaks over vmalloc space in the driver since
--read and --mmap make things worse.

Regards,
Andy

> Carl K
> 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: v4l2 api compliance test

[Carl Karsten]

I missed this: capture --read, a valid mode of vivi (at least it was not
reporting an error) is what is eating the memory.  guessing vivi, because I
don't think a user app can do what was happening.

A ubuntu dev has asked that I report it against the ubuntu kernel, so here it
is:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951

Carl K








--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list