Installing DB2 fails in late 2013 MacBook Pro

R

RobertJD

Bit poster
his is going to be a strange one, but please be assured this is no joke!



I have two MacBook Pro's. They both have Mavericks 10.9, Parallels Desktop 9, and 16G of RAM. The first MacBook Pro is Early 2011, the second is Late 2013. I also have a single Parallels image that is Windows 7 64bit allocated with 2 cores and 3G of RAM. 3D acceleration is ‘Disabled’.



When I install DB2 ESE 10.1 on the Early 2011, all is good.


However, when I try the same install on the same Parallels 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.




What in the world could prevent DB2 from installing in this Parallels image on the Late 2013 MacBook Pro?


Personally, I believe that it has to do with how Parallels interacts with the new Haswell chips, but that is just speculation.



Thanks!

Robert
 
Hi,

I know this is an old thread, but I'm having the same issue. I found a solution posted on the Fusion forums and I wonder if there might be a similar configuration for Parallels. I'm planning on reinstalling without the DAS and setting it up after the install. If all else fails maybe I can copy the VM to my older Mac and try it there.

From the Fusion forums:

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.

Thanks,

Loren
 
You must log in or register to reply here.
Back
Top