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

1 messages ยท Page 13 of 1

fiery turtle
#

indeed

#

i actually found two bugs because of your blobs, and one random one by browsing code while looking for your bug

#

all fixes pushed

#

the rest were minor but still

calm latch
#

(I'm trying to target Eee PC 700 now)

#

Wonder how that thing's ACPI is

fiery turtle
#

have u tried on there?

calm latch
#

It's 32 bit only

#

So no

fiery turtle
#

that would be interesting

#

but its old so probably not that big

#

but quirky af most likely

#

so good test

#

can u get a quick dump from it?

calm latch
#

No

#

It's my friend's laptop

fiery turtle
#

unlucky

calm latch
#

Ok I can't get TSC to cooperate

#

I'm too dumb for timers

fiery turtle
#

get managarm gods or mathewnd to help u

calm latch
#

I've stolen their code

#

And it doesn't work

fiery turtle
#

steal it again until it works

calm latch
#

I have frequency in nHz

#

And period in nHz^-1 (aka ns)

#

Why multiplying tsc * period gives me garbage

hollow elm
#

nanohenry :^)

calm latch
#

Too much electronics

#

Is 32949014999 a sane frequency of TSC?

frank canopy
fiery turtle
#

nah

#

it should be like 1000000000 or something i think?

frank canopy
#

3600042kHz is my emu's tsc freq

fiery turtle
calm latch
#

Lapic is 625699999

#

According to my measurements against PIC

calm latch
#

Relatively

median crest
frank canopy
fiery turtle
calm latch
#

I can't count

fiery turtle
#

can u help pmos get a working timer mathewnd

median crest
#

I mean my timers arent that good either halfmemeright

fiery turtle
#

last time i checked astral time keeping is super accurate

calm latch
#

(I kinda don't want to deal with timers right now)

calm latch
#

So 5,644,145/9.15 = 616'846 ops/s

vast kestrel
#

what you cooking

slim panther
#

#1316457641353936956

vast kestrel
#

damn

fiery turtle
#

yeah we're thinking of a common kernel api structure

#

not sure yet how its going to look

vast kestrel
#

I mean, the uacpi kernel api is pretty good

fiery turtle
#

problem is, some drivers need more, some need less

vast kestrel
#

and it provides most things that a driver would need (ignoring actual subsystem abstractions)

fiery turtle
#

e.g. udrm will need a ton more stuff

#

phys page allocation, bar mapping, msi, cpu affinity, threads, work queues etc

vast kestrel
#

isn't work queues already abstracted?

fiery turtle
#

sorta

vast kestrel
#

you have the schedule work or something alike

fiery turtle
#

yeah

#

but i dont control when or how they're created

vast kestrel
#

bar mapping is basically the normal map function

fiery turtle
#

not for arm stuff

vast kestrel
#

true, the arm pcie controllers are garbage

fiery turtle
#

yea

vast kestrel
#

ecam was created for a freaking reason

#

but nooooo

#

you need to be special and have cfg0/cfg1 memes

#

and the weird offsets

#

thing is that defining too much and you might as well define how the kernel should behave

calm latch
fiery turtle
#

alright im on vacation so time to hardcore push uACPI release 1.0

#

first things is ironing out final thread safety stuff

#

So far fixed this one

fiery turtle
#

the unfortunate news is some problems are unsolvable without a recursive mutex

slim panther
#

ew

mortal yoke
#

can't you just internally keep the recursion count?

fiery turtle
#

because there's handler install code that needs the ns write lock, then releases it for the duration of calling a user's handler because that might also call into the interpreter, but the problem is when it does it the installation is in half-finished state

fiery turtle
#

its just unfortunate overall

#

i have all the kernel api to implement one

#

normal mutex + thread_id getter

fiery turtle
# mortal yoke can't you just internally keep the recursion count?
uacpi_status uacpi_acquire_aml_mutex(uacpi_mutex *mutex, uacpi_u16 timeout)
{
    uacpi_thread_id this_id;
    uacpi_status ret = UACPI_STATUS_OK;

    this_id = uacpi_kernel_get_thread_id();
    if (UACPI_ATOMIC_LOAD_THREAD_ID(&mutex->owner) == this_id) {
        if (uacpi_unlikely(mutex->depth == 0xFFFF)) {
            uacpi_warn(
                "failing an attempt to acquire mutex @%p, too many recursive "
                "acquires\n", mutex
            );
            return UACPI_STATUS_DENIED;
        }

        mutex->depth++;
        return ret;
    }

    uacpi_namespace_write_unlock();
    ret = uacpi_acquire_native_mutex_with_timeout(mutex->handle, timeout);
    if (ret != UACPI_STATUS_OK)
        goto out;

    if (mutex->handle == g_uacpi_rt_ctx.global_lock_mutex->handle) {
        ret = uacpi_acquire_global_lock_from_firmware();
        if (uacpi_unlikely_error(ret)) {
            uacpi_release_native_mutex(mutex->handle);
            goto out;
        }
    }

    UACPI_ATOMIC_STORE_THREAD_ID(&mutex->owner, this_id);
    mutex->depth = 1;

out:
    uacpi_namespace_write_lock();
    return ret;
}
#

this is already existing code, but looks like ill have to add similar code for native mutexes

fiery turtle
#
void u()
{
    while (1) {

        uacpi_install_address_space_handler(
            uacpi_namespace_root(), UACPI_ADDRESS_SPACE_PCC,
            handle_ec, nullptr
        );
    }
}

void uu()
{
    while (1) {

        uacpi_uninstall_address_space_handler(
            uacpi_namespace_root(), UACPI_ADDRESS_SPACE_PCC
        );
    }
}

std::thread t0(u);
std::thread t1(uu);
t0.join();
#

least insane test

#
/mnt/d/uACPI/source/io.c:231:35: runtime error: member access within null pointer of type 'struct uacpi_address_space_handler'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2566==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x564416b1ad16 bp 0x7f5918afe310 sp 0x7f5918afe1e0 T1)
==2566==The signal is caused by a READ memory access.
==2566==Hint: address points to the zero page.
    #0 0x564416b1ad16 in dispatch_field_io /mnt/d/uACPI/source/io.c:231
    #1 0x564416b1bb92 in access_field_unit /mnt/d/uACPI/source/io.c:312
    #2 0x564416b1d35b in uacpi_write_field_unit /mnt/d/uACPI/source/io.c:461
    #3 0x564416acf837 in object_assign_with_implicit_cast /mnt/d/uACPI/source/interpreter.c:978
    #4 0x564416adde91 in store_to_reference /mnt/d/uACPI/source/interpreter.c:2332
    #5 0x564416af65ee in store_to_target /mnt/d/uACPI/source/interpreter.c:4194
    #6 0x564416af6acf in handle_copy_object_or_store /mnt/d/uACPI/source/interpreter.c:4227
    #7 0x564416affa20 in exec_op /mnt/d/uACPI/source/interpreter.c:5403
    #8 0x564416b02b7d in uacpi_execute_control_method /mnt/d/uACPI/source/interpreter.c:5755
    #9 0x564416b0ffa9 in region_run_reg /mnt/d/uACPI/source/opregion.c:143
    #10 0x564416b12b51 in do_run_reg /mnt/d/uACPI/source/opregion.c:451
    #11 0x564416b0897a in uacpi_namespace_do_for_each_child /mnt/d/uACPI/source/namespace.c:876
    #12 0x564416b13249 in reg_or_unreg_all_opregions /mnt/d/uACPI/source/opregion.c:506
    #13 0x564416b13ef3 in uacpi_install_address_space_handler /mnt/d/uACPI/source/opregion.c:642
