Unknown symbol put_vaddr_frames when using media_build

  Hi!

Whenever I compile the media drivers using media_build against a recent
kernel, I get this message when loading them:

[    5.848537] media: Linux media interface: v0.10
[    5.881440] Linux video capture interface: v2.00
[    5.881441] WARNING: You are using an experimental version of the
media stack.
...
[    6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
[    6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
[    6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
[    6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)

That means I am not able to load any drivers being based on
videobuf2_memops without manual actions.

I used kernel 4.11.0, but it does not matter which kernel version
exactly is used.

My solution for that has been to modify mm/Kconfig of my kernel like
this and then enable FRAME_VECTOR in .config


But I do not like that solution.
I would prefer one of these solutions:

1. Have media_build apply its fallback the same way as for older kernels
that do not even have the the FRAME_VECTOR support.

2. Get the above patch merged (plus description etc.).

What do you think?

Regards
Matthias
  

Em Tue, 9 May 2017 06:56:25 +0200
Matthias Schwarzott <zzam@gentoo.org> escreveu:

> Hi!
> 
> Whenever I compile the media drivers using media_build against a recent
> kernel, I get this message when loading them:
> 
> [    5.848537] media: Linux media interface: v0.10
> [    5.881440] Linux video capture interface: v2.00
> [    5.881441] WARNING: You are using an experimental version of the
> media stack.
> ...
> [    6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
> [    6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
> [    6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
> [    6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
> 
> That means I am not able to load any drivers being based on
> videobuf2_memops without manual actions.
> 
> I used kernel 4.11.0, but it does not matter which kernel version
> exactly is used.
> 
> My solution for that has been to modify mm/Kconfig of my kernel like
> this and then enable FRAME_VECTOR in .config

Well, if you build your Kernel with VB2 compiled, you'll have it.

> diff --git a/mm/Kconfig b/mm/Kconfig
> index 9b8fccb969dc..cfa6a80d1a0a 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -701,7 +701,7 @@ config ZONE_DEVICE
>           If FS_DAX is enabled, then say Y.
> 
>  config FRAME_VECTOR
> -       bool
> +       tristate "frame vector"
> 
>  config ARCH_USES_HIGH_VMA_FLAGS
>         bool
> 
> But I do not like that solution.
> I would prefer one of these solutions:
> 
> 1. Have media_build apply its fallback the same way as for older kernels
> that do not even have the the FRAME_VECTOR support.
> 
> 2. Get the above patch merged (plus description etc.).
> 
> What do you think?

(1) is probably simpler, but you would need to play with the building
system in order to identify if the current Kernel has it enabled or not.
That could be tricky.

I suspect people won't accept (2), as it doesn't make sense upstream.
> 
> Regards
> Matthias



Thanks,
Mauro
  

Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:
> Em Tue, 9 May 2017 06:56:25 +0200
> Matthias Schwarzott <zzam@gentoo.org> escreveu:
> 
>> Hi!
>>
>> Whenever I compile the media drivers using media_build against a recent
>> kernel, I get this message when loading them:
>>
>> [    5.848537] media: Linux media interface: v0.10
>> [    5.881440] Linux video capture interface: v2.00
>> [    5.881441] WARNING: You are using an experimental version of the
>> media stack.
>> ...
>> [    6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
>> [    6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
>> [    6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
>> [    6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
>>
>> That means I am not able to load any drivers being based on
>> videobuf2_memops without manual actions.
>>
>> I used kernel 4.11.0, but it does not matter which kernel version
>> exactly is used.
>>
>> My solution for that has been to modify mm/Kconfig of my kernel like
>> this and then enable FRAME_VECTOR in .config
> 
> Well, if you build your Kernel with VB2 compiled, you'll have it.
> 
Sure.

So my question is:
How good do the kernel origin vb2 and the media_build vb2 play together?

Will modprobe always choose the media_build one?
Or will "make install" just overwrite the original file?

>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 9b8fccb969dc..cfa6a80d1a0a 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -701,7 +701,7 @@ config ZONE_DEVICE
>>           If FS_DAX is enabled, then say Y.
>>
>>  config FRAME_VECTOR
>> -       bool
>> +       tristate "frame vector"
>>
>>  config ARCH_USES_HIGH_VMA_FLAGS
>>         bool
>>
>> But I do not like that solution.
>> I would prefer one of these solutions:
>>
>> 1. Have media_build apply its fallback the same way as for older kernels
>> that do not even have the the FRAME_VECTOR support.
>>
>> 2. Get the above patch merged (plus description etc.).
>>
>> What do you think?
> 
> (1) is probably simpler, but you would need to play with the building
> system in order to identify if the current Kernel has it enabled or not.
> That could be tricky.
> 
> I suspect people won't accept (2), as it doesn't make sense upstream.

Well, it would be equivalent to options like CRC16 in folder lib.

Regards
Matthias
  

Em Wed, 7 Jun 2017 22:17:50 +0200
Matthias Schwarzott <zzam@gentoo.org> escreveu:

> Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:
> > Em Tue, 9 May 2017 06:56:25 +0200
> > Matthias Schwarzott <zzam@gentoo.org> escreveu:
> >   
> >> Hi!
> >>
> >> Whenever I compile the media drivers using media_build against a recent
> >> kernel, I get this message when loading them:
> >>
> >> [    5.848537] media: Linux media interface: v0.10
> >> [    5.881440] Linux video capture interface: v2.00
> >> [    5.881441] WARNING: You are using an experimental version of the
> >> media stack.
> >> ...
> >> [    6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
> >> [    6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
> >> [    6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
> >> [    6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
> >>
> >> That means I am not able to load any drivers being based on
> >> videobuf2_memops without manual actions.
> >>
> >> I used kernel 4.11.0, but it does not matter which kernel version
> >> exactly is used.
> >>
> >> My solution for that has been to modify mm/Kconfig of my kernel like
> >> this and then enable FRAME_VECTOR in .config  
> > 
> > Well, if you build your Kernel with VB2 compiled, you'll have it.
> >   
> Sure.
> 
> So my question is:
> How good do the kernel origin vb2 and the media_build vb2 play together?
> 
> Will modprobe always choose the media_build one?
> Or will "make install" just overwrite the original file?

make install *should* overwrite the old one. If not, then there's a problem
at the media-build makefile [1].

[1] or, if you're using a Kernel built by some distro, they choose to
store the media drivers on some other random directory that it is not
known by v4l/scripts/make_makefile.pl.


> 
> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> index 9b8fccb969dc..cfa6a80d1a0a 100644
> >> --- a/mm/Kconfig
> >> +++ b/mm/Kconfig
> >> @@ -701,7 +701,7 @@ config ZONE_DEVICE
> >>           If FS_DAX is enabled, then say Y.
> >>
> >>  config FRAME_VECTOR
> >> -       bool
> >> +       tristate "frame vector"
> >>
> >>  config ARCH_USES_HIGH_VMA_FLAGS
> >>         bool
> >>
> >> But I do not like that solution.
> >> I would prefer one of these solutions:
> >>
> >> 1. Have media_build apply its fallback the same way as for older kernels
> >> that do not even have the the FRAME_VECTOR support.
> >>
> >> 2. Get the above patch merged (plus description etc.).
> >>
> >> What do you think?  
> > 
> > (1) is probably simpler, but you would need to play with the building
> > system in order to identify if the current Kernel has it enabled or not.
> > That could be tricky.
> > 
> > I suspect people won't accept (2), as it doesn't make sense upstream.  
> 
> Well, it would be equivalent to options like CRC16 in folder lib.

You can try to submit it to mm maintainers. I'm just saying that they
may not be too receptive to a patch meant to solve an OOT build,
specially because it will open a new item at the mm menu with should
never be touched, as it is automatically selected.

Thanks,
Mauro
  

On Wed, Jun 07, 2017 at 08:12:01PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 7 Jun 2017 22:17:50 +0200
> Matthias Schwarzott <zzam@gentoo.org> escreveu:
> 
> > Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:
> > > Em Tue, 9 May 2017 06:56:25 +0200
> > > Matthias Schwarzott <zzam@gentoo.org> escreveu:
> > >   
> > >> Hi!
> > >>
> > >> Whenever I compile the media drivers using media_build against a recent
> > >> kernel, I get this message when loading them:
> > >>
> > >> [    5.848537] media: Linux media interface: v0.10
> > >> [    5.881440] Linux video capture interface: v2.00
> > >> [    5.881441] WARNING: You are using an experimental version of the
> > >> media stack.
> > >> ...
> > >> [    6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
> > >> [    6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
> > >> [    6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
> > >> [    6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
> > >>
> > >> That means I am not able to load any drivers being based on
> > >> videobuf2_memops without manual actions.
> > >>
> > >> I used kernel 4.11.0, but it does not matter which kernel version
> > >> exactly is used.
> > >>
> > >> My solution for that has been to modify mm/Kconfig of my kernel like
> > >> this and then enable FRAME_VECTOR in .config  
> > > 
> > > Well, if you build your Kernel with VB2 compiled, you'll have it.
> > >   
> > Sure.
> > 
> > So my question is:
> > How good do the kernel origin vb2 and the media_build vb2 play together?
> > 
> > Will modprobe always choose the media_build one?
> > Or will "make install" just overwrite the original file?
> 
> make install *should* overwrite the old one. If not, then there's a problem
> at the media-build makefile [1].
> 

There is a problem. make install has been broken for at least a week,
see the thread "media_build: fails to install"

The reason is that scripts/make_makefile.pl aborts

make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
scripts/make_makefile.pl
Can't handle includes! In 
../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile at
scripts/          make_makefile.pl line 109, <GEN152> line 4.

is because that css2400/Makefile includes another:

$ cat ../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile

ccflags-y += -DISP2400B0
ISP2400B0 := y

include $(srctree)/$(src)/../Makefile.common

The abort of scripts/make_makefile.pl means that the v4l/Makefile
does not get completely written out, in particular the rules for
making the 'media-install' target.

I am not sure how to fix this. The make_makefile.pl deliberately
falls over when given an include to deal with, so there must be
some other mechanism in the media_build framework that handles
this kind of thing. But I am not aware of it. 

Vince
  

Em Thu, 8 Jun 2017 21:23:19 +1000
Vincent McIntyre <vincent.mcintyre@gmail.com> escreveu:

> On Wed, Jun 07, 2017 at 08:12:01PM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 7 Jun 2017 22:17:50 +0200
> > Matthias Schwarzott <zzam@gentoo.org> escreveu:
> >   
> > > Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:  
> > > > Em Tue, 9 May 2017 06:56:25 +0200
> > > > Matthias Schwarzott <zzam@gentoo.org> escreveu:
> > > >     
> > > >> Hi!
> > > >>
> > > >> Whenever I compile the media drivers using media_build against a recent
> > > >> kernel, I get this message when loading them:
> > > >>
> > > >> [    5.848537] media: Linux media interface: v0.10
> > > >> [    5.881440] Linux video capture interface: v2.00
> > > >> [    5.881441] WARNING: You are using an experimental version of the
> > > >> media stack.
> > > >> ...
> > > >> [    6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
> > > >> [    6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
> > > >> [    6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
> > > >> [    6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
> > > >>
> > > >> That means I am not able to load any drivers being based on
> > > >> videobuf2_memops without manual actions.
> > > >>
> > > >> I used kernel 4.11.0, but it does not matter which kernel version
> > > >> exactly is used.
> > > >>
> > > >> My solution for that has been to modify mm/Kconfig of my kernel like
> > > >> this and then enable FRAME_VECTOR in .config    
> > > > 
> > > > Well, if you build your Kernel with VB2 compiled, you'll have it.
> > > >     
> > > Sure.
> > > 
> > > So my question is:
> > > How good do the kernel origin vb2 and the media_build vb2 play together?
> > > 
> > > Will modprobe always choose the media_build one?
> > > Or will "make install" just overwrite the original file?  
> > 
> > make install *should* overwrite the old one. If not, then there's a problem
> > at the media-build makefile [1].
> >   
> 
> There is a problem. make install has been broken for at least a week,
> see the thread "media_build: fails to install"
> 
> The reason is that scripts/make_makefile.pl aborts
> 
> make[1]: Entering directory '/home/me/git/clones/media_build/v4l'
> scripts/make_makefile.pl
> Can't handle includes! In 
> ../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile at
> scripts/          make_makefile.pl line 109, <GEN152> line 4.
> 
> is because that css2400/Makefile includes another:
> 
> $ cat ../linux/drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile
> 
> ccflags-y += -DISP2400B0
> ISP2400B0 := y
> 
> include $(srctree)/$(src)/../Makefile.common

Hmm...

	$ git grep Makefile.common
	drivers/staging/media/atomisp/pci/atomisp2/css2400/Makefile:include $(srctree)/$(src)/../Makefile.common
	$ find . -name Makefile.common
	$

There's no Makefile.common! This is just a bogus line.
 
> The abort of scripts/make_makefile.pl means that the v4l/Makefile
> does not get completely written out, in particular the rules for
> making the 'media-install' target.
> 
> I am not sure how to fix this. The make_makefile.pl deliberately
> falls over when given an include to deal with, so there must be
> some other mechanism in the media_build framework that handles
> this kind of thing. But I am not aware of it. 

I just fixed it: make install should work again.

I also fixed some recent breakages after fwnode patches.
So, at least for me (built against 4.10.17-200.fc25.x86_64) it works.

Thanks,
Mauro