Re: [Spca50x-devs] Aiptek DV 4100M/DV3500, kernel oops at dark light + dynamic lightswitches
- Date: Fri, 02 Jun 2006 06:03:43 +0200
- From: thomas schorpp <t.schorpp@xxxxxx>
- Subject: Re: [Spca50x-devs] Aiptek DV 4100M/DV3500, kernel oops at dark light + dynamic lightswitches
michel Xhaard wrote:
> Le Jeudi 1 Juin 2006 17:57, Jon M. Lamb a écrit :
>
>>I have a Aiptek Pocket DV 4100M camera. lsusb gives an ID of
>>08ca:2040. After trying several I was able to get it working with the
>>following bridge.
>>
>>case 0x2040:
>>
>> spca50x->desc = AiptekDV4100M;
>> spca50x->bridge = BRIDGE_SPCA536;
>> spca50x->sensor = SENSOR_INTERNAL;
>>
>> spca50x->cameratype = JPEG;
>> info("USB SPCA5XX camera found. Aiptek DV4100M");
>> memcpy(&spca50x->funct,&fsp5xxfw2,sizeof(struct cam_operation));
>> break;
>>
>>I get an image and the pc is stable if I leave the camera pointing
>>outside. (Tested for at least an hour) If I move the camera to quickly
>>perhaps making the image become to dark as someone mentioned in a
>>previous post my PC freezes. Was a solution found for this and is there
>>something I should do to get this camera included in the driver?
>>
>>Jon
>>
>
>
> Jon,
> I will setup your patch for the next revision. Thanks for your feedback.
> The freeze seem to happen when the light come dark, that mean when the time
> exposure is very long and the frame rate slow . That seem strange, i suspect
> a chips fault. Did you have some errors in the /var/log/messages like timeout
> (error -110) ?
> regards
Jon,
i get the same problems with the DV3500 since ~ kernel 2.6.15 with this driver. google finds
some statements about performance enhancements in scheduler and software interrupt handling
around this release times. maybe the kernel guys have "overoptimized" it somehow.
from my view the kernel devs have optimize priorities for server linux from the big guys
(redhat, novell...) not desktop, so maybe dont expect too much from LKML.
1. can we see a oops trace from You, pls?
2. manufacturing date of the DV device and usb hw pls (reports of chip hw degration around).
3. behaviour with m$ windos?
4. list all Your usb devices on the system, pls.
5. is your kernel preemtible (schorpp@tom1:~$ uname -a
Linux tom1.schorpp.dyndns.dk 2.6.16.18 #4 PREEMPT Tue May 23 15:35:59 CEST 2006 i686 GNU/Linux
) ?
@michel: no usb timeouts in the logs here, no strangeness with usb-debug/debugfs turned on, sorry cant confirm.
i get the crash behaviour >80% better by disabling the BUG() in /usr/src/linux/kernel/softirq.c (see my patch
on this list, remove the simple users blocking "." before applying) and letting
the exception be handled elsewhere it works most of the time
but thats no real solution, it works at least most of the time at videoconferencing at same overall light-exposure:
--- /usr/src/linux-2.6.16-dbg/kernel/softirq.c 2006-03-22 00:28:17.000000000 +0100
+++ /usr/src/linux-2.6.16-dbg/kernel/softirq.c 2006-03-22 11:19:06.000000000 +0100
@@ -262,8 +262,9 @@
if (tasklet_trylock(t)) {
if (!atomic_read(&t->count)) {
- if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
- BUG();
+ test_and_clear_bit(TASKLET_STATE_SCHED, &t->state);
+// if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
+// tasklet_kill(t);
t->func(t->data);
tasklet_unlock(t);
continue;
you can get some picture of the behaviour by trying to (illegally) kill the (spca5xx-usb)
tasklet while in interrupt instead to BUG(),
theres a function in softirq.c to do that and you can use instead of BUG():
--- /usr/src/linux-2.6.16-dbg/kernel/softirq.c 2006-03-22 00:28:17.000000000 +0100
+++ /usr/src/linux-2.6.16-dbg/kernel/softirq.c 2006-03-22 11:19:06.000000000 +0100
@@ -262,8 +262,9 @@
if (tasklet_trylock(t)) {
if (!atomic_read(&t->count)) {
- if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
- BUG();
+// test_and_clear_bit(TASKLET_STATE_SCHED, &t->state);
+ if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
+ tasklet_kill(t);
t->func(t->data);
tasklet_unlock(t);
continue;
such a message printk("Attempt to kill tasklet from interrupt\n");
is printed more or less rapidly in the console then giving a clearer fault-occurring/-timing picture of what is
happening, the kernel does not oops then but the only way sometimes to get out after this is sysrq-keys.
maybe spca5xx is overloading the scheduler through the usb subsystem somehow at certain condition, but thats unsure speculative.
theres advanced kernel debugging needed to trace back this fault.
BTW, ive got more and more windos users here reporting evil troubles with their usb devices,
so there maybe general problems with nowadays cheap manufactured usb hardware kernel usb
developers have to face and workaround. so linux usb is not to be blamed first.
tom
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Spca50x-devs mailing list
Spca50x-devs@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/spca50x-devs