uACPI - a portable and easy-to-integrate ACPI implementation

[fiery turtle]

Oh its xHCI

it doesnt have a hid but has _ADR probably

[north holly]

it does

have ADR

[fiery turtle]

Which

[north holly]

Name (_ADR, 0x00140000)```

[fiery turtle]

Yeah see if 14:00:0 is your xHCI

[north holly]

I have a INT3420

[fiery turtle]

So maybe u do put them into d3 via acpi as well even for pci, idk man

[north holly]

intel bluetooth rf kill

[fiery turtle]

What is that

[north holly]

this

[fiery turtle]

On that pc if u do lspci you will see xhci at 14

[north holly]

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)

indeed

[fiery turtle]

Yup

[north holly]

I wonder what an intel bluetooth rf kill

is

I don't even have bluetooth

[fiery turtle]

Hopefully it doesn't kill you

[north holly]

it's a CIA backdoor

or a backdoor installed by Hyper

[fiery turtle]

Indeed

[north holly]

interestingly, it actually uses OSI here

[fiery turtle]

Nothing interesting about that

They do osi to emulate backwards compat for old oses

[north holly]

wait

[fiery turtle]

Or for non windows

[north holly]

it has an OSI linux

[fiery turtle]

Its from 2013, so yes

[north holly]

I assume firmware devs were more considerate back then?

and not

"hello firmware dev"
"hello, I like money"
"why did you make this firmware?"
"money"

[fiery turtle]

Im afraid not

Wait a sec I'll link u the thing

[fiery turtle]

https://github.com/torvalds/linux/blob/0fc810ae3ae110f9e2fcccce80fc8c8d62f97907/drivers/acpi/osi.c#L139

[north holly]

ngl I expected it to be used more

[fiery turtle]

Thats because they do it on init and store the integer representation in a global variable

[north holly]

soon bios writers will be using _OSI("OBOS")

[fiery turtle]

E.g. 3 would mean windows xp, 4 windows vista, etc

Then they just check that variable

[north holly]

so that's what OSYS means

[fiery turtle]

Yup

[north holly]

you're funny

just magic numbers

[fiery turtle]

Ye

Well they have a preprocessor obviously

[north holly]

interestingly, the linux constant is used in some other unrelated place

wait it's 1000 hex

Sleep (0x03E8)```

[fiery turtle]

Workaround for some bug they had with it at the time probably

[fiery turtle]

Makes sense

[north holly]

yea

does uacpi report as windows

I think so

yeah it does

[fiery turtle]

By default it does

[north holly]

aaaand my ahci driver broke

[fiery turtle]

Its configurable

And u can tell it not to or tell it to report arbitrary stuff as supported

[north holly]

can I make obos an OSI string

[fiery turtle]

Sure

U can even uacpi_eval it yourself

[north holly]

waiting for the day obos becomes used world wide

[fiery turtle]

Server hardware does queries for more obscure kernels

E.g HP-UX etc

Various supervisors

Hypervisors*

[north holly]

I'll just make a very good hypervisor for obos
I'll optimize it as hell

(not)

[fiery turtle]

Indeed

[north holly]

then obos will be used for your everyday web server

or your router

then I become rich

and retire at the age of n

https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/device-power-states

rare MS documentation W

[fiery turtle]

Yeah

Ms docs are very good sometimes

https://docs.kernel.org/power/pci.html#

Also seems useful

[fiery turtle]

@north holly this one is actually really deep

[north holly]

I will read it

[fiery turtle]

Do it

[north holly]

it seems as if most of my devices might not actually be able to wake my system?

I checked the ps2 keyboard

and it didn't have neither S3D or S3W

only PRW

[fiery turtle]

U have xHCI

Which is what the keyboard is connected with

[north holly]

oh yeah

kinda like how on qwinci's thing

there was something to do with I2C

and PS2

[fiery turtle]

If your motherboard actually had a ps2 port it would be wakable too

[fiery turtle]

Ye

[north holly]

I'm just gonna quickly see what state the xHCI controller needs to be in

to wake me

_S3D is 2

PRW is 3 I think

S3W is NA

so I'd go into D state 2

but wait

I don't have _PS2

which must mean I missed a _S3W

but I didn't

To put a device into the ACPI power state Dx (where x is a number between 0 and 3 inclusive) the kernel is supposed to (1) enable the power resources required by the device in this state using their _ON control methods and (2) execute the _PSx control method defined for the device. In addition to that, if the device is going to be put into a low-power state (D1-D3) and is supposed to generate wakeup signals from that state, the _DSW (or _PSW, replaced with _DSW by ACPI 3.0) control method defined for it has to be executed before _PSx. Power resources that are not required by the device in the target power state and are not required any more by any other device should be disabled (by executing their _OFF control methods). If the current power state of the device is D3, it can only be put into D0 this way.

unrelated to the xHCI thing

but still useful

I honestly thought that suspend was gonna be a one or two day thing

now it technically was

but it doesn't work on real hw

therefore invalid

[north holly]

and is incorrect

[fiery turtle]

Why do you think it breaks all the time and no one gets it right

[north holly]

idk if any hobby os except for crescent has suspend

[fiery turtle]

Nope

And crescent doesn't suspend on real hw either I think

[north holly]

I think I should keep a list of devices I put into a deeper sleep state

so I can wake them after wake

might solve the framebuffer problem if it exists on real hw

somehow

[mortal yoke]

on my laptop it does make the screen go off and the power light too though then it wakes up after like a second or so, idk what exactly wakes it up tho (and I did at least try doing the proper wake device setup + making sure that all the other cpus are in a cli hlt loop)

and on my desktop at least I hear the psu click when it goes off and then it didn't wake until I pressed the power button (idk where exactly did it get at that point tho as the display was just blank and I didn't re-enable the sci irq yet so I could see if it responds to power button press by shutting it down)

[vast kestrel]

I won't be surprised if it wants you to use it for random hardware workarounds

[fiery turtle]

alright finally ready to merge

19 commits

getting closer and closer to 1.0

this is it as far as new features for 1.0 go, maybe i'll also do more eval shorthands

the rest is thread safety related stuff

[torpid root]

so 1.0 means api freeze

[fiery turtle]

ye

[fiery turtle]

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               19           3420            849          15713
C/C++ Header                    46           1012           1399           5298
C++                              4            433            517           2655
Python                           3            213             39            587
Markdown                         1             59              0            190
CMake                            3             25             14            119
YAML                             1             10              5             57
Meson                            1              2              0             23
-------------------------------------------------------------------------------
SUM:                            78           5174           2823          24642
-------------------------------------------------------------------------------

Looks like we're nearing 25k, but i dont expect it to grow much beyond that. Maybe only because of new test cases or something

thread safety (which is the final large piece) shouldnt increase the loc by a lot

and L for cloc, imagine not knowing what ASL is

[fiery turtle]

...back to this annoying branch I go

[fiery turtle]

wait did the last acpica maintainer get laid off

[deft canopy]

i hope not

[fiery turtle]

yeah they were really nice

[jaunty fox]

possibly

[fiery turtle]

lol wtf?

[deft canopy]

oh no oh no

[fiery turtle]

????

this cant be

[fiery turtle]

how did u know this

[jaunty fox]

i googled his name

https://reddit.com/r/Corvette/comments/1g1mgar/we_got_em_boys/

this also came up on google

these people are obviously pissed off and probably wrote Intel to sack him

[fiery turtle]

so what did he do exactly

[jaunty fox]

Police released a video of the vandalism recorded on Oct. 2 at 6 p.m. near Kaiser Westside Hospital. In the video, the man appears to kick and yank on the car’s side mirror.

Shortly after noon on Friday, Hillsboro police arrested 32-year-old Saket Dumbre near NE Amberglen Parkway and NE Evergreen Parkway. He is charged with first-degree criminal mischief for damaging the car, a Corvette.

https://www.kptv.com/2024/10/12/man-arrested-after-car-vandalism-caught-camera-hillsboro/

god he really went for that mirror

well there you go

[fiery turtle]

what the fuck

[jaunty fox]

now you can write to Intel and ask if they'll get you a green card to take over

[fiery turtle]

id be down

like this is comical

what are the odds

that this happens to be this one and only acpica maintainer

[jaunty fox]

i wonder what pissed him off so much

[fiery turtle]

poorly parked car?

[jaunty fox]

looks satisfactory to me

i don't know what americans think good parking looks like though

[leaden fox]

the aml madness got to him

[fiery turtle]

lool

[jaunty fox]

yes, probably the most likely conclusion

[leaden fox]

it's only a matter of time till it gets you too @fiery turtle

I tell you this shi is cursed

[fiery turtle]

acpica maintaier after i open 99999 issues about nt incompatibility or various segfaults

[jaunty fox]

he was burnt out from maintaining acpica alone and lashed out at a corvette

[leaden fox]

I can't imagine having to maintain something as vital as acpica alone though

that's actually awful

[fiery turtle]

acpica actually doesnt get updates

so there isnt much to maintain

he was just laizily reviewing a few prs once a few weeks

[jaunty fox]

in fairness it looks like linux is just doing their thing

they did the usual thing and stole the acpica code and put it into the linux tree at some point, reformatted and restyled it, and now work on it themselves

[fiery turtle]

but yeah you would expect it to be a vital critical component

but its just this one guy

[leaden fox]

sounds fucked either way

