This is a "wild guess"-style question: If you boot without any USB devices connected, does the problem go away?
On Sun, Jun 30, 2013 at 5:12 AM, Mihai Carabas <[email protected]> wrote: > Hello, > > This week I build the initialization procedure for VMX. What I've been > following: > - detect if there is any support for VMX > - detect if the VMX isn't disabled by the BIOS > - detect and save in predefined variables the VMX capabilities of the CPU > - extract the VMX region size used by the vmxon operation > - extract the VMX version > - fix CR4 and CR0 registers on each CPU > - enable VMX operations by setting the CR4.VMXE on each CPU > > Using the data presented above I have built the vmx region for each CPU > (these have to exists on a per-cpu basis) and execute "vmxon" operation on > each CPU. After some struggling with errors like "general-fault protection" > (verified wrong MSRs or written the wrong bits in CRx), I managed to > successfully execute a vmxon operation. The system is running now in > VMX-root operation mode. > > I also exposed some data through sysctl, and more will be added: > root@dfly_x86-64:~# sysctl -a|grep vmm > hw.vmm.vmx.revision: 16 > hw.vmm.vmx.region_size: 1024 > hw.vmm.vmx.width_addr: 0 > hw.vmm.type: VMX from Intel > hw.vmm.enable: 1 > > The subtree coresponding is the "vmm" one which is populated dynamically, > depending on what virtualization extension we have (for now only VMX). As > you can see the region_size is 1024(1K), the width_addr means that the > addresses used must have the processor length in bits (not important in this > case) and the vmm_type is completed statically with the name of the > extension. > > There is an editable sysctl, hw.vmm.enable, which can turn on/off the VMM > (in the case of VMX, it executes vmxon/vmxoff). > > I also had some troubles with the sysctl, as I was trying to clean-up a node > from a sysctl PROC, which ended up with a self-deadlock. I modified the > design to not have to delete anything. > > As for the HP blade, it reboots now if I manually unload the ehci.ko module. > Can anyone suggest what might be the problem? Also swildner managed to bring > up an OCE driver for my 10gbit network card. sephe recommended some tests > but due to the fact that I had some troubles accessing the cluster with the > HP blade, I didn't get to do them. I promiss that tomorrow night I will run > the tests and then swildner can commit to upstream the drivers. > > Thanks, > Mihai
