* Unknown symbol put_vaddr_frames when using media_build
@ 2017-05-09 4:56 Matthias Schwarzott
2017-06-07 18:23 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 6+ messages in thread
From: Matthias Schwarzott @ 2017-05-09 4:56 UTC (permalink / raw)
To: Linux Media Mailing List, Hans Verkuil
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
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?
Regards
Matthias
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Unknown symbol put_vaddr_frames when using media_build
2017-05-09 4:56 Unknown symbol put_vaddr_frames when using media_build Matthias Schwarzott
@ 2017-06-07 18:23 ` Mauro Carvalho Chehab
2017-06-07 20:17 ` Matthias Schwarzott
0 siblings, 1 reply; 6+ messages in thread
From: Mauro Carvalho Chehab @ 2017-06-07 18:23 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: Linux Media Mailing List, Hans Verkuil
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unknown symbol put_vaddr_frames when using media_build
2017-06-07 18:23 ` Mauro Carvalho Chehab
@ 2017-06-07 20:17 ` Matthias Schwarzott
2017-06-07 23:12 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 6+ messages in thread
From: Matthias Schwarzott @ 2017-06-07 20:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Hans Verkuil
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unknown symbol put_vaddr_frames when using media_build
2017-06-07 20:17 ` Matthias Schwarzott
@ 2017-06-07 23:12 ` Mauro Carvalho Chehab
2017-06-08 11:23 ` Vincent McIntyre
0 siblings, 1 reply; 6+ messages in thread
From: Mauro Carvalho Chehab @ 2017-06-07 23:12 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: Linux Media Mailing List, Hans Verkuil
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unknown symbol put_vaddr_frames when using media_build
2017-06-07 23:12 ` Mauro Carvalho Chehab
@ 2017-06-08 11:23 ` Vincent McIntyre
2017-06-08 16:00 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 6+ messages in thread
From: Vincent McIntyre @ 2017-06-08 11:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Matthias Schwarzott, Linux Media Mailing List, Hans Verkuil
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unknown symbol put_vaddr_frames when using media_build
2017-06-08 11:23 ` Vincent McIntyre
@ 2017-06-08 16:00 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 6+ messages in thread
From: Mauro Carvalho Chehab @ 2017-06-08 16:00 UTC (permalink / raw)
To: Vincent McIntyre
Cc: Matthias Schwarzott, Linux Media Mailing List, Hans Verkuil
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-08 16:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-09 4:56 Unknown symbol put_vaddr_frames when using media_build Matthias Schwarzott
2017-06-07 18:23 ` Mauro Carvalho Chehab
2017-06-07 20:17 ` Matthias Schwarzott
2017-06-07 23:12 ` Mauro Carvalho Chehab
2017-06-08 11:23 ` Vincent McIntyre
2017-06-08 16:00 ` Mauro Carvalho Chehab
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.