Re: [linux-firmware] [GIT PULL] amlogic: add video decoder firmwares

[Josh Boyer]

On Mon, Oct 1, 2018 at 11:27 AM Maxime Jourdan  wrote:
>
> Hello,
>
> Below is a pull request to add the firmwares required by the Amlogic video
> decoder.
>
> The firmwares were dumped from GPLv2+ in-kernel source files from Amlogic's
> vendor kernel, in their buildroot package
> "buildroot_openlinux_kernel_4.9_wayland_20180316"
>
> You can find an example of such a file in an older kernel here:
> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/drivers/amlogic/amports/arch/ucode/mpeg12/vmpeg12_mc.c
>
> The corresponding driver is currently being upstreamed:
> https://lore.kernel.org/patchwork/cover/993093/
>
> Regards,
> Maxime
>
> The following changes since commit 7c81f23ad903f72e87e2102d8f52408305c0f7a2:
>
>   ti-connectivity: add firmware for CC2560(A) Bluetooth (2018-10-01 10:08:30 
> -0400)
>
> are available in the Git repository at:
>
>   https://github.com/Elyotna/linux-firmware.git

This seems questionable to me.  You have the license listed as GPLv2
or later, which is what the header file originally had but you have no
corresponding source included in your commit and it's completely
unclear who would be fulfilling the GPL obligations around this.  Even
less clear is how one would take whatever source is provided and turn
them back into the binaries you've provided.  Have you contacted AM
Logic to see if they can post the firmware files themselves or confirm
the license should be GPLv2?

josh

> for you to fetch changes up to b99cf8dcfb6e7a3dd00bdb6aa4f6c71cb6b42e58:
>
>   amlogic: add video decoder firmwares (2018-10-01 17:06:18 +0200)
>
> 
> Maxime Jourdan (1):
>   amlogic: add video decoder firmwares
>
>  WHENCE  |  16 
>  amlogic/gx/h263_mc  | Bin 0 -> 16384 bytes
>  amlogic/gx/vh265_mc | Bin 0 -> 16384 bytes
>  amlogic/gx/vh265_mc_mmu | Bin 0 -> 16384 bytes
>  amlogic/gx/vmjpeg_mc| Bin 0 -> 16384 bytes
>  amlogic/gx/vmpeg12_mc   | Bin 0 -> 16384 bytes
>  amlogic/gx/vmpeg4_mc_5  | Bin 0 -> 16384 bytes
>  amlogic/gxbb/vh264_mc   | Bin 0 -> 36864 bytes
>  amlogic/gxl/vh264_mc| Bin 0 -> 36864 bytes
>  amlogic/gxm/vh264_mc| Bin 0 -> 36864 bytes
>  10 files changed, 16 insertions(+)
>  create mode 100644 amlogic/gx/h263_mc
>  create mode 100644 amlogic/gx/vh265_mc
>  create mode 100644 amlogic/gx/vh265_mc_mmu
>  create mode 100644 amlogic/gx/vmjpeg_mc
>  create mode 100644 amlogic/gx/vmpeg12_mc
>  create mode 100644 amlogic/gx/vmpeg4_mc_5
>  create mode 100644 amlogic/gxbb/vh264_mc
>  create mode 100644 amlogic/gxl/vh264_mc
>  create mode 100644 amlogic/gxm/vh264_mc

Re: qcom: update firmware file for Venus on SDM845

[Josh Boyer]

On Fri, Aug 10, 2018 at 5:44 AM Vikash Garodia  wrote:
>
> hi,
>
> This pull request updates firmware files for Venus h/w codec found on the 
> Qualcomm SDM845 chipset.
>
> The following changes since commit 7b5835fd37630d18ac0c755329172f6a17c1af29:
>
>   linux-firmware: add firmware for mt76x2u (2018-07-30 07:20:31 -0400)
>
> are available in the git repository at:
>
>   https://github.com/vgarodia/venus_firmware_23 master
>
> for you to fetch changes up to 6ae7a5bf57f035aecc7613943528e52ada7e1e03:
>
>   qcom: update venus firmware files for v5.2 (2018-08-10 12:57:47 +0530)
>
> 
> Vikash Garodia (1):
>   qcom: update venus firmware files for v5.2
>
>  WHENCE   |   2 +-
>  qcom/venus-5.2/venus.b00 | Bin 212 -> 212 bytes
>  qcom/venus-5.2/venus.b01 | Bin 6600 -> 6600 bytes
>  qcom/venus-5.2/venus.b02 | Bin 819552 -> 837304 bytes
>  qcom/venus-5.2/venus.b03 | Bin 33536 -> 33640 bytes
>  qcom/venus-5.2/venus.mbn | Bin 865408 -> 883264 bytes
>  qcom/venus-5.2/venus.mdt | Bin 6812 -> 6812 bytes
>  7 files changed, 1 insertion(+), 1 deletion(-)