#

this is what im trying to protect against

#

this is my AML blob:

Device (X) {
    OperationRegion (Y, PCC, 0, 100)

    Device (X) { OperationRegion (Y, PCC, 0, 100)
        Device (Z) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (A) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (C) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (D) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (B) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (F) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (G) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (H) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (L) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}

    }
    Device (Z) { OperationRegion (Y, PCC, 0, 100) }
    Device (A) { OperationRegion (Y, PCC, 0, 100) }
    Device (C) { OperationRegion (Y, PCC, 0, 100) }
    Device (D) { OperationRegion (Y, PCC, 0, 100) }
    Device (B) { OperationRegion (Y, PCC, 0, 100) }
    Device (F) { OperationRegion (Y, PCC, 0, 100)
        Device (Z) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (A) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (C) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (D) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (B) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (F) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (G) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (H) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
        Device (L) { OperationRegion (Y, PCC, 0, 100) Method (_REG, 2) { Field (Y, AnyAcc, NoLock, WriteAsZeros) { Z, 1 } Z = 1 }}
    }
    Device (G) { OperationRegion (Y, PCC, 0, 100) }
    Device (H) { OperationRegion (Y, PCC, 0, 100) }
    Device (L) { OperationRegion (Y, PCC, 0, 100) }
}
#
    uacpi_namespace_write_unlock();
    ret = handler->callback(UACPI_REGION_OP_ATTACH, &attach_data);
    uacpi_namespace_write_lock();

    if (region->handler == UACPI_NULL) {
        uacpi_error("Lol handler is gone while we were attaching it\n");
    }
#

this is what im talking about

#

why i need recursive mutexes

#

[uACPI][ERROR] Lol handler is gone while we were attaching it

#

at least some mutex must be held while we're calling into a user-provided handler

#
    uacpi_object_ref(obj);
    uacpi_namespace_write_unlock();
    ret = handler->callback(UACPI_REGION_OP_ATTACH, &attach_data);
    uacpi_namespace_write_lock();

    // Handler might've disappeared while we were attaching it
    if (uacpi_unlikely(region->handler == UACPI_NULL))
        return UACPI_STATUS_NO_HANDLER;

Hmm this check technically fixes the segfault and i can cleanly abort in this case

#

i wonder if this could be the way out

rustic compass
#

you are removing the only excuse i had to procrastinate and not work on the uacpi rust bindingsnooo

fiery turtle
#

99% of the api is final btw

#

so u have no excuse meme

rustic compass
fiery turtle
#

[uACPI][TRACE] deactivated all 'PCC' opregions controlled by '\ ', 29 _REG() calls (18 errors)

#

now thats what i call a nice race condition

#

18 races out of 29 calls

#

but seems to not crash at least

#

my _REG serialization solution was bogus and causes deadlock tho so thats nice

#

whatever time to go workout and get some food

deft canopy
#

U can do it infy, i believe in u

fiery turtle
#

thanks

#

this is an unsolved problem in acpica so i get brag rights

#

if i do it that is

deft canopy
#

You've already got quite a few bragging rights over ACPICA

fiery turtle
#

lol

frank canopy
#

