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

1 messages · Page 67 of 1

crude summit
#

you could probably lift that file verbatim into your code and just implement the serial writer functions, it uses a preallocated memory region

#

otherwise calling an allocator during profiling would be death

fiery ice
#

i send it via serial after i finish rn

#

how do i make a flamegraph from your output btw

crude summit
#

and lots more

crude summit
#

this is a big wheel i didnt want to reinvent

fiery ice
#

i tought you had a script

crude summit
#

yeah, an open source program

#

the serial port output just redirects to a file called callgrind.out and that can parse it

#

back later, work time

frank canopy
#

actually started thinking about this too when I saw the mention of rapid free and allocation of small things

#

esp because zig has a lockless thread safe arena in the std

#

(thread safe as long as it's backing is anyway)

loud ice
#

i mean you could also try allocating less trl

crude summit
#

allocate one huge arena and divvy it out

loud ice
#

dont

crude summit
#

I mean I give uacpi it's own standalone buddy arena anyway

loud ice
#

big allocations are harder to cover

crude summit
#

I think I give it 4mb

#

it doesn't use anywhere near that

loud ice
#

imo you can get more from a better interpreter and better allocator usage than you can from a better allocator

flat badge
#

optimizing acpi interpreters for speed is useless

#

it's better to optimize for stability

#

that is, less code that can break and simpler code

loud ice
#

and the warmup path is even more useless

crude summit
#

I don't really care how long it takes so long as it's not noticeable

loud ice
#

its already not

crude summit
#

in the grand scheme of things uacpi startup is a fraction of a hundredth of a percent of startup time (and startup time is already under 2s and dominated by a pci scan)

jaunty fox
#

great news for uacpi and for its users

fiery ice
#

@crude summit how do i see the graph?

#

oh found it

crude summit
fiery ice
#

lol

crude summit
#

seeing proper profile data for my os was a huge eye opener, I increased my performance 10x

fiery ice
#

i'll re-enable the log instrument

crude summit
#

8% of your time spent logging

fiery ice
#

nah, that's just flanterm

crude summit
#

yes .flanterm from your log function

fiery ice
#

nope

#

part of it

hallow marten
#

You should try sampling rather than instrumenting

fiery ice
#

wdym sampling?

crude summit
#

you sure?

hallow marten
crude summit
hallow marten
#

yes but instrumenting is slow

crude summit
#

and?

hallow marten
#

Doesn't necessarily represent real runtime

crude summit
#

if he's using my code it's not that slow

hallow marten
#

I'd say it's best to mix both

crude summit
#

everything is equally slower

#

so the percentages are correct

#

all the profiler hooks are O(1) or close to

hallow marten
crude summit
#

you could mix both just don't profile your sampler

hallow marten
#

Yeah or like do a sampled run and an instrumented run

fiery ice
#

seems like it didn't finish writing yet

#

here is the full one

frank canopy
#

thats a lot of putchar

fiery ice
#

yeah

fiery turtle
#

Maybe disable logging completely when profiling?

fiery ice
fiery ice
#

and here it is

#

and my alloc seems pretty good rn

fiery turtle
#

there are a lot of redudant deep copies in the interpreter that cause extra allocations

#

but they arent easy to get rid of

hallow marten
#

yes they are

fiery turtle
#

since id need to know whether an object is a prvalue or not

fiery turtle
#

but tbh even as is it gets 10M ops/s

hallow marten
# fiery turtle are u an aml expert now lmfao

They’re honestly pretty easy to deal with once you look at them the right way. Most of those deep copies aren’t fundamentally required—they’re usually just there for safety or convenience. In a lot of cases, you can replace them with shallow copies, references, or move semantics without changing behavior.

fiery turtle
#

which is miliseconds even on most bloated aml

#

most bloated aml is like maybe 30k ops total

fiery turtle
#

go fix them make no mistake

#

also switching to computed gotos is a possibility for increasing perf

hallow marten
#

I dont think computed gotos even do anything nowadays

fiery turtle
#

nah i saw some example recently where they had some simple bytecode interpreter

#

and computed gotos boosted perf by a lot

#

it was all tail call based

hallow marten
#

was it a recent example

#

cuz I think I know what you're talking about

#

but that post is pretty old

fiery turtle
#

maybe

#

right now when microcode ops call into C it uses a dispatch table of function pointers

hallow marten
#

ah yeah thats probably not good

fiery turtle
#

yeah

craggy epoch
fiery turtle
#

thanks

#

cool arm with proper acpi

#

how it should always have been

#

looks like power state transitions still require prorietary drivers tho

loud ice
#

which is as much of a proprietary driver as SMM

fiery turtle
#

yeah maybe idk, its not indicated by acpi

loud ice
#

the arm equivalent(ish) of smm has a defined api boundary

#

you use it for AP startup and power management and shit

vast kestrel
#

Is it possible to invoke a psci via aml even

fiery turtle
#

like technically acpi has a proper power management spec for reduced hardware

#

but its not used here

vast kestrel
#

Smi you can cause it's port Io

vast kestrel
#

But isn't psci done via some special opcode

loud ice
#

actually sounds interesting

fiery turtle
#

it can be any address space they want

loud ice
#

hmm does linux support that

fiery turtle
#

yeah

loud ice
#

also how does the whole interface work, anyway

loud ice
fiery turtle
#

u read the magic values to write into the register from the state object, e.g. _S5 for state 5

#

then run _PTS, then write them into the register

loud ice
fiery turtle
#

multiple ways

loud ice
#

on x86 this works with smm

#

but idk if there is a "plz jump to physical address 0x4141424243434444 with no paging now" aml op

fiery turtle
#

generic address register has a way to specify hardware-specific address space, which could mean call into firmware with that instruction

loud ice
#

ok sure but that would require kernel support anyway

fiery turtle
#

yeah ofc

loud ice
#

there isnt anything generic ig?

fiery turtle
#

nothing to call into the psci i dont think

#

but i could be wrong

#

these are the defined address spaces

#define ACPI_AS_ID_SYS_MEM       0x00
#define ACPI_AS_ID_SYS_IO        0x01
#define ACPI_AS_ID_PCI_CFG_SPACE 0x02
#define ACPI_AS_ID_EC            0x03
#define ACPI_AS_ID_SMBUS         0x04
#define ACPI_AS_ID_SYS_CMOS      0x05
#define ACPI_AS_ID_PCI_BAR_TGT   0x06
#define ACPI_AS_ID_IPMI          0x07
#define ACPI_AS_ID_GP_IO         0x08
#define ACPI_AS_ID_GENERIC_SBUS  0x09
#define ACPI_AS_ID_PCC           0x0A
#define ACPI_AS_ID_FFH           0x7F
#define ACPI_AS_ID_OEM_BASE      0xC0
#define ACPI_AS_ID_OEM_END       0xFF
#

but i mean psci eventually does some mmio writes and stuff anyway right

#

that could be expressed in aml

loud ice
#

because the cpu resets into the secure monitor

#

so if you could control the reset vector that would be bad™

#

but anyway i dont think there is even any way to make acpi sleep work on arm

#

other than with psci

fiery turtle
#

ah yeah i guess because of protections u cant yeah

#

ig

loud ice
#

although i wonder if you could hack together an acpi table that would make acpi sleep work on m1

#

would be so jank

fiery turtle
#

does apple stuff also rely on that for shutdown?

loud ice
#

apple has magic drivers

fiery turtle
#

wdym

loud ice
#

apple doesnt use psci at all

#

and you cant make it work on apple hw without losing virt

#

which is more important

fiery turtle
#

I guess that should be easy to express in aml then?

loud ice
#

i dont know if it is no

#

i suspect the answer is more like "yeah no" though

fiery turtle
#

Lol

fiery turtle
loud ice
#

psci needs either el2 or el3

#

virt needs el2

#

and you cant use either for both at once

#

oh and apple doesnt implement el3

fiery turtle
#

Why does virt need el2

loud ice
#

x86 virt requires you to be outside of a vm too

fiery turtle
#

Yeah so you can run the kernel in el2 and run aml there too

#

And virt runs in el1 no?

loud ice
#

virtualized code runs in el1

#

yes

loud ice
fiery turtle
#

Well at least shutdown would be nice

loud ice
#

they have some kind of hack that makes it work without acpi

#

and without psci

#

ah its not a hack

#

i think the jank is that it cant do suspend or smth idr

fiery turtle
#

is there like an adhoc driver for that in asahi

loud ice
#

its upstream

#

for poweroff at least

#

i dont think you could make that really work with aml tbh

and even if you could, aml is shit as a programming language lol

fiery turtle
#

Can you show it

loud ice
#

well so its two drivers

#

driver one does a bunch of shit and then this: ```c
static int macsmc_power_off(struct sys_off_data *data)
{
struct macsmc_reboot *reboot = data->cb_data;

dev_info(reboot->dev, "Issuing power off (off1)\n");

if (apple_smc_write_u32_atomic(reboot->smc, SMC_KEY(MBSE), SMC_KEY(off1)) < 0) {
    dev_err(reboot->dev, "Failed to issue MBSE = off1 (power_off)\n");
} else {
    mdelay(100);
    WARN_ONCE(1, "Unable to power off system\n");
}

return NOTIFY_OK;

}

fiery turtle
loud ice
#

apple_smc_write_u32_atomic is ```c
int apple_smc_write_atomic(struct apple_smc *smc, smc_key key, const void *buf, size_t size)
{
guard(spinlock_irqsave)(&smc->lock);
u8 result;
int ret;
u64 msg;

if (size > SMC_MAX_SIZE || size == 0)
    return -EINVAL;

if (smc->boot_stage != APPLE_SMC_INITIALIZED)
    return -EIO;
if (!smc->atomic_mode)
    return -EIO;

memcpy_toio(smc->shmem.iomem, buf, size);
smc->msg_id = (smc->msg_id + 1) & 0xf;
msg = (FIELD_PREP(SMC_MSG, SMC_MSG_WRITE_KEY) |
       FIELD_PREP(SMC_SIZE, size) |
       FIELD_PREP(SMC_ID, smc->msg_id) |
       FIELD_PREP(SMC_DATA, key));
smc->atomic_pending = true;

ret = apple_rtkit_send_message(smc->rtk, SMC_ENDPOINT, msg, NULL, true);
if (ret < 0) {
    dev_err(smc->dev, "Failed to send command (%d)\n", ret);
    return ret;
}

while (smc->atomic_pending) {
    ret = apple_rtkit_poll(smc->rtk);
    if (ret < 0) {
        dev_err(smc->dev, "RTKit poll failed (%llx)", msg);
        return ret;
    }
    udelay(100);
}

if (FIELD_GET(SMC_ID, smc->cmd_ret) != smc->msg_id) {
    dev_err(smc->dev, "Command sequence mismatch (expected %d, got %d)\n",
        smc->msg_id, (unsigned int)FIELD_GET(SMC_ID, smc->cmd_ret));
    return -EIO;
}

result = FIELD_GET(SMC_RESULT, smc->cmd_ret);
if (result)
    return -EIO;

return FIELD_GET(SMC_SIZE, smc->cmd_ret);

}
EXPORT_SYMBOL(apple_smc_write_atomic);

loud ice
#

its a mailbox

#

there is a whole ipc-y system used to talk to devices

#

which is involved here

fiery turtle
#

Ah

loud ice
#

the smc also owns the rtc

#

and apple_rtkit_send_message is another lots of code: ```c
int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
struct completion *completion, bool atomic)
{
struct apple_mbox_msg msg = {
.msg0 = message,
.msg1 = ep,
};

if (rtk->crashed) {
    dev_warn(rtk->dev,
         "RTKit: Device is crashed, cannot send message\n");
    return -EINVAL;
}

if (ep >= APPLE_RTKIT_APP_ENDPOINT_START &&
    !apple_rtkit_is_running(rtk)) {
    dev_warn(rtk->dev,
         "RTKit: Endpoint 0x%02x is not running, cannot send message\n", ep);
    return -EINVAL;
}

/*
 * The message will be sent with a MMIO write. We need the barrier
 * here to ensure any previous writes to buffers are visible to the
 * device before that MMIO write happens.
 */
dma_wmb();

return apple_mbox_send(rtk->mbox, msg, atomic);

}

#

and apple_mbox_send is another screen of code

#

and its DMA btw

fiery turtle
#

Why is it called an rt kit

loud ice
#

lol

fiery turtle
#

Framework as in like set of APIs?

loud ice
#

seems like its an rtos lol

fiery turtle
#

There's a coprocessor running it?

loud ice
#

ofc

fiery turtle
#

Lol

loud ice
#

its apple

fiery turtle
#

I guess thats a neat way to do it but

loud ice
#

everything is a coprocessor

#

the display output thing is a coprocessor too

frank canopy
fiery turtle
#

Iirc the iPhone camera runs a separate Linux instance or something?

loud ice
#

well its not linux lol

fiery turtle
#

Someone said it literally was Linux

loud ice
#

that would be very weird

pine leaf
loud ice
pine leaf
#

I remember it's the case on some at least

#

people have gotten Linux running on specifically the touchbar

#

not the mac itself

#

the touchbar individually

loud ice
#

the touchbar was its own thing yeah iirc

fiery turtle
loud ice
#

apple loves putting too many cpus in things

#

its so dumb

fiery turtle
#

Isn't that really increasing the cost for everything

pine leaf
#

Nintendo did it first in 2006 trl

pine leaf
#

(probably not first; but before Apple at least)

loud ice
#

or not significantly anyway

fiery turtle
loud ice
#

its probably some arm thing

pine leaf
fiery turtle
#

Does it run some customized Darwin kernel by default or

loud ice
#

i think it was vulnernable to the same bootrom bug as iphone bootroms were lol

pine leaf
loud ice
#

its arm64 too

loud ice
fiery turtle
#

lol

hallow marten
#

Like they have a distinct thing from Darwin that they use somewhere

craggy epoch
craggy epoch
loud ice
craggy epoch
loud ice
#

oh lol

#

i think that wont fly for linux but idk

craggy epoch
#

It would fly just fine for a vendor Linux. Android does stuff like that all over the place.

frank canopy
fiery turtle
#

all pci stuff is described properly including allowed bar ranges etc tho

hollow elm
kind mantle
#

Is uacpi-rs reasonably up to date and maintained?

fiery turtle
#

might be worth asking in #1287451030241542205

vocal geyser
fiery ice
#

and you have to output the correct log syntax

fiery ice
#

@fiery turtle if i want to use uAcpi in userspace, i would have to use ioperm, but where should i use it?

#

i could do it in the io_read and write ops

#

and that should be pretty straightforward, but i am worried it might cause slowdowns

hollow elm
#

io_map and io_unmap?

#

that seems like a natural point to grant permissions

fiery ice
#

should i just use ioperm with the base?

#

i am worried it won't work with the offset later

hollow elm
#

i mean in the tss io bitmap just set bits corresponding to the ports in range [base, base+len)

calm latch
#

I just iopl 3 it

fiery ice
#

💀

hollow elm
#

for the acpi server might as well tbh

calm latch
#

but you can probably refcount it in userspace, and call your kernel helpers to enable/disable it in tss

hollow elm
#

given aml can just request arbitrary ports anyway

calm latch
#

from io_map/io_unmap

fiery ice
calm latch
#

yeah

fiery ice
#

thx

calm latch
#

Or you can just call kernel

#

like io is slow anyway so an extra roundtrip won't be noticeable I guess

#

you also need to think about pci discovery and stuff probably

fiery ice
#

i'm gonna use messages + a dedicated pci service for that

calm latch
#

cool

#

(also, why is everyone writing microkernels all of a sudden?)

fiery ice
#

i already have a messaging interface done

calm latch
#

like last week was the init server week

fiery ice
#

lol

calm latch
#

cool

#

how are you doing your ipc?

fiery ice
#

i have a central service that handles registration of the others

#

and you can call that to get the other services tid and port to send messages to

calm latch
#

no, I mean what's your ipc model, out of curiosity

#

not the discovery

#

(also, I'm thinking I can walk away from having a central discovery mechanism in my os)

fiery ice
#

i just made a custom message struct and use this to send messages between threads, messages are stored in a server queue and routed accordingly

#

this struct could prob be reduced tbh

calm latch
#

it's fine

#

mine is larger

loud ice
#

and in kernelmode its an unbounded message queue?

fiery ice
#

yeah it's unbounded

calm latch
#

so is it async send sync receive like mine?

fiery ice
#

i should probably put limits on it tho

calm latch
fiery ice
#

XD

#

@calm latch what would be the best method for a per thread IOPB?

#

or per process

#

copying the iopb array would be expensive, no?

calm latch
#

I guess just allocate a tss when you enable it

fiery ice
#

so a TSS per thread?

calm latch
#

idk

torpid root
#

CoW it if you want

calm latch
#

I'd imagine per-process would be problematic because you need to store the kernel stacks somewhere

#

I guess you could allocate one per cpu for each process and rotate through them though

rustic compass
#

or given that io ports are rarely used today have a syscall for io port reads

fiery ice
calm latch
#

but then you'd be copying the bitmap

fiery ice
#

the tss is still per process

#

if you do per process

calm latch
#

yeah, but what I mean is that you need to allocate tss per cpu per process

fiery ice
#

no?

#

oh wait

#

you would have to update the pointers

#

fuck it, syscall it is

flat badge
calm latch
#

I can just not support FRED then trl

flat badge
#

or support the tss bitmap

calm latch
#

extra work anyway

flat badge
#

you can emulate iopl by just storing an all ones bitmap in the tss

calm latch
#

I can also catch gpfs

flat badge
#

and then you can swap the pointer to the bitmap

#

this requires minimal effort

calm latch
#

no, if I'm doing it, I'm doing it properly, and with capabilities and stuff, and the proper bitmap

#

capabilities for everything is very nice anyway

#

like you don't have to do anything, and your system has suddenly got very good access control infrastructure

flat badge
#

you can also have a cap that gives access to all ports

calm latch
#

yeah, but that's boring

#

because otherwise it's very nice for drivers

#

especially if (when) I end up supporting iommu

#

(like as a whole)

#

I already have capabilities for interrupts, I'm planning to implement capabilities for timers and physical memory

fierce kiln
#

is dis fast

#

idk

#

i never pay attention to my benchmarks unless they become abominable

#

which is less frequent these days

#

this is emulated x64 on apple silicon m4

fiery turtle
#

TCG is usually an order of magnitude slower so good job

fiery ice
#

i think mine will work even better when i move uacpi to userspace

frank canopy
# fierce kiln is dis fast

qemu tcg or whatever the apple compat layer thing is? i keep hearing people say they have one but idk how good it is lol

left orbit
#

rosetta

#

?

#

but that's for running native applications

#

i belive it does aot x86->arm64

#

at least to some degree, idk how much you can really translate ahead of time

flat badge
#

I think it also links the transpiled apps against native libs

#

such that for example the gpu driver etc. runs natively

rustic compass
#

@fiery turtle is the string passed by uacpi_kernel_log changed after the function returns?

#

so is the lifetime limited to the function invocation?

fiery turtle
#

yes

loud ice
#

if you have formatted logging probably not tho

fiery turtle
#

i assume its talking about the non-printf version

#

since its for rust bindings

loud ice
#

ah yeah

rustic compass
#

anyway,
how should i handle if the user of uacpi-rs hasnt implemented memory map/unmap as there isnt a status return

fiery turtle
#

in for-5.0 there's a UACPI_MAP_FAILED

fiery turtle
loud ice
rustic compass
fiery turtle
#

lol

rustic compass
fiery turtle
#

i wasnt referring to you lmao

rustic compass
fiery turtle
#

on older versions returning NULL is treated as an error

fiery turtle
#

@pallid lava btw why did u need to trace ec events in linux

pallid lava
#

i wanted to know whatever is being called on my laptop

#

so when i get to write an ec driver i can make sure i am not reading garbage from the ec

fiery turtle
#

Ah ok

pallid lava
#

so uh

#

should there be an _EXX or something similar in \_GPE for the EC's GPE?

#

i am trying to install the gpe handler and i am getting not found error

fiery turtle
#

_EXX are run by uacpi automatically

pallid lava
#

okay, yeah, my issue is with uacpi_install_gpe_handler, that's the thing that is erroring

fiery turtle
#

did u verify that you're passing the right index?

pallid lava
#

Nvm, I was not calling finalize_gpe..., and i was supposed to pass null as first argument to install and enable handler

#

Now everything works ok

fiery turtle
#

yeah it expects a GPE device, which is either \_GPE or a custom installed GPE block

#

or NULL which implies the former

fiery turtle
pallid lava
#

got ec events and method dispatch working chad

#

as a fun fact, the ec apparently intercepts some fn + something keys in my laptop

#

the arrow keys for controlling the backlight brighness of the keyboard, and f7/f8 for the display backlight brighness

#

however, the aml code for the keyboard does not do anything unless you discover the wmi object that controls the keyboard and other memes and you initialize it (aka call some magic function with some magic values)

fiery turtle
#

Yeah wmi is a funny thing

pallid lava
#

and after you initialize it

#

that thing only sets a variable to 1, which is tested in the _Qxx method, and if set, does a notify() on the wmi object

fiery turtle
#

Ye

pallid lava
#

and then you have to handle that natively and call some other magic method and shi

fiery turtle
#

That's pretty normal

pallid lava
#

for the display brightness it gets a bit more weird

#

because it complains about objects that do not exist

fiery turtle
#

Lol

pallid lava
#

it complains about \blablabla...VGA.EDP

fiery turtle
#

Does it do that on Linux

pallid lava
#

letme check

fiery turtle
#

Also I mean

#

Just dump aml and check if its supposed to

pallid lava
#

yes

#

it complains in linux too

fiery turtle
#

Ah ok

#

Good firmware u got

pallid lava
#

extremely epic one

#
May 09 21:04:25 AtiePC kernel: ACPI BIOS Error (bug): Could not resolve symbol [^PCI0.GPP0.PEGP.EDP1], AE_NOT_FOUND (20251212/psargs-332)
May 09 21:04:25 AtiePC kernel: ACPI Error: Aborting method \_SB.BRTN due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:25 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0.QLIB due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:25 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0._Q17 due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:26 AtiePC kernel: ACPI BIOS Error (bug): Could not resolve symbol [^PCI0.GPP0.PEGP.EDP1], AE_NOT_FOUND (20251212/psargs-332)
May 09 21:04:26 AtiePC kernel: ACPI Error: Aborting method \_SB.BRTN due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:26 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0.QLIB due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
May 09 21:04:26 AtiePC kernel: ACPI Error: Aborting method \_SB.PCI0.SBRG.EC0._Q17 due to previous error (AE_NOT_FOUND) (20251212/psparse-529)
#

during namespace initialization both linux and uacpi complain about some other objects not existing

mortal yoke
#

reminds me that iirc on my laptop the ec fn keys were interacting weirdly with my ps2 driver at some point so then it stopped working or something, idr if that was with the old bad osdev wiki driver tho or the new better one that's based on linux's KEKW or it could have been qacpi weirdness somehow as there were also the spurious power button events during boot

fiery turtle
#

Lmao

fiery turtle
mortal yoke
# fiery turtle Iirc u fixed those power button events right

I don't think they actually got fixed, I did remove the ec clearing code that was also causing qookie's laptop to hang there but I think they did still happen when I last tried (I just though they were fixed because they didn't happen for a decent amount of boots)

pallid lava
#

otoh i have backlight methods in aml

#

the standard ones, specified in the acpi specification appendix

#

i have to see whether they work

fiery turtle
pallid lava
#

ASUS TUF Gaming A15 FA506NC

fiery turtle
#

yeah those usually have shit aml

pallid lava
#

lol

#

i remember when i bought the laptop, i thought it would be a good idea to install the asus linux kernel

fiery turtle
#

Thats a thing?

pallid lava
#

it's a community kernel

fiery turtle
#

Huh lol

pallid lava
#

after rebooting to it, the keyboard backlight stopped working after the firmware phase

fiery turtle
#

Lol

pallid lava
#

i was ultra panicking

#

i tried everything to get them back to work, including trying to write values to the sysfs attributes for the backlight

#

it resulted that idfk what they had done but their wmi driver was nuts

#

after cross referencing the mainline kernel source code with what the writes to the attributes should do

#

then i got back to an original kernel and the keyboard backlight started working again

#

those were the 2 scariest days in my life because i had just bought the laptop and i tried everything in whatever forum i found, including pressing the power button for 40 seconds to clear the ec, which i am not still sure whether that works

hollow elm
#
[85585.698385] atkbd serio0: Unknown key pressed (translated set 2, code 0xab on isa0060/serio0).
[85585.698396] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
[85585.781303] atkbd serio0: Unknown key released (translated set 2, code 0xab on isa0060/serio0).
[85585.781310] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
[85586.546999] atkbd serio0: Unknown key pressed (translated set 2, code 0xab on isa0060/serio0).
[85586.547011] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
[85586.673181] atkbd serio0: Unknown key released (translated set 2, code 0xab on isa0060/serio0).
[85586.673187] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
pallid lava
#

btw, has anyone here got sleep working?

#

i wonder if it would be possible to have the display working after waking up without having to write native video drivers, or only using aml methods

fiery turtle
#

@north holly and @calm latch did

#

oberrow had it working on real hw

#

but no display, that requires full gpu re-init

calm latch
#

I mean me too, but I didn't have GPU drivers

north holly
#

in theory sleep code still is correct

pallid lava
#

so you know you're awake via serial or some other mechanism, that is not by video?

north holly
north holly
pallid lava
#

oh okay

fiery turtle
#

u also need a real mode wake trampoline and own smp bringup code etc

#

its fun

north holly
#

u need to restore pci state too

#

which was fun to do

pallid lava
#

D0uninitialized by beloved

fiery turtle
#

it clears all BARs etc

pallid lava
#

i guess that it is not possible to use the boot services after waking up

fiery turtle
#

yeah ofc

#

u become the firmware

pallid lava
#

well nooo

mortal yoke
#

what would you even use them for

calm latch
fiery turtle
calm latch
pallid lava
mortal yoke
#

ah

pallid lava
#

to get a fb with gop

#

but in that case the firmware would have to reinitialize the video card too

fiery turtle
#

but yeah no u need suspend/resume callbacks for all drivers

north holly
#

on qemu u can make a bochs vbe driver to restore the fb fwiw

pallid lava
#

yeah but real hw is more exciting

fiery turtle
#

because u havent upstreamed the seabios fix

#

or rather, it disables ecam iirc

north holly
#

oh yeah forgot about that

pallid lava
#

wait, whats the problem with it

mortal yoke
fiery turtle
north holly
pallid lava
#

lol

#

seabios skill issue

north holly
#

or well it is but something else prevents it from being restored

fiery turtle
#

but idk if any firmware supports that trampoline

pallid lava
#

like seabios already has code for handling s3 wakes

#

how did they forget that, or qemu has had a nasty regression

fiery turtle
#

its just a logic bug in seabios

#

it write protects that

#

so writes do nothing

north holly
#

yeah that's it

#

i'd upstream my fixes but that's a lot of work

pallid lava
#

welp

north holly
#

if anyone wants to takeover it's a really simply patch

pallid lava
#

the seabios mailing list has very low traffic

north holly
#

(it's a lot of work because it interrupts my hyperfixation)

pallid lava
#

you could get it upstreamed in a few days

mortal yoke
#

iirc the problem wasn't that, it was that it left the mmconfig pointing to the ecam space and then after resuming the pci accesses it does (like enabling the ecam itself) try to use the mmconfig that isn't enabled

fiery turtle
#

seabios should be easy to upstream yeah

#

oh yeah maybe

#

it uses ecam to enable ecam

#

which fails

pallid lava
fiery turtle
#

@north holly can u post the patch here

north holly
#

i don't think i have it anymore

#

u would have to search the seabios mailing list for it

mortal yoke
pallid lava
#

make_bios_writable?

north holly
north holly
pallid lava
#

yeah ik

#

but what does it have to do with the ecam thing

#

ah okay

mortal yoke
#

it has to do with being able to write the variable

pallid lava
#

to modify the variable, right

north holly
#

ye

north holly
# north holly lgtm

i think they had a problem with just doing that in a random place if u wanted to find my post on the mailing list

#

before u submit the patch

north holly
#

yeah mainly just my own patch skill issues

mortal yoke
#

I think the comment about the bios readonly doesn't really even apply here as the commented out code wasn't there originally to begin with (and its made read-only later on in the same function anyway)

north holly
#

and forgot to when i got back

fiery turtle
#

would be nice if someone picked that up

north holly
#

sure would

pallid lava
#

well

#

_BCM seems to do nothing

#

it does some magic stuff and then a notify

fiery turtle
#

sadge

#

maybe u need some igpu pre-init before u can use it or smth

#

or hook the notify and do something

#

what an issue

calm latch
calm latch
fiery turtle
#

lol

#

how did u even uncover that

calm latch
#

stalking that person's profile

fiery turtle
#

lol

#

yeah idk maybe thats what they meant

calm latch
#

They just use gcc, so I guess uACPI could be compatible?

fiery turtle
#

im not sure it will compile in 16 bit mode but who knows

calm latch
#

why wouldn't it?

fiery turtle
#

UACPI_POINTER_SIZE checks for phys_addr etc

fiery ice
#

random u64s

fiery turtle
#

16 bit gcc doesnt support u64?

fiery ice
#

idk if 16 bit supports them

fiery ice
fiery turtle
#

no idea

fiery ice
#

clanker time

fiery turtle
#

honestly im not sure how that would even work considering the DSDT is definitely larger than 64k

fiery ice
calm latch
#

oh no, uacpi is AI tainted now nooo trl

fiery turtle
#

so u need segment support also

calm latch
kindred beacon
fiery turtle
#

yeah lol

fiery turtle
#

this is for open watcom

fiery ice
#

then clanker is stupid

#

lol

calm latch
#

yeah

fiery turtle
#

but clanker is right about other aspects

#

like 16-bit aml interpreter makes no sense

#

u literally cant even read the entire dsdt in one segment

calm latch
#

Is their thing 16 bit?

fiery turtle
#

i thought so since its DOS

fiery turtle
#

maybe its fine then

calm latch
#

Like if they're talking about windows, maybe they target i386 or something?

#

whatever is this

#

So maybe they do want to generate AML or something

#

I'm confused

fiery turtle
#

who knows what they want lmfao

calm latch
#

I think I'm gonna go back to doing what I was doing before, which is figuring out how tf linux manages its io bitmap/tss on x86...

fiery ice
#

works fine

calm latch
#

do you just copy all 16kb of memory?

#

8kb*

fiery ice
#

basically i have a per core tss, that is used by all the normal processes

#

then, if a thread needs an io bitmap

#

the tss gets cloned only for that thread

calm latch
fiery ice
#

my approach is faster and more reliable tbh

#

i just have a set of common pointers

#

that all the TSSes use

#

for each core

#

and the tss does not need to be copied

#

so it's faster

calm latch
#

I don't get what you're doing

#

oh

fiery ice
#

basically i allocate a new tss per thread

#

if they need one

#

for io stuff

calm latch
#

but that's the easy part

fiery ice
#

and if the thread does have one, the scheduler loads that one

#

if it does not, it just uses the cpu one

calm latch
#

What's complicated is that I'd need a TLB-shootdown like thing

#

for this

fiery ice
#

for cpu i mean the local shared tss

#

wdym

calm latch
#

when you take the permissions away

fiery ice
#

hmm

#

i just reload the tss using ltr

calm latch
#

I don't think it gets cached

fiery ice
#

wdym gets cached?

#

like it doesn't update the perms?

calm latch
#

like you don't need to reload it since the cpu looks it up on every access iirc

fiery ice
#

hmm

#

i change the gdt entry every time i have to switch it

#

so i tought i had to reload it

calm latch
#

in that case you do

#

but like when you change the tss itself you don't

fiery ice
#

yeah in that case no

#

tho i do it bc of how my syscall works

calm latch
#

Or I can just make it a syscall trl

fiery ice
#

wdym

calm latch
#

like not bother with tss and just call the kernel to i/o in ring 0

fiery ice
#

💀

calm latch
#

I'm gonna steal it

#

and this shit should be trivial to do

#

omg wtf

fiery turtle
#

W/e I guess

#

Not that I care about Userspace pio

calm latch
fiery turtle
calm latch
#

Because per-thread makes no sense

fiery turtle
#

Even so, the process can migrate between cpus right

calm latch
#

Yeah, and the process can have more than 1 thread running on more than 1 CPU at any given time

fiery turtle
#

So how do u sync stuff

fiery ice
#

lol

#

if you don't wanna nuke stacks

calm latch
fiery ice
#

how do you plan on not nuking rsp0?

#

or the ists

calm latch
# fiery turtle So how do u sync stuff

So my plan is to allocate 4 page frames virtual window, where the first page will be the per-CPU stuff, the two pages in the middle will be swapped in the page tables between the threads/processes (so the TSS stays in the same place in virtual memory, but the underlying memory changes between the processes), and the last one would also be the same (for the Intel's skill issue 0xFFFF terminator byte)

fiery ice
#

ah right if you only swap the 4 iopb pages the stacks won't get touched

#

tho wait

fiery ice
#

why 4 pages?

#

i think you only need 3

calm latch
fiery ice
#

the iopb is just 8k

#
  • a third page for the extra byte
calm latch
#

And switching is not too bad since you're just changing two leaf page table entries

fiery ice
#

ah wait, 4 pages is the full TSS you mean

calm latch
# fiery ice why 4 pages?

1 page for TSS (per-CPU), 2 pages for the bitmap (64K entries, 8KB of RAM per-process), and extra page (which will 1 page shared between everyone) for the meme in the screenshot

calm latch
calm latch
#

Also, while I'm at it, I might as well fix my stack allocation code and add guard pages as well...

calm latch
flat badge
#

That scheme sounds way more convoluted than simply loading another tss

calm latch
#

No

#

It's very simple

#

The only issue is that I need to decide if I want to trap GPFs and have a small instruction decoder, or to IPI other cores...

#

The first option sounds like an absolute nightmare on x86

#

I think I'll just hijack my TLB shootdown thing for this

flat badge
calm latch
#

So?

flat badge
#

which is not very simple + has design implications on the rest of the virtual memory subsystem

calm latch
#

I'll never free them once allocated

#

And I'll track them lazily

loud ice
#

just make an outb syscall tbh

flat badge
#

the alternative is a ltr instruction which doesn't have any impact on the rest of the kernel at all

calm latch
#

I thought about it yesterday, and didn't come up with any obvious issues

calm latch
flat badge
#

what's even the benefit over just ltr in all cases?

calm latch
#

That I don't have to allocate a million of TSSes, and syncrhonize them on every bitmap change

flat badge
#

Just make it per thread

calm latch
#

And that it can be faster

calm latch
flat badge
calm latch
#

With uACPI

flat badge
#

I don't buy "it is faster" w/o benchmarks

loud ice
#

at least for this kind of thing yeah its dicey

#

i would really just have an inb/outb syscall tbh, or iopl

flat badge
#

You're trading one instruction for extra effort in the VMM

#

that sounds like it's really not worth it to me

calm latch
#

The only extra "expensive" part compared to per-thread TSS is (maybe) swapping 2 pages in the page tables, but userspace stuff becomes a lot easier if it's per-process

flat badge
#

the syscall is probably fine

loud ice
#

just trap it with fred

flat badge
#

but supporting the bitmap is also not hard

loud ice
#

actually i have an even better idea

#

just make a jit

calm latch
flat badge
#

if you swap pages you need to TLB invalidate

calm latch
#

No remote shootdowns

flat badge
#

uh that becomes hard to reason about

calm latch
#

The TSS is per-CPU

#

Idk I'll implement it and you can look at the code trl

loud ice
flat badge
#

I'm aware but if you do it like this you can accessible-but-not-referenced-anymore pages over extended periods of time

calm latch
loud ice
#

tbh i doubt any of the approaches are meaningfully better

flat badge
#

the entire argument is moot until you have benchmarks on the cost of ltr

#

I bet this scheme is not worth it

calm latch
#

But I will ltr anyway

loud ice
#

ltr is certainly more annoying

flat badge
calm latch
#

Like what this saves me from is trying to figure out how to synchronize multiple bitmaps in userspace

loud ice
#

invlpg is 200+ cycles on intel

#

and 100+ on amd

calm latch
calm latch
flat badge
loud ice
#

i would have two tsses, one with all bits set and one with no perms and just switch between the two with ltr tbh

calm latch
#

But I don't really want iopl emulation

loud ice
#

well really youd need two entries anyway

#

imo iopl is just the better way to solve the problem for the like one driver which needs it

calm latch
#

Not if you have per-CPU GDT

loud ice
#

encoding a gdt entry isnt free either

calm latch
#

(or like you can wrap it with a lock or whatever, since ltr is cached)

loud ice
#

a lock is even worse tbh

calm latch
#

But sure

loud ice
#

yeah idk which fields contain the size tbh

calm latch
#

Idk either tbh but it doesn't matter

calm latch
flat badge
#

I'd just have per-thread bitmaps

#

which is what Managarm exposes

#

then you just ltr on task switch

loud ice
#

you are never creating a capability which only lets you do acpi and nothing else

calm latch
#

but you don't have uacpi in userspace...

loud ice
flat badge
#

except for switches between tasks with no enabled io ports, for these you just keep a global tss

calm latch
#

yeah, ofc

loud ice
flat badge
#

well, for acpi i agree that just iopl-like control is fine but you also need pio for some pcie drivers

loud ice
#

its not on the fast path for them though, right?

calm latch
#

you need pio for a bunch of stuff on x86

loud ice
#

@fiery turtle you shouldnt be using volatile loads when you do sync btw (this is source/mutex.c)

#

and also cmpxchg_weak is a thing

calm latch
#

Like idk, I have ns16550 and PS/2 drivers for example, both of those need 2-4 IO ports, like it would be nice to not have to give them out full iopl

loud ice
#

i guess

#

this is where kernlets come in

fiery turtle
#

yeah we discussed this before

#

i just never fixed it

loud ice
#

ah ok

calm latch
#

how many cycles is in/out stuff?

fiery turtle
#

how does it help anyway

loud ice
loud ice
#

sometimes by a lot

fiery turtle
#

arm doesnt have a global lock

#

this is for non-hw-reduced

loud ice
#

oh is it an x86 meme

#

okay then yeah it doesnt matter

fiery turtle
#

whast the diff btw

loud ice
#

weak is allowed to randomly fail

fiery turtle
#

ah ok

#

when would u use a non-weak if its faster?

calm latch
#

Like would 200-400 cycles for 2 invlpgs even matter compared to the IO itself?

loud ice
calm latch
fiery turtle
#

ah ok basically where u dont expect it to fail

loud ice
#

the really big number is throughput

calm latch
#

Also, I don't have PCIDs, so I just TLB flush anyway

loud ice
#

(in order: alder lake P, aalder lake E, zen5)

#

also lol doing an OUT on alder lake causes the JMP unit to do things

#

i wonder why meme

calm latch
#

Syscall is also like 50 cycles for the instruction itself + however long the kernel takes to do its stuff

loud ice
#

its a lot more than 50 iirc

calm latch
# loud ice

What about ltr? (and also, which website is this?)

loud ice
#

they dont list ltr

loud ice
#

i think its a bit more on x86

calm latch
#

Also, I guess it could be faster with FRED?

#

Since they've gotten rid of GDT memes

loud ice
#

because you gain however much time loading a tss takes

#

and you lose a few hundred cycles for a syscall which is not that much compared to the actual op

calm latch
#

How slow is FP/vector stuff save/restore on x86?

loud ice
#

no idea

flat badge
#

so if you do the non-weak version in a retry loop you have nested retry loops

#

which is unnecessary

fiery turtle
#

makes sense

#

maybe its relevant for itanium

#

which is the other non-hw-reduced platform

flat badge
#

it's relevant for all ll/sc archs

fiery turtle
#

is itanium one?

flat badge
#

idk ¯_(ツ)_/¯

fiery turtle
#
The Intel Itanium (IA-64) architecture does not use the traditional Load-Link/Store-Conditional (LL/SC) paradigm for atomic operations found in many RISC architectures (like MIPS or ARM).Instead, Itanium utilizes a combination of predication, speculation, and explicit, serialized memory instructions within its EPIC (Explicitly Parallel Instruction Computing) design to handle atomic operations and synchronization.
#

looks like it has cmpxchg in the isa

calm latch
#

Does Itanium have defined PE format and clang PE target? ultrameme

#

(Ultra meme)

fiery turtle
#

yes but no emulator support

#

trust me i wish it was relevant

calm latch
#

This is so sad...

#

The used servers are expensive

#

(I need to stop geting sad about random things which don't matter)

fiery ice
#

@fiery turtle What stage of the normal init i have to be to use uacpi_table_find_by_signature?

fiery turtle
fiery ice
#

oh cool

#

thx

calm latch
#

What's missing is capability and logic to set/clear the right bits (and i686), which is like nothing

#

And also I'm missing an invlpg when coming from tlb shoptdown routine

gentle peak
# loud ice many

isn't that heavily dependent on what hardware you're accessing with it

loud ice
calm latch
#

Does uacpi_namespace_node never get freed after getting it in uacpi_namespace_for_each_child?

#

I need it for a IPC thing where the drivers can request interrupts from my server with uACPI, where I plan to save the namespace node in some per-device thing, and then call _CRS to get the resources

#

(I mean managarm doesn't seem to free it at any point?)

fiery turtle
#

nodes exposed to client code are permanent

calm latch
#

So, do I need to go through ISA int overrides to get IOAPIC for this?

fiery turtle
#

Yes

rustic compass
#

@fiery turtle when will uacpi 5.0 likely be released?

fiery turtle
#

Tbh it only depends on my laziness to write tests and finish what I wanted

#

Soon ™

uneven wave
#

Could uacpi_kernel_wait_for_work_completion be replaced with a call to uacpi_kernel_schedule_work where the work item signals a semaphore? Would make the kernel API simpler.

pallid lava
#

and why not do that in wait_for_work_completion?

#

it's up to you how you implement workqueues

fiery turtle
pallid lava
#

also that would imply adding a new type of work

fiery turtle
#

Yeah

#

Also a lot of people using uacpi have completely broken or stubbed event api support, so the less thats used the better

pallid lava
#

everyone knows that the best workqueue is executing the work in place trl

fiery turtle
#

Technically if you execute uACPI interrupts in a preemptible context, nothing wrong with that

calm latch
fiery ice
#

@fiery turtle in uacpi_kernel_install_interrupt_handler, irq is an external interrupt that will go trough the IOAPIC, right?

torpid root
#

__ensure(irq == 9);

fiery ice
frank canopy
#

fwiw

fiery ice
#

oh

frank canopy
#

but yeah it goes through ioapic

fiery ice
#

perfect, thx

frank canopy
#

(and the isa interrupt stuff in madt too)

fiery turtle
#

Thats subject to the same translation as any other legacy interrupt

fiery ice
#

ok so ioapic it is

#

time to make an interrupt allocator

fiery turtle
#

But yeah you can hardcode it to 9 which it is always

fiery turtle
#

From the @fiery ice acpi dump that tried to map a bogus addres in @calm latch pmos:

OperationRegion (HBUS, PCI_Config, Zero, 0x0100)
Field (HBUS, DWordAcc, NoLock, Preserve)
{
    Offset (0x40), 
    EPEN,   1, 
        ,   11, 
    EPBR,   20, 
    Offset (0x48), 
    MHEN,   1, 
        ,   14,
    // 17 bit value, some sort of a base register? 
    MHBR,   17, 
}

Name (MH_B, Zero)

Method (GMHB, 0, Serialized)
{
    If ((MH_B == Zero))
    {
        MH_B = (MHBR << 0x0F)
    }

    Return (MH_B)
}

OperationRegion (MBAR, SystemMemory, (\_SB.PC00.GMHB () + 0x7100), 0x1000)
Field (MBAR, ByteAcc, NoLock, Preserve)
{
    Offset (0x10), 
    RBAR,   64
}

Method (IOMA, 0, NotSerialized)
{
    Return ((^RBAR & 0xFFFFFFFFFFFFFFFE))
}

Method (PIDS, 0, NotSerialized)
{
    Return (0x00C10000)
}

// The region that tried to map bogus value
OperationRegion (IOMR, SystemMemory, (IOMA () + PIDS ()), 0x0100)
#

I've extracted the important parts

#

so it gets some sort of a 17-bit base address from PCI config space, then shifts it up by 0xF bits. The it offsets it by 0x7100 and reads a 64-bit base address from that, which it ANDs with 0xFFFFFFFFFFFFFFFE

#

this was the address

#

@fiery ice i think we need a managarm test here before digging deeper or smth

#

Also whats funny is that aml has a shit ton of non stripped debug logs

calm latch
#

But what's weird is that all other addresses looked fine?

fiery turtle
#

Yeah hard to say why it could be bogus

calm latch
#

Maybe my kernel map is broken?

fiery turtle
#

thats why i said we should try managarm or smth before continuing

#

also make sure the pci map is correct as well

calm latch
calm latch
#

Wait a sec, I'm not at my PC, but I've printed what was given to me by uACPI directly

fiery turtle
#

well it could be a result of the previous mapping being incorrect

#

since that value is fetched as 10 indirections

calm latch
#

The mapping should be correct though

#

Was it above 4GB?

#

Maybe I'm truncating uint64_t somewhere

fiery turtle
#

who knows, we're only seeing a tiny portion of the log

calm latch
#

Though flanterm wouldn't work then

#

Since the framebuffer is at 512GB on my PCs

#

Also, I've added code to deduce caching types from e820, so in theory that should also be correct

#

Not that long ago

fiery turtle
#

that probably doesnt matter that much on x86 since MTRRs

calm latch
#

Yeah, but like in case they are broken

#

Another thing that can be tried is the i686 build trl

fiery turtle
#

yeah

#

i checked that the 17-bit load from the exact geometry register layout is performed correct

#

just compared the result against acpica runner

calm latch
#

But my PC doesn't want to turn on, and my laptop doesn't have disk space for that build

#

via etherwake

#

But still, how would that address go through AND?

fiery turtle
#

That and only removes the bottom 1 bit

#

Which you can see is not set in the map request

#

Why did you refuse to map it btw, what check do you have there

calm latch
#

Idr, I think it checks that the address is below 1 << 52

#

Idr if I get it from cpuid or not

#

Maybe even 1 << 48

fiery turtle
#

Ah

calm latch
calm latch
fiery turtle
#

Yeah I'm not saying its right

#

I was just curious

calm latch
#

Was the maximum phys addr in some cpuid thing?

#

on x86

fiery turtle
#

Yes

calm latch
#

Wtf is TME-MK?

#

Who needs memory encryption

fiery turtle
#

SEV etc is a popular thing as of recent

calm latch
#

This is nice

#

Up to 40 (3) with no (3)

#

Oh, it was on the next page, nevermind

fiery ice
fiery turtle
#

just press the power button

fiery ice
fiery turtle
#

unxz + dd

fiery ice
#

ah pain

#

time to find another usb

#

ok writing

fiery turtle
#

Hopefully it doesn't crash for other unrelated reasons

#

This is one of those cases where I wish there was a reference uacpi kernel

torpid root
#

sudo dd if=image of=/dev/sda

fiery ice
#

rn rufus is being slow to write

#

lol

fiery turtle
#

We can try obos if this doesn't work trl

fiery ice
#

lol

calm latch
fiery turtle
#

No idea tbh, im not monitoring that closely

fiery ice
#

this is slow XD

fiery turtle
#

Is this like a usb1 drive lol

calm latch
#

I recently bought a Kingston drive in a store without research, and even though it's USB 3 and from a reputable manufacturer, it has very slow write speeds as well

fiery ice
#

it is just rufus that is slow af

#

ok, booting managarm weston

hallow marten
#

no its probably just your drive lol

fiery ice
#

but writing with rufus is slow

#

lol, managarm is misreading my battery XD

#

by a lot

#

it says it has like 1MWh XD

#

and is charging

#

while it's def not

fiery turtle
#

What about the pwr BTN tho

fiery ice
#

it's still booting...

fiery turtle
#

Bruh

fiery ice
#

it's at PRNG reseeding rn

fiery ice
#

i pressed the power btn while here and it threw assertion failed

#

and now it is not doing anything

fiery turtle
#

Ffs I thought that assert was fixed lol

fiery ice
#

XD

fiery turtle
#

@north holly can you give an obos ISO

fiery ice
#

the latest iso on their server is from 2025....

fiery turtle
#

Wait wtf

fiery ice
fiery turtle
#

Oh u mean obos

#

Tbh u can probably use this one just find

fiery turtle
fiery ice
fiery turtle
#

Ofc

fiery ice
#

it went into instant kernel panic 💀

calm latch
#

Do I ask clanker to verify my PCI code?

fiery ice
#

try

calm latch
#

Tbh, I also saw some weirdness with it on my macbook in ahci driver, before I moved it to devicesd

#

Though it's weird...

#

I'm also compiling a i686 build

#

I also added a check to get the proper max phys addr now...

fiery turtle
fiery turtle
#

bruh how is there not a single bootable hobby kernel trl

calm latch
#

Mine is bootable trl

#

Who else had a competent kernel?

#

(i mean with a power button/shutdown driver)

fiery ice
#

it crashes

calm latch
#

Ironclad uses uACPI??

fiery ice
calm latch
#

You could

#

Like it's the same image, just with max phys addr from CPUID

#

My i686 image is still compiling

#

I mean you can also just replace devicesd with a 32 bit version

fiery ice
calm latch
#

If my compat mode hadn't bitrotted

#

Don't think it would change anuthing though

fiery ice
#

one new message now

#

devicesd just GPF'd after a bit

calm latch
#

pthread_exit is broken

#

because it couldn't shut down

fiery turtle
#

oh btw

calm latch
#

this is normal-ish given the circumstances trl

fiery turtle
#

@calm latch can u enable debug logs in uacpi