Re: Unknown symbol put_vaddr_frames when using media_build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:
> Em Tue, 9 May 2017 06:56:25 +0200
> Matthias Schwarzott <zzam@xxxxxxxxxx> 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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux