Jump to content

Show PCIe cards in System Information.app


17 posts in this topic

Recommended Posts

I know this is mostly cosmetic, but I would like to see my PCIe cards in System Information.  I get the error, "There was an error while gathering PCI device information."  Is there any way to manage this?  Perhaps something with Clover's SMBIOS Slots feature?

According to the Clover wiki, I have inserted the below to config.plist SMBIOS.  I have not touched the DSDT; instead I am trying with FixDisplay.  But then what number should be used for the ID, since I do not know the SUN number?  Currently I am sill getting the error when viewing System Information.

		<key>Slots</key>
		<array>
			<dict>
				<key>Device</key>
				<string>NVidia</string>
				<key>ID</key>
				<integer>1</integer>
				<key>Name</key>
				<string>GPU</string>
				<key>Type</key>
				<integer>16</integer>
			</dict>
		</array>

By the way, I did try manually editing the DSDT, but could not get it to compile.  This is what my display device looks like after adding the one line, as described in the wiki.  I don't think it makes sense to have two names for one device?

Device (H000)
                {
                    Name (_ADR, 0x00)  // _ADR: Address
                    Name (_SUN, 0x02)  // this is the line I added
                    Method (_SUN, 0, NotSerialized)  // _SUN: Slot User Number
                    {
                        Return (SNUM ())
                    }
                }

The _SUN name can indeed declare the used slot. But here you already have a _SUN Method. To me, it's either-or but not both at the same time...

 

I would suggest you use a _DSM method instead. For your nVidia card, you would 1st need to confirm the exact device name and address in IOReg, then declare something like this in DSDT at the identified location:

                Device (<your identified device>)
                {
                    Name (_ADR, Zero)
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package ()
                            {
                                "AAPL,slot-name", 
                                "PCIe x16", 
                                [...]
                                [...]
                                [...]
                            }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }
                }

There are other ways to declare _DSM info, that's just an example.

 

Can you post your IOReg + DSDT and hardware description of your system? If you have a desktop with multiple PCIe x16 slots, identify the slot physically used on your mobo and you can then replace "PCIe x16" by, say, "PCIe x16 #n" where n is your identified slot number. As you said, it's all just cosmetic.

 

Here's a sample of info I display on my old Dell Precision 670 workstation with such DSDT edits.

post-851564-0-98888400-1470389708_thumb.jpg

Full details of the DSDT edits are found here.

  • Like 1

Can you post your IOReg + DSDT and hardware description of your system?

 

Thanks.  Here is output from IOJones and MaciASL.  Hardware description in my signature.

Slot 1: EVGA Titan Black

Slot 4: Blackmagic DeckLink Duo

Slot 5: Atto H680

 

It sounds like you are confirming a DSDT edit is necessary, and the FixDisplay option won't help in this case.

 

In IOJones, I searched for 'display' and found the result at AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/BR3A@3/IOPP/H000@0/NVDA,Display-C@2.  So I'm working in MaciASL under DSDT/_SB/PCI0/BR3A/H000.  I think I'm doing this right so far, but I've never made any DSDT patches before.  This is what I'm trying, but it has one compile error: "Object does not exist (DTGP)".  I can see there is no DTGP method in the entire code, but I don't know where to create one and what to put in it.

Device (H000)
{
	Name (_ADR, 0x00)  // _ADR: Address
	Method (_DSM, 4, NotSerialized)  // Device Specific Method
	{
		Store (Package ()
		{
			"AAPL,slot-name",
			"PCIe x16"
		}, Local0)
		DTGP (Arg0, Arg1, Arg2, RefOf (Local0))
		Return (Local0)
	}
}

If you couldn't tell already, I have no experience with ACPI code.  I have some background in Java and PHP, but I can't find any basic tutorials on ACPI.  The 700 page spec is a bit intimidating.

origin.zip

Hackintosh.zip

If you visit the Precision 670 guide I linked to above (where all my DSDT patches are detailed), you'll find the code for the DTGP method that you can copy to paste in your own DSDT. I suggest you paste it, say, before your _PTS or _WAK method.


Try the attached patched DSDT. If it works Ok, we can then add the info about LAN, audio, etc.

DSDT.zip

 

NB: I've renamed your BR3A.H000 device to BRA3.GFX0 for easier identification. Of course, this would undoubtedly be irrelevant if you moved your card to a different PCIe x16 slot.

Cool, I think I'm making some progress.  I inserted the DTGP method, and got it to compile.

It looks like the H000 device is calling the DTGP method with 5 arguments, but what are they?  I don't see where those variables are defined.  And inside the DTGP method, it only uses 4 out of 5, that's weird.

 

With the patch, I still see the PCI Devices error in system profiler.  Then I tried your DSDT instead, same problem.

Made further edits for your SDI and SAS cards:

  • ATTO ExpressSAS H680 card attached to device BR2A.H000 and defined there under renamed device BR2A.SAS
  • Blackmagic dual-SDI card attached to RP01 and defined under new device RP01.SDI

DSDT_2.zip


With the patch, I still see the PCI Devices error in system profiler.  Then I tried your DSDT instead, same problem.

Can you post a screenshot of your SysProfiler?

Thanks for your help.  Still have the same problem with the new patch.  I had this problem for years on my real Mac Pro, because there's an "unsupported" GPU installed.  (several different models of Nvidia cards.)  By the way, this is what it looks like in the command-line system_profiler.

