Web lists-archives.org

Re: [linux-usb-devel] Re: [Spca50x-devs] [BUG] kernel stall in spca50x driver - reopened

michel Xhaard wrote:
> Le Samedi 11 Mars 2006 16:57, thomas schorpp a Ãcrit :
> 
>>michel Xhaard wrote:
>>
>>>Le Vendredi 10 Mars 2006 15:31, thomas schorpp a Ãcrit :
>>>
>>>>>Thomas,
>>>>>The problem here is very complex that should be:
>>>>>software:
>>>>>	The usb layer on the kernel API
>>>>>	The driver specially the spcadecoder
>>>>
>>>>most likely.
>>>>
>>>>
>>>>>Hardware or firmware:
>>>>>	The Aiptek DV3500
>>>>>	The usb Host controller
>>>>
>>>>impossible. unchanged since a year and working fine under winxp.
>>>>and worked under linux fine until at least kernel 2.6.13.
>>>>
>>>>
>>>>>As in all your report you speak about light or contrast we can
>>>>>raisonably disable the kernel API and the spcadecoder these two parts
>>>>>don't care about light :)
>>>>
>>>>hmm, ok theoretically.
>>>>
>>>>
>>>>>In the same way we can disable the Usb Host Controller.
>>>>>Now only the Aiptek DV3500 is on the list
>>>>>What about light and the video processor in the DV
>>>>>	If there are a lot of light the video processor on the DV decrease the
>>>>>times exposure, of course decreasing times exposure will increase the
>>>>>frame rate. As a second effect with a lot of light the jpeg encoder
>>>>>inside the chips find more details in the picture so the picture size
>>>>>increase. With this context we expect a very Hight CPU load
>>>>
>>>>ill check this.
>>>>
>>>>
>>>>>	If there are not enought light the video processor increase the times
>>>>>exposure that will of course decrease the frame rate.
>>>>>All this process are know to be Autoexposure, set inside the chips
>>>>>firmware. All spca jpg webcam is set with this feature by default. We
>>>>>did not have acces to this feature, know only by Sunplus and maybe M$
>>>>>developper.
>>>>>I suspect the chips to go out the limit of the Autoexposure and goes to
>>>>>sleep when the interrupt Handler withing the kernel is waiting for data
>>>>>.
>>>>
>>>>this could be traceable with verbose printk logs or debugfs.
>>>>if it is i will try to handle this state somehow if possible.
>>>>but this was surely *no* problem before 2.6.14. it worked just fine.
>>>>
>>>>
>>>>>I have no
>>>>>solution ATM and cannot produce the same effect as your DV3500 with my
>>>>>old DVII sorry :(
>>>>
>>>>sorry, but ive never seen autoexposure under linux with this device and
>>>>the spca driver. i had to have always adjust brightness manually.
>>>>so this would be out, too.
>>>
>>>Can you on a running kernel do the following test:
>>>Dark context choice a room with small light
>>>	run
>>>	spcaview -d /dev/video0 -f jpg -s 320x240
>>>	after 30s stop spcaview with q
>>>	note the frame rate get in the console.
>>
>>done. immediate kernel lockup at startup. no logs.
>>picture usually complete black.
>>
>>
>>>Bright context maybe outdoor light
>>>	run
>>>	spcaview -d /dev/video0 -f jpg -s 320x240
>>>	after 30s stop spcaview with q
>>>	note the frame rate get in the console.
>>>Is there the same ? can you mail me the result.
>>
>>done. camera against daylight room window.
>>varied light exposure by putting hand at front of the sensor
>>slowly and repeatedly from 0-100%.
>>
>>no issues. and the device does autoexposure at daylight :)
>>
>>turnig camera back to room and making room dark slowly:
>>kernel lockup.
>>last picture 98% black.
>>remarkable was a sudden colour change from daylight to
>>(flourescent) room light.
>>
>>requested log attached.
>>
>>
>>>Best regards
>>
>>best regards,
>>thomas
> 
> Thomas,
> good work, so the kernel hangs when the light become dark The strange is why a 
> crash

not in this case:
>>done. camera against *daylight* room window.
>>varied light exposure by putting hand at front of the sensor
>>slowly and repeatedly from 0-100%.

but in this:
>>turnig camera back to room and making room dark slowly:
>>kernel lockup.
>>last picture 98% black.
(*flourescent light lamp with 50hz* !!! this could be the problem)

and on startup capture with black picture.

> Is there a real crash with all led on the keyboard blinknig ? or the 
> screen of spcaview become dark and stop to respond ?
> In the second case you can try to press twice CTRL C that should interrupt 
> spcaview
> When the crash occurs did you have an access to the machine via IP (try a ping 
> with another box )?

no inet, no blinking, no oops, no working magic-sysreq key, no reaction even if kernel 
is booted and controlled and debugged over serial device console remotely.

nothing. the kernel *is in locked up state* somewhere as i said.
kernel is configured with debug option soft-lockup-detect and some others.
no experimental usb features are in. kernel 2.6.15.6 meanwhile.

windows kernel debugging has a feature to break-in over serial console in this 
case, but i dont know how this could be done with the linux kernel. you?
and i believe the kernel main-thread stalled too, so no use anyway.

> 
> regards



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Spca50x-devs mailing list
Spca50x-devs@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/spca50x-devs