#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages · Page 23 of 1
then your cpu doesn't support the same features as mine
How
it's compiled with -march=native -mtune=native and a hardcoded xcr0 value after all
i mean maybe if u enable avx512 or some shit
Maybe u just dont do cpu host
i do
Also wsl2 disables some stuff
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves avx_vnni vnmi umip waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize flush_l1d arch_capabilities
it does avx2
sse4_2
yeah
xcr0 state enabled: x87, sse, avx, pkru
idk something my generic xsave code detected my cpu supports
lmao
hmmm what more can i stub out
Can u boot into Linux and run under native kvm?
Its like stripping car parts lmaoo
i think i've stubbed out everything i can that still gets called during uacpi init
now time to try the uacpi_reset trick
Just reset in a loop until the score is satisfactory 
that definitely did something but it's supposed to warm up 10 times before doing the final init
@left orbit can you try this one?
Why is there only 2 runs
thats what im trying to figure out
ah its both a uacpi bug and a proxima bug
Whats the bug?
linux or prxima?

This is avx in kernel
or do you want me to wait for a new one?
uacpi bug: uacpi_state_reset doesn't uninstall the sci interrupt handler (i set a breakpoint in uacpi_kernel_uninstall_interrupt_handler and it never got triggered)
proxima bug: pic_install_vector only works the first time it's called
or well
alloc_irq_vectors to be exact
Ill investigate tmrw
yeah now its just this (running in debug mode + tcg that's why the numbers are low)
Still hangs?
see the last message
yeah i'm adding a manual uninstall in the warmup code
it is
Nice
lmao thanks for reassuring
Nice
Dont boot this bare metal 💀
record!!
oh no absolutely not
13M with LTO + O3 + AVX2 + SSO
this is incredibly hacky
Lmao
no 1, whats a interrupt model, do i also need to run uacpI_set_interrupt_model
no 2
i never ran finalize gpe init
do i nee dto run that
interrupt model tells aml what irq controller youre using
legacy, ioapic, etc
oh okay
Why not
i dont know if its necessary but i do it
will i run finalize gpe init
It is, it changes the _PRT output
Its needed to enable aml event handlers
i will run it
Monkuous laptop has them, but its an old mechanism
They're also needed for suspend etc
can i see ur imports
Oh that was no sso...
this is all that + SSO
?
provided by "uacpi/event.h"
thanks
Bro can't git grep
there we go
bare metal proxima
bro doesnt know im lazy
bro doesnt know im in his walls
Solid
bare metal uacpi comparisons are a bit bogus due to complicated aml
but yeah solid
you got it wrong, infy is in YOUR walls
i wonder what it's like on my dev system

12 blobs and 30k ops
i wanna run the final image u sent.
is that the mutex stub + half-leaking allocator + AVX2 in kernel ISO or is it the normal one
the one that reinitializes uacpi 10 times 
yeah not really comparable
i actually added something that i think will make nyaux faster tho
hold on lemme pull out ze iso
this will beat proxima
if im wrong hang me to the floorboards
Inb4 100/s
@fiery turtle do you thinnk i should rip out the 10+ inits before testing this on bare metal or do i just go for it
rip out the 10+ inits
but the question is, what happens after the reboot
why'd u guys tell me not to test it 😭
what about writing to proprietary bios registers that happen to have a checksum, and the system doesn't boot unless the checksum is what it is expects
If its a pc I wouldnt worry tooooo much
most laptops' blobs are delusion right?
I mean u can lol
nah i ain't rebooting now
Its just precautions
too lazy
Laptops have more controllers that do complex power management
bench nyaux or begone ur c-c-c-car!
when will I be able to run nyaux in my car
soon ™️
I'll bench nyaux once I've tested all 3 variants of proxima bare metal

lets goooo
monkuous W
my new astral lock is almost done.... soon:tm;
Would be funny if it just has sleep calls in there
finishing release and will just add a quick lock try later
Which is possible
Lets goo
release is super annoying
cool i can't even check how fast it went
no new nyaux version has properierty technology no one has ever thought about before

serial works
uacpi: successfully loaded 1 AML blob, 1705 ops in 101ms (avg 16838/s)
how the fufck do u manage that
hax


honestly its impressive
How many orders of magnitude is that from proximas score
about 8
Not bad
!!!!
nyaux supremacy
frfr!!!!
Indeed
normal (iso straight from GitHub actions): 10097 ops, 4,737,793/s
crazy (everything except the 10 warmup inits): 6,373,181/s
crazy² (everything): 6,313,331/s
Bare metal?
infy can you update me score
yes
Damn
aml fears this man
I wonder if executing it this fast can reveal bugs with missing waits etc
what does proxima even use uacpi for
flexing rights?
wtf how, even when running with a completely unoptimized profiler that records every single function call i got 60k/s
future proofing
and right now flexing rights
either that or runtime allocator tests :^)
uh I use it for power management, allocator tests, and device discovery
It used to be 120/s
🤯
🤯

