On 22/04/2009, at 5:42 AM, Andrew Ford wrote: > 2009/4/20 Christoph Willing <[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.
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 <[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
