I think for current Haikuporter versions, you need Python 3?
2 Likes
Indeed python3, just check on the RC’s that one is included, before them it could be that you had to install it first
There are no python3 in haikuports.cross.
1 Like
Yes, because no one has done a bootstrap since haikuporter migrated to Python 3. So we need to update haikuports.cross with newer versions of some recipes.
6 Likes
I’ve been working on python 3. It builds for ARM64, but havn’t gotten other build packages done.
3 Likes
tqh, when will your work on arm64 be available?
1 Like
I sidetracked on haikuports packages, as it would benefit both ARM64 and RISC-V. However for ARM64 there is a lot of low-level code that needs to be implemented, so I think it at some point would need some attention from someone with more ARM64 knowledge. I havn’t spent much time with computers lately either.
4 Likes
Pushed my python related haikuports.cross recipies. Rebuilding from a clean version to see if it is good. For dev-libs/libffi_bootstrap/libffi_bootstrap-3.3.recipe and dev-lang/python_bootstrap/python_bootstrap-3.9.1.recipe the ? for riscv would need to be removed I think, and then probably some build fixes. In haiku build/jam/repositories/HaikuPortsCross/riscv64 would need to use the right recipes as well.
14 Likes
Currently I trying to run haikuporter on packagefs Haiku on real hardware. I sometimes get crash in kernel signal handler here:
STrap(exception loadPageFault)
sstatus: (ie: {}, pie: {}, spp: s, sum: 1)
sie: {sTimer, sExtern}
sip: {sTimer}
stval: 0x3ad3756010 <user area> 0x10
tp: 0xffffffc12c0a0080(bash)
PANIC: page fault with interrupts disabled
Welcome to Kernel Debugging Land...
Thread 2468 "bash" running on CPU 0
Stack:
FP: 0xffffffc000fbe480
FP: 0xffffffc000fbe590, PC: 0xffffffc00215a7d1 <kernel_riscv64> arch_debug_call_with_fault_handler + 91
FP: 0xffffffc000fbe5e0, PC: 0xffffffc0020d23b1 <kernel_riscv64> debug_call_with_fault_handler.localalias.7 + 129
FP: 0xffffffc000fbe670, PC: 0xffffffc0020d39db <kernel_riscv64> _ZL20kernel_debugger_loopPKcS0_Pvi + 299
FP: 0xffffffc000fbe6e0, PC: 0xffffffc0020d3cc7 <kernel_riscv64> _ZL24kernel_debugger_internalPKcS0_Pvi + 135
FP: 0xffffffc000fbe720, PC: 0xffffffc0020d400f <kernel_riscv64> panic + 101
FP: 0xffffffc000fbe860, PC: 0xffffffc00215bc9f <kernel_riscv64> STrap + 1075
FP: 0xffffffc000fbe960, PC: 0xffffffc00215991d <kernel_riscv64> SVec + 77
FP: 0xffffffc000fbed60, PC: 0xffffffc0020a15ad <kernel_riscv64> handle_signals + 191
FP: 0xffffffc000fbed90, PC: 0xffffffc0020b1c85 <kernel_riscv64> thread_at_kernel_exit + 25
FP: 0xffffffc000fbee90, PC: 0xffffffc00215b94b <kernel_riscv64> STrap + 223
FP: 0xffffffc000fbef90, PC: 0xffffffc0021599dd <kernel_riscv64> SVecU + 109
FP: 0x3a5d061c40, PC: 0x207995e6f7 <libroot.so_seg0ro> 0x3c6f7
3 Likes
there’s a few x86 tickets in trac for similar issues, be great if the port fixed to Risc-V lead to a solution
Page table entry seems fine, user access flag (SUM) is also enabled, strange… Probably some race condition.
STrap(exception loadPageFault)
sstatus: (ie: {}, pie: {}, spp: s, sum: 1)
sie: {sTimer, sExtern}
sip: {sTimer}
stval: 0x3f317df010 <user area> 0x10
tp: 0xffffffc001ce05c0(bash)
PANIC: page fault with interrupts disabled
Welcome to Kernel Debugging Land...
Thread 1792 "bash" running on CPU 0
Stack:
FP: 0xffffffc000fca480
FP: 0xffffffc000fca590, PC: 0xffffffc00215a7d1 <kernel_riscv64> arch_debug_call_with_fault_handler + 91
FP: 0xffffffc000fca5e0, PC: 0xffffffc0020d23b1 <kernel_riscv64> debug_call_with_fault_handler.localalias.7 + 129
FP: 0xffffffc000fca670, PC: 0xffffffc0020d39db <kernel_riscv64> _ZL20kernel_debugger_loopPKcS0_Pvi + 299
FP: 0xffffffc000fca6e0, PC: 0xffffffc0020d3cc7 <kernel_riscv64> _ZL24kernel_debugger_internalPKcS0_Pvi + 135
FP: 0xffffffc000fca720, PC: 0xffffffc0020d400f <kernel_riscv64> panic + 101
FP: 0xffffffc000fca860, PC: 0xffffffc00215bc9f <kernel_riscv64> STrap + 1075
FP: 0xffffffc000fca960, PC: 0xffffffc00215991d <kernel_riscv64> SVec + 77
FP: 0xffffffc000fcad60, PC: 0xffffffc0020a15ad <kernel_riscv64> handle_signals + 191
FP: 0xffffffc000fcad90, PC: 0xffffffc0020b1c85 <kernel_riscv64> thread_at_kernel_exit + 25
FP: 0xffffffc000fcae90, PC: 0xffffffc00215b94b <kernel_riscv64> STrap + 223
FP: 0xffffffc000fcaf90, PC: 0xffffffc0021599dd <kernel_riscv64> SVecU + 109
FP: 0x3b187bfc40, PC: 0x357e23a6f7 <libroot.so_seg0ro> 0x3c6f7
kdebug> dump_page_table 1792
...
0x3f317df000 - 0x3f317dffff: 0x9af9a000 - 0x9af9afff, 0x1000, {valid, read, write, user, accessed, dirty}
4 Likes
It seems that wrong page table (SATP register) is sometimes selected after fork. Memory is mapped, but on another address space.
Also I fixed debug fault handing.
STrap(exception loadPageFault)
sstatus: (ie: {}, pie: {}, spp: s, sum: 1)
sie: {sTimer, sExtern}
sip: {sTimer}
stval: 0x3fc5599010
tp: 0xffffffc001c9a540(bash)
PANIC: page fault with interrupts disabled
Welcome to Kernel Debugging Land...
Thread 1535 "bash" running on CPU 0
Stack:
FP: 0xffffffc000fb0570
FP: 0xffffffc000fb0590, PC: 0xffffffc00215a7f1 <kernel_riscv64> arch_debug_call_with_fault_handler + 31
FP: 0xffffffc000fb05e0, PC: 0xffffffc0020d2401 <kernel_riscv64> debug_call_with_fault_handler.localalias.7 + 129
FP: 0xffffffc000fb0670, PC: 0xffffffc0020d3a2b <kernel_riscv64> _ZL20kernel_debugger_loopPKcS0_Pvi + 299
FP: 0xffffffc000fb06e0, PC: 0xffffffc0020d3d17 <kernel_riscv64> _ZL24kernel_debugger_internalPKcS0_Pvi + 135
FP: 0xffffffc000fb0720, PC: 0xffffffc0020d405f <kernel_riscv64> panic + 101
FP: 0xffffffc000fb0860, PC: 0xffffffc00215bd1d <kernel_riscv64> STrap + 1233
FP: 0xffffffc000fb0960, PC: 0xffffffc00215996d <kernel_riscv64> SVec + 77
FP: 0xffffffc000fb0d60, PC: 0xffffffc0020a15fd <kernel_riscv64> handle_signals + 191
FP: 0xffffffc000fb0d90, PC: 0xffffffc0020b1cd5 <kernel_riscv64> thread_at_kernel_exit + 25
FP: 0xffffffc000fb0e90, PC: 0xffffffc00215baa5 <kernel_riscv64> STrap + 601
FP: 0xffffffc000fb0f90, PC: 0xffffffc002159a2d <kernel_riscv64> SVecU + 109
FP: 0x3aefddbc40, PC: 0x34297966f7 <libroot.so> _kern_fork + 7
initial commands: dump_virt_page 0x3fc5599010
not mapped
kdebug> dump_virt_page -team 1535 0x3fc5599010
0x3fc5599000 - 0x3fc5599fff: 0x9af77000 - 0x9af77fff, 0x1000, {valid, read, write, user, accessed, dirty}
kdebug>
12 Likes
It seems I fixed issue. Problem was here.
Now it runs for a longer time, but then completely freezes without any errors or response. I have seen similar problems on emulator but it is harder to reproduce.
9 Likes
Not sure if it’s related, but I have to turn off SMP in safe mode or disable CPU’s with Pulse, otherwise the system freezes here too, no responce or any information, gathered some information in a ticket: https://dev.haiku-os.org/ticket/17053
Currently SMP is not used.
1 Like
Not related then 
I have an old laptop, with the Haiku x64. The computer was freezing when I did updates. I could not solve the problem. The problem was solved when I changed the router for the internet. Now the laptop works very well, it did not stick again. 
I can have 4 cores enabled on low usage, when building (some) larger projects with haikuporter it freezes so I reduce the cores to have a stable environment
1 Like
I managed to reproduce freeze on TinyEMU. It seems that freeze is easily to reproduce on TinyEMU thaen in QEMU. And TinyEMU is also faster.
Next this is what to do with this. Adding emulator additional debug output may help.
13 Likes
Haiku Debugger is useful here:
9 Likes