System restarts instantly trying heavy terminal compilation

[alpopa]

When trying to compile some large project from Terminal using make / jam or when trying to execute some not trivial scripts, the system restarts instantly.

Tested on Haiku x86-64 on real hardware CPU AMD Phenom II x4 955 3.2 GHz, 12GB RAM, GPU NVIDIA GP107 GeForce GTX 1050 2GB RAM.

This situation was so long time ago, but situation improved much on hrev53092 (see the comment in #14887 from 27.04.2019) and was stable on hrev53393 (21.08.2019). Now on hrev53971 (14.03.2020) the situation is again less than satisfactory.

May be related to #14887.

[Coldfirex]

syslog?

[X512]

Triple fault?

[waddlesplash]

#14082 may be related here (however that's about AMD FX "Bulldozer" processors.)

[alpopa]

Restart occurs sporadically but quite often. syslog.compilation-short is (hopefully) for restart shortly after compilation start. Once the system restarted several times: starting from very beginning of an compilation process and 4 or 5 times just after entering in desktop - syslog.autoreboot.

[X512]

Does in work fine in virtual machine on same PC with hardware virtualization enabled and multiple cores?

[alpopa]

I tested Haiku x86-64 hrev54105 on qemu under Linux (Debian 10 Buster). I checked kvm is enabled and 4 cores are configured. The compilation was stable.

For the sake of experiment correctness, I performed several compilations on bare metal on the same PC. The first 2 compilations were under hrev53971: one with triple fault (I don't remember at which stage of compilation) and another simple restart. This one was during writing core file (this file is ~35 MB and is written in several minutes). Both compilation took quite long (several tens minutes) until restart.

After that I updated Haiku on real hardware to hrev54105 and performed two more compilations. Both finished without restart or KDL.

It may mean Haiku hrev54105 is more stable than previous versions. I will also try to test previous versions of Haiku on qemu and report how it behaves.

[waddlesplash]

Kernel changes of potential interest:

• hrev54012 (fno-semantic-interposition)
• hrev53991 (mount rw_lock)
• hrev53988 (user boundary validation)
• hrev54101 (IORequest clamping)
• hrev54097 (DMAResource incorrect early unlock)

None of these strike me as being especially likely to have any effect on random triple faults and reboots, though, seeing as they did not have that effect elsewhere. I guess hrev54012 is the most "unknown" here as to what effect it had, but I recall running a diff on the generated assembly for a test file and saw the changes were mostly minimal. But admittedly I did not check the full kernel, possibly it caused significant changes to the final link.

It will be very interesting if the problems are actually gone, I suppose.

[waddlesplash]

Actually, in the compilation syslog, there is a lot of this:

KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0x10073df178, ip 0x1000d3d0ca, write 1, user 1, thread 0x61c
KERN: write access attempted on write-protected area 0xa74f at 0x0000001007288000

It's possible that the user_memcpy test changes actually affected this, I suppose, if that was the source of the faults.

[alpopa]

Retested Haiku x86-64 hrev53971 in qemu under Linux. The compilation seems stable.

I am not sure how to interpret these results. It may mean Haiku in qemu is more stable than on real hardware. There are several differences between VM and PC installations:

1. On VM I created clean Haiku environment without many extra packages and never updated OS or packages, unlike Haiku on PC;
2. On VM I use GUID partition scheme with 1 partition for Haiku, on PC I use MBR partition scheme with 14 partitions (1 is extended) and Haiku is on the 8th logical volume. On VM all partitioning and formatting are done within Haiku, on PC partitioning is done in Linux, formatting in Haiku. On VM Haiku partition is 8GB, on PC it is 100GB;

It will be very interesting if the problems are actually gone, I suppose.

Glad to see Haiku is stable enough for lengthy compilation processes. At very least, I did not see the restarts immediately after compilation start for quite long time. Restarts during compilation in tens of minutes or hours after start do occur sporadically, but there is a good chance a compilation attempt will succeed.

Unfortunately, the root cause is still unknown. If I can perform some more tests, or provide some more information, let me know. Alternatively, this bug can be closed and if the problem will become annoying in the future, I will reopen it and provide as much information as possible.

[X512]

Ticket should be not closed because issue is valid and there are no strong evidences that it is hardware failure. Other people reported similar issue.