TLDR; more things working. More confidence of this being a permanent go-forward solution.

USB-C 2nd port now working

Both USB-C ports are working now, and also with hubs (both USB3 and USB2 hubs) with devices off of them. I wish I could say it was up to my diligent work, but what seemed to do the trick was just a reboot. I’ve rebooted multiple times since that one time for other reasons and both USB-C ports continue to work. My USB-C (USB3) gigabit NIC is also consistently working, which is great.

Display

Still with my old DL-165 based Displaylink adapter, I’ve revered back to the default resolution of 1680x1050 at 60Hz. At the display adapters limit of 1920x1080 the desktop stitching seems to be unreliable where there will be overlap between the left and right displays by about 30 pixels. Additionally video performance is noticeably impacted for full motion video at the max res. The overlap is likely fixable, but I’m just going to source a modern Displaylink adapter instead of trying to get this one from 2009 working solid on a machine from 2022. The current config is still sufficient with the old adapter for my needs right now.

I’ve also dug quite a bit more into Displaylink technology in general to understand what is going on under the hood. It can be very CPU and RAM hungry. At one point I had a kworker thread taking 48% of the total system CPU and as soon as I unplugged the Displaylink adapter that thread disappeared. I’m also seeing much of the 24GB of RAM in this laptop being used by something and I suspect a its also Displaylink. I don’t know if its because of this old model, or if all Displaylink adapters would have equal resource consumption on the host system.

I want to figure out how to see how much of the shared memory is being consumed for the integrated graphics, and for the Displaylink frame buffer but having found a measurement point for either yet.

Power Management

I’ve done some work with ACPI and power configuration on x86 systems and assumed much would be the same. That was NOT a good assumption. At least Mac silicon doesn’t use anything like BIOS, EUFI, or ACPI. Instead it uses a Device Tree initialization which is something I’ll have to do a lot of reading on. Further, I’ve read some of the documentation from the m1n1 developers regarding the SMC where I’m guessing all of the power management sensors, data, and many of the controls reside to improve the power management of the hardware under Linux. The 1400 different values, with many being read/payload returns show me that the folks working on this have already done a HUGE amount of work, and there is still so much left to uncover with no documentation from Apple.

General

I’m doing more tweaks to the desktop environment. Learning the keyboard shortcuts, and uncovering small nice features (like “limit battery charging to X%”). I now have the unit only charge to 80% before stopping to save wear and tear on the battery from deep cycling.

The unit is plenty fast for my need and I have room to grow in it. My thanks again to the Asahi developers both past and present as well as the Fedora Remix maintainers!

How are you doing now, after 23 days? Looking forward to your next post.

After 1.5 months, I'm happy and productive. My remaining pain points are:

Power use during sleep

I've been shutting down a lot more than I used to. This isn't a huge deal since the machine boots fast. However it's clear that Apple didn't expect this machine to be fully shut down much. It's hard to know when it's fully shut down (and what that even means for a machine that has so many always-on systems such as the haptic trackpad).

USB-C hotplugging, docks, and PD

I often have devices failing to enumerate, PD not working, etc. I guess my USB tree is pretty big, with about a dozen devices connected via various USB hubs and such. It works perfectly if I boot with it all plugged in, but hotplugging tends to have issues, which leads me to try other ports (more hotplugging) which multiplies the problems. I haven't found much of a pattern yet, so I keep retrying, flipping connectors and running lsusb -tv until it works. And eventually rebooting if all else fails.

I'm now trying to rig up a serial debug cable so that I can better see what's happening out-of-band, especially while booting or while "sleeping".

So far so good. Its still my primary mobile unit.

Power use during sleep

This is really my biggest concern with the implementation. Before this unit, I was never a heavy "sleep" (aka ACPI S3) instead preferring to use hibernation (aka ACPI S5). Hibernation being the act of copying the contents of RAM to disk, and then a full power down of the unit occurring. Then on power up, the contents of RAM are copied back from the disk to RAM, and the unit wakes in a state precisely as it was prior to hibernation. So NOT having hibernation available is a massive change to my workflow.

I'm choosing to leave it in sleep attached to AC power more often, but its not a solution that I like. This is especially true with the knowledge about the possible unreliability of the power regulator in these Macbooks as shown by Louis Rossman.

I'd talked about trying to develop a script to capture the state of the running applications and then executing those after boot as a poor substitute for hibernation, but I haven't done any of that yet.

USB-C hotplugging, docks, and PD

After doing final OS patching and rebooting a couple of times, I've had no issues with USB hotplugging. Right now, I only have a single USB-3 device which is an ethernet adapter. As long as that is plugged directly in, everything works. However, trying to put that USB-3 device off a USB-3 hub does cause issues with hotplugging sometimes. All my other devices are USB 2.0 (or even USB 1.1) and I'm not having any issue with them.

