Jump to content
itpwd

dell m6700 usb 3.0 intel seen as 2.0

13 posts in this topic

Recommended Posts

Hi everyone, I have a problem with the intel USB 3.0 ports of my Dell Mobile Workstation M6700:

 

5 usb ports in total:
2 usb 2.0 ports (work perfectly)
1 usb / eSata combo port (works perfectly)
2 usb 3.0 intel ports (seen as 2.0 and slow as such)

I tried usbinjectall.kext with the patch limit port for sierra in clover (renamed ehci1 to eh01 .....), nothing.
I applied the patch (to the dsdt.amd) 7-series / 8-series usb of rehabman, nothing. (this method worked on another dell and on a toshiba)
I tried GenericUSBXHCI.kext and fakepciid.kext + fakepciid_xhcimux.kext, nothing.
The system always reads them as 2.0. In the profiler you can see 2 usb 2.0 controllers and no xhci controllers.

 

I hope you can help me because I'm really freaking out: cry :: cry:

 

Fyi some files.

1.png

2.png

3.thumb.png.c122550e2db0c2e7d8de80ee431d9523.png

 

 

 

 

CLOVER_M6700_5098_20191109.zip

Edited by itpwd

Share this post


Link to post
Share on other sites
Advertisement

Lack of USB3.0 controller is quite typical on Ivy Bridge platforms if DSDT's OSYS parameter is not set to the appropriate value in ACPI. If you look into your extracted DSDT table, you'll see that OSYS's default value is set to 0x07D0. The value then gets adjusted according to Windows's version. Very obviously, OS X/macOS is not taken into account in the original DSDT table so you need to inject "Darwin" so that the parameter can be set to the required value for that OS. This value needs to be that applied from Windows Vista at minimum.

 

For your info:

  • Windows 2001 = Win XP
  • Windows 2006 = Win Vista
  • Windows 2009 = Win7
  • Windows 2012 = Win8
  • etc.

 

You could either apply ACPI fix "FixDarwin7" in your Clover config (use Clover Configurator app to that effect) which sets Darwin for Windows 2009 (i.e. OSYS gets set for Win7) or patch your DSDT as follows:

origin:

    Scope (_SB.PCI0)
    {
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (0x07D0, OSYS)
            If (CondRefOf (\_OSI, Local0))
            {
                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }
                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }
                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }
                If (_OSI ("Windows 2001.1"))
                {
                    Store (0x07D3, OSYS)
                }
                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }
                If (_OSI ("Windows 2009"))
                {
                    Store (0x07D9, OSYS)
                }
            }
            [...]
        }

patched:

    Scope (_SB.PCI0)
    {
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (0x07D0, OSYS)
            If (CondRefOf (\_OSI, Local0))
            {
                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }
                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }
                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }
                If (_OSI ("Windows 2001.1"))
                {
                    Store (0x07D3, OSYS)
                }
                If (LOr (_OSI ("Darwin"), _OSI ("Windows 2006")))     // Injects Darwin to enable USB3/XHC support
                {
                    Store (0x07D6, OSYS)
                }
                If (_OSI ("Windows 2009"))                            // Darwin can be injected here too
                {
                    Store (0x07D9, OSYS)
                }
            }
            [...]
        }

 

Your USB3.0 controller will then be natively recognized and supported and you'll find your SysInfo USB section report changing from this:

USB2_only.png.511d369755e2dbac34704eccb615b52a.png

 

to this:

USB3.png.db5f867fc1a55ad84bc869de3b82beb1.png

 

There is no need of any GenericUSBXHCI kext for Intel's 0x1e31 XHC controller but you'll indeed need Rehabman's Fake_PCIID + FakePCIID_XHCIMux kexts of you want USB port multiplexing of USB3/USB2.

 

Edited by Hervé

Share this post


Link to post
Share on other sites
4 hours ago, Hervé said:

You could either apply ACPI fix "FixDarwin7" in your Clover config (use Clover Configurator app to that effect) which sets Darwin for Windows 2009 (i.e. OSYS gets set for Win7) or patch your DSDT

 

Hi Hervé,

Thank you for providing two professional methods.

Maybe my luck is not good.

 