Pulled and pushed out.  Thanks.

josh

Re: qcom: add firmware file for Venus on SDM845

[Josh Boyer]

On Sat, May 26, 2018 at 4:18 AM Vikash Garodia  wrote:
>
> Hi Josh,
>
> On 2018-05-25 17:34, Josh Boyer wrote:
> > On Fri, May 25, 2018 at 7:03 AM Vikash Garodia
> > 
> > wrote:
> >
> >> This pull request adds firmware files for Venus h/w codec found on the
> > Qualcomm SDM845 chipset.
> >
> >> The following changes since commit
> > 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
> >
> >>Merge branch 'for-upstreaming-v1.7.2' of
> > https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22
> > -0400)
> >
> >> are available in the git repository at:
> >
> >
> >>https://github.com/vgarodia/linux-firmware master
> >
> >> for you to fetch changes up to
> >> d6088b9c9d7f49d3c6c43681190889eca0abdcce:
> >
> >>qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
> >
> >> 
> >> Vikash Garodia (1):
> >>qcom: add venus firmware files for v5.2
> >
> >>   WHENCE   |   9 +
> >>   qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
> >>   qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
> >>   qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
> >>   qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
> >>   qcom/venus-5.2/venus.b04 |   1 +
> >>   qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
> >>   qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
> >>   8 files changed, 10 insertions(+)
> >>   create mode 100644 qcom/venus-5.2/venus.b00
> >>   create mode 100644 qcom/venus-5.2/venus.b01
> >>   create mode 100644 qcom/venus-5.2/venus.b02
> >>   create mode 100644 qcom/venus-5.2/venus.b03
> >>   create mode 100644 qcom/venus-5.2/venus.b04
> >>   create mode 100644 qcom/venus-5.2/venus.mbn
> >>   create mode 100644 qcom/venus-5.2/venus.mdt
> >
> > The venus.mbn file isn't mentioned in WHENCE:
> >
> > [jwboyer@vader linux-firmware]$ ./check_whence.py
> > E: qcom/venus-5.2/venus.mbn not listed in WHENCE
> > [jwboyer@vader linux-firmware]$
> >
> > Can you fix that up and let me know when to re-pull?
> I have fixed the error and is ready to be re-pulled from the same git
> repository.
> I have noted the process to run check_whence.py before uploading the
> firmwares.
>
> Do i need to resend the pull request as the end commit is now changed to
> 7602644358157e4b89960472b6d59ffcc040ca52 ?

Nope.  Pulled and pushed out now.  Thanks.

josh

Re: qcom: add firmware file for Venus on SDM845

[Josh Boyer]

On Fri, May 25, 2018 at 7:03 AM Vikash Garodia 
wrote:

> This pull request adds firmware files for Venus h/w codec found on the
Qualcomm SDM845 chipset.

> The following changes since commit
2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:

>Merge branch 'for-upstreaming-v1.7.2' of
https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)

> are available in the git repository at:


>https://github.com/vgarodia/linux-firmware master

> for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:

>qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)

> 
> Vikash Garodia (1):
>qcom: add venus firmware files for v5.2

>   WHENCE   |   9 +
>   qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
>   qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
>   qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
>   qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
>   qcom/venus-5.2/venus.b04 |   1 +
>   qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
>   qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
>   8 files changed, 10 insertions(+)
>   create mode 100644 qcom/venus-5.2/venus.b00
>   create mode 100644 qcom/venus-5.2/venus.b01
>   create mode 100644 qcom/venus-5.2/venus.b02
>   create mode 100644 qcom/venus-5.2/venus.b03
>   create mode 100644 qcom/venus-5.2/venus.b04
>   create mode 100644 qcom/venus-5.2/venus.mbn
>   create mode 100644 qcom/venus-5.2/venus.mdt

The venus.mbn file isn't mentioned in WHENCE:

