Jump to content
VegasKarma

Master Chief's P5K PRO ACPI Warfare

908 posts in this topic

Recommended Posts

Is it November(11.12), or you made some changes in it?

I´m using November release version..

 

Regards.

This is a pre-release, compiled by me just before the official release. I only wanted to know if the attached file works for you, or not of course – so that I can act when things don't seem to work for other people.

 

People like you, happily using another compiled version, may stay with it, for as long as they wish, because again; this was a request for feedback only. After all, developers like me cannot do much without feedback, but I'm not involved with the ACPICA project, but then again so is nobody else here...

 

Downloaded Nov 11th - working faultless here.

Thanks DB1, that's all I wanted to know <_<

Share this post


Link to post
Share on other sites
Advertisement
My problem wasn't about waking the system by keyboard (mouse), it was about the BIOS legacy usb setting (must be disabled for S3 - but for single mode I need to enable it to have my keyboard detected). The jumper setting is correct. <_<

Yeah I remember your PM, but this was another P5GC-MX/1333 user. Someone who jumped ship like we here did.

 

OT: I don't use Ubuntu anymore. In fact I am personally fairly unhappy with the Ubuntu GUI. Mark said to work on it and hired Mozilla UI buddy Matthew (Mozilla Application Developer here) but I don't see much changes being accepted. I just don't get this kind of slowness, because more people will jump to a free alternative when that looks half as good as OS X. Just look at the old big fat ugly button (icons). So 1985. A sad disappointment it is. We need a redefined Linux GUI and pronto. And Google's Chrome OS might kick some people to step up a few notches ;)

Share this post


Link to post
Share on other sites
This is a pre-release, compiled by me just before the official release. I only wanted to know if the attached file works for you, or not of course �" so that I can act when things don't seem to work for other people.

 

People like you, happily using another compiled version, may stay with it, for as long as they wish, because again; this was a request for feedback only. After all, developers like me cannot do much without feedback, but I'm not involved with the ACPICA project, but then again so is nobody else here...

 

 

Thanks DB1, that's all I wanted to know :wacko:

Right...Worked for me too..:wacko:

Thanks.

 

Regards.

Share this post


Link to post
Share on other sites

A new/updated version of LegacyACPI_SMC_PP.kext for OS X 10.6.2 is now available for download.

 

A few notes:

 

1) I use P5K PRO as model identifier and thus you have to rename that to the model you are using.

2) You only need this kext in case you want/need to change some values in it.

3) You have to put it in: /System/Library/Extensions/ or it won't even work.

4) This version won't trigger the load of LegacyAGPM.kext (my next attachment will/available sometime next week).

LegacyACPI_SMC_PP.kext.zip

Share this post


Link to post
Share on other sites

Master Chief,

 

after adding this to my dsdt:

 Device (FRWR)
			{
				Name (_ADR, 0x00060000)
				Name (_GPE, 0x1A)
				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x02)
						{
							"fwhub", 
							Buffer (0x04)
							{
								0x00, 0x00, 0x00, 0x00
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}
			}

 

 Method (_L1A, 0, NotSerialized)
	{
		Notify (\_SB.PCI0.HUB0.FRWR, 0x02)
		Notify (\_SB.PWRB, 0x02)
	}

 

 

this error:

"firewire runtime power conservation disabled. 2" is gone

but firewire doesn't run properly...

My audio interface is no longer recognized!

Share this post


Link to post
Share on other sites
Master Chief,

 

after adding this to my dsdt:

 ... see post #358

 

 ... see post #358

this error:

"firewire runtime power conservation disabled. 2" is gone

but firewire doesn't run properly... My audio interface is no longer recognized!

Yeah, and other people complained about the fact that hot-plug doesn't work either. But I think that you should start by using Zero instead of the 0x02 in Method _L1A since that triggers a bus check, since we don't want a wake call here. And you could experiment by adding something like this:

					Name (_PRW, Package (0x02)
				{
					0x09,  // <= match this with the one used in _GPE!!!
					0x03
				})

And... no better something like this:

					Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x02)
						{
							"fwports", 
							Buffer (0x04)
							{
								0x01, 0x00, 0x00, 0x00 // You may have to change this 0x01 here!
							}
						}, Local0)
					MCDP (Arg2, RefOf (Local0))
					Return (Local0)
				}