[fiery turtle]

well there is the uefi board too

and I think there are regular meeting there

i was promised a chance to maybe get a seat there at one point

[fiery turtle]

the cursed linuxize.sh script

[north holly]

yeah especially with me pinging you every 0.02 seconds while I'm implementing suspend

I now test suspend on real hw

[fiery turtle]

did u actually implement d states

[north holly]

No

Got too confusing

[fiery turtle]

what did u implement

[north holly]

Only difference that matters is that now I call PSW

[fiery turtle]

yea...

[fiery turtle]

any news

[north holly]

It no work

[fiery turtle]

F

[vagrant hull]

what a read lol

[strong heath]

if he was gonna be arrested might as well kick it harder

make it worth

crime is the same

[vale isle]

the implementors board or whatever?

i have a friend who's technically a member (licensees of UEFI or whatever are members apparently but idk much about how that works

they don't get to vote tho

[fiery turtle]

basically yes, people from all companies like intel, lenovo etc

[left orbit]

aren't they all based on one or few efi implementations? like from intel or something

by they i mean efi firmware that vendors like asus or lenovo ship

it would be kinda silly for everyone to make their own efi implementations

but i guess you gotta spend the shareholder money somehow

wasting it on buggy firmware is one way of course

[fiery turtle]

yeah but the uefi board also does acpi, and thats different per mb

and well they work on new features and stuff

[vast kestrel]

There are two modern bios vendors (companies selling bios as a product) I can think of, AMI and Insyde (historically also phoenix and Award), today I think both are based on edk2, but oems still have custom stuff like HP, Lenovo and Microsoft

With Microsoft the main selling point being written in Rust iirc

[fiery turtle]

Currently solving various thread safety puzzles like: if i dont lock here can this get copyobject'ed into under my feet

this is the main way for internal code to protect against copyobject

uacpi_object *uacpi_namespace_node_acquire_object(
    const uacpi_namespace_node *node
)
{
    uacpi_status ret;
    uacpi_object *obj;

    ret = uacpi_namespace_read_lock();
    if (uacpi_unlikely_error(ret))
        return UACPI_NULL;

    obj = uacpi_namespace_node_get_object(node);
    uacpi_object_ref(obj);

    uacpi_namespace_read_unlock();
    return obj;
}

and for user api there is no way to access the object at the node, only by deep copying it via uacpi_eval

[fiery turtle]

doubt

[north holly]

Well the smp trampoline worked

So I thought that it should obviously work when reused

[fiery turtle]

obviously

[fiery turtle]

    /*
     * These are stored here to protect against stuff like:
     * - CopyObject(JUNK, \)
     * - CopyObject(JUNK, \_GL)
     */
    uacpi_object *global_lock_object;
    uacpi_object *root_object;

i now store \ and _GL objects in the global uacpi context

first of all so i can protect against CopyObject, but also so that i dont have to race against them with AML and always have direct access where needed

[jaunty fox]

#3 0xffffffff800095da in uacpi_kernel_free (mem=0x0, size_hint=0) at ../../kernel/io/uacpi.c:199
#4 0xffffffff80019792 in item_array_clear (arr=0xffffc80000030098) at ../../vendor/uacpi/source/interpreter.c:49

normal?

[fiery turtle]

frees of null are pretty normal yeah, uacpi does them all the time

is this causing some trouble?

[jaunty fox]

no, i just couldn't remember if it was expected or not

uacpi is getting a more prominent position in keyronex in the future (the testbed kernel is getting a parallel tree of ACPI namespace nodes that the OS tree of devices associate themselves with) and the integration is new code

[fiery turtle]

i see, i could catch it at call site to cause less confusion for people ofc, but its generally pretty common to free NULL in C land i think

[fiery turtle]

nice!

[fiery turtle]

the docs above uacpI_kernel_free mention frees of null being a no-op i think

[fiery turtle]

Method (TEST) {
    OperationRegion(MYRE, SystemMemory, 0, 128)
    Field (MYRE, AnyAcc, NoLock) {
        FILD, 32
    }

    FILD = 1
    Return (RefOf(FILD))
}

Name (X, "")
Local0 = TEST()
CopyObject(DerefOf(Local0), X)

Debug = X

@mortal yoke new cursed test case dropped

This is expected to read from the MYRE operation region and return the previously written 1

uACPI wont pass it at this moment, but im in the process of making it do that

let me know what qacpi thinks

[mortal yoke]

time to test it ig

[fiery turtle]

i discover new cursed shit u can do with aml every day

making it pass unfortunately means that u can make an infinite chain of object -> ns node -> object -> ns node -> object

so either i add code to do it non recursively or i have to live with the fact that its possible to stack overflow uacpi

atm it does reference the namespace node, but it's marked as dangling and doesnt have an object backing it

so u cant read from this field

[mortal yoke]

it kinda works on qacpi, the opregion does reference a dangling namespace node but its not necessary to read from the op region

there are more field problems tho, ig its supposed to read the field when you deref it?

[fiery turtle]

Debug = X is supposed to print 1

Aka yeah it must actually read via MYRE

when u deref u just get a field object

u dont read it ofc

[mortal yoke]

ah yeah

[fiery turtle]

in this case X becomes the new FIDL container

[mortal yoke]

so its likely only an issue with my poor debug print lol

[fiery turtle]

so like it does actually do the read via MYRE and stuff?

[mortal yoke]

yes

[fiery turtle]

cool

so it must be possible to overflow qacpi too

[mortal yoke]

how would that work, I kinda want to try doing that lol

[fiery turtle]

im trying to come up with a test case

[mortal yoke]

or actually would that only happen if the namespace node is not destroyed at the end of the method?

[fiery turtle]

Method (FOO, 1) {
    OperationRegion(MYRE, SystemMemory, 0, 128)
    Field (MYRE, AnyAcc, NoLock) {
        FILD, 32
    }

    CopyObject(DerefOf(Arg0), MYRE)
    Return (RefOf(FILD))
}

Method (BAR) {
    OperationRegion(MYRE, SystemMemory, 0, 128)
    Field (MYRE, AnyAcc, NoLock) {
        FILD, 32
    }

    Return (FOO(RefOf(FILD)))
}

Method (TEST) {
    Name (X, "")

    Local0 = 100000

    Local1 = BAR()
    CopyObject(DerefOf(Local1), X)

    While (Local0--) {
       CopyObject(0, Local1) 
       Local1 = FOO(RefOf(X))
       CopyObject(DerefOf(Local1), X)
    }
}

TEST()

maybe something like that? idk i havent tested

it should make a chain of field -> opregion -> field -> opregion -> field -> opregion

Or rather, in the end it will be a field -> field -> field -> field -> field

so if u keep all of those references alive at the end you will recursively delete all of them

which should stack overflow

yeah i think this should work

it overwrites the opregion referenced by a field to also be a field

So iin the end the X object should be a chain of 10000 fields and an opregion at the end

[mortal yoke]

its an integer for some reason

[fiery turtle]

u probably read from the field somewhere where u shouldnt

[mortal yoke]

I think the local ref is getting destroyed somewhere and then it does a store with an implicit conversion

its copyobject but idk how do I actually fix that without breaking other stuff (that the tests test), looks like it does indeed cause a stack overflow with that field code tho

[fiery turtle]

hmm, how does it stack overflow if u said u deref the field?

[mortal yoke]

after I tried to fix it

[fiery turtle]

ah

but yeah u should probably fix it, because there shouldnt be any reads happening during DerefOf

[mortal yoke]

yeah, I think the same issue also occurs if you do stuff like ```
CopyObject(0, Local0)
Local0 = "abc"
Debug = Local0

[fiery turtle]

what happens in this case?

oh do u like always implicit cast via a local store?

[mortal yoke]

on local op it returns a special local reference stored within the actual local object (within the method frame) and then in copyobject it overwrites the local reference stored within the method frame so then any of the other code doesn't know its a local anymore

so then it does implicit conversion in the second store in the example I posted because it just sees Local0 as a normal integer object

[jaunty fox]

saket dumbnre's github account is now gone

[fiery turtle]

waaait

[jaunty fox]

oh no, he just renamed it

[fiery turtle]

your CopyObject actually modifies the object itself?

[mortal yoke]

the object data yes

[fiery turtle]

yeah i did that initially and it caused soo many problems

objects in uacpi are now immutable

i just do object_replace_child in CopyObject

so the object referenced by Local0 is replaced, not the Local0 itself

[fiery turtle]

this also means u must have a per-object mutex if u want to use it anywhere other than the interpreter

because it can get copyobject'ed into at any point in time

[mortal yoke]

oh yeah

[fiery turtle]

whereas in my object model i can just do

lock()
obj = node->obj
ref(obj)
unlock()

and im guaranteed that this object will remain the same

the only difference is e.g. if it's a string it can be modified via Index etc

but that wont cause a crash or anything

[fiery turtle]

also

i wonder if its an indefinite hiatus

[fiery turtle]

ffff9a0d5c7576ec: Method(TEST,0x0)
ffff9a0d5c757716: Name(X___,"")
ffff9a0d5c75771d: Store(TEST()
ffff9a0d5c780aea: {
ffff9a0d5c780aea: OperationRegion(MYRE,0x0,Zero,0x80)
ffff9a0d5c780af4: Field(MYRE,0x0)
ffff9a0d5c780afc: {
ffff9a0d5c780b01: FILD,32
ffff9a0d5c780b01: }
ffff9a0d5c780b01: Store(One,FILD)=0x1
ffff9a0d5c780b07: Return(RefOf(FILD)=<Obj=FFFF9A0D5C780BD0,Type=ObjAlias,Value=0xffff9a0d5c780de0,Buff=0000000000000000,Len=0>)
ffff9a0d5c780b0d: },Local0)=<Obj=FFFF9A0D5BBF2090,Type=ObjAlias,Value=0xffff9a0d5c780de0,Buff=0000000000000000,Len=0>
ffff9a0d5c757723: CopyObject(DerefOf(Local0=<Obj=FFFF9A0D5C77C430,Type=ObjAlias,Value=0xffff9a0d5c780de0,Buff=0000000000000000,Len=0>)=<Obj=FFFF9A0D5C75E238,Type=Unknown,Value=0x0,Buff=0000000000000000,Len=0>=<Obj=FFFF9A0D5C75E238,Type=Unknown,Value=0x0,Buff=0000000000000000,Len=0>,X___)=<Obj=FFFF9A0D5BBF2090,Type=Unknown,Value=0x0,Buff=0000000000000000,Len=0>
ffff9a0d5c75772a: Store(X___=<Obj=FFFF9A0D5C75E238,Type=Unknown,Value=0x0,Buff=0000000000000000,Len=0>,Debug)Unknown()
=<Obj=FFFF9A0D5BBF2090,Type=Unknown,Value=0x0,Buff=0000000000000000,Len=0>

    Method (TEST) {
        OperationRegion(MYRE, SystemMemory, 0, 128)
        Field (MYRE, AnyAcc, NoLock) {
            FILD, 32
        }

        FILD = 1
        Return (RefOf(FILD))
    }

    Name (X, "")
    Local0 = TEST()
    CopyObject(DerefOf(Local0), X)

    Debug = X

Looks like this test case causes a use-after-free in NT

because it thinks that Type=Unknown

so honestly fuck it, ill just keep the current behavior where the object stored at the node is deleted at the same time when the node is uninstalled

ill make sure that reads from this field will just abort execution instead of uaf

[left orbit]

is that just invalid aml? or should this work?

[fiery turtle]

the spec doesnt tell us if its valid or not

it returns a reference to a local object outside of the method

[left orbit]

that's interesting

[fiery turtle]

ACPI Error: Invalid descriptor 00635960 [Cached Object] (20220331/exresop-392) UAF in ACPICA as well

[mortal yoke]

yeah I guess nobody does that in practice if it doesn't even work on NT

[fiery turtle]

so annoying that we don't know what its supposed to do officially

and in general it says nothing about lifetimes

whether objects are allowed to escape the method where they're created

[mortal yoke]

ig Ill keep it in qacpi tho because idk how would I make it not work lol (and I did fix the copyobject issue, though it still copies the inner data to named objects but I left handling that for an another time because its more annoying and requires changes to stores as well and I'd rather not touch that code if I don't have to)

[fiery turtle]

well the way i do it is when a namespace node is uninstalled it just does node->obj = null; node->flags |= DANGLING_NODE;

and so when that field tries to access the opregion it aborts

and the node is deleted when its refcount drops to 0

[fiery turtle]

so u currently pass that test and also stack overflow on that other test?

[mortal yoke]

yes

[fiery turtle]

i see

thats one solution to it i guess

[mortal yoke]

I guess one possible fix for the overflow would be to make object destruction iterative but that's kinda annoying especially in c++

[fiery turtle]

for packages i just make a queue of objects to unref

and then when unrefing an object from a queue that might add even more objects to the queue

if its a nested package

i think this would work for this case too

[mortal yoke]

yeah it probably would

[fiery turtle]

uACPI thread safety has been excruciatingly painful

well for the most part because i have to resolve a few design issues to get there

currently banging my head against opregion handlers

since those need to have an opregion node reference, and also have the ability to run _REG, and also be able to be invoked from the interpreter, aka write-locked namespace context, but also unlocked for the duration of the client handler runtime

basically i have to be insanely careful to not cause a deadlock between subsystems

e.g.

thread0: thread1:
namespace_write_lock() opregion_lock()
opregion_lock(); to dispatch field r/w namespace_write_lock() to run _REG

what also makes the issue harder, is installing an opregion handler is done at device level

and then the installation recurses downwards and is applied to every opregion below

so it must run an arbitrary number of _REG methods

ig i have to queue them up to be run, and then run them once opregon_lock is released

[winter orbit]

Phoenix is still kicking

Oh that message is old oops lol

[fiery turtle]

lol

Hello there

[winter orbit]

Evening

Or afternoon

Getting close to make a draft PR for the new ACPI driver

Want me to add you to the discussion when I open it :)

[fiery turtle]

Damn, thats really cool

Yeah of course

[winter orbit]

It’ll probably get a little bit argument fair warning

[fiery turtle]

i could point out any api usage errors maybe if i spot any

[fiery turtle]

yeah i mean

thats probably expected

[winter orbit]

Really improved things when hooked up together with my WDDM work though

Can actually use interrupts with WDDM drivers properly now

[north holly]

Wow

Infy is based

[fiery turtle]

Really based!

[fiery turtle]

no ur based

[north holly]

No u

[leaden fox]

Is your fork already viewable?

[jaunty fox]

locking really is one of the hellish problems

probably the area in which i have had to develop the most to carry out keyronex properly

[torpid root]

page fault in namespace_load

[fiery turtle]

nooo i believed in your allocator

[north holly]

Skill issue

[torpid root]

uacpi issue of course

[fiery turtle]

lmao

is it real hw or qemu at least

[torpid root]

qemu

[fiery turtle]

lol

definitely uacpi issue

[torpid root]

so it's most likely the allocator?

[fiery turtle]

probably yes, because on namespace load it allocates quite a lot

didnt u have it working before

[torpid root]

I'm rewriting my kernel

but I use the same allocator

[fiery turtle]

ah

why rewrite btw?

[torpid root]

I don't really know tbh. I just didn't like the old one very much, plus I want to redesign some things and copy less code lol

and c++ modules

[fiery turtle]

i see

good luck!

[torpid root]

thanks!

found the issue

I was forgetting to allocate the space for the metadata

[fiery turtle]

how did it not break before in your last kernel lol

[torpid root]

it was fine in the previous one :D
I just experienced a brief skill issue while rewriting it

does uacpi append \n to log messages

seems like it does

[fiery turtle]

ye

[torpid root]

what might this be

[fiery turtle]

mutex

[torpid root]

?

[fiery turtle]

your mutex helpers

[torpid root]

I'm sorry I don't quite understand what you mean

because I have those implemented

[fiery turtle]

i mean just add printfs and see where you're returning this

those methods are serialized so it tries to acquire the mutex

[torpid root]

I don't have pci_read/write

could that be the issue?

[fiery turtle]

oh yeah

i mean its a PCI Link device lol

[torpid root]

yeah I just noticed :D

pci can wait for tomorrow

[fiery turtle]

lol

just copy old code

[undone wedge]

What actually needs to run concurrently? The performance of what is improved?

[fiery turtle]

context?

in general: any sort of driver initialization that binds to aml objects (so a lot of them), AML handlers, runtime GPE stuff, EC stuff

a lot of things

[undone wedge]

The context is your work on uACPI thread safety

I just realized I have no clue why it would be useful

[fiery turtle]

because things might run in different threads

[undone wedge]

Well, yeah, but unless you ran them a lot or just generally cared about their performance, a big lock would be enough

[fiery turtle]

a big lock sounds like a big L

[left orbit]

(it is)

[undone wedge]

So is needless work, so I wondered why it is needed

[torpid root]

because people like W s and not L s

[fiery turtle]

well as i mentioned, a lot of aml is called both at runtime and during initialization. a lot of uacpi api is used not directly related to aml for all of those things too

so it is definitely not needless work

[undone wedge]

I assumed it was needed, didn't mean to offend, I just realized I personally didn't know why

[fiery turtle]

none taken, fair question

[undone wedge]

cool

[fiery turtle]

I was struggling with some thread safety stuff as always

Essentially if u use just the namespace write lock it must be released for the duration of the user opregion handler, and during that window if the user calls uninstall_address_space_handler there's basically a race condition with the handler being uninstalled while it's being dispatched to etc

I was like how does ACPICA solve it

They should've had a similar problem right

Well

It doesnt solve it at all

It just lets the code crash in this case

big brain library

I like how any edge case i come up with ACPICA just straight up doesnt give a shit

am i being too pedantic or something idk

if (AcpiNsIsLocked)
{
    Status = AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE);
    if (ACPI_FAILURE (Status))
    {
        return_VOID;
    }
}

/* Now stop region accesses by executing the _REG method */

Status = AcpiEvExecuteRegMethod (RegionObj, ACPI_REG_DISCONNECT);
if (ACPI_FAILURE (Status))
{
    ACPI_EXCEPTION ((AE_INFO, Status, "from region _REG, [%s]",
        AcpiUtGetRegionName (RegionObj->Region.SpaceId)));
}

if (AcpiNsIsLocked)
{
    Status = AcpiUtAcquireMutex (ACPI_MTX_NAMESPACE);
    if (ACPI_FAILURE (Status))
    {
        return_VOID;
    }
}

like

no u can't just release the goddamn lock

oh i also found a bug in their opregion cleanup code

it calls ReleaseMutex instead of DeleteMutex

i guess i should fix it while im at it anyway lol

but SaketDumbre might not be able to accept it

[mortal yoke]

I wonder what happens if you compile acpica with asan

[leaden fox]

actually based

[fiery turtle]

wait im actually brain damanged

i just spent an hour inventing a solution for a problem i didnt have

anyways that hour was wasted but at least now i know i was doing redundant work in one place

I invented a special queue to queue _REG methods to run at a later point with mutex released

but i literally didnt need to do that because i was doing uacpi_reg_all_opregions at the bottom anyway and it just rescans the namespace and runs _REG where needed and doesnt need a special queue to do that

so not only did i not need to do this, i also came up with a dumb overcomplicated solution

[fiery turtle]

/*
 * Returns UACPI_TRUE via 'out' if the type of the object stored at the
 * namespace node matches any of the type bits in the provided value,
 * UACPI_FALSE otherwise.
 *
 * NOTE: due to the existance of the CopyObject operator in AML, the
 *       return value of this function is subject to TOCTOU bugs.
 */
uacpi_status uacpi_namespace_node_is_one_of(
    const uacpi_namespace_node *node, uacpi_u32 type_mask, uacpi_bool *out
);

also added stuff like this

[fiery turtle]

Alright, about that ACPICA bug

https://github.com/acpica/acpica/pull/982

Will see if Saket is able review it

I even searched through the history and blames to figure out how they did this bogus stuff

looks like this bug is present in the Linux kernel as well, so ill send it there as well when the patch is accepted into acpica

on an unrelated note, they were leaking an entire mutex object for each opregion for 6 months and no one noticed

imagine not having any tests for this

[sterile egret]

lmao

[fiery turtle]

Hows uacpi thread safety going you may ask...

currently passing all tests, but still basically incorrect for all edge cases

interpreter, notify handlers, opregion handlers, namespace and stuff should be thread safe

the event subsystem is the last non thread safe one atm

still a lot of polish to do before this is even remotely mergeable

also i have 11 commits where the last one is a giant patch bomb

which is something i try to avoid

also uacpi_namespace_for_each_node_depth_first is now:

• uacpi_namespace_for_each_child_depth_first
• uacpi_namespace_for_each_child_depth_first_typed

where the typed helper accepts a bit mask of the types u care about

also i just realized i dont have any public api for checking if the current node is an alias lmao

[fiery turtle]

the amount of TOCTOU bugs in ACPICA is insane

yes those are difficult to trigger in real world but like

idk man

basically everything related to uninstalling any sort of handlers

which is not really done that much

[vagrant hull]

why do you even bother trying to fix ACPICA?

[fiery turtle]

nah its more like

i have this race condition, how do I protect against it

ACPICA must have had a similar problem, lets see how they did it

look inside: they did nothing

[vagrant hull]

lol

[fiery turtle]

i do fix stuff if i notice low hanging fruit or completely bogus shit

but race conditions like this are not trivial to fix so i wont bother ofc

[fiery turtle]

https://cdrdv2-public.intel.com/772754/intel-processor-vendor-specific-acpi.pdf

saving this here so i can go back later

[fiery turtle]

Thinking whether i should add a namespace_for_each_child with a max depth parameter, like ACPICA

Looked at the existing ~80 usages in the linux kernel

1. 80% is just UNIT32_MAX
2. 15% is 1
3. 4% is clearly bogus limits like 32 (where did they come up with those??)
4. 1% is 2

still not sure but maybe ill still add it as a separate helper

u can currently emulate it in uacpi by just doing if (namespace_node_depth(node) == X) return NEXT_PEER

[fiery turtle]

/*
 * Depth-first iterate the namespace starting at the first child of 'parent'.
 *
 * The extended helper allows limiting the iteration depth with 'max_depth'
 * while also performing node filtering based on the 'type_mask'.
 *
 * uacpi_namespace_for_each_child_simple is equivalent to:
 * uacpi_namespace_for_each_child(..., UACPI_OBJECT_ANY_BIT, UACPI_DEPTH_ANY)
 */
uacpi_status uacpi_namespace_for_each_child_simple(
    uacpi_namespace_node *parent, uacpi_iteration_callback callback, void *user
);
uacpi_status uacpi_namespace_for_each_child(
    uacpi_namespace_node *parent, uacpi_iteration_callback callback, void *user,
    uacpi_object_type_bits type_mask, uacpi_u32 max_depth
);

whatever this is what it's gonna look like now

hmm fuck

ACPICA also has a way to specify ascending_callback

its used by linux only to offline busses upwards from child to parent

[fiery turtle]

alright im going to add the goddamn ascending callback as well lmao

lets break every user api in existance

pls vote: #polls message

[mortal yoke]

imo returning an enum like they do now is fine, if they would return status then it might be confusing where a particular status is coming from (as in whether it was an error while iterating or if it was an error returned by the user from the callback)

idk if its really a problem in practice though

[fiery turtle]

yeah i agree on that point

the only reason im considering this is there are like 5 different enums right now for this

i made the internal node find helper more verbose since thread safety and stuff

ret = uacpi_namespace_node_resolve(
    node->parent, "_REG", UACPI_SHOULD_LOCK_NO,
    UACPI_MAY_SEARCH_ABOVE_PARENT_NO, UACPI_PERMANENT_ONLY_NO, &reg_node
);

now every call is like this lmao

same goes for namespace iteration:

uacpi_namespace_do_for_each_child(
    device_node, do_run_reg, UACPI_NULL,
    UACPI_OBJECT_OPERATION_REGION_BIT, UACPI_MAX_DEPTH_ANY,
    UACPI_SHOULD_LOCK_NO, UACPI_PERMANENT_ONLY_YES, &ctx
);

[mortal yoke]

that's indeed a lot of enums lol

[fiery turtle]

well thats unrelated to that poll but yeah

i just dont like booleans as function parameters

when using enums like this its very hard to make a mistake and when u look at the call site u instantly know whats going on

@mortal yoke this works for u right?

// Name: CopyObject to predefined works
// Expect: str => HelloWorld

DefinitionBlock ("x.aml", "SSDT", 1, "uTEST", "TESTTABL", 0xF0F0F0F0)
{
    Method (HELO) {
        Return ("Hello")
    }

    Method (WRLD) {
        return ("World")
    }

    Method (MAIN) {
        CopyObject(HELO, \)
        CopyObject(WRLD, _GL)

        Return (Concatenate(\(), _GL()))
    }
}

[mortal yoke]

yes

[fiery turtle]

Nice

but also dont implement GL sooo

cheating

[mortal yoke]

I should implement that

[fiery turtle]

yes!

the test should probably be extended to attempt to write to a locked field after this copyobject

[mortal yoke]

also I found a funny field bug while I were implementing reads for fields > 8 bytes, I were using a 32-bit mask while reading the field so for a >= 8-byte field using 8-byte access size would cause a shift overflow

idk what I were thinking when I used an uint32_t there

[fiery turtle]

lol

at least u found it

[fiery turtle]

this passes for ACPICA also

BUT

// Name: CopyObject to predefined works
// Expect: str => HelloWorld

DefinitionBlock ("x.aml", "SSDT", 1, "uTEST", "TESTTABL", 0xF0F0F0F0)
{
    Method (HELO) {
        Return ("Hello")
    }

    Method (WRLD) {
        Return ("World")
    }

    Method (MAIN) {
        OperationRegion(NVSM, SystemMemory, 0x100000, 128)
        Field (NVSM, ByteAcc, Lock, WriteAsZeros) {
            FILD, 8,
        }

        FILD = 0xFF

        CopyObject(HELO, \)
        CopyObject(WRLD, _GL)

        If (FILD != 0xFF) {
            Return ("Locked field read-back failed")
        }

        Return (Concatenate(\(), _GL()))
    }
}

I made a slightly more complex version of the test

ACPICA:

ACPI Error: AE_BAD_PARAMETER, Could not acquire Global Lock (20200925/exutils-248)

ACPI Exec: Segmentation Fault

they really dont care about anything do they

[north holly]

Yeah don't do that unless it's like doX

[fiery turtle]

Updated comparison vs ACPICA in the readme

lemme know what u think

also added this example lol

[vagrant hull]

should i test uACPI on my new Arrow Lake PC? :^)

[fiery turtle]

yes!

u know the answer

[north holly]

Btw is the "bug" with 0 byte allocs fixed

[fiery turtle]

@north holly .

oberrow dementia any%

[north holly]

I was pretty sure you did

But I made sure

[fiery turtle]

well now u know for sure

[north holly]

until I forget again

[fiery turtle]

nooo

#polls message interesting

so far people think status codes are better

[deft canopy]

Lovely

[jaunty fox]

i'm less keen

it's not the end of the world either way

[fiery turtle]

so far almost a tie

[dusky glade]

i voted

EVERYONE VOTE ENUM CALLBACK

[fiery turtle]

did u even use this api lol

[dusky glade]

yes

[fiery turtle]

what for?

[dusky glade]

i use uacpi, as for the api no i dont use it in nyaux BUTTTTT i might use it soon :)

and I

like

enum callbacks

[fiery turtle]

well looks like they're here to stay

[dusky glade]

good enum callbacks are good\

only enum callback

[fiery turtle]

me when acpica maintainers ignore my prs

or well, the one maintainer

[dusky glade]

damn goverment ignoring infys prs 😡

#down with acpica

acpica is making the frogs acpi error

[deft canopy]

didnt the maintainer get arrested or smth?

[hasty plinth]

Yeah he did

Something about vandalizing a corvette

[north holly]

That makes acpica unmaintained, no

Another acpi lib bites the dust

[hasty plinth]

For now, I don't imagine it's a situation everyone's comfortable with if it's true

Perfect time to add an acpica compat layer to uacpi and get it mainlined

[fiery turtle]

Lmao

[fiery turtle]

Well they still have GitHub activity

Like starring random repos

So I imagine not

[jaunty fox]

He'll be on bail

Probably won't get a life term without parole just for smashing a corvette

[fiery turtle]

u mean vacation

[kindred beacon]

can't blame anyone for doing that

ugly shit car

[fiery turtle]

Okay so

the poll looks like people like the enum values

but ill still generalize the enum to just uacpi_iteration_decision, it can be reused for everything, with an extra UACPI_ITERATION_DECISION_NEXT_PEER specific to namespace iteration

[kindred beacon]

enums bad, proof by ignoring democracy

[dusky glade]

keep yourself safe

[fiery turtle]

I also deretardefied my uacpi_kernel_get_ticks kernel api, it's now called uacpi_kernel_get_nanoseconds_since_boot and returns a regular nanosecond counter instead of 100ns ticks

i handle the conversion to 100ns ticks where needed internally

should be harder to make mistakes in api implementations

[north holly]

This is the stuff I do for that, kinda retarded https://github.com/OBOS-dev/obos/blob/userspace-work/src%2FuACPI%2Fkernel_api.c#L321-L332

[fiery turtle]

yeah i guess u dont have to now

[uACPI][INFO] successfully loaded & executed 1 AML blob in 533ms
[uACPI][INFO] namespace initialization done in 8ms: 188 devices, 0 thermal zones

Would u guys like it if i added these in Xms into the log?

[north holly]

Sure

[fiery turtle]

i kinda also want to add how many opcodes and the total bytecode bytes executed lol

maybe thats going a bit too far

ill see if someone else says their thoughts on this

[north holly]

More useless stats that have no performance

[fiery turtle]

personally i enjoy seeing metrics like this but overall they're useless and just add extra noise to the log

[north holly]

Just add config options for it

Obos at the end of initing the kernel

Says all vmm stats

The line wraps cause of how much

[fiery turtle]

i dont want to grow entropy for no reason

with infinite config options

[north holly]

It has committed memory, pageable memory, non-pageable memory, memory paged out, uncommitted memory, amount of page faults, amount of soft page faults, amount of hard page faults, amount of page faults since the last paging interval, amount of soft page faults since the last paging interval, and amount of hard page faults since the last paging interval

[north holly]

Also physical memory usage

https://github.com/OBOS-dev/obos/blob/userspace-work/src%2Foboskrnl%2Fmm%2Fcontext.h#L80-L104

So all of these

And this https://github.com/OBOS-dev/obos/blob/userspace-work/src%2Foboskrnl%2Fmm%2Fpage.h#L90

[torpid root]

yes

[hasty plinth]

Me too, maybe hide all the additional stats behind a more verbose log level so it's opt in?

[fiery turtle]

hows this
[uACPI][INFO] successfully loaded & executed 1 AML blob in 826ms (9192 opcodes, avg 11116 ops/s)

(this is slow because its using O0 + asan + ubsan + builtin uacpi libc which is slow af)

[fiery turtle]

ngl i like these stats

maybe needs to be less verbose somehow

[mortal yoke]

even if its not that useful its always fun to see metrics like that

[torpid root]

what's the average time in a kernel?

[fiery turtle]

no idea, this is on a very wip PR branch

depends on how advanced the kernel is

its very libc + allocator bound id imagine

[fiery turtle]

also test runner records every uacpi allocation in a hash table which doesnt help lmao

[fiery turtle]

i guess if i merge this people would be able to brag about how fast their kernel is

inb4 nyaux 1 op per second

(jk nyaux pls dont get offended)

[hasty plinth]

uacpi is now a stress and performance test 😆

[torpid root]

lol

[fiery turtle]

lmao

[hasty plinth]

Very satisfying to read

[fiery turtle]

glad u like it

i would kinda enjoy seeing something like this in my kernel log

[hasty plinth]

Its not all that practical, but I like seeing those kind of stats

Or more generally interrupts/sec, kernel vm/pm memory usage.

[fiery turtle]

in some sense it is a good benchmark because it uses like most critical kernel infra, like vmm, slab, mutexes, io, stuff like that

[fiery turtle]

yeah

[north holly]

io isn't really tested that much tho

Literally just port io and mmio

[zenith crescent]

I like that

[north holly]

@fiery turtle my time is now synced with Moscow time

So now I will tell you to go to sleep since it's 12am

[fiery turtle]

are u in turkey

[north holly]

Saudi arabia

In medina

[fiery turtle]

ah

my sleep schedule is fucked

i can barely go to sleep at 3

[north holly]

Now I know full well I'm not going to sleep for another couple hours

[jaunty fox]

on pilgrimage?

[fiery turtle]

are u back from vacation?

[north holly]

Soon

Two days

[north holly]

22nd I go back

[fiery turtle]

i see

[north holly]

Then I'm back on obos grind

[fiery turtle]

whats next for obos

[north holly]

Still on pci

I had a road map somewhere

[north holly]

#1141057599584878645 message

[fiery turtle]

glgl

[north holly]

Thanks

[north holly]

Although before mlibc, I might port to esp32

We'll see how that goes

[fiery turtle]

it doesnt even have an mmu

[north holly]

It haves something resembling one

SHOULD be good enough

If that doesn't work it's riscv port

Risc v 64 because I quite like 64 bit arches

Or maybe even both

And if I decide riscv is yuck

I do i386

[fiery turtle]

be ahead of fadanoid and do ppc64le

[north holly]

I feel like by the time I get to porting fadanoid would've started

Because I have a hell lot of syscalls to implement

And I'm gonna needa implement TTYs

I expect that all to be mid December at the earliest

m68k took a week to port

So I assume most other ports should take around the same time

[jaunty fox]

i'll source a powerpc box at some point

it might be a powermac g5 though (affordable and generally of good quality) and that's big endian

[hollow elm]

is it forced to be BE or can you toggle it

[jaunty fox]

in principle supporting open firmware on a powermac g5 should be a great leap towards supporting the linux version of device trees

[jaunty fox]

you know, i thought forced, but i also know that windows/ppc was little-endian

[hollow elm]

i'd guess you can switch but in LE you lose access to openfw

[fiery turtle]

he was forced to use big endian <insert gif>

[jaunty fox]

apparently not the powerpc 970 (g5) actually

[north holly]

I hate big endian

[jaunty fox]

little endian mode was a concession to microsoft so when microsoft deported windows from powerpc, that was the end of that

[north holly]

m68k was a beautiful arch

[fiery turtle]

wdym was

[north holly]

Who uses it but fadanoid and I

Also obos' WIP branch hasn't updated any m68k things

So it fails to compile

[jaunty fox]

the powermac g5 can support kvm on linux so that's the important thing, that makes for a pleasant medium between emulation and native, one where the subtleties of the architecture leak through but you still have the conveniences of qemu

[fiery turtle]

damn there is even a powerpc kvm?

[jaunty fox]

it's very popular

[fiery turtle]

nice

[fiery turtle]

fadanoid what do u think of this

[jaunty fox]

i approve, this will make for interesting comparisons

[fiery turtle]

well thanks for your input

[jaunty fox]

i think uacpi will benefit from cultivating its corporate identity by introducing distinctive textual expressions of its philosophy

[fiery turtle]

lol

[jaunty fox]

you can even put up a pretentious branding page about it

[fiery turtle]

and a blogpost to hn

[jaunty fox]

does ACPICA do that printout in the linux boot process where you see the tables?

[fiery turtle]

hmm no i think thats linux

[mortal yoke]

I am pretty sure its acpica, iirc I also saw them when I tried porting acpica to my kernel at some point https://github.com/acpica/acpica/blob/master/source/components/tables/tbprint.c#L251

[fiery turtle]

ohh interesting

i wonder if i should add a printout like this too

more logs more attention to uacpi bigger ego

[hasty plinth]

Indeed, who else could use be using it 🤔

[north holly]

You rewrote your thing, no?

[hasty plinth]

Yeah but the loader still exists

And the arch layer of the rewrite is basically the same anyway, 68k and rv64 support should be trivial once I get the motivation 😔

Anyway I have my own progress thread, I should post an update there lol

[fiery turtle]

my acpica pr finally got merged lol

only a two week delay

should also send into the linux kernel probably

[torpid root]

🎉

[jaunty fox]

i wonder if intel kept him on despite you-know-what

[fiery turtle]

his profile still says he's on vacation but not sure

[jaunty fox]

maybe they suspended him and then realised he would be hard to replace and decided to weather the angry corvette owners sending them emails demanding his head

[fiery turtle]

lmao

[jaunty fox]

or maybe he is gone

[fiery turtle]

There's also Robert Moore, who is i guess the OG maintainer, who is mostly doing stuff around the linux kernel these days

maybe they will get him back

[hollow elm]

acpibob

[fiery turtle]

thats the guy

[fiery turtle]

hmm unlucky test case

[uACPI][TRACE] load of 'DSDT' (OEM ID 'uTEST' OEM Table ID 'RUNRIDTB')
[uACPI][WARN] BUG: attempting to free an opregion@0000606000000440 with a handler attached
=================================================================
==562==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000000478 at pc 0x55ef1944726d bp 0x7ffee1116720 sp 0x7ffee1116710
READ of size 8 at 0x606000000478 thread T0
    #0 0x55ef1944726c in find_previous_region_link /mnt/d/uACPI/source/opregion.c:186
    #1 0x55ef19447f2c in region_uninstall_handler /mnt/d/uACPI/source/opregion.c:281
    #2 0x55ef19448975 in uacpi_opregion_uninstall_handler /mnt/d/uACPI/source/opregion.c:325
    #3 0x55ef1943cf8b in uacpi_namespace_node_uninstall /mnt/d/uACPI/source/namespace.c:404
    #4 0x55ef1942f9fb in call_frame_clear /mnt/d/uACPI/source/interpreter.c:4374
    #5 0x55ef194388a8 in ctx_reload_post_ret /mnt/d/uACPI/source/interpreter.c:5593
    #6 0x55ef194397e3 in uacpi_execute_control_method /mnt/d/uACPI/source/interpreter.c:5712
    #7 0x55ef1940a44b in do_load_table /mnt/d/uACPI/source/interpreter.c:1274
    #8 0x55ef1940d243 in uacpi_execute_table /mnt/d/uACPI/source/interpreter.c:1539
    #9 0x55ef193dcaa2 in uacpi_table_load_with_cause /mnt/d/uACPI/source/tables.c:1063
    #10 0x55ef193ebb8f in uacpi_namespace_load /mnt/d/uACPI/source/uacpi.c:371
    #11 0x55ef1933676e in run_test /mnt/d/uACPI/tests/runner/test_runner.cpp:480
    #12 0x55ef19338b8b in main /mnt/d/uACPI/tests/runner/test_runner.cpp:616
    #13 0x7f209ae6bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #14 0x7f209ae6be3f in __libc_start_main_impl ../csu/libc-start.c:392

forgetting to bump a reference count somewhere i guess?

[fiery turtle]

OperationRegion(MYRE, SystemMemory, 0, 128)
Field (MYRE, AnyAcc, NoLock) {
    FILD, 32
}
CopyObject(123, MYRE)

getting closer to a simple reproducer

==598==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f40cb2cd887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55fdca36ffad in uacpi_kernel_alloc /mnt/d/uACPI/tests/runner/interface_impl.cpp:227
    #2 0x55fdca457407 in uacpi_install_address_space_handler /mnt/d/uACPI/source/opregion.c:556
    #3 0x55fdca45b8ba in uacpi_install_default_address_space_handlers /mnt/d/uACPI/source/default_handlers.c:400
    #4 0x55fdca3f869c in uacpi_initialize /mnt/d/uACPI/source/uacpi.c:303
    #5 0x55fdca34353c in run_test /mnt/d/uACPI/tests/runner/test_runner.cpp:429
    #6 0x55fdca345b8b in main /mnt/d/uACPI/tests/runner/test_runner.cpp:616
    #7 0x7f40ca6b1d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

[fiery turtle]

nvm i get it

the opregion handler is uninstalled when a node is removed from the namespace

but here the node gets overwritten so the handler object is just unreferenced and not uninstalled

welcome to this weeks episode of obscure aml edge case that must be solved even though its impossible to encounter in the real world

[fiery turtle]

fixed this bug!

+static uacpi_iteration_decision opregion_detach_from_parent(
+    void *user, uacpi_namespace_node *node, uacpi_u32 node_depth
+)
+{
+    uacpi_object *target_object = user;
+    UACPI_UNUSED(node_depth);
+
+    if (node->object == target_object) {
+        uacpi_opregion_uninstall_handler(node);
+        return UACPI_ITERATION_DECISION_BREAK;
+    }
+
+    return UACPI_ITERATION_DECISION_CONTINUE;
+}
+
 static void object_replace_child(uacpi_object *parent, uacpi_object *new_child)
 {
+    if (parent->flags == UACPI_REFERENCE_KIND_NAMED &&
+        uacpi_object_is(parent->inner_object, UACPI_OBJECT_OPERATION_REGION)) {
+
+        /*
+         * We're doing a CopyObject or similar to a namespace node. Try to find
+         * the parent node and manually detach the handler.
+         */
+        uacpi_namespace_do_for_each_child(
+            uacpi_namespace_root(), opregion_detach_from_parent, UACPI_NULL,
+            UACPI_OBJECT_OPERATION_REGION_BIT, UACPI_MAX_DEPTH_ANY,
+            UACPI_SHOULD_LOCK_NO, UACPI_PERMANENT_ONLY_NO, parent
+        );
+    }
+
     uacpi_object_detach_child(parent);
     uacpi_object_attach_child(parent, new_child);
 }

it was actually non-trivial as we have to scan the namespace to find the parent namespace node that is responsible for the opregion

So that even when it's an anonymous reference to a named object it still works:

OperationRegion(MYRE, SystemMemory, 0, 128)

Method (REPL, 1) {
    Arg0 = 123
}

REPL(RefOf(MYRE))

[fiery turtle]

and this now just times out as expected:

[uACPI][TRACE] load of 'DSDT' (OEM ID 'uTEST ' OEM Table ID 'RUNRIDTB')
[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 \TEST()
[uACPI][INFO] successfully loaded 1 AML blob in 3001ms (1054988 ops, 351526/s)

[fiery turtle]

this is fixed too

[torpid root]

uacpi_initialize(0);
uacpi_namespace_load();
uacpi_namespace_initialize();
uacpi_finalize_gpe_initialization();
// ...
uacpi_install_fixed_event_handler(
    UACPI_FIXED_EVENT_TIMER_STATUS,
    [](uacpi_handle) -> uacpi_interrupt_ret
    {
        log::debug("SCI");
        return UACPI_INTERRUPT_HANDLED;
    }, nullptr
);

before I start debugging why the interrupt isn't triggered, is there anything else I need to do to receive pmtimer SCIs?

[fiery turtle]

@mortal yoke I came up with some nasty test cases for opregions

// Name: CopyObject with Operation Region works
// Expect: int => 0

DefinitionBlock ("", "DSDT", 2, "uTEST", "TESTTABL", 0xF0F0F0F0)
{
    Method (REPL, 1) {
        Arg0 = 123
    }

    Method (CAS0) {
        OperationRegion(MYRE, SystemMemory, 0, 128)
        Field (MYRE, AnyAcc, NoLock) {
            FILD, 32
        }
        FILD = 1

        CopyObject(123, MYRE)
    }
    CAS0()

    Method (CAS1) {
        OperationRegion(MYRE, SystemMemory, 0, 128)
        Field (MYRE, AnyAcc, NoLock) {
            FILD, 32
        }
        FILD = 1

        REPL(RefOf(MYRE))
    }
    CAS1()

    Method (CAS2) {
        OperationRegion(MYRE, SystemMemory, 0, 128)
        Field (MYRE, AnyAcc, NoLock) {
            FILD, 32
        }
        FILD = 1

        Name (FAKE, 123)
        CopyObject(MYRE, FAKE)
        Field (FAKE, AnyAcc, NoLock) {
            FAKF, 32
        }

        REPL(RefOf(MYRE))
        FAKF = 1
    }
    CAS2()

    Method (CAS3) {
        OperationRegion(MYR0, SystemMemory, 0, 128)
        OperationRegion(MYR1, SystemMemory, 0, 128)
        CopyObject(123, MYR1)
    }
    CAS3()

    Method (CAS4) {
        OperationRegion(MYRE, SystemMemory, 0, 128)
        Field (MYRE, AnyAcc, NoLock) {
            FILD, 32
        }

        FILD = 1
        CopyObject(FILD, MYRE)
        FILD = 1
    }
    CAS4()

    Name (MAIN, 0)
}

Give this a try

[torpid root]

@fiery turtle

pleadyeehaw

[fiery turtle]

this should be enough

do u receive other SCIs, like the power button?

try installing that

[torpid root]

does qemu's "power down" send that?

[fiery turtle]

yup

[torpid root]

I'm not receiving it either

[fiery turtle]

yeah then its a bug on your side

[fiery turtle]

happy to report all of thse work in uACPI now:

[uACPI][TRACE] load of 'DSDT' (OEM ID 'uTEST ' OEM Table ID 'TESTTABL')
[uACPI][TRACE] write to [\CAS0.MYRE] (1 bytes) SystemMemory[0x0000000000000000] = 0x1
[uACPI][TRACE] write to [\CAS0.MYRE] (1 bytes) SystemMemory[0x0000000000000001] = 0x0
[uACPI][TRACE] write to [\CAS0.MYRE] (1 bytes) SystemMemory[0x0000000000000002] = 0x0
[uACPI][TRACE] write to [\CAS0.MYRE] (1 bytes) SystemMemory[0x0000000000000003] = 0x0
[uACPI][TRACE] write to [\CAS1.MYRE] (1 bytes) SystemMemory[0x0000000000000000] = 0x1
[uACPI][TRACE] write to [\CAS1.MYRE] (1 bytes) SystemMemory[0x0000000000000001] = 0x0
[uACPI][TRACE] write to [\CAS1.MYRE] (1 bytes) SystemMemory[0x0000000000000002] = 0x0
[uACPI][TRACE] write to [\CAS1.MYRE] (1 bytes) SystemMemory[0x0000000000000003] = 0x0
[uACPI][TRACE] write to [\CAS2.MYRE] (1 bytes) SystemMemory[0x0000000000000000] = 0x1
[uACPI][TRACE] write to [\CAS2.MYRE] (1 bytes) SystemMemory[0x0000000000000001] = 0x0
[uACPI][TRACE] write to [\CAS2.MYRE] (1 bytes) SystemMemory[0x0000000000000002] = 0x0
[uACPI][TRACE] write to [\CAS2.MYRE] (1 bytes) SystemMemory[0x0000000000000003] = 0x0
[uACPI][ERROR] unable to attach (SystemMemory) operation region \CAS2.FAKE: no handler found
[uACPI][ERROR] aborting method invocation due to previous error: no handler found
[uACPI][ERROR]     #0 in \CAS2()
[uACPI][TRACE] write to [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000000] = 0x1
[uACPI][TRACE] write to [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000001] = 0x0
[uACPI][TRACE] write to [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000002] = 0x0
[uACPI][TRACE] write to [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000003] = 0x0
[uACPI][TRACE] read from [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000000] = 0x1
[uACPI][TRACE] read from [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000001] = 0x0
[uACPI][TRACE] read from [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000002] = 0x0
[uACPI][TRACE] read from [\CAS4.MYRE] (1 bytes) SystemMemory[0x0000000000000003] = 0x0
[uACPI][ERROR] unable to attach (<unknown>) operation region \CAS4.MYRE: invalid argument
[uACPI][ERROR] aborting method invocation due to previous error: invalid argument
[uACPI][ERROR]     #0 in \CAS4()
[uACPI][TRACE] load of 'SSDT' (OEM ID 'uTEST ' OEM Table ID 'RUNRIDTB')
[uACPI][TRACE] [AML DEBUG] String => "TestRunner ID SSDT loaded!"
[uACPI][INFO] successfully loaded 2 AML blobs in 2ms (85 ops, 30504/s)
[uACPI][TRACE] initialized GPE block _GPE[0->128], 0 AML handlers (IRQ 0)
[uACPI][TRACE] initialized GPE block _GPE[128->256], 0 AML handlers (IRQ 0)
[uACPI][TRACE] fixed event 0 enabled successfully
[uACPI][TRACE] activated all 'EmbeddedControl' opregions controlled by '\   ', 0 _REG() calls (0 errors)
[uACPI][TRACE] activated all 'PCI_Config' opregions controlled by '\   ', 0 _REG() calls (0 errors)
[uACPI][INFO] namespace initialization done in 0ms: 0 devices, 0 thermal zones
[uACPI][TRACE] _STA calls: 0 (0 errors), _INI calls: 0 (0 errors)
[uACPI][TRACE] fixed event 0 disabled successfully

no leaks, no UAFs

[torpid root]

does using pic instead of ioapic have anything to do with it
or does it not matter

I don't think it should

[fiery turtle]

is there like a qemu info pic thing?

could look what that says

but shouldnt matter i think

[left orbit]

info irq i think?

[torpid root]

info pic

I guess the everything above bottom two lines is ioapic

[fiery turtle]

what do those regs mean?

[torpid root]

I'm trying to find that out

[left orbit]

info irq might be better

it tells you which irqs have been triggered and how many times

[vast kestrel]

I mean, looks like all of them are masked lel

[fiery turtle]

thats ioapic tho

[vast kestrel]

Oh wait yeah

Just use the ioapic smh

[torpid root]

I'm working on that

sci is supposed to be 9

but it's not triggered

[fiery turtle]

wth is i8259

[vagrant hull]

pic

[vast kestrel]

Pic

[torpid root]

pic

[fiery turtle]

pic

[vast kestrel]

Mint do you have a bpf on PC related related questions lol

[fiery turtle]

maybe sci is routed exclusively via ioapic on qemu, who knows

[torpid root]

maybe

[vast kestrel]

Nah unlikely

Does install actually enable the bit?

[torpid root]

I guess I'll find out in a few days, when I have the time

[fiery turtle]

yeah

i mean these fixed events worked for everyone

including astral, managarm and obos

[torpid root]

and my previous kernel

but I used ioapic

[vast kestrel]

Do you have pic interrupts for other hardware?

[torpid root]

pit works

[vagrant hull]

no

[torpid root]

nothing else yet

[vagrant hull]

just a coincidence i had it opened rn

[vast kestrel]

I guess you could boot Linux with noapic and see if it gets the shutdown button from qemu

[vagrant hull]

you can do ACPI without the apic on qemu

that's how the LAI test image did it and it worked fine (using the PIC)

[fiery turtle]

https://elixir.bootlin.com/qemu/v9.1.2/source/hw/isa/lpc_ich9.c#L427

yeah looks like it allocates a normal irq vector

should work with pic

[vast kestrel]

Yeah it has zero reason to do something else lel

[fiery turtle]

oh wait

[torpid root]

I install it like any other interrupt and unmask it

[fiery turtle]

    if (irq >= ICH9_LPC_PIC_NUM_PINS) {
        ich9_lpc_update_apic(lpc, irq);
    } else {
        ich9_lpc_update_pic(lpc, irq);
    }

[torpid root]

hm?

[vast kestrel]

Doesn't it always gets allocated as 9

[fiery turtle]

well the version im looking at doesnt have a hardcoded number

https://elixir.bootlin.com/qemu/v9.1.2/source/hw/isa/lpc_ich9.c#L357

[fiery turtle]

but yeah i believe this

@torpid root are u using q35?

[torpid root]

yes

[fiery turtle]

what if u remove it

[torpid root]

still no sci

[fiery turtle]

must be some other skill issue

[torpid root]

perchance

[fiery turtle]

if u build qemu u can try setting breakpoint on ich9_set_sci

[north holly]

Those are apic registers

[fiery turtle]

it literally says pic

[north holly]

*ioapic

Mb

The pin, then the raw value, then the decoded fields

[torpid root]

the bottom two are pic

[north holly]

I know

[torpid root]

and what do those regs mean?

[north holly]

irr is incoming irqs

isr is the irq being served

Irq base is the irq you rebased the pic to

imr is the interrupt mask register

[torpid root]

rr_sle elcr fnm

[north holly]

Idk

I know a good source tho

[fiery turtle]

it says 01 for liobilo

[north holly]

https://google.com

[north holly]

On which pic?

[fiery turtle]

0

[north holly]

That means irq pin 0 is being served

And if it isn't that means you have a bug

[torpid root]

"power down" works on linux

[north holly]

Where you forget to send an eoi

[north holly]

Well ofc it does

[torpid root]

I added noapic

[north holly]

That's because power down isn't bugged

The button

[fiery turtle]

u mean the pic driver

[fiery turtle]

u can do cat /proc/interrupts to see sci stats, maybe that will highlight something

[torpid root]

what is there to be bugged

[fiery turtle]

who knows

[torpid root]

io::out<8>(port::master_command, cmd::icw1_init | cmd::icw1_icw4);
io::out<8>(port::slave_command,  cmd::icw1_init | cmd::icw1_icw4);
io::out<8>(port::master_data, 0x20);
io::out<8>(port::slave_data,  0x28);
io::out<8>(port::master_data, 0x04);
io::out<8>(port::slave_data,  0x02);
io::out<8>(port::master_data, cmd::icw4_8086);
io::out<8>(port::slave_data,  cmd::icw4_8086);
// ...
// unmask
// vector = 0x20 + 9 = 41
auto port = port::master_data;
auto irq = vector - 0x20;
if (irq >= 8) {
    port = port::slave_data;
    irq -= 8;
}
io::out<8>(port, io::in<8>(port) & ~(1 << irq));

literally just this

[fiery turtle]

i mean

if it works for ioapic but not for pic

that can only mean one thing

[torpid root]

I don't know if it works for ioapic

on this kernel

[fiery turtle]

can you show your install irq handler? maybe we could spot something

[torpid root]

the uacpi one?

uacpi_status uacpi_kernel_install_interrupt_handler(uacpi_u32 irq, uacpi_interrupt_handler func, uacpi_handle ctx, uacpi_handle *out_irq_handle)
{
    auto vector = irq + 0x20;

    auto handler = interrupts::get(cpu::bsp_idx, vector).value();
    if (handler.get().used())
        lib::panic("Requested uACPI interrupt vector {} is already in use", vector);

    handler.get().set([](cpu::registers *, auto func, auto ctx) { func(ctx); }, func, ctx);
    interrupts::unmask(vector);

    *reinterpret_cast<std::size_t *>(out_irq_handle) = vector;
    return UACPI_STATUS_OK;
}

interrupts unmask just calls the pic unmask in this case

[fiery turtle]

hmm

[torpid root]

please tell me that fixed events need uacpi read/write pci functions implemented

[fiery turtle]

they dont

[torpid root]

sadyeehaw~1

[fiery turtle]

but i mean maybe since it aborted some _INI methods because u dont implement those some init is not complete

[torpid root]

just returning UACPI_STATUS_OK doesn't work

I might have an acute case of skill issue

[fiery turtle]

are your io read/write handlers correct?

[torpid root]

I believe they are

[fiery turtle]

double check because io is how those fixed events are configured

[torpid root]

I pushed to a new branch

https://github.com/ilobilo/ilobilix/blob/525c644e20df229139aa6141d2d8963501ff39fe/kernel/source/system/uacpi.cpp#L88-L132
https://github.com/ilobilo/ilobilix/blob/525c644e20df229139aa6141d2d8963501ff39fe/kernel/interfaces/arch/x86_64/lib/io.cppm

I don't see anything wrong

I'll go eep

good night

[fiery turtle]

looks correct at a glance

[fiery turtle]

wait

unsigned integral

how is in<8> resolved into uint8_t?

[torpid root]

https://github.com/ilobilo/ilobilix/blob/525c644e20df229139aa6141d2d8963501ff39fe/kernel/interfaces/lib/types.cppm#L8-L24

[fiery turtle]

i dont see this used there tho?

[torpid root]

https://github.com/ilobilo/ilobilix/blob/525c644e20df229139aa6141d2d8963501ff39fe/kernel/interfaces/lib/io.cppm

did I complicate it too much

[fiery turtle]

jesus

did u check that it produces the expected assembly at least?

[torpid root]

hmmmm

I'll see

[fiery turtle]

        if constexpr (std::same_as<Type, std::uint8_t>)
            asm volatile ("out %w1, %b0" :: "a"(_val), "Nd"(_port));
        else if constexpr (std::same_as<Type, std::uint16_t>)
            asm volatile ("out %w1, %w0" :: "a"(_val), "Nd"(_port));
        else if constexpr (std::same_as<Type, std::uint32_t>)
            asm volatile ("out %w1, %0" :: "a"(_val), "Nd"(_port));

is this correct?

[torpid root]

should be

[fiery turtle]

hmm

https://github.com/managarm/managarm/blob/14addb10c1950a5d93a5004aaff231aea7ee2022/kernel/thor/system/acpi/glue.cpp#L158

what if u just hardcode it to this

just for testing

[torpid root]

0000000000401130 <void tst<unsigned char>()>:
401130:       55                      push   %rbp
401131:       48 89 e5                mov    %rsp,%rbp
401134:       c6 45 ff 7b             movb   $0x7b,-0x1(%rbp)
401138:       66 c7 45 fc 7b 00       movw   $0x7b,-0x4(%rbp)
40113e:       8a 45 ff                mov    -0x1(%rbp),%al
401141:       66 8b 55 fc             mov    -0x4(%rbp),%dx
401145:       ee                      out    %al,(%dx)
401146:       5d                      pop    %rbp
401147:       c3                      ret
401148:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
40114f:       00

0000000000401150 <void tst<unsigned short>()>:
401150:       55                      push   %rbp
401151:       48 89 e5                mov    %rsp,%rbp
401154:       66 c7 45 fe 7b 00       movw   $0x7b,-0x2(%rbp)
40115a:       66 c7 45 fc 7b 00       movw   $0x7b,-0x4(%rbp)
401160:       66 8b 45 fe             mov    -0x2(%rbp),%ax
401164:       66 8b 55 fc             mov    -0x4(%rbp),%dx
401168:       66 ef                   out    %ax,(%dx)
40116a:       5d                      pop    %rbp
40116b:       c3                      ret
40116c:       0f 1f 40 00             nopl   0x0(%rax)

0000000000401170 <void tst<unsigned int>()>:
401170:       55                      push   %rbp
401171:       48 89 e5                mov    %rsp,%rbp
401174:       c7 45 fc 7b 00 00 00    movl   $0x7b,-0x4(%rbp)
40117b:       66 c7 45 fa 7b 00       movw   $0x7b,-0x6(%rbp)
401181:       8b 45 fc                mov    -0x4(%rbp),%eax
401184:       66 8b 55 fa             mov    -0x6(%rbp),%dx
401188:       ef                      out    %eax,(%dx)
401189:       5d                      pop    %rbp
40118a:       c3                      ret

al ax eax

seems correct

[fiery turtle]

hm

[torpid root]

alright

[fiery turtle]

i mean who knows

[torpid root]

hmmm how do I use att syntax when I compile with -masm=intel

something like .intel_syntax noprefix

.att_syntax prefix

[fiery turtle]

lol

[torpid root]

not an io issue

[fiery turtle]

damn

really interesting

can u make a hacky pci r/w impl?

grasping at straws here ofc

[torpid root]

death

doesn't work

I'll go actually sleep now, maybe I'll dream up a solution

[fiery turtle]

Good night

Yeah like at this point idk what it can be other than a pic bug

Or could be a mapping bug and uacpi getting an incorrect register offset

Thats easy to check by just tracing what io writes uacpi does in a working kernel and this one

The mapping function does look rather complicated, I wonder if there's a bug there

[mortal yoke]

the last one leaks the opregion in qacpi

[fiery turtle]

nice

what happens on attempt to write to that field?

[mortal yoke]

actually yeah the last write is not right either ```
qacpi_os_mmio_read1 0x50b000002880
qacpi_os_mmio_write1 0x50b000002880 = 0x1
qacpi_os_mmio_read1 0x50b000002881
qacpi_os_mmio_write1 0x50b000002881 = 0
qacpi_os_mmio_read1 0x50b000002882
qacpi_os_mmio_write1 0x50b000002882 = 0
qacpi_os_mmio_read1 0x50b000002883
qacpi_os_mmio_write1 0x50b000002883 = 0

