[x264-devel] Bug Report/Help?

Benjamin Rosenblum ben at brosenblum.com
Tue Aug 14 16:33:46 CEST 2007


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
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070814/fc1de49f/attachment.htm 
-------------- next part --------------
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel


More information about the x264-devel mailing list