Haiku randomly crashes when executing terminal commands

[Undoified]

Haiku randomly crashes when executing some terminal commands (usally comands that execute multiple other command, such as neofetch and config scripts) and when starting the terminal. The entire system, or perhaps just the graphics, freezes.

This only occurs on x86_64 running natively (doesn't happen running in a virtual machine).
My computer has a FX 6300 prossesor, an RX 560 graphics card, and is running hrev52837.

[humdinger]

You may want to have a look at the syslogs in /var/logs/ so see if the crashes are logged there and upload it here. Maybe you have assigned not enough RAM for the virtual environment? Also make sure in Haiku's VirtualMemory preferences, that VM is activated.

[alpopa]

Does the problem persists when using single CPU boot option?

[Undoified]

Replying to humdinger:

You may want to have a look at the syslogs in /var/logs/ so see if the crashes are logged there and upload it here. Maybe you have assigned not enough RAM for the virtual environment? Also make sure in Haiku's VirtualMemory preferences, that VM is activated.

I purposly crashed Haiku and uploaded the syslog, and it appears to be a problem with BFS. I appear to have made a typo on the ticket - this only happens on hardware, and doesn't occur when using a virtual machine.

[Undoified]

Replying to alpopa:

Does the problem persists when using single CPU boot option?

No, it does not.

[humdinger]

Replying to Undoified:

I purposly crashed Haiku and uploaded the syslog, and it appears to be a problem with BFS.

Do a backup of important files, then try a "checkfs /boot" (or maybe "checkfs -c /boot" first for a testrun).

I appear to have made a typo on the ticket - this only happens on hardware, and doesn't occur when using a virtual machine.

I changed the text accordingly.

[alpopa]

Replying to Undoified:

Replying to alpopa:

Does the problem persists when using single CPU boot option?

No, it does not.

In this case, the bug may be the same, or have the same root cause, as in #10279.

[Undoified]

Replying to humdinger:

Replying to Undoified:

I purposly crashed Haiku and uploaded the syslog, and it appears to be a problem with BFS.

Do a backup of important files, then try a "checkfs /boot" (or maybe "checkfs -c /boot" first for a testrun).

I appear to have made a typo on the ticket - this only happens on hardware, and doesn't occur when using a virtual machine.

I changed the text accordingly.

I ran checkfs. It had no effect, which doesn't really surprise me considering the issue is still present on a clean install of Haiku.

[Undoified]

Replying to alpopa:

Replying to Undoified:

Replying to alpopa:

Does the problem persists when using single CPU boot option?

No, it does not.

In this case, the bug may be the same, or have the same root cause, as in #10279.

I think its probably related, but I'm not entirely convinced its the same bug. #10279 is blocked by #14082 which includes some attachments of kdl output, however when my system crashes i don't receive any kdl output. Python seems stable to me, which it isn't under #10279.

[waddlesplash]

Probably this is the same as #14718, though, which has the same kind of lockup.

I've found some hardware this is easily reproducible on by changing HDA settings. However I have no idea what's going on, and the fact that KDL is not enterable via the emergency keys in this state make it notoriously difficult to debug.

[waddlesplash]

I recently committed hrev52883 which might catch this as a panic (unlikely, it's probably some more nefarious issue.) Please test on that if you can.

Also, the output of listimage | grep kernel on a completely idle system would be helpful.

[diver]

Replying to waddlesplash:

I've found some hardware this is easily reproducible on by changing HDA settings.

This is #9560.

[waddlesplash]

I don't think so, I don't get a kernel crash, just a deadlock. KDL is definitely working, as I can drop into it before triggering the lock, but then afterwards I can't. So it's not a page fault.

[waddlesplash]

The top 2 commits in hrev52902 will catch more cases of illegal context switches, which may help with diagnosing this.

[waddlesplash]

hrev53046 and hrev53041 add some more asserts here. Please retest after that.

[alpopa]

(Also added this comment to #14082)

Retested hrev53092 on AMD Phenom II x4 955. I can compile from Terminal large projects, and compilation takes several (tens of) minutes with no problem. However, when trying to grep something simple, the system restarts instantly.