[jwboyer@vader linux-firmware]$ ./check_whence.py
E: qcom/venus-5.2/venus.mbn not listed in WHENCE
[jwboyer@vader linux-firmware]$

Can you fix that up and let me know when to re-pull?

josh

Re: pull request: linux-firmware: Update Mediatek MT8173 VPU firmware

[Josh Boyer]

On Wed, Jan 17, 2018 at 8:35 AM,   wrote:
> The following changes since commit 65b1c68c63f974d72610db38dfae49861117cae2:
>
>   wl18xx: update firmware file 8.9.0.0.76 (2018-01-04 10:06:01 -0500)
>
> are available in the git repository at:
>
>   https://github.com/pochun-lin/linux_fw_vpu_v1.0.8.git v1.0.8
>
> for you to fetch changes up to e72c23c9ff2ceeb3509cb6441cc81f0227edf06d:
>
>   mediatek: update MT8173 VPU firmware to 1.0.8 (2018-01-17 20:19:56 +0800)
>
> 
> pochun.lin (1):
>   mediatek: update MT8173 VPU firmware to 1.0.8

Pulled and pushed out.  If the firmware is versioned, perhaps that
version should be listed in the WHENCE file?  You might want to add
that in a future patch.

josh

ite-cir/nuvoton-cir circular locking dependency with v3.17-rc1-22-g480cadc2b7e0

[Josh Boyer]

Hi All,

I've been seeing the following lockdep splat on all of the 3.17
kernels I've tried so far on my Celeron and i7 based NUC machines.
Both the ite-cir and nuvoton-cir drivers seem to have similar issues,
so the problem may be in rc_core itself?  I'm hoping you all will have
better ideas.

Splats for both below.

josh

ite-cir:

[7.750478] ite_cir: Auto-detected model: ITE8713 CIR transceiver
[7.750484] ite_cir: Using model: ITE8713 CIR transceiver
[7.750490] ite_cir: TX-capable: 1
[7.750493] ite_cir: Sample period (ns): 8680
[7.750495] ite_cir: TX carrier frequency (Hz): 38000
[7.750498] ite_cir: TX duty cycle (%): 33
[7.750500] ite_cir: RX low carrier frequency (Hz): 0
[7.750503] ite_cir: RX high carrier frequency (Hz): 0
[7.813687] Registered IR keymap rc-rc6-mce
[7.815512] input: ITE8713 CIR transceiver as /devices/virtual/rc/rc0/input7
[7.817682] rc0: ITE8713 CIR transceiver as /devices/virtual/rc/rc0
[7.861333] IR RC6 protocol handler initialized
[7.864124] IR RC5(x/sz) protocol handler initialized
[7.869105] IR NEC protocol handler initialized
[7.885375] IR Sony protocol handler initialized
[7.886710] IR JVC protocol handler initialized
[7.892205] IR SANYO protocol handler initialized
[7.900678] IR Sharp protocol handler initialized
[7.917897] IR MCE Keyboard/mouse protocol handler initialized
[7.927969] lirc_dev: IR Remote Control driver registered, major 249
[7.944156] input: MCE IR Keyboard/Mouse (ite-cir) as
/devices/virtual/input/input8
[7.944191] ==
[7.944194] [ INFO: possible circular locking dependency detected ]
[7.944197] 3.17.0-0.rc1.git1.1.fc22.x86_64 #1 Not tainted
[7.944200] ---
[7.944203] systemd-udevd/301 is trying to acquire lock:
[7.944206]  (input_mutex){+.+.+.}, at: [81601357]
input_register_device+0x4b7/0x5b0
[7.944219]
but task is already holding lock:
[7.944222]  (ir_raw_handler_lock){+.+.+.}, at:
[a0078621] ir_raw_event_register+0x111/0x1b0 [rc_core]
[7.944233]
which lock already depends on the new lock.

