Actually, no. All of those OSes you mentioned are recently ‘AMD processor patched’ at various builds/releases for certain AMD family/model releases.They all suffered the same or similar fate during their previous releases.
Hardware health checks and BIOS updates help alleviate some/most of the issues.
My AMD PC is from 2010 with BIOS from 2009. I use all these OSes installed on different partitions of the same computer at the same time. Moreover, I used these and other OSes (Debian GNU/Hurd, Plan 9, etc) for more than 10 years. I installed and used different versions of each OS on this PC and on my previous computers (all with AMD CPU). And I can certainly say this kind of problem did not appear except for Haiku. All previous AMD CPUs were single core, so the problem was not there. And when I disable all but one core on my current AMD Phenom, its stability improves much (at least this particular problem goes).
It may be true. But again, the very same combination of motherboard, CPU, BIOS, RAM, graphics etc has different effect on Haiku than on other OSes installed alongside with respect to this particular problem - restart during heavy compilation.
Have you tried building Haiku x86_64 from Ubuntu on your system and it reboots with more than two cores active? I have not tried to build Haiku x86_64 from within another OS other than Haiku x86_64.
I have detailed files…
OK. My comments are from the actual bug reports and patches I had to use from those OSes from years prior and even recently (I happen to look up a few during this discussion). If we review pre-2010 OS releases or some of the recent ones, you’ll see the bug reports mentioned.
I used Haiku with an AMD Athlon 64 Processor 3200+ Socket 939 system which ran pre-Haiku R1B1 and the R1B1 release - now migrated to faster multi-core systems. Before that, my faithful dual-core AMD Opteron workstation w/ 32GB RAM. The AMD Athlon 64 was pretty rock solid and ran two monitors (cloned). I’ve tested all of the mentioned OSes on it with decent results as well. The BIOS release was around the Y2010 era.
Remember, everything is just electronics and code. Dust, debris, slightly defective hardware, wrong code execution - all these things can trip a motherboard into reset as a protective measure (or cause a kernel crash event). Some motherboard manufacturers provide the certain fixes in BIOS (ROM) or within the OSes, These fixes in the OSes and BIOS help alleviate or bypass certain circuitry issues or data/stack bashing that can trip/reset your hardware or just crash kernels/freeze systems. This is possible without tripping a kernel crash event (suprise, suprise) as I’ve witnessed it myself. Enterprise-grade commercial OSes didn’t end with a kernel-crash - just a motherboard reset. Some hardware can appear perfectly fine until the right/wrong code (whether from grep or jam or make -j8) is executed. It is all electronic circuits running hot and cold with the peeking and the poking…
Some AMD processors have multiple “dual-core” modules. These modules can mistakenly appear as the physical cores and the core components can appear as virtual threads (versus physical CPU cores). So, a 8-core processor can appear as a 4-core/8-thread processor versus a 8-core/8-thread processor - and not get the performance of a true physical 8 CPU equivalent. Issues can appear once a certain OS goes beyond using one of those ‘dual-core’ modules and into intermodule mode…
So, are the Bulldozer/Vishera CPU’s ones that use this “intermodule mode” you speak of? Is Haiku’s Jam expecting a “standard multi-core CPU” design (older AMD and Intel designs) and getting thrown for a loop when the CPU doesn’t react the way it thinks it should? Is there a “failsafe” mode that Jam can use that would work? Is the Bulldozer/Vishera CPU designed in such a way, it doesn’t handle things the same way other CPU’s do (kinda a “break from the norm”; I believe the Bulldozer design was meant to be a “new start”, if I recall correctly), so asking it to do things “standardly” tends to freak it out?
What systems/CPU’s have been used successfully (all cores/threads going (3 or more cores/threads)) in Jam’ing Haiku from within Haiku? That may be the easiest solution to this situation… what MB (Intel/AMD) chipsets are supported? We really should have this kinda stuff listed in a concise format.
As far as we can tell, AMD Bulldozer is the only variant with this problem. AMD CPUs both before that and after that work just fine, so if anything we need an “exception” list.
Well, if Vishera is a “upgrade“ of Bulldozer (which is what it is, if I read things right), then it likely has the same issue for that reason.
The issue happens only in Haiku. Jam itself or any of the tools is not at fault. There is some bug in the hardware that makes it not behave as expected. Other OS probably found it and applied some workaround (microcode updates or whatever was needed) so that they don’t have this problem. It’s hard for us to say more: if we knew exactly what was happeningm we would have fixed the problem already. So far we’re at the very generic level and we don’t know more than this:
Given this, what we need to do is look at other OS (Linux and *BSD, probably) and see if they had similar issues and how they solved them. Maybe microcode updates (to patch and fix the CPU itself), maybe some workaround documented by the CPU manufacturer where we need to insert some extra instruction somewhere to help the CPU keep track of what’s going on, maybe there is something in the CPU that’s completely broken and there is some instruction we should never use because it will crash everything.
As far as I know at this point the issue has not been investigated further than this.
In any case, the problem is not in Jam (in general, if the machine reboots like this, it’s because something went wrong at the hardware or at the kernel level, applications are not to blame). It’s somewhere between the Haiku kernel and the CPU. Replacing either of these will solve it.
If anyone has Haiku x86_64 running on a specific motherboard/CPU combo that has 4 cores or more and can Jam Haiku x86_64 from it (all cores/threads going), I’ll definitely consider buying it on eBay or NewEgg or somewhere… 
I’d rather build Haiku from within Haiku than have to go outside and use Ubuntu or something… call me a purist.
If i am not mistaken, here is the errata sheet of your current cpu, see how many bugs lurking in the hw/microcode?
https://www.amd.com/system/files/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Guide.pdf
I don’t think so. Haiku on my AMD system is rock solid even on heavy load when doing GUI tasks. But when trying to do something heavy in Terminal (command line) it becomes very unstable and often restarts in the same moment the task was started. So I tend to believe the issue is rather in excessive / concurrent filesystem reads / writes or something similar.
Then, OS-related. I noted you mentioned system stability with hrev53393 x86_64. So, let us revisit
testing on:
Let us rule out any hardware issues for now…
I would be happy to see it fixed. In case I can provide some more information, please ask it in #15817.