Using a Presonus Quantum Thunderbolt 2 Audio Interface...HELP

[shatterhenner]

Thanks again to all guys involved for contributing in here. Im glad that MyTosh have now approved the fix and we see a second vrs8 working. We need a different approach on the x299 Boards, no news so far. Same problem with the memory mapping. We need to drop DMAR tables, if not the machine is simply not booting anymore. We are still on it....

The driver for the cheesegrater macpro´s is probably affected with the same issues, i can smell it ;-) Its still not released yet...maybe if the developers are fixing it in a newer driver release, we all get it to work...who knows?!

Fact is, its connected on hardware that is over 10 Years old (pcie card) an the whole world knows the issues with the sound cards containing these via chipsets, so we are basically slab a dead horse here!!!!

 

[Mixerjack]

Your IOREG.txt and Kextstats.txt files appear to be .rtf files. If you use TextEdit.app, remember to use the "Make Plain Text" command in the Format menu.

For ioreg, please use the command described in #47 (so all the properties are extracted and the width is not truncated - because I can't see the id of the device that is connected to Thunderbolt)

ioreg -lw0 > ioreg.txt

For kextstat, include everything so we can see the status of the entire set of loaded kernel extensions

kextstat > kextstat.txt

Like so?

 

[joevt]

Like so?

Better.

kextstat shows the com.presonus.pae-quantum driver is loaded.

ioreg shows the Quantum device "pci1c67,101" connected to Thunderbolt. This matches the first personality "Quantum1" of the quantum_driver.kext.

But we don't have a log message showing an error for why the driver doesn't attach to the device.

Check console app for related log files?

Is the device turned on and connected before boot?

I think there should be a "InitLogging" message in the boot log.

Can you "sudo kextunload /System/Library/Extensions/quantum_driver.kext"? Note the time, then "sudo kextutil" to load the extension. Then get a log (set the start time and end time) or check console.app.

 

[Mixerjack]

Great, I will pull up console today and have a look. Am I looking for files that contain the pci id and/or than contain the word quantum?

Device is plugged in and switched on before machine is powered up yes.

Shall I run another boot log?

 

[Mixerjack]

Better.

kextstat shows the com.presonus.pae-quantum driver is loaded.

ioreg shows the Quantum device "pci1c67,101" connected to Thunderbolt. This matches the first personality "Quantum1" of the quantum_driver.kext.

But we don't have a log message showing an error for why the driver doesn't attach to the device.

Check console app for related log files?

Is the device turned on and connected before boot?

I think there should be a "InitLogging" message in the boot log.

Can you "sudo kextunload /System/Library/Extensions/quantum_driver.kext"? Note the time, then "sudo kextutil" to load the extension. Then get a log (set the start time and end time) or check console.app.

the kext unload command in terminal gave me this

Can't open CFBundle for /System/Library/Extensions/quantum_driver.kext.

Can't create /System/Library/Extensions/quantum_driver.kext.

Console app. Can't see anything presonus related in log files. But i obviously could be missing something here. Search returns nothing and I'm looking in all sub folders of L/Logs var/logs etc...

 

[joevt]

The quantum_driver.kext has a lot of logging code in it (use the "strings quantum_driver.kext/Contents/MacOS/quantum_driver" command to see all of the possible messages and other stuff) but I don't know where the log goes.

You can try doing another boot log, but if it doesn't contain a log message from those listed by the strings command, then it's useless. The error I'm expecting to see that is similar to the error from the VRS8 driver is "IOBufferMemoryDescriptor::inTaskWithPhysicalMask failed" from the "TLSTATUS torilogic:maBuffer::Allocate(uint64_t, uint64_t)" method. Actually, that might not be the problem because it doesn't appear to be using the kIOMemoryPhysicallyContiguous option.

Maybe you can tell their tech support that the driver loads (as seen in "kextstat") but doesn't attach to the device (as seen in IORegistryExplorer.app), and that you would like to know how to see the driver log messages to find out why (since the driver log messages don't seem to appear in the system log in Console.app or with the "log show" command).

The driver doesn't have a probe routine. It has an init routine that doesn't do much. The start routine is interesting. It looks for a "IOPCITunnelled" property. If it's not found then the "virtual bool com_presonus_quantum_driver_Device::start(IOService *)" routine will log a "no thunderbolt" message (to whatever the unknown logging system is). You should tell their tech support to fix their driver so it doesn't look for Thunderbolt related properties such as "IOPCITunnelled" if it doesn't affect the functioning of the device.

Maybe edit the info.plist of the quantum_driver.kext so the Quantum1 personality includes the following two lines:

            <key>IOPCITunnelled</key>
            <true/>

Update the kext cache. Reboot. See if it works. Dump a new ioreg to see if the IOPCITunnelled property was added and to show if the driver gets attached.

 

[joevt]

Can't open CFBundle for /System/Library/Extensions/quantum_driver.kext

Is the kernel extension at /Library/Extensions/quantum_driver.kext ? Enter the correct path.

 

[Mixerjack]

Joe VT....

I don't know who you are, or what you do for a living.... But I really cannot thank you enough...

I can confirm the Presonus Quantum now works with my i9 7940 Hackintosh. That line of code in the driver fixed it... You fixed it.

I was really ready to move to windows, or seriously consider the new Mac Pro due out this year. Thanks to you I don't have to consider either of those options.

If you ever need anything remotely musical (I am a record producer/mix engineer) please don't hesitate to ask! Just PM me.

 

[joevt]

I can confirm the Presonus Quantum now works with my i9 7940 Hackintosh. That line of code in the driver fixed it... You fixed it.

That's great. I'm still curious about their logging system but I guess it doesn't matter now.

Back to the VRS8 problem.

I tried creating a AppleACPIPlatformExpert override but it seems to cause a crash even if the overridden methods (init, probe, start) don't do anything but call the super (AppleACPIPlatformExpert).

Then I tried creating a standalone kext similar in positioning to AppleEFIRuntime, but it is unable to allocate the 192K in the first 256 MB (28 address bits) of memory. It is able to allocate all the other physically contiguous buffers that are not address space limited. I should try smaller buffers (down to a single 4K page) in the 256 MB space to see if anything can be allocated there.

Also of note is the AppleVTD driver which is the IOMapper for Macs that use VT-d. I think this reads the DMAR ACPI table. Source code is at https://opensource.apple.com/source/IOPCIFamily

I was thinking it might be possible to alter the driver so it uses a full 32 bit address space, but the datasheet I found for VT1712 shows why the driver limits the DMA buffer to the first 256 MB of memory. The chip has some registers that are only 28 bit (bits 27:0 or 27:2) and has a statement in the description of some registers that says "up to 256 MB address space supported" and "Address space beyond 256MB is not supported".

There is a message in the boot log that says something like "Available physical space from 0x16bad000 to 0x89efff000" (this message might be kprintf only and therefore require a serial port or FireWire kprintf to see). Those addresses are outside the 28 bits. The message is part of the xnu kernel, so it might help to build your own kernel to see what that message means - if it truly means that no physical allocations can be made outside that range.

Some research into macOS memory and virtual memory is required:

Memory and Virtual Memory

Essential information for programming in the OS X kernel. Includes a high-level overview.

developer.apple.com

There is a boot_args parameter passed from EFI to the Apple kernel that has a MemoryMap which is an array of EfiMemoryRange (or EFI_MEMORY_DESCRIPTOR in EFI) that describes the virtual and physical ranges used in EFI. I think AptioMemoryFix might affect this table? There is also a slide value in boot_args which moves the kernel. These are are discussed at

AptioMemoryFix

I thought it was worth making a separate thread for our AptioFix discussions.Some links to relevant posts (suggest us gather stuff here):1. Information about APTIO V nvram bugs2. Z97 NvramSmi code & boot.efi memory move code3. KASLR slide calculation & usage 4. Slide calculation formula 5...

www.insanelymac.com

There is a MemoryMap command in EFI Shell. I suppose the results of that compared with the MemoryMap seen by the kernel might be interesting.

 

[Slaughter]

Joe VT....

I don't know who you are, or what you do for a living.... But I really cannot thank you enough...

I can confirm the Presonus Quantum now works with my i9 7940 Hackintosh. That line of code in the driver fixed it... You fixed it.

Wow.... this is good news.

Ok, so - which os and audio software are you running, @Mixerjack? Is it safe for me to consider this progress to be an effective solution to PreSonus connectivity with a prospective hackintosh build, running Mojave - with Pro Tools?