From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Matthias Schwarzott <zzam@gentoo.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: Unknown symbol put_vaddr_frames when using media_build
Date: Wed, 7 Jun 2017 20:12:01 -0300 [thread overview]
Message-ID: <20170607201201.3e9eef8f@vento.lan> (raw)
In-Reply-To: <cc11c60e-8a39-35f2-06e5-f6cb3b1cdc4a@gentoo.org>
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
next prev parent reply other threads:[~2017-06-07 23:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2017-06-08 11:23 ` Vincent McIntyre
2017-06-08 16:00 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170607201201.3e9eef8f@vento.lan \
--to=mchehab@s-opensource.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=zzam@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).