viking1304

I just noticed that article New driver for Realtek PCIe card readers! have completely different links on home page and on articles page forums/forum/201-articles/ When you try to open it from the homepage it opens articles/articles/new-driver-for-realtek-pcie-card-readers-r37/ but from other pages it opens forums/topic/16087-new-driver-for-realtek-pcie-card-readers/ Links that are not on homepage have different display style and also some additional attributes as data-ipshover-target and id. All links are intentionally shorten in order not to be rendered as preview.

@Hervé as you can see in attached screenshots, there is an error 500 in console and network (in Brave and Safari). Since that is an internal server error I can't help you more than this. I just noticed one thing when I am not logged in and page works (last screenshot). There is an additional line in console: "Service worker installed". Address is "index.php?app=core&module=system&controller=serviceworker&v=77d9e467eb1638513812&type=front". I am not sure if it helps. btw. I always have at least 5 browsers (Safari, Brave, Chrome, Edge, Firefox) on every computer that I have, since I constantly test my websites (I am a web developer). I am mostly using private/incognito for testing in order to avoid any caching issues.

As Jake wrote, as soon as I log out, article appears.

Everything works great, but for some strange reason if I try to open any article on homepage I am always getting this error: Sorry, there is a problem Something went wrong. Please try again. I can't access any of those links:

I am aware that you replaced old VoodooPS2Controller-Alps.kext with that one and indeed it works much better. Unfortunately I noticed random zoom-ins of web pages while I am scrolling with two fingers, so I already submitted this ticket.

@Hervé I was talking about SSDT-7450.aml from E7450 OC 0.7.5 that Jake posted. Most important thing is that installation went fine and that macOS works. I was just curious what he actually put inside. Since I wasn't here for a last few years I forgot some things. Thank you very much for reming me. Everything is clear now. @Jake Lo I already tried DP method and it works fine. I will also try this method soon. Thank you very much . Not just for this answer, but also for the OC package and config. The only real issue that I have is that trackpad is little hectic, but that is not related to your package or config. I will submit an issue report as soon as I figure out how to find ALPS HW version.

Since a lot of things have changed in last few years, I had to read a lot in order to catch up. Installation wasn't difficult, thanks to @Jake Lo. Almost everything works fine, but I have to ask a few questions. 1. What exactly is in SSDT-E7450.aml? I will decompile it for sure when I find some time, but quick info would be appreciated. 2. Do I need to change anything related to ACPI, since I am on latest (A24) BIOS? 3. What is the best way to disable NVidia GeForce 840M with OC? I guess DeviceProperties method.

After almost 3 years I am (at least temporary) back. Most pleasant surprise that I noticed so far is Intel WiFi support. I am currently preparing initial installation of Monterey for my old E7450 with OC. See you in Dell section soon.

I just got MacBook Pro and I will give my Dell E7450 away in few days, which means that this great journey came to it's end. It was a pleasure being here, and I am grateful for everything I have learnt. I also hope that I helped someone. Thank you all for great support!

Go to https://www.tp-link.com/us/download/TL-WN823N.html#Driver Download TL-WN823N(UN)_V3_Mac os x 10.14_Beta Plug device into any USB port and run Install.pkg Easy as that.

For iMessage / Facetime problems check this thread:

@Darius1984 there is no need to change anything in kext that works in High Sierra to make it work in Mojave. 1. You need to change USBCOMP mode to 6, 8 or 14 to make it work in MacOS. If you are using dual boot with Windows use USBCOMP 14. I did that from persistent Ubuntu USB using perl script. 2. Since I saw in another thread that you have same card as me, you can use this kext vkgLegacySierraQMI.kext.zip 3. Be sure that your system can access your card properly. I had problems with this in the beginning. Check USB / USB Device Tree and Network / WWAN in System Information. You can use AT commands from your terminal like this.

Since I was getting RAW values with VirtualSMC and didn't with FakeSMC I jumped to conclusion that you are using FakeSMC. Are you just replacing AML files in patched folder and config or you also replacing some kexts when switching from hot-patched to static config?

You don't see those values because you are using FakeSMC.kext and ACPIBatteryManager.kext, but that is not an issue here. Values that you are getting from command line are same as those from Coconut. I made a test with ACPIBatteryManager. First I checked Coconut: And few seconds later I checked ioreg from terminal: dragon:~ viking$ ioreg -w0 -l | grep "Capacity" | | | "Configuration" = {"Correct16bitSignedCurrentRate"=Yes,"UseDesignVoltageForDesignCapacity"=Yes,"EstimateCycleCountDivisor"=6,"UseExtraBatteryInformationMethod"=Yes,"UseDesignVoltageForMaxCapacity"=Yes,"UseExtendedBatteryInformationMethod"=Yes,"CorrectCorruptCapacities"=Yes,"StartupDelay"=0,"FirstPollDelay"=4000,"CurrentDischargeRateMax"=20000,"UseDesignVoltageForCurrentCapacity"=Yes} | | "MaxCapacity" = 5527 | | "CurrentCapacity" = 3341 | | "LegacyBatteryInfo" = {"Amperage"=18446744073709550173,"Flags"=4,"Capacity"=5527,"Current"=3341,"Voltage"=7601,"Cycle Count"=188} | | "DesignCapacity" = 6660 dragon:~ viking$ And that is perfectly fine since there was a few seconds difference. 3353 is 60.66582232676% of 5527. 3341 is 60.448706350642% of 5527. So, Coconut and ioreg are in sync. So everything looks fine, but... iStatMenus showed this: And same (wrong) percentage was displayed by OS: Since those values are higher than real ones, there are only two potential reasons: 1. one of two values (or even both) used for calculation that system gets are wrong - but this is almost impossible since ioreg values are correct 2. system gets result with delay - is even more problematic to comprehend the possible reason for this @Jake Lo I am totally confused now, since you wrote that you noticed this difference even with VirtualSMC. I will revert VirtualSMC and repeat those tests again.

I don't see this issue on my system (E7450 + VirtualSMC + SMCBatteryManager). dragon:~ viking$ ioreg -w0 -l | grep "Capacity" | "AppleRawCurrentCapacity" = 1194 | "AppleRawMaxCapacity" = 5456 | "MaxCapacity" = 5456 | "CurrentCapacity" = 1194 | "LegacyBatteryInfo" = {"Amperage"=18446744073709549617,"Flags"=4,"Capacity"=5456,"Current"=1194,"Voltage"=7366,"Cycle Count"=0} | "DesignCapacity" = 6660 | "BatteryData" = {"StateOfCharge"=5376,"Voltage"=7366,"QmaxCell1"=0,"ResScale"=0,"QmaxCell2"=0,"QmaxCell0"=0,"CycleCount"=0,"DesignCapacity"=6660} As you can see MaxCapacity is same as AppleRawMaxCapacity and CurrentCapacity is same as AppleRawCurrentCapacity. Since there is no difference, it's expected to get same results whatever value is used. There might be slight difference because of different number rounding rules. In this example 1194 is 21.8841642228739 percent of 5456. CoconutBattery: iStatMenus: macOS: Looks like Cycle Count and Battery Temperature are always 0 with virtualSMC. Coconut wrongly displays absolute zero when it reads 0 value for temperature.