Keep in mind that the previous code (with fwhub) was copied from a MacPro3,1 which happens to have a FireWire hub too. And a MacPro4,1 also, but we don't have one so... Let me know if this works for you.

 

Work in progress... I'll be testing this myself later today. This seems to work. At least here.

 

Update: The server went down when I was about to update my reply, because here hot plug works after sleep. That's also when my HD LED starts to flash like a heartbeat. I don't know why, but I guess that we have to figure it out a.s.a.p.

Share this post


Link to post
Share on other sites

Master Chief,

 

can you please check this:

 

 Scope (_GPE)
{
	Method (_L1A, 0, NotSerialized)
	{
		Notify (\_SB.PCI0.HUB0.FRWR, Zero)
		Notify (\_SB.PWRB, 0x02)
	}

	Method (_L03, 0, NotSerialized)
	{
		Notify (\_SB.PCI0.USB0, 0x02)
		Notify (\_SB.PWRB, 0x02)
	}

	Method (_L04, 0, NotSerialized)
	{
		Notify (\_SB.PCI0.USB1, 0x02)
		Notify (\_SB.PWRB, 0x02)
	}
....

 

and here is my FRWR Device including this :

Name (_PRW, Package (0x02)

{

0x09, // <= match this with the one used in _GPE!!!

0x03

})

 

Device (FRWR)
			{
				Name (_ADR, 0x00060000)
				Name (_GPE, 0x1A)
				Name (_PRW, Package (0x02)
				{
					0x1A, 
					0x03
				})
				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x02)
						{
							"fwports", 
							Buffer (0x04)
							{
								0x01, 0x00, 0x00, 0x00
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}
			}

 

 

 

Is this right?

If yes it doesn't work for me...

Share this post


Link to post
Share on other sites
Master Chief,

 

can you please check this:

 

 ... see post #360

Is this right?

If yes it doesn't work for me...

You don't need Notify (\_SB.PWRB, 0x02) and you can also remove Name (_PRW... from your FRWR device.

 

Does it work for you after sleep? See my previous post about the HD LED.

 

Note: Here hot plug only works after sleep.

Share this post


Link to post
Share on other sites
You don't need Notify (\_SB.PWRB, 0x02) and you can also remove Name (_PRW... from your FRWR device.

 

Does it work for you after sleep? See my previous post about the HD LED.

 

Note: Here hot plug only works after sleep.

 

I removed this "Notify (\_SB.PWRB, 0x02)" and removed this:

"Name (_PRW, Package (0x02)

{

0x1A,

0x03

})"

 

But no it doesn't recognizing my audio interface after/before sleep!!!

 

My audio interface is recognizing only while booting....

But booting with audio interface plugged the boot time is more than twice!!!

And I can't use the interface properly in Logic...I always get some glitches and noises!!!

Share this post


Link to post
Share on other sites
I removed this "Notify (\_SB.PWRB, 0x02)" and removed this:

"Name (_PRW, Package (0x02)

{

0x1A,

0x03

})"

 

But no it doesn't recognizing my audio interface after/before sleep!!!

 

My audio interface is recognizing only while booting....

But booting with audio interface plugged the boot time is more than twice!!!

And I can't use the interface properly in Logic...I always get some glitches and noises!!!

Let's go back a few steps.

 

1) You did not have any DSDT related code before we started to work on it?

2) The interface was recognized and worked flawlessly with 10.5.n?

3) The boot time change when? After you started to use 10.6.n?

4) You did not have Name (_PRW... before, so you should be able to remove it.

5) If you remove things, do it one after the other. Not two or more things at one time.

6) My ioreg output changes after sleep, so please verify this by entering ioreg -l in a terminal window. And when you see the same, then please attach a ZIP file with both outputs, but disconnect all equipment with serial numbers first! You may also upload it and PM me the link, and remove it afterwards. Thanks.

 

Here are the changes I see before (-) after (+) sleep (only the relevant parts listed):

    | |   +-o PCIB@1E  <class IOPCIDevice, id 0x100000159, registered, matched, active, busy 0 (717 ms), retain 10>
    | |   | | {
    | |   | |   "compatible" = <"pci8086,244e","pciclass,060401">
-    | |   | |   "IOPowerManagement" = {"ChildrenPowerState"=1,"CurrentPowerState"=1}
+    | |   | |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2}

    | |   |   |   "IOClass" = "IOPCI2PCIBridge"
-    | |   |   |   "IOPowerManagement" = {"CurrentPowerState"=1,"ChildProxyPowerState"=2,"ChildrenPowerState"=1}
+    | |   |   |   "IOPowerManagement" = {"CurrentPowerState"=2,"ChildProxyPowerState"=2,"ChildrenPowerState"=2}

    | |   |     |   "IOInterruptSpecifiers" = (<1000000007000000>)
-    | |   |     |   "IOPowerManagement" = {"ChildrenPowerState"=1,"CurrentPowerState"=1}
+    | |   |     |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2}

    | |   |       +-o IOFireWireController  <class IOFireWireController, id 0x1000001c6, registered, matched, active, busy 0 (645 ms), retain 9>
-    | |   |         |   "IOPowerManagement" = {"DriverPowerState"=1,"CurrentPowerState"=1}
-    | |   |         |   "FireWire Generation ID" = "2"
+    | |   |         |   "IOPowerManagement" = {"DriverPowerState"=2,"CurrentPowerState"=2}
+    | |   |         |   "FireWire Generation ID" = "8"

    | |   |         +-o IOFireWireLocalNode  <class IOFireWireLocalNode, id 0x100000200, registered, matched, active, busy 0 (644 ms), retain 12>
@@ -1646,7 +1660,7 @@
    | |   |           |   "FireWire Speed" = 2
-    | |   |           |   "FireWire Device ROM" = <0404a96331333934f800a242001e8c000119a5e6000927043800000403000a278100000717000
00a8100000d0c0083c08d000011d1000013d10000150007ac750000000$
+    | |   |           |   "FireWire Device ROM" = <04045d6131333934f800a272001e8c000119a5e60009a1413800000703000a278100000717000
00a8100000d0c0083c08d000011d1000013d10000150007ac750000000$

 

lspci -nnxxvv also shows some changes:

PCI Express Root Port

Capabilities: [100] #8086

00: 86 80 c1 29 07 01 10 00 02 00 04 06 08 00 01 00

-10: 00 00 00 00 00 00 00 00 00 01 01 00 c0 c0 00 20

+10: 00 00 00 00 00 00 00 00 00 01 01 00 c0 c0 00 00

 

PCI Express Port 1

Capabilities: [827] #f8f1

00: 86 80 40 29 06 01 10 00 02 00 04 06 08 00 81 00

-10: 00 00 00 00 00 00 00 00 00 03 03 00 f0 00 00 20

+10: 00 00 00 00 00 00 00 00 00 03 03 00 f0 00 00 00

 

And a bunch of these:

 

- Capabilities: [50/98/B0] Vendor Specific Information <?>

+ Capabilities: [50/98/B0] PCIe advanced features <?>

Share this post


Link to post
Share on other sites
Let's go back a few steps.

 

1) You did not have any DSDT related code before we started to work on it?

2) The interface was recognized and worked flawlessly with 10.5.n?

3) The boot time change when? After you started to use 10.6.n?

4) You did not have Name (_PRW... before, so you should be able to remove it.

5) If you remove things, do it one after the other. Not two or more things at one time.

6) My ioreg output changes after sleep, so please verify this by entering ioreg -l in a terminal window. And when you see the same, then please attach a ZIP file with both outputs, but disconnect all equipment with serial numbers first! You may also upload it and PM me the link, and remove it afterwards. Thanks.

 

 

Master Chief,

first, thanks for trying to help!!!

 

1) No, I did not have any DSDT related code before we started here in this thread(page 16, post #316)

2) Yes, was recognized in 10.5n and in Snow from 10.6, but never had worked flawlessly like in Windows or in a real

Mac...

3) The boot time changed since 10.5n

4) No I did not have Name (PRW...) before, so i removed it!

5) O.K.

6) Yes my ioreg output changes after sleep too, I will send you a pm with the ioregs befor and after sleep!

 

again, Thanks!!!

Share this post


Link to post
Share on other sites
Master Chief,

first, thanks for trying to help!!!

 