Method 1: Fix "FixDarwin7"

Restart cannot be loaded/entered into the OS after fix "FixDarwin7".

Fyi -v screenshot.

763BB3788BB5DEE4FF71045EDD31F569.thumb.jpg.30a87ee82b235201f4259e4dc6abb290.jpg

 

Method2: Patch DSDT

I am not familiar with patch dsdt, there are two syntax errors here, but I don't know how to fix it.

Fyi the dsdt.dsl.

DSDT.dsl.zip

dsdt_error.thumb.png.04a1440862dab8ee84d17c135ab3864a.png

 

Hope to receive your reply/help. And I hope you have a great time every day. ^_^

Edited by itpwd

Share this post


Link to post
Share on other sites

It's just the well-known and documented ACPI/iASL bug that messes up the section of code for PM6H and PM0H:

                If (LEqual (PM6H, One))
                {
                    CreateBitField (BUF0, \_SB.PCI0._Y0C._RW, ECRW)  // _RW_: Read-Write Status
                    Store (Zero, ECRW (If (PM0H)
                            {
                                CreateDWordField (BUF0, \_SB.PCI0._Y0D._LEN, F0LN)  // _LEN: Length
                                Store (Zero, F0LN)
                            }))
                }

Code needs to be fixed as follows:

                If (LEqual (PM6H, One))
                {
                    CreateBitField (BUF0, \_SB.PCI0._Y0C._RW, ECRW)  // _RW_: Read-Write Status
                    Store (Zero, ECRW)
                }

                If (PM0H)
                {
                    CreateDWordField (BUF0, \_SB.PCI0._Y0D._LEN, F0LN)  // _LEN: Length
                    Store (Zero, F0LN)
                }

 

Anyway, here's your patched DSDT and source code with bug fix:

patched.zip

 

Please note that, since we're dealing with an iASL bug, the issue will return if you open up the compiled DSDT.aml file I just posted and recompile it. That's why I've also attached the source code .dsl file that includes the fixed piece of ACPI code. Ideally, apply any subsequent patch to the .dsl file before recompiling the DSDT. If you simply re-open the .aml file for modification (which you're perfectly allowed to do), you'll have to also re-apply the above fix.

 

Edited by Hervé

Share this post


Link to post
Share on other sites
9 hours ago, Hervé said:

It's just the well-known and documented ACPI/iASL bug that messes up the section of code for PM6H and PM0H.

In fact, I found that the syntax here is not normal, but because I am not familiar with dsdt…

Thank you for your information, I have learned the knowledge of dsdt.

 

9 hours ago, Hervé said:

Anyway, here's your patched DSDT and source code with bug fix:

patched.zip

 

Please note that, since we're dealing with an iASL bug, the issue will return if you open up the compiled DSDT.aml file I just posted and recompile it. That's why I've also attached the source code .dsl file that includes the fixed piece of ACPI code. Ideally, apply any subsequent patch to the .dsl file before recompiling the DSDT. If you simply re-open the .aml file for modification (which you're perfectly allowed to do), you'll have to also re-apply the above fix.

Got your information.

But the patched file you provided cannot be loaded into the system after being placed in ACPI/patched.

I tried to replace FakeSMC/VirtualSMC or remove FakePCIID/FakePCIID_XHCIMux in the kext directory, but it didn't work very well.
To do this, I generated the debug file(not included dsdt.aml) and asked for your help again.

 

Hope all is well and fine.

debug_29309.zip

F5401359B7D49D03C74282E664FAB70A.jpg

Share this post


Link to post
Share on other sites

Hi Hervé,

Good news.

Works good after apply USB fix "Repair ownership"(I am not sure if this translation is in English.) in Clover config.

 

Thanks for your professional information.

 

Share this post


Link to post
Share on other sites
3 hours ago, Hervé said:

So I guess both OSYS adjustment methods should work with this additional fix in place.

Hi Hervé,

You are right. I tested two methods.

Both of these methods can achieve the display USB3.0 (1e31), then what is the difference between them?

 

Thanks.

Share this post


Link to post
Share on other sites

