Issues installing OpenBSD 7.7 on FW13-AMD-AI-370

wondering if anyone has tried to install OpenBSD 7.7, i encountered what i believe to be a driver issue with an output of “panic: aml_die aml_convert:2094 \n the operating system has halted. \n please press any key to reboot.”. and hitting just an infinite loop of being requested to press a key to reboot. i believe it’s an i/o apic but i couldn’t find any toggle to shut that off. happy to post the error report but figured i’d just throw this question out there first. i believe openbsd added support for the cpu though with the latest 7.7 version.

happy to have joined the framework community in any case.

Same machine, same problem here. I was able to avoid the panic with the disable acpi kernel option (run boot -c on startup to be able to set options, see boot_config(8)). Unfortunately, that only led me to a second problem where the keyboard repeats each key exactly seven times each time a key is pressed. I tried a workaround, but no luck. Accordingly, I’ve been unable to install thus far.

If time allows, and if no one else gets to it first, I’ll attempt to look into the issues in the coming weeks. OpenBSD is not my forte though. If nothing else, I should send a proper report to the appropriate mailing list.

i see, i’ll give that a try with boot_config. i submitted a report yesterday to Framework to let them know. happy to collaborate on this issue!

Hi there! I got the laptop yesterday and naturally ran into this as well. Since my C is pretty decent and I’ve done some OpenBSD kernel debugging in the past, I couldn’t help but have a look. It’s a subtle bug in the ACPI driver. The TLDR is that it’s missing an implicit type conversion. Here’s my report to bugs@:

I’ve got my machine to boot, so a patch to tech@ is coming.

3 Likes

thank you so much!! i was going to write up an OpenBSD bug report. unfortunately a cold and fever got in the way. will be following attentively!

Patch posted. I’ll include it here for convenience.

