- Joined
- Dec 22, 2015
- Messages
- 39
- Motherboard
- gigabyte z170x gaming 3
- CPU
- i5-6600k
- Graphics
- hd530
You need it to enable all ports. It is in config_patches.plist available in the USBInjectAll repo.
Ah OK! I seen now, they were already included in my clover's config.plist, because I base that off somebody else's (who has slightly different motherboard).
Injecting only the ports you need allows you to stay within the 15-port limit.
Right sorry. But that was actually my 'why?' question: What is the effect of ignoring the 15 port limit? That we cannot remove the config plist patches? --> Therefore its not possible long term, without issues related to those patches?
I don't know why you have that impression.
[EDITED]
So if I try "XOSI fix" then? Will it give all of the USB ports? Or also still I keep the USBInjectAll.kext, and 15 ports limit, and still keep my custom .aml file in ACPI/PATCHED/ folder?
Since I have a Skylake PC, presumably its newer than what Window 7 knew. So if my XOSI.dsl file is to use the windows10 instead of windows 7. But I am confused because in your windows7 BRIX example, and in your github repo, multiple versions of windows are uncommented, not just win7, (but also including Vista and XP). I understand i must always leave uncommented:
"Windows", // generic Windows query
So then do i also un-comment all prior versions of windows before mine?
Does this look ok to you?
Code:
// This SSDT can be used instead of an "OS Check Fix" patch to
// simulate a version of Windows for Darwin
//
// The default code below simulates Windows 2009 (Windows 7)
//
// To use this SSDT, you must compile it as AML, place in ACPI/patched, add
// to config.plist/ACPI/SortedOrder, and use the "change _OSI to XOSI"
// patch in config.plist/ACPI/DSDT/Patches (see config_patches.plist)
//
DefinitionBlock ("", "SSDT", 2, "hack", "XOSI", 0)
{
// All _OSI calls in DSDT are routed to XOSI...
// XOSI simulates "Windows 2012" (which is Windows 8)
// Note: According to ACPI spec, _OSI("Windows") must also return true
// Also, it should return true for all previous versions of Windows.
Method(XOSI, 1)
{
// simulation targets
// source: (google 'Microsoft Windows _OSI')
// http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
Store(Package()
{
"Windows", // generic Windows query
"Windows 2001", // Windows XP
"Windows 2001 SP2", // Windows XP SP2
//"Windows 2001.1", // Windows Server 2003
//"Windows 2001.1 SP1", // Windows Server 2003 SP1
"Windows 2006", // Windows Vista
"Windows 2006 SP1", // Windows Vista SP1
//"Windows 2006.1", // Windows Server 2008
"Windows 2009", // Windows 7/Windows Server 2008 R2
"Windows 2012", // Windows 8/Windows Server 2012
"Windows 2013", // Windows 8.1/Windows Server 2012 R2
"Windows 2015", // Windows 10/Windows Server TP
}, Local0)
Return (Ones != Match(Local0, MEQ, Arg0, MTR, 0, 0))
}
}
You can use that to exclude ports. But usually you need to also set UsbConnector correctly, which cannot be done with a kernel flag. Hence the suggestion to create a custom SSDT.
Ah OK! Now I understand the point of it. Thank you.
You would have to provide "Problem Reporting" files that show the test device plugged in and the specifics on the device, and the specific way you're testing speed... And also, keep in mind that actual speeds may vary depending on the specific device you have plugged in. Just because you use a USB3 device, does not mean that device can perform at the top of USB3 bandwidth. In any case, you should verify your device can perform at your expected speeds by testing in Windows.
Yes I understand somewhat. I already know from windows10 and linux that this USB 3.0 device can do 70MB/Sec speeds. The reason I think its wider issue is because 3-4 other people said that they have same issue in sierra, in PikerAlpha's blog.
As for providing the "Problem Reporting" files... I did that earlier today. You may want again? They way I test speed is as follows:
* Insert SATA HDD into USB caddy,
* Attach device to USB 3.0 port
* Check it shows up in IORegExplorer attached to an 'SS' port.
* run 'diskutil list' to see which disk it is
* run 'dd if=/dev/disk3 of=/dev/null bs=1m count=100m'
Always takes about 7.-- seconds, which is about 14MB/Sec average speed. I havent removed the config plist patches yet though...
Last edited: