Nyaux

[surreal path]

wait

try this iso

[tawdry mirage]

yes hpet ```
[ 0.005544] ACPI: HPET 0x00000000C723E000 000038 (v01 HPQOEM 8707 01072009 HP 00000005)
[ 0.005598] ACPI: Reserving HPET table memory at [mem 0xc723e000-0xc723e037]
[ 0.035746] ACPI: HPET id: 0x10228201 base: 0xfed00000
[ 0.108900] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
[ 0.998988] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 0.998991] hpet0: 3 comparators, 32-bit 14.318180 MHz counter

[surreal path]

no 64 bit one tho

[tawdry mirage]

that seems to be a running theme on amd platforms

[surreal path]

try this iso tho

[tawdry mirage]

i have an athlon 64 x2 machine and it also has a 32-bit hpet

[surreal path]

if it founds a ecdt table and successfully installs ec handlers it will say

so i think it probs did find an ecdt table on ur laptop

just try it tho

WAIT

@tawdry mirage HOLD ON

[tawdry mirage]

?

i am at the bios boot menu

[surreal path]

try this isntead

flash it like rq

and try it

i had to move some functions aroun

but it should say now

[tawdry mirage]

no ecdt table, will init from namespace

then the hpet panic

[surreal path]

okay well uhhh i could disable the hpet

will i disable the hpet

i will do so

[tawdry mirage]

you could just impl 32 bit hpet support

[surreal path]

nahh

@tawdry mirage okay i disabled hpet in this iso

try

let me know anything that comes from ec

[tawdry mirage]

what are you using for sleeps etc?

[surreal path]

hpet

[tawdry mirage]

in this iso i mena

[surreal path]

i commented out all "sleeps"

[tawdry mirage]

mean

[surreal path]

in this iso

there is no sleep call at all

so uacpi will incorrectly report the amount of ops per second

which i dont care about

[tawdry mirage]

device does not have ec

lol

[surreal path]

damn

😔

[tawdry mirage]

thats wrong btw

[surreal path]

sad ur laptop doesnt have ec

wait what

how

[tawdry mirage]

its your code

[surreal path]

uhhhh

i scan for it

WAIT

hold on @tawdry mirage

forgot ONE line of code lmao

try now

this is why we test code btw

[tawdry mirage]

now it finds the ec

no queries happen though

[surreal path]

i forgot

another

fucking line of code

hold on

try now again

[tawdry mirage]

stuck now and doesnt print that it even found the ec

[surreal path]

wdym

what was the last log

[tawdry mirage]

uacpi: namespace initialization done

[surreal path]

that is bad

i scan for devices

and i install the ec handlers

then print device has ec

install ec handlers does this

is there something wrong with this while loop

i dont think so

wait

..

yea that should be fine

wtf

do u have an idea @tawdry mirage as to whats getting stuck?

[tawdry mirage]

no idea

[surreal path]

it shouldnt get stuck

[tawdry mirage]

you could compare it to the managarm code, that works on this laptop

[surreal path]

its quite similar to that

well the obos impl

let me double check everything tho

@tawdry mirage i have double checked

everything looks similar

are u SURE

the last log was uacpi: namespace init done

like

did it not print kmain

or init_acpi

or that it installed GPEs

[tawdry mirage]

nop

[surreal path]

damn

https://github.com/rayanmargham/NyauxKC/blob/master/kernel/src/acpi/ec.c

thats the code ig

idk what to do

chat

its prob stuck in this function

i dont know where tho

i will add more printcs

@tawdry mirage try this iso

tell me the last log it printed

inb4 it gets stuck evulating the integer

[surreal path]

what

what the fuck

huh???????????

maybe its because i forgot to return something

causing ub or smthin

@tawdry mirage

added more prints

and returned something

[surreal path]

i think its stuck installing the address space

uacpi_install_address_space_handler(uacpi_namespace_root(), UACPI_ADDRESS_SPACE_EMBEDDED_CONTROLLER, ecamlhandler,
                                        NULL);

@tawdry mirage arugments to this should look fine

thats all ecamlhandler does

so

why is it stuck installing an address space handler

that was not a proper iteratition decision from uacpi 😡

/j

@tawdry mirage try this, last one i promise

[surreal path]

so im guessing it was the break statement on UACPI_REGION_OP_ATTACH

but now its stuck evulating the gpe integer???

this very much sounds like UB

idk about you

[surreal path]

also why is ioapic 1s max gsi 1f

im printing integers

not hex

tf

[tawdry mirage]

lol

[surreal path]

lx is not hex

wait

nvm

it is

💀

MY BAD

that makes complete sence

[surreal path]

but getting stuck evulating the gpe idx is not

[tawdry mirage]

you could set the uacpi log level to trace

[surreal path]

okay

wait how do i do that with uacpi

theres no set log level with uacpi

wait nvm

@tawdry mirage try

[surreal path]

tf????

i think ur laptop is trolling me

he did not evulate the gpe

actually cringe

WAIT

no

nvm

@tawdry mirage its still stuck trying to install the address space handler

was looking at the logs wrong

[tawdry mirage]

are your mutexes or spinlocks broken

[surreal path]

no

they shouldnt be

WAIT

i forgot an unlock

somewhere

hold on

okay @tawdry mirage

try this

i forgot some unlock lines in 2 functions

[tawdry mirage]

still stuck in the same spot

[surreal path]

damn

😔

that is what my spinlocks look like btw

stole them from somewhere

[tawdry mirage]

i think ill go to bed now

[surreal path]

goodnight

[tawdry mirage]

gn

[surreal path]

thanks for testing btw

sweet dreams

[rigid fable]

i can

do

testings

[surreal path]

its fine

im kinda stuck rn

srry

[rigid fable]

ventoy on top 💯

[rigid fable]

why you need ec

like

what devices you can find with it

[surreal path]

its just cool

plus 4th hobby os to do it

anyways im going sleep now

we will debug why ec driver fails to install an address space handler tmrw

[rigid fable]

https://tenor.com/view/marvin-gif-1644493607771721553

[surreal path]

test this rq if u dont mind

flash to a usb and test on real hw

@plush hearth u awake

test this pls if u are

[plush hearth]

yep. It's only 3:43 pm for me

[surreal path]

tell me the last log

that comes out of the term

[plush hearth]

do I just dd it to a usb?

[surreal path]

yea

supports both uefi and bios

[plush hearth]

this won't brick my laptop?

[surreal path]

no it wont

[plush hearth]

it says all the CPUs are online

[surreal path]

can u screenshot

[plush hearth]

and device as an ec

[surreal path]

or

take a picture

please

[plush hearth]

I can try

there is a lot of glare

[surreal path]

that is weird, it hangs on qookies laptop but not urs???

[surreal path]

yea do so please

[rigid fable]

ok

[plush hearth]

my laptop screen is annoying

[surreal path]

does closing ur laptop lid and reopening it do anything

[rigid fable]

@surreal path why only 32 bit hpet

[surreal path]

this is weird

[rigid fable]

okay I'll test on my old laptop

[surreal path]

i only support that sorry

[surreal path]

why tf does it hang on @tawdry mirage 's laptop

[rigid fable]

it have 32 bit hpet

[surreal path]

[plush hearth]

no

[surreal path]

that is a bad sign

i smell ub

[plush hearth]

unplugging and replugging the charger does nothing

[rigid fable]

nyaux test laptop

[surreal path]

@plush hearth try this new iso

[rigid fable]

@surreal path

[surreal path]

u dont have ec lol

[plush hearth]

also, pressing the power button causes a panic

[surreal path]

triple fault or what?

[rigid fable]

support 64 bit hpet

[plush hearth]

I'll try the new iso

[plush hearth]

unhandled interrupt 0x21

[surreal path]

thats interrupt 33

it should be handled

tf

very weird

[rigid fable]

I have it too

[plush hearth]

new ISO yields the same result

[surreal path]

okay lets keep a list as to the issues we are currently having

1. on qookies laptop, the install address space function just hangs
2. on frostys and ducks machine, pressing the power button yields a panic even though the sci handler is installed

[surreal path]

this will be very difficult to debug

[plush hearth]

don't forget that nothing happens for lid or power cable changes

[surreal path]

yea

[thorny glen]

and then u get to be even more proud when u get it to work

and can put "highly skilled at debugging in difficult environments" on your resume and have it be true and not word salad

[plush hearth]

yep. It really doesn't help that QEMU doesn't support EC

[molten grotto]

@surreal path ```c
void kmain() {
while (true) {
__try {
nyaux_kmain();
}
__except (1) {
kprintf("nyaux null deref, restarting");
}
}
}

