Hello!
> 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 :-/
I have separate directory, for cvs. After each cvs update I do:
rm -rf freemware.work
cp -a freemware freemware.work
cd freemware.work
...
I perform no compilation, nothing in freemware dir.
> 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 ...
I have not only Celeron CPUs, I also tried this on Pentium-133,
it reboots too.
> Otherwise, we might try to narrow the fault down by adding premature
> exits. You said the 'virtcode' guest runs, but 'cooperative' doesn't?
both cooperative and preemptive reboots.
> Well, does 'virtcode' still run if you cause it to trap by e.g. adding
> a 'hlt' statement somewhere?
No. When I do:
--- freemware/guest/virtcode/virtcode.c Sun Nov 14 17:06:47 1999
+++ freemware.work/guest/virtcode/virtcode.c Mon Dec 27 22:15:40 1999
@@ -33,6 +33,7 @@
" movw %ax, %es \n"
" movw %ax, %fs \n"
" movw %ax, %gs \n"
+ " hlt \n"
" call do_nothing \n" /* Run the test code */
"1: jmp 1b \n" /* Should never get here */
);
It reboots.
> 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)?
No, it does "Abort due to exception 13 at 001b:0001000f" (modified guest)
...
> 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).
ironmaiden kernel: freemware: start: c402c8d0 end: c402f790: init: c402c904 pages: 4
ironmaiden kernel: freemware: vm c402c000..c402cfff -> page 00000d04
ironmaiden kernel: freemware: vm c402d000..c402dfff -> page 00000c12
ironmaiden kernel: freemware: vm c402e000..c402efff -> page 00000e78
ironmaiden kernel: freemware: vm c402f000..c402ffff -> page 00000f23
ironmaiden:/usr/src/freemware-cvs/freemware.work/kernel# uname -a
Linux ironmaiden 2.3.34 #5 Tue Dec 21 20:02:47 EET 1999 i686 unknown
[ 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
Sure, I am ;) I am just not going to test it on my main server ;)
> this, I can understand that ;-) It would definitely be desirable to find
> the reason for the crash you're experiencing, though ... ]
Of course I understand that.
Bye,
Oleg
