> angband:/usr/src/freemware-cvs/freemware.work/user# ./user
> Loading guest code: ../guest/preemptive/kernel.elf
> Allocating 0x288c bytes of memory for reading file
> ok, this is an ELF-Binary
> Opening VM
> Allocating 4MB of physical memory in VM
> Mapping virtualized physical memory into user monitor
> Zeroing virtualized physical memory
>
> Looking at angband's monitor - its rebooting.
> This time it is Celeron 450/64M RAM, 2.3.34
> Linux angband 2.3.34 #10 Tue Dec 21 14:25:26 EET 1999 i686 unknown
> Do you need to know smth more?
Just to exclude one possible trivial source of problems: did you recompile
freemware from a clean state (make dist-clean)? Unfortunately, we don't
have correct dependencies in the Makefiles currently, so changes to a
header file might result in incompatible object files lying around :-/
If the problem persists, we'll have to track this down somehow. First
of all, does anybody else have experiences with running freemware under
Linux 2.3.3x and/or on Celeron CPUs? Maybe there's some sort of fundamental
problem ...
Otherwise, we might try to narrow the fault down by adding premature
exits. You said the 'virtcode' guest runs, but 'cooperative' doesn't?
Well, does 'virtcode' still run if you cause it to trap by e.g. adding
a 'hlt' statement somewhere?
If every trap crashes, maybe it's the module page mapping. Does it
still crash if you replace the line
handler_mon = type == IDT_INTERRUPT ? (u32) MON_NEXUS_OFFSET(__guest2host)
: (u32) MON_NEXUS_OFFSET(__handle_fault);
by
handler_mon = (u32) MON_NEXUS_OFFSET(__guest2host);
in 'init_idt_slot' (kernel/monitor.c)?
If not, could you activate the commented-out lines
//printk(KERN_WARNING "freemware: vm %08lx..%08lx -> page %08lx\n",
// virt_addr, virt_addr + PAGE_SIZE-1, pte->base);
in 'retrieve_monitor_pages' (kernel/host-linux.c) and check out the
syslog lines they produce (it suffices to just load the module, you
don't need to trigger the crash to see those lines).
[ Note: You're probably aware that if you do this kind of testing, you'll
probably trigger the crash several times ... If you don't want to risk
this, I can understand that ;-) It would definitely be desirable to find
the reason for the crash you're experiencing, though ... ]
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