1) No, I did not have any DSDT related code before we started here in this thread(page 16, post #316)

2) Yes, was recognized in 10.5n and in Snow from 10.6, but never had worked flawlessly like in Windows or in a real

Mac...

3) The boot time changed since 10.5n

4) No I did not have Name (PRW...) before, so i removed it!

5) O.K.

6) Yes my ioreg output changes after sleep too, I will send you a pm with the ioregs befor and after sleep!

 

again, Thanks!!!

You are welcome. I just love new challenges, especially when I haven't even finished most of my other work. Ah whatever. Now a cup of coffee first, and let's see what I can do after only getting a few hours of sleep.

 

Any French people here willing to help another French citizen per PM, with installing Snow Leopard on a P5K PRO? I'm asking this because I like to concentrate on stuff like this, among others, without Isabelle having to wait until Christmas for my help, so come on guys (PM only). Give her a little help and be nice to her!!!

 

TIA

Share this post


Link to post
Share on other sites

I think to have found a better way to shutdown my hack, and maybe sleep as well. Look here. Let's see what people get as result with the new code. Works a treat here – I'm even going to shutdown my hack for fun right now LOL

 

And the idea is simple... let Power Management initiate the transition. Here's a first code snippet:

    OperationRegion (PM1C, SystemIO, 0x0804, 0x04) // PM1_CNT—Power Management 1 Control (ICH9R-316972.pdf / 13.8.3.3 / page 507)
   Field (PM1C, ByteAcc, NoLock, Preserve)
   {
           ,  10,
       SLPT,   3,                                 // Bits 10:12 – Sleep Type
       SLPE,   1                                  // Bit 13 – Sleep Enable.
   }

With the usual comments so that everyone can look at it, read the specification and understand what I am doing. In fact it is pretty easy with the specifications at hand. And here are the bit definitions to trigger state transitions:

 

Code State

000b S0 – ON / 0x00 (Zero).

001b S1 – Stop-Grant state / 0x01 (One).

010b Reserved.

011b Reserved.

100b Reserved.

101b S3 – Suspend-To-RAM / 0x05.

110b S4 – Suspend-To-Disk / 0x06.

111b S5 – Soft off / 0x07.

 

Now we have to change Method _PTS a little, to make use of the new code. And here's what I am using at the moment:

    Method (_PTS, 1, NotSerialized) // Prepare To Sleep.
   {
       If (LEqual (Arg0, 0x05)) // S5 – Soft off
       {
           Store (0x07, SLPT)
           Store (One, SLPE)
       }
       Else 
       {
           Store (Arg0, DBG8)

           If (Arg0)
           {
               \_SB.PCI0.LPCB.SPTS (Arg0)
           }

           Store (ASSB, WSSB)
           Store (AOTB, WOTB)
           Store (AAXB, WAXB)
           Store (Arg0, ASSB)
           Store (One, AOTB)
           Store (Zero, AAXB)
           \_SB.PCI0.SBUS.DISB ()
       }
}

We Asus users also have had a pretty long BIOS field, and had because I reduced it by removing all unused parts – I removed the last sixteen lines. And this is what is am using right now:

    OperationRegion (BIOS, SystemMemory, 0xCFF8E064, 0x32)
   Field (BIOS, ByteAcc, NoLock, Preserve)
   {
       SS1,    1, 
       SS2,    1, 
       SS3,    1, 
       SS4,    1, 
               Offset (0x01), 
       IOST,   16,
               Offset (0x0A), 
       MG1B,   32, 
       MG1L,   32, 
       MG2B,   32, 
       MG2L,   32, 
               Offset (0x2C), 
       ASSB,   8, 
       AOTB,   8, 
       AAXB,   32,
   }

Still a bit long, but a lot shorter already. It would be nice of course if we could use the new code for the S1, S2, S2 and S4 state transitions as well, but this is not possible right now – fan's at full speed, and it refused to start so you are warned.

 

But the cool things is that you can also use:

    Method (_PTS, 1, NotSerialized) // Prepare To Sleep.
   {
       If (LNotEqual (Arg0, 0x05))
       {
           Store (Arg0, DBG8)

           If (Arg0)
           {
               \_SB.PCI0.LPCB.SPTS (Arg0)
           }

           Store (ASSB, WSSB)
           Store (AOTB, WOTB)
           Store (AAXB, WAXB)
           Store (Arg0, ASSB)
           Store (One, AOTB)
           Store (Zero, AAXB)
           \_SB.PCI0.SBUS.DISB ()
       }
   }

