[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