RFC: Patch for stricter parsing to fix crash on broken hardware

RFC: Patch for stricter parsing to fix crash on broken hardware

[nick]

Hi team,

First time posting here -- sorry I don't know how to use git send-email 
yet, so I'm just going to include the patch inline, it's only an RFC and 
not suitable to merge directly in any case. It would need a command-line 
option added to make it useful.

The problem I'm working on is, getting linux to boot on a new Asus M1502 
laptop model released late 2025 -- symptom was a blank screen and 
apparently nobody is using this model yet, because there weren't any 
suggestions online. I found that acpi=off helps. But strangely, noacpi 
doesn't help. I guess the older syntax noacpi does something different 
than the newer syntax acpi=off.

I spent some time trying to find a workaround for the blank screen, 
because I couldn't see any error messages -- and eventually came up with 
the incantation: earlycon=efifb keep_bootcon (I found that other options 
like earlyprintk=vga or vga=0xf00 do not work on this hardware, not sure 
why).

Okay so with this in place I can see that the ACPI tables are broken, 
the errors are approximately (transcribing from a screenshot I took by 
phone):
ACPI BIOS Error (bug): Failure creating named object [\ASMI], 
AE_ALREADY_EXISTS ...
ACPI Error: AE_ALREADY_EXISTS, during lookup/catalog ...
ACPI BIOS Error (bug): Failure creating named object [\RESV], 
AE_ALREADY_EXISTS ...
ACPI Warning: NsLookup: Type mismatch on RESV (IndexField), searching 
for (RegionField) ...

Shortly afterwards it gets a NULL pointer dereference and crashes. I did 
try putting NULL tests on this line but then it just crashed further 
down, so the problem is apparently that due to the type mismatch, it's 
trying to interpret the wrong kind of object and this object has NULLs 
in the wrong places.

So what I decided to do was make the NsLookup stricter, so it would 
return a failure instead of returning the wrong kind of object. 
Additionally, I had to remove some other error recovery code later on, 
which was accepting the table despite errors parsing it. With these two 
fixes, I can boot.

The following patch applies to linux tag v6.19 and implements the 
stricter checking:
```patch
diff --git a/drivers/acpi/acpica/nsaccess.c 
b/drivers/acpi/acpica/nsaccess.c
index a0c1a665dfc1..a758acf90fa3 100644
--- a/drivers/acpi/acpica/nsaccess.c
+++ b/drivers/acpi/acpica/nsaccess.c
@@ -700,6 +700,7 @@ acpi_ns_lookup(union acpi_generic_state *scope_info,
  								    type),
  					      acpi_ut_get_type_name
  					      (type_to_check_for)));
+ return_ACPI_STATUS(AE_NOT_EXIST);
  			}

  			/*
diff --git a/drivers/acpi/acpica/psobject.c 
b/drivers/acpi/acpica/psobject.c
index 496a1c1d5b0b..4235fd98869a 100644
--- a/drivers/acpi/acpica/psobject.c
+++ b/drivers/acpi/acpica/psobject.c
@@ -588,6 +588,7 @@ acpi_ps_complete_op(struct acpi_walk_state 
*walk_state,
  		walk_state->prev_op = NULL;
  		walk_state->prev_arg_types = walk_state->arg_types;

+#if 0
  		if (walk_state->parse_flags & ACPI_PARSE_MODULE_LEVEL) {
  			/*
  			 * There was something that went wrong while executing code at the
@@ -600,6 +601,7 @@ acpi_ps_complete_op(struct acpi_walk_state 
*walk_state,
  			ACPI_INFO(("Ignoring error and continuing table load"));
  			return_ACPI_STATUS(AE_OK);
  		}
+#endif
  		return_ACPI_STATUS(status);
  	}

```

I realize that in a majority of cases, ignoring type mismatch errors and 
accepting a table despite errors in it, is the right thing to do. So I 
believe that adopting this patch unconditionally would cause breakage 
and complaints with previously working systems. But perhaps it could be 
a kernel command-line option? Like acpi.strict=on or similar. There are 
guides that suggest you try acpi=ht and similar, this could be another 
one to try.

If agreed, I could try to work up a formal patch. But I think we would 
also run into difficulties getting it accepted upstream. So I'm not 
sure. Hmm.

Kind regards, Nick