[AG-TECH] System freezes sending video on Linux w/ IVC-200 capture card

Wed Apr 22 00:13:27 CDT 2009

On 22/04/2009, at 5:42 AM, Andrew Ford wrote:

> 2009/4/20 Christoph Willing <c.willing at uq.edu.au>
>
> On 21/04/2009, at 3:47 AM, Andrew Ford wrote:
>
> Hi Chris,
>
> After some testing we've seen this happen with multiple IVCs and  
> multiple machines - at any rate, we don't have any more spare linux  
> boxes to test with. I have a feeling it might be related to Ubuntu's  
> CPU frequency scaling though, as I've never seen it freeze when I  
> manually set it to use the maximum clock speed. What are the clock  
> settings on your machine?
>
>
>> Andrew,
>>
>> Did you roll your own kernel? When I tried to add the cpu frequency  
>> scaler applet, it reports that I don't have it set in the kernel -  
>> since I try to keep our build machines as standard as possible  
>> (i.e. only latest supplied kernels) and if frequency scaling is  
>> working for you, I'm guessing you have a non-standard kernel. In  
>> that case I suggest you revert to a standard kernel to test whether  
>> the freeze effect goes away. Either the  frequency scaling itself  
>> or the change of some other kernel option may be causing the freeze  
>> effect; reverting to a standard kernel could rule those changes out  
>> as the cause.
>>
>>
> Nope, standard kernel - one machine is a clean install of x86  
> Intrepid, the other is also x86 Intrepid that's been upgraded from  
> Gutsy. What kind of CPUs do you have in your machines? I'm guessing  
> Ubuntu automatically detects on install - for example, it's also  
> automatically enabled on my laptop, which has a Core 2 Duo. It looks  
> like it functions through a variety of kernel modules depending on  
> type of processor - "powernow-k8" for Opterons, for example. I'm  
> going to try disabling that module to see if that does what I want.

Andrew,

It looks like ability to control the cpu speed via the applet is  
determined by a BIOS setting. The intrepid machine here (with Core 2  
Quad) has a Dell BIOS. In the Performance section of the BIOS, the  
SpeedStep setting was set to Off - in that mode I was unable to set  
the cpu speed with the frequency scaler applet. When I turned it On, I  
was able to make the adjustments you mentioned. Setting it back to Off  
returns it to its 100% usage mode.

On another (AMD) machine with PhoenixBIOS, that setting is in the  
Hammer section of the Advanced settings. Enabling the AMD PowerNOW!  
entry allows adjustment with the scaler applet; disabling that setting  
returns it to 100% mode.

chris

>> In my case, without frequency scaling enabled in the kernel, the  
>> scaler applet works in read only mode. From that, I could see that  
>> the clock setting is set to 100%.
>>
>> BTW it looks from the applet like the frequency scaling could be  
>> set to different values on different cores of a multicore machine -  
>> that may also contribute to the freezing.
>
> No - if you set a speed for a core the displayed speed for the other  
> cores on the same processor will change correspondingly.
>
> --Andrew
>
>
>
>
> chris
>
>
>>
>>> 2009/3/29 Christoph Willing <c.willing at uq.edu.au>
>>>
>>>> On 26/03/2009, at 4:58 PM, Christoph Willing wrote:
>>>>
>>>>>
>>>>> On 26/03/2009, at 3:34 AM, Andrew Ford wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> For a while now we've been seeing hard freezes (ie, trying to  
>>>>> kill the X server does nothing) on one of our Linux machines  
>>>>> when it tries to send video via an IVC-200 cap card. It tends to  
>>>>> occur more frequently when the load is heavier - attempting to  
>>>>> send 2 or more 720x480 mpeg4 or h.264 streams causes it to  
>>>>> freeze within 5-10 minutes, 4 h.261 videos make it freeze in  
>>>>> about half an hour, and 2 261 videos makes it last about 2 days.  
>>>>> dmesg and /var/log/messages don't give any clues. Other types of  
>>>>> load don't seem to cause freezes, and I ran memtest86 overnight  
>>>>> with no errors. Originally the machine was Ubuntu 8.04 64-bit,  
>>>>> then 8.10 64-bit, then 8.10 32-bit, and the problem was seen in  
>>>>> all 3. In all cases it was running the UQ-provided AG 3.2beta  
>>>>> with the stock VideoProducer services. I know there was a bttv  
>>>>> driver deadlock issue in kernels pre-2.6.24, but this is running  
>>>>> kernel 2.6.27 so that shouldn't be the problem.
>>>>>
>>>>> Also when sending video on that machine occasionally the stream  
>>>>> would start to flicker, flashing an old frame alternating with  
>>>>> the current output of the camera. Has anyone seen either of  
>>>>> these issues before?
>>>>>
>>>>>
>>>> Andrew,
>>>>
>>>> I just installed a 32bit Ubuntu 8.10 on the UQVislab node's video  
>>>> capture machine. I've been running 2x mpeg4 streams and an h261  
>>>> stream for over two hours. I just powered the machine down to  
>>>> confirm it is actually an IVC-200G card (it is). After the  
>>>> restart, I've now configured it to run with 3x mpeg4 streams.  
>>>> These are full PAL streams 704x576. Its been running for nearly  
>>>> 10 minutes now - will leave it running overnight (in the APAG  
>>>> lobby, if you want to check on them) and report back. Based on  
>>>> the previous successful 2 hour test, I think this 3 large streams  
>>>> test will be OK too.
>>>>
>>>
>>> Andrew,
>>>
>>> We've now had this setup (32bit Ubuntu 8.10 with IVC-200G  
>>> streaming 3x mpeg4 streams @ 704x576) running continuously for  
>>> over three days now without any discernible problem. That result  
>>> suggests a hardware issue with your capture card (or even the  
>>> machine itself).
>>>
>>>
>>> chris
>>>
>>>
>>
>>
>> You could try reseating the card - maybe some dust or contact  
>> oxidation is creating some bad effect? Do you have any similar  
>> capture cards lying around you could temporarily replace the IVC  
>> with? That may indicate whether you have a card fault or machine/OS  
>> fault.
>>
>>
>> chris
>>

Christoph Willing                       +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland