913 replies to this topic

[Rampage Dev]

Kext Helper B7 !!!!!

Best app ever... at least for us old guys who have been around for a long time.

[Zenith432]

I'm getting nothing, finally got around to trying this, but not on 10.8.2. Rather the 10.8.3 that just got released

I need time to check if GenericUSBXHCI is still binary-compatible with IOUSBFamily in 10.8.3.

Edit: Haven't tried to run it yet, but from examination of the header files, should be ok under 10.8.3.
Edit: Verified that GenericUSBXHCI works under 10.8.3. [I also found that I had to remove AppleHDA, because it now blocks VoodooHDA.]

, I dumped Caps/Running to a file if that helps but it's not recognizing anything and NOTHING in Console.app. It shows up in system profiler but no devices when plugged in...

The only thing unusual I see in the dump is that the Asmedia 0x1042 does not support 64-bit physical addressing. I haven't really tested that condition. So what I'll do is simulate it with the xhci chip I have, and see if it screwes things up.

Edited by Zenith432, 15 March 2013 - 02:39 PM.

[Philz]

The only thing unusual I see in the dump is that the Asmedia 0x1042 does not support 64-bit physical addressing. I haven't really tested that condition. So what I'll do is simulate it with the xhci chip I have, and see if it screwes things up.

Thats interesting, am I the first Asmedia user? Let me know if you want me to test anything on the actual system if you don't want to simulate anything. Thanks for looking into it

[lollo78]

Hi, thank you!
It works for me, but no wake up after sleep (Black screen)

[Zenith432]

