#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages ยท Page 70 of 1
arent motherboard com headers on 12V?
huuh, i don't think they are 12V
its called idc10 to db9
is there a variant of this that ends in a male usb type a
I don't have any machines with rs232 ports
there are usb to rs232 if you want
yep there is
just search idc10 to usb
or similar
alternatively u can have 2 separate cables, idc10 to db9, and db9 to usb serial
would be nice if u could test it out
(Including my B550 Ryzen system)
and check logs if it crashes as well on your hw
my desktop has ine of these i installed
i used it to test my gdb stub on real hardware
nice
Or actually 2.5 
I've bought 3 adapters, but lost one of them
more people noticing vibecoding regressions
its been almost a month and a half
but the maintainer merges typo fixes instead
anyone wants to make an ASL compiler for the uacpi org? 
tbh a clanker could probably oneshot that but
maybe someone wants to do it by hand
apart from the interpreter, it's an assembler, disassembler, and anything else?
yes
for the assembler, would it be possible to make something quick and good using flex and bison?
i don't think the grammar is too complicated
yeah its pretty simple honestly
they designed it so that all the complexity goes into the kernel and not the compiler
which is very smart ofc
99.9999% of the complexity is in interpreting the garbage 
yeah
they could make a proper bytecode with virtual registers, simple non recursive logical ops etc
but instead its ASL but translated 1 for 1 into AML
i was going to ask whether the assembler is also at fault for being too lax
yeah partially
maybe if the compiler wasn't so garbage and firmware devs were a bit smarter aml wouldn't be crazy
the NT ASL compiler does 0 checking
u can put any garbage consisting of valid keywords
bruh
thats partially why the AML is such a mess yeah
very poor underdeveloped tooling
these days acpica produces more warnings and stuff
but sometimes that does more harm as well
because they work around the warnings by doing even stupider stuff
I mean, i could try to write one when i'm at home
Or well, let clanker loose
I have 5.5 for free 
the acpi dump repo has a lot of decompiled ASL you could throw at it
@fiery turtle so what do i need to work on for the uacpi linux stuff
i missed a few things here and too lazy so tldr 
well there's the suspend stuff
I've ordered the serial stuff so I should be able to get logs on that soon
no it didn't suspend in the first place
power led stayed on and fans kept spinning
is there a repo for this btw? or is it just sharing patch files
for now it's just sharing patches but I'll update the uacpi repo eventually
@fiery ice you had issues with wake right?
can you try this
When i get home
bro
you know monkuous never asks such things for no reason 
but no srsly push it somewhere
it stubbed acpi_any_fixed_event_status_set acpi_any_gpe_status_set
I'm too ashamed that it's like 95% clanker
its fiiiine
I'm mostly asking because the patches thing is inconvenient lol
especially since testing it on the affected machine requires a custom kernel config (for amdgpu) and a custom initrd (for the firmware binaries)
that's what I'd do
yes
can you do it infy
i have org rights but not delete rights (and I shouldnt have them)
do u want to import it with the name uacpi-linux?
that would be nice i suppose
or if this does end up being patches we would just redo the patches anyway
with good conventions
i mean the conventions are pretty simple no?
Signed-Off-By: is annoying 
no reason im just lazy 
make up a fake name if u want
nah it's fine ive already doxxed myself on the lkml anyway
i mean especially if we consider the remote possibility of ever upstreaming it
linux doesn't allow anonymous contributors anyways
thatd be useful
yeah I know I'm a contributor
I have made very important contributions
society using linux after the patch I sent ^
Add files via upload
Linux after uACPI becomes the default AML engine
Also I spent like 2 hours trying to make a minimal and decent kernel config
Just for some bullshit to nuke it
๐
I'm doing ts tomorrow
@fiery turtle I'll just name the repo "linux", it's cooler
sure, whatever u want lol
first
https://github.com/uACPI/linux/tree/master/drivers/acpi/uacpi clanker readme that could be useful
ugh the commit message is shit forced push lol
Sub module it?
not sure that's a thing linux does
yeah no
@fiery turtle could you create a repo for the compiler / disassembler pls?
screen goes black and power led stays blue
then if i press anything, nothing happens
not even the power button
Yeah that sounds like _PTS and stuff is not getting called for some reason
What color is it supposed to be usually on suspend
That's what's happening on my PC as well
Really could use those logs
like it could literally be panicking in the kernel and we wouldnt know
i don't have serial there
acpidump
yeah, but it was decompiling it to multiple table files, lol
i just kept dsdt and ssdt
that had actual aml code
Sure
i hate that AI literally "fixes" the missing operation and replaces them with a No-Op
Lol I should try the new mythos release
on the uACPI thing
Claude fix everything make no mistake
(I won't, I'm not AI bro enough)
oh yeah
does Intel AMT Serial-over-lan thingy also work for getting logs? If so, then I might be able to test on my laptop
depends if yours captures normal output via COM1 or a PCI bar
if its a pci bar it might be too late but not sure
yeah, lemme try, lol
the disassembler is borked on the app clanker made
i need to force it to fix it
๐
bruh, it was using medium reasoning
gg
it did not fully decompile, but it's still a good result
I need to find the second serial lead
Is there any way to know? Or do I just chuck the ISO at it and see what happens?
yeah, the latter
with the appropriate command line to enable said output
@hallow marten @fiery turtle i have some logs
full logs from serial
it seems to behave the same way
so it does wake up but the screen doesnt light up or?
from your log it does, and it even wakes up
qemu has a seabios bug that prevents ECAM from working on resume
try without q35
just omit machine
i did
qemu-system-x86_64 -cdrom /home/diamantino/Downloads/uacpi.iso -serial stdi
i'm running it like this
ah ok
then thats the bug
But your qemu does wake up [ 33.454310] PM: suspend exit
i never touch anything
it wakes up from itself
and also, the terminal gets stuck
i can't do anything
ah ok then that should be easy to debug by clanker
@hallow marten can u tell clanker to run suspend in qemu and see why it doesnt suspend?
anyway, 5 hour window resetted, time to get clanker back at working, lol
lol
uAICP
the compiler is almost done i think
ACPIAI 
๐
5hr budget already run out
but seems like it won't stop the current job
it's now trying to fix the decompiler
what language are you even doing it in
c
ah
why?
idk
i think it's done?
ok nope
oh finally
after 40 mins
(or well 70 in total)
@fiery turtle
lol nice
u could try shoving it into the uacpi test runner instead of acpica
and see if its able to compile stuff
theres the --asl-compiler argument
but it will obv try to pass acpica options to it
those will not work, yeah
The answers it gets from acpiexec
Maybe the generated aml is not correct so acpiexec doesn't generate whats expected as the output
Compile the test file with iasl and your compiler and then run with acpiexec and compare the outputs ig
what file is that if you know
maybe 2080-buffer-reads?
it's the only one without a .aml
hmm, 2080 runs fine i think?
the writes does not tho
Yeah the 2080 is the autogenerated thing
Thats not the answers file
It failed to parse the output of the answers run
This is tho
yeah
Compiler bug?
Should've done rust
then i would've need to port the uacpi .h files every time it updated
Maybe but rust is agentic language bro
XD
it does work in qemu
idk what hes on about
idk i can reproduce that as well
qemu-system-x86_64 -cdrom uacpi-linux-iso -serial stdio, add no_console_suspend to kernel args, echo mem > /sys/power/state
interestingly it has different behavior with kvm enabled: it does enter suspend but on wakeup it gets stuck at the same point that it gets to with no interaction on tcg
or at least sometimes it does? sometimes it behaves the same as tcg
nevermind i'm stupid
this is just because linux defconfig doesn't have a proper vga driver
the "automatic wakeup" is just the interrupt for the enter key being released
and it's only "stuck" because userspace uses tty0 instead of ttyS0 and it doesn't know how to resume vga
works perfectly fine for me on q35
Ah ok that makes perfect sense
That explains why his log contained 0 errors
Thats probably linux magic
Like ecam shouldn't be usable at that point unless linux fixes the chipset register itself
That would also explain how that regression has gone unnoticed
@fiery turtle is this correct?
do u think i know all 2080 values it outputs by heart? 
cant u just compare to the iasl output?
the test idea is:
generate asl that writes every possbile combination of buffer fields
compile it
run it in acpiexec, get what it outputs
run it in uacpi, get what it outputs
make sure they agree

yeah it seems likely that thats correct
makes sense
lol
well, it is going so hopefully in a bit we'll have a good version
/goal make all tests run
i think that's what it's going for, lol
67/69 tests completed
huuh
lemme go see
not that bad tbh
it could def use some refactoring, but it is not very bad
and the file with the most LOCs is just the parser at 3.5k LOC
all the others are 1.5k or less
what about the disassembler?
lemme test
it's broken again, ooooof
i think it only updated the compiler for the tests
yk it's AI code when it has =======
In this case its actually handrolled uacpi tests
I think ======= is just very popular in general?
Nah AI does that but with em-dashes
Not in code
@fiery turtle i was stupid, i tried to decompile using compile ๐
it decompiled correctly i think
in comments yeah
but like
i never saw it print("emdashemdashemdash")
it's always print("==========")
yeah that's true
my 2017 project that does ======== was secretly written by an LLM
Are you secretly a LLM?
Gg
and i fixed a small bug where strings didn't get copied correctly
it's pretty surprising that people are able to find an uptime window long enough to perform github CI cyberattacks
@fiery turtle out of curiosity, do you actually have numbers for perf benefits for keeping aml microps stored inline? or is that just a code thing where in C its easier to make them like that?
Oh I have no idea, but it would definitely be way less convenient to have to define them separately, then make a declaration, then reference it etc
But in general id assume there's some benefit since the entire op array can be hot
ok cool. for my zaml project im sticking with out of line only then since i can just take address-of an array literal to get a slice and the compiler will put the array in rodata for me
it is probably better for cache true
probably when i have more than two ish lines of code
its all in the mind only at this point
Fair
@fiery turtle how does UACPI_UNRESOLVED_NAME_STRING_OP work? im having trouble understanding what the microcode is even doing for those
is it just hijacking it into the nameseg parsing or something?
ig the resolution thing would skip past the whole nameseg looking at this more
would an acpi library go under non-os or is it close enough for my thread to go in this category? not sure if uacpi is effectively grandfathered in or if this is the right category for mine too lol
imo it belongs in an os category
๐ I'll make a thread this afternoon sometime then
Did you figure it out BTW
I was asleep
i think so? #1217009725711847465 message is my best guess at how it works rn
update on the whole uacpi-linux real hardware suspend serial output thing: first I mistakenly bought both idc10-to-male-db9 and male-db9-to-usb adapters, then I bought a female-db9-to-usb adapter but when it arrived today I noticed that my idc10-to-db9 used the wrong idc10 layout so I bought the correct one today
hopefully tomorrow I will be able to get output
case '0'..'9'
case 'A'..'Z'
case 'a'..'z': // all valid ascii chars, must be a namestring
aml_pc--;
namestring = parse_namestring(aml + aml_pc);
// Is it a method call, a reference..?
do_what_namestring_wants(namestring);
@frank canopy
lol nice
so it is going oh this opcode is actually an identifier character, back up and parse a namestring
yep
hopefully those werent expensive?
nah
your actual code doesnt use the same op declaration for 0..9 or lowercase btw, only A-Z and \^_/.
even if they were I'm getting a full refund
yeah because 0..9 is not a valid starting char
so ig drop that case lol
ah good
ok so i was right then, just bad at describing what i thought it was lol
ye
also, warning for anyone else that wants to get a serial port header adapter: there are (apparently) 2 different electrical layouts in use for the same physical port
so make sure you get the right one
wtf
once we have fully working uacpi-linux ill make that the reference uacpi test os lol
if someone comes in with one of those uacpi bugs again 
my desktop has a working port btw
i could test this today
also wait there are multible difrent IDC10 things??
does it have the same issue?
yeah it's awful
I've tested it on two of my three computers and it's worked on one
I must have gotten lucky as fuckkkk
I was troubleshooting for like two hours before I decided to check the pinout of the adapter (I would've done so earlier but the adapter I bought had like 0 documentation so it wasn't immediately obvious where to find the pinout)
in fact I never did find any adapter specific pinout documentation
I found out about the multiple layouts thing first and then noticed that the packaging said "DTK" (as in "DTK/Intel layout")
serial works!
now to get the actual suspend output
thats just the stuff from the initramfs
@full nimbus @hallow marten
[ 75.281499] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 75.288456] #PF: supervisor read access in kernel mode
[ 75.293585] #PF: error_code(0x0000) - not-present page
[ 75.298720] PGD 10905b067 P4D 10905b067 PUD 10905c067 PMD 0
[ 75.304372] Oops: Oops: 0000 [#1] SMP NOPTI
[ 75.308556] CPU: 12 UID: 0 PID: 1 Comm: sh Not tainted 7.1.0-rc7-geb39c6a26396 #4 PREEMPT(lazy)
[ 75.317322] Hardware name: Gigabyte Technology Co., Ltd. B550M S2H/B550M S2H, BIOS F19d 09/02/2024
[ 75.326265] RIP: 0010:handle_control_flow+0x32/0xe0
[ 75.331136] Code: 48 8b 8f 38 1d 00 00 4c 8b 87 58 1d 00 00 48 8b 91 08 07 00 00 48 85 d2 74 77 48 8b 87 40 1d 00 00 48 39 c2 75 33 49 8b 70 08 <8b> 50 08 66 81 7e 1a a5 00 0f 45 50 04 89 91 1c 07 00 00 48 8b 87
[ 75.349859] RSP: 0018:ffffa5c980013bf0 EFLAGS: 00010246
[ 75.355077] RAX: 0000000000000000 RBX: ffff90ff898a6000 RCX: ffff90ff8713c000
[ 75.362202] RDX: 0000000000000000 RSI: ffffffff9c088c40 RDI: ffff90ff898a6000
[ 75.369326] RBP: 0000000000000015 R08: ffff90ff8713c080 R09: 0000000000000001
[ 75.376450] R10: 0000000000000005 R11: 0000000000000000 R12: ffff90ff8713c080
[ 75.383572] R13: 0000000000000015 R14: 0000000000000000 R15: ffff90ff8713c000
[ 75.390697] FS: 0000000000713198(0000) GS:ffff910ee17a2000(0000) knlGS:0000000000000000
[ 75.398772] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 75.404510] CR2: 0000000000000008 CR3: 0000000109054000 CR4: 0000000000750ef0
[ 75.411634] PKRU: 55555554
[ 75.414341] Call Trace:
[ 75.416791] <TASK>
[ 75.418892] uacpi_execute_control_method+0xea4/0x2660
whats the addr2line for this rip?
one sec i messed around with a few things between making the usb and today so i don't have the vmlinux for that build anymore
u did disable kaslr right?
but the fact that it page faults is good tbh, if it was silently suceeding but still hanging that would be way scarier
not via the command line and the build i'm using there is just defconfig + amdgpu builtin
ah yeah then addr2line wont work
i'll make a more debugging friendly build and retry
whats interesting is it dies in uacpi control flow opcodes handler
handle_control_flow
which (should) be a pretty well tested code path
also the uacpi entrypoint is uacpi_prepare_for_sleep_state so it can't just be a simple "oh the shim maps arguments incorrectly"
i think so yes
but tbh yours is not the only one that dies on suspend so I doubt its related to a particular aml blob
also, some things i discovered while doing said messing around:
- it doesn't compile on 32 bit platforms due to uacpi doing 64-bit division (which requires some special macro on linux instead of just using the operator)
- it doesn't compile unless PCI is also compiled in (acpica does)
the former is a good point, i should probably add a way to replace that with a kernel specific function, e.g. do_div on linux
the latter i guess is also a config option
yeah it's probably a shim thing that the acpica osl.c takes into account
ill add those to my todo list, thanks
that would be nice, maybe nokaslr, ubsan, and asan
ok this is with the debugging build
for some reason addr2line is saying it's line number 0 wtf
lol it GPFed and page faulted at the same time?
how did u get the actual rip since its hidden there?
i just passed the sym+x to llvm-addr2line directly
ooh
doesn't seem to have worked perfectly though
$ llvm-addr2line -e vmlinux 0xffffffff823dce20
/home/monkuous/dev/linux/drivers/acpi/uacpi/lib/../../../../uACPI/source/interpreter.c:4175``` this should be accurate
very strange
(i just did objdump -t vmlinux | grep handle_control_flow and added the offset manually)
Hm but thats a different function handle_code_block
this should be on uacpi master as of ~30 minutes ago
nevermind i used the wrong value as offset
using the correct offset does reproduce the interpreter.c:0 thing (???)
wtf
did it per chance jump to an invalid offset or smth
which misinterpreted the instruction
; if (op_ctx->op->code == UACPI_AML_OP_BreakOp)
ffffffff823dcbcc: 49 83 c4 08 addq $0x8, %r12
ffffffff823dcbd0: 4c 89 e0 movq %r12, %rax
ffffffff823dcbd3: 48 c1 e8 03 shrq $0x3, %rax
ffffffff823dcbd7: 42 80 3c 30 00 cmpb $0x0, (%rax,%r14)
ffffffff823dcbdc: 74 08 je 0xffffffff823dcbe6 <handle_control_flow+0x146>
ffffffff823dcbde: 4c 89 e7 movq %r12, %rdi
ffffffff823dcbe1: e8 4a bf 55 ff callq 0xffffffff81938b30 <__asan_report_load8_noabort>
ffffffff823dcbe6: 4d 8b 24 24 movq (%r12), %r12
ffffffff823dcbea: 49 83 c4 1a addq $0x1a, %r12
ffffffff823dcbee: 4c 89 e0 movq %r12, %rax
ffffffff823dcbf1: 48 c1 e8 03 shrq $0x3, %rax
ffffffff823dcbf5: 42 0f b6 04 30 movzbl (%rax,%r14), %eax
ffffffff823dcbfa: 84 c0 testb %al, %al
ffffffff823dcbfc: 0f 85 2d 01 00 00 jne 0xffffffff823dcd2f <handle_control_flow+0x28f>
ffffffff823dcc02: 31 c0 xorl %eax, %eax
ffffffff823dcc04: 66 41 81 3c 24 a5 00 cmpw $0xa5, (%r12)
ffffffff823dcc0b: 0f 94 c0 sete %al
ffffffff823dcc0e: 4c 8d 24 85 04 00 00 00 leaq 0x4(,%rax,4), %r12
ffffffff823dcc16: 4d 01 ec addq %r13, %r12
ffffffff823dcc19: 4c 89 e0 movq %r12, %rax
ffffffff823dcc1c: 48 c1 e8 03 shrq $0x3, %rax
ffffffff823dcc20: 42 0f b6 04 30 movzbl (%rax,%r14), %eax``` this is what `llvm-objdump -dS` has to say about it (last instruction is the faulting one)
frame->code_offset = ctx->cur_block->begin; probably this line, because thats the only field at offset 8 there
Or rather, this line
if (op_ctx->op->code == UACPI_AML_OP_BreakOp)
frame->code_offset = ctx->cur_block->end;
Lemme try to look for a dump
this i think
yeah
it's the gigabyte one
i don't think i've updated the bios since then so that should be the exact one
i could try kgdb?
afaik that's like an in kernel gdbserver thing
Wow it executes just ridiculous amounts of AML when u _PTS with != 5
yeah that would be nice
if u could dump the state of the execution_context when it dies
ill try to look at the aml in the meantime
That happens when it's an instruction but not a line
Also, it would really help if u added a printf that printed the method name that it tries to call in prepare_method_call, maybe just using uacpi_namespace_node_generate_absolute_path on the node object
lol kgdb isn't very well integrated with the rest of the kernel it seems
i was just setting up my breakpoints and when i continued it triggered the watchdog
I have a suspicion its this break https://pastebin.com/DXRb6uqN but i cant repro anything with my synthetic tests so maybe not
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
bruh
this problem wouldn't have happened if uacpi were written in rust 
decided to just disable watchdog, turns out there's more watchdog: amdgpu 0000:07:00.0: [drm] vblank wait timed out on crtc 0
lol
at least this time it's not a panic
ok it seems like kgdb is just bitrot central
I mean I somewhat get why it wouldn't be fully integrated into everything with watchdogs etc
btw, my laptop's nvidia gpu has an _EJ0
๐
i am afraid to call it 
what is _EJ0
What's that again?
to eject it
@gentle peak wont be needed
STDERR FOR desktop_gigabyte_technology_b550m_b550m_s2h_a1360a8647f9:
/home/d-tatianin/Projects/uACPI/source/interpreter.c:4127:48: runtime error: member access within null pointer of type 'struct code_block'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==310039==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x58ac07f76ba5 bp 0x7ffdb5997690 sp 0x7ffdb5997660 T0)
==310039==The signal is caused by a READ memory access.
==310039==Hint: address points to the zero page.
#0 0x58ac07f76ba5 in handle_control_flow /home/d-tatianin/Projects/uACPI/source/interpreter.c:4127
#1 0x58ac07f84b3c in exec_op /home/d-tatianin/Projects/uACPI/source/interpreter.c:5727
#2 0x58ac07f88aa7 in uacpi_execute_control_method /home/d-tatianin/Projects/uACPI/source/interpreter.c:6136
#3 0x58ac07f372f1 in uacpi_eval /home/d-tatianin/Projects/uACPI/source/uacpi.c:779
#4 0x58ac07fae120 in eval_sleep_helper /home/d-tatianin/Projects/uACPI/source/sleep.c:290
#5 0x58ac07fae267 in eval_pts /home/d-tatianin/Projects/uACPI/source/sleep.c:309
#6 0x58ac07fae64d in uacpi_prepare_for_sleep_state /home/d-tatianin/Projects/uACPI/source/sleep.c:386
#7 0x58ac07f08ddb in enumerate_namespace /home/d-tatianin/Projects/uACPI/tests/runner/test_runner.c:212
#8 0x58ac07f09849 in run_test /home/d-tatianin/Projects/uACPI/tests/runner/test_runner.c:436
#9 0x58ac07f0a006 in main /home/d-tatianin/Projects/uACPI/tests/runner/test_runner.c:569
#10 0x752a55c2a600 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:59
#11 0x752a55c2a717 in __libc_start_main_impl ../csu/libc-start.c:360
#12 0x58ac07f049e4 in _start (/home/d-tatianin/Projects/uACPI/tests/runner/build-linux-64bits/test-runner+0x12a9e4) (BuildId: 86cac9384beae0bde0a4b9ac9f3f72e7ac3b01a8)
๐ญ
oh nice
nah
Or at least decompile it maybe?
I added uacpi_prepare_for_sleep_state to the test runner
SUMMARY: 681/689 in 105.85s (8 FAILED)
and one of those is my dump?
8 segfaults, all on gigabyte B5XX
gigabyte W
indeed, the first segfault is your dump
this one is yours I believe
yeah i think so judging by the name
@fiery ice what was your pc where our uacpi linux died on suspend?
Samsung galaxy book
yes
in this chat a while ago
for the pci stuff
if i remember correctly
and the suspend one
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
ill check it out a bit later
weird that it triggered ASAN in the test runner but not in the live kernel
nevermind i'm illiterate
lol
in case it helps (even if just to check whether you're reproducing the same issue): [ 37.987287] ACPI: PM: Preparing to enter system sleep state S3 [ 37.993268] ACPI: prepare_method_call: \_PTS [ 37.999361] ACPI: prepare_method_call -> OK [ 38.005383] ACPI: prepare_method_call: \_SB_.MPTS [ 38.011909] ACPI: prepare_method_call -> OK [ 38.017929] ACPI: prepare_method_call: \GSA1.MPTS [ 38.024454] ACPI: prepare_method_call -> OK [ 38.030459] ACPI: prepare_method_call: \GSA1.EZV8 [ 38.036995] ACPI: prepare_method_call -> OK [ 38.043028] ACPI: prepare_method_call: \GSA1.EZVH [ 38.049560] ACPI: prepare_method_call -> OK [ 38.055614] ACPI: prepare_method_call: \GSA1.MM01 [ 38.062138] ACPI: prepare_method_call -> OK [ 38.069271] ACPI: prepare_method_call: \GSA1.ISMF [ 38.075827] ACPI: prepare_method_call -> OK [ 38.081898] ACPI: prepare_method_call: \GSA1.HWC0 [ 38.088430] ACPI: prepare_method_call -> OK [ 38.199038] ACPI: prepare_method_call: \GSA1.SMM2 [ 38.205594] ACPI: prepare_method_call -> OK [ 38.211636] ACPI: prepare_method_call: \GSA1.SMB2 [ 38.218171] ACPI: prepare_method_call -> OK [ 38.224179] ACPI: prepare_method_call: \GSA1.SRDY [ 38.230711] ACPI: prepare_method_call -> OK [ 38.236877] ACPI: prepare_method_call: \GSA1.CMPL [ 38.243406] ACPI: prepare_method_call -> OK [ 38.249663] ACPI: prepare_method_call: \GSA1.SMM5 [ 38.256201] ACPI: prepare_method_call -> OK [ 38.262235] ACPI: prepare_method_call: \GSA1.SMB5 [ 38.268768] ACPI: prepare_method_call -> OK [ 38.274773] ACPI: prepare_method_call: \GSA1.SRDY [ 38.281291] ACPI: prepare_method_call -> OK [ 38.287467] ACPI: prepare_method_call: \GSA1.CMPL [ 38.293992] ACPI: prepare_method_call -> OK [ 38.300340] ACPI: prepare_method_call: \GSA1.CMN1 [ 38.306879] ACPI: prepare_method_call -> OK [ 38.313070] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
thanks
whats funny is this doesnt trace returns so we technically dont know which one caused it to die exactly
where do i add a printf to trace returns
hmm good Q
technically its ctx_reload_post_ret but there isnt a trivial way to extract the top most code block, which is the bounds of the method, which contains the method node
i mean i don't need to get the method node, if i just make sure to trace every return i can look at the prepare_method_call log to see what it returned from
ah true
manually indented for readability
huh ofc msvc doesnt catch it for some reason
uACPI][ERROR] loop time out after running for 3 seconds
[uACPI][ERROR] aborting method invocation due to previous error: hanging AML while loop
[uACPI][ERROR] #0 in \GSA1.SRDY()
[uACPI][ERROR] #1 in \GSA1.SMB2()
[uACPI][ERROR] #2 in \GSA1.SMM2()
[uACPI][ERROR] #3 in \GSA1.ISMF()
[uACPI][ERROR] #4 in \GSA1.EZVH()
[uACPI][ERROR] #5 in \GSA1.EZV8()
[uACPI][ERROR] #6 in \GSA1.MPTS()
[uACPI][ERROR] #7 in \_SB_.MPTS()
[uACPI][ERROR] #8 in \_PTS()
[uACPI][ERROR] error while evaluating _PTS: hanging AML while loop
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
yeah strange
maybe u misread the output
huh --log-level=debug gets rid of the crash??
Do other operating systems with uACPI and S3 sleep work? 
yeah no i'm pretty sure that's correct
something really weird is going on here
the fact that the log level change fixes it makes me think its some sort of a corruption
yeah
like its not even a compile time log level change
lemme try valgrind maybe
Yeah i managed to catch it with break interpreter.c:4118 if strcmp(why, "\GSA1.EZVH") == 0
ah fuck
it has Switch/Case
those are macros which are compiled down to while and breaks
ahh
does the aml decompiler have a "literal" option?
seems like it would be useful for stuff like this
it doesnt 
damn
@gentle peak can u try this fix locally
@@ -2103,11 +2107,8 @@ static void frame_reset_post_end_block(struct execution_context *ctx,
code_block_array_pop(&frame->code_blocks);
ctx->cur_block = code_block_array_last(&frame->code_blocks);
- if (type == CODE_BLOCK_WHILE) {
- frame->last_while = find_last_block(&frame->code_blocks, type);
- } else if (type == CODE_BLOCK_SCOPE) {
- update_scope(frame);
- }
+ frame->last_while = find_last_block(&frame->code_blocks, CODE_BLOCK_WHILE);
+ update_scope(frame);
}
i dont understand entirely why thats needed yet but it seems to fix it
successfully went to sleep and woke again!
send the iso
@hallow marten
very cool
its the most complex aml ive seen
it calls like 20 methods deep
at peak
this is what i use, it's not an iso but you can just extract it onto a fat32 partition and it'll work
note that performance is not representative, this build has kasan and ubsan enabled
hmm, i may xorriso it then
why bother unless you actually use a dvd
i use ventoy
i am a genius
as far as i can tell yeah
yeah it works now
theres a genuine uacpi bug with pointer re-hydration after dynamic array realloc
ah okay, if you do xorriso it you need to follow the limine xorriso instructions
it would only manifest in deeply nested call stacks
[ 3.588785] ACPI: successfully loaded 12 AML blobs, 10097 ops in 238ms (avg 42340/s)
still faster than nyaux ๐
i have a script to generate an iso locally but you could ask a clanker if you dont want to figure it out
i guess the next test is building it with some distro's .config and booting a proper distro with it
thats the real fix i think
@@ -4235,6 +4244,9 @@ static void refresh_ctx_pointers(struct execution_context *ctx)
ctx->cur_op_ctx = op_context_array_last(&frame->pending_ops);
ctx->prev_op_ctx = op_context_array_one_before_last(&frame->pending_ops);
ctx->cur_block = code_block_array_last(&frame->code_blocks);
+
+ frame->last_while = find_last_block(&frame->code_blocks, CODE_BLOCK_WHILE);
+ update_scope(frame);
}
basically pointer hydration was missing
ill add a helper for this i think, since theres some duplication going on there
and another callsite where hydration was missing but it never manifested
i guess normal aml execution is usually not as deeply nested as sleeping/suspend helpers stuff
that would be based af
God this makes me glad uACPI exists
lol
https://pastebin.com/pVePrxNA this is the method where it was dying
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
@gentle peak what was the cmd to sleep?
echo deep > /sys/power/mem_sleep && echo mem > /sys/power/state
thx
basically here u can see it calls really deep, which reallocates the call frame array, which then makes the cached context pointers point to incorrect memory
This is why you should've made it recursive
ehm, you sure it works?
on my pc it does
true 
what happens on yours?
not on mine
What happens
Logs would be nice
serial
it boots but suspend still dies?
ye
it's a laptop ๐
if you have a serial port and use the 2nd boot option (Linux uACPI - test shell on serial (for debugging suspend)) you get serial output through suspend
Can't wait for the uACPI patches to be in Gentoo repos so now people that configure their own kernels can use it
USB serial potentially may work?????
i don't have any serial adapter
If you have a USB C DRD port
lemme try your aml blob
I dont think u ever attached it
ig I can also try this on my pc for fun
though I don't think it has particularly cursed aml (at least in terms of errors)
that would be nice, if it dies then at least its a pc with a com
hmm ok doesnt segfault here but it doesnt get far in _PTS because my test runner is not real hardware
[uACPI][ERROR] loop time out after running for 3 seconds
[uACPI][ERROR] aborting method invocation due to previous error: hanging AML while loop
[uACPI][ERROR] #0 in \_SB_.QPTS()
[uACPI][ERROR] #1 in \_SB_.SPTS()
[uACPI][ERROR] #2 in \_PTS()
[uACPI][ERROR] error while evaluating _PTS: hanging AML while loop
While (!(PBTN & 0x02))
{
Sleep (0x64)
}
genius hardware
XD
looks like it did work, it suspended and resumed when I pressed a key on the keyboard (gpu didn't resume properly but typing poweroff -f made it shut down afterwards)
what gpu model do you have? the only drm modules i have compiled in are simpledrm, i915, and amdgpu
and the only firmware included in the initramfs is amdgpu
rtx 4070 ti s, yeah I guess then that makes sense
awesome!
commented the while loop out and recompiled dsdt, still no segfault, no hangs either
@fiery ice whats the model of that laptop?
galaxy book /750XDA-KC2IT
i5 1135g7
it does have a
Device (UAH0)
{
Name (_DDN, "SerialIoUart0") // _DDN: DOS Device Name
Name (_UID, "SerialIoUart0") // _UID: Unique ID
Method (_HID, 0, NotSerialized) // _HID: Hardware ID
hmm maybe its possible to capture those
Yeah and your logs say [ 0.138648] printk: legacy console [ttyS0] enabled
i wonder where the hell that outputs to
damn, I guess we'll have to wait for more test subjects that can repro this 
maybe evalyn?
yeah perhaps
i do have a serial port
il test tomorrow afternoon
i gotta finish up riscv/la64 stuff
Thanks, hopefully maybe we get a repro
dm me an iso incase i wakeup at 2am again so i can get out of the way then too
Here
I realized the hydration issue was just a stupid design decision, that piece of code doesnt really need to hold a pointer to the array, it just needs to know the index
which is what it does now
ill make a test case for it, also ill make all large tests run _PTS(3) on top
lets see if CI likes it
me when i thought my code was well tested but then I meet firmware devs
"I have a firm belief that most firmware developers are not actually humans, but are instead caged rodents fed a solid diet of crack cocaine. Because that would explain a lot."
- Linus Torvalds
isn't this your fault tho?
yeah this one is completely my fault
but to actually repro it you'd need like really complex aml
ill see if i can make clanker come up with a minimal repro so i can use it for a standalone test
so far the linux experiment has been extremely useful
exercising code paths that hobby kernels never touch and uncovering edge cases
@anthropic sponsor us
real
or lockheedmartin
rok is this true
why?
I was saying spacex cuz they just bought cursor
Not my fault itโs so easy to stub :p
Mecha uACPI
which is the greatest AI ever
What if we integrated grok into uACPI to dynamically handle complex AML?
we could just remove the interpreter entirely and just ask grok
grok what on earth were they thinking when they made this?
Money and white genocide

outsource workers paid for each loc
๐ญ
lmO
@gentle peak so the fix I gave u was more of a random bullshit go type of fix, I now added a proper one to master + tests, would be nice if you could do a quick re-test once you have the time
Wtf thats crazy
how long did it take
Did you make a bochs gpu driver also
like 8 hours total i think
nah this is just debugcon and uart
i currently do not do anything with acpi on wake
the only thing i do on wake is restore cpu state, irq controller state, and reinit serial
Yeah but when suspending, how do you configure the devices for wake?
That are allowed to wake you
oh i don't do anything with that
this is the entire acpi side of entering suspend
(arch_prepare_suspend does the waking vector stuff)
Ah, most likely on real hw it will cause it to just not wake up on key press
i checked, it doesn't
it handles SST but not TTS
Ah wait yeah, what was TTS again
no idea
Did u get that from linux?
linux does do it yes but i got it from the spec
Where repo btw
tried it on real hardware, for some reason serial only works if it's a warm boot (???) but more importantly it doesn't enter any sleep states correctly
not even S5
F
oh nevermind it just takes a while
worked
bad allocator or smth?
the allocator should be fine
hmm, usually at least S5 should be instant
it gets stuck in uacpi_enter_sleep_state_simple before disabling interrupts (since i still get power button! prints)
thats quite interesting
might just be a scheduler bug or something, the way i designed this isn't exactly conventional (it has no idle thread)
lol, what does it do if theres nothing to do?
this is fully cooperative scheduling, there's no preemption (whether from priority or timeslice stuff)
i could see firmware developers relying on the timeslice of the thread executing aml expiring or whatever
like maybe they do Stalls to wait for a software event idk
could be
what the fuck, there's an actual noticeable performance improvement in glxgears fps of all things
Year of the uacpi linux desktop
AUR package for linux-uacpi when?
uacpi hovers around 20k fps, acpica around 17k
Isn't glxgears more variable with stuff?
I've heard before somewhat
it's always been very consistent for me
And make sure to add the malware to it too

Mainline kernel when 
What the fuck
I wonder if there's some actual gpe traffic that uacpi handles faster
Crazy work as always what can I say
it might just be the changes made between the mainline kernel arch linux uses and the git master that uacpi-linux is based on
It's probably more of a kernel thing than acpi lol
Yep
or some PM difference where either uACPI or acpica doesn't work correctly
Yeah that could be a reason too
modern intel chipsets cannot run both the CPU and all chipset devices at maximal performance settings at the same time
its only ever a week or two behind or so iirc
you can dump cat /sys/bus/pci/devices/*/power/runtime_status
or similar to check if devices are properly being suspended
- check dmsg for PM issues
i am on a not-so-modern AMD chipset
anyway i did a few more random perf measurements ACPICA: Time-to-boot 18.50 s (started when pressing enter in GRUB, stopped when plasma-login-manager became visible) GLXGears FPS 17k-18k vkmark score 17193 Time-to-suspend 2.55 s (started when clicking sleep button in plasma launcher, stopped when fans stopped spinning) Time-to-wake 6.30 s (started when pressing power button, stopped when plasma lock screen visible) uACPI: Time-to-boot 16.63 s GLXGears FPS 19k-20k vkmark score 17758 Time-to-suspend 2.44 s Time-to-wake 5.78 s
the time measurements were done by hand so there's a fairly large margin of error there
Wait you ported uACPI to Linux?
i wasn't the one doing the porting
who was?
abbix with claude
hmm, did you all review the code?
and like fix it
if so Iโd honestly like seeing this getting into mainstream kernel
my involvement was limited to getting serial output from a device where suspend didn't work initially and using the kernel with an actual distro instead of just a busybox initramfs
surprisingly i don't think any of the issues we've encountered so far have been with the llm generated code
they've all been uacpi bugs that haven't been encountered before because of the limited scope of hobby kernels
Awesome
really cool
Iโd totally use that
Yes
@fiery turtle if you want some more stuff for acpidumps, this is from an MSI Venture 14 AI A2HMG-021NL laptop
i removed MSDM ofc but still
yeah it's my new laptop
I did try booting uacpi-linux but defconfig lacks a lot of the modules needed to be usable so I don't know how functional it really is
did it die on boot?
/sys/power/mem_sleep contains both s2idle and deep
although s2idle is selected by default
ah
nah it got to the desktop (plasma) but didn't have working audio, graphics accel, or touchpad
worth noting that this laptop isn't perfect for linux regardless
really?
even on the regular kernel installed by the distro I get driver errors from i915, aml errors, etc
and I had to disable the Intel vmd controller in the bios before I could really do anything
Can you show what the AML errors are btw?
ah yeah that proprietary crap
before I did this the entire system behaved very strangely
omg i was just yesterday reading how linux actually assigns iommu groups, and for vmd there is a special case
nvme io kept timing out randomly and for some reason the system could only even get into bash if I replaced the default loglevel=3 quiet with loglevel=7
lmao
and no matter what it couldn't get into a graphical environment
is there any chance your distribution doesn't have compiled in support for vmd?
$ sudo dmesg | grep 'ACPI Error'
[ 0.275562] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.275565] ACPI Error: Aborting method \_SB.PC00.XHCI.RHUB.HS02._PLD due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.289605] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.289608] ACPI Error: Aborting method \_SB.PC00.TXHC.RHUB.SS04._PLD due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.541321] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.541325] ACPI Error: Aborting method \_SB.PC00.TXHC.RHUB.SS04._PLD due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.541334] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.541336] ACPI Error: Aborting method \_SB.PC00.TXHC.RHUB.SS04._UPC due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.541346] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.541347] ACPI Error: Aborting method \_SB.PC00.TXHC.RHUB.SS04._PLD due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.543802] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.543803] ACPI Error: Aborting method \_SB.PC00.XHCI.RHUB.HS02._PLD due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.543809] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.543810] ACPI Error: Aborting method \_SB.PC00.XHCI.RHUB.HS02._UPC due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
[ 0.543818] ACPI Error: Missing argument(s) for method [RUCC] (20251212/dsmethod-486)
[ 0.543819] ACPI Error: Aborting method \_SB.PC00.XHCI.RHUB.HS02._PLD due to previous error (AE_AML_TOO_FEW_ARGUMENTS) (20251212/psparse-529)
wouldn't it just fail to boot at all in that case?
from what i can tell vmd is some storage thing so it shouldn't have been able to find the rootfs without supporting it
no idea, the thing i was looking was gated behind a config_vmd
they keep fucking up _PLD for some reason
maybe because those errors never show up in NT
but it definitely fails in this case also
or maybe they do and they just didn't care
its not super important
im not even sure what it needs the physical location of usb ports for
$ gunzip -c /proc/config.gz | grep VMD
CONFIG_VMD=m
CONFIG_MVMDIO=m```
well
who knows
btw if you get the time to do it, a PR into the acpi-dumps repo would be nice (with the real or fake hw id)
this was very annoying to do btw, the option was grayed out unless you pressed some secret key combo while in the bios
why are firmware devs like this
wtf
why do they even shove this vmd shit into consumer laptops
who even uses that
i mean i'm not sure this technically is a consumer laptop
like i'm a consumer yes but still
oh its not?
like i said i'm not sure
is it supposed to be a corporate laptop?
idk i got the vibe that it's supposed to be suitable as a corporate laptop in any case
The MSI Venture 14 AI A2HMG-021NL is a premium, AI-ready business and productivity laptop. Featuring an Intel Core Ultra 7 processor, Copilot+ support, and 32GB of RAM, it easily powers through demanding office workflows, multitasking, and media editing on its sharp 14-inch OLED display
clanker opinion 
copilot+ support
since its ai-ready i expect you to vibecode all of your stuff from now on
i don't think the npu has done a single thing since i got the laptop a month ago
the first thing i did was do a clean install and i don't really use any ai ever
what the hell even is copilot+
if i knew my hardware supported it, first thing id do is find out how to uninstall it
decided to compile uacpi-linux with the arch .config, wonder how long it'll take
filter by high refresh rate and >=32gb ram, sort by price low to high, look at cpu benchmarks for everything below like 1300eur
Does refresh rate really matter to you that much?
i got used to 180 Hz and now whenever i try to use 60 Hz i cannot help but notice the roughness of basically all animations
this one is 144 Hz which is enough to feel smooth to me
This tends to reduce over time
You get used to it if you use a 60hz monitor for like a day or two
oh yeah definitely but i didn't want to be switching between the two all the time
yeah
one of my monitors is 144, and the other is 60
over time i stopped noticing the difference at all lol
I can't notice the difference between my 75hz desktop and 120hz phone
...huh ```
ERROR: modpost: "acpi_gbl_FADT" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "acpi_gbl_FADT" [sound/soc/intel/avs/snd-soc-avs.ko] undefined!
is that the missing EXPORT_SYMBOL thing again?
yeah should be
Afaict the main use cases for NPUs etc are for example doing speed recognition locally such that you don't have to send audio to a remote server
it actually got less far with all the modules compiled in
it failed to mount /boot from fstab due to a timeout
journalctl shows a bunch of udevd hung worker warnings
then after a while there's this
then a bunch of kernel hung task warnings
there's also this earlier in boot which might be related?
for what it's worth though the aml errors I had with acpica disappeared
I'm actually very confused why this mount is timing out
because root is on the same device and that's already mounted successfully
and io on root works without any timeouts
if I disable timeout and let it wait forever it boots successfully
Looks like thats also in the i2c code
The i2c handler error here is most likely the cause, although I have no idea why it would fail
Or why it would hang somewhere also
that being said I still don't have working ethernet, audio, or touchpad
I'm guessing those all involve i2c in some way
Huh lol
Yeah likely
I guess first thing id investigate is that i2c error message, its possible clanker fucked up the handler installation since there's some differences in api there between acpica and uacpi
But the errors it produces are really strange
my thinking is that after the hung task warnings the kernel does something to free up whatever mount is blocking on but that takes longer than the timeout
Yeah maybe
would it by any chance involve one of these functions
I think it's acpi_install_address_space_handler family of helpers
also whats strange is it hangs on some mutex lock, even outside of any uACPI code ๐ค
id guess that has something to do with the i2c stuff as well
yeah probably
like maybe whatever's holding the mutex is waiting on something that would get done by the i2c space handler
could be
But also it wasnt hanging before you recompiled with the new config right? Did that have i2c disabled or smth
well the old config was just defconfig with uapci, amdgpu, and nvme
I doubt it had i2c and, even if it did, the specific i2c device used here
hm yeah defconfig probably didnt have it
added a few printfs
handle = ACPI_HANDLE(adapter->dev.parent); possible that this is NULL so it always tries to install them to root?
well the very next line below that is a null check
ah right
/* Check for an existing internal object */
obj_desc = acpi_ns_get_attached_object(node);
if (obj_desc) {
/*
* The attached device object already exists. Now make sure
* the handler is not already installed.
*/
handler_obj = acpi_ev_find_region_handler(space_id,
obj_desc->
common_notify.
handler);
if (handler_obj) {
if (handler_obj->address_space.handler == handler) {
/*
* It is (relatively) OK to attempt to install the SAME
* handler twice. This can easily happen with the
* PCI_Config space.
*/
status = AE_SAME_HANDLER;
goto unlock_and_exit;
} else {
/* A handler is already installed */
status = AE_ALREADY_EXISTS;
}
goto unlock_and_exit;
}
} else {
ACPICA has this check also
so something about that handle must be wrong or something?
it does seem to be using the same handle every time
hmm very interesting
like that would definitely fail under acpica
maybe the way clanker made parent resolution work is wrong
I should check whether this happens with the normal kernel
oh yeah true, try replacing the uacpi config with normal acpica
and keep these logs
I'll need to replicate the logs in drivers/acpi/acpica but yeah
u could probably put them directly in i2c-core-acpi.c?
oh true
but then i'll have to properly recompile the module and regenerate the initramfs instead of just copying bzimage
seems like that file is part of CONFIG_ACPI, which should be y for you
okay this is weird
on acpica there's only one call to acpi_install_address_space_handler
oh nevermind they're just spread out more
hows the handle value looking
they are all on different handles though
yeah sounds like clanker fucked something up
and there's still not as many calls as with uacpi
there's only 7 where uacpi logged 9
could be that it retries some stuff in case it fails from different code paths
this is very strange
the specific i2c device objects that fail to install their space handlers on uacpi never even try to do so on acpica
wtf
$ sudo dmesg | grep 'space handler'
[ 1.116434] i2c i2c-0: installing i2c space handler, parent=0xffff8aff01d51410
[ 1.121845] i2c i2c-1: installing i2c space handler, parent=0xffff8aff0e781810
[ 1.760916] i2c i2c-2: installing i2c space handler, parent=0xffff8aff027870d0
[ 1.885632] i2c i2c-11: installing i2c space handler, parent=0xffff8aff1cc87000
[ 1.885819] i2c i2c-12: installing i2c space handler, parent=0xffff8aff1cc8a000
[ 1.885888] i2c i2c-13: installing i2c space handler, parent=0xffff8aff1cc8a800
[ 1.885948] i2c i2c-14: installing i2c space handler, parent=0xffff8aff1cc8e800
[ 4.358038] i2c i2c-15: installing i2c space handler, parent=0xffff8aff0312e0d0```
and if you look at the uacpi logs its i2c 3-10 that fail
maybe the way it checks for _STA on those is somehow returning the wrong value? Although that still doesnt explain the same parent handle
you should be able to generate the absolute path to the device object btw i think
when logging what's causing the early exit: Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-3: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-4: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-5: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-6: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-7: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-8: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-9: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE Jun 18 10:48:35 archlinux kernel: ACPI Error: Unknown exception code: 0xFFFFFFED (20251212/utexcep-41) Jun 18 10:48:35 archlinux kernel: i2c i2c-10: i2c space handler: acpi_bus_attach_private_data failed: UNKNOWN_STATUS_CODE
huh
thats so strange
thats on acpica right?
yeah
acpi_bus_attach_private_data calls acpi_attach_data, which is supposed to attach a user pointer to an aml namespace node, but uacpi doesnt even have a mechanism like that so it uses a clanker designed hash table
but why it would fail on acpica is beyond me
and with an UNKNOWN_STATUS_CODE
maybe log it as an int
oh the unknown_status_code is because acpi_bus_attach_private_data blindly returns -ENODEV instead of the actual acpi status
i'm adding a printf to acpi_bus_attach_private_data now
brilliant 
AE_ALREADY_EXISTS
๐
how the hell does it already exist for a unique i2c object
Does the clanker rolled hash table attachment check for duplicates also?
nope
Ah, that must be it
Ill add the native uacpi_namespace_node_attach_user_data in the next version anyway
these are the specific semantics acpica has
so you can have multiple data things on the same node if they have different handlers
handler is always the same tho, acpi_bus_private_data_handler
void acpi_bus_private_data_handler(acpi_handle handle,
void *context)
{
return;
}
EXPORT_SYMBOL(acpi_bus_private_data_handler);
very important
in this case yes but i'd like to actually be correct
yeah ofc
looks like its also called here https://elixir.bootlin.com/linux/v7.1/source/drivers/acpi/scan.c#L718, but with a different handler
this should work i hope
yeah looks correct
oh wait no i think i'm overriding e there
also I just realized: those functions errored on acpica anyway for those objects, they just did so silently, so this can't be the underlying issue
maybe something attached some data to them earlier?
no I mean that the whole i2c failed to attach thing can't be causing all the other issues I experienced
the timeouts, the lack of networking, touchpad, etc
ah, right
so does this same kernel boot with all of those working under acpica?
yes
maybe its not related to i2c afterall
also backlight brightness modification isn't working
yeah something really cursed is going on
Yeah they are good for background image bluring, speech recognition, maybe OCR things too.
This is why iphones have been shipping with them for ages
@gentle peak btw are you going to try to debug uacpi-linux hangs & other weird behavior on that laptop further? Id be happy to help where I can, would be cool to get that thing working
maybe in the future but not any time soon
Wake up babe, new uACPI feature dropped. AML backtraces are now more detailed, they include the offset within the method as well as the opcode that caused the failure. This should make pinpointing real hardware problems easier.
Some examples:
[uACPI][ERROR] aborting method invocation due to previous error: hanging AML while loop
[uACPI][ERROR] #0 in \HANG()+14/14 at WhileOp
[uACPI][ERROR] attempted access to deleted (<unknown>) operation region \CAS4.MYRE: invalid argument
[uACPI][ERROR] aborting method invocation due to previous error: invalid argument
[uACPI][ERROR] #0 in \CAS4()+47/47 at StoreOp
[uACPI][ERROR] unable to perform a read from field 00007385aade1d50: parent opregion gone
[uACPI][ERROR] aborting table load due to previous error: invalid argument
[uACPI][ERROR] #0 in \()+126/137 at DerefOfOp
[uACPI][ERROR] aborting method invocation due to previous error: reached maximum AML call stack depth
[uACPI][ERROR] #0 in \HANG()+9/9 at MethodCallOp
[uACPI][ERROR] #1 in \HANG()+9/9 at MethodCallOp
[uACPI][ERROR] #2 in \HANG()+9/9 at MethodCallOp
[uACPI][ERROR] #3 in \HANG()+9/9 at MethodCallOp
[uACPI][ERROR] attempted to perform an invalid implicit cast (String -> Package)
[uACPI][ERROR] aborting table load due to previous error: incompatible AML object type
[uACPI][ERROR] #0 in \()+372/775 at StoreOp
[uACPI][ERROR] Load: table size 17 is too small
[uACPI][ERROR] aborting table load due to previous error: invalid table length
[uACPI][ERROR] #0 in \()+56/370 at LoadOp
[uACPI][INFO] dynamic load of 'DSDT' (OEM ID 'uTEST' OEM Table ID 'TESTTABL')
[uACPI][ERROR] aborting table load due to previous error: invalid table length
[uACPI][ERROR] #0 in \()+145/370 at LoadTableOp
(not yet merged but going to be there for 6.0)
pretty!
imagine fuchsia gets uACPI
