spoke too soon. Hangs on booting on my t420. Possibly IRQ problem, not sure.
On Mon, Mar 24, 2025 at 10:02 PM ron minnich <rminn...@gmail.com> wrote: > nix is working pretty reliably for me now. > > We're past the will it run stage, now for the clean it up stage. As > always, contributors welcome. I note that Paul dialed down all the nasty > debug prints, so if you use it, you'll find it nicer. > > reminder: TODOs are here: > https://github.com/rminnich/9front/blob/nix/TODO.md > > > > On Mon, Mar 24, 2025 at 2:35 PM ron minnich <rminn...@gmail.com> wrote: > >> I've taken it a bit further, and it's odd. >> >> rfork(RFCORE) works fine. up->errlab is 0 when the rfork(RFCORE) exits. >> But here's the interesting part. >> up->nerrlab is still 1 when we flip the process over to the ac. This is >> because of the call to _procctl in syscall() >> >> Then the process calls pwrite, and, up->nerrlab is 1 BEFORE the first >> waserror() in syscall. >> >> I think before the _procctl() in syscall, there needs to be a poperror(). >> this fixes it for me. >> if (up->procctl == Procto ...) {poperror(); _procctl(up); } >> The reason is, that when procctl is set to Proc_toac, that call to >> procctl never returns, and the poperror never happens. >> >> Why did this ever work, you say? I don't know. >> >> Paul, see what you think. >> >> On Mon, Mar 24, 2025 at 1:56 PM Paul Lalonde <paul.a.lalo...@gmail.com> >> wrote: >> >>> No, it does not block, failing if it can't. >>> >>> This piece is still buggy - the error labeling (waserror(), poperror(), >>> error()) is out of balance, even in the path that doesn't fork. >>> So I'm tracing carefully to understand where the missing poperror() or >>> extra waserror() is. >>> >>> Paul >>> >>> On Mon, Mar 24, 2025 at 1:41 PM Stuart Morrow <morrow.stu...@gmail.com> >>> wrote: >>> >>>> On Mon, 24 Mar 2025 at 15:12, ron minnich <rminn...@gmail.com> wrote: >>>> > Further, he fixed the rfork support, such that processes can set up >>>> and move from a TC to an AC. This restores a long-lost capability. >>>> > >>>> > This is a pretty major step forward. It is now even possible to do >>>> things like this: >>>> > main(){ >>>> > /* set it all up */ >>>> > rfork(RFACORE); /* something like that */ >>>> > >>>> > and your process is now running on a dedicated, non-preempted, >>>> interrupt-free, no kernel code, core all to its own. >>>> >>>> Does that block until the resource is available? 9front added the >>>> ability for rfork to fail. >>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions >>> <https://9fans.topicbox.com/groups/9fans> + participants >>> <https://9fans.topicbox.com/groups/9fans/members> + delivery options >>> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink >>> <https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M578da3e508ed84bd7aa48d11> >>> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M7c012264be6d78e0822cdbb8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