anyway hows nyaux, what are you going to do next

[edgy pilot]

what is that sorcery

[molten grotto]

SEH

[thorn bramble]

msvc seh

ew

[edgy pilot]

^

[molten grotto]

I think its pretty cool, I can just wrap my entire syscall handler in a try block to catch faults lol (and the unwind info is more sane than dwarf afaik)

[thorn bramble]

it requires runtime support tho

it's not cool at all

just an msvc standardized abomination

[molten grotto]

sure like any exceptions but I don't think its that bad

[thorn bramble]

shouldn't fault, ideally, at all

user access should be done through a special mechanism that catches it for you in a more lightweight way

and if your kernel code faults then just write better code or smth

[molten grotto]

how do you catch it without faulting lol

[thorn bramble]

yeah but you can write it in a more lightweight way than using seh in your kernel

[molten grotto]

its rare anyway

doesn't matter how long it takes

[thorn bramble]

even more or a reason to not do seh in your kernel :^)

for this one specific case

[molten grotto]

idk I want to at least try it for the fun of it lol

[thorn bramble]

like sorry, dont get me wrong - do whatever you want in your kernel, but i just simply think that adding seh support is a bit overkill :^)

especially since faults shouldn't happen anyway lol

that's just an indicator of bad code and you should fix it instead of slapping a band aid on it

[surreal path]

we are currently stuck on the embedded controller

driver hangs

when installing the address space

behavior is inconsisent depending on hw

[surreal path]

on streaks computer it just deadlocks here

@molten grotto are u awake

i need your help so bad

[surreal path]

serial shows nothing so it didnt fault

it just shows the last thing on the term

[molten grotto]

yes

[surreal path]

please help i beg

i have multiple ub bugs happening on real hw

1. freezes on scroll on streaks computer

2. gets stuck installing the address space on qookies

3. no ec events on frostys

[molten grotto]

if you push the code I can take a look

[surreal path]

yea itsp suhed

take a look

