VMWare Player .. nice

I used to use VMWare server - quite a few years ago. I really liked it.
But I got fed up with the server product lagging kernel development.
New Linux kernels would come out and either I, or someone else, would
have to figure out the compile-time changes for the drivers.

VMWare created the Player product - which could be used for running VMs
but not creating them. I have up with VMWare workstation.

That was a few years ago.

Today, I installed VMWare Player 4.0 - and it works as expected. Its nice
to come to it after a few years of non-use. It seems highly reliable and
works.

So, I transferred my Ubuntu 11.10 i386 VM from VirtualBox to VMWare Player.
A bit of googling showed me how to convert the disk image.

The VM came up fine. I had a few issues with the network card. My
kernel didnt have the driver - I had disabled as much as possible when
creating a custom kernel, so spent a little while trying to find the
PCNET32 driver. That resolved, I could remote login.

So - now time to try dtrace: pretty much the same results as VirtualBox.
Some small difference - occasionally when VB would hit the double fault
issue, the screen would frantically scroll for 5-10s until the VM gave
up and hung (hard). Doing the same on Player - it will scroll continously.
There appears to be an emulation difference, which, by the looks of
it, is that VB isnt playing as well in the face of double faults.

All this would be boring. But googling for 'vmware debugger' led me to
a page which shows how to enable local gdb debugging of the VM guest.
Using TCP rather than the silly serial port emulation of classic kgdb
setups in the kernel.

So, I tried it. The first thing to note is: it just worked. gdb got
a breakpoint in the native_safe_halt function in the kernel. Whats
interesting is that when a breakpoint is hit, you get a big "Pause" bitmap
slap in the middle of the video console. If you hit ^C in the gdb to regain
control, or we hit a panic, the pause bitmap becomes visible and you know
you have stopped the VM.

The gdb debugger seems more resilient to debugging the doublefault.

Heres a fragment of the stack trace from gdb:

.....
#253 0xc1004adb in show_registers (regs=0xc1732a6c)
    at arch/x86/kernel/dumpstack_32.c:106
#254 0xc1460113 in __die (str=0xc15865f6 "general protection fault",
    regs=0xc1732a6c, err=0) at arch/x86/kernel/dumpstack.c:275
#255 0xc10058c2 in die (str=0xc15865f6 "general protection fault",
    regs=0xc1732a6c, err=0) at arch/x86/kernel/dumpstack.c:308
#256 0xc145f836 in do_general_protection (regs=0xc1732a6c, error_code=0)
    at arch/x86/kernel/traps.c:402
#257 
#258 0xc1048c04 in vprintk (
    fmt=0xc158f150 "<0>PANIC: double fault, gdt at %08lx [%d bytes]\n",
    args=0xc1732b38 "") at kernel/printk.c:827
#259 0xc1456956 in printk (
    fmt=0xc158f150 "<0>PANIC: double fault, gdt at %08lx [%d bytes]\n")
    at kernel/printk.c:750
#260 0xc1021bee in doublefault_fn () at arch/x86/kernel/doublefault_32.c:26
#261 0x00000000 in ?? ()

So - its good that I am seeing the same thing with VMware, and I have
a new "debug" route to try and diagnose.

Just need to figure out who is at fault. It has to be "me". I hope its not
the Virtual emulation (VB or Player). I hope its not a CPU bug. I hope
its not the Linux kernel.



Post created by CRiSP v10.0.22a-b6154