I don't really check that the region object is an opregion, ig I could do that (or alternatively after having implemented wrapper refs for named objects the field could reference the actual underlying region object but idk if that's correct)

[fiery turtle]

my fields reference a namespace node

and on access time they try to get the opregion object

if that fails it just -EINVAL

but your approach is different iirc in that u support writes to opregions that have been deleted basically

[gentle peak]

(irr & ~imr) != 0 usually means you're forgetting to send an eoi

although considering isr is 0 you probably just have flags.if disabled

[torpid root]

could it be showing info during handling an interrupt and before eoi

[torpid root]

interrupts are enabled

[gentle peak]

sure but if your interrupt handlers are taking so much time that that's at all likely you have a bigger issue

[torpid root]

I don't think they are https://github.com/ilobilo/ilobilix/blob/rewrite/kernel/source/arch/x86_64/system/idt.cpp#L62

nothing spectacular here

[torpid root]

yeah I can't reproduce irr not being 0

[gentle peak]

maybe you got extremely lucky with timing

[torpid root]

probably

[gentle peak]

I don't think this is the issue considering isr for both pics is 0 but SCI is IRQ9 right? if so, you need to unmask IRQ2 since that's used for cascading

[torpid root]

unmasking does nothing unfortunately, but why would that matter?

[torpid root]