my imaginarium ones already have that option (though I think it's actually bugged right now lmao)

fiery turtle
frank canopy
#

if you want to do it yourself then sure lol

fiery turtle
#

i already had to implement a special-cased version for AML mutex objects so kinda

#

nice, my acpica fix for linux was added to a bunch of linux stable branches

vagrant hull
#

big W

fiery turtle
#

thanks

#

this was a type of bug that would make keyronex panic, but I guess linux had a workaround for it

#

so it never manifested itself in prod

fiery turtle
#

okay i think i got it finally

#
    std::thread t0([] {
        while (1) {
            uacpi_install_address_space_handler(
                uacpi_namespace_root(), UACPI_ADDRESS_SPACE_PCC,
                handle_ec, nullptr
            );
        }
    });
    std::thread t1([] {
        while (1) {
            uacpi_uninstall_address_space_handler(
                uacpi_namespace_root(), UACPI_ADDRESS_SPACE_PCC
            );
        }
    });
    t0.join();
#

this is now fully thread safe and serialized in uacpi

#

just so u know the amount of work this does on install:

  1. attach a new address space handler to the device object
  2. scan every opregion node under this device and attach the handler to it
  3. run _REG for every new opregion found
  4. if this opregion is accessed, dispatch to user handler first with OP_ATTACH, then with OP_READ/WRITE, both release the interpreter lock for the duration
#

and uninstall does the same, but in reverse, while also calling into the user handler with OP_DETACH

#

so its insane to serialize properly

#
static uacpi_status upgrade_to_opregion_lock(void)
{
    uacpi_status ret;

    /*
     * Drop the namespace lock, and reacquire it after the opregion lock
     * so we keep the ordering with user API.
     */
    uacpi_namespace_write_unlock();

    ret = uacpi_recursive_lock_acquire(&g_opregion_lock);
    uacpi_namespace_write_lock();
    return ret;
}

I have this atrocity where the interpreter might call into the opregion subsystem tho

#
attaching EC 17028
[uACPI][TRACE] write to [\X___.X___.Z___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17029
[uACPI][TRACE] write to [\X___.X___.A___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17030
[uACPI][TRACE] write to [\X___.X___.C___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17031
[uACPI][TRACE] write to [\X___.X___.D___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17032
[uACPI][TRACE] write to [\X___.X___.B___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17033
[uACPI][TRACE] write to [\X___.X___.F___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17034
[uACPI][TRACE] write to [\X___.X___.G___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17035
[uACPI][TRACE] write to [\X___.X___.H___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17036
[uACPI][TRACE] write to [\X___.X___.L___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17037
[uACPI][TRACE] write to [\X___.F___.Z___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17038
[uACPI][TRACE] write to [\X___.F___.A___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17039
[uACPI][TRACE] write to [\X___.F___.C___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17040
[uACPI][TRACE] write to [\X___.F___.D___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17041
[uACPI][TRACE] write to [\X___.F___.B___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17042
[uACPI][TRACE] write to [\X___.F___.F___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17043
[uACPI][TRACE] write to [\X___.F___.G___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17044
[uACPI][TRACE] write to [\X___.F___.H___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
attaching EC 17045
[uACPI][TRACE] write to [\X___.F___.L___.Y___] (1 bytes) PCC[0x0000000000000000] = 0x1
[uACPI][TRACE] activated all 'PCC' opregions controlled by '\   ', 29 _REG() calls (0 errors)
detaching EC 17046
detaching EC 17047
detaching EC 17048
detaching EC 17049
detaching EC 17050
detaching EC 17051
detaching EC 17052
detaching EC 17053
detaching EC 17054
detaching EC 17055
detaching EC 17056
detaching EC 17057
detaching EC 17058
detaching EC 17059
detaching EC 17060
detaching EC 17061
detaching EC 17062
detaching EC 17063

At least all logs are like this now, no races

flat badge
#

this looks like a weird mechanism

#

you drop the namespace_write lock, so other threads can take it now

#

but if it's fine for other threads to take it, why do you have it in the first place?

fiery turtle
#

in this case i dont do either of those, and i verify that the object that i have with namespace locked is still what i want, e.g. that it didnt get overwritten by other aml during lock upgrade

#

so basically without the ns lock held its unsafe to:

  • scan the namespace
  • access objects at permanent namespace nodes
  • access temporary namespace nodes
flat badge
#

i see

fiery turtle
# flat badge i see

the problem is there's user api to manipulate opregion handlers, and it calls into the interpreter, which may call back into opregion code, which may in turn need to run the user IO handler (for the duration of which i have to release the namespace lock so user can run aml inside handlers), during this window anyone can call uninstall_handler, which will uninstall the handler that is currently being used for AML IO

#

so there has to be some mutex ensuring serialized access to opregion handlers

#

which the ns lock is not good enough for because user handlers require releasing it

#

this is further made more difficult by the fact that a device might have any number of opregions underneath, and all must be regged and unregged in a seralized manner as well

#

idk if what im saying makes sense, its kinda hard to understand without the full context

fiery turtle
fiery turtle
#

obligatory astral test

#

while i wait for CI

#

@north holly does obos currently boot on real hw

fiery turtle
#

do u want to test new thread safety stuff meme

north holly
#

Sure

fiery turtle
#

thanks

#

git fetch && git checkout thread-safety-p2

north holly
#

Mhm

fiery turtle
#

no api changes

north holly
#

K

north holly
fiery turtle
#

nice

north holly
#

Unless

#

Why isn't it loading my com driver

#

I will debug that

fiery turtle
#

nooo my com collection

#

Anyways thanks for testing

#

All tests passed as well

#

Alright thats one huge roadblock before 1.0 solved

#

The last non-thread-safe thing in uACPI is events

#

I will fix that tomorrow

#

Only took like 6 hours today

#

Figuring out what code paths are possible

#

Im not a giant fan of the solution but i cant currently even theoretically think of a different one

frank canopy
#

nice

median crest
fiery turtle
#

Ok so

#

Event thread safety

#

I will have to change the meaning of uacpi_kernel_wait_for_work_completion

#

It will have to be also wait for in-flight ACPI irqs to finish

#

basically similar to synchronize_hardirq(); in linux

#

otherwise i cant guarantee that the interrupt handler won't touch event handlers that are being deleted

#
/*
 * Waits for two types of work to finish:
 * - All work scheduled via uacpi_kernel_schedule_work
 * - All in-flight interrupts installed via uacpi_kernel_install_interrupt_handler
 */
uacpi_status uacpi_kernel_wait_for_work_completion(void);
#

basically like this

#

so event handler deinstallation will do:

  1. mask the event in the GPE register block
  2. wait for in-flight interrupts to complete
  3. unregister the handler
  4. restore the old native handler if one existed
  5. unmask
calm latch
#

Is EC driver basically just functions to read and write to/from its registers, passed by uACPI?

calm latch
#

Can there be more than one controller??

fiery turtle
#

technically nothing prevents it

#

but almost impossible

#

managarm supports only one i think

calm latch
#

The ACPI standard supports multiple embedded controllers in a system, each with its own resources

fiery turtle
#

sure why wouldnt the standard support it

calm latch
#

I guess I'll support multiple because why not

fiery turtle
#

im not sure linux supports multiple tbh

#

no it does

calm latch
#

It doesn't look difficult to do

calm latch
#

Does it not pass ECDT?

fiery turtle
#

your laptop doesnt have ECDT

calm latch
fiery turtle
#

global ACPI firmware lock

calm latch
#

What do I need it for?

#

(where am I supposed to acquire it)

#

Did anyone notice that managram doesn't initialize gpeNode?

#

Is that intended?

fiery turtle
#

The firmware might ask you to lock it

#

When u access EC

fiery turtle
#

Its resolved into _GPE automatically

calm latch
#

I've already looked at it

#

I guess they have clearing allocator

#

Can EC be in memory? Thonk

fiery turtle
fiery turtle
calm latch
#

Since managram only takes UACPI_RESOURCE_TYPE_IO and UACPI_RESOURCE_TYPE_FIXED_IO

fiery turtle
#

Yeah I doubt other exist but u can take a look at which ones Linux expects

vast kestrel
#

Btw why doesn't the aml just implement the EC driver? Is there an actual reason or just yet another acpi weirdness?

fiery turtle
vast kestrel
#

But acpi has everything it needs to handle async code

#

It has the event mechanism and the gpe mechanism

fiery turtle
#

yeah

#

it would require non-trivial aml with events and stuff, I guess firmware devs are not at that level yet

vast kestrel
#

The only actual reason I can think of is if maybe the OEM wants its own driver to do some EC stuff, but they could have just used the aml driver for both

fiery turtle
#

one other reason i can think of is EC is used directly by the host to request hw specific information about thermals and firmware settings etc

#

maybe they did it to avoid races with host

loud ice
#

i think the real reason is because aml is a shitty programming language

vast kestrel
#

Is there a reason uacpi doesn't provide it's own EC driver?

loud ice
#

and vendors dont want to write even more aml

fiery turtle
#

already answered before

vast kestrel
#

Lemme search then

fiery turtle
#

#1217009725711847465 message

vast kestrel
#

How the fuck do you search discord on mobile

#

Bruh I asked that

fiery turtle
#

lmao

north holly
loud ice
#

like in general

vast kestrel
#

Tbh I can't really agree with the quirk thing because if you won't handle it no one would, but the coupling with the kernel I can understand

fiery turtle
#

handling it requires uacpi to have SMBIOS hooks in kernel api

#

so basically just too many extra kernel api functions needed for that

vast kestrel
#

Yeah that sucks

#

Could be a nice uDriver maybe :^)

fiery turtle
#

yeah definitely

#

cool idea

vast kestrel
#

Given for that you will def need smbios hooks

#

Like uapi

fiery turtle
#

uapi will definitely need platform info yeah

vast kestrel
#

Its funny because I am not sure if I will even use any of these stuff in my C# kernel giving the whole goal is to have managed drivers 3sGudaEhehe

fiery turtle
#

C# bindings for uAPI meme

vast kestrel
#

I am actually kinda waiting to see the API to see if I can take inspiration from it lol

fiery turtle
#

lol

#

nice

vast kestrel
#

Like I need "safe" abstractions over interrupts and hardware resources

#

And I wasn't that impressed with the rust Linux bindings for inspiration

fiery turtle
#

lol

#

i can imagine that

vast kestrel
#

The closest to a nice api inspiration is WDK from all things

fiery turtle
#

yup

#

storport meme

vast kestrel
#

Ah yes I too like a switch case over every kernel function because ?????

fiery turtle
#

ikr

#

not a fan of that giant switch

calm latch
fiery turtle
#

_GLK evaluating to 1

calm latch
#

Oh so basically when doing reads and writes?

fiery turtle
#

ye

calm latch
#

But not in GPE handler

fiery turtle
#

uACPI will be fully thread safe after I merge this PR!

#

it's basically done, just need to test it now

#

to test this properly ill need managarm because no one else uses events properly

calm latch
#

Are they difficult to implement?

fiery turtle
#

well the managarms ec driver

#

did u implement one?

calm latch
#

No

#

I'll finish it today

north holly
#

I should implement ec driver

calm latch
#

I've started writing it

fiery turtle
#

ok nice

fiery turtle
calm latch
north holly
#

Like maybe before adding the new syscalls

fiery turtle
#

i can test obos on like 5 laptops if u do it

#

ill have to pull them out and find chargers tho

calm latch
#

I have a bunch of PCs

#

8

fiery turtle
#

damn

calm latch
#

I think

fiery turtle
#

does your os boot on all?

calm latch
#

Yes

fiery turtle
#

damn

#

i guess that includes uacpi?

north holly
#

Will be doing that soon

calm latch
#

Yes

#

Although I haven't tested it for a long time

fiery turtle
#

nice, if u add an ec driver that should be a very large coverage

#

if u do fn+various keys it should spam EC events

calm latch
#

How would I see them?

fiery turtle
#

same for AC charger/lid and stuff like that if u have laptops

calm latch
fiery turtle
#

the EC makes u run AML

#

that it wants

calm latch
#

Yeah my code is very similar (copy-pasted)

#

Except in C

calm latch
#

And potentially not all of them are working

#

Like my old laptop died a month ago sadmeme

#

But it's a battery problem so I can disassemble it and disconnect it I'd suppose

#

And it's a weird HP 2 in 1, which struggles with sound in Linux

#

Anyway, I think I'll try to finish it today's evening, and at least try it on my Lenovo laptop

fiery turtle
#

okay astral revealed a slight skill issue but seems to be fixed now

#

seems to work

fiery turtle
#

Event stuff was much easier to make thread safe and ended up cleaner and safer than ACPICA

#

ACPICA has a complex mutex + spinlock design

#

And still subject to race windows

#

Whereas i just use a mutex for public API + mask the corresponding event when modifying its handlers so it can't even occur and thus race against handler modification

fiery turtle
# median crest What was it

I moved some logic into a separate helper and it was page faulting

static uacpi_status for_all_gpes_locked(struct do_for_all_gpes_ctx *ctx)
{
    uacpi_status ret;

    UACPI_ENSURE_INIT_LEVEL_AT_LEAST(UACPI_INIT_LEVEL_SUBSYSTEM_INITIALIZED);

    ret = uacpi_recursive_lock_acquire(&g_event_lock);
    if (uacpi_unlikely_error(ret))
        return ret;

    for_each_gpe_block(do_for_all_gpes, &ctx);

    uacpi_recursive_lock_release(&g_event_lock);
    return ctx->ret;
}
#

can u spot the bug?

calm latch
#

ctx?

median crest
#

&ctx

fiery turtle
#

yup

#

also I noticed astral doesnt even initialize events lol

#

i forgor to add it ๐Ÿ’€

#
--- a/kernel-src/io/acpi/acpi.c
+++ b/kernel-src/io/acpi/acpi.c
@@ -35,6 +35,8 @@ void acpi_init(void) {
        __assert(ret == UACPI_STATUS_OK);

        uacpi_install_fixed_event_handler(UACPI_FIXED_EVENT_POWER_BUTTON, handle_pwrbtn, UACPI_NULL);
+
+       uacpi_finalize_gpe_initialization();
 }
#

I decided to use recursive locks but it's mostly to prevent the user from deadlocking themselves if they want to do something about the event from an event handler

#

which technically u shouldn't be doing but whatever

calm latch
#

Does it use recursive mutex?

#

From kernel api

fiery turtle
#

no such kernel api

calm latch
#

So it's spinlocks

fiery turtle
#

its normal mutexes

#

just with depth count

calm latch
fiery turtle
#
uacpi_status uacpi_recursive_lock_acquire(struct uacpi_recursive_lock *lock)
{
    uacpi_thread_id this_id;
    uacpi_status ret = UACPI_STATUS_OK;

    this_id = uacpi_kernel_get_thread_id();
    if (UACPI_ATOMIC_LOAD_THREAD_ID(&lock->owner) == this_id) {
        lock->depth++;
        return ret;
    }

    ret = uacpi_acquire_native_mutex(lock->mutex);
    if (uacpi_unlikely_error(ret))
        return ret;

    UACPI_ATOMIC_STORE_THREAD_ID(&lock->owner, this_id);
    lock->depth = 1;
    return ret;
}
calm latch
#

Cool

#

My mutex implements recursive locks, but I don't know if it can be trusted...

fiery turtle
#

lol

#

yeah less work for kernel api is better

#

less space for user bugs

north holly
#

Does recursive lock include recursive unlock?

fiery turtle
#

yes

north holly
#

Like if I lock twice, the first time I unlock doesn't release it, but the 2nd time it does

fiery turtle
hollow elm
fiery turtle
#

i could add that to just log BUG: ...

hollow elm
#

i was thinking just assert that thats the case

north holly
fiery turtle
#

^

#

uACPI's ideology is that it has no right to decide what is worthy of panic

#

so all errros are propagated back to the host

#

it does reset its own state if some critical init fails tho

median crest
#

uAssert when

calm latch
#

uKernel

rustic compass
#

wouldnt it be better if all manageable error are handled and the rest is an Abort?

fiery turtle
#

whats an example of an unmanagable error?

fiery turtle
#

thats just an internal error IMO

#

like it could signify a memory corruption for example ofc

#

but idk if its worth to abort just because it might be one

loud ice
#

debug assertions are good

#

add them

dusky glade
#

guys just do it like managarm

loud ice
#

lol

dusky glade
#

add asserts everywhere

fiery turtle
#

yeah as an optional "fortified" uacpi build i could definitely add that tbh

loud ice
#

DEBUG build lol

dusky glade
#

assert(if cpu exists)

fiery turtle
#

for debugging shitty kernel api

loud ice
#

yeah

dusky glade
#

have u asserted if the cpu actually exists

loud ice
#

and possibly internal errors

fiery turtle
#
#ifdef UACPI_MAYBE_BROKEN_KERNEL_API
void uacpi_kernel_abort(const uacpi_char *why);
#endif
calm latch
#

(100% of operating systems that use uACPI)

loud ice
fiery turtle
#

I was memeing but yeah

#

thats what I would do

dusky glade
loud ice
fiery turtle
#

but i would still add a kernel api hook

#

just hanging is not that great

loud ice
#

true

#

but if internal consistency checks are failing, the kernel hooks are more than a bit suspect

calm latch
#

Have you considered adding heap to uACPI?

gentle peak
fiery turtle
dusky glade
calm latch
loud ice
#

else just hang

fiery turtle
#

msvc also has this

#

i think

dusky glade
#

who compiles a kernel with msvc

fiery turtle
#

__debugbreak or something

calm latch
fiery turtle
rustic compass
#

nullptr and its value is an index into a error table

dusky glade
loud ice
fiery turtle
calm latch
#

Does msvc output to elf?

loud ice
#

no

loud ice
fiery turtle
#

lol

calm latch
fiery turtle
#

I already had to sacrafice a lot of make uacpi compilable under msvc so at this point its sunk cost fallacy

loud ice
#

what about uACPITableBuilder

fiery turtle
#

like an asl compiler?

dusky glade
#

why support a compiler

#

no one is gonna use

fiery turtle
#

i work on windows

dusky glade
#

i havent seen one osdev compile their kernel with msvc

fiery turtle
#

plus its an extra platform for testing

#

plus kernels that go for nt compat

#

since uacpi is nt compatible

loud ice
#

uacpi.sys when

dusky glade
#

^

fiery turtle
#

yeah still tho

fiery turtle
loud ice
#

oh

fiery turtle
#

wip in reactos

loud ice
#

damn

#

what about uacpi on NT?

calm latch
fiery turtle
#

this

dusky glade
#

good question

fiery turtle
dusky glade
#

insane

loud ice
fiery turtle
#

apparently uacpi fixed touchscreen detection in reactos on that tablet

#

idk how exactly but thats cool

#

they were previously using acpica

calm latch
#

Did reactos switch to uacpi?

fiery turtle
#

darkfire is working hard on it but not yet

#

a lot of tech debt to solve before that

calm latch
#

That's cool

fiery turtle
#

yeah that would be a huge milestone for uacpi as well

calm latch
#

Imagine Linux switching one day

fiery turtle
#

yeah its doable, just a lot of files to go 1 by 1

#

but uacpi is very close to feature parity with acpica

#

there's like a few thousand acpica api calls

#

each one has to be carefully changed

#

although a lot of them are almost identical

#

also uACPI's repo is a bit over 2 years old now

#

which is crazy

#

i finished the interpreter last december

#

and its been all the rest of the features since then

#

and fixes etc

north holly
#

First uacpi port in Feburary

#

I think

fiery turtle
#

yeah it couldnt do shit back then

north holly
#

Or earlier

#

Made by some guy named oberrow

#

On the cherno server

fiery turtle
#

yeah lol

north holly
#

I can link his kernel wait

#

Daily obos shilling complete

fiery turtle
#

never seen it before

north holly
#

Yeah it is a pretty cool kernel

#

Although since it first ported uacpi, it has had some rewrites

fiery turtle
#

lol

dusky glade
#

i think we can talk about the second kernel that ported uacpi

#

its pretty cool

#

it was made by a guy i can link his kernel wait

#

its had some rewrites tho

#

idk

#

Daily nyaux shilling complete

torpid root
#

guys what about kernel rewrite by some guy named ilobilo
I hear it throws a coprocessor segment overrun exception if you press a key in vmware

#

that dumass probably messed up the pic again

fiery turtle
#

Actually I dont know which kernel was second

#

I wanna say managarm

torpid root
#

I guess I should only enable interrupts when the pic is remapped lol

torpid root
north holly
#

Managarm was 2nd

#

I believe

dusky glade
#

damn

calm latch
#

Was I third?

north holly
#

On the 28th of January 2024, I ported uacpi to obos

#

#560042023638269955 message

fiery turtle
median crest
#

Astral was first because all others arent real operating systems

#

Astral <------- real operating system
Linux windows etc etc <------- delusional cosplayers

calm latch
#

Although I did that on May 13

#

It's kinda late

#

Maybe not

north holly
#

I am also the first one using uacpi to implement suspend functionality

#

And the first one to implement device detection via uacpi (sometime in February)

calm latch
#

I'm racing you to be the second OS to have EC

north holly
#

Well I can't work on obos for another couple hours

calm latch
#

I can't either

loud ice
north holly
#

Time to copy managarm code

#

I meant read the spec

fiery turtle
calm latch
#

ctrl+c ctrl+v speed contest

north holly
#

found ec spec

loud ice
#

what kind of stuff does an EC do anyway?

north holly
#

magical stuff

fiery turtle
calm latch
#

Was I the second to do PCI interrupts routing with uACPI?

loud ice
#

oh lol

#

what does it do tho

fiery turtle
#

Abstraction over proprietary firmware state basically

north holly
loud ice
#

ah so nothing useful

#

got it

north holly
#

well no, you need it on modern devices

#

for power button

#

n'shit

loud ice
#

"need"

fiery turtle
#

It can toggle fans, features, thermals, runtime options etc

#

Read temperatures

loud ice
calm latch
fiery turtle
#

Basically all firmware stuff

loud ice
#

and then i get the power button from something else

north holly
calm latch
#

No

#

MacBooks

#

And my 2023 lenovo laptop for no reason

north holly
#

$120 school laptops

#

or sorry

#

$60

#

/j

loud ice
#

i think chromebooks have their own linux driver

fiery turtle
#

Basically all x86 hw after circa 2010 has one

fiery turtle
#

So they get a special driver or quirk

loud ice
#

they have their own entire driver lol

#

called cros_ec

#

its also in frameworks btw

fiery turtle
#

The thing is ec is abstract away it shouldn't need special drivers lol

calm latch
#

But how does Windows deal with it

loud ice
#

it would imply writing aml

#

and they are vendoring their own kernels anyway so might as well

fiery turtle
#

Dont they expose it via aml as well

#

Chromebooks have acpi

loud ice
#

no fucking idea

#

also its open source so you'll see it more and more i guess

fiery turtle
loud ice
#

frameworks also have a cros_ec

#

so

fiery turtle
#

I've had someone boot uacpi on a Chromebook so yeah

loud ice
#

oh cool

fiery turtle
#

It does have aml albeit tiny

loud ice
#

i think i sent you my aml dump

fiery turtle
#

Compared to other hw

loud ice
#

from my chromebook?

fiery turtle
#

Think so yeah

#

A while ago

loud ice
#

which is dead now, rip charging controller

fiery turtle
#

Oof

torpid root
#

my uacpi commit was on June 1

#

I'll take the fourth place

loud ice
#

maybe i should add uacpi support to my bootloader/firmware thing

calm latch
#

you def need userspace /s

loud ice
#

userspace?

calm latch
#

to run stuff in it

#

in bootloader

#

(unrelated to uACPI)

loud ice
#

why would i do userspace

#

much better to write my own scripting lang

calm latch
#

because it's cursed

loud ice
#

an AOT bytecoded one so i dont ship the compiler

#

my binaries are already way too big

fiery turtle
loud ice
#

so idk maybe not

fiery turtle
#

Aml ones u just propagate as is, the rest is just hardcoded struct + data so

loud ice
#

i need to build them dynamically

#

thats like the point

fiery turtle
#

I thought u dropped that idea

#

But yeah if thats your only goal for acpi then yes, unless u want to use aml to discover available non pci devices in the bootloader directly

loud ice
#

its on the list of things i may want to do at some point

fiery turtle
#

That would be a truly unique thing

loud ice
#

yes but it would involve dealing with aml shit

#

id probably have to write an aml compiler

fiery turtle
#

I would just use a DSL like qemu

#

Aml is very good for that

loud ice
fiery turtle
#

I can show u an example of how qemu does it if u want

fiery turtle
fiery turtle
#

example for a TPM device

loud ice
#

ah

fiery turtle
#

ifctx = aml_if(aml_lgreater_equal(op, aml_int(0x100)));

loud ice
#

ugly

fiery turtle
#

literally trivial

#

no compiler needed

loud ice
#

id much rather make a good compiler

#

or a good dsl at lesat

fiery turtle
#

you would produce ascii text then compile it?

loud ice
#

actually ig i could abuse rust

loud ice
fiery turtle
#

rust macros could be abused to make a very powerful dsl here

loud ice
#

true

dusky glade
#

@fiery turtle this u?

fiery turtle
#

Wut

dusky glade
#

on the irc channel

fiery turtle
#

Never used irc before

dusky glade
#

told them that now

#

cant believe im using irc in 2024

#

smh

fiery turtle
#

Is it active?

dusky glade
#

yea

fiery turtle
dusky glade
#

they are weird

#

but its an active irc channel so

#

๐Ÿคทโ€โ™‚๏ธ

fiery turtle
#

Didnt understand any of that but w/e

dusky glade
#

wwe?

#

john cena? did u say john cina infy

deft canopy
calm latch
#

Ok, I'm back

#

Time to finish EC

winter orbit
#

Thatโ€™s the goal

winter orbit
#

Im not sure if Infy wants a vs solution sent back into a PR or something that remains to be figured out

calm latch
#

Btw, what should interrupt handlers return on failure?

winter orbit
#

But uACPI will be able to be plugged into vista from reactos

dusky glade
#

wwe

#

real

#

infy is john cena

#

real

north holly
#

I'm still at school

fiery turtle
calm latch
north holly
#

It's 2 pm

calm latch
#

I confused you and linuxmaster2.0

fiery turtle
north holly
#

I only have a small base for an EC driver

#

Basically nothing

#

I could ssh into my 0x

#

Pc

#

From school

calm latch
north holly
#

If only I had that port forwarded

loud ice
north holly
#

Wait

#

I will compile a cross compiler

#

For x86 64 elf

#

Then compile obos with it

#

Termux can't run static executables, unfortunately

#

So that won't work

calm latch
#

I'm eating, so you have time bruh

calm latch
#

Do I have to use burst?

#

Managram does it, but since I'm running in userspace, I'm afraid this stuff could be preempted

#

(though I have priorities in scheduler, I don't want to use that)

winter orbit
calm latch
#

And it would disengage

north holly
#

Infy don't answer his questions

#

Until I get back home

calm latch
#

Does QEMU support EC?

#

I'm gonna try it on my laptop...

#

Looks like QEMU doesn't have it..?

#

@fiery turtle it's failing what am I doing wrong

#

But I did get an even pressing f keys...

fiery turtle
calm latch
#

omega bruh

fiery turtle
calm latch
#

Idk it doesn't boot

fiery turtle
#

Hard power off

calm latch
#

Ok it booted

fiery turtle
#

Least broken ec driver

calm latch
#

But it booted to Windows, turned off and then I had this

fiery turtle
calm latch
#

I'm gonna push my code to gitlab

fiery turtle
#

Basically you should early reg for your laptop

#

This error doesnt happen on Linux right? Idk what logic it uses to decide if you should or not

calm latch
#

Idk

#

I think it's secure boot

#

Which I have to turn on because of bitlocker

fiery turtle
#

Your laptop is strange in that it doesnt give an ECDT but expects _REG to be called before _STA

#

I have a laptop which wants the opposite

calm latch
#

What am I supposed to do?

#

Managram broken?

calm latch
#

Which part of spec should I look at?

fiery turtle
#

Look at how Linux decides when to install the handler I guess, but for your hw the managarm logic is wrong

fiery turtle
calm latch
#

I find linux source to be intimidating

fiery turtle
#

BSDs

#

I can take a look later

#

Btw try to boot live Linux on it

calm latch
#
#ifdef CONFIG_ACPI_EC
    /*
     * ACPI 2.0 requires the EC driver to be loaded and work before
     * the EC device is found in the namespace (i.e. before acpi_initialize_objects()
     * is called).
     *
     * This is accomplished by looking for the ECDT table, and getting 
     * the EC parameters out of that.
     */
    status = acpi_ec_ecdt_probe();
    /* Ignore result. Not having an ECDT is not fatal. */
#endif
```?
#

What's the website with linux source

#

drivers/acpi/bus.c:689

fiery turtle
#

Bootlin

calm latch
#
ret = acpi_ec_get_real_ecdt();
/* Try to make a fake ECDT */
if (ret && acpi_fake_ecdt_enabled) {
  ret = acpi_ec_fake_ecdt();
}
```![KEKW](https://cdn.discordapp.com/emojis/913708372329644042.webp?size=128 "KEKW")
fiery turtle
#

Lol

#

What decides if there should be a fake ECDT

calm latch
#

I'm gonna try Linux

fiery turtle
#

Yeah try it

calm latch
#

I think it's a kernel option

#

But I would imagine someone using Linux on it

#

It's 1 year old laptop

fiery turtle
#

Yeah

calm latch
#

So it must work.......

#

Ok, it's 5 minutes to try

fiery turtle
#

Yeah try and we'll try to decide from there

#

Its not a critical error or anything but still

calm latch
#

What fedora ships ppc?

#

Bruh and it's 2 gb ISO

#

I'm gonna download ubuntu as well...

calm latch
#

But power button didn't work

fiery turtle
#

Dont see u running the query

calm latch
#

Which query

fiery turtle
#

... In response to the event

#

_QXX

calm latch
#

Maybe it locked up

#

I need more printfs

fiery turtle
#

Yup

calm latch
#

I was kinda hoping it would work first try

fiery turtle
#

I had to debug hangs as well, but it was a skill issue

#

When making the managarm ec driver

calm latch
calm latch
#

I've basically copied managram and so it should be firing uacpi_kernel_schedule_work, which should be printing stuff without taking locks

#

Maybe I do have a deadlock in kernel after all..

fiery turtle
#

See your aml _Q01

calm latch
#

I'm feeling dumb

#

There's nowhere to lock up between 2 printfs

#

Ok, something fishy is going on

#

(maybe I do need kernel panic to framebuffer after all)

slim panther
#

serial meme

calm latch
#

No that's the only output I have from kernel

#

The issue is that I only have it in VMs and on couple of my PCs

#

And not on laptops

#

So sometimes I don't know if the kernel has panicked

#

Ok anyways I've been looking at the wrong part of code again galaxybrain

#

Somehow the kernel never crashes

frank canopy
#

dang updating to the new recursive-locks version broke my kernel

calm latch
#

Btw can EC be tested in VMs?

north holly
#

I still have time to make a more stable ec driver than you

calm latch
#

EC on PCI??

#

I'm trying Linux

torpid root
calm latch
#

Phoenix bios?????

#

I thought they were out of business

#

What is [ 1.057783] Unstable clock detected, switching default tracing clock to "global"?

#

So TSC is broken on this laptop?

#

Lol

#

And it's using PIT for calibration

#

What snd_hda_intel 0000:c3:00.1: enabling device (0000 -> 0002)

#

This is AMD only laptop

#

Will uhda work on it?thinkong

#
[   12.512529] snd_hda_intel 0000:c3:00.1: enabling device (0000 -> 0002)
[   12.512944] snd_hda_intel 0000:c3:00.1: Handle vga_switcheroo audio client
[   12.513058] snd_hda_intel 0000:c3:00.6: enabling device (0000 -> 0002)
[   12.531287] amd_atl: AMD Address Translation Library initialized
[   12.531624] intel_rapl_common: Found RAPL domain package
[   12.531627] intel_rapl_common: Found RAPL domain core
[   12.532028] snd_hda_intel 0000:c3:00.1: bound 0000:c3:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
[   12.534327] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:08.1/0000:c3:00.1/sound/card0/input16
[   12.534388] input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:08.1/0000:c3:00.1/sound/card0/input17
[   12.534454] input: HD-Audio Generic HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:08.1/0000:c3:00.1/sound/card0/input18
fiery turtle
fiery turtle
frank canopy
#

oh thats why the new recursive mutex thing broke my kernel, my get thread id crashes before my processor-local control blocks get initialized which i dont do until after i init uacpi so i can have the MADT

#

does early table access use mutexes?

#

(by crashes i mean that before processor-local control blocks are initialized the gs-base is 0 and so the gs-relative pointer page faults accessing virt address 0 when i try to check the current thread id)

fiery turtle
#

or actually no it doesnt use any

#

it doesnt use heap whatsoever

frank canopy
#

cool, then i can use early table access to ensure i dont need thread ids until after i get processor local stuff figured out

fiery turtle
#

yeah definitely

#

early table access uses logging and map/unmap

frank canopy
#

will need to figure out memory management for the early table access buffer (which i assume can be freed after the normal initialize) but ill need memory management anyway by that point for the map/unmap so thats fine

fiery turtle
#

yeah

#

linux just puts it in an __init section

#

which is automatically freed after init

frank canopy
#

ill have full kernel-mode alloc ready to use well before that point most likely anyway

fiery turtle
#

ah ok then u can just kmalloc(4096)

#

then free after uacpi_initialize

#

there are kernel initialization hooks u may reuse for this

frank canopy
#

also a question for those who know windows synchronization stuff, is the uacpi_kernel_xxx_event stuff expected to be closer to a KSEMAPHORE or to a SynchronizationEvent?

#

cool

calm latch
mortal yoke
fiery turtle
calm latch
#

I think Linux has gotten the same frequency

mortal yoke
# mortal yoke only one way to find out :p

I should make a test image but I still haven't figured out the issue with astral and on my own kernel switching the output would be painful because the xhci is broken (though ig I could add a kernel param but that's not ideal)

hollow elm
calm latch
#

I think I have the latest bios though

calm latch
mortal yoke
#

shouldn't be that hard

calm latch
#

But I want shell first...

#

And for that I need AHCI

#

And for that I need working set

north holly
#

@fiery turtle does ec init have to happen before namespace load or init?

fiery turtle
#

it cant happen before load

#

either before init or after

#

depending on something

#

idk what specifically

north holly
#

does the spec know?

fiery turtle
#

no

#

only linux knows

#

managarm does if ECDT exists then after load, otherwise after init

torpid root
#

linux knows all

median crest
#

who is this linux person

slim panther
#

linux torvald

calm latch
#

Wait can I unconditionally call it after init?

fiery turtle
#

that will break some init code like your battery

calm latch
#

Like I'm iterating through it, where in it does it request early init?

torpid root
north holly
#

where is linux' ec driver

#

found it

calm latch
#

Ok I'm having a skill issue with my pthreads

#

I think I've found it ๐Ÿ‘

north holly
calm latch
#

(for some reason, pinning threads to other CPUs seems to be broken...)

#

Wait, no

#

Do GPE handlers want CPU 0?

#

bootstrap CPU that is

north holly
#

I believe so

#

what linux does:

  • before namespace load, it probes the ecdt table, if it exists
  • if that exists, all is fine
  • otherwise, sometime after namespace init, it probes the acpi namespace for an EC
calm latch
north holly
#

well does linux work?

calm latch
#

It looks like it

north holly
#

linux init sequence there

north holly
#

or dmesh

#

*dmesg

#

to make sure nothing errored out

calm latch
fiery turtle
#

it installs it to root if there's an ECDT

calm latch
#

ACPI BIOS Error (bug): Failure creating named object [\_SB.MHSP], AE_ALREADY_EXISTS (20240322/dswload2-326)

fiery turtle
#

yeah this one uacpi produces as well

#

its unrelated

calm latch
#

What is this ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored?

fiery turtle
#

also unrelated

#

long story

#

just to make sure, there's definitely no ECDT right?

calm latch
#

Could I need to be calling initialization code before finalize_gpe_initialization?

fiery turtle
#

nah thats unrelated

#

_REG happens when installing the handler

calm latch
fiery turtle
#

so u should be installing it earlier

#

can u paste the full dmesg

calm latch
#

If I'm not missing anything

fiery turtle
calm latch
#

Cool

#

I though everyone was using AMI

#

Anyway

fiery turtle
#
[    0.249958] ACPI: EC: EC started
[    0.249959] ACPI: EC: interrupt blocked
[    0.587395] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.587399] ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC used to handle transactions
calm latch
#

DSDT EC?

fiery turtle
#

this call here

fiery turtle
#

so yeah in your case linux also calls _STA and _INI before

#

but i guess maybe they initialize locals to 0 by default and no Uninitialized

#

anyway that shouldnt matter for now

#

its not that big of an issue

calm latch
#

But my power button doesn't work

#

(and my threads are broken)

fiery turtle
#

thats your driver's skill issue

calm latch
#

(maybe that is the reason)

fiery turtle
#

its unrelated to this

calm latch
#

That's my kernel's skill issue because why doesn't it work

fiery turtle
#

could try managarm to see if its a uacpi bug

#

but do u even run the query?

calm latch
#

I run uacpi_kernel_schedule_work

#

And it creates a thread, which pins itself to bootstrap CPU

#

And after that syscall, it disappears

#

Looking at printfs

fiery turtle
#
Method (_Q32, 0, NotSerialized)  // _Qxx: EC Query, xx=0x00-0xFF
{
    P80H = 0x32
    Notify (PWRB, 0x80) // Status Change
}
calm latch
#

Or the kernel hangs

fiery turtle
#

this is the event u should be getting

#

0x32

#

so your reading of 0x01 is bogus also

calm latch
#

From EC?

fiery turtle
#

yes

calm latch
#

Bruh

#

Anyway

#

I'll fix bogus reading

#

I need to know what's going on with that thread

#

Maybe the kernel is panicking

fiery turtle
#

yeah

#

Hmm maybe uacpi should also zero-initialize locals, i'll see what NT does

calm latch
#

How do you know what it does?

calm latch
#

Or I could test it in VM

#

Anyway, I think this is irrelevant to uACPI

fiery turtle
calm latch
#

(I urgently need a keyboard driver)

fiery turtle
torpid root
#

infy I have a request to make

#

โœจ uacpi benchmark leaderboard โœจ

fiery turtle
#

lmao

#

true true

#

ill maybe add that to the README

calm latch
#

lol

fiery turtle
#

Please give me your submissions so I can record them, like project link: x ops/s

north holly
#

_GPE can resolve to a package

#

but you only evaluate it as an integer

#

or they do

#

idk who wrote that driver

fiery turtle
#

can it?

mortal yoke
north holly
north holly
calm latch
fiery turtle
#

they dont exist and arent supported

north holly
#

wtf

#

acpi spec stoobid

fiery turtle
#

ye

north holly
#

my ec driver is nearly complete

#

I just need

#

to implement initializing it from the acpi namespace

#

my pc does indeed have an ec

#

wut

#

why is there no _GPE

fiery turtle
#

might be there just added later

#

with Scope and stuff

north holly
#

only two mentions of _GPE in the entire dsdt

#

so I doubt it

#

both of which in the namespace root

#

first is a Scope(_GPE) in the root

#

and the 2nd is Scope(\_GPE)

#

or smth

#

the other way around

fiery turtle
#

do u have any _QXX methods?

north holly
#

nope

fiery turtle
#

yeah your ec just doesnt have events

#

it doesnt have to

north holly
#

so what's really the point of it now then?

fiery turtle
#

AML can still access it

#

it stores firmware state

north holly
#

guess so

#

I wonder what would happen if I wrote random shit to it

#

what could possibly go wrong

torpid root
fiery turtle
north holly
#

wtf

#

there is no _CRS

#

in the ec device

#

guess it just doesn't exist

fiery turtle
#

yeah just a stub ig

calm latch
#

My scheduler has a giant skill issue

#

Wtf

pine leaf
#

man now I'm half tempted to revive techflash-os just so that I can compete on the leaderboard meme

fiery turtle
calm latch
north holly
#

nope

calm latch
#

And it had a huge bug all along

#

And I was wondering why threads were disappearing