Arnaud Patard wrote: > When using VIDIOC_QBUF with memory type set to V4L2_MEMORY_MMAP, the > v4l2_buffer buffer gets unmodified on drivers like uvc (well, only > bytesused field is modified). Then some apps like gstreamer are reusing > the same buffer later to call munmap (eg passing the buffer "length" > field as 2nd parameter of munmap). > > It's working fine on full 32bits but on 32bits systems with 64bit > kernel, the get_v4l2_buffer32() doesn't copy length/m.offset values and > then copy garbage to userspace in put_v4l2_buffer32(). > > This has for consequence things like that in the libv4l2 logs: > > libv4l2: v4l2 unknown munmap 0x2e2b0000, -2145144908 > libv4l2: v4l2 unknown munmap 0x2e530000, -2145144908 > > The buffer are not unmap'ed and then if the application close and open > again the device, it won't work and logs will show something like: > > libv4l2: error setting pixformat: Device or resource busy > > The easy solution is to read length and m.offset in get_v4l2_buffer32(). > > > Signed-off-by: Arnaud Patard <apatard@xxxxxxxxxxxx> > --- > I am not sure it even works fine on 32bit. Just yesterday I discovered https://bugzilla.gnome.org/show_bug.cgi?id=608042 I get this when using gstreamer with my UVC based camera request == VIDIOC_STREAMOFF result == 0 libv4l2: v4l2 unknown munmap 0xb6d45000, 38400 libv4l2: v4l2 unknown munmap 0xb6d3b000, 38400 I verified that buffer address and size is correct. The libv4l code for v4l2_munmap could be a bit more verbose in the case of an error ... Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
