USB 3.0 G|DRIVE Problem

[RehabMan]

Looks like not so easy - I used your "7-series/8-series USB" with no problems, but with "7-series USB3 Multiplex" when trying to compile I get 145 Errors.

I'm sending View attachment 93260 and View attachment 93259 if u have some time, can take a look.

It may not be an option. I would have to see native DSDT prior to patch...

I tried boot up system with "7-series/8-series USB" patch only, it looks like with GenericUSBXHCI.kext it works normally as before, but without GenericUSBXHCI.kext any device connected to USB port freezes system for 4s-PwrBtn shutdown.

This is last message I get upon boot up when USB device present in port:

SuperIODevice: [Fatal] found unsupported chip! ITE sequence ID=0xffff, Winbond sequence ID=0xffff

That message is just LPCSensors.kext saying it doesn't support your LPC chip (normal on most laptops). You can remove LPCSensors.kext if you don't want to see it.

 

[igielskv]

It may not be an option. I would have to see native DSDT prior to patch...

Just in case U would have some time, here I'm sending View attachment DSDTs.zip. There's DSDT prior 7-series USB3 Multiplex and also prior 7-series/8-series USB (my previous which I was normally using). There's also clean untouched DSDT as extracted from system without any patch applied.

Thanks in advance for an advice and have good evening...

 

[RehabMan]

Just in case U would have some time, here I'm sending View attachment 93265. There's DSDT prior 7-series USB3 Multiplex and also prior 7-series/8-series USB (my previous which I was normally using). There's also clean untouched DSDT as extracted from system without any patch applied.

Thanks in advance for an advice and have good evening...

Try removing the existing XHC1 device before applying the patch (fix the one error that results after). Then apply Multiplex patch. You'll have another error to fix.. call to XWAK(Arg0) should be changed to _INI().

 

[igielskv]

Sorry, but it doesn't help. Patching process worked well exactly as U described... but no change. Still can not see this G-Drive connected when system is running (only if disk is connected prior to power on). And still cannot go without GenericUSBXHCI.kext (other ways my system freeze right on boot or whenever USB device is connected).

So should I keep my DSDT patched with these 2 USB patches? Even if still have to rely on GenericUSBXHCI.kext? Or should revert to previous one without these patches applied?

Thanks a lot anyway RehabMan, have good day...

 

[RehabMan]

Sorry, but it doesn't help. Patching process worked well exactly as U described... but no change. Still can not see this G-Drive connected when system is running (only if disk is connected prior to power on). And still cannot go without GenericUSBXHCI.kext (other ways my system freeze right on boot or whenever USB device is connected).

So should I keep my DSDT patched with these 2 USB patches? Even if still have to rely on GenericUSBXHCI.kext? Or should revert to previous one without these patches applied?

Thanks a lot anyway RehabMan, have good day...

The multiplex patches are only for AppleUSBXHCI.kext. You should not use multiplex patch with GenericUSBXHCI.kext. You might try GenericUSBXHCI.kext with only the XHC1 device removed from DSDT.

 

[igielskv]

The multiplex patches are only for AppleUSBXHCI.kext. You should not use multiplex patch with GenericUSBXHCI.kext. You might try GenericUSBXHCI.kext with only the XHC1 device removed from DSDT.

Ok (even it looks like there's no differences in system behaviour) I will roll back to DSDT without multiplex patch applied. As if U're saying I should not have this patch while using GenericUSBXHCI.kext. Can keep that 7/8 series patch in DSDT or better roll back to previous one where no USB patch is applied?

 

[RehabMan]

Ok (even it looks like there's no differences in system behaviour) I will roll back to DSDT without multiplex patch applied. As if U're saying I should not have this patch while using GenericUSBXHCI.kext. Can keep that 7/8 series patch in DSDT or better roll back to previous one where no USB patch is applied?

Generally, you need the 7/8 patch to avoid instant wake after sleep...

 

[igielskv]

The multiplex patches are only for AppleUSBXHCI.kext. You should not use multiplex patch with GenericUSBXHCI.kext. You might try GenericUSBXHCI.kext with only the XHC1 device removed from DSDT.

Sorry for so many maybe stupid questions, but U say use GenericUSBXHCI.kext only with XHC1 device removed from DSDT. But I still have XHC1 device there, and it's not from multiplex patch. It must have been there before.

Device (XHC1)
{
Name (_ADR, 0x00140000) // _ADR: Address
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x0D, 0x03))
}


Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg2, Zero))
{
Return (Buffer (One)
{
0x03
})
}


Return (Package (0x12)
{
"AAPL,clock-id",
Buffer (One)
{
0x02
},


"built-in",
Buffer (One)
{
0x00
},


"subsystem-id",
Buffer (0x04)
{
0x70, 0x72, 0x00, 0x00
},


"subsystem-vendor-id",
Buffer (0x04)
{
0x86, 0x80, 0x00, 0x00
},


"AAPL,current-available",
0x0834,
"AAPL,current-extra",
0x0898,
"AAPL,current-extra-in-sleep",
0x0640,
"AAPL,device-internal",
0x02,
"AAPL,max-port-current-in-sleep",
0x0834
})
}
}

Even when looking on m clean DSDT, theres still XHC1 device used like this:

Device (XHC1)
{
Name (_ADR, 0x00140000) // _ADR: Address
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x0D, 0x03))
}
}



So should I remove it??? Or leave it there?

 

[RehabMan]

Sorry for so many maybe stupid questions, but U say use GenericUSBXHCI.kext only with XHC1 device removed from DSDT. But I still have XHC1 device there, and it's not from multiplex patch. It must have been there before.

Device (XHC1)
{
Name (_ADR, 0x00140000) // _ADR: Address
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x0D, 0x03))
}


Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg2, Zero))
{
Return (Buffer (One)
{
0x03
})
}


Return (Package (0x12)
{
"AAPL,clock-id",
Buffer (One)
{
0x02
},


"built-in",
Buffer (One)
{
0x00
},


"subsystem-id",
Buffer (0x04)
{
0x70, 0x72, 0x00, 0x00
},


"subsystem-vendor-id",
Buffer (0x04)
{
0x86, 0x80, 0x00, 0x00
},


"AAPL,current-available",
0x0834,
"AAPL,current-extra",
0x0898,
"AAPL,current-extra-in-sleep",
0x0640,
"AAPL,device-internal",
0x02,
"AAPL,max-port-current-in-sleep",
0x0834
})
}
}

Even when looking on m clean DSDT, theres still XHC1 device used like this:

Device (XHC1)
{
Name (_ADR, 0x00140000) // _ADR: Address
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x0D, 0x03))
}
}



So should I remove it??? Or leave it there?

Try removing it just to see what happens...

 

[igielskv]

Try removing it just to see what happens...

Ok, I removed it also this one:

Device (XHC1)
{
Name (_ADR, 0x00140000) // _ADR: Address
Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
{
Return (GPRW (0x0D, 0x03))
}

Which was in my Clean extracted DSDT and it still works, USB3 and USB2 devices with no problem...

Just doesn't have any effect on that slight problem with G-Drive recognition while system is running.