2009/4/20 Christoph Willing <[email protected]<mailto:[email protected]>>
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.
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
<[email protected]<mailto:[email protected]>>
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
Christoph Willing +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland
Christoph Willing +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland
