#l0 gets "no phy" error #l1 gets dma error / timeout good solid hang after that. I miss ^T^Tp or whatever that sequence was ... anyway ... hopefully someone else can try on different hardware.
I think it is hung in network startup somehow. On Mon, Mar 24, 2025 at 10:31 PM ron minnich <rminn...@gmail.com> wrote: > 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-M112075ad17ac7162b7f03e17 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