Index: dev/acpi/dsdt.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.274
diff -u -p -r1.274 dsdt.c
--- dev/acpi/dsdt.c	22 Mar 2025 18:14:37 -0000	1.274
+++ dev/acpi/dsdt.c	6 Jun 2025 22:16:44 -0000
@@ -1753,6 +1753,7 @@ struct aml_scope *aml_pushscope(struct a
 struct aml_scope *aml_popscope(struct aml_scope *);
 
 void		aml_showstack(struct aml_scope *);
+struct aml_value *aml_tryconv(struct aml_value *, int, int);
 struct aml_value *aml_convert(struct aml_value *, int, int);
 
 int		aml_matchtest(int64_t, int64_t, int);
@@ -1766,6 +1767,8 @@ int		aml_ccrlen(int, union acpi_resource
 
 void		aml_store(struct aml_scope *, struct aml_value *, int64_t,
     struct aml_value *);
+void		aml_rwfield(struct aml_value *, int, int, struct aml_value *,
+    int);
 
 /*
  * Reference Count functions
@@ -2022,7 +2025,7 @@ aml_hextoint(const char *str)
 }
 
 struct aml_value *
-aml_convert(struct aml_value *a, int ctype, int clen)
+aml_tryconv(struct aml_value *a, int ctype, int clen)
 {
 	struct aml_value *c = NULL;
 
@@ -2045,6 +2048,11 @@ aml_convert(struct aml_value *a, int cty
 			c = aml_allocvalue(AML_OBJTYPE_BUFFER, a->length,
 			    a->v_string);
 			break;
+		case AML_OBJTYPE_BUFFERFIELD:
+		case AML_OBJTYPE_FIELDUNIT:
+			c = aml_allocvalue(AML_OBJTYPE_BUFFER, 0, NULL);
+			aml_rwfield(a, 0, a->v_field.bitlen, c, ACPI_IOREAD);
+			break;
 		}
 		break;
 	case AML_OBJTYPE_INTEGER:
@@ -2062,6 +2070,13 @@ aml_convert(struct aml_value *a, int cty
 		case AML_OBJTYPE_UNINITIALIZED:
 			c = aml_allocvalue(AML_OBJTYPE_INTEGER, 0, NULL);
 			break;
+		case AML_OBJTYPE_BUFFERFIELD:
+		case AML_OBJTYPE_FIELDUNIT:
+			if (a->v_field.bitlen > aml_intlen)
+				break;
+			c = aml_allocvalue(AML_OBJTYPE_INTEGER, 0, NULL);
+			aml_rwfield(a, 0, a->v_field.bitlen, c, ACPI_IOREAD);
+			break;
 		}
 		break;
 	case AML_OBJTYPE_STRING:
@@ -2087,7 +2102,15 @@ aml_convert(struct aml_value *a, int cty
 		}
 		break;
 	}
-	if (c == NULL) {
+	return c;
+}
+
+struct aml_value *
+aml_convert(struct aml_value *a, int ctype, int clen)
+{
+	struct aml_value *c;
+
+	if ((c = aml_tryconv(a, ctype, clen)) == NULL) {
 #ifndef SMALL_KERNEL
 		aml_showvalue(a);
 #endif
@@ -2099,8 +2122,26 @@ aml_convert(struct aml_value *a, int cty
 int
 aml_compare(struct aml_value *a1, struct aml_value *a2, int opcode)
 {
+	struct aml_value *cv;		/* value after conversion */
 	int rc = 0;
 
+	/*
+	 * Convert A1 to integer, string, or buffer.
+	 *
+	 * The possible conversions listed in Table 19.6 of the ACPI spec
+	 * imply that unless we already got one of the three supported types,
+	 * the conversion must be from field unit or buffer field. In both
+	 * cases, the rules (Table 19.7) state that we should convert to
+	 * integer if possible with buffer as a fallback.
+	 */
+	if (a1->type != AML_OBJTYPE_INTEGER && a1->type != AML_OBJTYPE_STRING
+	    && a1->type != AML_OBJTYPE_BUFFER) {
+		cv = aml_tryconv(a1, AML_OBJTYPE_INTEGER, -1);
+		if (cv == NULL)
+			cv = aml_convert(a1, AML_OBJTYPE_BUFFER, -1);
+		a1 = cv;
+	}
+
 	/* Convert A2 to type of A1 */
 	a2 = aml_convert(a2, a1->type, -1);
 	if (a1->type == AML_OBJTYPE_INTEGER)
@@ -2127,6 +2168,14 @@ aml_concat(struct aml_value *a1, struct 
 {
 	struct aml_value *c = NULL;
 
+	/*
+	 * Make A1 an integer, string, or buffer. Unless we already got one
+	 * of these three types, convert to string.
+	 */
+	if (a1->type != AML_OBJTYPE_INTEGER && a1->type != AML_OBJTYPE_STRING
+	    && a1->type != AML_OBJTYPE_BUFFER)
+		a1 = aml_convert(a1, AML_OBJTYPE_STRING, -1);
+
 	/* Convert arg2 to type of arg1 */
 	a2 = aml_convert(a2, a1->type, -1);
 	switch (a1->type) {
@@ -2292,7 +2341,6 @@ void aml_rwgen(struct aml_value *, int, 
 void aml_rwgpio(struct aml_value *, int, int, struct aml_value *, int, int);
 void aml_rwgsb(struct aml_value *, int, int, int, struct aml_value *, int, int);
 void aml_rwindexfield(struct aml_value *, struct aml_value *val, int);
-void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
 
 /* Get PCI address for opregion objects */
 int
2 Likes

thanks a lot! i imagine they’ll incorporate the patch into the file sets soon!

Thank you so much for taking the time to look into this! I haven’t had a chance to use the laptop at all this past week, so I’m glad someone else was able to step up. Really, thank you.

Do you have the same keyboard issue I mentioned (repeating keys) after boot, or does this patch solve that issue as well?

It should resolve that, because it is tangential.

As far as I understand, several makes of laptops needlessly emulate a legacy keyboard using the wrong (i.e. modern) signaling, level-triggered vs. edge-triggered. Here is the relevant post where I read it: 'chromebook keyboards' - MARC

The workaround is to prioritice attaching the keyboard driver via ACPI rather than legacy. But if you disable acpi…

For reference, the workaround seems to have landed in OpenBSD in February: 'Re: return of the chromebook keyboard diff' - MARC

PS: Since these mails explicitly mention Chromebooks, I wonder if this misbehavior is in our (Framework) EC, inherited from ChromeOS.

FYI, there is another issue that can cause the system to hang on shutdown out of a running X session. Seems related to switching consoles. As a workround, log out of the session first and press the power button on the xenodm login screen.

Thank you for tracking this issue down and sharing your information. One question, reading your bug report it seems the crash only occurs when shutting down the computer. Just to confirm though, does suspend (S3 suspend to RAM or S0ix modern standby) work as expected?

Suspend has its own issue or issues which I have not investigated much further. Sometimes it works (S0ix), but most times it loses the USB ports upon waking.

As for the hang, I’m trying to track that down and it does indeed seem related to switching the consoles. Simplest repro I can find is booting into single user and alternately pressing Alt-F2 and Alt-F1 until it stops responding. For bonus points, count how many times you can switch before it happens.

PS: The original issue of this thread (kernel panic on boot) has since been fixed upstream.

My FW13-AMD-AI-370 did arrive and I’ll share a few quick observations. The system had OpenBSD current from Jul 23, 2025 installed.

  • The MEDIATEK Corp. MT7925 (RZ717) Wi-Fi 7 is not recognized, but I was expecting this.
  • hw.battery.chargestop is not available to be set , so I’m unable to set the charge limit to 80%.
sysctl hw.battery.chargestop=80
sysctl: hw.battery.chargestop: value is not available
  • I have experienced a kernel panic twice when issuing halt -p.

Later this week I’ll try to replicate this last item and send in a bug report.

FWIW, I have set a charge limit in EFI setup and that works.

1 Like

Tusen Tack! I was expecting that it might take a while for this to be fixed, but… turns out there’s already a fix in. :smiley: I can soon daily my favourite OS again. :slight_smile:

PS: The original issue of this thread (kernel panic on boot) has since been fixed upstream.

Just for clarity, I’d realistically have to wait for 7.8 though, right? I’m busy learning other things at the moment, so probably not worth the effort for me to figure out building everything from source - without a running OpenBSD system. Or?

I do have some OpenBSD virtual machines on the network (wireguard, ssh, sftp, etc), so if it’s an easy thing I’ve just overlooked, I could be up for it as a weekend activity.

Just for clarity, I’d realistically have to wait for 7.8 though, right?

You can install a current snapshot just like a release if you don’t want to wait and are happy to run “beta” software until 7.8 comes around, at which time you could switch to the regular release.

https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/

1 Like

Huh. Somehow I had completely overlooked that there are snapshot installer images. Thanks again!

And yeah, no problem with beta software on my laptop system. I used to be on -CURRENT because it was needed for the 11th Gen Framework laptop at the time, and even managed to find and report a bug in a fairly common package on that architecture. Much fun was had.

I’ll go ahead and install then. Cheers!

Is anyone experiencing system freezes that necessitate a hard power reset when accessing internet video content, such as YouTube? I am following OpenBSD current. The laptop freezes within a few minutes of accessing video content when using either Firefox or Chrome. No core file is generated. The system fan just accelerates its speed. SSH connections to the laptop become unresponsive and eventually drop.

Disabling amdgpu in the kernel resolves the issue, but that is not a desirable solution.

Just as a follow-up to my post, after updating to the latest current yesterday, the issue has been resolved.

Did the issue re-occur for you? On -current I get a hard freeze with no logs or dumps in graphical environments; with Sway it is instant, with CWM it’s the moment I start Alacritty (so GPU-accelerated), and I’ve had it sometimes instant, sometimes delayed on FVWM.