I imagine you may have some USB-2 devices, or at least USB-3 devices that don't actually require USB-3 bandwidth (like keyboards and mice). I wonder if you put all of those off a USB-2 hub (forcing a compatible interface to USB 2) if that would remove your hotplugging issues.

I’m now trying to rig up a serial debug cable so that I can better see what’s happening out-of-band, especially while booting or while “sleeping”.

A few weeks ago I saw there was a large release of SMC data and a CLI tool for querying it under Linux. I've only read through parts of the data, but this gives me hope for further exploration and understanding of the power management and other hardware access in the Macbooks.

Earlier today on Lemmy there was a presentation posted about the challenge of running x86 games on ARM , which I know isn't exactly applicable to Asahi, but I'm interested in diving into that too to get another view and side-by-side comparison about the x86 universe where I'm pretty familiar and the ARM universe where I'm quite a bit weaker on the hardware side.

Booting back to OSX only when required

I wanted a Macbook as my Linux host because I knew at some point I would have to revert back to a commercial OS to get something working temporarily and I didn't want this fallback OS to be MS Windows. This exact use case presented itself about 2 weeks ago. I launched Netflix in a browser in Asahi and while the login to the site and browsing of the library worked without issue, any initiation of a video stream failed. I tried a few fixes with no success, and at that moment I didn't want to be troubleshooting Linux, I wanted to be watching a show with my wife. I was easily able to boot back to OSX, log into Netflix, and it worked right on the first try. In my mind this is even more affirmation that Macbook with Asahi is the right choice for me.

The power of Linux coupled to Mac hardware

I don't have a lot of scanning needs, but I do have some occasionally. Its not nearly enough to justify any kind of replacement purchase of modern hardware. I was delighted to be able to get my ancient cheap flatbed optical scanner working on this unit under Asahi. Its a cheapy USB 1.1 scanner from 2002. I believe I paid about $20 for it after its mail-in rebate. This means I have a 23 year old scanner build to work under Windows (which lost compatibility after Windows XP) fully operation on an ARM based Macbook from 2022. I love it!

Future goal: Whole disk encryption

I am interested in implementing this on my unit. I see there are others that have done this successfully, but its not entirely clear what the exact steps needed are for an M2 unit.

Future goal: Shared partition between OSX and Asahi

To make sharing data between the two OSes easier, I left some unallocated space on the SSD. I'd like to create a partition that is readable by both OSes (separately when each is booted of course). From the preliminary searched I've done it looks like this is possible. I should be able to use a Mac native format and be able to mount that as a volume under Asahi Linux to do this. I haven't tried any of this yet.

Moonshot goal: Boot the Asahi Linux partition inside OSX as a VM

Back in the first few years of x86 Macbooks, I did succeed in creating a dual boot OSX/Windows (XP or Vista) unit. This was common with Bootcamp. However, I was able to take this a step further and use Parallels to run a VM under OSX and point the VM at the other partition. This meant the VM itself had no virtual disk. Its only disk was the other partition with the OS on it. This did some wonderful things. It allowed the user to use the superior power management on Mac hardware, yet still be able to run applications natively in the other OS. Yes there was a performance hit for running it in a VM, but there were only a few instances when full bare metal performance was needed, and at those times the user could simply save their work in the Windows VM, Power Down, boot in the bare metal Windows install and pick up their work where they left off with the full power of bare metal available to them.

I am hopeful I could do something similar here. Yes I know I could create a VM with a virtual disk and simply run it under OSX, but I don't want to have to maintain two Linux operating systems and manage sharing data between them.

Overall, I'm still quite happy with the solution I have today, and see opportunities for improving my experience.

Let me know if you make progress on your out-of-band connection. I too am curious what is visible under the hood.

Some fascinating ideas. Thank you!

Future goal: Shared partition between OSX and Asahi

Yes, this should be doable. It's straightforward to make a partition that's visible to both OSes, but choosing a filesystem that has good support in both is difficult. MacOS has no support for any linux filesystems. In the past, as a mac user needing to share external drives with linux, I often resorted to exFAT or NTFS.

Fortunately, I've been having good luck lately with fuse-apfs, and even used it to restore my mac TimeMachine backups. Unfortunately it's read-only.

Just now I was able to mount several unencrypted APFS partitions from my internal NVME under Asahi. But the main APFS partition (which is encrypted) does not work. It seems that fuse-apfs supports encrypted APFS volumes, but not hardware-encrypted volumes (see limitations). So that's unfortunate.

HFS+ might be an option, since its Linux support might be better, and MacOS still supports it very well.