Jump to content

Mieze

Developers
  • Content Count

    1,376
  • Joined

  • Last visited

  • Days Won

    17

Mieze last won the day on November 26 2016

Mieze had the most liked content!

4 Followers

About Mieze

  • Rank
    Giant Cat

Profile Information

  • Gender
    Female
  • Location
    Germany
  • Interests
    Cats

Recent Profile Visitors

49,748 profile views
  1. In order to use the device with the Apple driver, it's firmware must be updated with macOS 10.13.3 but as the AQC111's device id 0x11b1 isn't supported natively by Apple's driver, I doubt that it will update the firmware and even in case it does, there is no guarantee that Apple's firmware will work on this chip, it might as well render the chip unusable. Mieze
  2. Mieze

    New Driver for Realtek RTL8111

    Sure, I will add support for new devices as soon as Realtek releases Linux driver sources so that I can learn how to handle them. Mieze
  3. Mieze

    New Driver for Realtek RTL8111

    It's Apple's Bonjour daemon listening for requests. Mieze
  4. First of all, if you don't know how to clean the system caches of your Mac OS version, ask Google. Second, there is no driver problem with static IP addresses because address handling is far beyond the scope of a driver. The driver handles packets, nothing more and nothing less. In case it continues to crash, fix your system. Mieze
  5. Please delete system caches and see if it resolves the issue. Mieze
  6. Thank you for the feedback. I received a similar problem report form from vit9696 but I neither can reproduce the issue on my test system, nor do I have a conclusive explanation for it. Instead of that I noticed a strange behavior of the power LED during sleep on my test machine. Although the system seems to sleep and wake properly, the power LED stays on in sleep state which indicates, that the machine doesn't manage to complete the transition to sleep state (S3) completely. This never happened before updating to Mojave and it indicates that there is a general power management issue, which may also be related to the crash. Anyway, it would be helpful if you could provide me a kernel panic report of the machine showing the incident? Are you using Gigabit Ethernet for your LAN? How fast is your internet connection? I also attach the prebuilt binary (requires Mojave) to this post so that anybody interested in testing version 2.5.0d0 of the driver or having the same problem can try it too. It should also fix the no network after wakeup issue that some users with LM-versions of the NIC reported in the past, as it doesn't release control of the chip during sleep anymore Mieze IntelMausiEthernet-V2.5.0d0.zip
  7. Of course it's a typo and it should read "No-hda-gfx" but apart from that it can be injected in the same way as other properties. Mieze
  8. I just saw your post and wanted to share this piece of code which I used to dump the GPU's register space in order to investigate the wakeup issue. It adds the dump as property GBUF to the GPU's IORegistry entry while the system is booting so that it my be retrieved using IORegistryExplorer later. Have fun! Device (PEGP) { Name (_ADR, Zero) // _ADR: Address OperationRegion (PCIB, PCI_Config, Zero, 0x0100) Field (PCIB, AnyAcc, NoLock, Preserve) { Offset (0x04), CMDR, 16, Offset (0x10), BAR0, 32, BAR1, 32, BAR2, 64 } OperationRegion (GREG, SystemMemory, And (BAR2, 0xFFFFFFFFFFFFFFF0), 0x8000) Field (GREG, AnyAcc, NoLock, Preserve) { Offset (0x681C), SBS0, 32 } OperationRegion (GREF, SystemMemory, And (BAR2, 0xFFFFFFFFFFFFFFF0), 0x00010000) Field (GREF, AnyAcc, NoLock, Preserve) { GSRC, 524288 } Name (GBUF, Buffer (0x00010000) {}) Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Or (CMDR, 0x02), CMDR) Sleep (One) CopyObject (GSRC, GBUF) Store (Package (0x02) { "GBUF", GBUF }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } Mieze
  9. Since I replaced my my R9 270X with an RX570 a half year ago, I noticed that this strange kernel message was showing up after wakeup from sleep: kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms kernel: AppleHDAHDMI_DPDriver::setPowerState(0xdf0b895bf4bcbbf9, 0 -> 1) timed out after 10134 ms Although it doesn't seem to do much harm to the system, DisplayPort audio used to work well anyway, I'm curious like all cats and decided to investigate the issue. As I'm using system definition iMac18,3 it was the most obvious step to take a look at the IOReg dump of an original Apple machine of that type and compared it with mine. Checking device HDEF, I noticed that the iMac18,3 doesn't have the "hda-gfx" property on that device anymore but instead of it a "No-hda-gfx" property so that I decided to edit my HDEF's method _DSM in order to adopt this change and it made the error message after wakeup disappear. Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x06) { "No-hda-gfx", Buffer (0x08) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }, "layout-id", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 }, "PinConfigurations", Buffer (Zero) {} }) } Mieze
  10. Yes, the driver supports LACP. I successfully tested it in combination with a Realtek RTL8111E using my Realtek driver. Mieze
  11. Mieze

    New Driver for Realtek RTL8111

    Sorry, but this is off-topic.
  12. In the past there have always been reports of kernel panics after every major update of macOS and I also received some of them from users which upgraded to Mojave. It always turned out that the driver is innocent and I have no reason to assume that it's different this time. Anyway, I ran some tests with 10.14.1 this afternoon using the prebuilt binary from the download section and there haven't been any issues. Version 2.4.0 of IntelMausiEthernet works perfectly with Mojave. In case you are experiencing any problems, it's most likely because something went wrong during the update and you should try to fix your system. Mieze
  13. @Sabrina13 and @kenzobengy: According to your description, this is not a driver issue. In case you can rule out a hardware problem, it's most likely a messed up network configuration or a DHCP related problem. Mieze
  14. It's your call. Both methods work fine. Anyway you have to remove AppleIntelE1000e.kext in order to avoid conflicts. Mieze
  15. Most likely because your network configuration is messed up so that the names of the devices have been exchanged.
×