In a nutshell, Clover's method basically sets the OS to Win7 in DSDT through a fancy on-the-fly patch whilst the other method is a much shorter single-line modification that simply injects Darwin alongside Win Vista (or Win7) in a conditional OS identification check that sets OSYS.

 

Both methods basically achieve the same result but Clover's patch is an on-the-fly direct modification of the DSDT table loading from BIOS ROM whilst the other method I described consists of a patched DSDT table saved in a file that Clover loads at system startup to replace the default BIOS table.

 

If you apply the Clover method, then use maciASL app to open your active DSDT, you'll see the difference with the 2 in terms of modifications to the ACPI code.

 

Clover's FixDarwin7

1) at beginning of DSDT, sets OS to Win7 and, as an alternative to _OSI method (an ASL standard method used to identify operating system version), defines new OOSI method which compares all declared Windows versions to Win7's and returns true or false :

    Name (VER0, "Clover autopatched")
    Name (WXP1, "Windows 2009")
    Method (GET9, 2, NotSerialized)
    {
        CreateByteField (Arg0, Arg1, TCH9)
        Return (TCH9)
    }
    Method (STR9, 2, NotSerialized)
    {
        Name (STR8, Buffer (0x50){})
        Name (STR9, Buffer (0x50){})
        Store (Arg0, STR8)
        Store (Arg1, STR9)
        Store (Zero, Local0)
        Store (One, Local1)
        While (Local1)
        {
            Store (GET9 (STR8, Local0), Local1)
            Store (GET9 (STR9, Local0), Local2)
            If (LNotEqual (Local1, Local2))
            {
                Return (Zero)
            }
            Increment (Local0)
        }
        Return (One)
    }
    Method (OOSI, 1, NotSerialized)
    {
        If (STR9 (WXP1, Arg0))
        {
            Return (One)
        }
        Return (Zero)
    }

2) then replaces _OSI standard method by newly defined OOSI method which, in PCI0's _INI method, results in:

        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (0x07D0, OSYS)
            If (CondRefOf (\OOSI, Local0))
            {
                If (OOSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }
                If (OOSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }
                If (OOSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }
                If (OOSI ("Windows 2001.1"))
                {
                    Store (0x07D3, OSYS)
                }
                If (OOSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }
                If (OOSI ("Windows 2009"))
                {
                    Store (0x07D9, OSYS)
                }
            }

            [...]
        }

 

Patched DSDT table

injects Darwin alongside Win Vista (or Win7) in PCI0's _INI method:

                If (LOr (_OSI ("Darwin"), _OSI ("Windows 2006")))
                {
                    Store (0x07D6, OSYS)
                }

 

Edited by Hervé

Share this post


Link to post
Share on other sites
44 minutes ago, Hervé said:

In a nutshell, Clover's method basically defines the OS to Win7 in DSDT through a fancy patch whilst the other method simply injects Darwin OS alongside Win Vista (or Win7) in a much shorter single-line mod.

 

Both methods basically achieve the same result but Clover's patch is an on-the-fly direct modification of the DSDT table loading from BIOS ROM whilst the other method I described consists of a patched DSDT table saved in a file that Clover loads at system startup to replace the default BIOS table.

Hi Hervé,

Thanks for your quickly reply.

I am afraid this requires more knowledge to understand what you mean.

There should be some guidelines for the fix in this area, but I can't search for it.

It should be said that I don't know how to search for keywords. I don’t seem to be able to search for related cases in the Chinese community.

Can you provide some typical examples /link to study? If possible, I will share your professional information to some Chinese communities to help more people search for this information.

 

BTW, in the advice of novices, which method do you think is better?

 

Thanks.

Share this post


Link to post
Share on other sites

Let's avoid the off-topic and I'm not the right person to teach you ACPI coding, I hardly know it myself! It's very low-level stuff for people with advanced programming skills and hardware knowledge.

 

With regards to Clover's fixes, you can consult the Clover documentation available on the Web; you can Google for it (Clover wiki for instance).

 

One method is not really better than the other... Clover's method is on-the-fly and therefore can be applied to systems that do not use a patched DSDT. If you already use a patched DSDT, obviously use the 2nd one.

 

This thread can now be closed.

Edited by Hervé

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×