Jmicron Technologies Driver For Mac
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. Modified PXHCD and oyen's MXHCD kexts do resume after sleepWell, 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? PXHCD uses some code from AppleUSBEHCI for ExpressCardPort. 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 chipdevice 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 March 18, 2013 by Zenith432. 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? If you want to compare it to pxhcd. 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. 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. 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? 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. 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. And as I'm typing this, I discover 'xhcdump options' and find that the '-guxnosleep' 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: 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 'guxlog=2' set, I don't get any differing output.
Qwerty12: The save errors in the log indicate ASM1042 cannot sleep, and you should use '-guxnosleep' 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 '-guxnosleep', 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? 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 ' -guxdeferusb2 ' it solves all my problems! What is the correct way to add this to chameleon boot? 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 ' -guxdeferusb2 ' 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 '-guxdeferusb2'. 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 '-guxdeferusb2').
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 March 23, 2013 by Zenith432. 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 '-guxdeferusb2'. 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 '-guxdeferusb2'). 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 -guxdeferusb2, 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!
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. 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. 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.There's no grand design there, just historical order of development. When I first ran into the thunderbolt code, I'd never done anything with thunderbolt before, so I went back and checked exactly which version it began. For the rootHub.
fields, I looked in 10.7.5 and saw it's #ifdefed. I didn't know whether the distributed kexts were built with the symbols defined or not, so I stopped there and didn't look earlier. In retrospect, 10.7.5 kexts were built with the symbols defined, so GenericUSBXHCI can be used with it. OS 10.7.4 and earlier had no support for superspeed devices.
So you won't be able to simply make them work. They can only be supported by simulation like PXHCD/mXHCD/Caldigit do, and it's a complicated simulation to develop.
I explained in an earlier post why (slightly different descriptors from USB 2.0 to USB 3.0) If you make enough of the code conditional, you can probably get it to manage USB 2.0 devices on xhci with OS 10.7.4 and earlier. Note that in OS 10.6.8 some of the fields in IOUSBController, IOUSBControllerV2 were different, so it gets even more complicated. If you want to check stuff into the repository, let me know. Edited March 23, 2013 by Zenith432.
There's no grand design there, just historical order of development. When I first ran into the thunderbolt code, I'd never done anything with thunderbolt before, so I went back and checked exactly which version it began. For the rootHub. fields, I looked in 10.7.5 and saw it's #ifdefed.
I didn't know whether the distributed kexts were built with the symbols defined or not, so I stopped there and didn't look earlier. In retrospect, 10.7.5 kexts were built with the symbols defined, so GenericUSBXHCI can be used with it.
OS 10.7.4 and earlier had no support for superspeed devices. So you won't be able to simply make them work. They can only be supported by simulation like PXHCD/mXHCD/Caldigit do, and it's a complicated simulation to develop. I explained in an earlier post why (slightly different descriptors from USB 2.0 to USB 3.0) If you make enough of the code conditional, you can probably get it to manage USB 2.0 devices on xhci with OS 10.7.4 and earlier. Note that in OS 10.6.8 some of the fields in IOUSBController, IOUSBControllerV2 were different, so it gets even more complicated.
If you want to check stuff into the repository, let me know. My intention is not to make it work on 10.7.4 or prior, but I do want it to gracefully exit if installed. What I've done with my repo is: - removed the #if ENVIRONMENTMACOSXVERSIONMINREQUIRED = 1072 checks from V1Overrides.cpp and V1Pure.cpp (because we are always on 10.7.5 or greater) - set the OS X target to 10.7 (SDK is still 10.8) - added this to GenericUSBXHCI.h: #define MakeKernelVersion(maj,min,rev) (maj #define GetKernelVersion MakeKernelVersion(versionmajor,versionminor,versionrevision). I've also optimized the build settings a bit to reduce the kext to 116 KB (binary is 114 KB). BTW, it looks like your Lion build might have debug symbols in it or something (256 KB).
Mostly hiding symbols, turning LinkTime Optimize on, dead code elimination on, etc. With these options the only symbol exported is kmodinfo.
You could get rid of all the attribute((visibility('hidden'))) using my build settings (I didn't bother as I didn't want to introduce huge diffs). My fork is at: Let me know if something I've done doesn't make sense. My intention is not to make it work on 10.7.4 or prior, but I do want it to gracefully exit if installed.Info.plist asks for IOUSBFamily version 5.0.0a1 or later. So in fact it will gracefully not load at all on 10.7.4 or prior A build compiled for min-version 10.7.5 with dual-arch should work on 10.8+, and a build compiled for min-version 10.8 (dual-arch) can functionally work on 10.7.5, but I'm not sure will load - ld may stick some load commands not supported in 10.7.5. This needs to be checked if important. A build compiled for min-version 10.7.5 with dual-arch should work on 10.8+, and a build compiled for min-version 10.8 (dual-arch) can functionally work on 10.7.5, but I'm not sure will load - ld may stick some load commands not supported in 10.7.5. This needs to be checked if important.
I just realized that your kext does support 32-bit, which I don't really plan to use. Makes sense that your 10.7 build was dual-arch; mine won't be. I think I was getting confused between your usb3 and Meize's realtek driver, which won't build 32-bit. (working on both right now). I will update my README.md/project to reflect. And yes, I don't know if there is any material difference between building w/ target set to 10.7 vs. In theory, Apple should have their headers appropriately #ifdef, such that if say target '10.7' you can't accidentally use something that is not in 10.7.
Jmicron Technologies Driver For Mac Pro
In practice, we know they are not that diligent with their SDK (I think they don't bother at all). Kexts don't have the 'Minimum system version' that apps do. Instead they have, as you say, the OSBundleLibraries dictionary. Whether ld sets something in the actual binary to indicate OS X target, I don't really know (but I think not). Warning: This driver is made for none-Intel chipset USB3.0 controllers.
This AppleUSBXHCI.kext is based on Zenith432's patch. Original Topic Please install this driver to /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns. Alternatively, you can use Clover's KextsToPatch with the following Binary patch.
Binary patch description (Hex & Assembly Codes): Chipset Compatible List: (Working/Semi-working) Please feel free give some feedbacks, if your chipset is not on this list, or if you think there is something wrong about the list. NEC/Renesas: D720200 D720200a D720201 D720202 D720210 Etron: EJ168 EJ168a EJ188 EF198 Fresco Logic: FL1000 FL1009 FL1100 VIA: VL800 VL801 VL805 VL806 Texas Instruments: TUSB7320 TUSB7340 ASMedia: ASM1042 If this driver doesn't work for you, restore the original AppleUSBXHCI.kext and check out Zenith432's GenericUSBXHCI.kext. Since when I updated to 10.13.6 (and possibly.5 since i don't use usbs that often) my usb 3.0 drives don't work on usb 3.0 ports or hubs and work only if inserted slowly and get recognized as usb 2.0s in that case (480mb/s in sysinfo) and if i try to put my hackintosh to sleep the screen turns black for a second and then it takes me to the login screen instead of going to sleep, this usb issue happened to me on 10.13.2/3 too, is there a way to fix it? Thank you CLOVER not working usb 3.0s+ sleep.zip. Looks like after the 10.12.6 update something reset in my USB subsystem and now I am no longer able to reliably use almost half of my USB ports.
This is across both USB 2.0 and 3.x ports. It looks like the ports re-organized themselves and I am hitting limits again though I am not sure why (granted I have 4 USB hubs attached to my computer in addition to the internal ones).
I guess I havent been keeping up on grooming my edits and patches since.3 so it was bound to happen. i really hope the USB subsystem is better in 10.13 Any assistance would be appreciated. I have attached my ACPI dumps as patched by Clover, the original unpatched dumps, my current config.plist, my patched ssdt.aml, and an IOREG USB dump. Asrock Z170 Ext 6+ 6700K @ 4.4.zip. GenericUSBXHCI USB 3.0 driver for OS X with source.
Jmicron Technology Driver
Licensee agrees not to make any copies of the Software or the Documentation, in whole or in part, other than one copy for archival purposes only. Licensee agrees not to modify, translate, reverse engineer, de-compile, disassemble, or create derivative works based on the Software, except to the extent that such limitation is prohibited by applicable law. Licensee agrees to take reasonable steps to safeguard copies of the Software and Documentation against disclosure, copying or use by unauthorized persons, and to take reasonable steps to ensure that the provisions of this license are not violated by Licensee's employees or agents.
THE SOFTWARE AND DOCUMENTATON ARE PROVIDED “AS IS.” HGST EXPRESSLY DISCLAIMS AND NEGATES ALL WARRANTIES FOR THE SOFTWARE AND DOCUMENTATON, WHETHER EXPRESSED, IMPLIED, STATUTORY OR OTHERWISE, AND HGSTSPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OF INTELLECTUAL PROPERTY OR OTHER VIOLATION OF RIGHTS. HGST does not warrant that the Software will meet Licensee’s requirements or that the operation of the Software will be uninterrupted or error free. This statement gives Licensee specific legal rights. Licensee may also have other rights, which vary from state to state or country to country. LIMITATION OF LIABILITY. IN NO EVENT WILL HGST OR ITS SUPPLIERS BE LIABLE FOR ANY LOST REVENUE, PROFIT, OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE EVEN IF HGSTOR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
In no event shall HGST or its suppliers' liability to Licensee, whether in contract, tort (including negligence), or otherwise, exceed the license fees paid by Licensee. Some states or countries do not allow exclusion or limitation of incidental or consequential damages or limitation on how long an implied warranty lasts, so the above limitations or exclusions may not apply to Licensee. This agreement shall continue in effect until terminated hereunder. This agreement shall terminate automatically on Licensee's failure to comply with any of the provisions herein, including any attempt to transfer this license or the Software or Documentation.
Upon any termination, Licensee shall promptly destroy or return to HGST all copies of the Software and Documentation, including all original and archival copies. No refunds shall be given for such returned materials. Notwithstanding any termination of this License, the rights and obligations relating to title, warranty, termination and limitation of liability, as well as any other provisions which survive by their terms, shall survive termination:. RESTRICTED RIGHTS. The Software and Documentation are provided with Restricted Rights. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c) (1) and (2) of the Commercial Computer Software—Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is HGST, Inc.
3403 Yerba Buena Rd, San Jose, California 95135. MISCELLANEOUS. Licensee may not assign or transfer any of its rights or delegate any of its obligations under this agreement.
No delay, failure or waiver by either party to exercise any right or remedy under this agreement shall operate to waive any exercise of such right or remedy or any other right or remedy. Licensee shall comply with all export laws and regulation of the United States to assure that the Software is not exported, directly or indirectly, in violation of U.S. This agreement shall be governed by and construed in accordance with the laws of the State of California without regard to conflict of laws principles and without regard to the 1980 U.N. Convention on Contracts for the International Sale of Goods.
If any provision in this agreement shall be found or be held to be invalid or unenforceable, then the meaning of said provision shall be construed, to the extent feasible, so as to render the provision enforceable, and the remainder of this agreement shall remain in full force and effect. This agreement constitutes the entire agreement between Licensee and HGST with respect to the subject matter of this agreement.
PROPRIETARY NOTICES. Licensee shall maintain and reproduce all copyright and other proprietary notices on all copies of the Software in the same form and manner that such notices are included on the Software. G-Technology is a registered trademark of HGST, Inc.
And its affiliates in the United States and/or other countries. All HGST/G-Technology product names are trademarks and/or service marks of HGST, Inc. And its affiliates in the United States and/or other countries.
Product Firmware Mac Windows G-Drive G-Drive Mini G-Drive Mobile G-RAID v5 G-Speed eS PRO Enclosure Firmware Update (V4.10.3.0) G-Speed eS PRO Mini-SAS Controller Firmware Update (V4.10.3.0). G-RAID Mini - RAID Configurator Using the G-Technology configurator, you can change the RAID settings to either RAID 0 (Stripe) or RAID 1 (Mirror). The RAID 0 setting will allow for an increased performance across both drives and display the maximum capacity available.
Jmicron Drivers Hp
The RAID 1 configuration allows you to write the same information to both drives providing a better level of protection in the event one drive fails, however RAID 1 will reduce the capacity of the drive to 50% of the advertised capacity. G-RAID mini with USB 2.0 uses two different types of chipsets Oxford and JMicron.
Should you have a serial number with a 'JM' at the end, please download the JMicron chipset utility. If your G-RAID mini does NOT have a 'JM' at the end of the serial number, please download the Oxford chipset utility.
G-RAID mini with USB 3.0 uses the JMicron chipset, please download the JMicron chipset utility. G-SPEED Q - RAID Configurator Using the G-Technology configurator, you can change the RAID settings to either RAID 0 (Stripe) or RAID 5 (Redundant Stripe). The RAID 0 setting will allow for an increased performance across both drives and display the maximum capacity available. The RAID 5 configuration allows you to write partial data across all drives. For example in a G-SPEED Q with 1TB (x4) drives, the end capacity would be 3TB of storage. The 'missing' 1TB of space in this example is used to hold partial amounts of data in the event any 1 drive in the RAID fails.
Mac OS X 10.6 and above. Windows 2000, Windows XP & Windows Vista Important: Download the zip package below.
Run the executable zip file contained to automatically copy the G-SPEED eS installation files to 'C: G-SPEED eS Windows' Use this folder to find the files necessary during the installation procedure as outlined in the Installation Guide. There are 3 steps to installing the G-SPEED eS on a Windows system. Failure to follow these steps as outlined in the Installation Guide may cause your G-SPEED eS to function improperly. Please see the READ ME FIRST file located in the Windows Installation Package download for more information.