media
Hi all, With a 3.19-rc3 kernel i'm running into the warning below on boot with a pvrusb2 device. It's hitting this warn: /* * Drivers MUST fill in device_caps, so check for this and * warn if it was forgotten. */ WARN_ON(!(cap-capabilities V4L2_CAP_DEVICE_CAPS) || !cap-device_caps); -- Sander [ 25.604846] [ cut here ] [ 25.622165] WARNING: CPU: 4 PID: 2133 at drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x3e/0x70() [ 25.654888] Modules linked in: [ 25.667494] CPU: 4 PID: 2133 Comm: v4l_id Not tainted 3.19.0-rc3-20150110-pciback-doflr+ #1 [ 25.695927] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 25.723022] 81fcf468 880546fefbc8 81bb3fc9 880544a83240 [ 25.748684] 880546fefc08 810c738d 880544a83240 [ 25.774301] 880546fefd38 80685600 880544b78e00 [ 25.799936] Call Trace: [ 25.810584] [81bb3fc9] dump_stack+0x45/0x57 [ 25.829319] [810c738d] warn_slowpath_common+0x8d/0xd0 [ 25.850669] [810c73e5] warn_slowpath_null+0x15/0x20 [ 25.871477] [81851fae] v4l_querycap+0x3e/0x70 [ 25.890692] [818513f4] __video_do_ioctl+0x284/0x300 [ 25.911478] [81103556] ? __lock_acquire+0x4e6/0x21a0 [ 25.932412] [818521d1] video_usercopy+0x1f1/0x4e0 [ 25.952525] [81851170] ? v4l_printk_ioctl+0xa0/0xa0 [ 25.973136] [811018dd] ? trace_hardirqs_on+0xd/0x10 [ 25.993791] [818524d0] video_ioctl2+0x10/0x20 [ 26.012844] [81892df7] pvr2_v4l2_ioctl+0xa7/0x180 [ 26.032939] [8184e2ff] v4l2_ioctl+0x12f/0x150 [ 26.051927] [811d6163] do_vfs_ioctl+0x83/0x5b0 [ 26.071161] [811d3321] ? final_putname+0x21/0x50 [ 26.090911] [81bbf995] ? sysret_check+0x22/0x5d [ 26.110395] [811d66d7] SyS_ioctl+0x47/0x90 [ 26.128537] [81bbf969] system_call_fastpath+0x12/0x17 [ 26.149531] ---[ end trace 52e366625e9023ef ]--- [ 26.166528] [ cut here ] -- 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 v2] media: stk1160: Avoid stack-allocated buffer for control URBs
Friday, April 25, 2014, 11:51:53 PM, you wrote:
On Apr 17, Ezequiel Garcia wrote:
Currently stk1160_read_reg() uses a stack-allocated char to get the
read control value. This is wrong because usb_control_msg() requires
a kmalloc-ed buffer.
This commit fixes such issue by kmalloc'ating a 1-byte buffer to receive
the read value.
While here, let's remove the urb_buf array which was meant for a similar
purpose, but never really used.
Cc: Alan Stern st...@rowland.harvard.edu
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Ouch, I forgot to Cc Sander!
Sander, Here's the patch:
https://patchwork.linuxtv.org/patch/23660/
Maybe you can give it a ride and confirm it fixes the warning over there?
Also, have you observed any serious issues caused by this or just the
DMA API debug warning?
Hi Ezequiel,
Just tested with your v2 patch for a while and haven't seen the warning again
:-)
I don't remember for certain if it gave any serious issues .. since i have been
running with you v1 patch now for a while and it's on a test machine i use
infrequently.
--
Sander
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/media/usb/stk1160/stk1160-core.c | 10 +-
drivers/media/usb/stk1160/stk1160.h | 1 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-core.c
b/drivers/media/usb/stk1160/stk1160-core.c
index 34a26e0..03504dc 100644
--- a/drivers/media/usb/stk1160/stk1160-core.c
+++ b/drivers/media/usb/stk1160/stk1160-core.c
@@ -67,17 +67,25 @@ int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8
*value)
{
int ret;
int pipe = usb_rcvctrlpipe(dev-udev, 0);
+ u8 *buf;
*value = 0;
+
+ buf = kmalloc(sizeof(u8), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
ret = usb_control_msg(dev-udev, pipe, 0x00,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- 0x00, reg, value, sizeof(u8), HZ);
+ 0x00, reg, buf, sizeof(u8), HZ);
if (ret 0) {
stk1160_err(read failed on reg 0x%x (%d)\n,
reg, ret);
+ kfree(buf);
return ret;
}
+ *value = *buf;
+ kfree(buf);
return 0;
}
diff --git a/drivers/media/usb/stk1160/stk1160.h
b/drivers/media/usb/stk1160/stk1160.h
index 05b05b1..abdea48 100644
--- a/drivers/media/usb/stk1160/stk1160.h
+++ b/drivers/media/usb/stk1160/stk1160.h
@@ -143,7 +143,6 @@ struct stk1160 {
int num_alt;
struct stk1160_isoc_ctl isoc_ctl;
- char urb_buf[255]; /* urb control msg buffer */
/* frame properties */
int width;/* current frame width */
--
1.9.1
--
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
--
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
WARNING: CPU: 0 PID: 3918 at drivers/media/v4l2-core/videobuf2-core.c:2094 __vb2_queue_cancel+0x11d/0x180()
Hi, With a 3.15-rc3 kernel i seem to reliably trigger these warnings (which don't trigger on 3.14.2) when stopping a video stream. They don't seem to cause to much havoc because the devices are still usable after this. It seems to happen with both this syntek device as with em28xx devices. -- Sander [ 264.705467] stk1160: queue_setup: buffer count 8, each 691200 bytes [ 264.728032] stk1160: queue_setup: buffer count 8, each 691200 bytes [ 264.736159] stk1160: queue_setup: buffer count 8, each 691200 bytes [ 264.744373] stk1160: setting alternate 5 [ 264.748274] stk1160: minimum isoc packet size: 3072 (alt=5) [ 264.753377] stk1160: setting alt 5 with wMaxPacketSize=3072 [ 264.758958] stk1160: allocating urbs... [ 264.765254] stk1160: 16 urbs allocated [ 264.772243] stk1160: streaming started [ 270.523114] stk1160: killing 16 urbs... [ 270.656992] stk1160: all urbs killed [ 270.660639] stk1160: freeing 16 urb buffers... [ 270.664925] stk1160: all urb buffers freed [ 270.668891] stk1160: setting alternate 0 [ 270.675200] stk1160: buffer [88003b865000/7] aborted [ 270.678496] stk1160: buffer [88003b866400/0] aborted [ 270.678496] stk1160: buffer [88003b864400/1] aborted [ 270.678496] stk1160: buffer [88003b861000/2] aborted [ 270.678496] stk1160: buffer [88003b863800/3] aborted [ 270.678496] stk1160: buffer [88003b861c00/4] aborted [ 270.700760] stk1160: streaming stopped [ 270.703414] [ cut here ] [ 270.706603] WARNING: CPU: 0 PID: 3918 at drivers/media/v4l2-core/videobuf2-core.c:2094 __vb2_queue_cancel+0x11d/0x180() [ 270.713272] Modules linked in: [ 270.715907] CPU: 0 PID: 3918 Comm: videograbber.py Not tainted 3.15.0-rc3-security-20140428-v4lall-stkpatch+ #1 [ 270.721578] Hardware name: Xen HVM domU, BIOS 4.5-unstable 04/21/2014 [ 270.725238] 0009 88003d589c48 81c5277e [ 270.731505] 88003d589c80 810e4aa3 0001 [ 270.737774] 88003c3b13e0 88003d589c90 [ 270.744021] Call Trace: [ 270.746022] [81c5277e] dump_stack+0x45/0x56 [ 270.749420] [810e4aa3] warn_slowpath_common+0x73/0x90 [ 270.753934] [810e4b75] warn_slowpath_null+0x15/0x20 [ 270.758987] [8185067d] __vb2_queue_cancel+0x11d/0x180 [ 270.764168] [81850766] vb2_ioctl_streamoff+0x56/0x60 [ 270.769276] [81838785] v4l_streamoff+0x15/0x20 [ 270.774037] [8183c2c4] __video_do_ioctl+0x294/0x310 [ 270.779124] [81bdd2f6] ? unix_stream_sendmsg+0x3a6/0x3e0 [ 270.784460] [8183bd50] video_usercopy+0x1f0/0x4b0 [ 270.789411] [8183c030] ? video_ioctl2+0x20/0x20 [ 270.794193] [81ae0e1f] ? sock_aio_write+0xcf/0xe0 [ 270.799136] [811771eb] ? free_pages.part.69+0x3b/0x40 [ 270.804299] [8118fe6d] ? tlb_finish_mmu+0x2d/0x40 [ 270.809194] [8183c020] video_ioctl2+0x10/0x20 [ 270.813879] [818375ff] v4l2_ioctl+0x10f/0x150 [ 270.818407] [811d62e0] do_vfs_ioctl+0x2e0/0x4c0 [ 270.822878] [811c4b1c] ? vfs_write+0x17c/0x1e0 [ 270.827387] [811d64fc] SyS_ioctl+0x3c/0x80 [ 270.831927] [81c687b9] system_call_fastpath+0x16/0x1b [ 270.837545] ---[ end trace 8d6b91c80125b9e2 ]--- [ 270.842103] [ cut here ] [ 270.846562] WARNING: CPU: 0 PID: 3918 at drivers/media/v4l2-core/videobuf2-core.c:1165 vb2_buffer_done+0x163/0x170() [ 270.856204] Modules linked in: [ 270.859787] CPU: 0 PID: 3918 Comm: videograbber.py Tainted: GW 3.15.0-rc3-security-20140428-v4lall-stkpatch+ #1 [ 270.868591] Hardware name: Xen HVM domU, BIOS 4.5-unstable 04/21/2014 [ 270.873886] 0009 88003d589c10 81c5277e [ 270.882386] 88003d589c48 810e4aa3 88003b863000 88003c3b1460 [ 270.890943] 88003c3b13e0 0003 88003d589c58 [ 270.899446] Call Trace: [ 270.902102] [81c5277e] dump_stack+0x45/0x56 [ 270.906634] [810e4aa3] warn_slowpath_common+0x73/0x90 [ 270.911926] [810e4b75] warn_slowpath_null+0x15/0x20 [ 270.916783] [8184f493] vb2_buffer_done+0x163/0x170 [ 270.921378] [818506b7] __vb2_queue_cancel+0x157/0x180 [ 270.926030] [81850766] vb2_ioctl_streamoff+0x56/0x60 [ 270.931019] [81838785] v4l_streamoff+0x15/0x20 [ 270.935648] [8183c2c4] __video_do_ioctl+0x294/0x310 [ 270.940571] [81bdd2f6] ? unix_stream_sendmsg+0x3a6/0x3e0 [ 270.945806] [8183bd50] video_usercopy+0x1f0/0x4b0 [ 270.950581] [8183c030] ? video_ioctl2+0x20/0x20 [ 270.955479] [81ae0e1f] ? sock_aio_write+0xcf/0xe0 [ 270.960517] [811771eb] ? free_pages.part.69+0x3b/0x40 [ 270.965703] [8118fe6d] ? tlb_finish_mmu+0x2d/0x40 [ 270.970702] [8183c020] video_ioctl2+0x10/0x20 [ 270.975462]
Re: [PATCH] media: stk1160: Avoid stack-allocated buffer for control URBs
Monday, April 14, 2014, 6:41:05 PM, you wrote:
Currently stk1160_read_reg() uses a stack-allocated char to get the
read control value. This is wrong because usb_control_msg() requires
a kmalloc-ed buffer, and a DMA-API warning is produced:
WARNING: CPU: 0 PID: 1376 at lib/dma-debug.c:1153 check_for_stack+0xa0/0x100()
ehci-pci :00:0a.0: DMA-API: device driver maps memory fromstack
[addr=88003d0b56bf]
This commit fixes such issue by using a 'usb_ctrl_read' field embedded
in the device's struct to pass the value. In addition, we introduce a
mutex to protect the value.
While here, let's remove the urb_buf array which was meant for a similar
purpose, but never really used.
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Sander, Hans:
Does this cause any regressions, other than the DMA-API warning?
In that case, we can consider this as suitable for -stable.
Thanks !
Will test and report back later.
--
Sander
drivers/media/usb/stk1160/stk1160-core.c | 8 +++-
drivers/media/usb/stk1160/stk1160.h | 3 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-core.c
b/drivers/media/usb/stk1160/stk1160-core.c
index 34a26e0..cce91e7 100644
--- a/drivers/media/usb/stk1160/stk1160-core.c
+++ b/drivers/media/usb/stk1160/stk1160-core.c
@@ -69,15 +69,20 @@ int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8
*value)
int pipe = usb_rcvctrlpipe(dev-udev, 0);
*value = 0;
+
+ mutex_lock(dev-urb_ctrl_lock);
ret = usb_control_msg(dev-udev, pipe, 0x00,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- 0x00, reg, value, sizeof(u8), HZ);
+ 0x00, reg, dev-urb_ctrl_read, sizeof(u8), HZ);
if (ret 0) {
stk1160_err(read failed on reg 0x%x (%d)\n,
reg, ret);
+ mutex_unlock(dev-urb_ctrl_lock);
return ret;
}
+ *value = dev-urb_ctrl_read;
+ mutex_unlock(dev-urb_ctrl_lock);
return 0;
}
@@ -322,6 +327,7 @@ static int stk1160_probe(struct usb_interface *interface,
* because we register the device node as the *last* thing.
*/
spin_lock_init(dev-buf_lock);
+ mutex_init(dev-urb_ctrl_lock);
mutex_init(dev-v4l_lock);
mutex_init(dev-vb_queue_lock);
diff --git a/drivers/media/usb/stk1160/stk1160.h
b/drivers/media/usb/stk1160/stk1160.h
index 05b05b1..8886be4 100644
--- a/drivers/media/usb/stk1160/stk1160.h
+++ b/drivers/media/usb/stk1160/stk1160.h
@@ -143,7 +143,7 @@ struct stk1160 {
int num_alt;
struct stk1160_isoc_ctl isoc_ctl;
- char urb_buf[255]; /* urb control msg buffer */
+ char urb_ctrl_read;
/* frame properties */
int width;/* current frame width */
@@ -159,6 +159,7 @@ struct stk1160 {
struct i2c_adapter i2c_adap;
struct i2c_client i2c_client;
+ struct mutex urb_ctrl_lock; /* protects urb_ctrl_read */
struct mutex v4l_lock;
struct mutex vb_queue_lock;
spinlock_t buf_lock;
--
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] [81c516fe] dump_stack+0x45/0x56 [5.641633] [810e4aa3] warn_slowpath_common+0x73/0x90 [5.645688] [810e4b07] warn_slowpath_fmt+0x47/0x50 [5.649843] [81468820] check_for_stack+0xa0/0x100 [5.652420] systemd-udevd[2143]: starting version 204 [5.657709] [814699fc] debug_dma_map_page+0xfc/0x150 [5.661836] [8172109c] usb_hcd_map_urb_for_dma+0x5fc/0x710 [5.666132] [817214c5] usb_hcd_submit_urb+0x315/0xa30 [5.670247] [810ef85a] ? del_timer_sync+0x4a/0x60 [5.674072] [81c6291d] ? schedule_timeout+0x14d/0x1f0 [5.678083] [810ef2a0] ? migrate_timer_list+0x60/0x60 [5.682167] [81722fac] usb_submit_urb+0x30c/0x580 [5.685989] [81c63f4b] ? wait_for_common+0x16b/0x240 [5.689919] [817236fa] usb_start_wait_urb+0x5a/0xe0 [5.693830] [811b] ? mpol_rebind_policy+0x30/0xa0 [5.697638] [81723838] usb_control_msg+0xb8/0x100 [5.701468] [81984ab2] stk1160_read_reg+0x52/0x80 [5.705358] [8198690c] stk1160_i2c_busy_wait+0x6c/0x90 [5.709656] [81986afb] stk1160_i2c_xfer+0x1cb/0x440 [5.713647] [81126052] ? irq_to_desc+0x12/0x20 [5.717515] [81129329] ? irq_get_irq_data+0x9/0x10 [5.721432] [8178a1ac] __i2c_transfer+0x5c/0x80 [5.725783] [8178b48b] i2c_transfer+0x5b/0x90 [5.730187] [8178b676] i2c_smbus_xfer_emulated+0x116/0x570 [5.735194] [8110f8ce] ? wake_up_process+0x1e/0x40 [5.739631] [81c63f4b] ? wait_for_common+0x16b/0x240 [5.744338] [8111da6f] ? __wake_up+0x3f/0x50 [5.748997] [8178bbc2] i2c_smbus_xfer+0xf2/0x140 [5.753538] [8178bcd3] i2c_default_probe+0xc3/0x100 [5.758173] [8178a586] ? i2c_check_addr_busy+0x36/0x60 [5.763227] [8178a892] i2c_new_probed_device+0x92/0xe0 [5.768736] [8178bc10] ? i2c_smbus_xfer+0x140/0x140 [5.774035] [81844bdf] v4l2_i2c_new_subdev_board+0x4f/0x100 [5.779495] [81844ce8] v4l2_i2c_new_subdev+0x58/0x70 [5.784638] [81984fdf] stk1160_probe+0x3df/0x4e0 [5.789553] [81726dda] usb_probe_interface+0xca/0x1d0 [5.794659] [816408d6] really_probe+0x56/0x1e0 [5.799231] [81640a60] ? really_probe+0x1e0/0x1e0 [5.804225] [81640aa8] __device_attach+0x48/0x50 [5.809514] [8163ecf3] bus_for_each_drv+0x53/0x90 [5.814602] [81640868] device_attach+0x88/0xa0 [5.819487] [8163fe08] bus_probe_device+0x98/0xc0 [5.824337] [8163dfbc] device_add+0x4bc/0x5c0 [5.829267] [81725a15] usb_set_configuration+0x495/0x7a0 [5.834590] [8172eff9] generic_probe+0x29/0xa0 [5.839419] [81725db5] usb_probe_device+0x15/0x20 [5.844594] [816408d6] really_probe+0x56/0x1e0 [5.849538] [81640a60] ? really_probe+0x1e0/0x1e0 [5.85] [81640aa8] __device_attach+0x48/0x50 [5.859393] [8163ecf3] bus_for_each_drv+0x53/0x90 [5.864390] [81640868] device_attach+0x88/0xa0 [5.869408] [8163fe08] bus_probe_device+0x98/0xc0 [5.874652] [8163dfbc] device_add+0x4bc/0x5c0 [5.879185] [8171aec8] usb_new_device+0x228/0x390 [5.884283] [8171da60] hub_thread+0xdb0/0x14e0 [5.888638] [8110f6f0] ? try_to_wake_up+0x100/0x2c0 [5.892802] [8111dec0] ? abort_exclusive_wait+0xa0/0xa0 [5.896554] [8171ccb0] ? usb_reset_device+0x180/0x180 [5.900309] [81103e3d] kthread+0xcd/0xf0 [5.903619] [81103d70] ? kthread_create_on_node+0x170/0x170 [5.908064] [81c6754c] ret_from_fork+0x7c/0xb0 [5.912017] [81103d70] ? kthread_create_on_node+0x170/0x170 [5.916654] ---[ end trace 18f58175dc2f3152 ]--- -- To unsubscribe from this list: send the line
Re: [media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
Sunday, July 14, 2013, 11:41:13 AM, you wrote: Hi Sander, On 07/12/2013 10:56 PM, Sander Eikelenboom wrote: Friday, May 17, 2013, 11:52:17 AM, you wrote: On Fri May 17 2013 11:04:50 Sander Eikelenboom wrote: Friday, May 17, 2013, 10:25:24 AM, you wrote: On Thu May 16 2013 19:41:42 Sander Eikelenboom wrote: Hi Hans / Mauro, With 3.10.0-rc1 (including the cx25821 changes from Hans), I get the bug below which wasn't present with 3.9. How do I reproduce this? I've tried to, but I can't make this happen. Looking at the code I can't see how it could hit this bug anyway. I'm using motion to grab and process 6 from the video streams of the card i have (card with 8 inputs). It seems the cx25821 underwent quite some changes between 3.9 and 3.10. It did. And in the past there have been some more locking issues around mmap and media devices, although they seem to appear as circular locking dependencies and with different devices. - http://www.mail-archive.com/linux-media@vger.kernel.org/msg46217.html - Under kvm: http://www.spinics.net/lists/linux-media/msg63322.html Neither of those are related to this issue. - Perhaps that running in a VM could have to do with it ? - The driver on 3.9 occasionaly gives this, probably latency related (but continues to work): cx25821: cx25821_video_wakeup: 2 buffers handled (should be 1) Could it be something double unlocking in that path ? - Is there any extra debugging i could enable that could pinpoint the issue ? Try this patch: diff --git a/drivers/media/pci/cx25821/cx25821-core.c b/drivers/media/pci/cx25821/cx25821-core.c index b762c5b..8f8d0e0 100644 --- a/drivers/media/pci/cx25821/cx25821-core.c +++ b/drivers/media/pci/cx25821/cx25821-core.c @@ -1208,7 +1208,6 @@ void cx25821_free_buffer(struct videobuf_queue *q, struct cx25821_buffer *buf) struct videobuf_dmabuf *dma = videobuf_to_dma(buf-vb); BUG_ON(in_interrupt()); - videobuf_waiton(q, buf-vb, 0, 0); videobuf_dma_unmap(q-dev, dma); videobuf_dma_free(dma); btcx_riscmem_free(to_pci_dev(q-dev), buf-risc); I don't think the waiton is really needed for this driver. What really should happen is that videobuf is replaced by videobuf2 in this driver, but that's a fair amount of work. Hi Hans, After being busy for quite some time, i do have some spare time now. Since i'm still having trouble with this driver, is there a patch series for a similar driver that was converted to videobuf2 ? I don't know if it is entirely in my league, but i could give it a try when i have a example. The changes done for usb/em28xx might come close. That said, the cx25821 is already in decent shape to convert to vb2. At least the videobuf data structures are already in the correct place (they are often stored in a per-filehandle struct, which is wrong). Found the em28xx port to videobuf2 patch from Devin Heitmueller. Unfortunately the patch format isn't very neat as a example (due to reusing/renaming function parts) Apart from that the cx25821 also supports multiple channels / subdevices. From what i see one of the major changes is that the handling of the queue is now internal to and handled by videobuf2 ? include/media/videobuf2-core.h gives a reasonable overview of vb2. Like em28xx, you should use the vb2 helper functions (vb2_fop_* and vb2_ioctl_*) which takes a lot of the work off your hands. Converting cx25821-alsa.c may be the most difficult part as it is using some videobuf internal functions which probably won't translate to vb2 as is. I think videobuf is being abused here, but I don't know off-hand what the correct approach will be with vb2. I would ignore the alsa part for the time being (also the audio/video-upstream code, that's been disabled and without datasheets of the cx25821 I'm not sure it can be resurrected). If you can get cx25821-video.c to work with vb2, then we can take a look at the alsa code. Will do. Regards, Hans -- Sander -- 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: [media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
Friday, May 17, 2013, 11:52:17 AM, you wrote:
On Fri May 17 2013 11:04:50 Sander Eikelenboom wrote:
Friday, May 17, 2013, 10:25:24 AM, you wrote:
On Thu May 16 2013 19:41:42 Sander Eikelenboom wrote:
Hi Hans / Mauro,
With 3.10.0-rc1 (including the cx25821 changes from Hans), I get the bug
below which wasn't present with 3.9.
How do I reproduce this? I've tried to, but I can't make this happen.
Looking at the code I can't see how it could hit this bug anyway.
I'm using motion to grab and process 6 from the video streams of the card
i have (card with 8 inputs).
It seems the cx25821 underwent quite some changes between 3.9 and 3.10.
It did.
And in the past there have been some more locking issues around mmap and
media devices, although they seem to appear as circular locking dependencies
and with different devices.
- http://www.mail-archive.com/linux-media@vger.kernel.org/msg46217.html
- Under kvm: http://www.spinics.net/lists/linux-media/msg63322.html
Neither of those are related to this issue.
- Perhaps that running in a VM could have to do with it ?
- The driver on 3.9 occasionaly gives this, probably latency related (but
continues to work):
cx25821: cx25821_video_wakeup: 2 buffers handled (should be 1)
Could it be something double unlocking in that path ?
- Is there any extra debugging i could enable that could pinpoint the issue ?
Try this patch:
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index b762c5b..8f8d0e0 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1208,7 +1208,6 @@ void cx25821_free_buffer(struct videobuf_queue *q,
struct cx25821_buffer *buf)
struct videobuf_dmabuf *dma = videobuf_to_dma(buf-vb);
BUG_ON(in_interrupt());
- videobuf_waiton(q, buf-vb, 0, 0);
videobuf_dma_unmap(q-dev, dma);
videobuf_dma_free(dma);
btcx_riscmem_free(to_pci_dev(q-dev), buf-risc);
I don't think the waiton is really needed for this driver.
What really should happen is that videobuf is replaced by videobuf2 in this
driver, but that's a fair amount of work.
Hi Hans,
After being busy for quite some time, i do have some spare time now.
Since i'm still having trouble with this driver, is there a patch series for a
similar driver
that was converted to videobuf2 ?
I don't know if it is entirely in my league, but i could give it a try when i
have a example.
--
Sander
Regards,
Hans
--
Sander
Regards,
Hans
--
Sander
[ 53.004968] =
[ 53.004968] [ BUG: bad unlock balance detected! ]
[ 53.004968] 3.10.0-rc1-20130516-jens+ #1 Not tainted
[ 53.004968] -
[ 53.004968] motion/3328 is trying to release lock (dev-lock) at:
[ 53.004968] [819be5f9] mutex_unlock+0x9/0x10
[ 53.004968] but there are no more locks to release!
[ 53.004968]
[ 53.004968] other info that might help us debug this:
[ 53.004968] 1 lock held by motion/3328:
[ 53.004968] #0: (mm-mmap_sem){++}, at: [81156cae]
vm_munmap+0x3e/0x70
[ 53.004968]
[ 53.004968] stack backtrace:
[ 53.004968] CPU: 1 PID: 3328 Comm: motion Not tainted
3.10.0-rc1-20130516-jens+ #1
[ 53.004968] Hardware name: Xen HVM domU, BIOS 4.3-unstable 05/16/2013
[ 53.004968] 819be5f9 88002ac35c58 819b9029
88002ac35c88
[ 53.004968] 810e615e 88002ac35cb8 88002b7c18a8
819be5f9
[ 53.004968] 88002ac35d28 810eb17e
810e7ba5
[ 53.004968] Call Trace:
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [819b9029] dump_stack+0x19/0x1b
[ 53.004968] [810e615e] print_unlock_imbalance_bug+0xfe/0x110
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [810eb17e] lock_release_non_nested+0x1ce/0x320
[ 53.004968] [810e7ba5] ?
debug_check_no_locks_freed+0x105/0x1b0
[ 53.353529] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.353529] [810eb3cc] lock_release+0xfc/0x250
[ 53.353529] [819be4b2] __mutex_unlock_slowpath+0xb2/0x1f0
[ 53.353529] [819be5f9] mutex_unlock+0x9/0x10
[ 53.353529] [81711105] videobuf_waiton+0x55/0x230
[ 53.353529] [8114d052] ? tlb_finish_mmu+0x32/0x50
[ 53.353529] [81154a46] ? unmap_region+0xc6/0x100
[ 53.353529] [81172e05] ? kmem_cache_free+0x195/0x230
[ 53.353529] [8172d3d9] cx25821_free_buffer+0x49/0xa0
[ 53.353529] [8172f939] cx25821_buffer_release+0x9/0x10
[ 53.353529] [81712c35] videobuf_vm_close+0xc5/0x160
[ 53.353529] [81154aa5] remove_vma+0x25/0x60
[ 53.353529
Re: [media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
Friday, May 17, 2013, 10:25:24 AM, you wrote:
On Thu May 16 2013 19:41:42 Sander Eikelenboom wrote:
Hi Hans / Mauro,
With 3.10.0-rc1 (including the cx25821 changes from Hans), I get the bug
below which wasn't present with 3.9.
How do I reproduce this? I've tried to, but I can't make this happen.
Looking at the code I can't see how it could hit this bug anyway.
I'm using motion to grab and process 6 from the video streams of the card i
have (card with 8 inputs).
It seems the cx25821 underwent quite some changes between 3.9 and 3.10.
And in the past there have been some more locking issues around mmap and media
devices, although they seem to appear as circular locking dependencies and with
different devices.
- http://www.mail-archive.com/linux-media@vger.kernel.org/msg46217.html
- Under kvm: http://www.spinics.net/lists/linux-media/msg63322.html
- Perhaps that running in a VM could have to do with it ?
- The driver on 3.9 occasionaly gives this, probably latency related (but
continues to work):
cx25821: cx25821_video_wakeup: 2 buffers handled (should be 1)
Could it be something double unlocking in that path ?
- Is there any extra debugging i could enable that could pinpoint the issue ?
--
Sander
Regards,
Hans
--
Sander
[ 53.004968] =
[ 53.004968] [ BUG: bad unlock balance detected! ]
[ 53.004968] 3.10.0-rc1-20130516-jens+ #1 Not tainted
[ 53.004968] -
[ 53.004968] motion/3328 is trying to release lock (dev-lock) at:
[ 53.004968] [819be5f9] mutex_unlock+0x9/0x10
[ 53.004968] but there are no more locks to release!
[ 53.004968]
[ 53.004968] other info that might help us debug this:
[ 53.004968] 1 lock held by motion/3328:
[ 53.004968] #0: (mm-mmap_sem){++}, at: [81156cae]
vm_munmap+0x3e/0x70
[ 53.004968]
[ 53.004968] stack backtrace:
[ 53.004968] CPU: 1 PID: 3328 Comm: motion Not tainted
3.10.0-rc1-20130516-jens+ #1
[ 53.004968] Hardware name: Xen HVM domU, BIOS 4.3-unstable 05/16/2013
[ 53.004968] 819be5f9 88002ac35c58 819b9029
88002ac35c88
[ 53.004968] 810e615e 88002ac35cb8 88002b7c18a8
819be5f9
[ 53.004968] 88002ac35d28 810eb17e
810e7ba5
[ 53.004968] Call Trace:
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [819b9029] dump_stack+0x19/0x1b
[ 53.004968] [810e615e] print_unlock_imbalance_bug+0xfe/0x110
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [810eb17e] lock_release_non_nested+0x1ce/0x320
[ 53.004968] [810e7ba5] ? debug_check_no_locks_freed+0x105/0x1b0
[ 53.353529] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.353529] [810eb3cc] lock_release+0xfc/0x250
[ 53.353529] [819be4b2] __mutex_unlock_slowpath+0xb2/0x1f0
[ 53.353529] [819be5f9] mutex_unlock+0x9/0x10
[ 53.353529] [81711105] videobuf_waiton+0x55/0x230
[ 53.353529] [8114d052] ? tlb_finish_mmu+0x32/0x50
[ 53.353529] [81154a46] ? unmap_region+0xc6/0x100
[ 53.353529] [81172e05] ? kmem_cache_free+0x195/0x230
[ 53.353529] [8172d3d9] cx25821_free_buffer+0x49/0xa0
[ 53.353529] [8172f939] cx25821_buffer_release+0x9/0x10
[ 53.353529] [81712c35] videobuf_vm_close+0xc5/0x160
[ 53.353529] [81154aa5] remove_vma+0x25/0x60
[ 53.353529] [81156b67] do_munmap+0x307/0x410
[ 53.353529] [81156cbc] vm_munmap+0x4c/0x70
[ 53.353529] [81157c09] SyS_munmap+0x9/0x10
[ 53.353529] [819c20a9] system_call_fastpath+0x16/0x1b
--
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: [media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
Friday, May 17, 2013, 11:52:17 AM, you wrote:
On Fri May 17 2013 11:04:50 Sander Eikelenboom wrote:
Friday, May 17, 2013, 10:25:24 AM, you wrote:
On Thu May 16 2013 19:41:42 Sander Eikelenboom wrote:
Hi Hans / Mauro,
With 3.10.0-rc1 (including the cx25821 changes from Hans), I get the bug
below which wasn't present with 3.9.
How do I reproduce this? I've tried to, but I can't make this happen.
Looking at the code I can't see how it could hit this bug anyway.
I'm using motion to grab and process 6 from the video streams of the card
i have (card with 8 inputs).
It seems the cx25821 underwent quite some changes between 3.9 and 3.10.
It did.
And in the past there have been some more locking issues around mmap and
media devices, although they seem to appear as circular locking dependencies
and with different devices.
- http://www.mail-archive.com/linux-media@vger.kernel.org/msg46217.html
- Under kvm: http://www.spinics.net/lists/linux-media/msg63322.html
Neither of those are related to this issue.
- Perhaps that running in a VM could have to do with it ?
- The driver on 3.9 occasionaly gives this, probably latency related (but
continues to work):
cx25821: cx25821_video_wakeup: 2 buffers handled (should be 1)
Could it be something double unlocking in that path ?
- Is there any extra debugging i could enable that could pinpoint the issue ?
Try this patch:
Hmm it seems it's gone after pulling in linuses latest tree, with some
workqueue / rcu fixes.
(running without the patch underneath now)
Thx,
Sander
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index b762c5b..8f8d0e0 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1208,7 +1208,6 @@ void cx25821_free_buffer(struct videobuf_queue *q,
struct cx25821_buffer *buf)
struct videobuf_dmabuf *dma = videobuf_to_dma(buf-vb);
BUG_ON(in_interrupt());
- videobuf_waiton(q, buf-vb, 0, 0);
videobuf_dma_unmap(q-dev, dma);
videobuf_dma_free(dma);
btcx_riscmem_free(to_pci_dev(q-dev), buf-risc);
I don't think the waiton is really needed for this driver.
What really should happen is that videobuf is replaced by videobuf2 in this
driver, but that's a fair amount of work.
Regards,
Hans
--
Sander
Regards,
Hans
--
Sander
[ 53.004968] =
[ 53.004968] [ BUG: bad unlock balance detected! ]
[ 53.004968] 3.10.0-rc1-20130516-jens+ #1 Not tainted
[ 53.004968] -
[ 53.004968] motion/3328 is trying to release lock (dev-lock) at:
[ 53.004968] [819be5f9] mutex_unlock+0x9/0x10
[ 53.004968] but there are no more locks to release!
[ 53.004968]
[ 53.004968] other info that might help us debug this:
[ 53.004968] 1 lock held by motion/3328:
[ 53.004968] #0: (mm-mmap_sem){++}, at: [81156cae]
vm_munmap+0x3e/0x70
[ 53.004968]
[ 53.004968] stack backtrace:
[ 53.004968] CPU: 1 PID: 3328 Comm: motion Not tainted
3.10.0-rc1-20130516-jens+ #1
[ 53.004968] Hardware name: Xen HVM domU, BIOS 4.3-unstable 05/16/2013
[ 53.004968] 819be5f9 88002ac35c58 819b9029
88002ac35c88
[ 53.004968] 810e615e 88002ac35cb8 88002b7c18a8
819be5f9
[ 53.004968] 88002ac35d28 810eb17e
810e7ba5
[ 53.004968] Call Trace:
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [819b9029] dump_stack+0x19/0x1b
[ 53.004968] [810e615e] print_unlock_imbalance_bug+0xfe/0x110
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [810eb17e] lock_release_non_nested+0x1ce/0x320
[ 53.004968] [810e7ba5] ?
debug_check_no_locks_freed+0x105/0x1b0
[ 53.353529] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.353529] [810eb3cc] lock_release+0xfc/0x250
[ 53.353529] [819be4b2] __mutex_unlock_slowpath+0xb2/0x1f0
[ 53.353529] [819be5f9] mutex_unlock+0x9/0x10
[ 53.353529] [81711105] videobuf_waiton+0x55/0x230
[ 53.353529] [8114d052] ? tlb_finish_mmu+0x32/0x50
[ 53.353529] [81154a46] ? unmap_region+0xc6/0x100
[ 53.353529] [81172e05] ? kmem_cache_free+0x195/0x230
[ 53.353529] [8172d3d9] cx25821_free_buffer+0x49/0xa0
[ 53.353529] [8172f939] cx25821_buffer_release+0x9/0x10
[ 53.353529] [81712c35] videobuf_vm_close+0xc5/0x160
[ 53.353529] [81154aa5] remove_vma+0x25/0x60
[ 53.353529] [81156b67] do_munmap+0x307/0x410
[ 53.353529] [81156cbc] vm_munmap+0x4c/0x70
[ 53.353529] [81157c09] SyS_munmap+0x9/0x10
[media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
Hi Hans / Mauro,
With 3.10.0-rc1 (including the cx25821 changes from Hans), I get the bug below
which wasn't present with 3.9.
--
Sander
[ 53.004968] =
[ 53.004968] [ BUG: bad unlock balance detected! ]
[ 53.004968] 3.10.0-rc1-20130516-jens+ #1 Not tainted
[ 53.004968] -
[ 53.004968] motion/3328 is trying to release lock (dev-lock) at:
[ 53.004968] [819be5f9] mutex_unlock+0x9/0x10
[ 53.004968] but there are no more locks to release!
[ 53.004968]
[ 53.004968] other info that might help us debug this:
[ 53.004968] 1 lock held by motion/3328:
[ 53.004968] #0: (mm-mmap_sem){++}, at: [81156cae]
vm_munmap+0x3e/0x70
[ 53.004968]
[ 53.004968] stack backtrace:
[ 53.004968] CPU: 1 PID: 3328 Comm: motion Not tainted
3.10.0-rc1-20130516-jens+ #1
[ 53.004968] Hardware name: Xen HVM domU, BIOS 4.3-unstable 05/16/2013
[ 53.004968] 819be5f9 88002ac35c58 819b9029
88002ac35c88
[ 53.004968] 810e615e 88002ac35cb8 88002b7c18a8
819be5f9
[ 53.004968] 88002ac35d28 810eb17e
810e7ba5
[ 53.004968] Call Trace:
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [819b9029] dump_stack+0x19/0x1b
[ 53.004968] [810e615e] print_unlock_imbalance_bug+0xfe/0x110
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [810eb17e] lock_release_non_nested+0x1ce/0x320
[ 53.004968] [810e7ba5] ? debug_check_no_locks_freed+0x105/0x1b0
[ 53.353529] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.353529] [810eb3cc] lock_release+0xfc/0x250
[ 53.353529] [819be4b2] __mutex_unlock_slowpath+0xb2/0x1f0
[ 53.353529] [819be5f9] mutex_unlock+0x9/0x10
[ 53.353529] [81711105] videobuf_waiton+0x55/0x230
[ 53.353529] [8114d052] ? tlb_finish_mmu+0x32/0x50
[ 53.353529] [81154a46] ? unmap_region+0xc6/0x100
[ 53.353529] [81172e05] ? kmem_cache_free+0x195/0x230
[ 53.353529] [8172d3d9] cx25821_free_buffer+0x49/0xa0
[ 53.353529] [8172f939] cx25821_buffer_release+0x9/0x10
[ 53.353529] [81712c35] videobuf_vm_close+0xc5/0x160
[ 53.353529] [81154aa5] remove_vma+0x25/0x60
[ 53.353529] [81156b67] do_munmap+0x307/0x410
[ 53.353529] [81156cbc] vm_munmap+0x4c/0x70
[ 53.353529] [81157c09] SyS_munmap+0x9/0x10
[ 53.353529] [819c20a9] system_call_fastpath+0x16/0x1b
--
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: [ 3960.758784] 1 lock held by motion/7776: [ 3960.758788] #0: (queue-mutex){......}, at: [ffffffff815c62d2] uvc_queue_enable+0x32/0xc0
Hello Laurent / Mauro,
I have updated to latest 3.4-rc5-tip, running multiple video grabbers.
I don't see anything specific to uvcvideo anymore, but i do get the possible
circular locking dependency below.
--
Sander
[ 96.257129] ==
[ 96.257129] [ INFO: possible circular locking dependency detected ]
[ 96.257129] 3.4.0-rc5-20120506+ #4 Not tainted
[ 96.257129] ---
[ 96.257129] motion/2289 is trying to acquire lock:
[ 96.257129] (dev-lock){+.+.+.}, at: [8156c04c]
v4l2_mmap+0xbc/0xd0
[ 96.257129]
[ 96.257129] but task is already holding lock:
[ 96.257129] (mm-mmap_sem){++}, at: [81113cca]
sys_mmap_pgoff+0x1ca/0x220
[ 96.257129]
[ 96.257129] which lock already depends on the new lock.
[ 96.257129]
[ 96.257129]
[ 96.257129] the existing dependency chain (in reverse order) is:
[ 96.257129]
[ 96.257129] - #1 (mm-mmap_sem){++}:
[ 96.257129][810aa972] __lock_acquire+0x3a2/0xc50
[ 96.257129][810ab2e8] lock_acquire+0xc8/0x110
[ 96.257129][81108cb8] might_fault+0x68/0x90
[ 96.257129][8156d2a1] video_usercopy+0x1d1/0x4e0
[ 96.257129][8156d5c0] video_ioctl2+0x10/0x20
[ 96.257129][8156c110] v4l2_ioctl+0xb0/0x180
[ 96.257129][8114dc3c] do_vfs_ioctl+0x9c/0x580
[ 96.257129][8114e16a] sys_ioctl+0x4a/0x80
[ 96.257129][81813039] system_call_fastpath+0x16/0x1b
[ 96.257129]
[ 96.257129] - #0 (dev-lock){+.+.+.}:
[ 96.257129][810aa529] validate_chain+0x1259/0x1300
[ 96.257129][810aa972] __lock_acquire+0x3a2/0xc50
[ 96.257129][810ab2e8] lock_acquire+0xc8/0x110
[ 96.257129][8180e58c]
mutex_lock_interruptible_nested+0x5c/0x550
[ 96.257129][8156c04c] v4l2_mmap+0xbc/0xd0
[ 96.257129][8111359a] mmap_region+0x3da/0x5a0
[ 96.257129][81113ab4] do_mmap_pgoff+0x354/0x3a0
[ 96.257129][81113ce9] sys_mmap_pgoff+0x1e9/0x220
[ 96.257129][81011ee9] sys_mmap+0x29/0x30
[ 96.257129][81813039] system_call_fastpath+0x16/0x1b
[ 96.257129]
[ 96.257129] other info that might help us debug this:
[ 96.257129]
[ 96.257129] Possible unsafe locking scenario:
[ 96.257129]
[ 96.257129]CPU0CPU1
[ 96.257129]
[ 96.257129] lock(mm-mmap_sem);
[ 96.257129]lock(dev-lock);
[ 96.257129]lock(mm-mmap_sem);
[ 96.257129] lock(dev-lock);
[ 96.257129]
[ 96.257129] *** DEADLOCK ***
[ 96.257129]
[ 96.257129] 1 lock held by motion/2289:
[ 96.257129] #0: (mm-mmap_sem){++}, at: [81113cca]
sys_mmap_pgoff+0x1ca/0x220
[ 96.257129]
[ 96.257129] stack backtrace:
[ 96.257129] Pid: 2289, comm: motion Not tainted 3.4.0-rc5-20120506+ #4
[ 96.257129] Call Trace:
[ 96.257129] [810a8fb6] print_circular_bug+0x206/0x300
[ 96.257129] [810aa529] validate_chain+0x1259/0x1300
[ 96.257129] [810a9417] ? validate_chain+0x147/0x1300
[ 96.257129] [810ab773] ? lock_release+0x113/0x260
[ 96.257129] [810aa972] __lock_acquire+0x3a2/0xc50
[ 96.257129] [810aa993] ? __lock_acquire+0x3c3/0xc50
[ 96.257129] [8156024c] ? tda18271_tune+0x71c/0x9c0
[ 96.257129] [810ab2e8] lock_acquire+0xc8/0x110
[ 96.257129] [8156c04c] ? v4l2_mmap+0xbc/0xd0
[ 96.257129] [8180e58c] mutex_lock_interruptible_nested+0x5c/0x550
[ 96.257129] [8156c04c] ? v4l2_mmap+0xbc/0xd0
[ 96.257129] [810a77ce] ? mark_held_locks+0x9e/0x130
[ 96.257129] [8156c04c] ? v4l2_mmap+0xbc/0xd0
[ 96.257129] [811134de] ? mmap_region+0x31e/0x5a0
[ 96.257129] [810a7900] ? lockdep_trace_alloc+0xa0/0x130
[ 96.257129] [8156c04c] v4l2_mmap+0xbc/0xd0
[ 96.257129] [8111359a] mmap_region+0x3da/0x5a0
[ 96.257129] [81113ab4] do_mmap_pgoff+0x354/0x3a0
[ 96.257129] [81113ce9] sys_mmap_pgoff+0x1e9/0x220
[ 96.257129] [8132554e] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 96.257129] [81011ee9] sys_mmap+0x29/0x30
Monday, April 30, 2012, 1:05:27 AM, you wrote:
Hi Sander,
On Saturday 28 April 2012 22:02:46 Sander Eikelenboom wrote:
Hi,
I'm using a webcam (logitech) supported by the uvcvideo module to capture
video. Previously once in a while I would get the uvcvideo: Failed to
resubmit video URB (-27)., but the grabbing continued without a problem.
Now the video grabbing program (motion) seems to lock due to some nested
lock if i interpret it right.
The uvcvideo driver doesn't use nested locks, this is just a normal locking
issue
[ 3960.758784] 1 lock held by motion/7776: [ 3960.758788] #0: (queue-mutex){......}, at: [ffffffff815c62d2] uvc_queue_enable+0x32/0xc0
Hi,
I'm using a webcam (logitech) supported by the uvcvideo module to capture video.
Previously once in a while I would get the uvcvideo: Failed to resubmit video
URB (-27)., but the grabbing continued without a problem.
Now the video grabbing program (motion) seems to lock due to some nested lock
if i interpret it right.
Additional problem is that i don't really know what kernel version was still
OK, so can't help with that info.
This is on a vanilla 3.4 RC kernel latest commit:
c629eaf8392b676b4f83c3dc344e66402bfeec92
--
Sander
[ 3696.753490] ehci_hcd :09:00.1: request 880016091400 would overflow
(3923+31 = 3936)
[ 3696.753494] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753563] ehci_hcd :09:00.1: request 880016091800 would overflow
(3922+31 = 3936)
[ 3696.753566] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753609] ehci_hcd :09:00.1: request 880016090800 would overflow
(3922+31 = 3936)
[ 3696.753611] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753645] ehci_hcd :09:00.1: request 880016090c00 would overflow
(3922+31 = 3936)
[ 3696.753647] uvcvideo: Failed to resubmit video URB (-27).
[ 3696.753656] ehci_hcd :09:00.1: request 880016091000 would overflow
(3922+31 = 3936)
[ 3696.753657] uvcvideo: Failed to resubmit video URB (-27).
[ 3960.758154] INFO: task motion:7776 blocked for more than 120 seconds.
[ 3960.758168] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 3960.758174] motion D 0201 0 7776 1 0x
[ 3960.758183] 8800239d9b68 0216 eaa50018
810a451b
[ 3960.758192] 88002392cf60 00012600 8800239d9fd8
8800239d8010
[ 3960.758200] 00012600 00012600 8800239d9fd8
00012600
[ 3960.758209] Call Trace:
[ 3960.758219] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758226] [814e0048] ? hub_suspend+0xf8/0x130
[ 3960.758232] [814f0024] ? usbdev_do_ioctl+0x194/0x1000
[ 3960.758238] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758244] [8108ba01] ? get_parent_ip+0x11/0x50
[ 3960.758250] [8108d6cd] ? sub_preempt_count+0x9d/0xd0
[ 3960.758257] [815c02d2] ? hdpvr_probe+0x6c2/0xa30
[ 3960.758264] [817f8e84] schedule+0x24/0x70
[ 3960.758269] [817f9363] schedule_preempt_disabled+0x13/0x20
[ 3960.758275] [817f77c7] mutex_lock_nested+0x1a7/0x420
[ 3960.758281] [815c62d2] ? uvc_queue_enable+0x32/0xc0
[ 3960.758287] [815c62d2] uvc_queue_enable+0x32/0xc0
[ 3960.758292] [815c941f] uvc_video_enable+0x12f/0x180
[ 3960.758298] [815c7b55] uvc_v4l2_do_ioctl+0x555/0x1190
[ 3960.758304] [816c5668] ? sock_update_classid+0xa8/0x120
[ 3960.758310] [816c1d7e] ? sock_sendmsg+0xee/0x120
[ 3960.758316] [81561996] video_usercopy+0x186/0x4c0
[ 3960.758322] [815c7600] ? uvc_v4l2_set_streamparm+0x190/0x190
[ 3960.758327] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758333] [810a559f] ? lock_release+0xff/0x210
[ 3960.758338] [8108ba01] ? get_parent_ip+0x11/0x50
[ 3960.758344] [815c6bc4] uvc_v4l2_ioctl+0x24/0x70
[ 3960.758349] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 3960.758740] [8116e474] ? fsnotify+0x84/0x360
[ 3960.758745] [81560850] v4l2_ioctl+0xb0/0x180
[ 3960.758751] [81145213] do_vfs_ioctl+0x93/0x500
[ 3960.758756] [810a559f] ? lock_release+0xff/0x210
[ 3960.758762] [81134ba7] ? fget_light+0xd7/0x140
[ 3960.758768] [81134b0b] ? fget_light+0x3b/0x140
[ 3960.758773] [811456ca] sys_ioctl+0x4a/0x80
[ 3960.758778] [817fb0f9] system_call_fastpath+0x16/0x1b
[ 3960.758784] 1 lock held by motion/7776:
[ 3960.758788] #0: (queue-mutex){..}, at: [815c62d2]
uvc_queue_enable+0x32/0xc0
[ 4080.758504] INFO: task motion:7776 blocked for more than 120 seconds.
[ 4080.758518] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 4080.758524] motion D 0201 0 7776 1 0x
[ 4080.758532] 8800239d9b68 0216 eaa50018
810a451b
[ 4080.758540] 88002392cf60 00012600 8800239d9fd8
8800239d8010
[ 4080.758547] 00012600 00012600 8800239d9fd8
00012600
[ 4080.758555] Call Trace:
[ 4080.758564] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 4080.758570] [814e0048] ? hub_suspend+0xf8/0x130
[ 4080.758576] [814f0024] ? usbdev_do_ioctl+0x194/0x1000
[ 4080.758581] [810a451b] ? __lock_acquire+0x5b/0xc00
[ 4080.758587] [8108ba01] ? get_parent_ip+0x11/0x50
[ 4080.758592] [8108d6cd] ? sub_preempt_count+0x9d/0xd0
[ 4080.758597] [815c02d2] ? hdpvr_probe+0x6c2/0xa30
[ 4080.758603] [817f8e84] schedule+0x24/0x70
[ 4080.758608] [817f9363]
Kernel support for CX25853 and CX25821 combination (8/16 channel dvr h264 pcie capture cards)
Hi Hans/Mauro, Is there any support for the combination of CX25853 and CX25821 (8/16 channel dvr h264 pcie capture cards) ? I have found some old references to some development http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/9982 And a ancient tree referenced in that post: http://linuxtv.org/hg/~mchehab/cx25821/ But it's unclear to what has become of it, can't find reference on the v4l/linuxtv wiki. -- Sander -- 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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Hello Devin, Yes it's completely reproducible for a change: ffmpeg -f video4linux -r 25 -s 720x576 -i /dev/video0 out.flv gave an error: serveerstertje:/mnt/software/software# ffmpeg -f video4linux -r 25 -s 720x576 -i /dev/video0 out.flv FFmpeg version r11872+debian_0.svn20080206-18+lenny1, Copyright (c) 2000-2008 Fa brice Bellard, et al. configuration: --enable-gpl --enable-libfaad --enable-pp --enable-swscaler --e nable-x11grab --prefix=/usr --enable-libgsm --enable-libtheora --enable-libvorbi s --enable-pthreads --disable-strip --enable-libdc1394 --enable-shared --disable -static libavutil version: 49.6.0 libavcodec version: 51.50.0 libavformat version: 52.7.0 libavdevice version: 52.0.0 built on Jan 25 2010 18:27:39, gcc: 4.3.2 Input #0, video4linux, from '/dev/video0': Duration: N/A, start: 1281511364.644674, bitrate: 165888 kb/s Stream #0.0: Video: rawvideo, yuyv422, 720x576 [PAR 0:1 DAR 0:1], 165888 kb/ s, 25.00 tb(r) File 'out.flv' already exists. Overwrite ? [y/N] y Output #0, flv, to 'out.flv': Stream #0.0: Video: flv, yuv420p, 720x576 [PAR 0:1 DAR 0:1], q=2-31, 200 kb/ s, 25.00 tb(c) Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding VIDIOCMCAPTURE: Invalid argument frame=1 fps= 0 q=3.0 Lsize= 38kB time=0.0 bitrate=7687.6kbits/s video:37kB audio:0kB global headers:0kB muxing overhead 0.530927% So I tried just: ffmpeg -i /dev/video0 out.flv That makes it oops allways and instantly. -- Sander Wednesday, August 11, 2010, 4:33:28 AM, you wrote: On Tue, Aug 10, 2010 at 6:57 PM, Sander Eikelenboom li...@eikelenboom.it wrote: Hello Devin, It's a k-world, which used to work fine (altough with another program, but I can't use that since it seems at least 2 other bugs prevent me from using my VM's :-) It's this model http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248modid=6pcid=47ifid=17prodid=104 Tried to grab with ffmpeg. Is it reproducible? Or did it just happen once? If you have a sequence to reproduce, can you provide the command line you used, etc? Devin -- Best regards, Sandermailto:li...@eikelenboom.it -- 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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Hello Devin, Yes i can confirm it was my mistake, with video4linux2 it works. -- Sander Wednesday, August 11, 2010, 8:31:56 PM, you wrote: On Wed, Aug 11, 2010 at 12:46 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 11-08-2010 12:58, Pete Eberlein escreveu: On Wed, 2010-08-11 at 09:25 +0200, Sander Eikelenboom wrote: Hello Devin, Yes it's completely reproducible for a change: ffmpeg -f video4linux -r 25 -s 720x576 -i /dev/video0 out.flv gave an error: Use -f video4linux2. The -f video4linux option uses the old video4linux1 API. I have seen similar strange behavior when I used that ffmpeg option with a v4l2 driver I am developing. Also, ffmpeg does not use libv4l. Still, we have a bug to fix. The driver shouldn't generating a PANIC if accessed via V4L1 API. I agree with Mauro completely. There is nothing userland should be able to do which results in a panic (and I have no reason to believe Pete was suggesting otherwise). That said, it's really useful to know that this is some sort of v4l1 backward compatibility problem. I'll see if I can reproduce this here. Thanks, Devin -- Best regards, Sandermailto:li...@eikelenboom.it -- 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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
Hello Devin, It's a k-world, which used to work fine (altough with another program, but I can't use that since it seems at least 2 other bugs prevent me from using my VM's :-) It's this model http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248modid=6pcid=47ifid=17prodid=104 Tried to grab with ffmpeg. -- Sander Wednesday, August 11, 2010, 12:45:20 AM, you wrote: Hello Sander, Which application were you using, and specifically which em28xx based product do you have? Devin On Tue, Aug 10, 2010 at 6:12 PM, Sander Eikelenboom li...@eikelenboom.it wrote: Hi, While trying to test try and report about some other bugs, i ran into this kernel panic when trying to grab video from my usb 2.0 em28xx videgrabber connected to a usb 2.0 port. Complete serial log attachted. [ 279.680018] general protection fault: [#1] SMP [ 279.683901] last sysfs file: /sys/devices/pci:00/:00:12.2/usb1/1-5/i2c-0/name [ 279.683901] CPU 5 [ 279.683901] Modules linked in: xt_multiport ipt_REJECT xt_recent xt_limit xt_tcpudp powernow_k8 mperf xt_state ipt_MA SQUERADE ipt_LOG iptable_mangle iptable_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_d efrag_ipv4 fuse hwmon_vid loop saa7115 snd_cmipci gameport snd_opl3_lib snd_hwdep snd_mpu401_uart snd_rawmidi em28xx v4l 2_common snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_seq_device videodev snd_timer snd v4l1_compat v4l 2_compat_ioctl32 videobuf_vmalloc videobuf_core psmouse tpm_tis joydev evdev tveeprom serio_raw shpchp edac_core i2c_pii x4 soundcore pcspkr i2c_core pci_hotplug wmi snd_page_alloc processor button sd_mod r8169 thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 279.683901] [ 279.683901] Pid: 0, comm: swapper Not tainted 2.6.352.6.35-vanilla-xhci-isoc+ #6 890FXA-GD70 (MS-7640) /MS-7640 [ 279.683901] RIP: 0010:[a004fbc5] [a004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx] [ 279.683901] RSP: 0018:880001b43c68 EFLAGS: 00010082 [ 279.683901] RAX: dead00200200 RBX: 0804 RCX: 880229625818 [ 279.683901] RDX: dead00100100 RSI: 0003 RDI: 880229625868 [ 279.683901] RBP: 880001b43d08 R08: R09: 0804 [ 279.683901] R10: 880229597000 R11: R12: [ 279.683901] R13: 88022f158820 R14: 880229597000 R15: 0344 [ 279.683901] FS: 7fa4bd3706e0() GS:880001b4() knlGS: [ 279.683901] CS: 0010 DS: ES: CR0: 8005003b [ 279.683901] CR2: 7fa4bd35f000 CR3: 00022a9ad000 CR4: 06e0 [ 279.683901] DR0: DR1: DR2: [ 279.683901] DR3: DR6: 0ff0 DR7: 0400 [ 279.683901] Process swapper (pid: 0, threadinfo 880237d4a000, task 880237d2f7a0) [ 279.683901] Stack: [ 279.683901] 8103d7a3 880001b43cb0 0082 8802375e2188 [ 279.683901] 0 0804 880229625818 880229597a40 880229597a90 [ 279.683901] 0 c90010b72000 002237d2 880229597000 [ 279.683901] Call Trace: [ 279.683901] IRQ [ 279.683901] [8103d7a3] ? enqueue_task+0x77/0x87 [ 279.683901] [a0053398] em28xx_irq_callback+0x7e/0xfe [em28xx] [ 279.683901] [81359415] usb_hcd_giveback_urb+0x84/0xb8 [ 279.683901] [8136b51b] ehci_urb_done+0xcf/0xe4 [ 279.683901] [8136cd15] ehci_work+0x504/0x8da [ 279.683901] [81370fda] ehci_irq+0x19c/0x1ce [ 279.683901] [81358bd1] usb_hcd_irq+0x3e/0x83 [ 279.683901] [8108782c] handle_IRQ_event+0x58/0x136 [ 279.683901] [81089414] handle_fasteoi_irq+0x92/0xd2 [ 279.683901] [8100b241] handle_irq+0x1f/0x2a [ 279.683901] [8100a884] do_IRQ+0x5a/0xc1 [ 279.683901] [8146c953] ret_from_intr+0x0/0x11 [ 279.683901] EOI [ 279.683901] [a0044740] ? acpi_idle_enter_simple+0x130/0x168 [processor] [ 279.683901] [a004473c] ? acpi_idle_enter_simple+0x12c/0x168 [processor] [ 279.683901] [813ad822] cpuidle_idle_call+0x9b/0xfd [ 279.683901] [81007868] cpu_idle+0x51/0x84 [ 279.683901] [81466d1b] start_secondary+0x1c0/0x1c5 [ 279.683901] Code: 83 ef 80 e8 69 39 01 e1 48 8b 4d 88 49 c7 86 18 0b 00 00 00 00 00 00 be 03 00 00 00 48 8b 51 40 48 8b 41 48 48 89 cf 48 83 c7 50 48 89 42 08 48 89 10 48 b8 00 01 10 00 00 00 ad de 48 89 41 40 [ 279.683901] RIP [a004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx] [ 279.683901] RSP 880001b43c68 [ 279.683901] ---[ end trace 0f55a03076b067cf ]--- [ 279.683901] Kernel panic - not syncing: Fatal exception in interrupt [ 279.683901] Pid: 0, comm: swapper Tainted: G D 2.6.352.6.35-vanilla-xhci-isoc+ #6
Re: [em28xx] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [ffffffffa00997be] :ir_common:ir_input_free+0x26/0x3e
Hello Mauro, With the patch the NULL pointer dereference is fixed. Thx, Sander Sunday, December 6, 2009, 1:53:40 AM, you wrote: Sander Eikelenboom wrote: Hi All, Tried to update my v4l-dvb modules today, but got a bug with my pinnacle card, seems to be related to the recent changes in the ir code. I have added dmesg output of the bug (changeset a871d61b614f tip), and dmesg output of the previous modules (working). -- Sander Dec 5 23:30:25 security kernel: [5.596128] em28xx: New device Pinnacle Systems GmbH PCTV USB2 PAL @ 480 Mbps (2304:0208, interface 0, class 0) Dec 5 23:30:25 security kernel: [5.596535] em28xx #1: chip ID is em2820 (or em2710) Dec 5 23:30:25 security kernel: [5.726154] em28xx #1: i2c eeprom 00: 1a eb 67 95 04 23 08 02 10 00 1e 03 98 1e 6a 2e Dec 5 23:30:25 security kernel: [5.726181] em28xx #1: i2c eeprom 10: 00 00 06 57 6e 00 00 00 8e 00 00 00 07 00 00 00 Dec 5 23:30:25 security kernel: [5.726203] em28xx #1: i2c eeprom 20: 16 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726226] em28xx #1: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726247] em28xx #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726270] em28xx #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726290] em28xx #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 2e 03 50 00 69 00 Dec 5 23:30:25 security kernel: [5.726312] em28xx #1: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 Dec 5 23:30:25 security kernel: [5.726333] em28xx #1: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 20 00 47 00 Dec 5 23:30:25 security kernel: [5.726354] em28xx #1: i2c eeprom 90: 6d 00 62 00 48 00 00 00 1e 03 50 00 43 00 54 00 Dec 5 23:30:25 security kernel: [5.726376] em28xx #1: i2c eeprom a0: 56 00 20 00 55 00 53 00 42 00 32 00 20 00 50 00 Dec 5 23:30:25 security kernel: [5.726397] em28xx #1: i2c eeprom b0: 41 00 4c 00 00 00 06 03 31 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726420] em28xx #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726440] em28xx #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726461] em28xx #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726484] em28xx #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 07 56 d9 35 01 ed 0b f8 Dec 5 23:30:25 security kernel: [5.726506] em28xx #1: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x0fd77740 Dec 5 23:30:25 security kernel: [5.726513] em28xx #1: EEPROM info: Dec 5 23:30:25 security kernel: [5.726517] em28xx #1: AC97 audio (5 sample rates) Dec 5 23:30:25 security kernel: [5.726522] em28xx #1: 500mA max power Dec 5 23:30:25 security kernel: [5.726528] em28xx #1: Table at 0x06, strings=0x1e98, 0x2e6a, 0x Dec 5 23:30:25 security kernel: [5.726534] em28xx #1: Identified as Pinnacle PCTV USB 2 (card=3) Dec 5 23:30:25 security kernel: [5.735698] BUG: unable to handle kernel NULL pointer dereference at Dec 5 23:30:25 security kernel: [5.735716] IP: [a00997be] :ir_common:ir_input_free+0x26/0x3e Dec 5 23:30:25 security kernel: [5.735736] PGD 1fdcb067 PUD 1f65d067 PMD 0 Dec 5 23:30:25 security kernel: [5.735744] Oops: [1] SMP Dec 5 23:30:25 security kernel: [5.735750] CPU 0 Dec 5 23:30:25 security kernel: [5.735754] Modules linked in: ir_kbd_i2c(+) saa7115 usbhid(+) hid ff_memless em28xx(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 ir_common videobuf_vmalloc videobuf_core tveeprom i2c_core evdev ext3 jbd mbcache ohci_hcd ohci1394 ieee1394 ehci_hcd uhci_hcd thermal_sys Dec 5 23:30:25 security kernel: [5.735793] Pid: 1091, comm: modprobe Not tainted 2.6.26-2-xen-amd64 #1 Dec 5 23:30:25 security kernel: [5.735798] RIP: e030:[a00997be] [a00997be] :ir_common:ir_input_free+0x26/0x3e It is weird to call ir_input_free during the boot. This means that something got wrong during IR initialization. Anyway, I think I know here's the bug: the first thing the routine does is this: struct ir_scancode_table *rc_tab = input_get_drvdata(dev); However, if ir_input_init() doesn't initialize fine, rc_tab will be null. Could you please test if the enclosed patch fixes the issue? --- Avoid usage of an initialized drvdata Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/linux/drivers/media/common/ir-keytable.c b/linux/drivers/media/common/ir-keytable.c --- a/linux/drivers/media/common/ir-keytable.c +++ b/linux/drivers/media/common/ir
[em28xx] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [ffffffffa00997be] :ir_common:ir_input_free+0x26/0x3e
Hi All, Tried to update my v4l-dvb modules today, but got a bug with my pinnacle card, seems to be related to the recent changes in the ir code. I have added dmesg output of the bug (changeset a871d61b614f tip), and dmesg output of the previous modules (working). -- Sander Dec 5 23:30:25 security kernel: [5.596128] em28xx: New device Pinnacle Systems GmbH PCTV USB2 PAL @ 480 Mbps (2304:0208, interface 0, class 0) Dec 5 23:30:25 security kernel: [5.596535] em28xx #1: chip ID is em2820 (or em2710) Dec 5 23:30:25 security kernel: [5.726154] em28xx #1: i2c eeprom 00: 1a eb 67 95 04 23 08 02 10 00 1e 03 98 1e 6a 2e Dec 5 23:30:25 security kernel: [5.726181] em28xx #1: i2c eeprom 10: 00 00 06 57 6e 00 00 00 8e 00 00 00 07 00 00 00 Dec 5 23:30:25 security kernel: [5.726203] em28xx #1: i2c eeprom 20: 16 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726226] em28xx #1: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726247] em28xx #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726270] em28xx #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726290] em28xx #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 2e 03 50 00 69 00 Dec 5 23:30:25 security kernel: [5.726312] em28xx #1: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 Dec 5 23:30:25 security kernel: [5.726333] em28xx #1: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 20 00 47 00 Dec 5 23:30:25 security kernel: [5.726354] em28xx #1: i2c eeprom 90: 6d 00 62 00 48 00 00 00 1e 03 50 00 43 00 54 00 Dec 5 23:30:25 security kernel: [5.726376] em28xx #1: i2c eeprom a0: 56 00 20 00 55 00 53 00 42 00 32 00 20 00 50 00 Dec 5 23:30:25 security kernel: [5.726397] em28xx #1: i2c eeprom b0: 41 00 4c 00 00 00 06 03 31 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726420] em28xx #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726440] em28xx #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726461] em28xx #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Dec 5 23:30:25 security kernel: [5.726484] em28xx #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 07 56 d9 35 01 ed 0b f8 Dec 5 23:30:25 security kernel: [5.726506] em28xx #1: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x0fd77740 Dec 5 23:30:25 security kernel: [5.726513] em28xx #1: EEPROM info: Dec 5 23:30:25 security kernel: [5.726517] em28xx #1: AC97 audio (5 sample rates) Dec 5 23:30:25 security kernel: [5.726522] em28xx #1: 500mA max power Dec 5 23:30:25 security kernel: [5.726528] em28xx #1: Table at 0x06, strings=0x1e98, 0x2e6a, 0x Dec 5 23:30:25 security kernel: [5.726534] em28xx #1: Identified as Pinnacle PCTV USB 2 (card=3) Dec 5 23:30:25 security kernel: [5.735698] BUG: unable to handle kernel NULL pointer dereference at Dec 5 23:30:25 security kernel: [5.735716] IP: [a00997be] :ir_common:ir_input_free+0x26/0x3e Dec 5 23:30:25 security kernel: [5.735736] PGD 1fdcb067 PUD 1f65d067 PMD 0 Dec 5 23:30:25 security kernel: [5.735744] Oops: [1] SMP Dec 5 23:30:25 security kernel: [5.735750] CPU 0 Dec 5 23:30:25 security kernel: [5.735754] Modules linked in: ir_kbd_i2c(+) saa7115 usbhid(+) hid ff_memless em28xx(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 ir_common videobuf_vmalloc videobuf_core tveeprom i2c_core evdev ext3 jbd mbcache ohci_hcd ohci1394 ieee1394 ehci_hcd uhci_hcd thermal_sys Dec 5 23:30:25 security kernel: [5.735793] Pid: 1091, comm: modprobe Not tainted 2.6.26-2-xen-amd64 #1 Dec 5 23:30:25 security kernel: [5.735798] RIP: e030:[a00997be] [a00997be] :ir_common:ir_input_free+0x26/0x3e Dec 5 23:30:25 security kernel: [5.735812] RSP: e02b:88001e12fd28 EFLAGS: 00010246 Dec 5 23:30:25 security kernel: [5.735817] RAX: RBX: RCX: Dec 5 23:30:25 security kernel: [5.735823] RDX: 0202 RSI: 7fff RDI: 88001f6b9000 Dec 5 23:30:25 security kernel: [5.735829] RBP: ffed R08: 8800016c9270 R09: 88001f6bca50 Dec 5 23:30:25 security kernel: [5.735835] R10: R11: a0080ec6 R12: 0063 Dec 5 23:30:25 security kernel: [5.735840] R13: 88001f6b9000 R14: 8800016c9008 R15: 88001f65e1a8 Dec 5 23:30:25 security kernel: [5.735848] FS: 7fe1b4eb76e0() GS:80539000() knlGS: Dec 5 23:30:25 security kernel: [5.735855] CS: e033 DS: ES: Dec 5 23:30:25 security kernel: [5.735860] DR0: DR1:
