On Thu, May 31, 2001 at 04:24:35PM -0400, Roland McGrath wrote:
> Please try this patch, which I have just checked in.
You forgot to move "#include " to the top of the file.
Jeroen Dekkers
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.or
Thanks for finding that. It looks like the last time I was hacking on
oskit-mach SMP, I left it so that the only thing that would boot was a
kernel compiled for SMP and booted on a uniprocessor! Heh.
Please try this patch, which I have just checked in.
Index: mp_desc.c
===
On Tue, May 29, 2001 at 05:02:29PM -0400, Roland McGrath wrote:
> This probably the first time interrupts have been enabled since early in
> the boot process. There will immediately be a clock interrupt, since one
> surely fired a little bit earlier and was blocked until the "sti" insn.
> There m
> After rebooting a lot of times (I should really get a serial cable to do
> remote debugging) I found out that the sti instruction near the of the
> function is causing the troubles. At the moment I've no idea what's wrong, I
> have to read a lot of documentation and code before knowing what's
On Sat, May 26, 2001 at 07:59:50PM -0400, Roland McGrath wrote:
> > I've just pulled the oskit-mach source from CVS build it and tried to
> > boot it. Unfortunately, it didn't work.
>
> Well, I'm very glad that you are trying and are interested in debugging it.
>
I'm interested in developing i
> I've just pulled the oskit-mach source from CVS build it and tried to
> boot it. Unfortunately, it didn't work.
Well, I'm very glad that you are trying and are interested in debugging it.
> I've managed to track down the problem to spl0() (defined in
> i386/i386/spl.S). Here's how it happens:
I've just pulled the oskit-mach source from CVS build it and tried to
boot it. Unfortunately, it didn't work. That wasn't totally unexpected
given my rotten luck with trying new kernels.
Once the boot process gets to a certain point the computer just
restarts. That means it's some sort of unhandl