I uploaded v1.1a4 (in post #1) with a fix for the ASM1042 (problem mentioned in post #20.)
Also enhanced debug information printed by xhcdump.
The crash during sleep (post #24) still being worked on. [Fixed for 1.1]

[bebop68]

I'm using a macbook 8,3 2011 (sandy bridge, 17" with expresscard) and 10.8.3. Expresscards with asmedia 1042, nec 720202 and fresco logic 1000, and 1009 all work, mount usb 2 and usb 3 drives but none of them resume after sleep. I get the disconnected drive error message and then the drives remount. I suspect its something to do with how the macbook initialises theexpresscards - modified PXHCD and oyen's MXHCD kexts do resume after sleep, I find pxhcd prone to disconnects, and while they both mount drives under 'superspeed' in system information, they list the max speed as 480mbps instead of 5gbps like your driver or apple's kext when patched. I don't know if sleep will ever work for me anyway, but thanks for all your work, I do run hackintoshes too.

[Zenith432]

modified PXHCD and oyen's MXHCD kexts do resume after sleep

Well, if they do it means it can be done... I'll try to figure out what PXHCD is doing to accomplish that. I assume by "modified" you're referring to modbin's patch?

Edit: Hmm... PXHCD uses some code from AppleUSBEHCI for ExpressCardPort... stay tuned.
Edit: It's doing something specific to an express card, but that's not the reason it's able to resume. What PXHCD does on wake it to reset the controller, and internally reenumerate all devices. Functionally, it's the same result as having IOUSBFamily reenumerate all devices, except you don't see the ejection messages, because IOUSBFamily doesn't know about the 'silent' reenumeration. It also has a side-effect of readdressing all devices. Since device addresses may change, they have to be mapped so IOUSBFamily continues to see the old addresses.
PXHCD doesn't try xhci suspend/resume at all.
I've considered this option before as a recovery from a failed suspend/resume. It's a lot of work to implement, and all just to hide those ejection messages (since otherwise as I said - functionally the same result.) So it's not gonna happen in GenericUSBXHCI.

I find pxhcd prone to disconnects, and while they both mount drives under 'superspeed' in system information, they list the max speed as 480mbps instead of 5gbps like your driver or apple's kext when patched.

Just to clear that part up...

• Software has no control on whether a USB3 device connects as a high-speed or super-speed. It's the chip that decides that based on the electronic detection circuits and once decided, whatever channel is chosen is the one used for chip<->device communication.
• PXHCD and MXHCD present the device as a high-speed device to IOUSBFamily, because that's all it supported prior to OS 10.7.something.
• The question of whether a device can reach its peak performance has to do with whether it's programmed with the highest allowed packetization parameters. Superspeed drives allow much bigger burst transfers than high-speed.
• The packetization parameters are ostensibly read from the device itself via its descriptors, and passed down from IOUSBFamily.
• Superspeed devices have slightly different format (and limits) for packetization parameters.
• So it's unclear what happens to the packetization parameters when a superspeed device is presented as a highspeed device to IOUSBFamily. It may be that it ends up programmed with sub-optimal parameters. It may be that PXHCD or MXHCD somehow tweak the whole process so that the device ends up with the best parameters anyway.

Edited by Zenith432, 18 March 2013 - 10:23 PM.

[bebop68]

Thanks for the analysis. - I'm really only concerned with the error message if it means it's possible to lose date - i.e. if the caches don't get written before sleep.

PXHCD was the modbin patched version, but I removed the device id from the inf so it loaded for a variety of cards in the specified class. I modified the MXHCD inf the same way, but the binary didn't need patching as it's not locked to any specific device.

Speed wise I find them on a par with the patched apple kext and with your generic kext, in banchmarks mxhcd is the fastest by a not-noticeable margin, but also more reliable than pxhcd. If it's simply re-enumerating after sleep I might switch to apple/generic

Is there any way to hack mxhcd to present the device as superspeed to iousbfamily?

NDS USB 3.0 Driver if you want to compare it to pxhcd

[Zenith432]

I'm really only concerned with the error message if it means it's possible to lose date - i.e. if the caches don't get written before sleep.

I don't know, looks like this is a common problem. Do a search for "eject drives before sleep mac" and you'll find some scripts that automate external drive ejection b4 sleep.

I may implement the 'silent reenumeration' that PXHCD does later on. It's a lower-priority item than isoch endpoints though. I've thought about it, and if it's the same drive, then doing a silent reenumation may prevent data-corruption - since the upper layer driver doesn't know the disk disconnected, and doesn't throw away the caches.
Drawback is - it's never really safe to do anything but a fully-broadcast reenumeration if xhci chip loses power. Why? because when sleeping without power, chip stops detecting connection changes on the ports. For instance, I have two USB thumbsticks that are the same model. The only difference is the content of the data blocks. Say system is put to sleep with one drive connected, and xhci chip loses power. I unplug the disk and put in the other one. Then I wake the system. PXHCD does silent reenumeration. The upper-layer driver believes it's the same disk and uses previous caches... data corruption on 2nd disk.

When putting a xhci chip to aux-powered sleep with xhci suspend, it continues to detect connection changes on the ports. When you unplug a device, it wakes up the system into darkwake (screen remains off), and the connection change is handled just like a fully-wake connection change. So you know for sure whether a device was replaced or not during sleep. With ports powered off - you can't know that... PXHCD just assumes it's the same device...

Is there any way to hack mxhcd to present the device as superspeed to iousbfamily?

Not by bin-patching, it's a ton of code that needs to be added. But if you get peak-performance with it, it makes no difference. It's just one driver cheating another driver to get things working right.

I'll check the Oyen kext when I have time.

Edit: mXHCD is the strangest of them... It does xhci suspend-resume, but at the end of the resume, without checking if the resume failed, it proceeds to reset the chip (!). I didn't follow it much after that, but looks like it's reinitializing everything. If you're not getting disk ejection notices after a reset, it must be doing an internal reenumeration like PXHCD. Are you sure the drives work after sleep?

[bebop68]

Thanks - a couple of things I noticed about mxhcd when I did an ioreg -xrc - it shows all cards as 'built in' when other drivers do not. If you can find out how it's doing that it might be useful. Also generic or apple or both (can't remember) list the superspeed port as simulated, and mxhcd doesn't. Don't know whether that means anything.

Considering the amount of work involved in the pxhcd method I would pick data integrity (or at least being told that the disks got ejected,) over silent reenumeration. Not knowing what's happening is worse.

The drives definitely work after sleep with mxhcd. If it performs xhci suspend-resume presumably that means it flushes the caches before sleeping? Could you block it from resetting the chip after it's suspend-resume? - I'd be interested to see if that works and for which chipsets it works. Then we'd have an example of a driver that makes things built-in and does xhci suspend-resume successfully.

[Zenith432]

I uploaded release 1.1.
It contains some fixes for problem mentioned in #24 - KPed sometimes during suspend/resume code due to interrupt timing.
If this is stable for a while, I'll delete the older builds 1.1a3, 1.1a4.

Thanks - a couple of things I noticed about mxhcd when I did an ioreg -xrc - it shows all cards as 'built in' when other drivers do not.

That's no big mystery. They all (GenericUSBXHCI too) enable PME and mark the card as "built-in". It's just AppleUSBXHCI that's got issues with this, because it checks some Apple device-properties before doing so. There's no need for that. It's always right to enable PME on PCI endpoints that support it (well, not quite, some chips report they support it and then assert PME when they shouldn't). That should also be enough to get aux power during sleep - but unfortunately, it's not. [Correction: GenericUSBXHCI only marks it "built-in" if it supports PME. I think PXHCD always marks it as built-in].

