Jump to content

Stabi

Members
  • Content count

    28
  • Joined

  • Last visited

About Stabi

  • Rank
    InsanelyMac Protégé
  1. Stabi

    Slow POST due to APFS?

    No, I haven't. Manually adding entries to clover and turning off scanning did not help. It is sometimes not super slow currently, though. Just slow. I should maybe get a stopwatch and measure it some time. But I don't reboot often right now.
  2. Stabi

    Slow POST due to APFS?

    That is normal behaviour for apfs.efi. That is why back when we relied on it instead of using APFSDriverLoader, there were patched versions that suppress these debug messages.
  3. Stabi

    Slow POST due to APFS?

    @thread: I have been rather busy in the last days and hence haven't had time to add custom entries and turn off scanning. I don't know if I am imagining it, but it does seem POSTing and/or loading Clover is a bit faster now, even though I didn’t do anything. So probably just a figment of my imagination. @denny76: I don't think that is the issue. For one, it is not the actual boot process of macOS that is slow, but the time my system needs to arrive at the Clover screen. For another, I don't patch anything for trim, or have "trimforce enable" set, because the only SATA SSD in my system is for Windows. NVMe disks always have trim enabled. Edit: I am re-attaching an up-to-date output of RunMe.app. The last one might've been a bit weird in places due to me wrestling with AGDP and my Z27q. Everything is now back to normal though. Even though I doubt that there'll be meaningful differences in this dump. Send me Styx.zip
  4. Stabi

    Slow POST due to APFS?

    That was one of the first things I tried too, but it did not make a difference. I just gave it a whirl again. But it did not make a difference. Yes, I booted from my TimeMachine's backup EFI for the dump. That's because I am currently tinkering with my "real" EFI. I just acquired a 5k monitor, but OS X would only recognise it as two monitors. Had to switch to a MacPro6,1 SMBIOS and remove WEG to get it to work, which is less ideal. But that is for another thread. Would it maybe be worth trying to deactivate auto-scanning for boot entries and only have manually set up ones?
  5. Stabi

    Slow POST due to APFS?

    Sure, here it is. Send me.box.zip
  6. Hey forum, Since upgrading to Mojave, I am facing a strange issue and I am not sure if I narrowed it down correctly: My computer needs very long to POST and load Clover. I am booting from an NVMe disk and I can tell from the wild LED blinking on my PCIe to M2 adapter that it is reading furiously. Without that disk, POST is very quick. As this didn’t happen with High Sierra, I am thinking it must have to do with APFS and apfsdriverloader.efi (I used HFS+ before). My second computer, which is nearly identical does not have this issue, but it is booting from SATA. Is there anything I can do to troubleshoot this further or resolve it right away? Has anybody else had this issue? I currently use the following EFI drivers: Thanks. Stabi
  7. Stabi

    WhatEverGreen Support Topic

    Oh my that would be great if that did the trick! For the record, I too am using a RX 560, a "high-speed" HDMI cable (I understand why vendors don't wanna put version numbers on cables but giving them such names is really confusing to more tech-savvy people) and a very similar monitor (LG 27MU67-B, which has that menu option too). Will give this a try.
  8. Stabi

    WhatEverGreen Support Topic

    I have a question about HDMI 2.0: Are the fixes for this only applicable to iGPUs, or do they also work for AMD cards? Or in other words: Can one activate HDMI 2.0 for Polaris cards somehow?
  9. Stabi

    macOS 10.13.2 Update is out

    Yes, all (?, most?) of these modifiers of the AMD9xxxControllers can be put in DSM methods within your GFX0 device in your DSDT or a SSDT. An example are the various SSDTs which are implementing the wakeup fix (what Clover's RadeonDeinit does) or the sample SSDT which vandroiy2012 linked to some pages ago: https://github.com/vit9696/WhateverGreen/blob/master/Manual/Sample.dsl
  10. Stabi

    AppleALC — dynamic AppleHDA patching

    That's because I am using my DSDT to inject the layout-id. So that wasn't the issue. If I look at the HDEF resource in IOreg I can also clearly see that the layout-id was "B" (or now again "1"), so that worked. The issue must've lain elsewhere.
  11. Stabi

    AppleALC — dynamic AppleHDA patching

    That didn't help. However, the problem went away, came back, then went away again. Before it came back, I deactivated Fast Boot in the UEFI, but really only because I noticed that the board skipped giving out POST codes via the speaker with it enabled (and I like the calming "beep"). Is this just coincidence or might this influence how the motherboard initialises the codec? I have no idea about such things. In any case, I have installed the new version of the kext now and reverted back to layout 1. So far so good. We'll see if it persists.
  12. Hi community, I had a pretty well-working system up until yesterday, when all of a sudden sleep stopped working. Now instead, my monitor goes to sleep and OS X stays on happily ever running. The only person not so content is I, 'cause I've got no clue where to look. I did not change my hardware, nor my clover config, nor the DSDT that I am loading. The syslog shows nothing exact for the random errors and general verboseness of certain (non system) processes. The one thing that did change yesterday is that I upgraded my secondary, non-productive installation to the El Cap GM. But that is on a separate drive and should therefore not interfere with my productive system at all. Any ideas where I could start looking? So far, I only learned that kextd seems to update the kernel cache for other OS X installations it finds in /Volumes/, too. Neat, but nothing that really helps me. For reference, my config.plist is at: http://pastebin.com/zTwCXzpC And I attached the DSDT I load at boot. I do not now what to make of my syslog (http://pastebin.com/LjLZfj17). I sent it to sleep, right after you see the log part about TimeMachine, then pressed the power button again ca. 1 minute later because the system didn't go to sleep. The bluetooth, WiFi and Airport deamons seem to acknowledge that the system is supposed to switch to S3 mode, but nothing happens. I'd be grateful for any ideas. DSDT.aml.zip
  13. Stabi

    Wakeup Issues

    This didn't help either, unfortunately. Any further ideas? I attached logs once again. But they seem empty to me. syslogs.zip panics.zip
  14. Stabi

    Wakeup Issues

    Thanks again. I will try your DSDT. Concerning the SSDT, I looked into the ones that clover dumped and identified the ones that contain some non CPU related stuff. In my case, they are SSDT-5 and 6, which have some definitions for PCI and SATA. I just put them into EFI/CLOVER/ACPI/patched and have clover load them up. That should result in the same result as dropping only CPU-related tables. And no, my reboots do not occur during use. I wasn't clear there. I meant that it is completely random if my computer wakes up or not. It can wake up correctly 10 times in a row, only to then crash twice in a row the next time. I have had many days where all was fine and some sequences of days where I have 2-3 crashes a day. Lastly, what makes you think I have hibernation turned on? $ pmset -g Active Profiles: AC Power -1* Currently in use: standby 1 Sleep On Power Button 1 womp 0 autorestart 0 hibernatefile /var/vm/sleepimage darkwakes 0 networkoversleep 0 disksleep 10 sleep 15 (sleep prevented by coreaudiod, iTunes) autopoweroffdelay 14400 hibernatemode 0 autopoweroff 1 ttyskeepawake 1 displaysleep 10 standbydelay 10800
  15. Stabi

    Wakeup Issues

    Hi Lex, thanks for the link to RehabMan's branch. I see it has a slightly lower version number (1.3 vs 1.5), but its bundled IASL works a lot better and there's even still an icon for the compile button (the little things ;])! That autosave feature was indeed annoying, also. So we're pretty good on that front. I will drop the OEM SSDT, no prob. Just for my understanding though: I thought that doing that is unnecessary if one drops individual CPU related tables of it. Then again, I don't really know what a standard SSDT contains except for infos about one's CPU. When it comes to my crashes yesterday: I was unfortunately quite busy yesterday and didn't really spend much time on them because of that. The second one was weird though because the screen stayed blank and I had to boot in safe mode and repair the kernel cache afterwards. I dug into the archived logs at /var/log/ and didn't find much (except for a SIMBL plugin running amok, which was nice enough to find and solve I guess). I'll attach the panic report and that part of the log. I can unfortunately not find the first panic anymore, which is weird. But maybe my memory is just blurry. Bottom line: I will do what you suggested, leave these logs in case there's something in them I missed, monitor it some more and come back with more logs when more problems occur. Thank you for your patient help, btw. - Stabi syslog_snippet.txt Kernel_2015-04-28-160000_Hades.panic.txt
×