$ system_profiler SPPCIDataType
2016-08-05 11:42:52.646 system_profiler[565:6084] -[__NSCFString bytes]: unrecognized selector sent to instance 0x7fe74be80420
2016-08-05 11:42:52.646 system_profiler[565:6084] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFString bytes]: unrecognized selector sent to instance 0x7fe74be80420'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff97f0403c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff8b6c876e objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff97f070ad -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
	3   CoreFoundation                      0x00007fff97e4ce24 ___forwarding___ + 1028
	4   CoreFoundation                      0x00007fff97e4c998 _CF_forwarding_prep_0 + 120
	5   SPPCIReporter                       0x000000010cfb01e0 SPPCIReporter + 12768
	6   SPSupport                           0x000000010ce1e332 -[SPDocument _reportFromBundlesForDataType:] + 426
	7   SPSupport                           0x000000010ce1ea47 -[SPDocument reportForDataType:] + 180
	8   SPSupport                           0x000000010ce1ed01 __34-[SPDocument reportsForDataTypes:]_block_invoke + 68
	9   libdispatch.dylib                   0x00007fff8ceff004 _dispatch_client_callout2 + 8
	10  libdispatch.dylib                   0x00007fff8cf02c7b _dispatch_apply_serial + 42
	11  libdispatch.dylib                   0x00007fff8ceeee73 _dispatch_client_callout + 8
	12  libdispatch.dylib                   0x00007fff8cefdee9 _dispatch_sync_f_invoke + 39
	13  libdispatch.dylib                   0x00007fff8cefec20 dispatch_apply_f + 290
	14  SPSupport                           0x000000010ce1eb55 -[SPDocument reportsForDataTypes:] + 234
	15  SPSupport                           0x000000010ce21d66 -[SPDocument xmlPropertyListRepresentationForDataTypes:] + 27
	16  system_profiler                     0x000000010ce0c865 system_profiler + 18533
	17  system_profiler                     0x000000010ce0ca6c system_profiler + 19052
	18  libdispatch.dylib                   0x00007fff8cef2700 _dispatch_call_block_and_release + 12
	19  libdispatch.dylib                   0x00007fff8ceeee73 _dispatch_client_callout + 8
	20  libdispatch.dylib                   0x00007fff8cef25cd _dispatch_queue_drain + 1100
	21  libdispatch.dylib                   0x00007fff8cef2030 _dispatch_queue_invoke + 202
	22  libdispatch.dylib                   0x00007fff8cef1bef _dispatch_root_queue_drain + 463
	23  libdispatch.dylib                   0x00007fff8cef1a1c _dispatch_worker_thread3 + 91
	24  libsystem_pthread.dylib             0x00007fff8e762a9d _pthread_wqthread + 729
	25  libsystem_pthread.dylib             0x00007fff8e7603dd start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
2016-08-05 11:42:52.891 system_profiler[564:6076] Non-zero termination status from '/usr/sbin/system_profiler -nospawn -xml SPPCIDataType -detailLevel full', termination status: 6

post-1122323-0-92476500-1470422734_thumb.png

Ok, so it's probably not DSDT related. If you look at your Graphics/Displays info, you'll see that the slot now shows "PCIe x16 Slot1", so DSDT patches are Ok.

 

I also noticed you appear to use VoodooTSCSync kext on that Broadwell machine. Was that a necessary step? Post your complete EFI folder, I'll have a look at kext, SMBIOS and general Config.plist.

Okay.  I'll keep researching to see if I can find a solution.  The Clover documentation about the Slots feature is incomplete, so maybe I'll open a ticket at sourceforge when I get back from vacation. (I'm about to leave.)

 

Yes I think VoodooTSCSync was necessary.  I posted a guide a few days ago, documenting what I did and what works.

http://www.insanelymac.com/forum/topic/313858-guide-working-x99-system-with-6950x/

You can see my EFI folder here: https://drive.google.com/open?id=0B52QuT8oHvtZeDIxQWJsWFpkdVU

What's that patch you have in your Config.plist for the IOPCIFamily kext?

Find: 4881F901000040
Replace: 4881F901000080

`

I'm also surprised you have Generate P states and Generate C states activated for the CPU; that only applies to C2D/C2Q/1st gen Core "i" CPUs. Your Broadwell would normally require to generate a SSDT through Pike R Alpha's generator script, place it in EFI/ACPI/patched folder alongside your patched DSDT and then activate Drop SSDT (Drop OEM) in the Config.plist. I guess that, right now, you're running without CPU power management, i.e. sometimes at LFM and most of the time at HFM with no Turbo boost at all.

 

I also noticed the MacPro5,1 SMBIOS. That's very old generation (Westmere CPUs pre-date SandyBridge) compared to your Broadwell system; you'd probably be better using MacPro6,1 profile instead.

That patch is necessary to boot with this chip. Brumbaer explains it here: http://www.insanelymac.com/forum/topic/312245-5960x-successfully-installed-under-el-capitan-10113/?do=findComment&comment=2239116

 

The P and C states generation was default in my clover install, and I never tried disabling them.

 

Currently I have only one P-state (40), which I overclocked to 42. I previously tried Pike's SSDT script, but it didn't help. I could try it again with the Drop OEM option, but I think a better solution is XCPM, which Pike recently discovered on Sierra. I'm hoping someone can teach me how to port it to Yosemite.

 

When I tried Mac Pro 6,1, I couldn't get any image on the monitor, just black; although the system was otherwise functional, and I could connect remotely with Screen Sharing. Do you think there's any benefit to the newer 6,1 SMBIOS? If so, I can look into fixing it.

  • 4 months later...
  • 8 months later...
  • 1 year later...
×
×
  • Create New...