Also generic or apple or both (can't remember) list the superspeed port as simulated, and mxhcd doesn't. Don't know whether that means anything.

It doesn't. There are 2 root hubs - superspeed and highspeed, and they're call "simulated" because they're not external USB hubs which are "real" hubs. It's just a name the kext itself chooses.

Considering the amount of work involved in the pxhcd method I would pick data integrity over silent reenumeration, or at least being told that the disks got ejected. Not knowing what's happening is worse.

I think PXHCD's method does add integrity as long as you don't swap the drive during sleep. It reenumerates the drive silently - the disk-cache handler doesn't know about the power loss - and continues to use the cache as if nothing happened.

If it performs xhci suspend-resume presumably that means it flushes the caches before sleeping?

No, no it's got nothing to do with flushing the caches. The caches are managed by a completely different part of the system (higher-layered drivers), and it's up to them to decide if to flush the caches.

Could you block it from resetting the chip after it's suspend-resume?

Why? That's the only reason it succeeds in continuing to function after resume. Your expresscards lose power, and AppleUSBXHCI gets hosed precisely because it doesn't reset the chip.
suspend/resume only works if the cards don't lose power.

[bebop68]

All makes sense..

Why - to see if it does lose power during sleep with all drivers. The 720202 at least should resume after sleep and does on pcs with generic/apple-patched, and doesn't on my macbook. Is that the expresscard, or the way the mac talks to expresscards, or the drivers?

Sleepy.

[qwerty12]

…and as I'm typing this, I discover "xhcdump options" and find that the "-gux_nosleep" kernel flag lets me sleep and still enjoy USB 2.0 goodness with my USB 3.0 ports. A workaround, I know, but still a brilliant improvement over the CalDigit drivers, nevertheless.

---

Thank you very much for the ASM1042 support. I was previously using CalDigit's drivers, which worked fine with USB 3.0 devices but wouldn't handle USB 2.0 devices being plugged into the USB 3.0 ports correctly. This is on an ASUS N55SL laptop running 10.8.3 with XHCI handoff enabled in the BIOS and firmware 12220E running on the ASM1042. While I doubt it has any relevance, on this laptop, ASUS have something they call "USB Charger", which lets the laptop supply power to one of its USB 3.0 ports when the laptop is off.

However, I'm having trouble putting my laptop to sleep. With no devices connected, my laptop will sleep and then wake up right away. With the CalDigit drivers, this was solved with a DSDT edit posted here: http://www.osx86.net...working_...html
The same DSDT edit has no effect with GenericUSBXHCI.kext version 1.1. With the DSDT lines removed the same behaviour occurs.

Here is a part of a log from around the time I tried to sleep (at the login screen, with no devices attached). Even with "gux_log=2" set, I don't get any differing output.

hibernate image path: /var/vm/sleepimage
hibernate_alloc_pages act 68005, inact 5446, anon 342, throt 0, spec 126162, wire 265599, wireinit 73045
hibernate_setup(0) took 0 ms
sizeof(IOHibernateImageHeader) == 512
kern_open_file_for_direct_io(0) took 264 ms
Opened file /var/vm/sleepimage, size 8589934592, partition base 0x0, maxio 400000 ssd 0
hibernate image major 1, minor 0, blocksize 512, pollers 5
(Re-)enabled Turbo Boost: 4000850089 -> 850089
SaveControllerStateForSleep: xHC Save Error
         0 [Time 1363832035] [Message hibernate_page_list_setall(preflight 0) start 0xffffff80d12b8000, 0xffffff80d12f8000
hibernate_page_list_setall time: 302 ms
pages 435895, wire 236247, act 42947, inact 1, cleaned 0 spec 17, zf 297, throt 0, could discard act 22875 inact 5205 purgeable 1496 spec 126810 cleaned 0
hibernate_page_list_setall found pageCount 279509
IOHibernatePollerOpen, ml_get_interrupts_enabled 0
IOHibernatePollerOpen(0)
encryptStart 13290
bitmap_size 0x3f4c0, previewSize 0x57fbe8, writing 277953 pages @ 0x5d2338
encryptEnd 73a8a00
image1Size 0xb4a5c00, encryptStart1 0x13290, End1 0x73a8a00
encryptStart b4a5c00
encryptEnd ee0fe00
PMStats: Hibernate write took 4052 ms
all time: 4052 ms, comp bytes: 1138495488 time: 608 ms 1783 Mb/s, crypt bytes: 181401968 time: 333 ms 519 Mb/s, 
image 249626112 (2%), uncompressed 1138495488 (277953), compressed 241989824 (21%), sum1 441f7f05, sum2 fde1a6ea
wired_pages_encrypted 172324, wired_pages_clear 62367, dirty_pages_encrypted 43262
hibernate_write_image done(0)
sleep
Disabled Turbo Boost: 850089 -> 4000850089
Wake reason = XHCI
No interval found for . Using 8000000
RTC: PowerByCalendarDate setting ignored
Previous Sleep Cause: 5
RestoreControllerStateFromSleep: xHC Restore Error

Here are some xhcdump results obtained when the laptop had no devices connected to any of its USB ports:

Minitrue:GenericUSBXHCI_1.1 $./xhcdump caps
Found a device of class GenericUSBXHCI: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP04@1C,3/IOPCI2PCIBridge/XHCI@0/GenericUSBXHCI
Vendor 0x1b21, Device 0x1042, Revision 0
CapLength  32
HCIVersion 0x96
MaxSlots 32, MaxIntrs 8, Rsvd(1) 0, MaxPorts 4
IST 1 microframes, ERST Max 32768, Rsvd(2) 0x17, SPR N, Max Scratchpad Bufs 0
U1 Device Exit Latency 0, Rsvd(3) 0, U2 Device Exit Latency 0
AC64 N, BNC N, CSZ N, PPC N, PIND N, LHRC N, LTC N, NSS Y, Rsvd(4) 0x1, MaxPSASize 65536
  xHC Extended Cap ID 1, Specific 0
    Legacy CTLSTS 0x10000
  xHC Extended Cap ID 2, Specific 0x300
    Supported Protocol Name 0x20425355 PortOffset 1 PortCount 2 ProtocolDefined 0
  xHC Extended Cap ID 2, Specific 0x200
    Supported Protocol Name 0x20425355 PortOffset 3 PortCount 2 ProtocolDefined 0x1
DBOff  0x1800
RTSOff 0x1000
PageSize 4096
Using MSI

Minitrue:GenericUSBXHCI_1.1 $./xhcdump running
Found a device of class GenericUSBXHCI: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP04@1C,3/IOPCI2PCIBridge/XHCI@0/GenericUSBXHCI
USBCmd RS Y HCRST N INTE Y HSEE N LHCRST N CSS N CRS N EWE Y EU3S N
USBSts HCH N HSE N EINT Y PCD N SSS N RSS N SRE N CNR N HCE N
DNCtrl 0xffff
CRCr CRR Y
Config 32
MFIndex 234
Last Time Sync xHC 272384 milliseconds <-> CPU 328512475030 nanoseconds
# Configured Endpoints 0
# Interrupts: Total 137, Serviced 137, Inactive 0, Offline 0
# Save Errors 1
# Restore Errors 1
Port   1 PortSC CCS N PED N OCA N PR N
           PLS RxDetect PP Y Speed Unknown PIC Off LWS N
           CSC N PEC N WRC N OCC N PRC N PLC N CEC N CAS N
           WCE Y WDE Y WOE Y DR N WPR N
         PortPmsc U1 0 U2 0 FLA N PortLi LEC 0
Port   2 PortSC CCS N PED N OCA N PR N
           PLS RxDetect PP Y Speed Unknown PIC Off LWS N
           CSC N PEC N WRC N OCC N PRC N PLC N CEC N CAS N
           WCE Y WDE Y WOE Y DR N WPR N
         PortPmsc U1 0 U2 0 FLA N PortLi LEC 0
Port   3 PortSC CCS N PED N OCA N PR N
           PLS RxDetect PP Y Speed Unknown PIC Off LWS N
           CSC N PEC N WRC N OCC N PRC N PLC N CEC N CAS N
           WCE Y WDE Y WOE Y DR N WPR N
         PortPmsc L1S Invalid RWE N HIRD 50 us L1Slot 0 HLE N TestMode Disabled
Port   4 PortSC CCS N PED N OCA N PR N
           PLS RxDetect PP Y Speed Unknown PIC Off LWS N
           CSC N PEC N WRC N OCC N PRC N PLC N CEC N CAS N
           WCE Y WDE Y WOE Y DR N WPR N
         PortPmsc L1S Invalid RWE N HIRD 50 us L1Slot 0 HLE N TestMode Disabled
Interrupter 0 iman IP N imod I 40000 ns C 0 ns erstsz 1 erdp DESI 0 EHB N

Minitrue:GenericUSBXHCI_1.1 $./xhcdump bandwidth
Found a device of class GenericUSBXHCI: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP04@1C,3/IOPCI2PCIBridge/XHCI@0/GenericUSBXHCI
Bandwidth for RootHub, Speed 0
  0  0  90  90
Bandwidth for RootHub, Speed 1
  0  0  90  90
Bandwidth for RootHub, Speed 2
  0  0  80  80
Bandwidth for RootHub, Speed 3
  90  90  0  0

[jamiethemorris]

This kext works perfectly, except that when I log out and back in I get a full system freeze, as well as intermittently on startup. Caldigit drivers do the same thing. I'm using the Etron EJ168 built in to my motherboard.

[Zenith432]

qwerty12: The save errors in the log indicate ASM1042 cannot sleep, and you should use '-gux_nosleep' in your Boot.plist permanently. That is not just a workaround, but the best way to handle a chip that can't sleep. Let me know if it wakes-up instantly when you boot with "-gux_nosleep", because that would need a fix.
Edit: I sent you a build with an attempt to fix the instant wakeup without a kernel flag. Let me know how it works out.

jamiethemorris: Why do you think those freezes have anything to do with the xhci drivers? Have tried it without any xhci drivers?

[cRuNcHiE]

Thankyou very much! My s3-391 (Ivy bridge version) now has functioning USB 3.0 ports!

Tested with usb2 and usb3 devices and they seem to work. It seems to crash when i unplugged a device once, but hasnt done it again yet.


If i try and sleep now i just get a black screen though and cant wake up.

Also, if i bootup with my sdcard reader plugged . Once it gets to the desktop, a message appears saying 'Disk unreadable'
If i unplug, re-plug its ok. Could be a power issue? I notice the reader felt very hot which is not normal.

Will keep testing!

EDIT: it appears if i add the boot flag ' -gux_defer_usb2 ' it solves all my problems!

What is the correct way to add this to chameleon boot?

[Zenith432]

If i try and sleep now i just get a black screen though and cant wake up.

Also, if i bootup with my sdcard reader plugged . Once it gets to the desktop, a message appears saying 'Disk unreadable'
If i unplug, re-plug its ok. Could be a power issue? I notice the reader felt very hot which is not normal.

EDIT: it appears if i add the boot flag ' -gux_defer_usb2 ' it solves all my problems!

What is the correct way to add this to chameleon boot?

For Intel Series 7, when the xhci driver initializes, it yanks control of the USB 2.0 ports away from the ehci driver (assuming the ehci driver initialized earlier). This may cause problems for some devices. I'm not sure what to do about this. For the time being, if this gives you trouble, go ahead and leave the ports with the ehci driver by "-gux_defer_usb2".
You can add permanent kernel flags in /Extra/org.chameleon.Boot.plist in the "Kernel Flags" entry.
Edit: Try looking in your bios settings if it's possible to route the ports to xhci from boot-time, that may also solve the problem (instead of "-gux_defer_usb2").

I uploaded v1.1.4 (see post #1). Anyone that's being having trouble with not-coming-back-from-sleep, or spontaneous-reboot-on-shutdown, I suggest you try it, as I made code for those things more robust.

Edited by Zenith432, 23 March 2013 - 09:02 PM.

[cRuNcHiE]

For Intel Series 7, when the xhci driver initializes, it yanks control of the USB 2.0 ports away from the ehci driver (assuming the ehci driver initialized earlier). This may cause problems for some devices. I'm not sure what to do about this. For the time being, if this gives you trouble, go ahead and leave the ports with the ehci driver by "-gux_defer_usb2".
You can add permanent kernel flags in /Extra/org.chameleon.Boot.plist in the "Kernel Flags" entry.
Edit: Try looking in your bios settings if it's possible to route the ports to xhci from boot-time, that may also solve the problem (instead of "-gux_defer_usb2").

I uploaded v1.1.3 (see post #1). Anyone that's being having trouble with not-coming-back-from-sleep, or spontaneous-reboot-on-shutdown, I suggest you try it, as I made code for those things more robust.

Thank you for the reply. The only option I can see in the bios similar to that is 'load xhci at preboot' which is already enabled.

With -gux_defer_usb2 , my webcam works again and is listed under usb2 in system profile. Similarly, if I plug in a usb3 device it will correctly be listed under usb3 . I haven't performed a speed test yet but to me it suggests its working?

Sleep works, usb storage doesn't give any error after wake up and everything seems to plug in and work now!

[RehabMan]

I've been working on an open source USB 3.0 driver for OS X for a while, and decided it's stable enough to be published.

...

Binaries contain

• build for OS 10.8.
• build for OS 10.7.
• xhcdump utility..

Zenith432,

First of all nice work on this driver...

I've been looking at building a single binary for 10.7 and 10.8 and I thought I'd ask you some questions.

I noticed the #ifdefs checking for 10.7 build target... one example:

#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1072
if (getProperty("IOPCITunnelled", gIOServicePlane) == kOSBooleanTrue) {
_v3ExpansionData->_onThunderbolt = true;
requireMaxBusStall(25000U);
}
#endif

Looks like the code is protecting against writing to parts of _v3ExpansionData that don't exist on earlier versions of Lion (10.7.1 and prior). My intention was to do these checks at runtime instead and this prompted me to review all access to _v3ExpansionData and to do some research on how it has changed over OS X versions.

Compiled by looking at each version of IOUSBControllerV3.h at opensource.apple.com:

// 10.8.2 IOUSBControllerV3::V3ExpansionData
struct V3ExpansionData {
uint32_t _rootHubPollingRate32;
bool _rootHubTransactionWasAborted;
IOPMDriverAssertionID _externalUSBDeviceAssertionID;
SInt32 _externalDeviceCount;
UInt32 _inCheckPowerModeSleeping;
bool _onThunderbolt;
// added 10.7.2
uint32_t _thunderboltModelID;
uint32_t _thunderboltVendorID;
// added 10.7.5 (#ifdef SUPPORTS_SS_USB)
UInt8 _rootHubNumPortsSS;
UInt8 _rootHubNumPortsHS;
UInt8 _rootHubPortsHSStartRange;
UInt8 _rootHubPortsSSStartRange;
IOUSBRootHubInterruptTransaction _outstandingSSRHTrans[4];
// added 10.8.2
bool _wakingFromStandby; // t when waking from S4 stanby
};

The code in GenericUSBXHCI uses the following fields:
_onThunderbolt
_rootHubNumPortsSS
_rootHubPortsSSStartRange
_rootHubNumPortsHS
_rootHubPortsHSStartRange
_externalDeviceCount

The _rootHub* fields are used without protection, even though they are only present in 10.7.5+.
The _onThunderbolt is accessed with protection in a couple of places (like the #if noted above), but others it is accessed without protection, even though only present on 10.7.2+.
The _externalDeviceCount is there in all versions (even 10.6.8).

What is the intention here? Thanks in advance...

P.S. This is my first look into Apple's kext backward/forward compatibility and frankly I'm a bit shocked at the fragility of the whole thing.

[cfmwan]

thank you!

USB 3.0 SuperSpeed Bus:

Host Controller Location: Built-in USB
Host Controller Driver: GenericUSBXHCI
PCI Device ID: 0x1042
PCI Revision ID: 0x0000
PCI Vendor ID: 0x1b21
Bus Number: 0xbc

USB to ATA/ATAPI Bridge:

Product ID: 0x0539
Vendor ID: 0x152d (JMicron Technology Corp.)
Version: 0.0f
Serial Number: WD-WMAZA7774525
Speed: Up to 5 Gb/sec
Manufacturer: JMicron
Location ID: 0xbc900000 / 1
Current Available (mA): 900
Current Required (mA): 2
Capacity: 2 TB (2,000,398,841,856 bytes)
Removable Media: Yes
Detachable Drive: Yes
BSD Name: disk6
Partition Map Type: MBR (Master Boot Record)
S.M.A.R.T. status: Not Supported
Volumes:
UNTITLED:
Capacity: 2 TB (2,000,396,746,752 bytes)
Available: 1.78 TB (1,775,855,992,832 bytes)
Writable: Yes
File System: ExFAT
BSD Name: disk6s1
Mount Point: /Volumes/UNTITLED
Content: Windows_NTFS
Volume UUID: E2745740-BE7E-3ABE-83DA-207986834C3A