[molten grotto]

you didn't modify it in the last 13h?

[surreal path]

no?

well yea

i didnt

[molten grotto]

ah, Ill take a look at it then

you don't set ec_node to anything when getting the ec from the ecdt

there is a string path in the ecdt table that you can give to some uacpi function to find the node

[surreal path]

fair but even then

that shouldnt cause nyaux to die trying to scroll on streaks laptop

anyways u can pull again i added the change so it gets the ec node from the ec id from uacpi

[molten grotto]

you don't wait for the burst mode status bit to get set when enabling the burst mode

but yeah other than that idk

[surreal path]

fuck

qwinci im sad

[surreal path]

wait where do i do that

[molten grotto]

in ec_burst_time after getting the burst ack I think

at least that's where I do it in my kernel

[surreal path]

no?

lol

[molten grotto]

I said that you don't do it

[surreal path]

oh i have to wait

my bad

[molten grotto]

idk if its really necessary tho

but ig its good to do

[surreal path]

should i do it after getting the ack

[molten grotto]

yes

[surreal path]

ok i do it now

but

that wont solve anything sadly

😔

im going to actually cry

@flat nymph please test i broke both usbs somehow

[flat nymph]

I'll be home in 20 minutes

[surreal path]

okok

[flat nymph]

Or so

Do you want PCs with EC?

I have 4

[surreal path]

yea

[hollow goblet]

@surreal path go to local computer shop and test EC driver

actually no don't do it in a local shop

do it in a multinational megacorporation shop

don't harm local businesses

[flat nymph]

Also, school PCs?

Although better not, you can get expelled and it's not good when you're about to finish

[molten grotto]

I could also test nyaux on my work laptop

I think it has an ec too

[flat nymph]

(telling from personal experience)

[surreal path]

please do so

[surreal path]

wtf

i do install the interrupt tho

wtf

qwinci

does this not look like

[molten grotto]

that last oopsie happened when i pressed the power button

[surreal path]

i install the interrupt

at least events work on urs

[surreal path]

i do not know whats going on

at all

[molten grotto]

also the lack of pci might cause some issues

[surreal path]

wdym

[surreal path]

does uacpi hate me

i INSTALLED

the interrupt

REGISTERHANDLER

RAHHHH

[molten grotto]

you don't implement uacpi pci stuff right?

[surreal path]

no not atm no

[molten grotto]

yeah that can cause issues

[surreal path]

it shouldnt be causing the UB

thats going on rn

at all

[flat nymph]

It's not ub

[surreal path]

it probs is

because so much inconsisent behavior

on mutiple pieces of hardware

[flat nymph]

This is probably bad programming habits and assuming things which aren't true

[surreal path]

uhhh

not if its inconsisent behavior

[flat nymph]

Qemu clears ram for you

And the hardware state is more or less the same

[surreal path]

ik

[flat nymph]

When are you implementing 32 bit hpet?

This is a 2023 laptop

[surreal path]

i dont impl 32 bit hpet

check dmesg that laptop is probs not 64 bit

[flat nymph]

So you don't support AMD

[surreal path]

what

[surreal path]

ugh fine ill support 32 bit hpet

[flat nymph]

And no events

Because no PCI support probably

and power button crashes it

laptop number 3

And laptop 4 is not turning on

[surreal path]

try this

i support 32 bit hpets now

[flat nymph]

No image

[surreal path]

what

MY BAD

commented out flanterm

hold on

[flat nymph]

0% success rate so far

[thorn bramble]

why tf does it have a notch

LMAO

[surreal path]

NOW TRY

[thorn bramble]

i thought that was an apple thing

[surreal path]

i commented in flanterm

[flat nymph]

Apple is screen notch

[kind root]

💀

[thorn bramble]

he had flanterm init commented out

cut him some slack

this time it'll SURELY work

[flat nymph]

My laptop's not turning on 💀

[thorn bramble]

most stable ec driver

[surreal path]

what

[thorn bramble]

laptop bricked

gg

[surreal path]

ur not joking???

@flat nymph???????

[flat nymph]

No events though

From lid and whatnot

[surreal path]

device does not have ec

probs on the pci bus

[flat nymph]

It definitely has EC

[surreal path]

yea most likely on the pci bus

[flat nymph]

We've been debugging it with infy

[flat nymph]

Not on PCI bus, it has a normal EC

[surreal path]

great 4 bugs now

[flat nymph]

And power button connected to GPIO

Which is only supported by pmOS out of all hobby OSes 😎

[surreal path]

void ec_init()
{
    kprintf("ec(): initing from namespace\n");
    if (ec_inited)
    {
        return;
    }
    kprintf("ec(): finding device\n");
    uacpi_find_devices("PNP0C09", ec_match, NULL);
    if (ec_inited)
    {
        kprintf("installing handlers\n");
        install_ec_handlers();
        kprintf("ec(): device has ec!!\n");
        return;
    }
    else
    {
        kprintf("ec(): device does not have ec\n");
        return;
    }
}
void initecfromecdt()
{
    struct uacpi_table chat = {};
    uacpi_status stat = uacpi_table_find_by_signature("ECDT", &chat);
    if (stat != UACPI_STATUS_OK)
    {
        kprintf("ec(): no ecdt table found, will init from namespace\n");
        return;
    }
    struct acpi_ecdt* ok = (struct acpi_ecdt*)chat.virt_addr;
    ec_control_register = ok->ec_control;
    ec_data_register = ok->ec_data;
    ec_gpe_idx = ok->gpe_bit;
    uacpi_namespace_node_find(NULL, ok->ec_id, &ec_node);
    ec_inited = true;
    install_ec_handlers();
    kprintf("ec(): found ecdt table, installed and inited ec successfully\n");
    return;
}