wait I got irq 9 after pressing the power down button

but it's not triggered

and it doesn't get higher than 1 if pressed multiple times

[rustic compass]

probably bc its not signaled eoi which is caused by not triggering your interrupt handler

[gentle peak]

the 2nd pic chip signals its interrupt status to the 1st using IRQ2, so if IRQ2 is masked you don't receive any interrupts from the 2nd chip

[torpid root]

hmm yes but i didn't know the mask affected that

[torpid root]

every irq that's triggered gets eoi ed

so it's not calling the code

[gentle peak]

if it's not triggering any of your interrupt code I'd look at the pic regs again

[torpid root]

I fixed it
I was masking everything then unmasking what I needed, including irq 2.
now I just saved the previous mask and rewrote it after initialising pic

why is that an issue, I don't know

[rustic compass]

if the second pic gets a interrupt you need to eoi to both pics

[torpid root]

I know

[rustic compass]

so your handler isnt called?

[torpid root]

It is now

[torpid root]

^

[rustic compass]

thats some weird shit the pic does

[fiery turtle]

so everything works now?

[torpid root]

yes

[fiery turtle]

nice

[torpid root]

thanks for help
I wouldn't think it was pic's fault myself

[fiery turtle]

why is what an issue specifically

did u think it worked cumulatively?

