cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Apr 14 04:00:18 CEST 2014 git branch: test git hash: a83b93a7480441a47856dc9104bea970e84cda87 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stk1160 / ehci-pci 0000:00:0a.0: DMA-API: device driver maps memory fromstack [addr=ffff88003d0b56bf]
On Sun, 13 Apr 2014, Sander Eikelenboom wrote: > Hi, > > I'm hitting this warning on boot with a syntek usb video grabber, it's not > clear > to me if it's a driver issue of the stk1160 or a generic ehci issue. It is a bug in the stk1160 driver. > This is with a 3.15-mergewindow kernel (pull of Linus his tree of today). > > -- > Sander > > [5.587759] [ cut here ] > [5.591210] WARNING: CPU: 0 PID: 1376 at lib/dma-debug.c:1153 > check_for_stack+0xa0/0x100() > [5.596612] ehci-pci :00:0a.0: DMA-API: device driver maps memory > fromstack [addr=88003d0b56bf] > [5.602548] Modules linked in: > [5.605380] CPU: 0 PID: 1376 Comm: khubd Not tainted > 3.14.0-security-20140413-v4lall+ #1 > [5.611042] Hardware name: Xen HVM domU, BIOS 4.5-unstable 04/10/2014 > [5.615314] 0009 88003d0b5348 81c516fe > 88003d0b5390 > [5.622147] 88003d0b5380 810e4aa3 88003ceae898 > 88003cf14070 > [5.628926] 88003d0b56bf 88003ceae898 8241ab40 > 88003d0b53e0 > [5.635536] Call Trace: > [5.638001] [] dump_stack+0x45/0x56 > [5.641633] [] warn_slowpath_common+0x73/0x90 > [5.645688] [] warn_slowpath_fmt+0x47/0x50 > [5.649843] [] check_for_stack+0xa0/0x100 > [5.652420] systemd-udevd[2143]: starting version 204 > [5.657709] [] debug_dma_map_page+0xfc/0x150 > [5.661836] [] usb_hcd_map_urb_for_dma+0x5fc/0x710 > [5.666132] [] usb_hcd_submit_urb+0x315/0xa30 > [5.670247] [] ? del_timer_sync+0x4a/0x60 > [5.674072] [] ? schedule_timeout+0x14d/0x1f0 > [5.678083] [] ? migrate_timer_list+0x60/0x60 > [5.682167] [] usb_submit_urb+0x30c/0x580 > [5.685989] [] ? wait_for_common+0x16b/0x240 > [5.689919] [] usb_start_wait_urb+0x5a/0xe0 > [5.693830] [] ? mpol_rebind_policy+0x30/0xa0 > [5.697638] [] usb_control_msg+0xb8/0x100 > [5.701468] [] stk1160_read_reg+0x52/0x80 > [5.705358] [] stk1160_i2c_busy_wait+0x6c/0x90 The bug is here. stk1160_i2c_busy_wait() passes the address of a variable on the stack to stk1160_read_reg(), and that routine passes the address to usb_control_msg(). But usb_control_msg() requires the buffer to be allocated by kmalloc, not on the stack. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: Work around buggy Logitech C920 firmware
Hi William, On Thursday 13 March 2014 22:08:36 William Manley wrote: > On 13/03/14 17:03, Laurent Pinchart wrote: > > On Thursday 13 March 2014 10:48:20 Will Manley wrote: > >> On Thu, 13 Mar 2014, at 10:23, Laurent Pinchart wrote: > >>> On Wednesday 12 March 2014 18:08:31 William Manley wrote: > The uvcvideo webcam driver exposes the v4l2 control "Exposure > (Absolute)" which allows the user to control the exposure time of the > webcam, essentially controlling the brightness of the received image. > By default the webcam automatically adjusts the exposure time > automatically but the if you set the control "Exposure, Auto"="Manual > Mode" the user can fix the exposure time. > > Unfortunately it seems that the Logitech C920 has a firmware bug where > it will forget that it's in manual mode temporarily during > initialisation. This means that the camera doesn't respect the exposure > time that the user requested if they request it before starting to > stream video. They end up with a video stream which is either too > bright or too dark and must reset the controls after video starts > streaming. > >>> > >>> I would like to get a better understanding of the problem first. As I > >>> don't have a C920, could you please perform two tests for me ? > >>> > >>> I would first like to know what the camera reports as its exposure time > >>> after starting the stream. If you get the exposure time at that point > >>> (by sending a GET_CUR request, bypassing the driver cache), do you get > >>> the value you had previously set (which, from your explanation, would be > >>> incorrect, as the exposure time has changed based on your findings), or > >>> a different value ? Does the camera change the exposure priority control > >>> autonomously as well, or just the exposure time ? > >> > >> It's a bit of a strange behaviour. I'd already tried littering the code > >> with (uncached) GET_CUR requests. It seems that the value changes > >> sometime during the call to usb_set_interface in uvc_init_video. > > > > I'll assume this means that the camera reports the updated exposure time > > in response to the GET_CUR request. > > That's right > > > Does the value of other controls (such as the > > exposure priority control for instance) change as well ? > > No, I've not seen any of the other controls change. > > >> Strangely enough though calling uvc_ctrl_restore_values immediately after > >> uvc_init_video has no effect. It must be put after the usb_submit_urb > >> loop to fix the problem. > >> > >>> Then, I would like to know whether the camera sends a control update > >>> event when you start the stream, or if it just changes the exposure time > >>> without notifying the driver. > >> > >> Wireshark tells me that it is sending a control update event, but it > >> seems like uvcvideo ignores it. I had to add the flag > >> UVC_CTRL_FLAG_AUTO_UPDATE to the uvc_control_info entry for "Exposure > >> (Auto)" for the new value to be properly reported to userspace. > > > > Could you send me the USB trace ? > > I've uploaded 3 traces: one with no patch (kernel 3.12) one with my > "PATCH v2" applied and one with no patch but caching of gets disabled. > You can get them here: > > http://williammanley.net/C920-no-patch.pcapng > http://williammanley.net/C920-with-patch.pcapng > http://williammanley.net/C920-no-caching.pcapng > > The process to generate them was: > > sudo dumpcap -i usbmon1 -w /tmp/C920-no-patch2.pcapng & > > # Plug USB cable in here > > v4l2-ctl -d > /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_C833389F-video-index1 > > -cexposure_auto=1,exposure_auto_priority=0,exposure_absolute=152,white_balan > ce_temperature_auto=0 > > ./streamon > > The relevant output seems to be (here from C920-no-patch.pcapng): > > 10446 23.095874000 21:14:16.313257000 host -> 32.0 USB 64 > > SET INTERFACE Request 10447 23.109379000 21:14:16.326762000 32.3 > > -> host USBVIDEO 70 URB_INTERRUPT in 10448 23.109389000 > > 21:14:16.326772000 host -> 32.3 USB 64 URB_INTERRUPT in > > 10449 23.189448000 21:14:16.406831000 32.3 -> host > > USBVIDEO 73 URB_INTERRUPT in 10450 23.189486000 21:14:16.406869000 > > host -> 32.3 USB 64 URB_INTERRUPT in 10451 23.243314000 > > 21:14:16.460697000 32.0 -> host USB 64 SET INTERFACE > > Response > Taking a closer look at packet 10449: > > Frame 10449: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) on > > interface 0> > > Interface id: 0 > > Encapsulation type: USB packets with Linux header and padding (115) > > Arrival Time: Mar 13, 2014 21:14:16.406831000 GMT > > [Time shift for this packet: 0.0 seconds] > > Epoch Time: 1394745256.406831000 seconds > > [Time delta from previous captured frame: 0.080059000 seconds] > > [Time delta from previous displayed frame: 0.0800
[Developers] I know how to make this Digivox work, could v4l-dvb be patched for it?
Device: http://linuxtv.org/wiki/index.php/MSI_DigiVox_Trio
In the "making it work" section I already described it: you just need to
threat this device exactly as if it's a Terratec H5.
Something as simple as adding:
{ USB_DEVICE(0xeb1a, 0x2885),/* MSI Digivox Trio */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
to linux/drivers/media/usb/em28xx/em28xx-cards.c is sufficient. This is
probably a slightly ugly way to do it, but I've been using this solution
for half a year and haven't found any problems with it.
What needs to be done in order to get a change like this (or maybe one
that looks slighty more neat) into the official v4l-dvb?
Best regards,
P. van Gaans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
stk1160 / ehci-pci 0000:00:0a.0: DMA-API: device driver maps memory fromstack [addr=ffff88003d0b56bf]
Hi, I'm hitting this warning on boot with a syntek usb video grabber, it's not clear to me if it's a driver issue of the stk1160 or a generic ehci issue. This is with a 3.15-mergewindow kernel (pull of Linus his tree of today). -- Sander [5.587759] [ cut here ] [5.591210] WARNING: CPU: 0 PID: 1376 at lib/dma-debug.c:1153 check_for_stack+0xa0/0x100() [5.596612] ehci-pci :00:0a.0: DMA-API: device driver maps memory fromstack [addr=88003d0b56bf] [5.602548] Modules linked in: [5.605380] CPU: 0 PID: 1376 Comm: khubd Not tainted 3.14.0-security-20140413-v4lall+ #1 [5.611042] Hardware name: Xen HVM domU, BIOS 4.5-unstable 04/10/2014 [5.615314] 0009 88003d0b5348 81c516fe 88003d0b5390 [5.622147] 88003d0b5380 810e4aa3 88003ceae898 88003cf14070 [5.628926] 88003d0b56bf 88003ceae898 8241ab40 88003d0b53e0 [5.635536] Call Trace: [5.638001] [] dump_stack+0x45/0x56 [5.641633] [] warn_slowpath_common+0x73/0x90 [5.645688] [] warn_slowpath_fmt+0x47/0x50 [5.649843] [] check_for_stack+0xa0/0x100 [5.652420] systemd-udevd[2143]: starting version 204 [5.657709] [] debug_dma_map_page+0xfc/0x150 [5.661836] [] usb_hcd_map_urb_for_dma+0x5fc/0x710 [5.666132] [] usb_hcd_submit_urb+0x315/0xa30 [5.670247] [] ? del_timer_sync+0x4a/0x60 [5.674072] [] ? schedule_timeout+0x14d/0x1f0 [5.678083] [] ? migrate_timer_list+0x60/0x60 [5.682167] [] usb_submit_urb+0x30c/0x580 [5.685989] [] ? wait_for_common+0x16b/0x240 [5.689919] [] usb_start_wait_urb+0x5a/0xe0 [5.693830] [] ? mpol_rebind_policy+0x30/0xa0 [5.697638] [] usb_control_msg+0xb8/0x100 [5.701468] [] stk1160_read_reg+0x52/0x80 [5.705358] [] stk1160_i2c_busy_wait+0x6c/0x90 [5.709656] [] stk1160_i2c_xfer+0x1cb/0x440 [5.713647] [] ? irq_to_desc+0x12/0x20 [5.717515] [] ? irq_get_irq_data+0x9/0x10 [5.721432] [] __i2c_transfer+0x5c/0x80 [5.725783] [] i2c_transfer+0x5b/0x90 [5.730187] [] i2c_smbus_xfer_emulated+0x116/0x570 [5.735194] [] ? wake_up_process+0x1e/0x40 [5.739631] [] ? wait_for_common+0x16b/0x240 [5.744338] [] ? __wake_up+0x3f/0x50 [5.748997] [] i2c_smbus_xfer+0xf2/0x140 [5.753538] [] i2c_default_probe+0xc3/0x100 [5.758173] [] ? i2c_check_addr_busy+0x36/0x60 [5.763227] [] i2c_new_probed_device+0x92/0xe0 [5.768736] [] ? i2c_smbus_xfer+0x140/0x140 [5.774035] [] v4l2_i2c_new_subdev_board+0x4f/0x100 [5.779495] [] v4l2_i2c_new_subdev+0x58/0x70 [5.784638] [] stk1160_probe+0x3df/0x4e0 [5.789553] [] usb_probe_interface+0xca/0x1d0 [5.794659] [] really_probe+0x56/0x1e0 [5.799231] [] ? really_probe+0x1e0/0x1e0 [5.804225] [] __device_attach+0x48/0x50 [5.809514] [] bus_for_each_drv+0x53/0x90 [5.814602] [] device_attach+0x88/0xa0 [5.819487] [] bus_probe_device+0x98/0xc0 [5.824337] [] device_add+0x4bc/0x5c0 [5.829267] [] usb_set_configuration+0x495/0x7a0 [5.834590] [] generic_probe+0x29/0xa0 [5.839419] [] usb_probe_device+0x15/0x20 [5.844594] [] really_probe+0x56/0x1e0 [5.849538] [] ? really_probe+0x1e0/0x1e0 [5.85] [] __device_attach+0x48/0x50 [5.859393] [] bus_for_each_drv+0x53/0x90 [5.864390] [] device_attach+0x88/0xa0 [5.869408] [] bus_probe_device+0x98/0xc0 [5.874652] [] device_add+0x4bc/0x5c0 [5.879185] [] usb_new_device+0x228/0x390 [5.884283] [] hub_thread+0xdb0/0x14e0 [5.888638] [] ? try_to_wake_up+0x100/0x2c0 [5.892802] [] ? abort_exclusive_wait+0xa0/0xa0 [5.896554] [] ? usb_reset_device+0x180/0x180 [5.900309] [] kthread+0xcd/0xf0 [5.903619] [] ? kthread_create_on_node+0x170/0x170 [5.908064] [] ret_from_fork+0x7c/0xb0 [5.912017] [] ? kthread_create_on_node+0x170/0x170 [5.916654] ---[ end trace 18f58175dc2f3152 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] Prefer gspca_sonixb over sn9c102 for all devices
Hi,
On 04/11/2014 09:15 AM, Jean Delvare wrote:
> The sn9c102 driver is deprecated. It was moved to staging in
> anticipation of its removal in a future kernel version. However, USB
> devices 0C45:6024 and 0C45:6025 are still handled by sn9c102 when
> both sn9c102 and gspca_sonixb are enabled.
>
> We must migrate all the users of these devices to the gspca_sonixb
> driver now, so that it gets sufficient testing before the sn9c102
> driver is finally phased out.
>
> Signed-off-by: Jean Delvare
> Cc: Hans de Goede
> Cc: Mauro Carvalho Chehab
> Cc: Luca Risolia
> Cc: Greg Kroah-Hartman
> ---
> I consider this a bug fix, I believe it should go upstream ASAP.
Agreed:
Acked-by: Hans de Goede
Mauro, can you pick this up directly, or do you want a pull-req from me
for this?
Regards,
Hans
>
> drivers/media/usb/gspca/sonixb.c |2 --
> drivers/staging/media/sn9c102/sn9c102_devtable.h |2 --
> 2 files changed, 4 deletions(-)
>
> --- linux-3.15-rc0.orig/drivers/media/usb/gspca/sonixb.c 2014-04-11
> 08:57:26.932408285 +0200
> +++ linux-3.15-rc0/drivers/media/usb/gspca/sonixb.c 2014-04-11
> 09:02:32.151943578 +0200
> @@ -1430,10 +1430,8 @@ static const struct usb_device_id device
> {USB_DEVICE(0x0c45, 0x600d), SB(PAS106, 101)},
> {USB_DEVICE(0x0c45, 0x6011), SB(OV6650, 101)},
> {USB_DEVICE(0x0c45, 0x6019), SB(OV7630, 101)},
> -#if !IS_ENABLED(CONFIG_USB_SN9C102)
> {USB_DEVICE(0x0c45, 0x6024), SB(TAS5130CXX, 102)},
> {USB_DEVICE(0x0c45, 0x6025), SB(TAS5130CXX, 102)},
> -#endif
> {USB_DEVICE(0x0c45, 0x6027), SB(OV7630, 101)}, /* Genius Eye 310 */
> {USB_DEVICE(0x0c45, 0x6028), SB(PAS202, 102)},
> {USB_DEVICE(0x0c45, 0x6029), SB(PAS106, 102)},
> --- linux-3.15-rc0.orig/drivers/staging/media/sn9c102/sn9c102_devtable.h
> 2014-04-11 08:57:26.932408285 +0200
> +++ linux-3.15-rc0/drivers/staging/media/sn9c102/sn9c102_devtable.h
> 2014-04-11 09:02:32.151943578 +0200
> @@ -48,10 +48,8 @@ static const struct usb_device_id sn9c10
> { SN9C102_USB_DEVICE(0x0c45, 0x600d, BRIDGE_SN9C102), },
> /* { SN9C102_USB_DEVICE(0x0c45, 0x6011, BRIDGE_SN9C102), }, OV6650 */
> { SN9C102_USB_DEVICE(0x0c45, 0x6019, BRIDGE_SN9C102), },
> -#endif
> { SN9C102_USB_DEVICE(0x0c45, 0x6024, BRIDGE_SN9C102), },
> { SN9C102_USB_DEVICE(0x0c45, 0x6025, BRIDGE_SN9C102), },
> -#if !defined CONFIG_USB_GSPCA_SONIXB && !defined
> CONFIG_USB_GSPCA_SONIXB_MODULE
> { SN9C102_USB_DEVICE(0x0c45, 0x6028, BRIDGE_SN9C102), },
> { SN9C102_USB_DEVICE(0x0c45, 0x6029, BRIDGE_SN9C102), },
> { SN9C102_USB_DEVICE(0x0c45, 0x602a, BRIDGE_SN9C102), },
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