As that appears to work too, be it a little slower (YMMV) but give the cleanest variant a try first, before you start adding the new lines. And for now; This is it. This is what I have done on my free Sunday. I hope you enjoy it as much as I did. Back to work now.

 

p.s. I've seen a script to test shutdown, like a hundred times, but I can't for the life of me remember where (:

 

Happy Hacking!

Share this post


Link to post
Share on other sites

Another day... another update. DSDT V3.1 still had this code:

	Method (_PIC, 1, NotSerialized)
{
	If (Arg0)
	{
		Store (0xAA, DBG8)
	}
	Else
	{
		Store (0xAC, DBG8)
	}
}

Name (OSVR, Ones)
Method (OSFL, 0, NotSerialized)
{
	If (LNotEqual (OSVR, Ones))
	{
		Return (OSVR)
	}

	Store (One, OSVR)
	Return (OSVR)
}

Which looks like this now, after my cleanups:

	Method (_PIC, 1, NotSerialized)
{
	Store (0xAA, DBG8)
}

And because of this I also had to change this a little:

			If (OSFL ())
		{
			FindSetLeftBit (Local0, Index (PRWP, One))
		}

into another one liner:

			FindSetLeftBit (Local0, Index (PRWP, One))

Back to FireWire hacking now.

Share this post


Link to post
Share on other sites

I now removed these:

	Name (WOTB, Zero)
Name (WSSB, Zero)
Name (WAXB, Zero)

And replaced Method _PTS with this:

    Method (_PTS, 1, NotSerialized) // Prepare To Sleep.
   {
       If (LEqual (Arg0, 0x05))
       {
           Store (One, \_SB.PCI0.LPCB.AG3E)
           Store (0x07, SLPT)
           Store (One, SLPE)
       }
       Else
       {
           Store (And (Arg0, 0x0F), Local0)
           \_SB.PCI0.LPCB.SPTS ()
           Store (Arg0, ASSB)
       }

       \_SB.PCI0.SBUS.DISB ()
   }

And removed the last two lines from our BIOS Field to get this:

    Field (BIOS, ByteAcc, NoLock, Preserve)
   {
       SS1,    1, 
       SS2,    1, 
       SS3,    1, 
       SS4,    1, 
               Offset (0x01), 
       IOST,   16,
               Offset (0x0A), 
       MG1B,   32, 
       MG1L,   32, 
       MG2B,   32, 
       MG2L,   32, 
               Offset (0x2C), 
       ASSB,   8 
   }

For instant sleep and shutdown. And I am quite pleased with this change, but I haven't got the slightest clue about the mysterious ASSB... unfortunately of course. Anyone?

 

p.s. I also found some errors in my comments, which I fixed for the next update (DSDT V3.2).

 

What I do know is that storing 0x05 in ASSB initiates a shutdown. That's all for now folks. Back to work now.

Share this post


Link to post
Share on other sites
I now removed these:
	Name (WOTB, Zero)
Name (WSSB, Zero)
Name (WAXB, Zero)

And replaced Method _PTS with this:

    Method (_PTS, 1, NotSerialized) // Prepare To Sleep.
   {
       If (LEqual (Arg0, 0x05))
       {
           Store (One, \_SB.PCI0.LPCB.AG3E)
           Store (0x07, SLPT)
           Store (One, SLPE)
       }
       Else
       {
           Store (And (Arg0, 0x0F), Local0)
           \_SB.PCI0.LPCB.SPTS ()
           Store (Arg0, ASSB)
       }

       \_SB.PCI0.SBUS.DISB ()
   }

And removed the last two lines from our BIOS Field to get this:

    Field (BIOS, ByteAcc, NoLock, Preserve)
   {
       SS1,    1, 
       SS2,    1, 
       SS3,    1, 
       SS4,    1, 
               Offset (0x01), 
       IOST,   16,
               Offset (0x0A), 
       MG1B,   32, 
       MG1L,   32, 
       MG2B,   32, 
       MG2L,   32, 
               Offset (0x2C), 
       ASSB,   8 
   }

For instant sleep and shutdown. And I am quite pleased with this change, but I haven't got the slightest clue about the mysterious ASSB... unfortunately of course. Anyone?

 

p.s. I also found some errors in my comments, which I fixed for the next update (DSDT V3.2).

 

What I do know is that storing 0x05 in ASSB initiates a shutdown. That's all for now folks. Back to work now.

 

Everything up until this post compiled ok and was about to test but made these mods and get error on compile:

Users/db1/Desktop/Work_dsdt/P5K_VM_3.1+/P5K_VM_3.1+_dsdt.dsl  2888:			 \_SB.PCI0.LPCB.SPTS ()
Error	4004 -																 Too few arguments ^  (\_SB.PCI0.LPCB.SPTS requires 1)

 

P5K_VM_3.1__dsdt.dsl.zip

Did I miss something or does VM need something different?

Share this post


Link to post
Share on other sites
Everything up until this post compiled ok and was about to test but made these mods and get error on compile:

Users/db1/Desktop/Work_dsdt/P5K_VM_3.1+/P5K_VM_3.1+_dsdt.dsl  2888:			 \_SB.PCI0.LPCB.SPTS ()
Error	4004 -																 Too few arguments ^  (\_SB.PCI0.LPCB.SPTS requires 1)

 

P5K_VM_3.1__dsdt.dsl.zip

Did I miss something or does VM need something different?

Oh blimey. I forgot to mention that you need to change the argument counter of Method SPTS from 1 in 0

 

/me ducks

Share this post


Link to post
Share on other sites
Oh blimey. I forgot to mention that you need to change the argument counter of Method SPTS from 1 in 0

 

/me ducks

 

LOL, check your PM's

Share this post


Link to post
Share on other sites

Are other people here also getting different readings of lspci -xxxvvv after sleep?

 

Anyone here familiar with reggie_se? In that case, can you please read 0x3410 (see page 385 of the ICH9R datasheet) and let me know if bit-12 changes after sleep. Thanks. Err. That doesn't work like this.

Share this post


Link to post
Share on other sites

Thank you DB1. Food for thought.

 

Now. I see that your (UHCn) USB ports are already set to "Capabilities: [50] PCIe advanced features <?>". Much to my surprise of course, because here that's not the case so – are you are sure that your PC didn't sleep before your did the lspci -xxxvvv?

 

Would you mind attaching your DSDT for me?

 

p.s. I am currently documenting the changes – adding pointers to the ICH9 datasheet – which I think can be used at a later stage, so that people who are new to lspci can learn to use it, and link the register output to the(ir) datasheet.

Share this post


Link to post
Share on other sites

Hello Master Chief - (long time follower, first time ask for helper)

 

I thought that since I have an ICH10, I wouldn't need to add the SBUS device to my DSDT but I still get the

 

"** AppleSMBusPCI::start failed to get acpi path for provider" error on boot.

 

Does that mean that I do in fact need that device in my DSDT and if so what exactly needs to be added?

 

Here is what lspci says.

 

00:1f.3 SMBus [0c05]: Intel Corporation 82801JI (ICH10 Family) SMBus Controller [8086:3a30]

 

Regards,

danm

Share this post


Link to post
Share on other sites
Hello Master Chief - (long time follower, first time ask for helper)

 

I thought that since I have an ICH10, I wouldn't need to add the SBUS device to my DSDT but I still get the

 

"** AppleSMBusPCI::start failed to get acpi path for provider" error on boot.

 

Does that mean that I do in fact need that device in my DSDT and if so what exactly needs to be added?

 

Here is what lspci says.

 

00:1f.3 SMBus [0c05]: Intel Corporation 82801JI (ICH10 Family) SMBus Controller [8086:3a30]

 

Regards,

danm

It tried to read a property called acpi-path but failed to locate it, which is normally something like: IOACPIPlane:/_SB/PCI0@0/SBUS@1f0003

 

And you might have a Device (SBUS) but with a different name. Search for: Name (_ADR, 0x001F0003) and if you find it, then change the name into SBUS and fix all callers. Just search for the old name.

 

If not, add it. Read this thread and look at the attachments (DSDT's) in post #3.

 

Oh, and please use: lspci -d 8086:2930 -xxxvvv next time, because that tells me a lot more.

 

Good luck!

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.

×