[torpid root]

so I was initialising the pic, masking every irq and then unmasking whatever I needed. it didn't work.
now I save the masks, init pic, restore masks

[fiery turtle]

that should work

which irqs does the default mask unmask?

[torpid root]

I'm not at pc but I'll check in a bit

hmm everything is masked

maybe I messed something up idk

0b11111111 0b11111111

master and slave masks

well it works fine now so idc

[fiery turtle]

lol

some larger skill issue was taking place

[torpid root]

yeah probably

[fiery turtle]

but nice that it works now

[fiery turtle]

going to merge this today

30 commits of fixes, thread safety, new features and api improvements

and also a bunch of new test cases

[fiery turtle]

#1061407633745125397 message

[hollow elm]

what kind of changes are needed in the kernel apis?

[fiery turtle]

mutex_acquire returns a status instead of bool, get_ticks gets a different name and returns actual nanoseconds and not 100ns fractions

i dont think managarm uses any other apis that i changed, namely namespace iteration stuff

also i still haven't merged it, it's all in the thread-safety branch

[north holly]

I want to see how fast obos is in ops/s

But I need to fix the god damn bug

[fiery turtle]

it doesnt even get past namespace init in obos?

[north holly]

I should at least see how fast it is on qemu

[north holly]

Maybe it does

[north holly]

It works there

[fiery turtle]

fix it 😡

well yeah at least on qemu

[north holly]

Also new kde update on my computer broke everything