this is what i do

like tf

[flat nymph]

Idk check what pmOS does

Because it works there

But it might be that AML freaks out because it can't find some PCI devices

[tawdry mirage]

i told you yesterday (or rather, today at 5 am) that amd platforms all have 32-bit hpet

for a long while now

[surreal path]

i support it now

[surreal path]

where is ur ec code

[flat nymph]

https://gitlab.com/mishakov/pmos/-/blob/main/devicesd/generic/ec.c?ref_type=heads

[thorn bramble]

u have a github mirror?

[surreal path]

we lit do the same shit

i wanna kms

@tawdry mirage can u check if it still hangs at installing address space handler, i support 32 bit hpets now so it should work without any hacks now

if ur free ofc

[thorn bramble]

@flat nymph does ur laptop have an ecdt?

[flat nymph]

No

[thorn bramble]

fair i figured

[flat nymph]

One of them does

[thorn bramble]

but id rather ask

oh?

but the yoga doesnt

[flat nymph]

But not that particular one

Yeah Lenovo doesn't

The one that does is not turning on

[surreal path]

this iso

[thorn bramble]

bro was returning iter_decision_break on error in ec_match 😭😭

[tawdry mirage]

which iso do i try then

[thorn bramble]

latest one prob

[surreal path]

this one

[thorn bramble]

if ur laptop has an ecdt then it probably doesn't matter

[surreal path]

interesting

[tawdry mirage]

also god bless this laptop

i think the ec sometimes gets confused due to partial init or whatever and after rebooting into linux some keys don't work

[surreal path]

try this iso

[tawdry mirage]

and the fix i've found to consistently fix this is to reboot into windows and then immediately into linux

[surreal path]

i print what ops it does now

[surreal path]

i think the first op was ec attach

[kind root]

Does that happen for managarm/pmos as well?

[tawdry mirage]

i've had it happen sometimes when testing managarm

but not consistently

it also doesn't consistently happen with nyaux

[surreal path]

okay

[kind root]

Interesting

[tawdry mirage]

the keys don't work in uefi already btw

[kind root]

Least brainrotted firmware

[tawdry mirage]

or rather, things that use the uefi input apis

[thorn bramble]

least insane ec

[tawdry mirage]

if it was some useless keys i wouldn't be that mad

[thorn bramble]

most functional laptop firmware

[tawdry mirage]

but it's space and right shift that stop working

among others

[surreal path]

okay try this

[thorn bramble]

is it just random keys???

[surreal path]

if it deadlocks

im gonna

kms

[thorn bramble]

how does it figure out which ones to fuck up

seems so arbitrary

[tawdry mirage]

idk but it's always consistent

[thorn bramble]

almost as if it was trying to stop you from using your computer

[kind root]

Your ec driver just sucks

It probably hangs in read

Obos had this as well

[surreal path]

why did obos hang

[thorn bramble]

i cant wait for my ec driver to hang randomly too

[kind root]

Skill issue

[surreal path]

like sir

[thorn bramble]

i need to find a guinea pig

someone who will test my kernel's ec driver

[kind root]

It will cause problems only if you do completely insane things

[kind root]

And will need a powercycle

[surreal path]

okay

[thorn bramble]

i really like poking random values into random registers and seeing what happens

[kind root]

Welcome to aml lmao

[thorn bramble]

isnt that how you make drivers for undocumented devices anyway

[surreal path]

added more prints

[kind root]

Yeah

[thorn bramble]

u gonna make an igpu driver for your new upcoming kernel?

:^)

8086:a780 🙏

[tawdry mirage]

refer to my last photo

[surreal path]

so it didnt print anything new?

so its stuck at ec_readreal

hmst

[kind root]

Yeah thats the plan

[kind root]

Every igpu hopefully

[thorn bramble]

i can be the guinea pig if u wanna poke random values into the raptor lake-s igpu

[kind root]

Lmao

[thorn bramble]

whats the worst that can happen

hopefully my monitors can handle invalid displayport parameters :^)

[surreal path]

@tawdry mirage added a billion prints

[molten grotto]

