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

[shatterhenner]

hi @luckyal, can you please upload your clover config and an IOReg with connected vrs8. that would help us to examine the issue in detail. thanks in advance!!!

 

[luckyal]

@shatterhenner go ahead and post your IOReg and Config and I'll take a look. Seems more fitting since you're the ones having issues.

 

[shatterhenner]

Luckyal, my device is at his home. we are testing for months now and working as a team and he is one of the best hackintosh experts around, so sending my config and ioreg is really pointless. where is the problem at your side? i can't get it? do ya have something to hide? we think its not done with a simple dv-t bios setting, so there must be more behind that...

btw the files from our testing rig are already posted...again, where is your problem?

we know several people waiting for a proper solution to fix the drive issue, and you are the one where it "might be working"
there is still a lack of proof from your side

 

[luckyal]

Luckyal, my device is at his home. we are testing for months now and working as a team and he is one of the best hackintosh experts around

For months? Wow! It took me about that long to solve my problem - keep in mind, I have a completely different

we know several people waiting for a proper solution to fix the drive issue, and you are the one where it "might be working"

I understand - I think joevt is probably the most qualified to help. I honestly don't think it's a config.plist issue at all. Based on the output @VRS8User, an experienced hackintosher himself, posted it appears that joevt has already identified the problem.

there is still a lack of proof from your side

See Post #91

To sidestep all of this - can you post a screenshot of your Boot page in BIOS? Also is your onboard Audio enabled or disabled in BIOS?

 

[luckyal]

@luckyal you should read correctly... I didnt say that the issue is related to Config.plist. I asked you to upload your EFI/ioreg/log with a cold booted rig and an working vrs8 for Debugging.

But it seems that you think its better to hold of things that could help others if analyzed correctly...

Bravour!!!
@tonymacx86
Give this Guy a medal of honor

Read Post #102

 

[joevt]

I don't think the solution of enabling VT-d, removing dart=0, and/or not dropping DMAR table is the best solution for this problem. There are probably good reasons why most Hackintosh build guides tell you to do those things (not just because USB doesn't work, the computer won't boot, or mounting the EFI partition causes a crash). Fixing those problems may prove more difficult than fixing the problem of the VRS8 driver.

To fix the VRS8 driver, you need to know why it fails in the first place. The failure messages in the logs can be found in the VRS8 driver code. You can do two-machine kernel debugging (with Ethernet or FireWire or serial), set a breakpoint, and discover the parameters being passed to the routines that are failing. One parameter you need to know is how much memory is being requested.

The next thing you'll want to know is why that memory cannot be allocated. All the code is at opensource.apple.com. You'll probably want to write a function that finds all the free spaces in physical memory and calculates their sizes. Then see how those sizes compare with the amount of memory being requested.

To aide in debugging, you might want to build your own kernel (I haven't tried this recently). But before doing that, you could try the debug or development kernel in the "Kernel Debug Kit" which can be downloaded from Xcode (get the one that matches your macOS version and build).

Once you know how much memory is required, You'll want to create a method to reserve that memory. Maybe a Lilu plugin can do that early enough using LiluFriend. If that works, then you can do one of two things:
A) Move the VRS8 kext from /S/L/E or /L/E to somewhere else. After booting, force your memory reserving kext to unload. Then load the VRS8 driver kext.
B) Add code to the plugin that patches the VRS8 driver to call a routine that releases the memory so that the VRS8 driver can use it.

Both of those options requires that no memory in the reserved range is reserved by something else in the time between when the memory is released and the VRS8 driver requests it. In that case, maybe there's a way for the Lilu plugin to pass the reserved memory to the VRS8 driver without releasing it.

If the Lilu plugin cannot reserve memory early enough, then maybe it can be done in your custom built kernel. But that's not a good long term solution, so maybe you can do it in a custom build of Clover, but that's not a good long term solution either, so you'll want to do it in an EFI driver. You'll need your Lilu plugin to take that memory and pass it to the VRS8 driver. The EFI code could create a device property with the address of the reserved memory.

The work I have done so far includes a Hopper Disassembler v4.app file for the VRS8 driver and a dump of all the vtables and structs in the dwarf files included in the Kernel Debug Kits. I am missing a method of converting the dumps into types that Hopper can import to make the disassembly easier. Hopper can use C type header files, so I guess I just need to modify my dwarf dumper to produce output that looks more like C.

 

[joevt]

I did some work in Hopper. The disassembly is easier to read if you fix up the procedure parameters (the signature). Hopper isn't smart enough to do that automatically using the demangled names. It also isn't smart enough to include the "this" parameter for functions included in a vtable. And the decompiler seems to ignore procedure parameters given to external procedures, which may cause it to misidentify dead code, so you'll want to decompile without the "Remove potentially dead code" option. The Hopper python script api doesn't have methods for modifying a procedure's signature or parameters, so it has to be done manually using the UI.

The VRS8 driver wants to allocate the following physically contiguous spaces:
"VRS inputs 1-8" 192K in the first 256MB of memory on a page boundary.
"VRS8 outputs 1-2" 32K anywhere on a 4K page boundary.
"VRS8 outputs 3-8" 96K anywhere on a 4K page boundary.

The first one is most problematic, because it is the largest and because it needs to be within the first 256 MB of memory. So you just need to figure out a way to get that memory for the driver (by getting it before other drivers fragment the memory space, or by fixing dart).

 

[MyTosh]

I just wanna thank you guys for trying to figure this one out and being willing to share the outcome. I'm not specialized enough to help but I'll be able to tell if it works on my z390 system.

I find it interesting that those K numbers are the same than khz numbers. As in if you record at 32k, 44k, 48k, 96khz or 192k kHz.

 

[luckyal]

I find it interesting that those K numbers are the same than khz numbers. As in if you record at 32k, 44k, 48k, 96khz or 192k kHz.

I don't think you have the option to record in 32k. 44.1 and up. I'm surprised you haven't been able to employ the same exact method to get yours going. @shatterhenner has a x299 system, which are a different animal altogether, but you and I are not far apart. Do you have Thunderbolt running or did you decide on the PCIe/HDMI method?

The other issue you have is that Z390 doesn't have NVRAM support. That may have something to do with it.

 

[shatterhenner]

Thx again for your contribution @joevt
highly appreciated, thats quite usable information...