Date: Tue, 10 Feb 2004 00:34:08 +1000 From: Peter Grehan <grehan@freebsd.org> To: Suleiman Souhlal <refugee@segfaulted.com> Cc: freebsd-ppc@freebsd.org Subject: Re: Alu Powerbook Message-ID: <40279A60.4060002@freebsd.org> In-Reply-To: <20040209084040.6718d16e@zZzZ.segfaulted.com> References: <20040206000245.20a84f0c@zZzZ.segfaulted.com> <40232DA3.5090508@freebsd.org> <20040206013218.4eb1cd37@zZzZ.segfaulted.com> <40235C60.9010509@freebsd.org> <20040206115743.2f6ad7af@zZzZ.segfaulted.com> <402450B7.9030106@freebsd.org> <20040208224036.6f1fb172@zZzZ.segfaulted.com> <402731BD.3070703@freebsd.org> <20040209023918.079ec9f5@zZzZ.segfaulted.com> <402740C9.1050506@freebsd.org> <20040209084040.6718d16e@zZzZ.segfaulted.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Suleiman,
> After a long night of compiling the kernel countless times, I have
> found what was wrong. The TDF_NEEDRESCHED flag kept being set to the
> init thread, which, to my understanding, shouldn't happen, as it runs in
> the userland. The (very simple) patch is attached. I can now get to
> multi-user.
That type of debugging takes a huge amount of persistence: thankyou
for your effort !! Now, onto the bug:
The second argument of ithread_schedule determines if the current
thread can be pre-empted. The sparc64 and ia64 ports both leave this
as zero, and ppc followed suit to be conservative.
When the second param is 1, the current thread is immediately switched
over to the interrupt thread, which should run to completion. If
it is 0, the ithread will be run when the user-thread returns to
user-space, with the switch done in subr_trap.c:ast().
There's a couple of possibilities:
- I messed up the AST/RESCHED asm code in the recent trap update.
Probable.
- the cutover to ULE changed some scheduling dynamics. Not that likely
this early in the boot.
- there is an interrupt storm that is never allowing init to return to
user space. Mildly probable, and should show up under tracing.
I'd probably like to determine what the culprit is before committing
your fix, since as the '0' parameter has worked fine and continues to
do so on at least my test machines, I suspect there is another bug being
masked.
later,
Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40279A60.4060002>