On 5/6/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 5/6/07, Laurent Pinchart <[EMAIL PROTECTED]> wrote: > > Let's move this discussion to the linux-uvc-devel list. I CCed > > video4linux-list for reference, please reply to linux-uvc-devel only to > > avoid > > flooding the video4linux list. > > > > On Saturday 05 May 2007, Markus Rechberger wrote: > > > > [snip non-uvc issues] > > > I'll just write all my considerations here, you can put the ML into CC > > > and/or split up the topics: > > > > > > 1.) > > > May 5 20:14:19 debian kernel: ekiga: page allocation failure. > > > order:10, mode:0x0 > > > May 5 20:14:19 debian kernel: [__alloc_pages+629/646] > > > __alloc_pages+0x275/0x286 > > > May 5 20:14:19 debian kernel: [__get_free_pages+26/51] > > > __get_free_pages+0x1a/0x33 > > > May 5 20:14:19 debian kernel: [dma_alloc_coherent+170/222] > > > dma_alloc_coherent+0xaa/0xde > > > May 5 20:14:19 debian kernel: [pg0+513461816/1069679616] > > > uvc_init_video_bulk+0xb7/0x143 [uvcvideo] > > > May 5 20:14:19 debian kernel: [pg0+513462425/1069679616] > > > uvc_video_enable+0xfe/0x121 [uvcvideo] > > > May 5 20:14:19 debian kernel: [pg0+513458219/1069679616] > > > uvc_v4l2_do_ioctl+0x830/0x8bf [uvcvideo] > > > May 5 20:14:19 debian kernel: [dput+24/373] dput+0x18/0x175 > > > May 5 20:14:19 debian kernel: [__link_path_walk+2824/3148] > > > __link_path_walk+0xb08/0xc4c > > > May 5 20:14:19 debian kernel: [n_tty_receive_buf+3303/3378] > > > n_tty_receive_buf+0xce7/0xd32 > > > May 5 20:14:19 debian kernel: [get_page_from_freelist+635/798] > > > get_page_from_freelist+0x27b/0x31e > > > May 5 20:14:19 debian kernel: [wakeup_kswapd+45/104] > > > wakeup_kswapd+0x2d/0x68 May 5 20:14:19 debian kernel: > > > [pg0+511673193/1069679616] > > > video_usercopy+0x112/0x1a3 [videodev] > > > May 5 20:14:19 debian kernel: [vma_prio_tree_insert+23/42] > > > vma_prio_tree_insert+0x17/0x2a > > > May 5 20:14:19 debian kernel: [vma_link+218/247] vma_link+0xda/0xf7 > > > May 5 20:14:19 debian kernel: [pg0+513458420/1069679616] > > > uvc_v4l2_ioctl+0x3a/0x40 [uvcvideo] > > > May 5 20:14:19 debian kernel: [pg0+513456123/1069679616] > > > uvc_v4l2_do_ioctl+0x0/0x8bf [uvcvideo] > > > May 5 20:14:19 debian kernel: [do_ioctl+76/98] do_ioctl+0x4c/0x62 > > > May 5 20:14:19 debian kernel: [vfs_ioctl+583/602] > vfs_ioctl+0x247/0x25a > > > May 5 20:14:19 debian kernel: [sys_ioctl+51/76] sys_ioctl+0x33/0x4c > > > May 5 20:14:19 debian kernel: [syscall_call+7/11] syscall_call+0x7/0xb > > > May 5 20:14:19 debian kernel: ======================= > > > May 5 20:14:19 debian kernel: Mem-info: > > > May 5 20:14:19 debian kernel: DMA per-cpu: > > > May 5 20:14:19 debian kernel: CPU 0: Hot: hi: 0, btch: 1 usd: > > > 0 Cold: hi: 0, btch: 1 usd: 0 > > > May 5 20:14:19 debian kernel: Normal per-cpu: > > > May 5 20:14:19 debian kernel: CPU 0: Hot: hi: 186, btch: 31 usd: > > > 13 Cold: hi: 62, btch: 15 usd: 51 > > > May 5 20:14:19 debian kernel: Active:93485 inactive:7268 dirty:0 > > > writeback:0 unstable:0 free:1171 slab:5255 mapped:15182 pagetables:980 > > > May 5 20:14:19 debian kernel: DMA free:1928kB min:92kB low:112kB > > > high:136kB active:10716kB inactive:0kB present:16256kB > > > pages_scanned:429 all_unreclaimable? no > > > May 5 20:14:19 debian kernel: lowmem_reserve[]: 0 459 > > > May 5 20:14:19 debian kernel: Normal free:2756kB min:2692kB > > > low:3364kB high:4036kB active:363224kB inactive:29072kB > > > present:470284kB pages_scanned:291 all_unreclaimable? no > > > May 5 20:14:19 debian kernel: lowmem_reserve[]: 0 0 > > > May 5 20:14:19 debian kernel: DMA: 4*4kB 1*8kB 1*16kB 1*32kB 1*64kB > > > 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1928kB > > > May 5 20:14:19 debian kernel: Normal: 47*4kB 5*8kB 12*16kB 3*32kB > > > 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2756kB > > > May 5 20:14:19 debian kernel: Swap cache: add 440134, delete 421407, > > > find 136779/175577, race 0+0 > > > May 5 20:14:19 debian kernel: Free swap = 455676kB > > > May 5 20:14:19 debian kernel: Total swap = 976888kB > > > May 5 20:14:19 debian kernel: Free swap: 455676kB > > > May 5 20:14:19 debian kernel: 122592 pages of RAM > > > May 5 20:14:19 debian kernel: 0 pages of HIGHMEM > > > May 5 20:14:19 debian kernel: 1844 reserved pages > > > May 5 20:14:19 debian kernel: 70305 pages shared > > > May 5 20:14:19 debian kernel: 18727 pages swap cached > > > May 5 20:14:19 debian kernel: 0 pages dirty > > > May 5 20:14:19 debian kernel: 0 pages writeback > > > May 5 20:14:19 debian kernel: 15182 pages mapped > > > May 5 20:14:19 debian kernel: 5253 pages slab > > > May 5 20:14:19 debian kernel: 980 pages pagetables > > > > > > This happens either if a box has 256 mb ram, or is almost out of > > > physical memory. > > > The other driver I have works properly with it. After a fresh reboot > > > the uvcvideo driver seems to work for a while. > > > > Oh, an OOM issue. > > > > The driver allocates memory for bulk/isochronous transfers based on two > > parameters. The first one is the maximum payload transfer size, as > reported > > by the device. I can't do much about that one. The second one is the > number > > of URBs allocated by the driver. This is currently hardcoded to 5, but > could > > be made configurable or could be computed based on the maximum payload > > transfer size. I'll look into this issue. > > > > this really seems to be an issue with usb_buffer_alloc() after that > call fails the whole memory management goes dizzy. > It tries to swap out almost all the physical memory hangs for a while > and copies the swapped memory back to physical memory till it becomes > normal again. > I also see that more than half of the system memory is used as cache, > since usb_buffer_alloc is called with GFP_KERNEL it might wait until > some cache memory gets released for it. I added Greg to that mail > since I think that he knows alot about the usb framework itself. > > dwMaxVideoFrameBufferSize 2752512 (which is used for > usb_buffer_alloc, seems to be too much already) > > I don't have a problem with that in my uvc driver since I only > allocate memory for max. 640x480 and do not support a higher mode. > > > Could you please post the output of lsusb -v (with usbutils 0.72 or later) > ? > > Thanks. > > > > (think that value was what you were looking for) > > > > 2.) No v4l1 support using the compat layer > > > > > > I read some discussions about not supporting v4l1, as a point from the > > > userside it simply has to work and there are still applications out > > > there which only support v4l1, I read that a compat version of that > > > driver is available but you don't want it in the main driver. > > > > The Linux UVC driver calls v4l_compat_translate_ioctl() for all > non-handled > > ioctls. The compat layer is thus used. It seems the problem comes from a > > required v4l1 ioctl not handled properly by the compat layer. I haven't > > looked into that issue, as I don't plan to support v4l1 explicitly in the > > driver. > > > > as for my drivers I always saw this as an open issue too, there is no > reason to not add support for it at least, it just requires a few more > ioctl controls. > > > > 3.) Some controls are missing, for example mplayer isn't supported by > > > just running > > > mplayer -tv driver=v4l2 tv:// > > > > mplayer is buggy. It doesn't set the v4l2_buffer.memory field prior to > > dequeuing buffers, as required by the v4l2 specification. I think a patch > > has > > been applied to the mplayer repository to fix this issue. > > > > I see xawtv doesn't work either here, the em28xx driver works with > both without the need of any patches. xawtv is used as a reference for > some other userspace applications since it has been available for a > very long time already. >
just tested mplayer (latest svn) it doesn't work either > > > 4.) read() isn't supported > > > > That's right, and this is definitely a shortcomming. I plan to support > > read(), > > but this hasn't been done yet. If you need read() support for a specific > > application, we could work together to add it to the driver as quickly as > > possible. > > > > > 5.) I'd like to share common code between usb video devices, the > > > em28xx driver supports slicing the video and piping a part of the > > > video to /dev/vbi for example (raw vbi). > > > 6.) Mauro also wrote some ideas about having a general usb framework > > > since all devices share common parts. > > > > > > these points would be part of the agenda which I'd like to discuss > > > with you and Mauro actually. > > > > I plan to see if I can use video-buf in the Linux UVC driver. However, > this > > might not be beneficial to all users. The buffer queue code in the UVC > > driver > > is USB-specific, and is thus smaller than video-buf. Users who currently > > don't use video-buf would see their memory usage grow. > > > > Laurent Pinchart > > > > (I'll answer the other issues later) > > Markus > -- Markus Rechberger _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
