[x264-devel] Bug Report/Help?

Tue Aug 14 18:32:03 CEST 2007

If you think it's your memory, visit http://www.memtest.org/ for a
free, open source memory testing tool. It does not run inside your OS,
rather at boot time, but there is no more effective memory testing
application.

Paul.

On 14/08/07, Kevin P. Jacobson <kevin at kjake.net> wrote:
>
>
> Benjamin, thanks for your reply.  I don't have a kill-a-watt, but I know
> somenoe who has one and could borrow it I suppose.  I used to have two
> additional hard drives in this system when it was a core 2 duo, I don't
> think it is a wattage problem, but I'll check it.
>
> Consensus has been pretty clear that something is up with my memory.  I did
> purchase it through NewEgg, and they are known for being reasonable about
> exchanges, I'll contact them...I do not have any other memory around.
>
> Thanks.
>
>
>  ________________________________
>  From: x264-devel-bounces at videolan.org [x264-devel-bounces at videolan.org] On
> Behalf Of Benjamin Rosenblum [ben at brosenblum.com]
>  Sent: Tuesday, August 14, 2007 10:33 AM
>
>  To: Mailing list for x264 developers
>  Subject: Re: [x264-devel] Bug Report/Help?
>
>
>
>
> So just to confirm what your saying, even if you run x264 10 times with the
> exact same settings/source/everything, it reboots at different spots in the
> encode and not always at the same spot?  While I'm no expert on the inner
> workings of x264, I would venture to say that if thats the case its almost
> definitely not (directly) an x264 issue since in theory x264 should run
> basically identically for each of those runs.  Think about it this way, if
> you take x264 down to the most basic level, its only really a calculator
> designed to run predefined mathematical equations on a set of numbers to
> generate another set of numbers.  Given that those equations aren't changing
> (which they obviously aren't assuming your using the same x264 binary and
> cli options each time), and that the input numbers (your source) aren't
> changing, x264 should in theory run exactly the same every time.
>
>  Given that all of the above is true and that you are seeing the reboots at
> different (and dare I say random) times through the encode, I would agree
> with everyone elses view that this is a hardware problem.  While I realize
> 600W sounds like a lot (and yes it should be plenty), have you ever actually
> tested to see how much power your system is sucking out of the wall?  How do
> you know your power supply isn't defective in some way that it could be
> having issues at higher loads?  One really good way to test this is using a
> little gadget called a Kill-A-Watt
> (http://www.the-gadgeteer.com/review/kill_a_watt_electric_usage_monitor_review).
>  I've had one of these monitoring my server since I built it a few months
> ago (actually its monitoring the UPS since thats in the line between it, but
> you get the idea).  I've seen my system get as high as 550W when working it
> to the max (its a dual x5355 quadcore xeon, so you can imagine, it sucks
> some juice).
>
>  The only other thing that pops into my head as a possible cause is a bad
> ram chip.  Specifically one spot on one chip on one piece of ram.  I saw an
> issue similar to this about a year ago when building a media center for my
> father.  The system would just "randomly" reboot under load.  There was no
> definitive way to cause the reboot or any particular amount or duration of
> the load similar to your situation.  What actually helped us narrow down the
> problem was that the ram we were using (crucial's ballistix tracer line) had
> led's on it that would show different things when under different usage.  We
> noticed that when one particular chip would get to a specific amount of load
> the reboot would happen.  My guess is that a similar thing could be
> happening to you.  As your system loads up and allocates the memory, its
> very possible that its allocating it to different areas of the physical ram
> chips.  When your encode hits that spot in the ram, the system goes nuts and
> something triggers the reboot to happen.  BTW, when we ran memtest86 on that
> ram, it performed perfectly in every test also.  Again, this is just a
> thought, but if you have more then one stick of ram in there I would be
> curious to see if you can do a few passes with some of the sticks removed
> (and rotate which ones are out obviously between passes, just make sure you
> track which is which and put them back in the original configuration so that
> we don't skew any future results of tests that could point to bad ram).
>
>  I hope some of that helped or at least triggered a thought in some one else
> for another idea if my theory isn't right.
>
>
>  Kevin P. Jacobson wrote:
>  Sorry for lack of details...
>
> Power Supply is 600W, it should be plenty.
>
> CPU doesn't get over 50C at any time, and I have run it over 68C before with
> other applications. CPU or memory is not overclocked.
>
> The reboots are random. It always happens on the first pass, it has been at
> the very beginning of the pass (as soon as I press Enter to execute), half
> way, 3/4, almost done. A full first pass is supposed to run for around 6
> minutes (~23min DVD clip @ ~100fps).
>
> I ran two full passes of all 8 tests from memtest86 on the memory last
> night, no errors reported.
>
> I have had perfectly fine uptime with this system. For example, DVDShrink
> also makes use of all four cores and I can run three instances of it at a
> time, most of the time running more than 10 minutes.
>
> I am very close to installing XP on this machine, I have had some headaches
> with Vista. While I love linux and use it all day at work, it is just not an
> option for my desktop at home, sorry Guillaume.
>
> Again, thank you for your time and suggestions.
>
> -Kevin
>
> ________________________________________
> From: x264-devel-bounces at videolan.org [x264-devel-bounces at videolan.org] On
> Behalf Of Tomas Carnecky [tom at dbservice.com]
> Sent: Tuesday, August 14, 2007 3:57 AM
> To: Mailing list for x264 developers
> Subject: Re: [x264-devel] Bug Report/Help?
>
> Kevin P. Jacobson wrote:
>
>
>  I am trying to run x264 on a Xeon X3220 (Quad Core @ 2.40Ghz). I am
> using the binaries at http://x264.nl and have tried the most recent
> (r669) all the way down to r654 without success. My system usually
> reboots spontaneously, but sometimes it will just freeze. I am running
> Windows Vista Ultimate and have 2GB of RAM (DDR800, Corsair). I am
> going to run memtest86 on the computer tonight to rule out a memory
> problem, but I think this is related closer to my Quad Core processor
> and that is something that I don't know much about.
>
>  Maybe insufficient power supply. You didn't tell how long it takes until
> the computer reboots, it it right as soon as you start x264 or after it
> runs for some time?
>
> tom
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
>
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
>
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel