Crash in OSX 10.11 with Fusion 8.0.1 vmware-usbarbitr

[wmarchekwa]

Getting a crash a few times a day with vmware-usbarbitr.  Its acting as if something is being plugged in over and over then it crashes.

Anonymous UUID:       0B90FC0A-FD1A-07E4-02B6-0EF09B150424

Sun Oct  4 00:21:49 2015

*** Panic Report ***

panic(cpu 4 caller 0xffffff800b1d6a9a): Kernel trap at 0xffffff7f8bd382db, type 14=page fault, registers:

CR0: 0x0000000080010033, CR2: 0x0000000000000000, CR3: 0x00000003571d50f0, CR4: 0x00000000001626e0

RAX: 0x0000000000000000, RBX: 0xffffff8052bbbc00, RCX: 0xffffff800b80fb68, RDX: 0xffffff80291d1d40

RSP: 0xffffff92213dbcb0, RBP: 0xffffff92213dbcc0, RSI: 0x0000000000000000, RDI: 0xffffff8052bbbc00

R8:  0x000000000000ffff, R9:  0x0000000000000001, R10: 0xffffff80295e8e50, R11: 0x0000000000000001

R12: 0xffffff8052bbbc00, R13: 0xffffff80460bad00, R14: 0x00000000e00002c0, R15: 0xffffff8052bcaf40

RFL: 0x0000000000010246, RIP: 0xffffff7f8bd382db, CS:  0x0000000000000008, SS:  0x0000000000000010

Fault CR2: 0x0000000000000000, Error code: 0x0000000000000000, Fault CPU: 0x4, PL: 0

Backtrace (CPU 4), Frame : Return Address

0xffffff92213db940 : 0xffffff800b0e5357

0xffffff92213db9c0 : 0xffffff800b1d6a9a

0xffffff92213dbba0 : 0xffffff800b1f4093

0xffffff92213dbbc0 : 0xffffff7f8bd382db

0xffffff92213dbcc0 : 0xffffff7f8deabee5

0xffffff92213dbd20 : 0xffffff7f8deac933

0xffffff92213dbda0 : 0xffffff800b6e0057

0xffffff92213dbe00 : 0xffffff800b19c68f

0xffffff92213dbe30 : 0xffffff800b0e9af3

0xffffff92213dbe60 : 0xffffff800b0cd448

0xffffff92213dbea0 : 0xffffff800b0dcfc5

0xffffff92213dbf10 : 0xffffff800b1c135a

0xffffff92213dbfb0 : 0xffffff800b1f48b6

      Kernel Extensions in backtrace:

         com.apple.iokit.IOUSBFamily(900.4.1)[CB8A6BC0-D37B-36C6-BDAF-F61B7EAA85E5]@0xffffff7f8bd13000->0xffffff7f8bd84fff

            dependency: com.apple.iokit.IOPCIFamily(2.9)[668E3DEE-F98E-3456-92D6-F4FEEA355A72]@0xffffff7f8b92d000

            dependency: com.apple.iokit.IOUSBHostFamily(1.0.1)[A9596EBF-A521-317E-957E-791CC4049D4C]@0xffffff7f8bca2000

         com.vmware.kext.vmioplug.15.1.6(15.1.6)[7C0B5925-E6D3-304A-B966-24A699BDFCF3]@0xffffff7f8deaa000->0xffffff7f8deaffff

            dependency: com.apple.iokit.IOUSBFamily(900.4.1)[CB8A6BC0-D37B-36C6-BDAF-F61B7EAA85E5]@0xffffff7f8bd13000

BSD process name corresponding to current thread: vmware-usbarbitr

Mac OS version:

15A284

Kernel version:

Darwin Kernel Version 15.0.0: Wed Aug 26 16:57:32 PDT 2015; root:xnu-3247.1.106~1/RELEASE_X86_64

Kernel UUID: 37BC582F-8BF4-3F65-AFBB-ECF792060C68

Kernel slide:     0x000000000ae00000

Kernel text base: 0xffffff800b000000

__HIB  text base: 0xffffff800af00000

System model name: Macmini6,2 (Mac-F65AE981FFA204ED)

System uptime in nanoseconds: 44947417308635

last loaded kext at 245211150067: com.apple.filesystems.msdosfs 1.10 (addr 0xffffff7f8deb5000, size 69632)

last unloaded kext at 306869206432: com.apple.driver.AppleUSBMergeNub 900.4.1 (addr 0xffffff7f8deb0000, size 12288)

loaded kexts:

[jfarwell]

Hi wmarchekwa,

Thank you for reporting this. If possible, could you supply a bit more information for us to be able to diagnose this crash:

* The full crash report file.

* The log files from /Library/Logs/VMware/

* The /var/log/system.log file.

* A full System Information Report, which can be obtained either by clicking the "System Report…" button from "About This Mac" or by running "/usr/sbin/system_profiler -detailLevel full -xml > ~/Desktop/mymachine.spx" on the command line.

If you like, all of these are contained within the support bundle generated by going to Help -> "Collect Support Information" in VMware Fusion. if you would prefer not to attach these files to the forum post, you could send me a private forum message with a private download link to dropbox or another file sharing solution.

Thanks!

James

[wmarchekwa]

James i could not find a way to send you a private message through the forums.  I did upload the files to my document folder on the vmWare Community.  Thanks for the help.

[wmarchekwa]

James,

It appears that one usb device is causing this behavior.  It is a Velleman oscilloscope PSCU1000.  Whenever it is plugged in, it keeps detecting it over and over, so quickly that i do not have the chance to pick if i want it connected to Windows or Mac.  If i am in Vmware settings/USB i do see the device connecting and disconnecting over and over.  If i click the device in the USB settings i can un-select it.

This device worked previously before the upgrade to 8.0.1.  It is odd that throughout the day the behavior happens with the device left connected. It will detect it over and over until it causes a panic and resets my machine.

I moved the scope to my laptop which has Windows 10 installed as well, and all is fine.  I thought perhaps that i had a bad cable, or perhaps the scope was causing the issue but that does not seem to be the case.

But i found the issue.  It appears that when the device is plugged into my external usb hub (Sabrent USA) this behavior arises. When plugged directly in the mac mini usb, all is well. Perhaps i am at my current limit for the hub?

Let me know if there is anything additional i can send but i am guessing this is resolved.

[jfarwell]

wmarchekwa,

Excellent detective work, that is all very useful, thank you!

So, to confirm: the problem occurs specifically with a Velleman oscilloscope PSCU1000 device, the problem only occurs when the device is plugged into an external (Sabrent USA) hub, and the problem is a regression in Fusion 8.0.1, it did not occur in Fusion 8.0? Do you happen to have any other hubs (even a built-in hub in a keyboard or monitor would suffice) to see if it is caused by using any external hub or is specific to that Sabrent one?

We will investigate this and let you know if we need any additional information. I doubt it is a current problem because I do not believe Apple's kernel would allow our driver to load in the first place if the device exceeded the current limit of the hub (unless the hub is malfunctioning or reporting an incorrect current limit or something). Hopefully we can track down the root cause and solve it in a future patch release of Fusion, but those can take some time so I recommend using your workaround of plugging it directly into the mac mini for now.

Thanks!

James

[jfarwell]

> ... and the problem is a regression in Fusion 8.0.1, it did not occur in Fusion 8.0?

Whoops, I just remembered that Fusion 8.0.1 had almost no changes in it over 8.0 except to fix installing Mac OS X 10.11 inside a VM. So I assume you mean upgrading to 8.0.1 from 7.x.

[jfarwell]

Hi wmarchekwa,

I see the following (over and over and over again) in your system.log file:

   38 Oct  8 11:21:46 Walters-Mini kernel[0]: 076247.663536 TTL2@14112300: AppleUSBDevice::ResetDevice: <software attempt to RESET>

   39 Oct  8 11:21:46 Walters-Mini kernel[0]: 076247.701016 TTL2@14112300: AppleUSBDevice::ResetDevice: <software attempt to RESET>

   40 Oct  8 11:21:46 Walters-Mini kernel[0]: 076247.755832 AppleUSB20Hub@14110000: AppleUSBHub::deviceRequest: resetting due to persistent errors

   41 Oct  8 11:21:47 Walters-Mini kernel[0]: 076248.586582 PCSU1000@14113000: AppleUSBDevice::ResetDevice: <software attempt to RESET>

   42 Oct  8 11:21:47 Walters-Mini kernel[0]: 076248.623784 PCSU1000@14113000: AppleUSBDevice::ResetDevice: <software attempt to RESET>

This looks to me like Apple's hub driver is angry at your hub because of some sort of "persistent errors" -- unfortunately it does not go into more detail than that. It sounds like we might possibly be falling into the "unless the hub is malfunctioning or reporting an incorrect current limit or something" scenario... either that or the device itself is doing something that is making the hub freak out, but that your Mac Mini's root hub is able to handle. VMware Fusion does not do anything directly with external hubs, only with the leaf devices themselves, so it seems that something we are doing to the device is causing the hub to have these errors.

You did not mention in your initial post what the reproduction steps were that trigger this behavior. Do you just have to plug in the device when Fusion is running? Or do you have to try to connect the device to the VM before it happens? If you plug in the device without Fusion running and then don't connect the device to the VM does the problem reproduce? I would also try a different make/model hub, as I suggested before... that should help narrow down if it is the hub behaving badly on its own or the device causing the hub to have errors.