trolled
You'll get em next time
on my cpu with kvm: uacpi: successfully loaded 1 AML blob, 1705 ops in 73ms (avg 23342/s)
thats nyaux btw
Thanks for clarifying 
test obos 🥺

Update your pinned comment
369756/s
On real hw
wtf literally how ,,,
i wonder if there is a way to profile nyaux
obos faster than astral before I got my shit together
and it crashes loading /init right?
to see where its spending most of its time being so slow
its just
omg init on / this is just like the hit operating system astral
pinned message
oohhh
omg!!!!11!!!!11!!!1
im gonna throw the profiler he has in lib
nevermind i used an older downloaded iso instead of obos(1).iso, it's actually 216154/s
no this is consistent
bru
Cope
i'll try it on bare metal
Inb4 blows up
id sure hope not
What did u do there
allocator changes
but really if 11 uacpi inits don't brick my machine what will
True
triple fault before any output was visible, close enough
Is this also amd?
Obos doesnt like amd computers
yeah idk why
Haswell gang
I genuniely have no idea what's so special about amd that it triples before even getting to gdt init
yo he good
Arch_KernelEntryBootstrap:
cmp rsi, 0x554c5442
je .ok ; should triple fault on failure
xor rax,rax
jmp rax ; All hope is lost.
.ok:
push rdi
push rsi
; Get a hardware-generated random value.
; If both methods are unsupported, it will fallback to using the default value used.
.rdrand:
mov eax, 1
xor ecx,ecx
cpuid
bt ecx, 30
jnc .rdseed
rdrand rax
jnc .rdrand
jmp .move
.rdseed:
mov eax, 7
xor ecx,ecx
cpuid
bt ebx, 18
jnc .done
rdseed rax
jnc .rdseed```
wha
it does some cpuid
then rdseed/rdrand for teh stack check guard
then disables the pic
Is it possible the framebuffer is too high and u try to access it
Yes
on said laptop it just hangs until eventually getting to the "insert system disk in drive" bios prompt
im beginning to think i fucked up the usb
yea i do not know what its complaining
well idk if that's my fault or not
does your compiler support -finstrument-functions?
let me try and add the flag hold on
try uefi ig
💀
it's empty in the iso as well
even with the flag @gentle peak
wtf
crazy that my main pc triple faults when there's no efi boot image available
one of your headers is fucked ig
Least broken uefi implementation
idk
no not rlly? i made a seperate file called profiler.h
and i only imported this
nothing else
those last 2 things are supposed to be in your task_t struct or equivalent
but idk what could be causing the syntax error
oh im not running this in the scheduler
before kentry
then they can be static vars in prof.c itself but they shouldn't be global and outside the header guard
still
i dont think clang likes any of this
even my language server is not happy
i use clang myself
its just saying its not allowing the function defination here
@north holly now it's stuck on Using AGING PRA
bruh
vmm hang
it's after the vmm actually
I'm gonna send an iso with more logs wait
@dusky glade apparently there's a } missing at the end of prof_stop. oops
even doing that its still not happy
nvm
and missing ) at the cursor here
i really should've implemented prof_start/prof_stop in my ide instead of in the github gist editor
since you're using global frames/cur_frame just remove the current_task-> parts
okay
they're supposed to be task-local since they represent the call stack
like this?
yeah
@north holly
don't forget the pitfalls listed here https://gist.github.com/monkuous/5752282d03995080e99671ecb9969b3f?permalink_comment_id=5364478#gistcomment-5364478
uhhh oop
that's what happens when you put them in the header instead of prof.c
nvm ur right
and i have that in the form of #ifndef+#define+#endif
addr2line time
can you make sure that the pci device I'm trying to initialize isn't a bridge or smth similar
through lspci
before prof_start and after prof_stop the only variable accessed should be prof_active which is a static var so
starting in kentry
very beginning
it is static
0c:03:30 doesn't exist
oh
that's USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)
can you show me what resources it has?
so why is this happening
nyaux works fine on real hw even and the scheduler is like really simple so
is it something with ze profiler idk
also nothing came out of debugcon

oh wait need to call prof show
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) (prog-if 30 [XHCI])
Subsystem: Toshiba Corporation Device 0001
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at e4620000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: xhci_hcd
interesting
the first thing it does
is discovering BARs
so that's probably where it hagns
it's bar0 if i'm reading lspci -vv correctly
since there should be more logs around the bars of that device
@gentle peak this is the results of the nyaux profile before it page faults dying in the scheduler, uhhhh the first function is acpi.c:line 9???
then it hangs reading bar0 
i made a python script to format this nicely but i accidentally deleted it lmao
anyway that's sorted by ns/call
bru
why is uacpi taking so much ns
acpi.c line 9??
bro
#!/usr/bin/env python3
import os
import re
import subprocess
with open('dump.txt', 'r') as f:
text = f.read()
def translate(matchobj):
addr = matchobj.group(0)
out = subprocess.check_output(['addr2line', '-f', '-e', 'hydrogen/kernel/hydrogen', addr], stderr=subprocess.DEVNULL).decode().strip().split('\n')
func = out[0]
path = out[1].split(':')[0]
file = os.path.basename(path)
line = out[1].split(':')[1]
return f'{func} ({file}:{line} {addr})'
text = re.sub(r'(0x[0-9a-f]*)', translate, text)
print(text)
it's the call including all subcalls
ohhh
@dusky glade this will take the dump at dump.txt, addr2line everything using hydrogen/kernel/hydrogen, and print it to stdout
yea ik
alright just making sure you didn't miss it
more readable
here's some alternative impls for pred in prof.c btw ```c
attribute((no_instrument_function)) static bool pred(record_t *a, record_t *b) {
return a->total < b->total; // total time, high to low
}
attribute((no_instrument_function)) static bool pred(record_t *a, record_t *b) {
return a->calls < b->calls; // number of calls, high to low
}```
the time unit there is tsc ticks
you may want to add -cpu tsc-frequency=1000000000 to turn it into nanoseconds
kinda slow too
init hpet is SUPER slow lol
anyways we know that nyaux isnt a complete dumpster fire
its just
slab allocator is REALLY ass
like
REALLY
REALLY REALLY
nvm it seems vmm is slower
well i was kinda expecting it to be my allocators, not that i have a reason why it would be
but
it prob cause my code is ass or smt
idfk
i personally find sorting by total time spent in function more useful, because it also indicates how necessary it is to optimize a given function
this shouldnt be THAT slow tho
can you try this
void* slab_alloc(cache* mod)
{
if (mod->slabs == NULL || mod->size == 0)
{
return NULL;
}
slab* cur = (slab*)mod->slabs;
assert(cur);
while (true)
{
if (cur->freelist == NULL)
{
if (cur->next != NULL)
{
cur = (slab*)cur->next;
continue;
}
break;
}
assert(cur != NULL);
void* guy = cur->freelist;
cur->freelist = ((pnode*)cur->freelist)->next;
memset(guy, 0, mod->size);
return guy;
};
assert(cur);
cur->next = (struct slab*)init_slab(mod->size);
cur = (slab*)cur->next;
assert(cur);
void* guy = cur->freelist;
cur->freelist = ((pnode*)cur->freelist)->next;
memset(guy, 0, mod->size);
return guy;
}
like
its really just this code
while(true)
simple != fast
okay, then how would this be faster
that works
wut
acpi init benchmark scrolled away though
it got to the panic while trying to load /init
all I did was add more logs 
I'll disable the extra logs
and send you an iso
like is there some way to optimize this?
bet it's gonna hang at pci init again
only one way to find out
maybe it was just a one-time thing, sometimes obos randomly hangs in stuff where it usually doesn't
which is usually solved by a reboot
possibly
you should add in all the previous messages except replace \n with \r
stays on a single line while still doing all the printing
before I do that I want to test something
maybe I get an irq in the middle of the bar being in a weird state, causing a hang
i doubt that'd be this consistent
i got slab alloc to be a tiny bit faster by removing not needed if statement
statements
151 instead of 171
now
i can't really tell you how fast or slow this is most likely going to be just based on the code
what you really have to think about is what the common path is and how much work it's doing on that path
worked, but again, uacpi benchmark scrolled away
it seems the -finstrument flag is causing nyaux to die
all -finstrument-functions does is insert a function call at the start of each function and another at the end
yeah the only changes I added there was masking irqs while getting the bar size
nyaux running on kvm
weird that that's a consistent issue
and the logs never happened, as you could see
maybe it's because of an LAPIC timer IRQ
or hpet irq
which happen pretty consistently in my kernel
nvm it made no difference
even more interesting that it works on AMD in KVM
yeah
because that functions almost exactly the same as AMD bare metal
the only thing I could think of doing is digging through the AMD SDM
for instructions behaving differently
removed some not needed memset calls
removed even more not needed memset calls
refactored it a bit, this does exactly the same but is much cleaner code imo and easier to analyze and reason about and thus easier to optimize ```c
void *slab_alloc(cache *mod) {
if (mod->slabs == NULL || mod->size == 0) return NULL;
slab *cur = (slab *)mod->slabs;
assert(cur != NULL);
while (cur->freelist == NULL) {
if (cur->next == NULL) {
cur->next = (struct slab *)init_slab(mod->size);
}
cur = (slab *)cur->next;
assert(cur != NULL);
}
void *ptr = cur->freelist;
cur->freelist = ((pnode *)cur->freelist)->next;
memset(ptr, 0, mod->size);
return ptr;
}```
will try
what i usually do when encountering something that causes phys hw to triple fault is to do a "binary search" with cli; hlt loops
if you wanna do that we can
it should function and perform the exact same, it's just a lot easier to read, analyze, and optimize
don't really have the time rn (it's 4 AM) sorry
it's np
it went slower lol
nvm its not consisent
anyway
due to that refactor, i can tell you that the common path should be cur->freelist != NULL
so your performance issues are most likely due to something causing that to never happen
or almost never anyway
is it open source so i can take a look at more of the allocator?
exact same on kvm
YEPP
heres the link
awesome
it is not for the weak minded
😭 
i think i'm gonna need a debugger for this because i really can't analyze this code purely by source
the low res trollface is fucked
for love of god do not look at ioapic.c for love of god do not look at ioapic.c
bruh using my new locks barely changed anything at all wtf is this
DONT LOOK AT SCHED.C
it goes all over the place
why does git submodule update --init --recursive not even work
mathew looks at nyaux ioapic.c challenge
i do not know
i do have a .gitsubmodules
dont know why it doesnt work tho
can anyone try this I'm coping that its my computer being bad
qemu-system-x86_64 -cdrom astral.iso -M q35 -enable-kvm -cpu host,migratable=off
right well the sources are apparently here without updating the submodules so i'm just gonna ignore that
yea lol
if u have any questions ping me
bruh it made it even worse
kms
is the compile_commands.json supposed to be fucked
uhhh
run bear -- make
it usually works after that
its generated by bear
+ clone_repo_commit https://github.com/osdev0/cc-runtime.git cc-runtime 9c281448fe40498a6341d74f55c9af4f642c0b1d
+ test -d cc-runtime/.git
+ test -d cc-runtime
+ set +x
error: 'cc-runtime' is not a Git repository
make: *** [GNUmakefile:161: kernel-deps] Error 1``` fun
i just removed the dir
works now
this whole thread is really manifesting goodhart's law
@median crest
does ur kernel do serial logs by any chance
cuz my server is headless
lol
❤️
I dont see an issue with turning off every feature but the ones required by uacpi to measure the success of my kernel
wow it was surprisingly painless to get a vscode debug configuration working
@north hull
kinda funny how my new lock is much better than the old one but did not even affect speed
still keeping it though, having a word sized lock is great
nyaux with -O0 how fast will it be
how do I get the serial logs to showup again
-debugcon stdio
e9 isn't serial
yeah yeah
oh no
interesting
unfortunate
I need to get a serial driver one dya
at least it is consistent
here is the entire log @median crest
that assert fail is expected, it couldn't find nvme0n1
it is
cuz there is no nvme set up lol
its in the boot options
with kvm on -O0 its 20k
theres also an initrd option but I only shippsed the bare minimum there to make it small
bare minimum being not even enough to boot
this was with a AMD Ryzen 9 7900 (24) @ 5.482GHz
god okay this is worse than i thought
i fixed the main bug causing the slab to be slow
(the bug was that each slab only had at most one object on its freelist)
but that exposed a bug where too-small slabs were getting picked for allocations, which wasn't caught before since due to the aforementioned bug each allocation was effectively 4k
so i fixed that
and now there's ANOTHER bug
which i haven't investigated yet
WAIT WHT???
TF??/
explain the bug
right so in init_slab you build a new freelist right
but you were doing new->next = cur; cur = new; and then not ultimately setting hdr->freelist to cur at the end
so effectively the entire freelist was just the first object
oh my god.
i fixed it in a slightly different way so that the ascending address order is preserved
is that nyaux?
yes
damn monkuous turned into a nyaux developer
now i'm getting a bunch of USELESS SLAB messages which are (i assume) ruining perf
that means nyaux is the new kernel we should all be working on
@dusky glade with that + the selecting slab bug fixed + removing USELESS SLAB, i get 146061/s on -O0 + KVM
on -O2 this is now uacpi: successfully loaded 1 AML blob, 1705 ops in 3ms (avg 505754/s)
oh my god.
holy fuck what
how is nyaux doing THIS WELL
successfully loaded 1 AML blob, 1705 ops in 3ms (avg 443800/s)
how am i slower 😭😭
LMFAO
here's the patch ```patch
diff --git a/kernel/src/mem/pmm.c b/kernel/src/mem/pmm.c
index 838b4e5..a69ea75 100644
--- a/kernel/src/mem/pmm.c
+++ b/kernel/src/mem/pmm.c
@@ -119,7 +119,8 @@ slab* init_slab(uint64_t size)
for (uint64_t i = 1; i < obj_amount; i++)
{
pnode* new = (pnode*)((uint64_t)first + (i * size));
-
new->next = (struct pnode*)cur;
-
new->next = NULL; -
cur->next = (struct pnode*)new; cur = new;};
return hdr;
@@ -158,7 +159,7 @@ void* slab_alloc(cache* mod)
}cur = (slab*)cur->next;
-
// assert(cur != NULL);
-
assert(cur != NULL);}
void* ptr = cur->freelist;
@@ -173,7 +174,7 @@ void* slaballocate(uint64_t amount)
for (int i = 0; i != 7; i++)
{
cache* c = &caches[i];
-
assert(c->size != 0);
-
}if (c->size < amount) continue; return slab_alloc(c);
return NULL;
@@ -257,6 +258,6 @@ void slabfree(void* addr)
}
if (howmanynodes == guy->obj_ammount)
{
-
kprintf("USELESS SLAB\n");
-
}//kprintf("USELESS SLAB\n");
}
different CPU
the other "bug" was just useless slab being printed right?
yeah
i have a faster cpu strictly speaking
but like there is a lot of factors at play
i figured that was some debug message you put in as a pseudo assert
THIS ONE FUCKING BUG
turns out it was more like a todo
SLOWED NYAUX INTO ASS
yea it was
thank you @gentle peak
actually.
2 lines of code
slowed down nyaux like crazy
your a very smart developer.
if those kinds of bugs are "hiding" in nyaux
literally hiding in plain sight
i wonder what other kinds of bugs there are
lol
fun fact
this is actually the exact same bug i had in one of the first iterations of proxima
and fixing it made my perf go from 1.1M to 4.5M
so this is basically an allocator benchmark?
did someone try with a bump allocator already
slower than proxima due to all allocations being in cold memory
allocator + mutex/spinlock + memcpy/memset 
@dusky glade is the profiler code in the git repo? or did you take it out before pushing
ah nvm found it
successfully loaded 1 AML blob, 1705 ops in 1ms (avg 956441/s)
compiling out all the asserts
because for some reason i didn't do that in !debug 
how much memory is allocated in total?
if this profiler was able to fix nyaux
don't know
surely it can fix me
like roughly, megabytes?
iirc only a few hundred kb
so really a bump allocator is slower 
even prefetching the entire memory blob ahead of time?
or, well, all memory needed to parse the tables and dsdt
if i make my heap never give memory back to the pmm then the pmm reports 848K used at end of kernel init
so
@gentle peak any idea?
i just applied the patch
is all
it just triple faults
on kvm
like
here
consistently
???
like, with git apply?
yea
then you have the exact same source as me and i'm not getting the bug
did u try running kvm?
that's still really surprising bump would be slower no? i mean the prefetcher should be going brr, and that can fit in cache still
idk that's what the experimental data told us
bump certainly can't be slower for the allocating itself so the speed diff must be due to cache
@dusky glade only happens with -smp 20
triple faults
if it's with -smp 1 it's fine
yea what.
so it's probably a race condition
tf...
i noticed that your allocator has no locking? or at least none that i could see
and your bump allocator was literally, get a block and increment pointer each time?
I would also try to populate the tlb since tlb refills will be quite slow inside kvm
and a bit of prefetching to warm things up
that's quite intruiging though, almost makes me want to whip out the performance counters
yep
as for prefetching & stuff
we tried double init using uacpi_state_reset in between
did noticeably improve performance
but obv not useful in real world
improve better than the slab?
it is worth checking the performance counters in general though, might reveal useful info
this is weird
maybe its the same bug that the scheduler to die when u run the profiler
@dusky glade your create_region gets called from other cpus and bypasses the global memory lock
i dont know
at least i think it bypasses the lock
to call create region
u need to call kvm_region_calloc
alloc*
to call that
u need to go through the mem lock
ah ok
oh for fucks sake kvm why aren't you giving me the rip of the cpu that triple faulted
wait @dusky glade that 500k/s measurement was with UBSan enabled, with it disabled it's 1,459,252/s
damn
1 million
@left orbit

