based on my limited testing - adding dprintf() in thread block and unblock:
it’s more like that thread_unblock is not called.
i changed launch_daemon config to simplify things: removed everything except registrar and autologin from system launch config.
this way registrar is able to start
autologin starts, sends a signal to launch_daemon and terminates
system launch_daemon attempts to start user launch_daemon which gets blocked inside runtimer_loader and never unblocked.
@pengphei I can confirm your observation: user threads are getting blocked in WaitForPageEvents
sometimes NotifyPageEvents get called but more often it’s not. so the blocked threads won’t wake up.
PageWriterRun::Go() might be getting blocked at some point
parse elf referring info, start kernel thread(referring to usrland app)
trigger page_fault, lookup alreadyed pages or alloc new pages for libs or images which userland app depends
the kernel thread(referring to userland app) blocked (couldn’t be waked up)until we got the last page(its busy flag couldn’t be refreshed by “page writer” kernel thread ;( ) which is blocked when calling to uint32 failedPages = run.Go();The first time run to this function.
That’s all the stages, we reached the final step (the last page loading) for userland application, then blocked.
Haven’t looked at the ARM port recently. As I remember it looked like a race condition or dealock related to modified page handling. So the issue is not loading, it’s page writing that gets blocked.
there’s no deadlock, no race condition, the lockup is caused by lack of accessed/modified bit handling in MMU. Current paging method reported all pages as dirty which causes trouble. If I modify it to report that no pages are dirty, we are able to progress further in the bootup. Of course we’ll need a proper accessed/modified flag implementation.
alignment issue in BMessage::FindInt64
we need to implement fork, signals, restart syscalls
framebuffer.accelerant expects that boot loader will pass framebuffer configuration to kernel arguments. Boot loader get this info from UEFI GOP interface. But u-boot EFI do not support QEmu ramfb device and don’t provide GOP interface.
In that case, an additional mechanism to find the QEMU framebuffer should be added somewhere, probably, but I don’t think it needs an entirely separate driver in userland for this purpose? The ARM port already has a graphical bootsplash, doesn’t it?
There’s a bootsplash with TianoCore but no bootsplash with u-boot.
Even with TianoCore, the framebuffer driver did not work quite well for me, probably due to the reason pointed out by X512.
So for now I’m using a ramfb driver/accelerant for testing, I’m not sure if it should be upstreamed or just keep it on my dev branch as a test tool. (I’m not sure whether I’m indecisive)
Quick question. Are we considering targeting the Raspberry Pi explicitly? Because it seems to me that if we can get Haiku working well on the RPi, that would be a killer combo and a very interesting development platform. Looking forward to see this progressing further. Amazing job so far.
Ahahahahaha… If you prefer, I can go away. I have not been posting but I am around and have been following things. Last time I showed up, I fixed a lot of ethernet drivers so I guess this might be a positive thing.
I think we want to support Raspberry on both 32 bit and 64 bit. It just takes time. Note that a lot of ARM hardware has come and gone since the ARM port was started so it is very much up in the air…
(For the work in progress 64 bit there were/are? issues with libs so it is currently targeting only newer arch, but that will change)
I have not been posting but I am around and have been following things. Last time I showed up, I fixed a lot of ethernet drivers so I guess this might be a positive thing.