HPReg's Accepted Solutions

It is ultimately a bug in iTunes that Apple should fix (so please click "Send to Apple" in that window), but it is important for use to discover what triggers it. I suspect one important change we made to the guest graphics driver (inside the VMware Tools for OS X) between Fusion 6 and Fusion 7. To test this theory, please try the following experiments in your Mavericks VM: o Experiment 1 In Terminal.app, run the following command:   sudo nvram boot-args='vmw_gfx_caps=0' then restart the Mavericks guest. Does that make the problem go away? If not, move to experiment 2 o Experiment 2 In Terminal.app, run the following command:    sudo rm -rf {/System,}/Library/Extensions/VMwareGfx.kext then restart the Mavericks guest. Does that make the problem go away?

If you are familiar with writing C code to do user<->kernel communication via IOServiceGetMatchingService/IOServiceOpen/IOConnectCallStructMethod, send me your email address at hpreg@YouKnowTheCompany.com, and I will email you the trivial piece of C code we use in the guest to request that the VMware SVGA driver does steps #a through #c.

We have reported the issue to Apple and they acknowledged that it is a bug in Mavericks, that they will fix in subsequent developer seed builds. In theory, you should be able to reproduce the issue without VMware Fusion, by running Mavericks on a physical machine and trying to double-click with a USB tablet. What is going on in the input stack is there is a field on all mouse events called click count.  Some apps will perform double click actions when the click count is 2 and a button is pressed.  Whereas other apps will look for two clicks within a small amount of time.  The issue with this bug is that the click count field is not getting incremented inside of the Mavericks kernel's HID driver for absolute interface devices. The "mouse" VMware Fusion exposes to Mac OS guests is more like a "tablet", in the sense that it uses absolute, not relative, coordinates.

Setting up a OS X netboot server is fairly easy. ... Thanks for the pointer. 4) see attachment Looks like the kernel is unable to find the nic based on this output. I agree. The key thing in the successful output are these lines: AppleIntel8254XEthernet: Ethernet address 00:0c:29:4a:58:71 Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/P2P0@11/IOPCI2PCIBridge/S3F0@2/AppleIntel8254XEthernet/IOEthernetInterface BSD root: en0 netboot: using network interface 'en0' It shows that in the successful case (Fusion 3), the AppleIntel8254XEthernet driver (which drives the virtual e1000 NIC) loads, whereas in the failing case (Fusion 3.0.1) it does not. Based on this valuable information, I strongly suspect the issue is with #1, i.e. our virtual EFI change. Let's check this theory: o Install a fresh Fusion 3.0.1 o Download the EFI ROMs from Fusion 3 which I have made available to you at: http://ftpsite.vmware.com/download/bgarner/EFI32.ROM http://ftpsite.vmware.com/download/bgarner/EFI64.ROM o Modify your VM to use the downloaded EFI ROMs (from Fusion 3) instead of the default ones (from Fusion 3.0.1), by adding these lines to your .vmx file: efi32.filename = "" o Power on the VM If I'm correct, then this time NetBoot will work. So what did we change in our virtual EFI? In the new EFI, we improved boot time by allowing the Apple bootloader (boot.efi) to load the single .mkext file (kernel + all kexts in one file) whereas in the old EFI the Apple bootloader was loading all these component as individual files. So I suspect the following: on the small filesystem that you initially boot in your VM, the folder /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntel8254XEthernet.kext (which is being picked up by the bootloader running on top of the old EFI) exists, but for some reason it is not part of the file /System/Library/Extensions.mkext (which is being picked up by the bootloader running on top of the new EFI). You can check the contents of an .mkext file with the mkextunpack utility. Interestingly, on my physical MacPro2,1 here, the kextstat shows that the AppleIntel8254XEthernet.kext driver is loaded, but for some reason it is not part of /System/Library/Extensions.mkext either. Forcing a rebuild of that file by touching /System/Library/Extensions does not help. I suspect this is because in the AppleIntel8254XEthernet.kext, the Info.plist has its key OSBundleRequired set to Network-Root instead of Root, and to rebuild the .mkext cache, the system calls kextcache with the -l option (local disk boot) only. So I see 2 possible ways to solve this issue, please let me know if they work for you (don't forget to re-install Fusion 3.0.1 and remove the 2 lines from your .vmx file before you test them!): 1) Change /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntel8254XEthernet.kext/Contents/Info.plist so it says Root instead of Network-Root. Check that the system has re-built /System/Library/Extensions.mkext and reboot the VM. This will only work until a system update resets the content of the Info.plist file (maybe that never happens in your case). 2) Re-build /System/Library/Extensions.mkext yourself, but pass the -n option (network boot) on top of the -l option to kextcache, then reboot the VM. This will only work until the system re-builds /System/Library/Extensions.mkext (maybe that never happens in your case). To conclude: If, as I believe, you are responsible for generating the .mkext file in this kind of setup, then I believe that on a real Mac, you would need the -n option as well for this setup to work. So far (Fusion 2 and Fusion 3), our virtualization ignored this .mkext file to boot Mac OS, so you have been lucky it worked without the -n option. But as Fusion 3.0.1 improved and now honors the .mkext file, you need the -n option. I hope it helps, -- hpreg

Chris, We apply the keyboard mapping you want, but only in Unity mode. For Single Window and Full Screen mode, we currently don't do it. We might change that in the future if enough people want it. We certainly have registered your vote for that matter

Eric is right about the reason, but I don't think the .vmx line offers will help. I bet that when you run your VM, you see this appear in its vmware.log file: "Not putting a virtual RAM file on an external drive (at "<.vmem path inside the VM directory>") to workaround Apple radar bugs 5182703 and 5182760. Set mainMem.bug146468.disableWorkaround=TRUE to override." If you want to override this behavior, then set this in your .vmx file: mainMem.bug146468.disableWorkaround=TRUE Note: Apple radar bugs 5182703 and 5182760 have been solved in Leopard.

Danny Joe and elantric, The reason you are hitting this issue is because you are running a very recent version of Mac OS (10.4.10 with Darwin version 8.10.3). As far as we know, you can only get that version of Mac OS when you have purchased your MaBook Pro very recently (for example, there is no way to update to that version with Software Update). That is why we didn't detect this problem in-house. We are working on a fix for the final Fusion 1.1 release. In the meantime, you acen either downgrade Fusion (as explained by Ben), or upgrade to Leopard. Sorry for the inconvenience.

Ideally, we would like to add a delay between the moment your mouse hits the top of the screen and the moment the menu bar drops down. That is what we do in VMware Player for Linux/Windows. Why cannot we do that? Right now the auto-hide feature is just one Carbon call (we haven't found a way to do it in Cocoa). So you get the exact same behavior (including very small delay that is obviously not large enough for you) as with iPhoto, iDVD, and QuickTime. If we want to use a larger delay, we need to re-implement a lot of this ourselves, and right now doing so is low on our priority list.

It is hard to tell what is a VMware bug and what is a jpeg artifact in your screenshots Consider using non-lossy image formats (png is a good option) when reporting this kind of issues. Anyway, it clearly seems there is an issue in the Linux screenshot. It is weird. I don't think we have seen this before. I wonder if that is related to your secondary Cinema display, because we have done no testing with that device. Would you mind trying with the Cinema display disconnected (and maybe a Mac OS reboot for good measure)?