stonks
ok i managed to reproduce the triple fault with TCG
so i can now actually inspect state
how did u reproduce it
-smp 255
oh i see
ran it a few times
lmfao
get eepy
https://hst.sh/desecidamo.apache here's the exception state
gonna go to sleep now as well
general protection fault
i see
in flanterm @gentle peak ??
huh
and now its suddenly a segment related issue
crazy
the address is not likely to match between builds
ur profiler thing broke obos
it causes all code to get corrupted, it seems
this is the call stack
wait I think I stack overflowed
yeah I did
i had a similar issue in which there was something wrong with the far return
and it also faulted on that instruction
that is solved now
#GP(selector) If the source selector points to a segment that is not a TSS or to one for a task that is already busy.
the two gdt entries at that selector:
0x00908ba5802c00670x00000000ffff8000
first one looks so fucking weird
tf
memory corruption?
yea looking at the bit sitself
first one is corrupted
i think
nvm second one looks weirder
keep in mind this is a tss descriptor
2nd one is top 32 bits of base zero extended to 64 bits
base 0xffff800000a5802c
limit 0x67
attr 0b1001
pres 1
dpl 0
type 0xb
yeah so the tss is busy
everything except the type is correct for a tss
yeah no this is just a race condition
wdym
you're setting the correct bits in gdt_init yes, but you're setting them in a global shared variable without locking said variable
multiple cpus are running gdt_init at the same time and setting the same memory
you should probably go to sleep
here's the patch i used which successfully fixes it ```patch
diff --git a/kernel/src/arch/x86_64/gdt/gdt.c b/kernel/src/arch/x86_64/gdt/gdt.c
index 218233d..09759db 100644
--- a/kernel/src/arch/x86_64/gdt/gdt.c
+++ b/kernel/src/arch/x86_64/gdt/gdt.c
@@ -3,6 +3,7 @@
#include <stdint.h>
#include "sched/sched.h"
+#include "utils/basic.h"
typedef struct
{
@@ -10,11 +11,13 @@ typedef struct
uint64_t offset;
} attribute((packed)) GDTR;
uint64_t gdt[11];
+static spinlock_t gdt_lock;
extern void gdt_flush(void*);
GDTR gptr = {};
void init_gdt()
{
-
spinlock_lock(&gdt_lock);
gdt[0] = 0x0;
gdt[1] = 0x00009a000000ffff;
gdt[2] = 0x000093000000ffff;
@@ -44,6 +47,7 @@ void init_gdt()
gptr.size = sizeof(gdt) - 1;gdt_flush(&gptr);
-
spinlock_unlock(&gdt_lock);
}
void change_rsp0(uint64_t stackaddr)
{
i just added it
gn
wait
nvm
forgot to run make
goodnight monkuous have a goodnights rest
thanks for the stupid race condition u caught as well!
oh wtf booting with 64 mbs of memory gives a huge boost to performance what
I go from 900k to 1.4mil-1.5mil consistently
on my crap laptop
nyaux has 1 million ops now
😎
neat
no like actually
without ubsan
it runs 1m ops
ish
500k with ubsan
because of one slab allocator bug lol
@fiery turtle update my score when u wake up
seems like running with over 2 gbs of memory slows it down
wonder why
if I run with 2.9gb it gets the consistent ~1.4mil and with 3 gb it gets 1 mil wtf??
You haven't implemented PCI though have you?
Bruh wtf have I missed
nyaux is 1.5M/s if you change 3 lines of code and disable ubsan
Nyaux single handedly fixed by monkuous
💀 thats actually crazy
slab was broken basically
every time a slab was allocated only the first object was put onto its freelist so effectively every allocation went to the pmm
Ah
also @\infy if you're still curious about zig's ability, you can take ghostty (the zig terminal emulator) and actually effortlessly cross compile it on linux for windows, which i find kinda cool that it just produces a working windows binary with no dependencies other than zig, everything including the C/C++ dependencies is built by zig and statically linked into the final binary
oh btw @dusky glade i figured out why the profiler caused a page fault: when creating a task your scheduler sets its rsp to the top of the stack, but the sysv abi expects the return address to be stored at rsp, so when it tried to read the return address it page faulted
Oh yeah that's pretty nice, I know people who do osses in zig literally compile elf on windows
fixed by just subtracting 8 from the top of the stack when creating a task
yeah that is also possible, if you want to do that for whatever reason
Bruh inb4 nyaux beats proxima 
xorriso for windows is another beast
Xorriso is kind of insane yeah
i've used a working xorriso for windows multiple times
I want to try it out for sure, you've shilled it enough 
i think this is the place i downloaded it from usually? https://github.com/PeyTy/xorriso-exe-for-windows
Surprisingly its from a guy with fake os
seems like it's just a cygwin build though
yeah i just wanted to note my little experiment, i think ghostty is a nice benchmark for the compiler and showcases it's in a much better state than 1-1.5 years ago where it crashed if you called a function in a funny way lol
Yeah
damn I gotta pump my numbers up
step 1: figure out how
step 2: give up
that concludes the work, goodbye
i wonder what the numbers will look like if infy decides to work on a kernel of his own
I will soon join obos at the bottom
more people at the bottom, easier to look cool with my potential future kernel next to obos so im happy 
lol obos
obos has suspend which is cool
astral and obos nah because of code quality, my "ocd" makes it impossible to work with code like that
sadly
oh yeah astral code style is uhhh
mfw no ironclad
hardtocomprehend
contribute to cynix or something, there is not much so it's not a good project
oh ye
it's just a project
forgot about it
autohell makes me wanna cry but i'll look
it doesn't even use autohell
yeah
bear it up :p
implement enough in cynix so it can be put on the leaderboard
iirc it scored very high
tahts probably with old uacpi too
yeah
i didn't really look at proxima so it could be a target, and managarm is phd code so i'd rather blow my head off than try to wrap my head around all the async hell :^)
the thing with Cynix compared with the other examples there is that despite there not being much to show, admittedly, i have tried to keep the code really clean and there is no technical debt
my main problem with managarm is its hard to build
u need a sequence of commands, files, edit stuff
if I ever get this PE kernel anywhere I am going to try uacpi on it, can also do sse because the call conv saves them iirc (so using it in interrupts is not a problem)
it's actually easy with cbuildrt, and you get to pull tools and packages from ci
proxima and cynix are both pretty clean i think
@\monkuous
monkuous
i wanted to do a funny PE kernel too lol
Ironclad is unironically the best to contribute, its reasonably stable, very low technical debt, very self contained, very documented, easy to test, it just has a single problem, and that is knowing Ada
i like how PE does imports/exports
compare to ELF
it actually has a dedicated thing for that, which is awesome
yeah
PE is also built with reloc in mind
yup
not as an afterthought
my plan was to have a loader that boots with limine and gets the kernel + some modules passed as limine modules, does some simple memory management, loads kernel + module into the memory and passes control to the kernel
but i hate C build systems
Is it difficult to patch to have os specific toolchain?
probably not, as long as you add it to llvm
like what
PE support to Limine would honestly be a welcome addition
building llvm 💀
like loading kernels from a PE instead of an ELF?
yeah
the protocol itself is literally 100% executable agnostic
is it?
Have you looked at pmOS? 
doesnt the protocol mandate e.g. ET_DYN
I have llvm
it actually doesn't, wow
limelfline
i took care specifically of never making the protocol in any way ELF specific
it can
The executable, loaded at or above 0xffffffff80000000, sees all of its segments mapped using write-back (WB) caching at the page tables level.
segments
very nice
PE support is very doable then, i guess
clearly this means GDT segments 

