Jump to content

DSDT fixes for Gigabyte boards

iSoprano

By iSoprano,
in Guides

 Share
1,908 posts in this topic

Recommended Posts

Johnny V
Johnny V
Posted
Posted
Old patch was this:

"AAPL,clock-id", 
Buffer (One)
{
     0x01
}

Those have to be removed.

 

Hi mm67!

 

I'm also using iSoprano's #6 DSDT I just had to change Realtek ALC888 data to Realtek ALC889a for my motherboard and all is working 100%.

 

I also have the above code, should I delete this? Also what are we looking for when running kextstat|grep SMBus from the Terminal?

 

 

Thanks!

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted
I just wanted to throw this out there for what it's worth. I know there's the ESB patch that fixes the orange drive icon problem. Against my better judgment I decided to try it because of all the people saying they've been using it for months with no problems. I applied the patch and ran some performance tests to see if there were no ill effects. Well it didn't perform any better or any worse but within 24 hours my 1.5TB drive that I've had less than a year is junk. Now, is this just coincidence… yeah probably but never the less I've reverted back to using IOAHCIBlockStorageInjector.

 

Strange indeed yesterday my test system's main drive a 1tb died off on me, I applied that patch on it a couple of days ago..

Link to comment
Share on other sites
artimess
artimess
Posted
Posted

I have this annoying problem of hearing the clicking of my DVD device when my machine is on sleep.

I would appreciate any suggestions or fixes that you might have for this problem.

My P and C state work perfectly, thanks to you all.

Looking forward to your suggestions. And merry Xmas to you all.

 

Artimess

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
Hi mm67!

 

I'm also using iSoprano's #6 DSDT I just had to change Realtek ALC888 data to Realtek ALC889a for my motherboard and all is working 100%.

 

I also have the above code, should I delete this? Also what are we looking for when running kextstat|grep SMBus from the Terminal?

 

 

Thanks!

 

It doesn't matter much unless you have something connected to a USB2.0 hub that you want to use for wake up. New Apple wired keyboard for example, or a normal keyboard connected to a USB2.0 hub instead of motherboard connector. But it certainly won't do any harm to fix that error. Who knows, maybe you will buy an Apple keyboard one day :D

 

 

Strange indeed yesterday my test system's main drive a 1tb died off on me, I applied that patch on it a couple of days ago..

 

That didn't happen to be a Seagate disk ? If so then check this page: http://forums.seagate.com/stx/board?board.id=ata_drives

 

In last 6 months my 1 Tb Seagate has failed two times, both times a firmware failure. Anyone that has these newer Seagate disks should check their firmwares.

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted
That didn't happen to be a Seagate disk ? If so then check this page: http://forums.seagate.com/stx/board?board.id=ata_drives

 

In last 6 months my 1 Tb Seagate has failed two times, both times a firmware failure.

 

Oh yeah it was the firmware was already updated way back when those problems were reported and that is the first thing I thought of until I read that post so I don't totally know which caused it, worst thing about it I have four more of that god damn series never again Seagate...

Link to comment
Share on other sites
mm67
mm67
Posted
Posted
Oh yeah it was the firmware was already updated way back when those problems were reported and that is the first thing I thought of until I read that post so I don't totally know which caused it, worst thing about it I have four more of that god damn series never again Seagate...

 

Yes, I also got the firmware updated last spring, turned out that the newer firmware was just as buggy as the original. They now had a new one again, let's see when someone tells that to be buggy as well. I think I am pretty much done with Seagate products.

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
Again the same error in EHCI devices.

                Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x04)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x3A, 0x29, 0x00, 0x00
                           }, 

                           "AAPL,clock-id", 
                           Buffer (One)
                           {
                               0x01
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }

 

Cut these out if you want to be able to use USB2.0 devices for wake up. Do you really need to do device-id injection with ICH10 device-id, I thought your board has ICH10.

@LocusOfControl

 

Yeah mm67 is right. First you don't need device injection here because you have an ICH10 MOBO. As well as using an old patch to get EHCI working. You were also missing the UHC6 device in your _GPE section.

 

Take a look at my signature and download the GA-EP45-UD3P. That's a ICH10 motherboard. It's been stripped down modeled after mm67's handywork! Compare it to your own and see where you can slim it down. You don't need half that stuff. You should be able to get your DSDT down to around 1100-1200 lines. Let me know how you make out.

 

 

Strange indeed yesterday my test system's main drive a 1tb died off on me, I applied that patch on it a couple of days ago..
So can we universally agree the ESB patch is a bad idea? If so spread the word.
Link to comment
Share on other sites
mm67
mm67
Posted
Posted

Anyone have any ideas how to access bit 18 of this register:

PxCMD—Port [5:0] Command Register (D31:F2)

 

On my MSI board value of that bit is 0 and it doesn't need IOAHCIBlockStorageInjector.kext. On my Gigabyte board that bit is set and the kext file is necessary. Only problem is that the bit is marked as R/WO, maybe there is no other way to modify it but to modify bios ?

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
Yes, I also got the firmware updated last spring, turned out that the newer firmware was just as buggy as the original. They now had a new one again, let's see when someone tells that to be buggy as well. I think I am pretty much done with Seagate products.
As a matter of fact mine was a Seagate too and I did upgrade the firmware way back. I done with them as well! I'm thinking I need to swap out all my Seagate drives now before they {censored} out too.

 

Anyone have any ideas how to access bit 18 of this register:

PxCMD—Port [5:0] Command Register (D31:F2)

 

On my MSI board value of that bit is 0 and it doesn't need IOAHCIBlockStorageInjector.kext. On my Gigabyte board that bit is set and the kext file is necessary. Only problem is that the bit is marked as R/WO, maybe there is no other way to modify it but to modify bios ?

Are you saying what I think you're saying?
Link to comment
Share on other sites
mm67
mm67
Posted
Posted
As a matter of fact mine was a Seagate too and I did upgrade the firmware way back. I done with them as well! I'm thinking I need to swap out all my Seagate drives now before they {censored} out too.

 

Are you saying what I think you're saying?

 

Yes, I think that bit is the reason for our extra kext file, but I haven't found any way to reset it. On MSI value of that register is 0x00000006, on Gigabyte it is 0x08040006. That bit is again same kind of {censored} than those bits on Ehci devices, on hardware level it does nothing but it does fool OS X into thinking that our hard disks are external.

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
Do you have only one drive in your computer? If not then this can't be true.
At the time I had four SATA hard drives and two SATA DVD drives.

 

 

Yes, I think that bit is the reason for our extra kext file, but I haven't found any way to reset it. On MSI value of that register is 0x00000006, on Gigabyte it is 0x08040006. That bit is again same kind of {censored} than those bits on Ehci devices, on hardware level it does nothing but it does fool OS X into thinking that our hard disks are external.
So do MSI motherboard not need IOAHCIBlockStorageInjector?
Link to comment
Share on other sites
mm67
mm67
Posted
Posted
That's the last time I buy a Gigabyte board too!

 

My MSI board has been a very handy tool in fixing Gigabytes bugs, easy to do comparisons and see how things should be done. But I too am no longer going to buy any more Gigabyte boards, too much extra work compared to MSI.

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted
So can we universally agree the ESB patch is a bad idea? If so spread the word.

 

Not sure there as MC points out there were four drives in my test machine only one died, what both of us had in common was the same series of Seagate crappy drives in addition to that patch.

Link to comment
Share on other sites
bs0d
bs0d
Posted
Posted
<br />Yes, I think that bit is the reason for our extra kext file, but I haven't found any way to reset it. On MSI value of that register is 0x00000006, on Gigabyte it is 0x08040006. That bit is again same kind of {censored} than those bits on Ehci devices, on hardware level it does nothing but it does fool OS X into thinking that our hard disks are external.<br /><br />
one could probably try adding it in the bootloader in a similar fashion to the USB Fixes.
Link to comment
Share on other sites
mm67
mm67
Posted
Posted
Not sure there as MC points out there were four drives in my test machine only one died, what both of us had in common was the same series of Seagate crappy drives in addition to that patch.

 

The one that got corrupted on my system is a Samsung disk. It took a couple weeks with the patch and then nothing helped but full format. After removing the patch disk has had no problems, neither before adding that patch. So I am not going to use it anymore.

 

 

one could probably try adding it in the bootloader in a similar fashion to the USB Fixes.

 

Problem is that R/WO, which means it can be written only once. I think that happens already when booting.

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted
The one that got corrupted on my system is a Samsung disk. It took a couple weeks with the patch and then nothing helped but full format. After removing the patch disk has had no problems, neither before adding that patch. So I am not going to use it anymore.

 

Good enough for me then when I get my test machine back up and running after Christmas that patch will not be used, thanks.

 

Edit: Just replied in another thread about the PCI slots on these P45 boards. Does anyone have a card in the slot closest to the CPU that works under OS X?

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
The one that got corrupted on my system is a Samsung disk. It took a couple weeks with the patch and then nothing helped but full format. After removing the patch disk has had no problems, neither before adding that patch. So I am not going to use it anymore.

 

Problem is that R/WO, which means it can be written only once. I think that happens already when booting.

That MSI board wouldn't happen to have firewire would it? That seems to be one of the last remaining issues.
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...