#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages ยท Page 35 of 1
not old
it's on master, but behind a commit for RTC support, which is used in zero places in obos
I've debugged to my full extent
@ me if you need any more testing
and have found it's in uacpi_finalize_gpe_initialization
No like put prints in uacpi code
sure
This doesnt tell me much because this pr didn't change any event code
So it must be something else
Like an obos bug 
What about this plus new uacpi
I'll do that
If that still hangs pls put prints in uacpi, finalize gpe initialization is really small
bruh wtf is cmake smoking
fatal: unable to read tree (63ab369748db5764b59a728f54da0d7e5390f407)
CMake Error at /home/oberrow/Code/obos/build/x86_64-release/_deps/uacpi-subbuild/uacpi-populate-prefix/tmp/uacpi-populate-gitclone.cmake:61 (message):
Failed to checkout tag: '63ab369748db5764b59a728f54da0d7e5390f407'
ah nvm
infy rewriting history
Yes
@keen marsh
Same as last time
guess I'm adding prints to uacpi code
I can probably test on my own from now, then when I've actually found a bug*
I can ask you
and framebuffer's broken on sony laptop 
Lets go
*in uacpi
and on the macbook
I can't test it 
I'll return in 3 days
In the meantime I'll only have my Lenovo laptop
At least that's one which has GPIO meme
Good test bed
ret = set_gpe_state(event, GPE_STATE_ENABLED);
if (uacpi_unlikely_error(ret)) {
gp_event_toggle_masks(event, UACPI_FALSE);
event->num_users--;
}```
uacpi is last seen here
ret = uacpi_gas_read(®->enable, &enable_mask);
if (uacpi_unlikely_error(ret))
goto out;
switch (state) {
case GPE_STATE_ENABLED:
enable_mask |= event_bit;
break;
case GPE_STATE_DISABLED:
enable_mask &= ~event_bit;
break;
default:
ret = UACPI_STATUS_INVALID_ARGUMENT;
goto out;
}
ret = uacpi_gas_write(®->enable, enable_mask);```
then hangs somewhere here
Gas write dispatches into your code btw
in between the two locks
which apis
uacpi is last seen during or after the gas write
I think it hangs in outb
writing 0x22 to I/O port 0x182a is the last thing I see
Wtf
byte width is 1
And that never returns?
so it's an outb
nope
there was a previous write to that port:
writing 0x02 to I/O port 0x182a```
a read made right before that indeed returned to the caller
with 0x02 as the value read
Huh
basically:
acquired [some random spinlock]
read 0x02 from 0x182a
writing 0x22 to I/O port 0x182a
HANGS
Can u roll back to previous uacpi but keep these io traces? To see if the values written have changed or something
sure
Thanks
Although I dont understand how outb can hang
Any chance u get an irq during that?
What about acpi
GPEs are blocked at IRQL 8 (some random IRQL, nothing special about it)
and IRQL_GPE > IRQL_DISPATCH
so it might get a GPE which throws stuff off, but it seems unlikely that it would happen every time
Because that thing might enable a gpe with a spinlock held, if you dont actually disable irqs and call into uacpi again that will hang
Do u trace spinlock acquires?
spinlock acquires are being traced
uacpi_cpu_flags uacpi_kernel_lock_spinlock(uacpi_handle hnd)
{
spinlock* lock = (spinlock*)hnd;
printf("acquiring %p\n", hnd);
irql r = Core_SpinlockAcquire(lock);
printf("acquired %p\n", hnd);
return r;
}```
and there are no logs related to spinlocks after the write
is master good?
or is that too old?
actually I'd ideally be on the commit that I knew to work before
1d636a34152dc82833c89175b702f2c0671f04e3
Yeah
How old is that
Compared to master
Signed-off-by: Daniil Tatianin [email protected]
Thats basically master
cmake is being retarted
*restarted
huh what
it still hangs on old uacpi
same value written
But u said it just worked on the old uacoi ๐๐๐
Bruh
Maybe try older uacpi or obos something?
And make sure u did overwrite the usb
yeah I did
Oh also
overwrite the usb
soo skip the call to OBOS_InitWakeGPEs
Also maybe it just doesnt repro every time?
still hangs
without that
and I can confirm the usb was overwritten
I'm going to download pmOS
Try that ig
That might have a fucked framebuffer tho
If that doesnt work will try proxima
bah whatever
I'll just see if the power button shuts down pmOS
Yeah
which should be enough to see if it works
this iso worked...
idk how new of uacpi it is
unless
it doesn't
idk if it's hanging or what
but the power button isn't shutting it down
it says that it enabled 11 GPEs
Its pr head
@calm latch is it supposed to?
Btw can u give a dump of this pc
you already have it
It is
Which one is it
Idk it only works in QEMU
it's an acer pc if that helps
does it use fixed events and EC?
but it's probably the first one
The only nice thing is that now it's consistently broken
Yes
it isn't shutting down
I would imagine the kernel is panicking
And nothing?
then nothing
also it seems to test the AHCI controller
spamming the keys on the keyboard does nothing
Yeah it's the thing I'm working on

