Weird build errors only on 3rd core of quad core CPU

Michael Powell nightrecon at
Wed Jan 27 23:32:36 UTC 2010

Pieter de Goeje wrote:

> I am suspecting a broken CPU, but am not sure.
> These commands:
> cd /usr/ports/sysutils/hal
> cpuset -c -l 2 make
> Will always result in errors, for example this one:
> gmake: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by
> `'.  Stop.
> *** Error code 1
> Sometimes the error occurs in a different place. When I check the input
> files, they are indeed broken. Gcc stops because of syntax errors for
> example.
> The configure process always completes, but apparently it creates broken
> files. When I run make on any other core, it always completes
> successfully: cpuset -c -l 0,1,3 make
> I've checked with script that the output of the build process is exactly
> the same, up until the error occurs. I've also tried to run cpuburn on
> that core, but it didn't find any problem. It's really weird that system
> is otherwise very stable.
> What do you guys think the problem is?
> CPU is AMD Athlon II X4 620. Running FreeBSD 8-STABLE/amd64. I've also
> tried -CURRENT, but it didn't help.

As a test I just ran these two commands on my Athlon II 630 here, but 
running FreeBSD 8.0-RELEASE-p2 amd64 build. The make process ran directly to 
completion with no error. With overclocking too. Tried 4 runs, on each core.

I'm not sure I recall all the details correctly without checking, but I 
thought there were some early samples or generations of these processors 
that were not the same as the final production releases. Something to do 
with being Phenom cores that had L3 cache disabled, being released as early 
engineering samples but the die of the final products is different with no 
L3 cache present from manufacturing.

I'd check into the stepping and if it turns out not to be a final version 
get whoever you bought it from to replace it. It may not be the core itself, 
but bad L1/L2 cache. It's either that or the only other difference is you're 
running stable, and I'm not. But I'd suspect bad cache spots in L1/L2.


More information about the freebsd-questions mailing list