Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Tuesday 06 September 2011 00:31:03 Sitsofe Wheeler wrote:
> On Mon, Sep 05, 2011 at 12:16:42PM +0200, Hans Verkuil wrote:
> > On Monday, September 05, 2011 12:13:26 Hans Verkuil wrote:
> > > The original order is correct, but what I missed is that for drivers
> > > that release (free) everything in the videodev release callback the
> > > v4l2_device struct is also freed and v4l2_device_put will fail.
> > >
> > > To fix this, add this code just before the vdev->release call:
> > > /* Do not call v4l2_device_put if there is no release callback set. */
> > > if (v4l2_dev->release == NULL)
> > >
> > > v4l2_dev = NULL;
> > >
> > > If there is no release callback, then the refcounting is pointless
> > > anyway.
> > >
> > > This should work.
> >
> > Note that in the long run using the v4l2_device release callback
> > instead of the videodev release is better. But it's a lot of work to
> > convert everything so that's long term. I'm quite surprised BTW that
> > this bug wasn't found much earlier.
>
> This inline patch fixes the second "poison overwritten" problem so:
> Tested-by: Sitsofe Wheeler
>
> However, it does not prevent the original oops that was reported in the
> original message. Yang Ruirui's patch in
> https://lkml.org/lkml/2011/9/1/74 seems to be required to resolve
> that initial problem - can it be ACK'd? Yang's patch is reproduced
> inline below:
>
> For uvc device, dev->vdev.dev is the &intf->dev,
> uvc_delete code is as below:
> usb_put_intf(dev->intf);
> usb_put_dev(dev->udev);
>
> uvc_status_cleanup(dev);
> uvc_ctrl_cleanup_device(dev);
>
> ## the intf dev is released above, so below code will oops.
>
> if (dev->vdev.dev)
> v4l2_device_unregister(&dev->vdev);
> Fix it by get_device in v4l2_device_register and put_device in
> v4l2_device_disconnect
Acked-by: Laurent Pinchart
> ---
> drivers/media/video/v4l2-device.c |2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/drivers/media/video/v4l2-device.c
> b/drivers/media/video/v4l2-device.c index c72856c..e6a2c3b 100644
> --- a/drivers/media/video/v4l2-device.c
> +++ b/drivers/media/video/v4l2-device.c
> @@ -38,6 +38,7 @@ int v4l2_device_register(struct device *dev, struct
> v4l2_device *v4l2_dev) mutex_init(&v4l2_dev->ioctl_lock);
> v4l2_prio_init(&v4l2_dev->prio);
> kref_init(&v4l2_dev->ref);
> + get_device(dev);
> v4l2_dev->dev = dev;
> if (dev == NULL) {
> /* If dev == NULL, then name must be filled in by the caller */
> @@ -93,6 +94,7 @@ void v4l2_device_disconnect(struct v4l2_device *v4l2_dev)
>
> if (dev_get_drvdata(v4l2_dev->dev) == v4l2_dev)
> dev_set_drvdata(v4l2_dev->dev, NULL);
> + put_device(v4l2_dev->dev);
> v4l2_dev->dev = NULL;
> }
> EXPORT_SYMBOL_GPL(v4l2_device_disconnect);
--
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
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Tue, Sep 6, 2011 at 6:31 AM, Sitsofe Wheeler wrote:
> On Mon, Sep 05, 2011 at 12:16:42PM +0200, Hans Verkuil wrote:
>> On Monday, September 05, 2011 12:13:26 Hans Verkuil wrote:
>> >
>> > The original order is correct, but what I missed is that for drivers
>> > that release (free) everything in the videodev release callback the
>> > v4l2_device struct is also freed and v4l2_device_put will fail.
>> >
>> > To fix this, add this code just before the vdev->release call:
>> >
>> > /* Do not call v4l2_device_put if there is no release callback set. */
>> > if (v4l2_dev->release == NULL)
>> > v4l2_dev = NULL;
>> >
>> > If there is no release callback, then the refcounting is pointless
>> > anyway.
>> >
>> > This should work.
>>
>> Note that in the long run using the v4l2_device release callback
>> instead of the videodev release is better. But it's a lot of work to
>> convert everything so that's long term. I'm quite surprised BTW that
>> this bug wasn't found much earlier.
>
> This inline patch fixes the second "poison overwritten" problem so:
> Tested-by: Sitsofe Wheeler
Confirmed
>
> However, it does not prevent the original oops that was reported in the
> original message. Yang Ruirui's patch in
> https://lkml.org/lkml/2011/9/1/74 seems to be required to resolve
> that initial problem - can it be ACK'd? Yang's patch is reproduced
> inline below:
Thanks, If it's ok, I can resend it as inline.
>
> For uvc device, dev->vdev.dev is the &intf->dev,
> uvc_delete code is as below:
> usb_put_intf(dev->intf);
> usb_put_dev(dev->udev);
>
> uvc_status_cleanup(dev);
> uvc_ctrl_cleanup_device(dev);
>
> ## the intf dev is released above, so below code will oops.
>
> if (dev->vdev.dev)
> v4l2_device_unregister(&dev->vdev);
> Fix it by get_device in v4l2_device_register and put_device in
> v4l2_device_disconnect
> ---
> drivers/media/video/v4l2-device.c | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/drivers/media/video/v4l2-device.c
> b/drivers/media/video/v4l2-device.c
> index c72856c..e6a2c3b 100644
> --- a/drivers/media/video/v4l2-device.c
> +++ b/drivers/media/video/v4l2-device.c
> @@ -38,6 +38,7 @@ int v4l2_device_register(struct device *dev, struct
> v4l2_device *v4l2_dev)
> mutex_init(&v4l2_dev->ioctl_lock);
> v4l2_prio_init(&v4l2_dev->prio);
> kref_init(&v4l2_dev->ref);
> + get_device(dev);
> v4l2_dev->dev = dev;
> if (dev == NULL) {
> /* If dev == NULL, then name must be filled in by the caller */
> @@ -93,6 +94,7 @@ void v4l2_device_disconnect(struct v4l2_device *v4l2_dev)
>
> if (dev_get_drvdata(v4l2_dev->dev) == v4l2_dev)
> dev_set_drvdata(v4l2_dev->dev, NULL);
> + put_device(v4l2_dev->dev);
> v4l2_dev->dev = NULL;
> }
> EXPORT_SYMBOL_GPL(v4l2_device_disconnect);
>
> --
> Sitsofe | http://sucs.org/~sits/
>
--
Regards
Yang RuiRui
--
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: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Mon, Sep 05, 2011 at 12:16:42PM +0200, Hans Verkuil wrote:
> On Monday, September 05, 2011 12:13:26 Hans Verkuil wrote:
> >
> > The original order is correct, but what I missed is that for drivers
> > that release (free) everything in the videodev release callback the
> > v4l2_device struct is also freed and v4l2_device_put will fail.
> >
> > To fix this, add this code just before the vdev->release call:
> >
> > /* Do not call v4l2_device_put if there is no release callback set. */
> > if (v4l2_dev->release == NULL)
> > v4l2_dev = NULL;
> >
> > If there is no release callback, then the refcounting is pointless
> > anyway.
> >
> > This should work.
>
> Note that in the long run using the v4l2_device release callback
> instead of the videodev release is better. But it's a lot of work to
> convert everything so that's long term. I'm quite surprised BTW that
> this bug wasn't found much earlier.
This inline patch fixes the second "poison overwritten" problem so:
Tested-by: Sitsofe Wheeler
However, it does not prevent the original oops that was reported in the
original message. Yang Ruirui's patch in
https://lkml.org/lkml/2011/9/1/74 seems to be required to resolve
that initial problem - can it be ACK'd? Yang's patch is reproduced
inline below:
For uvc device, dev->vdev.dev is the &intf->dev,
uvc_delete code is as below:
usb_put_intf(dev->intf);
usb_put_dev(dev->udev);
uvc_status_cleanup(dev);
uvc_ctrl_cleanup_device(dev);
## the intf dev is released above, so below code will oops.
if (dev->vdev.dev)
v4l2_device_unregister(&dev->vdev);
Fix it by get_device in v4l2_device_register and put_device in
v4l2_device_disconnect
---
drivers/media/video/v4l2-device.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index c72856c..e6a2c3b 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -38,6 +38,7 @@ int v4l2_device_register(struct device *dev, struct
v4l2_device *v4l2_dev)
mutex_init(&v4l2_dev->ioctl_lock);
v4l2_prio_init(&v4l2_dev->prio);
kref_init(&v4l2_dev->ref);
+ get_device(dev);
v4l2_dev->dev = dev;
if (dev == NULL) {
/* If dev == NULL, then name must be filled in by the caller */
@@ -93,6 +94,7 @@ void v4l2_device_disconnect(struct v4l2_device *v4l2_dev)
if (dev_get_drvdata(v4l2_dev->dev) == v4l2_dev)
dev_set_drvdata(v4l2_dev->dev, NULL);
+ put_device(v4l2_dev->dev);
v4l2_dev->dev = NULL;
}
EXPORT_SYMBOL_GPL(v4l2_device_disconnect);
--
Sitsofe | http://sucs.org/~sits/
--
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: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
- Original message -
> On Monday, September 05, 2011 11:59:03 Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 02 September 2011 09:29:08 Sitsofe Wheeler wrote:
> > > On Fri, Sep 02, 2011 at 01:35:49PM +0800, Dave Young wrote:
> > > > On Fri, Sep 2, 2011 at 12:59 PM, Dave Young wrote:
> > > > > On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote:
> > > > > > On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote:
> > > > > > > On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote:
> > > > > > > > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by
> > > > > > > > unplugging a
> > > > > > >
> > > > > > > > USB webcam. See below:
> > > > > > > Could you try the attached patch?
> > > > > >
> > > > > > This patch fixed the oops but extending the sequence (enable
> > > > > > camera, start cheese, disable camera, watch cheese pause,
> > > > > > enable camera, quit cheese, start cheese) causes the following
> > > > > > "poison overwritten" warning
> > > > >
> > > > > > to appear:
> > > > > It seems another bug, I can reproduce this as well.
> > > > >
> > > > > uvc_device is freed in uvc_delete,
> > > > >
> > > > > struct v4l2_device vdev is the member of struct uvc_device, so
> > > > > vdev is also freed. Later v4l2_device operations on vdev will
> > > > > overwrite the poison memory area.
> > > >
> > > > Please try attached patch on top of previous one, in this patch I
> > > > move v4l2_device_put after vdev->release in function
> > > > v4l2_device_release
> > > >
> > > > Not sure if this is a right fix, comments?
> >
> > (inlining the patch's contents)
> >
> > > > diff --git a/drivers/media/video/v4l2-dev.c
> > > > b/drivers/media/video/v4l2- dev.c
> > > > index 98cee19..541dba3 100644
> > > > --- a/drivers/media/video/v4l2-dev.c
> > > > +++ b/drivers/media/video/v4l2-dev.c
> > > > @@ -172,13 +172,14 @@ static void v4l2_device_release(struct
> > > > device *cd) media_device_unregister_entity(&vdev->entity);
> > > > #endif
> > > >
> > > > + /* Decrease v4l2_device refcount */
> > > > + if (vdev->v4l2_dev)
> > > > + v4l2_device_put(vdev->v4l2_dev);
> > > > +
> > > > /* Release video_device and perform other
> > > > cleanups as needed. */
> > > > vdev->release(vdev);
> > > >
> > > > - /* Decrease v4l2_device refcount */
> > > > - if (vdev->v4l2_dev)
> > > > - v4l2_device_put(vdev->v4l2_dev);
> > > > }
> > > >
> > > > static struct class video_class = {
> >
> > v4l2_device_put() got introduced in commit
> > bedf8bcf6b4f90a6e31add3721a2e71877289381 ("v4l2-device: add kref and a
> > release function"). If I understand its purpose correctly, drivers
> > that use a v4l2_device instance should use the v4l2_device release
> > callback to release device structures instead of counting
> > video_device release callbacks manually. In that case I think the
> > v4l2-dev.c code is correct, and all drivers that use v4l2_device
> > should be fixed.
> >
> > The above patch fixes the problem in a central location, but seems to
> > defeat the original purpose of v4l2_device_get/put().
> >
> > Hans, could you please comment on that ?
>
> The original order is correct, but what I missed is that for drivers
> that release (free) everything in the videodev release callback the
> v4l2_device struct is also freed and v4l2_device_put will fail.
>
> To fix this, add this code just before the vdev->release call:
>
> /* Do not call v4l2_device_put if there is no release callback set. */
> if (v4l2_dev->release == NULL)
> v4l2_dev = NULL;
>
> If there is no release callback, then the refcounting is pointless
> anyway.
>
> This should work.
>
thanks, will test tommorrow
> Regards,
>
> Hans
>
> >
> > > >
> > > > > > [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129
> > > > > > (04f2:b071) [ 191.277965] input: CNF7129 as
> > > > > > /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9
> > > > > > [ 220.287366]
> > > > > > =
> > > > > > [ 220.287379] BUG kmalloc-512: Poison overwritten
> > > > > > [ 220.287384]
> > > > > > -
> > > > > > [ 220.287387]
> > > > > > [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a
> > > > > > instead of 0x6b [ 220.287410] INFO: Allocated in
> > > > > > uvc_probe+0x54/0xd50 age=210617 cpu=0 pid=16 [ 220.287421]
> > > > > > T.974+0x29d/0x5e0 [ 220.287427] kmem_cache_alloc+0x167/0x180
> > > > > > [ 220.287433] uvc_probe+0x54/0xd50
> > > > > > [ 220.287441] usb_probe_interface+0xd5/0x1d0
> > > > > > [ 220.287448] driver_probe_device+0x80/0x1a0
> > > > > > [ 220.287455] __device_attach+0x41/0x50
> > > > > > [ 220.287460] bus_for_each_drv+0x53/0x80
> > > > > > [ 220.287466] device_attach+0x89/0xa0
> > > > > > [ 220.287472] bus_probe_device+0x25/0x40
> > > > > >
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Monday, September 05, 2011 12:13:26 Hans Verkuil wrote:
> On Monday, September 05, 2011 11:59:03 Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 02 September 2011 09:29:08 Sitsofe Wheeler wrote:
> > > On Fri, Sep 02, 2011 at 01:35:49PM +0800, Dave Young wrote:
> > > > On Fri, Sep 2, 2011 at 12:59 PM, Dave Young wrote:
> > > > > On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote:
> > > > >> On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote:
> > > > >>> On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote:
> > > > >>> > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by
> > > > >>> > unplugging a
> > > > >>>
> > > > >>> > USB webcam. See below:
> > > > >>> Could you try the attached patch?
> > > > >>
> > > > >> This patch fixed the oops but extending the sequence (enable camera,
> > > > >> start cheese, disable camera, watch cheese pause, enable camera, quit
> > > > >> cheese, start cheese) causes the following "poison overwritten"
> > > > >> warning
> > > > >
> > > > >> to appear:
> > > > > It seems another bug, I can reproduce this as well.
> > > > >
> > > > > uvc_device is freed in uvc_delete,
> > > > >
> > > > > struct v4l2_device vdev is the member of struct uvc_device, so vdev is
> > > > > also freed. Later v4l2_device operations on vdev will overwrite the
> > > > > poison memory area.
> > > >
> > > > Please try attached patch on top of previous one, in this patch I
> > > > move v4l2_device_put after vdev->release in function
> > > > v4l2_device_release
> > > >
> > > > Not sure if this is a right fix, comments?
> >
> > (inlining the patch's contents)
> >
> > > > diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-
> > > > dev.c
> > > > index 98cee19..541dba3 100644
> > > > --- a/drivers/media/video/v4l2-dev.c
> > > > +++ b/drivers/media/video/v4l2-dev.c
> > > > @@ -172,13 +172,14 @@ static void v4l2_device_release(struct device *cd)
> > > > media_device_unregister_entity(&vdev->entity);
> > > > #endif
> > > >
> > > > + /* Decrease v4l2_device refcount */
> > > > + if (vdev->v4l2_dev)
> > > > + v4l2_device_put(vdev->v4l2_dev);
> > > > +
> > > > /* Release video_device and perform other
> > > >cleanups as needed. */
> > > > vdev->release(vdev);
> > > >
> > > > - /* Decrease v4l2_device refcount */
> > > > - if (vdev->v4l2_dev)
> > > > - v4l2_device_put(vdev->v4l2_dev);
> > > > }
> > > >
> > > > static struct class video_class = {
> >
> > v4l2_device_put() got introduced in commit
> > bedf8bcf6b4f90a6e31add3721a2e71877289381 ("v4l2-device: add kref and a
> > release
> > function"). If I understand its purpose correctly, drivers that use a
> > v4l2_device instance should use the v4l2_device release callback to release
> > device structures instead of counting video_device release callbacks
> > manually.
> > In that case I think the v4l2-dev.c code is correct, and all drivers that
> > use
> > v4l2_device should be fixed.
> >
> > The above patch fixes the problem in a central location, but seems to
> > defeat
> > the original purpose of v4l2_device_get/put().
> >
> > Hans, could you please comment on that ?
>
> The original order is correct, but what I missed is that for drivers that
> release
> (free) everything in the videodev release callback the v4l2_device struct is
> also freed and v4l2_device_put will fail.
>
> To fix this, add this code just before the vdev->release call:
>
> /* Do not call v4l2_device_put if there is no release callback set. */
> if (v4l2_dev->release == NULL)
> v4l2_dev = NULL;
>
> If there is no release callback, then the refcounting is pointless anyway.
>
> This should work.
Note that in the long run using the v4l2_device release callback instead of the
videodev release is better. But it's a lot of work to convert everything so
that's
long term. I'm quite surprised BTW that this bug wasn't found much earlier.
Regards,
Hans
--
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: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Monday, September 05, 2011 11:59:03 Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday 02 September 2011 09:29:08 Sitsofe Wheeler wrote:
> > On Fri, Sep 02, 2011 at 01:35:49PM +0800, Dave Young wrote:
> > > On Fri, Sep 2, 2011 at 12:59 PM, Dave Young wrote:
> > > > On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote:
> > > >> On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote:
> > > >>> On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote:
> > > >>> > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by
> > > >>> > unplugging a
> > > >>>
> > > >>> > USB webcam. See below:
> > > >>> Could you try the attached patch?
> > > >>
> > > >> This patch fixed the oops but extending the sequence (enable camera,
> > > >> start cheese, disable camera, watch cheese pause, enable camera, quit
> > > >> cheese, start cheese) causes the following "poison overwritten"
> > > >> warning
> > > >
> > > >> to appear:
> > > > It seems another bug, I can reproduce this as well.
> > > >
> > > > uvc_device is freed in uvc_delete,
> > > >
> > > > struct v4l2_device vdev is the member of struct uvc_device, so vdev is
> > > > also freed. Later v4l2_device operations on vdev will overwrite the
> > > > poison memory area.
> > >
> > > Please try attached patch on top of previous one, in this patch I
> > > move v4l2_device_put after vdev->release in function
> > > v4l2_device_release
> > >
> > > Not sure if this is a right fix, comments?
>
> (inlining the patch's contents)
>
> > > diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-
> > > dev.c
> > > index 98cee19..541dba3 100644
> > > --- a/drivers/media/video/v4l2-dev.c
> > > +++ b/drivers/media/video/v4l2-dev.c
> > > @@ -172,13 +172,14 @@ static void v4l2_device_release(struct device *cd)
> > > media_device_unregister_entity(&vdev->entity);
> > > #endif
> > >
> > > + /* Decrease v4l2_device refcount */
> > > + if (vdev->v4l2_dev)
> > > + v4l2_device_put(vdev->v4l2_dev);
> > > +
> > > /* Release video_device and perform other
> > > cleanups as needed. */
> > > vdev->release(vdev);
> > >
> > > - /* Decrease v4l2_device refcount */
> > > - if (vdev->v4l2_dev)
> > > - v4l2_device_put(vdev->v4l2_dev);
> > > }
> > >
> > > static struct class video_class = {
>
> v4l2_device_put() got introduced in commit
> bedf8bcf6b4f90a6e31add3721a2e71877289381 ("v4l2-device: add kref and a
> release
> function"). If I understand its purpose correctly, drivers that use a
> v4l2_device instance should use the v4l2_device release callback to release
> device structures instead of counting video_device release callbacks
> manually.
> In that case I think the v4l2-dev.c code is correct, and all drivers that use
> v4l2_device should be fixed.
>
> The above patch fixes the problem in a central location, but seems to defeat
> the original purpose of v4l2_device_get/put().
>
> Hans, could you please comment on that ?
The original order is correct, but what I missed is that for drivers that
release
(free) everything in the videodev release callback the v4l2_device struct is
also freed and v4l2_device_put will fail.
To fix this, add this code just before the vdev->release call:
/* Do not call v4l2_device_put if there is no release callback set. */
if (v4l2_dev->release == NULL)
v4l2_dev = NULL;
If there is no release callback, then the refcounting is pointless anyway.
This should work.
Regards,
Hans
>
> > >
> > > >> [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071)
> > > >> [ 191.277965] input: CNF7129 as
> > > >> /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 [
> > > >> 220.287366]
> > > >> =
> > > >> [ 220.287379] BUG kmalloc-512: Poison overwritten
> > > >> [ 220.287384]
> > > >> -
> > > >> [ 220.287387]
> > > >> [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of
> > > >> 0x6b [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50
> > > >> age=210617 cpu=0 pid=16 [ 220.287421] T.974+0x29d/0x5e0
> > > >> [ 220.287427] kmem_cache_alloc+0x167/0x180
> > > >> [ 220.287433] uvc_probe+0x54/0xd50
> > > >> [ 220.287441] usb_probe_interface+0xd5/0x1d0
> > > >> [ 220.287448] driver_probe_device+0x80/0x1a0
> > > >> [ 220.287455] __device_attach+0x41/0x50
> > > >> [ 220.287460] bus_for_each_drv+0x53/0x80
> > > >> [ 220.287466] device_attach+0x89/0xa0
> > > >> [ 220.287472] bus_probe_device+0x25/0x40
> > > >> [ 220.287478] device_add+0x5a9/0x660
> > > >> [ 220.287484] usb_set_configuration+0x562/0x670
> > > >> [ 220.287491] generic_probe+0x36/0x90
> > > >> [ 220.287497] usb_probe_device+0x24/0x50
> > > >> [ 220.287503] driver_probe_device+0x80/0x1a0
> > > >> [ 220.287509] __device_attach+0x41/0x50
> > > >> [ 220.287515] bus_for_each_drv
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
Hi Hans,
On Friday 02 September 2011 09:29:08 Sitsofe Wheeler wrote:
> On Fri, Sep 02, 2011 at 01:35:49PM +0800, Dave Young wrote:
> > On Fri, Sep 2, 2011 at 12:59 PM, Dave Young wrote:
> > > On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote:
> > >> On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote:
> > >>> On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote:
> > >>> > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by
> > >>> > unplugging a
> > >>>
> > >>> > USB webcam. See below:
> > >>> Could you try the attached patch?
> > >>
> > >> This patch fixed the oops but extending the sequence (enable camera,
> > >> start cheese, disable camera, watch cheese pause, enable camera, quit
> > >> cheese, start cheese) causes the following "poison overwritten"
> > >> warning
> > >
> > >> to appear:
> > > It seems another bug, I can reproduce this as well.
> > >
> > > uvc_device is freed in uvc_delete,
> > >
> > > struct v4l2_device vdev is the member of struct uvc_device, so vdev is
> > > also freed. Later v4l2_device operations on vdev will overwrite the
> > > poison memory area.
> >
> > Please try attached patch on top of previous one, in this patch I
> > move v4l2_device_put after vdev->release in function
> > v4l2_device_release
> >
> > Not sure if this is a right fix, comments?
(inlining the patch's contents)
> > diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-
> > dev.c
> > index 98cee19..541dba3 100644
> > --- a/drivers/media/video/v4l2-dev.c
> > +++ b/drivers/media/video/v4l2-dev.c
> > @@ -172,13 +172,14 @@ static void v4l2_device_release(struct device *cd)
> > media_device_unregister_entity(&vdev->entity);
> > #endif
> >
> > + /* Decrease v4l2_device refcount */
> > + if (vdev->v4l2_dev)
> > + v4l2_device_put(vdev->v4l2_dev);
> > +
> > /* Release video_device and perform other
> >cleanups as needed. */
> > vdev->release(vdev);
> >
> > - /* Decrease v4l2_device refcount */
> > - if (vdev->v4l2_dev)
> > - v4l2_device_put(vdev->v4l2_dev);
> > }
> >
> > static struct class video_class = {
v4l2_device_put() got introduced in commit
bedf8bcf6b4f90a6e31add3721a2e71877289381 ("v4l2-device: add kref and a release
function"). If I understand its purpose correctly, drivers that use a
v4l2_device instance should use the v4l2_device release callback to release
device structures instead of counting video_device release callbacks manually.
In that case I think the v4l2-dev.c code is correct, and all drivers that use
v4l2_device should be fixed.
The above patch fixes the problem in a central location, but seems to defeat
the original purpose of v4l2_device_get/put().
Hans, could you please comment on that ?
> >
> > >> [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071)
> > >> [ 191.277965] input: CNF7129 as
> > >> /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 [
> > >> 220.287366]
> > >> =
> > >> [ 220.287379] BUG kmalloc-512: Poison overwritten
> > >> [ 220.287384]
> > >> -
> > >> [ 220.287387]
> > >> [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of
> > >> 0x6b [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50
> > >> age=210617 cpu=0 pid=16 [ 220.287421] T.974+0x29d/0x5e0
> > >> [ 220.287427] kmem_cache_alloc+0x167/0x180
> > >> [ 220.287433] uvc_probe+0x54/0xd50
> > >> [ 220.287441] usb_probe_interface+0xd5/0x1d0
> > >> [ 220.287448] driver_probe_device+0x80/0x1a0
> > >> [ 220.287455] __device_attach+0x41/0x50
> > >> [ 220.287460] bus_for_each_drv+0x53/0x80
> > >> [ 220.287466] device_attach+0x89/0xa0
> > >> [ 220.287472] bus_probe_device+0x25/0x40
> > >> [ 220.287478] device_add+0x5a9/0x660
> > >> [ 220.287484] usb_set_configuration+0x562/0x670
> > >> [ 220.287491] generic_probe+0x36/0x90
> > >> [ 220.287497] usb_probe_device+0x24/0x50
> > >> [ 220.287503] driver_probe_device+0x80/0x1a0
> > >> [ 220.287509] __device_attach+0x41/0x50
> > >> [ 220.287515] bus_for_each_drv+0x53/0x80
> > >> [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0
> > >> pid=1645 [ 220.287530] __slab_free+0x1f8/0x300
> > >> [ 220.287536] kfree+0x100/0x140
> > >> [ 220.287541] uvc_delete+0xfe/0x110
> > >> [ 220.287547] uvc_release+0x25/0x30
> > >> [ 220.287555] v4l2_device_release+0x9d/0xc0
> > >> [ 220.287560] device_release+0x19/0x90
> > >> [ 220.287567] kobject_release+0x3c/0x90
> > >> [ 220.287573] kref_put+0x2c/0x60
> > >> [ 220.287578] kobject_put+0x1d/0x50
> > >> [ 220.287587] put_device+0xf/0x20
> > >> [ 220.287593] v4l2_release+0x56/0x60
> > >> [ 220.287599] fput+0xcc/0x220
> > >> [ 220.287605] filp_close+0x44/0x70
> > >> [ 220.287613] put_files_struct+0x158/0x180
> > >> [ 220.287619] exit_files+0x40/0x50
[snip]
--
Re
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
CC'ing Hans Verkuil. On Fri, Sep 02, 2011 at 01:35:49PM +0800, Dave Young wrote: > On Fri, Sep 2, 2011 at 12:59 PM, Dave Young wrote: > > On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote: > >> On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: > >>> On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler > >>> wrote: > >>> > > >>> > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a > >>> > USB webcam. See below: > >>> > >>> Could you try the attached patch? > >> > >> This patch fixed the oops but extending the sequence (enable camera, > >> start cheese, disable camera, watch cheese pause, enable camera, quit > >> cheese, start cheese) causes the following "poison overwritten" warning > >> to appear: > > > > It seems another bug, I can reproduce this as well. > > > > uvc_device is freed in uvc_delete, > > > > struct v4l2_device vdev is the member of struct uvc_device, so vdev is > > also freed. Later v4l2_device operations on vdev will overwrite the > > poison memory area. > > > > Please try attached patch on top of previous one, in this patch I > move v4l2_device_put after vdev->release in function > v4l2_device_release > > Not sure if this is a right fix, comments? > > >> > >> > >> [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) > >> [ 191.277965] input: CNF7129 as > >> /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 > >> [ 220.287366] > >> = > >> [ 220.287379] BUG kmalloc-512: Poison overwritten > >> [ 220.287384] > >> - > >> [ 220.287387] > >> [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b > >> [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 > >> pid=16 > >> [ 220.287421] T.974+0x29d/0x5e0 > >> [ 220.287427] kmem_cache_alloc+0x167/0x180 > >> [ 220.287433] uvc_probe+0x54/0xd50 > >> [ 220.287441] usb_probe_interface+0xd5/0x1d0 > >> [ 220.287448] driver_probe_device+0x80/0x1a0 > >> [ 220.287455] __device_attach+0x41/0x50 > >> [ 220.287460] bus_for_each_drv+0x53/0x80 > >> [ 220.287466] device_attach+0x89/0xa0 > >> [ 220.287472] bus_probe_device+0x25/0x40 > >> [ 220.287478] device_add+0x5a9/0x660 > >> [ 220.287484] usb_set_configuration+0x562/0x670 > >> [ 220.287491] generic_probe+0x36/0x90 > >> [ 220.287497] usb_probe_device+0x24/0x50 > >> [ 220.287503] driver_probe_device+0x80/0x1a0 > >> [ 220.287509] __device_attach+0x41/0x50 > >> [ 220.287515] bus_for_each_drv+0x53/0x80 > >> [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 > >> [ 220.287530] __slab_free+0x1f8/0x300 > >> [ 220.287536] kfree+0x100/0x140 > >> [ 220.287541] uvc_delete+0xfe/0x110 > >> [ 220.287547] uvc_release+0x25/0x30 > >> [ 220.287555] v4l2_device_release+0x9d/0xc0 > >> [ 220.287560] device_release+0x19/0x90 > >> [ 220.287567] kobject_release+0x3c/0x90 > >> [ 220.287573] kref_put+0x2c/0x60 > >> [ 220.287578] kobject_put+0x1d/0x50 > >> [ 220.287587] put_device+0xf/0x20 > >> [ 220.287593] v4l2_release+0x56/0x60 > >> [ 220.287599] fput+0xcc/0x220 > >> [ 220.287605] filp_close+0x44/0x70 > >> [ 220.287613] put_files_struct+0x158/0x180 > >> [ 220.287619] exit_files+0x40/0x50 > >> [ 220.287626] do_exit+0xec/0x660 > >> [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) > >> flags=0x4080 > >> [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 > >> [ 220.287642] > >> [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a > >> 5a 5a 5a 5a mÈþÿ > >> [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > >> 6b 6b 6b 6b > >> [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Fri, Sep 2, 2011 at 12:59 PM, Dave Young wrote: > On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote: >> On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: >>> On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote: >>> > >>> > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a >>> > USB webcam. See below: >>> >>> Could you try the attached patch? >> >> This patch fixed the oops but extending the sequence (enable camera, >> start cheese, disable camera, watch cheese pause, enable camera, quit >> cheese, start cheese) causes the following "poison overwritten" warning >> to appear: > > It seems another bug, I can reproduce this as well. > > uvc_device is freed in uvc_delete, > > struct v4l2_device vdev is the member of struct uvc_device, so vdev is > also freed. Later v4l2_device operations on vdev will overwrite the > poison memory area. > Please try attached patch on top of previous one, in this patch I move v4l2_device_put after vdev->release in function v4l2_device_release Not sure if this is a right fix, comments? >> >> >> [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) >> [ 191.277965] input: CNF7129 as >> /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 >> [ 220.287366] >> = >> [ 220.287379] BUG kmalloc-512: Poison overwritten >> [ 220.287384] >> - >> [ 220.287387] >> [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b >> [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 >> pid=16 >> [ 220.287421] T.974+0x29d/0x5e0 >> [ 220.287427] kmem_cache_alloc+0x167/0x180 >> [ 220.287433] uvc_probe+0x54/0xd50 >> [ 220.287441] usb_probe_interface+0xd5/0x1d0 >> [ 220.287448] driver_probe_device+0x80/0x1a0 >> [ 220.287455] __device_attach+0x41/0x50 >> [ 220.287460] bus_for_each_drv+0x53/0x80 >> [ 220.287466] device_attach+0x89/0xa0 >> [ 220.287472] bus_probe_device+0x25/0x40 >> [ 220.287478] device_add+0x5a9/0x660 >> [ 220.287484] usb_set_configuration+0x562/0x670 >> [ 220.287491] generic_probe+0x36/0x90 >> [ 220.287497] usb_probe_device+0x24/0x50 >> [ 220.287503] driver_probe_device+0x80/0x1a0 >> [ 220.287509] __device_attach+0x41/0x50 >> [ 220.287515] bus_for_each_drv+0x53/0x80 >> [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 >> [ 220.287530] __slab_free+0x1f8/0x300 >> [ 220.287536] kfree+0x100/0x140 >> [ 220.287541] uvc_delete+0xfe/0x110 >> [ 220.287547] uvc_release+0x25/0x30 >> [ 220.287555] v4l2_device_release+0x9d/0xc0 >> [ 220.287560] device_release+0x19/0x90 >> [ 220.287567] kobject_release+0x3c/0x90 >> [ 220.287573] kref_put+0x2c/0x60 >> [ 220.287578] kobject_put+0x1d/0x50 >> [ 220.287587] put_device+0xf/0x20 >> [ 220.287593] v4l2_release+0x56/0x60 >> [ 220.287599] fput+0xcc/0x220 >> [ 220.287605] filp_close+0x44/0x70 >> [ 220.287613] put_files_struct+0x158/0x180 >> [ 220.287619] exit_files+0x40/0x50 >> [ 220.287626] do_exit+0xec/0x660 >> [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) >> flags=0x4080 >> [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 >> [ 220.287642] >> [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a 5a >> 5a 5a 5a mÈþÿ >> [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.288012] Object 0xec90f120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.288012] Object 0xec90f130: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b >> 6b 6b 6b >> [ 220.288012] Objec
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler wrote: > On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: >> On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote: >> > >> > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a >> > USB webcam. See below: >> >> Could you try the attached patch? > > This patch fixed the oops but extending the sequence (enable camera, > start cheese, disable camera, watch cheese pause, enable camera, quit > cheese, start cheese) causes the following "poison overwritten" warning > to appear: It seems another bug, I can reproduce this as well. uvc_device is freed in uvc_delete, struct v4l2_device vdev is the member of struct uvc_device, so vdev is also freed. Later v4l2_device operations on vdev will overwrite the poison memory area. > > > [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) > [ 191.277965] input: CNF7129 as > /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 > [ 220.287366] > = > [ 220.287379] BUG kmalloc-512: Poison overwritten > [ 220.287384] > - > [ 220.287387] > [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b > [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 pid=16 > [ 220.287421] T.974+0x29d/0x5e0 > [ 220.287427] kmem_cache_alloc+0x167/0x180 > [ 220.287433] uvc_probe+0x54/0xd50 > [ 220.287441] usb_probe_interface+0xd5/0x1d0 > [ 220.287448] driver_probe_device+0x80/0x1a0 > [ 220.287455] __device_attach+0x41/0x50 > [ 220.287460] bus_for_each_drv+0x53/0x80 > [ 220.287466] device_attach+0x89/0xa0 > [ 220.287472] bus_probe_device+0x25/0x40 > [ 220.287478] device_add+0x5a9/0x660 > [ 220.287484] usb_set_configuration+0x562/0x670 > [ 220.287491] generic_probe+0x36/0x90 > [ 220.287497] usb_probe_device+0x24/0x50 > [ 220.287503] driver_probe_device+0x80/0x1a0 > [ 220.287509] __device_attach+0x41/0x50 > [ 220.287515] bus_for_each_drv+0x53/0x80 > [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 > [ 220.287530] __slab_free+0x1f8/0x300 > [ 220.287536] kfree+0x100/0x140 > [ 220.287541] uvc_delete+0xfe/0x110 > [ 220.287547] uvc_release+0x25/0x30 > [ 220.287555] v4l2_device_release+0x9d/0xc0 > [ 220.287560] device_release+0x19/0x90 > [ 220.287567] kobject_release+0x3c/0x90 > [ 220.287573] kref_put+0x2c/0x60 > [ 220.287578] kobject_put+0x1d/0x50 > [ 220.287587] put_device+0xf/0x20 > [ 220.287593] v4l2_release+0x56/0x60 > [ 220.287599] fput+0xcc/0x220 > [ 220.287605] filp_close+0x44/0x70 > [ 220.287613] put_files_struct+0x158/0x180 > [ 220.287619] exit_files+0x40/0x50 > [ 220.287626] do_exit+0xec/0x660 > [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) > flags=0x4080 > [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 > [ 220.287642] > [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a 5a > 5a 5a 5a mÈþÿ > [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288012] Object 0xec90f120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288012] Object 0xec90f130: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288012] Object 0xec90f140: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288012] Object 0xec90f150: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b jkkk > [ 220.288012] Object 0xec90f160: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [ 220.288012] Object 0xec90f170: 6b 6b 6b 6b 6b
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: > On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote: > > > > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a > > USB webcam. See below: > > Could you try the attached patch? This patch fixed the oops but extending the sequence (enable camera, start cheese, disable camera, watch cheese pause, enable camera, quit cheese, start cheese) causes the following "poison overwritten" warning to appear: [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 191.277965] input: CNF7129 as /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 [ 220.287366] = [ 220.287379] BUG kmalloc-512: Poison overwritten [ 220.287384] - [ 220.287387] [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 pid=16 [ 220.287421] T.974+0x29d/0x5e0 [ 220.287427] kmem_cache_alloc+0x167/0x180 [ 220.287433] uvc_probe+0x54/0xd50 [ 220.287441] usb_probe_interface+0xd5/0x1d0 [ 220.287448] driver_probe_device+0x80/0x1a0 [ 220.287455] __device_attach+0x41/0x50 [ 220.287460] bus_for_each_drv+0x53/0x80 [ 220.287466] device_attach+0x89/0xa0 [ 220.287472] bus_probe_device+0x25/0x40 [ 220.287478] device_add+0x5a9/0x660 [ 220.287484] usb_set_configuration+0x562/0x670 [ 220.287491] generic_probe+0x36/0x90 [ 220.287497] usb_probe_device+0x24/0x50 [ 220.287503] driver_probe_device+0x80/0x1a0 [ 220.287509] __device_attach+0x41/0x50 [ 220.287515] bus_for_each_drv+0x53/0x80 [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 [ 220.287530] __slab_free+0x1f8/0x300 [ 220.287536] kfree+0x100/0x140 [ 220.287541] uvc_delete+0xfe/0x110 [ 220.287547] uvc_release+0x25/0x30 [ 220.287555] v4l2_device_release+0x9d/0xc0 [ 220.287560] device_release+0x19/0x90 [ 220.287567] kobject_release+0x3c/0x90 [ 220.287573] kref_put+0x2c/0x60 [ 220.287578] kobject_put+0x1d/0x50 [ 220.287587] put_device+0xf/0x20 [ 220.287593] v4l2_release+0x56/0x60 [ 220.287599] fput+0xcc/0x220 [ 220.287605] filp_close+0x44/0x70 [ 220.287613] put_files_struct+0x158/0x180 [ 220.287619] exit_files+0x40/0x50 [ 220.287626] do_exit+0xec/0x660 [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) flags=0x4080 [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 [ 220.287642] [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a 5a 5a 5a 5a mÈþÿ [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f130: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f140: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f150: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkk [ 220.288012] Object 0xec90f160: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f170: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f180: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f190: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f1a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f1b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec9
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler wrote: > Hi, > > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a > USB webcam. See below: Could you try the attached patch? > > eeepc kernel: [ 1263.874756] cheese[3402]: segfault at 58 ip 080630b6 sp > afc2c840 error 4 in cheese[8048000+24000] > eeepc kernel: [ 1393.419370] uvcvideo: Non-zero status (-84) in status > completion handler. > eeepc kernel: [ 1393.500719] usb 3-2: USB disconnect, device number 4 > eeepc kernel: [ 1393.504351] uvcvideo: Failed to resubmit video URB (-19). > eeepc kernel: [ 1495.428853] BUG: unable to handle kernel paging request at > 6b6b6bcb > eeepc kernel: [ 1495.429017] IP: [] dev_get_drvdata+0x17/0x20 > eeepc kernel: [ 1495.429017] *pde = > eeepc kernel: [ 1495.429017] Oops: [#1] DEBUG_PAGEALLOC > eeepc kernel: [ 1495.429017] > eeepc kernel: [ 1495.429017] Pid: 3476, comm: cheese Not tainted > 3.1.0-rc3-00270-g7a54f5e-dirty #485 ASUSTeK Computer INC. 900/900 > eeepc kernel: [ 1495.429017] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 > eeepc kernel: [ 1495.429017] EIP is at dev_get_drvdata+0x17/0x20 > eeepc kernel: [ 1495.429017] EAX: 6b6b6b6b EBX: eb08d870 ECX: EDX: > eb08d930 > eeepc kernel: [ 1495.429017] ESI: eb08d870 EDI: eb08d870 EBP: d3249cac ESP: > d3249cac > eeepc kernel: [ 1495.429017] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 > eeepc kernel: [ 1495.429017] Process cheese (pid: 3476, ti=d3248000 > task=df46d870 task.ti=d3248000) > eeepc kernel: [ 1495.429017] Stack: > eeepc kernel: [ 1495.429017] d3249cb8 b03e77a1 d307b840 d3249ccc b03e77d1 > d307b840 eb08d870 eb08d830 > eeepc kernel: [ 1495.429017] d3249ce4 b03ed3b7 0246 d307b840 eb08d870 > d3021b80 d3249cec b03ed565 > eeepc kernel: [ 1495.429017] d3249cfc b03e044d e8323d10 b06e013c d3249d18 > b0355fb9 fffe d3249d1c > eeepc kernel: [ 1495.429017] Call Trace: > eeepc kernel: [ 1495.429017] [] v4l2_device_disconnect+0x11/0x30 > eeepc kernel: [ 1495.429017] [] v4l2_device_unregister+0x11/0x50 > eeepc kernel: [ 1495.429017] [] uvc_delete+0x37/0x110 > eeepc kernel: [ 1495.429017] [] uvc_release+0x25/0x30 > eeepc kernel: [ 1495.429017] [] v4l2_device_release+0x9d/0xc0 > eeepc kernel: [ 1495.429017] [] device_release+0x19/0x90 > eeepc kernel: [ 1495.429017] [] ? usb_hcd_unlink_urb+0x7c/0x90 > eeepc kernel: [ 1495.429017] [] kobject_release+0x3c/0x90 > eeepc kernel: [ 1495.429017] [] ? kobject_del+0x30/0x30 > eeepc kernel: [ 1495.429017] [] kref_put+0x2c/0x60 > eeepc kernel: [ 1495.429017] [] kobject_put+0x1d/0x50 > eeepc kernel: [ 1495.429017] [] ? > usb_autopm_put_interface+0x25/0x30 > eeepc kernel: [ 1495.429017] [] ? uvc_v4l2_release+0x5d/0xd0 > eeepc kernel: [ 1495.429017] [] put_device+0xf/0x20 > eeepc kernel: [ 1495.429017] [] v4l2_release+0x56/0x60 > eeepc kernel: [ 1495.429017] [] fput+0xcc/0x220 > eeepc kernel: [ 1495.429017] [] filp_close+0x44/0x70 > eeepc kernel: [ 1495.429017] [] put_files_struct+0x158/0x180 > eeepc kernel: [ 1495.429017] [] ? put_files_struct+0x20/0x180 > eeepc kernel: [ 1495.429017] [] exit_files+0x40/0x50 > eeepc kernel: [ 1495.429017] [] do_exit+0x5a7/0x660 > eeepc kernel: [ 1495.429017] [] ? __dequeue_signal+0x12/0x120 > eeepc kernel: [ 1495.429017] [] ? _raw_spin_unlock_irq+0x22/0x30 > eeepc kernel: [ 1495.429017] [] do_group_exit+0x3c/0xb0 > eeepc kernel: [ 1495.429017] [] ? trace_hardirqs_on+0xb/0x10 > eeepc kernel: [ 1495.429017] [] get_signal_to_deliver+0x18f/0x570 > eeepc kernel: [ 1495.429017] [] do_signal+0x47/0x9e0 > eeepc kernel: [ 1495.429017] [] ? _raw_spin_unlock_irq+0x22/0x30 > eeepc kernel: [ 1495.429017] [] ? trace_hardirqs_on+0xb/0x10 > eeepc kernel: [ 1495.429017] [] ? T.1034+0x30/0xc0 > eeepc kernel: [ 1495.429017] [] ? schedule+0x29f/0x640 > eeepc kernel: [ 1495.429017] [] do_notify_resume+0x38/0x40 > eeepc kernel: [ 1495.429017] [] work_notifysig+0x9/0x11 > eeepc kernel: [ 1495.429017] Code: e5 5d 83 f8 01 19 c0 f7 d0 83 e0 f0 c3 8d > b4 26 00 00 00 00 55 85 c0 89 e5 75 09 31 c0 5d c3 90 8d 74 26 00 8b 40 04 85 > c0 74 f0 <8b> 40 60 5d c3 8d 74 26 00 55 89 e5 53 89 c3 83 ec 04 8b 40 04 > eeepc kernel: [ 1495.429017] EIP: [] dev_get_drvdata+0x17/0x20 > SS:ESP 0068:d3249cac > eeepc kernel: [ 1495.429017] CR2: 6b6b6bcb > eeepc kernel: [ 1495.466975] uvcvideo: Failed to resubmit video URB (-27). > eeepc kernel: [ 1495.467860] uvcvideo: Failed to resubmit video URB (-27). > eeepc kernel: last message repeated 3 times > eeepc kernel: [ 1495.512610] ---[ end trace 73ec16848794e5a5 ]--- > eeepc kernel: [ 1495.512620] Fixing recursive fault but reboot is needed! > > -- > Sitsofe | http://sucs.org/~sits/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards Yang RuiRui Reported-by: Sitsofe Wheeler Signe
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
Hi, On Wed, Aug 31, 2011 at 12:20:10AM +0200, Laurent Pinchart wrote: > > Thanks for the report. Can you reproduce this on v3.0 ? What were the exact > steps that led to the crash ? Yes I can reproduce on v3.0 (oops below). The steps that lead to it are: 1. Start GNOME. 2. Plug USB webcam into EeePC 900. 3. Start cheese. 4. Go to Edit | Preferences and change the device to the USB webcam. 5. Click Close. 6. Wait for video from the USB webcam to start playing in cheese. 7. Unplug USB webcam while video is still playing. This will usually cause cheese to display error messages on the console and then hang. 8. On the console press Ctrl-C to kill cheese. With a kernel with debug options turned on, these steps will cause the oops every time. I have not reproduced the oops on kernels with the debugging features turned off though. Oops under 3.0 (3.0 also outputs a lockdep warning for usb-snd before this oops happens but this seems to be fixed in 3.1): [ 188.072956] BUG: unable to handle kernel paging request at 6b6b6bcb [ 188.073013] IP: [] dev_get_drvdata+0x17/0x20 [ 188.073013] *pde = [ 188.073013] Oops: [#1] DEBUG_PAGEALLOC [ 188.073013] [ 188.073013] Pid: 2001, comm: cheese Not tainted 3.0.0 #486 ASUSTeK Computer INC. 900/900 [ 188.073013] EIP: 0060:[] EFLAGS: 00210202 CPU: 0 [ 188.073013] EIP is at dev_get_drvdata+0x17/0x20 [ 188.073013] EAX: 6b6b6b6b EBX: e2054040 ECX: 4081 EDX: e2054100 [ 188.073013] ESI: e2054040 EDI: e2054040 EBP: e211bcac ESP: e211bcac [ 188.073013] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 188.073013] Process cheese (pid: 2001, ti=e211a000 task=e2068000 task.ti=e211a000) [ 188.073013] Stack: [ 188.073013] e211bcb8 b03e8bc1 de22e9e0 e211bccc b03e8bf1 de22e9e0 e2054040 e2054000 [ 188.073013] e211bce4 b03ed847 00200246 de22e9e0 e2054040 e1f38850 e211bcec b03ed9f5 [ 188.073013] e211bcfc b03e1afd e1d56dc0 b06d751c e211bd18 b0355b89 fffe e211bd1c [ 188.073013] Call Trace: [ 188.073013] [] v4l2_device_disconnect+0x11/0x30 [ 188.073013] [] v4l2_device_unregister+0x11/0x50 [ 188.073013] [] uvc_delete+0x37/0x110 [ 188.073013] [] uvc_release+0x25/0x30 [ 188.073013] [] v4l2_device_release+0x9d/0xc0 [ 188.073013] [] device_release+0x19/0x90 [ 188.073013] [] ? usb_hcd_unlink_urb+0x7c/0x90 [ 188.073013] [] kobject_release+0x3c/0x90 [ 188.073013] [] ? kobject_del+0x30/0x30 [ 188.073013] [] kref_put+0x2c/0x60 [ 188.073013] [] kobject_put+0x1d/0x50 [ 188.073013] [] ? usb_autopm_put_interface+0x25/0x30 [ 188.073013] [] ? uvc_v4l2_release+0x5d/0xd0 [ 188.073013] [] put_device+0xf/0x20 [ 188.073013] [] v4l2_release+0x59/0x60 [ 188.073013] [] fput+0xcc/0x210 [ 188.073013] [] filp_close+0x44/0x70 [ 188.073013] [] put_files_struct+0x130/0x160 [ 188.073013] [] ? put_files_struct+0x20/0x160 [ 188.073013] [] exit_files+0x40/0x50 [ 188.073013] [] do_exit+0x58c/0x670 [ 188.073013] [] ? __dequeue_signal+0x12/0x120 [ 188.073013] [] ? dequeue_signal+0x2d/0x180 [ 188.073013] [] do_group_exit+0x3c/0xb0 [ 188.073013] [] ? trace_hardirqs_on+0xb/0x10 [ 188.073013] [] get_signal_to_deliver+0x26c/0x450 [ 188.073013] [] do_signal+0x68/0xa80 [ 188.073013] [] ? T.1021+0x30/0xc0 [ 188.073013] [] ? schedule+0x293/0x630 [ 188.073013] [] ? sys_futex+0x6a/0x110 [ 188.073013] [] ? lockdep_sys_exit+0x22/0x80 [ 188.073013] [] do_notify_resume+0x38/0x40 [ 188.073013] [] work_notifysig+0x9/0x11 [ 188.073013] [] ? pci_scan_bridge+0x100/0x40d [ 188.073013] Code: e5 5d 83 f8 01 19 c0 f7 d0 83 e0 f0 c3 8d b4 26 00 00 00 00 55 85 c0 89 e5 75 09 31 c0 5d c3 90 8d 74 26 00 8b 40 04 85 c0 74 f0 <8b> 40 60 5d c3 8d 74 26 00 55 89 e5 53 89 c3 83 ec 04 8b 40 04 [ 188.073013] EIP: [] dev_get_drvdata+0x17/0x20 SS:ESP 0068:e211bcac [ 188.073013] CR2: 6b6b6bcb [ 188.142768] ---[ end trace 801a4e56b6bf7f74 ]--- [ 188.142778] Fixing recursive fault but reboot is needed! -- Sitsofe | http://sucs.org/~sits/ -- 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: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
Hi, On Monday 29 August 2011 22:48:46 Sitsofe Wheeler wrote: > Hi, > > I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a > USB webcam. Thanks for the report. Can you reproduce this on v3.0 ? What were the exact steps that led to the crash ? -- 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
BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
Hi, I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: eeepc kernel: [ 1263.874756] cheese[3402]: segfault at 58 ip 080630b6 sp afc2c840 error 4 in cheese[8048000+24000] eeepc kernel: [ 1393.419370] uvcvideo: Non-zero status (-84) in status completion handler. eeepc kernel: [ 1393.500719] usb 3-2: USB disconnect, device number 4 eeepc kernel: [ 1393.504351] uvcvideo: Failed to resubmit video URB (-19). eeepc kernel: [ 1495.428853] BUG: unable to handle kernel paging request at 6b6b6bcb eeepc kernel: [ 1495.429017] IP: [] dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] *pde = eeepc kernel: [ 1495.429017] Oops: [#1] DEBUG_PAGEALLOC eeepc kernel: [ 1495.429017] eeepc kernel: [ 1495.429017] Pid: 3476, comm: cheese Not tainted 3.1.0-rc3-00270-g7a54f5e-dirty #485 ASUSTeK Computer INC. 900/900 eeepc kernel: [ 1495.429017] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 eeepc kernel: [ 1495.429017] EIP is at dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] EAX: 6b6b6b6b EBX: eb08d870 ECX: EDX: eb08d930 eeepc kernel: [ 1495.429017] ESI: eb08d870 EDI: eb08d870 EBP: d3249cac ESP: d3249cac eeepc kernel: [ 1495.429017] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 eeepc kernel: [ 1495.429017] Process cheese (pid: 3476, ti=d3248000 task=df46d870 task.ti=d3248000) eeepc kernel: [ 1495.429017] Stack: eeepc kernel: [ 1495.429017] d3249cb8 b03e77a1 d307b840 d3249ccc b03e77d1 d307b840 eb08d870 eb08d830 eeepc kernel: [ 1495.429017] d3249ce4 b03ed3b7 0246 d307b840 eb08d870 d3021b80 d3249cec b03ed565 eeepc kernel: [ 1495.429017] d3249cfc b03e044d e8323d10 b06e013c d3249d18 b0355fb9 fffe d3249d1c eeepc kernel: [ 1495.429017] Call Trace: eeepc kernel: [ 1495.429017] [] v4l2_device_disconnect+0x11/0x30 eeepc kernel: [ 1495.429017] [] v4l2_device_unregister+0x11/0x50 eeepc kernel: [ 1495.429017] [] uvc_delete+0x37/0x110 eeepc kernel: [ 1495.429017] [] uvc_release+0x25/0x30 eeepc kernel: [ 1495.429017] [] v4l2_device_release+0x9d/0xc0 eeepc kernel: [ 1495.429017] [] device_release+0x19/0x90 eeepc kernel: [ 1495.429017] [] ? usb_hcd_unlink_urb+0x7c/0x90 eeepc kernel: [ 1495.429017] [] kobject_release+0x3c/0x90 eeepc kernel: [ 1495.429017] [] ? kobject_del+0x30/0x30 eeepc kernel: [ 1495.429017] [] kref_put+0x2c/0x60 eeepc kernel: [ 1495.429017] [] kobject_put+0x1d/0x50 eeepc kernel: [ 1495.429017] [] ? usb_autopm_put_interface+0x25/0x30 eeepc kernel: [ 1495.429017] [] ? uvc_v4l2_release+0x5d/0xd0 eeepc kernel: [ 1495.429017] [] put_device+0xf/0x20 eeepc kernel: [ 1495.429017] [] v4l2_release+0x56/0x60 eeepc kernel: [ 1495.429017] [] fput+0xcc/0x220 eeepc kernel: [ 1495.429017] [] filp_close+0x44/0x70 eeepc kernel: [ 1495.429017] [] put_files_struct+0x158/0x180 eeepc kernel: [ 1495.429017] [] ? put_files_struct+0x20/0x180 eeepc kernel: [ 1495.429017] [] exit_files+0x40/0x50 eeepc kernel: [ 1495.429017] [] do_exit+0x5a7/0x660 eeepc kernel: [ 1495.429017] [] ? __dequeue_signal+0x12/0x120 eeepc kernel: [ 1495.429017] [] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [] do_group_exit+0x3c/0xb0 eeepc kernel: [ 1495.429017] [] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [] get_signal_to_deliver+0x18f/0x570 eeepc kernel: [ 1495.429017] [] do_signal+0x47/0x9e0 eeepc kernel: [ 1495.429017] [] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [] ? T.1034+0x30/0xc0 eeepc kernel: [ 1495.429017] [] ? schedule+0x29f/0x640 eeepc kernel: [ 1495.429017] [] do_notify_resume+0x38/0x40 eeepc kernel: [ 1495.429017] [] work_notifysig+0x9/0x11 eeepc kernel: [ 1495.429017] Code: e5 5d 83 f8 01 19 c0 f7 d0 83 e0 f0 c3 8d b4 26 00 00 00 00 55 85 c0 89 e5 75 09 31 c0 5d c3 90 8d 74 26 00 8b 40 04 85 c0 74 f0 <8b> 40 60 5d c3 8d 74 26 00 55 89 e5 53 89 c3 83 ec 04 8b 40 04 eeepc kernel: [ 1495.429017] EIP: [] dev_get_drvdata+0x17/0x20 SS:ESP 0068:d3249cac eeepc kernel: [ 1495.429017] CR2: 6b6b6bcb eeepc kernel: [ 1495.466975] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: [ 1495.467860] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: last message repeated 3 times eeepc kernel: [ 1495.512610] ---[ end trace 73ec16848794e5a5 ]--- eeepc kernel: [ 1495.512620] Fixing recursive fault but reboot is needed! -- Sitsofe | http://sucs.org/~sits/ -- 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