[7.944237]
the existing dependency chain (in reverse order) is:
[7.944240]
- #3 (ir_raw_handler_lock){+.+.+.}:
[7.944247][810f9be9] lock_acquire+0x99/0x1d0
[7.944253][81819206] mutex_lock_nested+0x86/0x450
[7.944260][a0078621]
ir_raw_event_register+0x111/0x1b0 [rc_core]
[7.944265][a0077d30]
rc_register_device+0x520/0x610 [rc_core]
[7.944271][a01cd2be] ite_probe+0x45e/0x52c [ite_cir]
[7.944278][814bc445] pnp_device_probe+0x65/0xd0
[7.944284][8151d11d] driver_probe_device+0x12d/0x3d0
[7.944289][8151d493] __driver_attach+0x93/0xa0
[7.944293][8151aed3] bus_for_each_dev+0x73/0xc0
[7.944298][8151caee] driver_attach+0x1e/0x20
[7.944302][8151c6c8] bus_add_driver+0x188/0x260
[7.944306][8151df94] driver_register+0x64/0xf0
[7.944310][814bc270] pnp_register_driver+0x20/0x30
[7.944315][a01e2010] ite_init+0x10/0x1000 [ite_cir]
[7.944320][81002144] do_one_initcall+0xd4/0x210
[7.944326][8113d361] load_module+0x1c81/0x2720
[7.944331][8113dedf] SyS_init_module+0xdf/0x130
[7.944335][8181e2e9] system_call_fastpath+0x16/0x1b
[7.944341]
- #2 (dev-lock){+.+.+.}:
[7.944347][810f9be9] lock_acquire+0x99/0x1d0
[7.944351][81819206] mutex_lock_nested+0x86/0x450
[7.944356][a007633a] rc_open+0x2a/0x80 [rc_core]
[7.944362][a00763a5] ir_open+0x15/0x20 [rc_core]
[7.944367][815ff201] input_open_device+0x81/0xb0
[7.944371][814e8000] kbd_connect+0x70/0x90
[7.944377][81600e47] input_attach_handler+0x1b7/0x210
[7.944381][8160139b] input_register_device+0x4fb/0x5b0
[7.944385][a0077bb5]
rc_register_device+0x3a5/0x610 [rc_core]
[7.944391][a01cd2be] ite_probe+0x45e/0x52c [ite_cir]
[7.944397][814bc445] pnp_device_probe+0x65/0xd0
[7.944401][8151d11d] driver_probe_device+0x12d/0x3d0
[7.944406][8151d493] __driver_attach+0x93/0xa0
[7.944410][8151aed3] bus_for_each_dev+0x73/0xc0
[7.944414][8151caee] driver_attach+0x1e/0x20
[7.944418][8151c6c8] bus_add_driver+0x188/0x260
[7.944423][8151df94] driver_register+0x64/0xf0
[7.944427][814bc270] pnp_register_driver+0x20/0x30
[7.944431][a01e2010] ite_init+0x10/0x1000 [ite_cir]
[7.944437]

Re: udev breakages - was: Re: Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

[Josh Boyer]

On Wed, Oct 3, 2012 at 6:58 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls awa...@md.metrocast.net wrote:

 I don't know if you can remove the /sys/.../firmware ABI altogether, because 
 there is at least one, somewhat popular udev replacement that also uses it: 
 mdev

 http://git.busybox.net/busybox/plain/docs/mdev.txt

 Heh. That web doc documents /lib/firmware as being the place to be.

 That said, there's clearly enough variation here that I think that for
 now I won't take the step to disable the udev part. I'll do the patch
 to support direct filesystem firmware loading using the udev default
 paths, and that hopefully fixes the particular case people see with
 media modules.

As you probably noticed, we had a tester in the RH bug report success
with the commit you included yesterday.

Do you think this is something worth including in the stable kernels
after it gets some further testing during the merge window?  Perhaps
not that specific commit as there seems to be some additional changes
needed for configurable paths, etc, but a backport of the fleshed out
changeset might be wanted.

We have a new enough udev in Fedora 17 to hit this issue with 3.5 and
3.6 when we rebase.  I'm sure other distributions will be in similar
circumstances soon if they aren't already.  Udev isn't going to be
fixed, so having something working in these cases would be great.

josh
--
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

3.1/3.2 uvcvideo and Creative Live! Cam Optia AF

[Josh Boyer]

Hi Laurent,

We've had a bug report [1] in Fedora for a while now that the uvcvideo
driver no longer works on the Creative Live! Cam Optia AF (ID 041e:4058)
in the 3.1 and 3.2 kernels.  The bug has all the various output from
dmesg, lsusb, etc.

I'm wondering if there is anything further we can do to help diagnose
what might be going wrong here.

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=739448
--
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

[PATCH] [media] ttusb2: Don't use stack variables for DMA

[Josh Boyer]

The ttusb2_msg function uses on-stack variables to submit commands to
dvb_usb_generic.  This eventually gets to the DMA api layer and will throw a
traceback if the debugging options are set.

This allocates the temporary buffer variables with kzalloc instead.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=734506

Signed-off-by: Josh Boyer jwbo...@redhat.com
---
 drivers/media/dvb/dvb-usb/ttusb2.c |   17 +++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c 
b/drivers/media/dvb/dvb-usb/ttusb2.c
index ea4eab8..faed393 100644
--- a/drivers/media/dvb/dvb-usb/ttusb2.c
+++ b/drivers/media/dvb/dvb-usb/ttusb2.c
@@ -75,10 +75,18 @@ static int ttusb2_msg(struct dvb_usb_device *d, u8 cmd,
u8 *wbuf, int wlen, u8 *rbuf, int rlen)
 {
struct ttusb2_state *st = d-priv;
-   u8 s[wlen+4],r[64] = { 0 };
+   u8 *s, *r = NULL;
int ret = 0;
 
-   memset(s,0,wlen+4);
+   s = kzalloc(wlen+4, GFP_KERNEL);
+   if (!s)
+   return -ENOMEM;
+
+   r = kzalloc(64, GFP_KERNEL);
+   if (!r) {
+   kfree(s);
+   return -ENOMEM;
+   }
 
s[0] = 0xaa;
s[1] = ++st-id;
@@ -94,12 +102,17 @@ static int ttusb2_msg(struct dvb_usb_device *d, u8 cmd,
r[2] != cmd ||
(rlen  0  r[3] != rlen)) {
warn(there might have been an error during control message 
transfer. (rlen = %d, was %d),rlen,r[3]);
+   kfree(s);
+   kfree(r);
return -EIO;
}
 
if (rlen  0)
memcpy(rbuf, r[4], rlen);
 
+   kfree(s);
+   kfree(r);
+
return 0;
 }
 
-- 
1.7.6.4


--
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: Fix crash when linking entities

[Josh Boyer]

On Wed, Sep 07, 2011 at 12:29:08AM +0200, Laurent Pinchart wrote:
 The uvc_mc_register_entity() function wrongfully selects the
 media_entity associated with a UVC entity when creating links. This
 results in access to uninitialized media_entity structures and can hit a
 BUG_ON statement in media_entity_create_link(). Fix it.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/uvc/uvc_entity.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 This patch should fix a v3.0 regression that results in a kernel crash as
 reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637740 and
 https://bugzilla.redhat.com/show_bug.cgi?id=735437.
 
 Test results will be welcome.

I built a test kernel for Fedora with the patch and the submitter of the
above bug has reported that the issue seems to be fixed.

