Hi all,
This is going to be a strange one, but please be assured this is no Holloween joke!
I have two MacBook Pro's. They both have Mavericks 10.9, Fusion 6.0.1, and 16G of RAM. The first MacBook Pro is Early 2011, the second is Late 2013. I also have a single VMware image that is Windows 7 64bit allocated with 2 cores and 3G of RAM. Accelerated 3D graphics is 'Off'.
When I install DB2 ESE 10.1 on the Early 2011, all is good.
However, when I try the same install on the same VMware image (copied over, of course) on the Late 2013 MacBook Pro, the installer 'hangs' when installing DB2 Administration Server (DAS). Just hangs. Nothing in the logs.
I've 'upgraded' to Hardware version 10.
What in the world could prevent DB2 from installing in this VMware image on the Late 2013 MacBook Pro?
Thanks!
Robert
If you would be up for another experiment, let's try disabling a number of new-ish CPU features to see if perhaps we have a bug in our implementation of one (or more) of them. Using the same procedure, power off the VM and add the following configuration options:
featMask.vm.cpuid.SMEP = "Val:0"
featMask.vm.cpuid.PCID = "Val:0"
featMask.vm.cpuid.FSGSBASE = "Val:0"
featMask.vm.cpuid.MOVBE = "Val:0"
featMask.vm.cpuid.POPCNT = "Val:0"
featMask.vm.cpuid.RDRAND = "Val:0"
featMask.vm.cpuid.F16C = "Val:0"
featMask.vm.cpuid.AVX = "Val:0"
Whether it is successful or not, please upload the resulting vmware.log file, so that I can see what features we are advertising to the guest.
Hi SteveMM,
Could I ask you to double-check that the problem occurs with DB2 Express (or even DB2 Express-C)? We're having difficulty reproducing the problem here, and we have information to suggest that DB2 Express and DB2 Express-C should be unaffected by this problem... which conflicts with the information that you have given... It'd be super helpful if you could double-check for us.
Thanks,
--
Darius
The log file doesn't show the new set of feature masks. You might have to quit Fusion before editing the configuration file.
Odd. The log shows none of the feature masks as being in the .vmx file, not even the original one (which did show up in the log before).
Thanks, gosieg. Is there any chance you could download the standalone DB2 Express installer from the IBM site and see if it fails with that too? I want to eliminate the possibility that it is something else associated with Business Process Manager's installation which might be ultimately triggering the failure.
Cheers,
--
Darius
The problem appears to be that the DB2 installer can't handle more than 4 responses to the CPUID query for deterministic cache parameters. It just so happens that the mobile Haswell CPUs with integrated GPUs reply with 5 or 6 responses to the CPUID query for deterministic cache parameters.
The same thing would happen if the DB2 installer were run natively on these parts (e.g. in Boot Camp). Note that this would not be an issue on desktop Haswell CPUs without integrated GPUs, since they only return 4 responses to the CPUID query for deterministic cache parameters.
Fortunately, with Fusion, you can configure your VM to lie about its deterministic cache parameters. The following configuration options should do the trick:
monitor_control.enable_fullcpuid = TRUE
cpuid.4.4.eax = "0000:0000:0000:0000:0000:0000:0000:0000"
As always, the VM must be completely powered down (not suspended), and you should quit Fusion before making these changes. It is always wise to make a back up first. See http://kb.vmware.com/kb/1014782 for details on editing your configuration file.
VMware cannot support this configuration, since we do not cover it in our testing, but this may be a reasonable workaround while you wait for a fix from IBM.
This fix, including:
monitor_control.enable_fullcpuid = TRUE
cpuid.4.4.eax = "0000:0000:0000:0000:0000:0000:0000:0000"
within the configuration file, fixed the problem for me (preventing an existing VMWare image with DB2 from starting on Mac Fusion (which worked fine on a VMWare Workstation on Windows).
Thanks for your help!!
This fix, including:
monitor_control.enable_fullcpuid = TRUE
cpuid.4.4.eax = "0000:0000:0000:0000:0000:0000:0000:0000"
within the configuration file, fixed the problem for me (preventing an existing VMWare image with DB2 from starting on Mac Fusion (which worked fine on a VMWare Workstation on Windows).
Thanks for your help!!
DavidAsh wrote:
This fix, including:
monitor_control.enable_fullcpuid = TRUE
cpuid.4.4.eax = "0000:0000:0000:0000:0000:0000:0000:0000"
within the configuration file, fixed the problem for me (preventing an existing VMWare image with DB2 from starting on Mac Fusion (which worked fine on a VMWare Workstation on Windows).
Thanks for your help!!
Are you running Workstation on Windows on a mobile Haswell CPU? If so, would you mind uploading the vmware.log file from.that VM.
DavidAsh wrote:
No, I'm running VMWare Workstation on an older ThinkPad W510.
Regards,
Great! I should point out that perhaps the only CPUs affected by this issue are the Iris Pro 5200 models. Wikipedia suggests that these are the only models with an L4 cache. Therefore, these may be the only models that have so much to say about their deterministic cache parameters.
That fix worked for me too! Thank you so much!
monitor_control.enable_fullcpuid = TRUE
cpuid.4.4.eax = "0000:0000:0000:0000:0000:0000:0000:0000"
I'm running VMWare Fusion 6.0.2 on OS X 10.9.1 on a brand new Macbook. I'll attach my vmware log file if anyone is interested. Thanks again!
Awesome! I can confirm that the fix works on my vmware images!! Thanks to everyone for your help on this!!!
Here's my setup:
- Macbook Pro 15" Retina, Late 2013 (Haswell)
- Intel Iris Pro integrated graphics + NVIDIA Geforce graphics
- VMware fusion 6.0.2
- In guest image: DB2 10.1.1 on Windows server 2008 R2 (64-bit)