also re this I though about it a bit more and come to the same conclusion that its not good at least not wrapping an entire syscall handler call with it (its going to leak mutexes and memory and whatever else). I also though about just using an elf kernel with mabi=ms to get sane debug info (I don't really need seh in the kernel), though clang doesn't support that for some reason so I'd first have to implement it but it can't be that hard

[kind root]

Yeah

[thorn bramble]

"clang doesn't support" "can't be that hard" last famous words

[molten grotto]

at least the clang code base is saner than gcc lol

[thorn bramble]

i mean yeah i guess it is

void foo(x, y)
    int x;
    int y;
  {
    return x + y;
  }```
 goes crazy

[tawdry mirage]

?

gcc is written in c++

[surreal path]

did u test this yet

[tawdry mirage]

no

[surreal path]

okay

[molten grotto]

and sometimes there are also random misaligned lines because they expect people to use 8 wide tabs and replace every 8 spaces with a tab character

anyway this is unrelated to nyaux

[surreal path]

why does it suddenly run now

wtf

i just added more prints

what ze actual fuck

[tawdry mirage]

no queries happen though

nothing if i close/open lid, un/plug the charger, press the brightness up/down keys

[surreal path]

i see

even weirder

[molten grotto]

I don't think I got queries on the laptop that I tried either

I tried to close/open the lid and nothing came up

[surreal path]

try this

i removed most prints

if it gets stuck here

we have UB or smthing

if it doesnt

idfk

what happened

[tawdry mirage]

last image i try for now

[surreal path]

okay

[tawdry mirage]

stuck after the attach event

[surreal path]

yea its UB

it has to be UB

adding prints shouldnt change its behavior

[finite summit]

or it could be timing related in another way

[surreal path]

timers is disabled until way later

[finite summit]

timing related does not mean timers

[surreal path]

wdym

@finite summit also how

me and ur code is like very similar

i took reference from ur code so like tf

[finite summit]

ur kernel is cursed

is the answer

[surreal path]

very helpful lol

[finite summit]

check places where I raise IRQL (mask interrupts in your terms) and make sure you do the same there

ig

[surreal path]

oh u mean here

right

[finite summit]

yes

[surreal path]

okay ill disable interrupts here

@finite summit added them but i dont think it will make an effect

at all

[finite summit]

kk

[unkempt relic]

upcoming kernel?

[kind root]

If I were to start it

[flat nymph]

pmOS doesn't mask interrupts

[thorn bramble]

PLEASEEE do

if u do i won't even work on my own

i will contribute to urs

[kind root]

why are u so confident it wont be a pile of crap lol

[surreal path]

anyone have any ideas

as to what to do

[finite summit]

because you're infy

[surreal path]

how to even debug this

[thorn bramble]

it's gonna be ur kernel

i mean

uacpi ain't shit

[thorn bramble]

also this is called being an early investor™️

/s

[kind root]

Lmfao

[thorn bramble]

half joke half not

but i absolutely can not work on a project on my own

and ur goals arent exactly to have a good kernel, rather ur interested in driver dev

so that could be fun

[kind root]

Yeah I hate algorithm related stuff like vmm and allocators and schedulers

Im just bad at those

[thorn bramble]

same but like i try sometimes 😭

[kind root]

You're doing pretty well id say

[surreal path]

:(

[elder shoal]

Hey I'm bad at these and I can still make a shit os

[flat nymph]

microkernels supposedly make it easy to write drivers

[thorn bramble]

uKernel time

(u stands for micro)

[surreal path]

@hexed mango had the deal of sending ipi to cpu 0 to figure out whats wrong

WAIT

@kind root i havent impled schedule work

💀

hold on

i need to make a thread that runs the uacpi init

[finite summit]

nyauxmaster

guess who beat your score

[surreal path]

you did

ill try to optizmize my slab later ig

[finite summit]

yes!!

[kind root]

u havent even impled pci

[surreal path]

im going to impl scheduler work

first

ugh fine ill impl pci

[thorn bramble]

is queueing a dpc for the work item a valid implementation?

or does it need to run at a certain point idk

[finite summit]

yes

[thorn bramble]

no interrupts or some shit

ah okay

good to know

[surreal path]

what should i call my pci source file

and wheres the spec for pci

[finite summit]

it's paid

go to osdev wiki

[finite summit]

you just need to have a way to wait until all scheduled work finishes

because a kernel api does that

[thorn bramble]

i can just have a linked list of dpcs queued by uacpi kernel api

[finite summit]

yes

that's what I do

[thorn bramble]

actually that's kinda bad

because there is no way to sleep on a list

i mean unless you also add an event

[finite summit]

while (nWork > 0);

[thorn bramble]

lol

also > * 1. All in-flight interrupts installed via uacpi_kernel_install_interrupt_handler

[kind root]

Are your dpcs allowed to sleep and block

If yes then yes

[thorn bramble]

i mean yeah, they are also allowed to be preempted

so idk if that's gonna be a problem

[kind root]

Yeah like no one does that

Although its only important if u do uninstalls

To prevent race conditions

[hexed mango]

there's a bit more to it than that, but ya p much

[thorny glen]

nuh uh

[tawdry mirage]

page faults that fault file contents in or whatever are fine imo

[thorny glen]

theres also no other good way to access userspace

than to access it directly and allow page faults to happen and just catch bad ones, either with something like SEH or with special handling by something like copy_to_user or whatever

the latter is preferred now because of SMAP or whatever its called

bc it provides a central choke point to disable it, do the access, re-enable it

[tawdry mirage]

yeah, that's what we do in managarm

[thorny glen]

toaru is an example of a kernel that tries to do it differently by checking for validity before doing the access but its littered with toctou because thats incorrect without also taking some big address space lock that prevents mappings from changing

which it doesnt do

[thorn bramble]

well thats what i meant, something like copy_from/to_user

[tawdry mirage]

the managarm impl is basically ```
handle_pf:
...
if ip >= copy_from_user_start && ip <= copy_from_user_end && is_read_fault
ip = copy_from_user_fail
return
...

[thorn bramble]

of course, but the unexpected page faults shouldn't happen obviously

[thorny glen]

i felt like you implied it shouldnt be taking any page faults and should be explicitly checking for validity

[thorn bramble]

no sorry for wording it badly lol

[tawdry mirage]

ofc a bit more abstracted (copy_from_user sets a cpu-local pointer to an info struct that has the start/end/fail pointers in it)

[thorny glen]

is it sufficient for it to be per-cpu rather than per-thread?

even if your kernel isnt preemptible, what if you take a page fault and reschedule and the thread comes back on another cpu

[elder shoal]

it should be per thread yeah

[tawdry mirage]

hmm that's a good point

well currently it's not a problem because we don't migrate threads between cores, but the fault could lead to a different process being scheduled (to fault in the page via the fs server)

and that also does the user copy

i could also just be missing something obvious

cc @quick quiver see above

[tawdry mirage]

actually, the pf doesn't even need to block the current thread

since the kernel is preemptible

[thorn bramble]

least inconsistent nyaux code

[kind root]

lmao

[surreal path]

nyaux has pci config support now

@tawdry mirage i have added pci config support to nyaux, if u arent busy please test it, ill only test it once and thats it

[tawdry mirage]

i don't think i saw any errors about it aborting execution of aml due to lack of pci io

[surreal path]

yes because

i added pci io now

if ur free please test

[tawdry mirage]

i mean when testing earlier

[surreal path]

weird, ud have to report that to infy

ngl

[kind root]

report what

[plush hearth]

why is it that slow?

[flat nymph]

My kernel does it, but I though it's very slow to do

[kind root]

the fact that firmware doesnt access pci?

im sorry

[surreal path]

tcg

[surreal path]

i have pci now

[tawdry mirage]

@kind root what's the asl keyword for a pci opregion

[surreal path]

but qookie tested an older version without pci

[tawdry mirage]

PciConfig?

[kind root]

PCI_Config

[kind root]

re read what i said

[surreal path]

what

why

is that something i need to impl now

how do i impl that

[kind root]

bruh

i just said that if it didnt abort before it didnt need pci during the namespace laod

so u adding it changed absolutely nothing

its not a bug nor a problem

[surreal path]

SORRY THIS IS THE ISO

MY BAD

[tawdry mirage]

yeah on my laptop only the dsdt has pci config opregions, and there's only two of them, and only one field ends up being used in total

and it only seems to be used for power management?

or not even actually

one of them is accessed from _DSM only

[kind root]

yeah i guess your firmware just doesnt need pci in general that much

maybe it talks over smbus instead

[tawdry mirage]

or at all, i don't see any references to any of the fields except for one from _DSM of some device

in the dsdt or ssdts

[kind root]

last time i checked ive seen handrolled smbus code in an amd aml dump

[tawdry mirage]

qookie@selenium /tmp/x λ rg -i Pci_Config -A7
dsdt.dsl
17464:            OperationRegion (PCFG, PCI_Config, Zero, 0x80)
17465-            Field (PCFG, AnyAcc, NoLock, Preserve)
17466-            {
17467-                DVID,   32, 
17468-                PCMS,   32, 
17469-                Offset (0x45), 
17470-                LPSW,   1
17471-            }
--
18073:            OperationRegion (RPRT, PCI_Config, Zero, 0x30)
18074-            Field (RPRT, AnyAcc, NoLock, Preserve)
18075-            {
18076-                VDID,   32, 
18077-                Offset (0x2C), 
18078-                SVID,   32
18079-            }
18080-
qookie@selenium /tmp/x λ rg "(DVID|PCMS|LPSW|VDID|SVID)"
dsdt.dsl
17467:                DVID,   32, 
17468:                PCMS,   32, 
17470:                LPSW,   1
18076:                VDID,   32, 
18078:                SVID,   32
18083:                If (WIST (VDID))
qookie@selenium /tmp/x λ rg PCFG
dsdt.dsl
17464:            OperationRegion (PCFG, PCI_Config, Zero, 0x80)
17465:            Field (PCFG, AnyAcc, NoLock, Preserve)
qookie@selenium /tmp/x λ rg RPRT
dsdt.dsl
18073:            OperationRegion (RPRT, PCI_Config, Zero, 0x30)
18074:            Field (RPRT, AnyAcc, NoLock, Preserve)
qookie@selenium /tmp/x λ 

[kind root]

interesting yeah

what does it read e.g. in _PRT?

or _CRS for pci link devices

[thorn bramble]

lmao

[tawdry mirage]

If (PICM) // PIC mode ig?
{
    Return (ARxx)
}

Return (PDxx)

for all _PRTs

[plush hearth]

it gets to the hello world from scheduled thread, but still no EC events

[kind root]

so just hardcoded lmao

yeah PICM is an integer that represents the pic mode

[plush hearth]

there is a bunch of firmware notify requests with no listeners though. and there is an error during _REG exectution for EmbeddedControl due to AML referencing an undefined object

[tawdry mirage]

_CRS is also all hardcoded for link devices ```
Method (CRS, 0, NotSerialized) // CRS: Current Resource Settings
{
CreateWordField (BUFA, One, IRQX)
IRQX = (One << PIRA) /* _SB.PIRA /
Return (BUFA) / _SB.BUFA */
}

[kind root]

what is PIRA?

[tawdry mirage]

actually

[surreal path]

yea weird

[tawdry mirage]

        OperationRegion (PIRQ, SystemIO, 0x0C00, 0x02)
        Field (PIRQ, ByteAcc, NoLock, Preserve)
        {
            PIDX,   8, 
            PDAT,   8
        }

        IndexField (PIDX, PDAT, ByteAcc, NoLock, Preserve)
        {
            PIRA,   8, 
            PIRB,   8, 
            PIRC,   8, 
            PIRD,   8, 
            PIRE,   8, 
            PIRF,   8, 
            PIRG,   8, 
            PIRH,   8, 

[kind root]

huh

is 0x0C00 some known port

or is this proprietary stuff

[tawdry mirage]

according to /proc/ioports ```
0c00-0c01 : pnp 00:03

[plush hearth]

oh and pressing the power button yields the same unhandled interrupt 0x21 at CS:RIP of 0x28:0xffffffff8002ec91

[kind root]

hmm i dont even know where that pnp thing comes from

[tawdry mirage]

no idea what pnp 00:03 means

[surreal path]

at least we have 2 types of behavior

[kind root]

did it perhaps just grab some _CRS output and built ioports from that?

[tawdry mirage]

i guess

[plush hearth]

also, I recommend renaming the CPUs to more normal numbers. Currently it is 0, 2, 4, and 6

[kind root]

or maybe PNP0003 APIC

[surreal path]

its just the lapic id

[kind root]

is that a thing in your blob?

[tawdry mirage]

ports 0x0C00-0x0C01 are in _CRS of ```
Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard Resources */) // _HID: Hardware ID

[kind root]

makes sense that its there, but wtf is 00:03

[tawdry mirage]

i guess 00:03 refers to some linux numbering?

[kind root]

perhaps

im just looking at other dumps that i have, some come up with the IRQ number by reading random memory addresses

Name (IBAS, 0xFED08000)

whatever that is

[finite summit]

lmao

[kind root]

i know qemu just reads from the pci config space to get those

[surreal path]

try this iso

[plush hearth]

exact same outcome

[surreal path]

unhandled interrupt?

okay

[plush hearth]

yep

[surreal path]

i see

[plush hearth]

different RIP obviously

but same function of kentry()

[surreal path]

idk how to fix this

[plush hearth]

also, why this many partitions?

[surreal path]

uhh what?

im just using xorriso

mints template makefile

[plush hearth]

you can probably strip down this makefile

[surreal path]

no thanks

[plush hearth]

you don't have aarch64, riscv64 or loongarch64

[surreal path]

yet.

™️

[plush hearth]

might just be the BIOS stuff

[surreal path]

dont ask me

ask mint about it

[tawdry mirage]

i want to see nyaux on loongarch

[surreal path]

it will soon dw

™️

just need to figure out why

some hardware freezes when reading ec
some hardware goes fine but no query events happen

[plush hearth]

you probably need to make it stable on x86_64 first...

[surreal path]

exactly

[plush hearth]

if you have another test for me to run on my laptop, ping me

[surreal path]

kk

[surreal path]

@kind root could it be timing related issues

like omar said

[kind root]

nah

if it hangs its not timing related

[surreal path]

but if i had prints

it works fine

around ec_read

[kind root]

just ub

[surreal path]

[kind root]

theres nothing in the ec subject to timing bugs

u always poll until a bit is set

[surreal path]

so ub

fun

!!!

[kind root]

i mean

quadriple check that your code matches obos or pmos

[surreal path]

it does

i already quadriple checked

[finite summit]

*quadruple

[surreal path]

read it yourself lol

[surreal path]

😡

[finite summit]

https://tenor.com/view/minor-spelling-mistake-gif-21179057

[kind root]

nyaux code is too phd for me

[surreal path]

no actually try

https://github.com/rayanmargham/NyauxKC/blob/master/kernel/src/acpi/ec.c

this code isnt THAT bad

i promise

[kind root]

i did ec a very long time ago so i dont remmeber anything

[finite summit]

only good nyaux code is nyaux code that has inspiration from other kernels

[kind root]

oberrow did it very recently so he knows better

[finite summit]

I looked at mangarm and was like "shi cool I should do that too"

then when I had bugs I actually tried understanding it

[kind root]

managarm looked at ultraos which looked at lai

and the spec i guess

[surreal path]

@finite summit read it

[finite summit]

I am

[surreal path]

kk

[finite summit]

and this code is like the exact same as mine but without underscores

in the function names

and with fnuy function names

[surreal path]

i didnt yoink it tho

i did actually write the code by hand

well the stuff that was yoinked

it commited

and its license is there

everything else i wrote

[finite summit]

I think the stuff you didn't yoink have the bugs

[surreal path]

💀

[surreal path]

i will yoink the entire obos ec driver

and try it

if it fails

we have a bug somewhere else

else

its my skill issues

[finite summit]

sure lol

it's using like 90% uacpi

functions

the rest are obos' functions

[tawdry mirage]

hmm ```
OperationRegion (FPIC, SystemIO, 0x0C00, 0x02)
Field (FPIC, AnyAcc, NoLock, Preserve)
{
FPII, 8,
FPID, 8
}

this one is used for interrupts of COM{1,2,3,4}

[kind root]

lol

like same offsets?

i guess it just shares those irq numbers

[tawdry mirage]

no different offsets

it skips a bunch of bytes in the indexfield that uses this copy

[surreal path]

@finite summit try this now

[kind root]

wait

the first example was also accessed as selector + data

[tawdry mirage]

i mean the indexfield has different offsets

[kind root]

yeah yeah makes sense

[tawdry mirage]

not the field with the data + index regs

[kind root]

what i mean is

this is like ioapic

FPII is FPI Index and FPID is FPI Data

so u write the index and read from data

what FPI stands for im not sure

FP Interrupt probably

[tawdry mirage]

FPIC

interrupt controller?

[kind root]

ah yeah

what is F

[finite summit]

@surreal path it doesn't hang

but I don't get events

[surreal path]

wtf

[plush hearth]

that is a start

[surreal path]

show logs

[kind root]

i guess your chipset has a device at 0xC00 which decides where irqs are routed

[tawdry mirage]

i can't find anything online about these ports except for people sharing dmesg dumps that say 0xc00-0xc01 is reserved

[kind root]

u can query it by writing the selector value at 0xc00 and reading back at 0xc01

[surreal path]

@finite summit

[finite summit]

it boots normally

says it has an EC

but I never get events

[surreal path]

wtfff

[kind root]

i wonder if the data field is writable as well

can u route irqs to random indices

[tawdry mirage]

[kind root]

is there a _SRS for e.g. COM?

[tawdry mirage]

no but there is one for pci link devices

[kind root]

does it actually write at 0xc01?

[tawdry mirage]

via a helper method yeah

[kind root]

lesgo

[surreal path]

@finite summit try this i replaced a few functions with obos ones, im gonna manually replace each function til we find the function that caused it

[tawdry mirage]

        IndexField (PIDX, PDAT, ByteAcc, NoLock, Preserve)
        {
            PIRA,   8, 
            PIRB,   8, 
            PIRC,   8, 
            PIRD,   8, 
...
        Method (INTD, 1, NotSerialized)
        {
            PIRD = Arg0
            SATA = Arg0
        }
...
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                CreateWordField (BUFA, One, IRQX)
                IRQX = (One << PIRD) /* \_SB_.PIRD */
                Return (BUFA) /* \_SB_.BUFA */
            }

            Method (_SRS, 1, NotSerialized)  // _SRS: Set Resource Settings
            {
                CreateWordField (Arg0, One, IRA)
                FindSetRightBit (IRA, Local0)
                Local0--
                INTD (Local0)
            }

[kind root]

lol nice

write a managarm driver to redirect irqs to random numbers

[tawdry mirage]

lol

[finite summit]

@surreal path it don't work

[surreal path]

hangs?

[finite summit]

nope

no events

[surreal path]

but it didnt hang right

it booted normal?

[finite summit]

yes

[surreal path]

IT WAS EC_WAIT_FOR_BIT????

[finite summit]

it booted normally

[kind root]

do u have logging in your ec gpe callback?

is it even called

[surreal path]

WTF

[plush hearth]

same on my laptop @surreal path

[surreal path]

his one

vs mine

[kind root]

did u think it was do while as opposed to while for no reason at all

[surreal path]

no i thought it was no reason?

[kind root]

bruh

[silver yarrow]

I mean it executes once without checking the condition

[kind root]

exactly

[surreal path]

OHHHHHHHHHHH

[kind root]

thats like entirely different behavior

[surreal path]

[silver yarrow]

do once, and then keep doing as long as the condition is true

[surreal path]

okay solved now

[kind root]

nyaux ec corruption any%

[surreal path]

but wehy no events

[silver yarrow]

lmao

[kind root]

do u have logging in your gpe callbacks??

[plush hearth]

it makes sense why this doesn't work

val is just 0

[surreal path]

hold on

yes

@kind root

[finite summit]

disabled interrupts

but never reenables them

[surreal path]

oh they get reenabled

nvm they dont

still not the issue tho??

[plush hearth]

flags would just get restored on interrupt exit wouldn't it?

[finite summit]

ye

[surreal path]

@kind root

[kind root]

static bool ec_querytime(uint8_t* idx)
{
    uint8_t status = ec_read(&ec_control_register);
    if (~status & EC_SCI_EVT)
    {
        return false;
    }
    bool ack = ec_burst_time();
    ec_write(&ec_control_register, QR_EC);
    *idx = ec_read(&ec_data_register);
    ec_burst_nomoretime(ack);
    return (bool)*idx;
}

least convoluted code

[surreal path]

i need them impl'd right?

[kind root]

so u copy paste without even thinking that your thing is not implemented

how do u expect to get events

[surreal path]

i did not copy paste wtf

[finite summit]

if you didn't

[kind root]

why did u call this function

[finite summit]

then you would've known that that function is unimplemented

in your kernel api

[surreal path]

i forgot to check if it was impld

my bad

forgot to check if it was impld

💀

but wallah

i did not copy paste

[kind root]

u dont have to call it even, u can run the query right there, its just bad to do in an irq context

[finite summit]

no need to swear by Allah

[surreal path]

just in case u dont believe me

[kind root]

like

[surreal path]

so i dont even need to call uacpi schedule work?

[kind root]

it doesnt matter if u press ctrl+c ctrl+v

[surreal path]

i did not tho

[kind root]

or just type it out manually by lookin at the other screen

if u dont bother trying to understand what it does

[surreal path]

didnt do that either

i did bother understanding it

then why didnt i not ask questions about the ec