especially since i don't have to do imports/exports
I also basically did that, its slightly cursed though because it has to have a page somewhere in the low virtual memory mapped in both the current page map and the new page map where you switch the pagemap
only load the PE into memory and do relocs
you still have to do relocs
segments in here isn't referring to ELF segments specifically, rather just executable image segments
yeah i get that, i just like the fact that it's format agnostic
and there can be only 1 segment, for those formats (or really lack thereof) that don't have segmentation
also technically we could implement a dynamic linker for PE into limine lol
it's piss easy as it's just loading multiple PE files and resolving imports
yeah but ELF is a bit more complicated in that regard
but true, feature parity would be nice
it's not something we couldn't do
why tho
because it would be nice, and as i said it's really easy with PE
yeah i don't think it's that useful honestly
it requires extensive kernel support
i'd worry about plain PE support first
and for things like kernel modules the kernel can also do that itself if it wants
not really extensive, it's done by the bootloader :^)
so you can just dynamically link ur kernel and drop the modules in /boot
well, how do you make sure it's mapped where the kernel won't complain
relocations have a size
but the IAT is just a table of addresses
so it won't complain
different story for elf maybe, i guess
idk how dynamic linking works in the ELF land
well so does mlibc
but it's kinda poop lol
well, not mlibc
but elf dynamic linking in general
i need your opinion on my coding style 
show
banger
looks properly formatted
tabs are L


