September 23, 2000

This is a snapshot of my development tree of oskit-mach versus that in CVS
(at subversions.gnu.org point your web browser there on how to get the
lastest archive).  A binary generated from it is also included.  It contains
debugging symbols from both the oskit distribution and mach.

Test it and please report the results (ie both bugs and success).  If mach
ever panics, you should not.  Mach will dump the type of fault, the register
contents and a small stack frame to the screen.  Take a pencil and copy down
the program counter, EIP, and the type of fault.  Then hit enter to reboot.
When the system comes back up, run:

# gdb /boot/oskit-mach
...
(gdb) info line *0xEIP

Of course, replace EIP with the EIP that you copied down.  If you copied
the value down correctly, this will tell us where the panic occurred.
Copy this, the output of `uname -a' with that kernel (if possible) and send
it to bug-hurd@gnu.org and cc me (address at end of this file).

INSTALLATION:

Copy oskit-mach into /boot beside gnumach.gz.  Do not overwrite gnumach.gz,
you will need it if you find your system unbootable.  When booting using
grub, point your kernel to /boot/oskit-mach instead.  oskit-mach takes
a superset of the options that gnumach accepts.

CAVEATS:

The SCSI support for the aix7xxx adapters is broken in oskit (tested against
both 20000202 and 20000901).  Other cards may work, however, this snapshot
turns SCSI off completely.

The global page bit still does not work;  This has been commented out
(Tested on a Xeon and a PIII).

The terminal emulation brings new meaning to the definition of dumb.  Basically,
it is good for _basic_ bash and capturing panics; do not even think about
vi or emacs, heck even the output of less is difficult to grok.  Thus,
there are four options:

1) Telnet in
2) Serial console
3) Patch it
4) Fix it properly

If you choose option three, feel free to port over the terminal emulation
from gnumach or someplace else.  If option four sounds appealing, ask on the
mailing list about how to expose the console to the hurd so that you can
write a server.

At the moment, this does not run when linked against oskit-20000901.  It
crashes when initializing the drive info in file oskit/linux/dev/init.c:

        if (osenv_mem_map_phys(0, PAGE_SIZE, &kaddr, 0))
                panic("%s:%d: unable to map phys memory", __FILE__, __LINE__);
        x = *((unsigned *)(kaddr + 0x104));

As kaddr is not mapped into the kernel virtual address space (kaddr == 0).
This could be a bug in oskit or in mach (I suspect that a change in oskit
caused it, however, it could be that mach uses some oskit functions
incorrectly which are now fixed).  If you find it, thank you very much.

Finally, as the system boots, you will see a lot of `(device driver) io:
0xXXX'.  This is oskit being verbose as it probes for different cards.  If
it crashes, write down the port, boot back into linux and try to reverse map
it using /proc/*.  Finally, report it back to the list.

Have fun.
-Neal
neal@cs.uml.edu or neal@walfield.org