Bug 7548 - Slot 0 not NULL on disconnecting SN9C10x PC Camera
Summary: Slot 0 not NULL on disconnecting SN9C10x PC Camera
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-18 07:14 UTC by Rafał Bilski
Modified: 2006-11-20 10:54 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.19-rc4
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Log from Linux 2.6.19-rc6 (8.73 KB, text/plain)
2006-11-18 13:33 UTC, Rafał Bilski
Details
My personal config for Linux 2.6.19-rc6 (44.52 KB, text/plain)
2006-11-18 13:35 UTC, Rafał Bilski
Details
Balance usb_get_dev() and usb_put_dev() calls. (987 bytes, patch)
2006-11-20 00:52 UTC, Dan Carpenter
Details | Diff

Description Rafał Bilski 2006-11-18 07:14:31 UTC
Most recent kernel where this bug did *NOT* occur: Unknown
Distribution: Gentoo

Hardware Environment:
VIA EPIA M-10000
USB 0c45:602c Microdia Clas Ohlson TWC-30XOP WebCam

Problem Description:
Each time when I'm removing plug from USB conector:
Nov 18 07:56:03 elke usb 1-1: USB disconnect, address 3
Nov 18 07:56:09 elke usb 2-2: USB disconnect, address 2
Nov 18 07:56:09 elke usb 2-2: Disconnecting SN9C10x PC Camera...
Nov 18 07:56:09 elke usb 2-2: V4L2 device /dev/video0 deregistered
Nov 18 07:56:09 elke get_unused_fd: slot 0 not NULL!
Nov 18 07:56:10 elke get_unused_fd: slot 0 not NULL!
Nov 18 07:56:10 elke get_unused_fd: slot 0 not NULL!
Nov 18 07:57:15 elke BUG: unable to handle kernel paging request at virtual
address 62696c33
Nov 18 07:57:15 elke printing eip:
Nov 18 07:57:15 elke c0139992
Nov 18 07:57:15 elke *pde = 00000000
Nov 18 07:57:15 elke Oops: 0002 [#1]
Nov 18 07:57:15 elke Modules linked in: via drm sn9c102 videodev v4l1_compat
v4l2_common parport_pc parport ohci1394 ieee1394 i2c_viapro
Nov 18 07:57:15 elke CPU:    0
Nov 18 07:57:15 elke EIP:    0060:[<c0139992>]    Not tainted VLI
Nov 18 07:57:15 elke EFLAGS: 00010082   (2.6.19-rc4-g1f874b96 #8)
Nov 18 07:57:15 elke EIP is at free_block+0x59/0xda
Nov 18 07:57:15 elke eax: 2d646c2f   ebx: dbfedf60   ecx: dbe8b7a0   edx: 62696c2f
Nov 18 07:57:15 elke esi: d1156000   edi: dbfeff00   ebp: 00000000   esp: dbf89f20
Nov 18 07:57:15 elke ds: 007b   es: 007b   ss: 0068
Nov 18 07:57:15 elke Process events/0 (pid: 3, ti=dbf88000 task=c13e9030
task.ti=dbf88000)
Nov 18 07:57:15 elke Stack: dbfe9210 00000001 dbfeca30 dbfeca30 00000001
dbfeca20 dbfeff00 c0139a7c 
Nov 18 07:57:15 elke 00000000 dbfedf60 dbfeff00 dbfe5360 00000000 c013aa1e
00000000 00000000 
Nov 18 07:57:15 elke 00000286 c0442ae0 c011adf3 8276f800 000003ec 275714ba
c013a9df dbfe5370 
Nov 18 07:57:15 elke Call Trace:
Nov 18 07:57:15 elke [<c0139a7c>] drain_array+0x69/0x83
Nov 18 07:57:15 elke [<c013aa1e>] cache_reap+0x3f/0xd6
Nov 18 07:57:15 elke [<c011adf3>] run_workqueue+0x6f/0xa2
Nov 18 07:57:15 elke [<c013a9df>] cache_reap+0x0/0xd6
Nov 18 07:57:15 elke [<c011b2b0>] worker_thread+0xe8/0x118
Nov 18 07:57:15 elke [<c010cb69>] default_wake_function+0x0/0xc
Nov 18 07:57:15 elke [<c011b1c8>] worker_thread+0x0/0x118
Nov 18 07:57:15 elke [<c011d3bd>] kthread+0xad/0xd8
Nov 18 07:57:15 elke [<c011d310>] kthread+0x0/0xd8
Nov 18 07:57:15 elke [<c0102ab7>] kernel_thread_helper+0x7/0x10
Nov 18 07:57:15 elke =======================
Nov 18 07:57:15 elke Code: 2a 44 c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 84 c0 78
08 0f 0b 5f 02 59 34 36 c0 8b 4a 1c 8b 54 24 20 8b 41 04 8b 5c 97 14 8b 11 <89>
42 04 89 10 31 d2 2b 71 0c c7 01 00 01 10 00 c7 41 04 00 02 
Nov 18 07:57:15 elke EIP: [<c0139992>] free_block+0x59/0xda SS:ESP 0068:dbf89f20
Nov 18 08:00:02 elke <4>get_unused_fd: slot 0 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 0 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 0 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 0 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 1 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 2 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 0 not NULL!
Nov 18 08:00:02 elke get_unused_fd: slot 0 not NULL!

Steps to reproduce:
Disconnect "Microdia Clas Ohlson TWC-30XOP WebCam"
Comment 1 Rafa&#322; Bilski 2006-11-18 13:33:13 UTC
Created attachment 9560 [details]
Log from Linux 2.6.19-rc6

Thats all what left in log. There was "fatal exception in interrupt
<beeeeeeep>" too.
Comment 2 Rafa&#322; Bilski 2006-11-18 13:35:23 UTC
Created attachment 9561 [details]
My personal config for Linux 2.6.19-rc6
Comment 3 Dan Carpenter 2006-11-19 21:15:24 UTC
On 11/18/06, bugme-daemon@bugzilla.kernel.org
<bugme-daemon@bugzilla.kernel.org> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=7548
>
> ------- Additional Comments From rafalbilski@interia.pl  2006-11-18 13:33 -------
> Created an attachment (id=9560)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=9560&action=view)
> Log from Linux 2.6.19-rc6
>
> Thats all what left in log. There was "fatal exception in interrupt
> <beeeeeeep>" too.
>

Rafa, you posted 2 different stack traces so there may be more than
one bug...  On the second stack trace, it looks like you disconnected
it then reconnected it 6 seconds later.  Is that correct?

Do you think you could post a stack trace again but this time include
everything from the point where the driver is modprobed?

Luca, there is one thing I noticed, in sn9c102_open():
1501                 err = wait_event_interruptible_exclusive(cam->open,
1502                                                   cam->state &
DEV_DISCONNECTED
1503                                                          || !cam->users);

The problem is that we're holding the sn9c102_disconnect lock so I
don't think cam->state & DEV_DISCONNECTED is ever going to be true.

regards,
dan carpenter

Comment 4 Rafa&#322; Bilski 2006-11-19 23:11:08 UTC
> Rafa&#322;, you posted 2 different stack traces
First was for 2.6.19-rc4. Error was always the same.
Second is for 2.6.19-rc6 because it is always good to check newest version.
These two kernels seems to fail in different way.
I'm using 2.6.19-rc6 now.
> it looks like you disconnected it then reconnected it 6 seconds later.  Is
that correct?
Yes. It looks interesting isn't it?
> Do you think you could post a stack trace again but this time include
> everything from the point where the driver is modprobed?
I have tried but I don't have luck this time. This is all what left in log.

Nov 20 07:35:07 elke Linux video capture interface: v2.00
Nov 20 07:35:07 elke sn9c102: V4L2 driver for SN9C10x PC Camera Controllers v1:1.27
Nov 20 07:35:07 elke usb 2-2: SN9C10[12] PC Camera Controller detected (vid/pid
0x0C45/0x602C)
Nov 20 07:35:07 elke usb 2-2: OV7630 image sensor detected
Nov 20 07:35:07 elke usb 2-2: Initialization succeeded
Nov 20 07:35:07 elke usb 2-2: V4L2 device registered as /dev/video0
Nov 20 07:35:07 elke usbcore: registered new interface driver sn9c102

About 12s later a lot of messages was printed (to fast for me). This is part of
last:
via_driver_irq_handler+0x11/0x157 [via]
[<c01270f9>] handle_IRQ_event+0x1a/0x3f
[<c0128106>] handle_level_irq+0x66/0xa3
[<c0104248>] do_IRQ+0x68/0x80
[<c01029aa>] common_interrupt+0x1a/0x20
Kernel painc - not syncing: Fatal exception in interrupt

And next time computer just lock up after 10s. Without any messages.
I can disconnect mass storage class USB devices and spca5 camera without any
problems.
Comment 5 Dan Carpenter 2006-11-20 00:52:53 UTC
Created attachment 9572 [details]
Balance usb_get_dev() and usb_put_dev() calls.

I don't have the hardware so I haven't tested the attached patch beyond
compiling it.

Based on your messages, it doesn't look like you are using the camera when you
unplug it.  It looks like in that code path we don't call usb_get_dev() but we
do call usb_put_dev()
Comment 6 Anonymous Emailer 2006-11-20 05:31:19 UTC
Reply-To: luca.risolia@studio.unibo.it

The patch below should fix the bug.

Signed-off-by: Luca Risolia <luca.risolia@studio.unibo.it>
---

diff -uprN -X a/Documentation/dontdiff a/drivers/media/video/et61x251/et61x251_core.c b/drivers/media/video/et61x251/et61x251_core.c
--- a/drivers/media/video/et61x251/et61x251_core.c	2006-11-20 14:08:16.000000000 +0100
+++ b/drivers/media/video/et61x251/et61x251_core.c	2006-11-20 14:21:54.000000000 +0100
@@ -1182,8 +1182,6 @@ static void et61x251_release_resources(s
 	video_set_drvdata(cam->v4ldev, NULL);
 	video_unregister_device(cam->v4ldev);
 
-	usb_put_dev(cam->usbdev);
-
 	mutex_unlock(&et61x251_sysfs_lock);
 
 	kfree(cam->control_buffer);
@@ -1275,6 +1273,7 @@ static int et61x251_release(struct inode
 
 	if (cam->state & DEV_DISCONNECTED) {
 		et61x251_release_resources(cam);
+		usb_put_dev(cam->usbdev);
 		mutex_unlock(&cam->dev_mutex);
 		kfree(cam);
 		return 0;
diff -uprN -X a/Documentation/dontdiff a/drivers/media/video/sn9c102/sn9c102_core.c b/drivers/media/video/sn9c102/sn9c102_core.c
--- a/drivers/media/video/sn9c102/sn9c102_core.c	2006-11-20 14:08:16.000000000 +0100
+++ b/drivers/media/video/sn9c102/sn9c102_core.c	2006-11-20 14:20:39.000000000 +0100
@@ -1462,8 +1462,6 @@ static void sn9c102_release_resources(st
 	video_set_drvdata(cam->v4ldev, NULL);
 	video_unregister_device(cam->v4ldev);
 
-	usb_put_dev(cam->usbdev);
-
 	mutex_unlock(&sn9c102_sysfs_lock);
 
 	kfree(cam->control_buffer);
@@ -1555,6 +1553,7 @@ static int sn9c102_release(struct inode*
 
 	if (cam->state & DEV_DISCONNECTED) {
 		sn9c102_release_resources(cam);
+		usb_put_dev(cam->usbdev);
 		mutex_unlock(&cam->dev_mutex);
 		kfree(cam);
 		return 0;




Alle 06:16, luned
Comment 7 Rafa&#322; Bilski 2006-11-20 10:54:58 UTC
Thank You.
Both patches are removing the problem.

Note You need to log in before you can comment on or make changes to this bug.