josh

 diff --git a/drivers/media/video/uvc/uvc_entity.c 
 b/drivers/media/video/uvc/uvc_entity.c
 index 48fea37..29e2399 100644
 --- a/drivers/media/video/uvc/uvc_entity.c
 +++ b/drivers/media/video/uvc/uvc_entity.c
 @@ -49,7 +49,7 @@ static int uvc_mc_register_entity(struct uvc_video_chain 
 *chain,
   if (remote == NULL)
   return -EINVAL;
  
 - source = (UVC_ENTITY_TYPE(remote) != UVC_TT_STREAMING)
 + source = (UVC_ENTITY_TYPE(remote) == UVC_TT_STREAMING)
  ? (remote-vdev ? remote-vdev-entity : NULL)
  : remote-subdev.entity;
   if (source == NULL)
 -- 
 Regards,
 
 Laurent Pinchart
 
--
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

Lockdep warning in ivtv driver in 3.1

[Josh Boyer]

Hi All,

We've gotten a report[1] that the ivtv driver is throwing a lockdep
warning when calling ivtv_gpio_init.  From what I can tell, it seems
like the lock being held twice is the one allocated for ivtv-cxhdl, but
I can't immediately see where it's locked and not unlocked in the
callstack path.

Does anyone have an idea where this could be happening?

[   28.556610] =
[   28.557007] [ INFO: possible recursive locking detected ]
[   28.557007] 3.1.0-0.rc0.git19.1.fc17.x86_64 #1
[   28.557007] -
[   28.557007] modprobe/684 is trying to acquire lock:
[   28.557007]  (hdl-lock){+.+...}, at: [a02919ba]
find_ref_lock+0x24/0x46 [videodev]
[   28.557007] 
[   28.557007] but task is already holding lock:
[   28.557007]  (hdl-lock){+.+...}, at: [a029380f]
v4l2_ctrl_add_handler+0x49/0x97 [videodev]
[   28.557007] 
[   28.557007] other info that might help us debug this:
[   28.557007]  Possible unsafe locking scenario:
[   28.557007] 
[   28.557007]CPU0
[   28.557007]
[   28.557007]   lock(hdl-lock);
[   28.557007]   lock(hdl-lock);
[   28.557007] 
[   28.557007]  *** DEADLOCK ***
[   28.557007] 
[   28.557007]  May be due to missing lock nesting notation
[   28.557007] 
[   28.557007] 3 locks held by modprobe/684:
[   28.557007]  #0:  (__lockdep_no_validate__){..}, at:
[81314d0c] __driver_attach+0x3b/0x82
[   28.557007]  #1:  (__lockdep_no_validate__){..}, at:
[81314d1a] __driver_attach+0x49/0x82
[   28.557007]  #2:  (hdl-lock){+.+...}, at: [a029380f]
v4l2_ctrl_add_handler+0x49/0x97 [videodev]
[   28.557007] 
[   28.557007] stack backtrace:
[   28.557007] Pid: 684, comm: modprobe Not tainted
3.1.0-0.rc0.git19.1.fc17.x86_64 #1
[   28.557007] Call Trace:
[   28.557007]  [8108eb06] __lock_acquire+0x917/0xcf7
[   28.557007]  [81014fbe] ? sched_clock+0x9/0xd
[   28.557007]  [8108dffc] ? mark_lock+0x2d/0x220
[   28.557007]  [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[   28.557007]  [8108f3dc] lock_acquire+0xf3/0x13e
[   28.584886]  [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[   28.585146]  [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[   28.585146]  [814f2523] __mutex_lock_common+0x5d/0x39a
[   28.585146]  [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[   28.585146]  [8108f6db] ? mark_held_locks+0x6d/0x95
[   28.585146]  [814f282f] ? __mutex_lock_common+0x369/0x39a
[   28.585146]  [8108f830] ? trace_hardirqs_on_caller+0x12d/0x164
[   28.585146]  [814f296f] mutex_lock_nested+0x40/0x45
[   28.585146]  [a02919ba] find_ref_lock+0x24/0x46 [videodev]
[   28.585146]  [a029367e] handler_new_ref+0x42/0x18a [videodev]
[   28.585146]  [a0293833] v4l2_ctrl_add_handler+0x6d/0x97 [videodev]
[   28.585146]  [a028f71b] v4l2_device_register_subdev+0x16c/0x257
[videodev]
[   28.585146]  [a02ddfe9] ivtv_gpio_init+0x14e/0x159 [ivtv]
[   28.585146]  [a02ebd57] ivtv_probe+0xdc4/0x1662 [ivtv]
[   28.585146]  [8108f6c3] ? mark_held_locks+0x55/0x95
[   28.585146]  [814f41df] ? _raw_spin_unlock_irqrestore+0x4d/0x61
[   28.585146]  [8126a12b] local_pci_probe+0x44/0x75
[   28.585146]  [8126acb1] pci_device_probe+0xd0/0xff
[   28.585146]  [81314bef] driver_probe_device+0x131/0x213
[   28.585146]  [81314d2f] __driver_attach+0x5e/0x82
[   28.585146]  [81314cd1] ? driver_probe_device+0x213/0x213
[   28.585146]  [81313c30] bus_for_each_dev+0x59/0x8f
[   28.585146]  [813147c3] driver_attach+0x1e/0x20
[   28.585146]  [813143db] bus_add_driver+0xd4/0x22a
[   28.585146]  [a02ff000] ? 0xa02fefff
[   28.585146]  [813151f2] driver_register+0x98/0x105
[   28.618302]  [a02ff000] ? 0xa02fefff
[   28.618302]  [8126b584] __pci_register_driver+0x66/0xd2
[   28.618302]  [a02ff000] ? 0xa02fefff
[   28.618302]  [a02ff078] module_start+0x78/0x1000 [ivtv]
[   28.618302]  [81002099] do_one_initcall+0x7f/0x13a
[   28.618302]  [a02ff000] ? 0xa02fefff
[   28.618302]  [8109a864] sys_init_module+0x114/0x267
[   28.618302]  [814fafc2] system_call_fastpath+0x16/0x1b

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=728316
--
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