it was a boofhead move on my part, it's not a real problem. etymology of boofhead: I don't know, picked it up from ericvh, who picked it up at Murray Hill.
On Tue, Mar 25, 2025 at 12:21 AM ron minnich <rminn...@gmail.com> wrote: > > #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 / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T25c85a39f00802e6-M3db64f77a140ad640e2c54c8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