I'm not at home but will debug this evening
Maybe the AHCI driver is messing everything up
@north holly can u try this?
k
alothugh fuck i dont think it hooks up the power button
@gentle peak (sry for ping) where can we get the latest proxima build that shuts down on power button?
yeah it also doesn't boot
yeah it triple faults
iirc that one does
like in qemu?
doesnt work in my qemu
no, it triple faults in real hardware
and doesnt shut down in qemu
last thing I see is limine messages
i tried looking for your ci image but i dont se the links in the repo
apparently i lied in that message and the build was not for x86-64-v0
bruh
i'll get the latest from ci
maybe that was the SSE build
i believe that one was where i built with -march=raptorlake -mtune=raptorlake accidentally because i forgot you have to fully reconfigure with meson for those to apply
makes sense
yeah I think haswell is a bit older than raptorlake
here's the latest from CI
that's the expected output yeah
still triple faults
i forgot currently it panics on init and therefore irqs are disabled
bruh we dont have a single non broken kernel to test uacpi with ๐
it's not really broken
astral
so it panics on init and disables irqs
it triple faults on my PC where the bug I'm trying to debug is on
yeah give me like 2s
it's github actions, you can't download the artifact if you're not logged in and idk if you need to be a member of the org or anything like that
astral doesnt enable events
not even finalize gpe init?
ye
latest local build, which actually has a /bin/init
that's very frustrating to debug fuck
hmm it says shutting down in 3 seconds but actually shuts down in like 30
btw pmOS does boot past finalize_gpe_init
yes but it doesnt shut down
which ur pc should because its a fixed event i think
as in qemu doesn't report it or your host doesn't have it
yeah it's fixed
because proxima ignores what cpuid says about invtsc presence
the former
I thought you did that since the power button works
nah thats a separate thing
Oh
the thign that hangs on obos is not called on astral
astral doesnt call it because i forgor
:skull
oh the build i sent also triple faults on my own haswell test machine
that makes it easier to debug at least
it is a outb
oh also this uses uacpi master not the 1.0 rc
@north holly are u brave enough to try latest managarm?
idk how that would be bugged
thats fine, obos hangs on master too
because that enables irq generation for those gpes
I don't feel like finding an iso
probably didnt mask well enough
because outb cant hang
unless it triggers and smi, which this one shouldnt i hope
it's at irql 15
the only thing that can happen is NMI
and SMI
probably
@north holly can u try this one pls https://builds.managarm.org/project/managarm/files/2025-01-22T21:56:41
993.0M
yes
too much time to download
ok what the fuck?
if i set up an hdd image on the usb with the exact same kernel and initrd images it boots fine
but if i dd an iso onto it it's broken
i mean i saw it get into the kernel on the iso boot
it triple faulted after time: tsc is ... MHz
ah
I didn't
Small is 8 gigs for me
i can confirm the shutdown works on my machine though
But we have a nightly image linked in the readme
I mean I can but it takes many long time
We default to 4 gigs lol
haswell fix 
i did not make any changes
that's the thing
i literally just switched from dd'ing an iso to setting up a proper hddboot on the usb for ease of debugging
can u send over that raw hdd image?
arent all managarm images at least 4gb
It's not 4gigs compressed
port in question is 0x182a
is it ASUS?
ACER
I don't own anything ASUS
the motherboard might be asus
Somebody with a managarm dev env could just do xbstrap install base && xbstrap run initialize-empty-image remake-image
to get a minimal image
what's the OEM ID
the one I have is ACRSYS
in the dsdt
[050h 0080 4] GPE0 Block Address : 00001820
with lenght 16
so yeah its correct
what's offset 0xa supposed to mean?
now I'm getting tempted to make a kernel that just dumps out the entire acpi tables to com1 or something just to make making the dumps easier
half is status half is enable bits
so i guess the fix is ```sh
DEVICE=/dev/...
LIMINE=$(limine --print-datadir)
sfdisk "$DEVICE" << EOF
,+,0c,-
EOF
limine bios-install "$DEVICE"
mkfs.fat "${DEVICE}1"
mount "${DEVICE}1" /mnt
mkdir -p /mnt/EFI/BOOT
cp "$LIMINE/BOOTX64.EFI" /mnt/EFI/BOOT
cp "$LIMINE/limine-bios.sys" /mnt
cat > /mnt/limine.conf << EOF
timeout: 5
/Proxima
protocol: limine
kernel_path: boot():/boot/hydrogen
module_path: boot():/boot/proxima.tar
EOF
umount /mnt
echo "Now copy /boot/hydrogen and /boot/proxima.tar from the ISO to the USB"
offset A is GPE 0xA - (16 / 2)
so 0x182a is GPE 10 of GPE block zero?
no, its at least GPE 16
each bit is one gpe
0xA - (16 / 2) is 2
so 16 bits
and then we would check the bit that it sets in that reg
I see
btw the oem id is dell @north holly
wrong ACPI tables
bruh
[000h 0000 4] Signature : "FACP" [Fixed ACPI Description Table (FADT)]
[004h 0004 4] Table Length : 0000010C
[008h 0008 1] Revision : 05
[009h 0009 1] Checksum : F5
[00Ah 0010 6] Oem ID : "ACRSYS"
[010h 0016 8] Oem Table ID : "ACRPRDCT"
[018h 0024 4] Oem Revision : 01072009
[01Ch 0028 4] Asl Compiler ID : "AMI "
[020h 0032 4] Asl Compiler Revision : 00010013
yes
and length?
ye
64 gpe regs, 128 bits total, 64 status bits, 64 enable bits
thanks
wdym
for reference: this hddboot image works on my haswell machine
and it doesn't on mine
at least when I dd the image
I'm gonna go get something to eat now
bruh
so unlucky
@gentle peak btw if you have time, could you test out the 1.0rc pr?
origin/address-spaces-support?
if i had a bit more patience i'd investigate it
but i have literally nothing to go off of given that (presumably) the triple fault occurs before the display "recovers" from limine's modeset
so it'd take a long time to narrow down
true
uacpi regression!
not receiving the power button event
i'm getting the VALZ no listeners warning
but the actual handler isn't getting invoked
ok this is actually good
I have found out it's tryna do something to GPE 21
it's trying to enable it
now time to see what GPE 21 is
this happens on real hardware too
on qemu i mean
sorry
i'm not getting the valz no listeners thing on qemu obv because that's a toshiba thing
but the power button handler isn't getting invoked either
nice because i can probably repro it in astral locally and then debug from there
yeah it happens on debug builds running in tcg and everything
as a quick guess, perhaps reverting dfd92d5d87acadc574619b1b0401dc59a92da422 could fix it
potentially followed by e7ffcaa016515e4857630af6ae342fb0eb97ceb6
Power button's also broken in QEMU for some reason...
yeye same in proxima
Maybe I messed something up
its a uacpi bug in the pr
some caching logic might be incorrect i think
ill debug it soon
I'm gonna test a really old obos commit
before I even had an EC driver
to see what happens there
seriously infy
you gotta stop rewriting git history
Cloning into 'uACPI'...
fatal: unable to read tree (cc2ac5f788d81874b9c677c763b803aa375e9395)
CMake Error at /home/oberrow/Code/obos-old/build/_deps/uacpi-subbuild/uacpi-populate-prefix/tmp/uacpi-populate-gitclone.cmake:61 (message):
Failed to checkout tag: 'cc2ac5f788d81874b9c677c763b803aa375e9395'
@gentle peak does reverting both of these on top of uacpi's pr fix it for u in qemu?
i'll try that in a sec but i'm stepping through the code a bit and i noticed that when do_read_one(mapping, 0, &value0) calls uacpi_gas_read_mapped, gas->total_bit_width is 0 so it doesn't read anything, and do_read_one(mapping, 1, &value1) does an early exit because it isn't in REGISTER_MAPPING_STATE_MAPPED
this is while reading PM1_STS
which seems wrong
obos 3783b02138985e269bceb137233328b658411427 works
yeah because PM1_STS can have two separate registers
and pm1b is not implemented on qemu
which is the commit right before any sort of EC driver was added
so it just skips reading it
oh wait, bit width is 0 even for the first one? yeah tahts wrong
i'm more so worried about the first one
oh great the revert has a merge conflict
yeah nvm dont even try to revet it, obv thats the bug
im not sure why it gets a zero there tho
in map_one for PM1a, the temp_gas has 0 for register_bit_{width,offset}
spec->access_width is 0
thats correct
its only specified for non-gas
gas_validate somehow returns 0 for total_width i guess?
yeah but that info is then copied into the mapping by uacpi_map_gas_noalloc
wdym? total_width is returned from gas_validate right?
the total_width calculated by gas_validate is align_up(bit_offset + bit_width, uacpi_size)
both of which are 0
yeah, but it aligns up to computed access width
or i guess it aligns the zero up to zero?
but pm1 is REGISTER_KIND_GAS no?
whats the backtrace?
#0 gas_validate (gas=0xffffffff9034ee84, access_bit_width=0xffffffff9034ee4b "", bit_width=0xffffffff9034ee4a "") at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/io.c:727
#1 0xffffffff800437e0 in uacpi_map_gas_noalloc (gas=0xffffffff9034ee84, out_mapped=0xffffffff8004f500 <g_register_mappings>) at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/io.c:837
#2 0xffffffff80044d76 in map_one (spec=0xffffffff80003da0 <g_registers>, mapping=0xffffffff8004f500 <g_register_mappings>, idx=0 '\000') at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/registers.c:139
#3 0xffffffff80044e39 in ensure_register_mapped (spec=0xffffffff80003da0 <g_registers>, mapping=0xffffffff8004f500 <g_register_mappings>) at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/registers.c:168
#4 0xffffffff80045064 in uacpi_read_register (reg_enum=UACPI_REGISTER_PM1_STS, out_value=0xffffffff9034ef20) at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/registers.c:236
#5 0xffffffff80046773 in handle_fixed_events () at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/event.c:205
#6 0xffffffff8004877a in handle_sci (ctx=0xffff800007f37440) at ../../../../../packages/hydrogen/src/subprojects/uacpi/source/event.c:2099
#7 0xffffffff80011835 in acpi_irq_dispatcher (ptr=0xffff800007d53980) at ../../../../../packages/hydrogen/src/kernel/src/drv/acpi.c:374
#8 0xffffffff80023665 in sched_init_task (func=0xffffffff800117de <acpi_irq_dispatcher>, ctx=0xffff800007d53980, task=0xffff800007d3d800) at ../../../../../packages/hydrogen/src/kernel/src/sched/sched.c:439
#9 0xffffffff8000eb7e in task_init_stub () at ../../../../../packages/hydrogen/src/kernel/src/sched/sched.S:42```
here's the raw one from gdb
[UACPI_REGISTER_PM1_STS] = {
.kind = REGISTER_KIND_GAS,
๐
yeah it gets changed somewhere
oh wait i was looking at access_kind not kind
you should really make the fields in the struct themselves enums instead of chars so the debugger prints them nicer
yeah kind is 0
i mean
not really
right now it's 3*u8 followed by a pointer
if you changed them to enums you'd only be wasting 4 more bytes
ah i see you made the same mistake i did
if i change that to spec->kind it works perfectly
no problem
does real hw work as well now?
testing now
(ideally on current pr head)
did you rewrite git history or something? git's saying the local and origin branches have diverged
it's not an issue but still
yeah ofc, i just pushed the fix into the commit which introduced the bug
works on real hw
nice
there's another behavior change which i dont like
total_width = UACPI_ALIGN_UP(
gas->register_bit_offset + gas->register_bit_width,
*access_bit_width, uacpi_size
);
previously this wasnt getting aligned up when doing io
not that it should matter in this case
@north holly ive just fixed a relatively important bug, can u retest
probably not the one that caused your hang but
i mean it could've been the cause, since the bug had the potential to access mmio as pio
with how interconnected everything is i still wouldnt be shocked if it was related to the hang in obos
fair
oh true
and e.g. latest pmos did make it past the spot where obos hung
but didnt shutdown because of this bug that monkuous found
@calm latch btw can u git fetch && git reset --hard origin/address-spaces-support and rebuild the image?
so oberrow can retest on his pc
because proxima triple faults on that
upsides of using zig fetch & co for dep management:
- zig fetch --save=uacpi git+https://github.com/uACPI/uACPI#address-spaces-support and its done without having to deal with git history management on a submodule
downsides:
- no local copy to edit for adding printfs
no local copy kinda sucks yeah
i think it stores one in the build cache but thats checksummed so cant edit it and hard to find
but if i dont need to edit uacpi then dang is it nice
can also put in a path instead of a url to do it with submodules or whatever in case of emergency
thats what i do for other deps i have needed to edit
True
I'm going to do that after playing Minecraft
Hypixel
My computer is too shit for mods
And I don't want to make a new world
bruh 1.13 still doesn't work on debian sid
I'll just send a crash report
ah
hopefully they fix that (they won't)
but anyway, I guess I'll play hypixel in the meantime
last time I looked at it, some library was failing
how
it's java
how can it not work on debian
When I was a kid I played mc with mods on a celeron with intel hd graphics 3000, you just gotta optifine it hard enough
And use like 2 render distance
nvm I'm not playing hypixel anymore
yeah idk
library initialization failed - unable to allocate file descriptor table - out of memoryAborted (core dumped)
hm
huh changing the command to use java instead of whatever the mc launcher packages
gets it to work
I'll be home in 2 hours, but I can explain how to build it 
(I think I need a better build system, but whatever)
I can't test now, but it was also not booting on my PCs
Though it might have been unrelated
shameless xbstrap suggestion
minecraft break done
bro why would an outb hang

uacpi_status uacpi_kernel_io_write8(
uacpi_handle hnd, uacpi_size offset, uacpi_u8 in_value
)
{
uintptr_t port = (uintptr_t)hnd;
#if defined(__x86_64__) || defined(__i386__)
outb(port+offset, in_value);
#endif
return UACPI_STATUS_OK;
}```
did you put a printf after the outb?
and is it just triggering an interrupt the instant the outb goes out and then thats hanging?
That was my assumption
Try no-oping uacpi irq installation
UACPI_STATUS_OK
my IOAPIC code has struck again
this is the second time this has happened
on that same computer
Wdym
Like doesnt hang anymore?
I guess it was hanging because your polarity was bogus
And u did get an irq right after the outb
fix your goddamn gsi routing code
Being registered
sure
Weird that it worked in a very old obos commit, even though I hadn't changed any ioapic code
Since then
git diff never lies
u mean git log
I used git diff
To compare whatever the commit that I tried was
To master
And the ioapic code wasn't changed except for one small detail which I am sure doesn't matter
inb4 memory corruption
one small detail which i am sure doesn't matter
๐ค
does uacpi support modern standby
what does it entail
Elixir Cross Referencer - source code of Linux v6.12.6: drivers/acpi/x86/s2idle.c
thanks ill give it a look
npnp
does uacpi need to be initialized to return tables with uacpi_table_find_by_signature
you can use early table access
what do you mean by that
uacpi_setup_early_table_access
np!
It's basically just switching the order a 64 bit register gets written in
From low first then high to high first then low
ok yeah that shouldnt be an issue lol
(0000000000) successfully loaded 1 AML blob, 1712 ops in 10ms (avg 171200/s)
q35 + kvm?
for the sake of my ego ill just not say
btw do u want me to add ironclad to the mentioned projects list
It gets power button notification, but doesn't shut down untill I press the keyboard button for some reason
no like
It sent messages in wrong order
u get the notification
not when u press the power button?
i dont think its a qemu thing
I press power button, it gets notification and doesn't do anything
untill I press enter
weird
i doubt it matters but
because it sounds like it hangs in userspace
until u press a key
master
or scheduler idk
but u get the notif
Maybe broken timers
Idk, it does sleep(3);
Lemmy check master
I added 3 new syscalls and changed my IPC stuff
maybe I broke something
in the process
That would explain it
(more messages to compete with Nyaux thread)
(for me to fix this)
bruh wtf is going on with my wifi
I can't even push a commit
Remove the star
I think my timers code is broken
If I open QEMU monitor it does it as it should
sleep() that is
Yeah potentially
@north holly ?
But why is pressing a button needed
It gets keyboard interrupt, which reschedules and restarts lapic timer, probably
https://gitlab.com/mishakov/pmos/-/tree/dev?ref_type=heads is on the new branch
I don't remember, but I think I might be disabling the timer in idle thread 
(I've also changed the timers' code)
Too defensive programming 
The Hamming weight of a string is the number of symbols that are different from the zero-symbol of the alphabet used. It is thus equivalent to the Hamming distance from the all-zero string of the same length. For the most typical case, a string of bits, this is the number of 1's in the string, or the digit sum of the binary representation of a g...
i think im going to do this
instead of relying on __builtin_popcnt
What advantages does it bring
not relying on libgcc or x86_64-v1
// https://en.wikipedia.org/wiki/Hamming_weight#Efficient_implementation
uacpi_u8 uacpi_popcount(uacpi_u64 x)
{
x -= (x >> 1) & 0x5555555555555555ull;
x = (x & 0x3333333333333333ull) + ((x >> 2) & 0x3333333333333333);
x = (x + (x >> 4)) & 0x0F0F0F0F0F0F0F0Full;
return (x * 0x0101010101010101) >> 56;
}
this should work
That would be very neat for me
Please do
yeah
everyone compiles for x86_64 base so it produces an undefined reference which is annoying
wait
this is used in like one place to count set bits of a 16 bit number
i can just get rid of this
for some reason i was under the impression that aml had a popcount instruction
nice to get rid of things
yeah ill just do this ad-hoc loop, which is used on a very cold path anyway
is has_builtin false if you compile without the instruction, for however popcout was implemented?
if so id use that just in case
yeah this is resource conversion
so very very cold path
@north holly @calm latch I just made a few last minute optimizations (for GPEs) and popcount removal, so if you can pls retest
EC stuff might've regressed
alright, I think that's it, if oberrow and mishakov dont find new regressions im merging it

and monkuous (if they're available to test)
uacpi 1.0 tomorrow then ๐ฅบ
lol
@stone reef I'm going to spam and there is nothing you can do about it!!21111!!!
if there's some builds that can be tested on hw, I'll try them on a few different machines of mine
sure that would be cool
I have desktops and laptops from a very wide range of eras and manufacturers
how old are these machines
oldest is a Core 2 Duo from 2007
newest 2 are an AM4 board from ASRock and an LGA1700 board from ASUS
and several in between
I can test on all of these
- Dell Optiplex 755 - C2D E8400
- Dell Precision T1650 - Xeon E3-1240v2
- HP ProBook 4540s - i5-3210M (sadly has known but unfixed graphics issues in Limine - iirc only when booting via legacy BIOS?)
- HP EliteDesk something or other - some 4th gen i7 (I haven't touched this one in a while, I forget what exactly it is)
- Dell Latitude E5250 - i5-5200U
- ThinkPad T14 Gen 1 AMD - Ryzen 7 PRO 4750U
- Beelink SER5 - Ryzen 5 5500U
- ASUS PRIME H610M-E D4 - i3-12100f
- ASRock B450 Steel Legend - Ryzen 5 3500X
well that's only on that one machine, and it's purely a graphical issue
it actually executes fine, but the fb pitch is wrong or some nonsense
This should be fun
I can also make a build with 32 bit userspace (and uACPI)
pmOS doesn't need framebuffer 
core2duo probably supports 64-bit stuf tho
(it doesn't work half the times)
Yeah it's an ok 64 bit
There's stuff like athlon 64
which is like early 64 bit
I had B450M steel legend lol
anyway
time to recompile llvm
git fetch && git reset --hard origin/address-spaces-support?
/home/misha/llvm-pmos/libcxx/src/memory.cpp:102:43: error: size of array element of type '__libcpp_mutex_t' (aka 'pthread_mutex_t') (32 bytes) isn't a multiple of its alignment (64 bytes) 
what the fuck
Idk
llvm insanity
It's defined as ```C
typedef struct {
__pmos64u_t block_count;
__pmos64u_t blocking_thread_id;
struct __pthread_waiter *waiters_list_head;
struct __pthread_waiter *waiters_list_tail;
unsigned long recursive_lock_count;
int type;
#ifdef i386
} pthread_mutex_t attribute((aligned(64)));
#else
} pthread_mutex_t;
@fiery turtle this new commit caused obos to shutdown on suspend
Either that or I forgot to do something
Ah nvm I forgot something
but that would be a funny bug
I forgot to put the wake gpe registering code back
lmao
Silly me
clang's -E is refusing to work 
what
The HEAD of the PR broke suspend
can u please triple check
Yes
that its not an obos bug
I will be going back in time to make sure
I am going insane ```C
230 "/home/misha/pmos/sysroot/usr/include/__posix_types.h" 3
typedef struct {
__pmos64u_t block_count;
__pmos64u_t blocking_thread_id;
struct __pthread_waiter *waiters_list_head;
struct __pthread_waiter *waiters_list_tail;
unsigned long recursive_lock_count;
int type;
} pthread_mutex_t attribute((aligned(64)));
typedef pthread_mutex_t __libcpp_mutex_t;
what the fuck
cpp output by clang
I need clang wizzards
no futex? 
hello
also what is strange about this CPP output?
My mutex is done with IPC 
Which needs to go because of priority inversion issues, and besides the point
This error
32 bit
ahhh
yeah
easy to get wrong :p
@north holly did u figure it out?
I'm trying
is it an obos problem?
Idk at this point
what happens exactly
The signs do not point anywhere
Are there operating systems with i686 uACPI?
not besides reactos
fuck ld.lld: error: unable to find library -lclang_rt.builtins-i386
not this shit again
that's why you're doing 32-bit stuff?
I'm trying to build 32 bit userspace
can you make a normal 64-bit pmos build as well?
Ok I think it works
what was the issue
which
can u do the pr head
I'm on my phone
Yes
-- Compiler-RT supported architectures: 
Why is it so difficult to compile compiler-rt?
clang makes me want to go back to gcc
which is not the vibe
wat da shit
wtf is going on
Page fault
in the allocator?
what
I put a restriction on what IRQL you can page fault on
Because like swap n'shit
That might need to block
why do u get a pf there
I didn't get an irq during that ig
Yeah probably
It's a timing issue
Or well
The irq is at the wrong time
maybe its a regression and u arent supposed to get an irq at that time?
whats even the event
do u get ec events?
Whatever happened to the light on suspend
I will check
hm?
how is literally everything breaking 
at this rate there will be davix suspend before obos suspend works 
But it's still in suspend
did it wake up at least
Obos suspend has worked for a long time
Yes
try ec events and see if that light not turning on repros
(on the 1.0 PR. also I'm just trolling. I have no plans on doing suspend for a while)
I don't think it worked on an older commit
So it's fine
the light?
Yes
kk
and also the ioapic fix so we can test on other pc
EC events worked
At my friend's house using my laptop
My laptop's EC events work
like lid and stuff?
Yes
ok cool at least this laptop didnt regress
Ye
do not walk towards it
but it worked with the broken pr as well earlier today right
lol
yeah this laptop doesnt care
What even happened?
32 bit userspace broke kernel
tldr is that i386 has too little registers, so I pass some of syscall arguments on stack
ok 32 bit userspace uACPI seems to be kinda working
I need to fix a pagefault
(fork is broken)
hey mishakov I'm bored, can you throw at me some random thing I could implement in my kernel that only takes a few hours
@calm latch
Do you support i386 userspace on 64 bit kernel? 
no
(t yet)

but for that I'd need an i686-obos toolchain which I don't feel like doing
I recently added CMOS RTC support because I was bored
but no gettimeofday syscall to go with that
yeah
anyway 32 bit userspace pmos build
@fiery turtle
@pine leaf ?
fork is broken but it shouldn't matter
yeah gimme a bit
I can test it later today
btw what's your timezone?
GMT-7
since ugh
Bruh it triple faults on my laptop
Which is something new
I think the last time I saw pmOS triple fault was a year ago...
@fiery turtle it only shuts down when I press enter in QEMU 
Anyway, normal build
could it be WSL2 shenanigans?
This works on my laptop
EC + AMD GPIO
(like power button + lid)
And it shuts down in 3 seconds, as it should
took until literally now but i think i finally have an understanding in my brain of how to make my mm work so i can go back to acpi and drivers and actually fun things
Like on real hw it works fine?
Is this from master or pr?
Letsgo
At least on my laptop
the pr head?
Lemmy double check
how did u manage to have it regress on qemu but not real hw
misha@Yoga:~/pmos/devicesd/uACPI$ git log
commit 199b625a347e8f91efad3ec6c7a2200903a24f01 (HEAD -> master, origin/address-spaces-support)
Author: Daniil Tatianin <[email protected]>
Date: Sat Jan 25 00:17:39 2025 +0300
stdlib: get rid of uacpi_popcount
Is this the right one?
yup
I think I've managed to catch the framebuffer bug/kernel panick in virtualbox...
so this is the one u tested with and no regressions on your laptop found?
It seems so
This is the build
lol
anyway looks like the pr should be good to merge then
@gentle peak if you're here maybe a final proxima test, since I've updated the PR since last time
especially curious about that laptop with legacy GPEs
because i added pre-mapping for GPE registers

whats the opcode?
sure, give me a minute since it seems like i managed to break my build system
216001: c5 f8 77 vzeroupper
btw why did you decide to split proxima into multiple repos
should work on 32 bit
i don't like when things that are logically different packages are in the same repo
kernel and libc shouldn't belong in the same repo imo
Yeah why is it broken on everything but my Zen 4 laptop...
i guess
I would like to thank infy for making me able to remove all copied libgcc code from Ironclad, not used for anything else but uacpi, with the latest commit in the dev branch
a toast for you infy
lol thanks
was there some other code besides popcount?
works on this laptop
nice, and u get the notify for that proprietary device too right?
yeah
no
i was worried for a sec
pmOS build without AVX-512 
interestingly, while i do still get the valz notify when pressing the power button, i don't get it when opening/closing the lid anymore
i don't install handlers for those events but i used to get them anyway
It breaks in the exact same way in virtualbox ๐
u should be getting them if you used to
does it happen if you revert?
only shuts down when I press enter
(or maybe try rebooting as well)
it was working fine before
and this entire time, you could have just used clang which never calls the builtin
before what?
of pmos?
I dont really have a choice with Ada, regardless of how much I shill GCC
maybe I did something in kernel
since GNAT is GCC only for the time being
yeah
ah
you can compile uacpi with clang though
what can it do other than calling the builtin tho?
that is a mess (to require 2 compilers at once and link them statically and hope nothing breaks) and a bit hard to line up with the current buildsystem
I rather just slap the C popcnt
which I dont have to do anymore!
doesn't happen on master either, maybe i'm misremembering and it never happened
bruh no last minute regressions for me to debug 
interestingly though, 1.0-rc seems to be a minor performance regression (very minor, 7.2-7.4M -> 7.0-7.2M on kvm)
fair enough
lemme take a look at your dump if u have that at all
it's on the acpidumps repo
yeah i have it
Def the popcount :^)
#[unsafe(no_mangle)]
extern "C" fn __popcountdi2(a: i64) -> i32 {
a.count_ones() as i32
}
``` my shitty test os had it implemented like this lul
thats probably because of extra logic to handle special fields