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

[loud ice]

then tell the firmware you want it

and then acquire it again

and you release it from a work handler

[fiery turtle]

What

[gentle peak]

why would you do that when you need events anyway

[loud ice]

fair

[fiery turtle]

Like deadlock yourself?

💀

[loud ice]

yes, until the firmware signals an interrupt

when you undeadlock yourself

[fiery turtle]

Some kernels would probably trip right away

Which is fair

[loud ice]

is it?

[fiery turtle]

Deadlocking as a feature is very cursed

[loud ice]

its not deadlocking, though

you are just (mis)using the mutex as a different kind of concurrency primitive

[fiery turtle]

Yes but as far as the kernel can see, its the same thread doing two acquires of a non recursive mutex

[loud ice]

yeah because you transferred the first acquisition to a different thread

[fiery turtle]

Anyway yeah that could work (although I kinda hate it), but aml needs event objects anyway so I just conveniently reused the api

[loud ice]

fair enough

[fiery turtle]

Such big brain idea I didnt get it at first

[loud ice]

yeah you are not embodying the firmware dev energy infy

[fiery turtle]

Some kernels rely on mutexes being released in the same thread as they were acquired too

[loud ice]

uacpi's api contract doesn't mandate that though

although it very much should tbh

[fiery turtle]

Yeah

[vagrant hull]

is there anything that needs to be done to "enter ACPI mode"

or is initialize/load_namespace enough?

and then you just call the API on demand?

[mortal yoke]

uacpi already does that in uacpi_initialize

[vagrant hull]

does it do it even if your things to install irq handlers are stubs? :^)

[mortal yoke]

it doesn't require irqs

[fiery turtle]

How would it know

[vagrant hull]

i mean

they return unimplemented or whatever

[fiery turtle]

If they do then it just aborts init entirely

Because its kinda unsafe to use acpi mode and not handle scis

[vagrant hull]

so it won't be able to enter S5 later on if asked to?

or other things?

[fiery turtle]

Just lie to it and say OK

[vagrant hull]

nvm we already lie and say OK

great lol

[fiery turtle]

Then yeah everything will work

[fiery turtle]

Ironclad doesn't have a way to install irqs or just to-do for now?

[flat badge]

can i use uacpi only to access the tables? or do i have to implement all helpers just for this purpose?

[vagrant hull]

i guess it's a to-do

[fiery turtle]

Yeah ofc

Early table access mode only needs map and unmap

[gentle peak]

there's early table access which only uses map and log, and iirc there's a table only #define, though idk if that's a wip or not

[fiery turtle]

The bare bones only mode is a planned feature yeah

[flat badge]

I want to access tables from eir (Managarm's prekernel) to know the number of CPUs before the kernel starts

[gentle peak]

for now I guess just use early table access without doing the full init and --gc-sections will take care of dce

and in the future switch to bare bones mode

but honestly if you're just accessing tables without doing anything else I'd just use a custom ACPI impl, table access is like 150 loc

[fiery turtle]

Yeah early table access will work just fine in that case

If you do what monkuous told you that will strip all unused code too

[flat badge]

is there some #define or similar to compile out the other OS APIs or do I have to rely on --gc-sections?

[fiery turtle]

UACPI_BARE_BONES_MODE is a planned feature

so not atm

[flat badge]

[fiery turtle]

yeah it turns out to be a relatively demanded feature, for e.g. microkernels with acpi in userspace, but still tables in kernel, or reactos where they need multiple acpi implementations, one core and one in acpi.sys etc

so its definitely higher prio

although after 1.0

[flat badge]

yea understandable 😄 --gc-sections is probably fine for now

[fiery turtle]

yeah it should be able to strip out most code i think

[hollow elm]

just build with lto and -fvisibility=hidden

[strong heath]

When do you plan on releasing 1.0?

[fiery turtle]

this week

[strong heath]

Neat

[fiery turtle]

i already have this working locally

but it will be a part of the large 1.0 PR

[strong heath]

Neato

[frank canopy]

why am i looking at this and just thinking ok i think i can automatically generate these with zig comptime lmao

im pretty sure thats possible but i cant be bothered to try it until the PR is merged

[fiery turtle]

damn

[frank canopy]

correction, its not a think i know i can

idk if its cleaner or messier than what ive got now on the old bit_width api but it will work

[left orbit]

oh i almost forgot, hows your zig journey infy?

[fiery turtle]

down the procrastination pipeline next to my future kernel

[left orbit]

damn that uacpi 1.0 thing really set things back

[fiery turtle]

lol

nah i think its cs2 and minecraft that did

and work

ive been looking at some zig streams tho

[vale isle]

hmm i should write some of my userland in zig (when i have a userland

but I'm happy with rust in my kernel

[fiery turtle]

yeah thats what i wanted to do as well

try doing some zig programming in userland

[vale isle]

i want to have my native and flagship os APIs in rust first and then maybe C++, go, zig idk whatever i touch

[fiery turtle]

go is pretty nice also

[vale isle]

i wouldn't use it in a kernel :3

but it was fun when I used it for like a 2k LOC project

but I already forgot how to write go

[calm latch]

I just use pthread_cond and pthread_mutex...

[fiery turtle]

im not sure how that would work, since its garbage collected

[frank canopy]

reminds me that i want to restructure how my wait code works since its a bit of a mess rn and i dont entirely trust it

[loud ice]

GC in kernel?

[fiery turtle]

letsgo

[calm latch]

Isn't the whole point of a microkernel is that you can use it in userspace and not give a shit about GC/runtime?

like for device drivers

I think its concurrency model should be really nice for a lot of things

[flat badge]

well, C++ and Rust now also have async

[calm latch]

but it requires explicit scheduling activations

[loud ice]

C++ async requires tons of allocations

[calm latch]

or whatever its called

[calm latch]

not like Go doesn't

[loud ice]

a rust-style system requires function coloring

[loud ice]

yeah it doesnt

they need significantly less of them

[calm latch]

huh

[loud ice]

since each function doesnt cause a gc alloc

the stack is just reallocated when it gets filled up

please do not think about how that works

[calm latch]

[loud ice]

rust async doesnt require as many sometimes usually but it has horrible degenerate cases

i.e. any recursion

that's a problem of all stackless systems

[calm latch]

but C++ supposedly also optimizes a lot of allocations away

[flat badge]

C++ and rust require the same number of allocations, more or less

[loud ice]

C++ requires strictly more

because rust can coalesce them in many cases

also its explicit in rust which is cool

[flat badge]

i don't think that's true

yes, it's more explicit in Rust

[calm latch]

you can also overload operator new in C++

[loud ice]

rust requires the absolute minimum allocations required for a stackless system

[flat badge]

maybe some future C++ will add non-erased coroutine types

[loud ice]

that would be cool but im not holding my breath

stackful systems are better anyway imo

[flat badge]

but anyway, this is a non-issue. in practice both C++ and Rust use roughly the same number of allocations

[calm latch]

anyway, C coroutines are the most fun

[flat badge]

it is true that Rust doesn't do type erasure

[loud ice]

does C++ coalesce them?

[loud ice]

*implicit type erasure

[flat badge]

the C++ compiler is allowed to coalesce them, yes

[loud ice]

ah cool

[flat badge]

in C++ it's an optimization while in Rust it's a language feature

[loud ice]

as an optimization

yeah

i would uh

not hold my breath

[flat badge]

but in reality, the case that C++ cannot optimize is exactly the case where Rust's model doesn't help, namely when you do a virtual call

[loud ice]

but yeah C++ requires at least one allocation more in every case

[loud ice]

C++ cannot optimize cross-TU too?

[gentle peak]

LTO :)

[loud ice]

since the scheduler allocation must be separate from the coroutine state

[loud ice]

apart from being a layering violation

[flat badge]

for example when you put a callback into a "wake me up when X happens" data structure

[loud ice]

true

[flat badge]

this requires an allocation both in Rust and in C++

[loud ice]

yeye

it does

this is why stackful systems are better

[flat badge]

stackful systems are sometimes better

that's true

but they are harder to scale

[loud ice]

they have one critical advantage though

[calm latch]

why

[loud ice]

they are way way way easier to implement

[flat badge]

or rather, they require some a priori knowledge about how often an operation will be called etc

[loud ice]

in rust, it's required due to aliasing rules

[loud ice]

and way way easier to work with

so yeah

[calm latch]

but in c++ you can also put that in coroutine state

[loud ice]

they also avoid function coloring

i think that the way forward is very much stackful coros fwiw

[flat badge]

not really, you still need to know whether a function blocks a green thread or an OS level thread

[loud ice]

no go function can block an os thread

only c functions can

and those are run on a threadpool

[calm latch]

[loud ice]

and yeah its a bad solution for performance

but if you are writing pure go, it is acceptable

[flat badge]

how portable is go to new OSes?

[calm latch]

I've ported libgo

[loud ice]

depthos has it?

i think

[calm latch]

Kinda

[loud ice]

i think its pretty good

[calm latch]

It works half the time

[loud ice]

you have the bad go compiler tho

not the good one

(the good one == the maximally nih one)

[calm latch]

I haven't found how to port the good one

[loud ice]

they have windows, a bunch of unixes, plan 9

[loud ice]

you add your os to the list

you compile a hello world for it

then you fix every error that comes up until its working

[calm latch]

but there are no instricions (or I didn't search well enough)

to know which list to put it in

[calm latch]

but I didn't know about that

Like I'm considering using Go for drivers, but I wasn't certain how that would work with blocking C syscalls

[loud ice]

the answer is that it would work poorly, and you should write nonblocking go assembly wrappers for them anyway

[vale isle]

the solution to function coloring is to color them all the same colour

[loud ice]

in a stackless system, that is another way of saying is "kill performance"

[vale isle]

i just solved racism

no i didn't lol

[vale isle]

i was trying to make a joke dw

[flat badge]

how would that work considering that go has no inline asm (?)

[left orbit]

im pretty sure you can link against manually built objects

so just use nasm/gcc to build separate assembly source files

[loud ice]

not inline asm

[loud ice]

eeeh i dont think that works, or works well at least

[loud ice]

they have external out-of-line asm support

[left orbit]

it works as well as their shitty assembly thing

[fiery turtle]

largest uACPI AML test case with 400 loc of ASL lol

it tests basically every single esoteric opregion type

38 commits

With this, I think the 1.0 PR is done, now it's review and testing time

[north holly]

[kind mantle]

[vagrant hull]

does this change any of the kernel API beyond the portio stuff?

compared to like, anytime recently i guess

[fiery turtle]

Nope

[rustic compass]

Time for win11 + clang to break any new internal macro

[fiery turtle]

lol

i dont think i added anything crazy like that (hopefully)

[dense steppe]

I'll be away from osdev during the weekend. Will the 1.0PR be done before I'm back?

[fiery turtle]

its basically done so yes

[north holly]

time to update my uacpi

[fiery turtle]

please do test

like everything

[north holly]

will do

[fiery turtle]

thanks!

@calm latch if u can test as well id appreciate it

[calm latch]

ok

Give me 1 hour

[dense steppe]

[fiery turtle]

lessgo

[dense steppe]

(that's maybe too many )

(except there's no such thing as too many )

()

[north holly]

[dense steppe]

you gotta do like a countdown before you merge it into main

like a specific time

2025-01-25T20:00:00

or something

[dense steppe]

(completely random example time here, nothing to think about)

[torpid root]

[north holly]

@fiery turtle

/home/oberrow/Code/obos-uacpi/dependencies/uACPI/source/registers.c:156:13: error: implicit declaration of function 'uacpi_atomic_load8' [-Wimplicit-function-declaration]
  156 |     state = uacpi_atomic_load8(&mapping->states[0]);

[fiery turtle]

it does compile on CI

make sure u pulled everything

[north holly]

I am on https://github.com/uACPI/uACPI/commit/f7a3278d49a9923cb2a17364aa67c4b563c17d33

also this is -Werror

[fiery turtle]

my builds are also werror

[north holly]

I'm on gcc 14.2.0

[fiery turtle]

do u have a custom arch header?

[north holly]

uh idk probably

idr

[fiery turtle]

does it have atomic load 8?

[north holly]

uh no

[fiery turtle]

ill help u out in a sec

lemme finish my cs2 game

[north holly]

ok I think I need to:

#include <uacpi/platform/atomic.h>

[fiery turtle]

i think we hit this same issue before

it was due to some header that leaks into other but not in your build

[calm latch]

(laptops' chargers have been found)

[north holly]

time to painfully separate the PCI and port io kernel api

into the per-byte functions

[fiery turtle]

lol

[frank canopy]

well this worked perfectly :D

split not bad at all tbh

[fiery turtle]

damn

[fiery turtle]

i've just pushed an update, pls pull

[dense steppe]

I should take the time to learn some other language like zig tbh

it seems pretty cool

[fiery turtle]

ikr

❯ cloc --vcs=git .
     145 text files.
     145 unique files.
      69 files ignored.

github.com/AlDanial/cloc v 1.90  T=2.69 s (29.0 files/s, 13559.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               19           3898            928          17830
C/C++ Header                    46           1111           1566           5656
C++                              4            502            516           2972
Python                           3            228             40            629
Markdown                         1             74              0            233
CMake                            3             28             14            132
YAML                             1             10              5             57
Meson                            1              2              0             23
-------------------------------------------------------------------------------
SUM:                            78           5853           3069          27532
-------------------------------------------------------------------------------

bruh almost 30k 💀

[north holly]

bruh

[fiery turtle]

wdym bruh, its literally a fix for your compile error lmfao

[north holly]

I see update copyright year

unless ur on master

[fiery turtle]

did u think i was gonna put a commit on top

i can fixup changes into existing commits

[north holly]

https://github.com/uACPI/uACPI/commit/63ab369748db5764b59a728f54da0d7e5390f407

[fiery turtle]

63ab369748db5764b59a728f54da0d7e5390f407 is the latest

[north holly]

I don't see how that fixes the compiler error...

[fiery turtle]

oberrow

u know how u can rewrite git history?

i can go back to the exact commit that broke the compilation and make a fix in it

without introducing an extra commit

[north holly]

o

[fiery turtle]

this is what i did

[dense steppe]

that is evil

[fiery turtle]

if this was master, yes

[dense steppe]

still evil, just less so.

[north holly]

git rebase

or smth

[fiery turtle]

its literally

git add -p
git commit -m "fixup! <commit-that-broke-shit>"
git rebase -i HEAD~N --autosquash
git push -f

[kind mantle]

Rebase'd

[north holly]

I couldn't be bothered to actually split the functions

[frank canopy]

amateur git history rewriting tbh. i once rewrote all of history to change one committer's name in every commit of every branch going back to the beginning retroactively

[north holly]

which is why I will just make it call into the function

that has the byte width passed

[fiery turtle]

just make it a macro

macro function template

[north holly]

bah

[frank canopy]

zig is nice, lets me not rewrite the functions and just use a comptime loop to do generic instantiation of all them and export them

[dusky glade]

me after giving everyone brain damage

[frank canopy]

kinda like the macro idea tbh

[north holly]

haven't looked in nyaux code

so I'm fine

[fiery turtle]

this is what i did in my test-runner.cpp

#define UACPI_IO_READ(bits)                                              \
    uacpi_status uacpi_kernel_io_read##bits(                             \
        uacpi_handle handle, uacpi_size offset, uacpi_u##bits *out_value \
    )                                                                    \
    {                                                                    \
        auto addr = (uacpi_io_addr)handle + offset;                      \
                                                                         \
        if (io_space && addr <= UINT16_MAX) {                            \
            memcpy(out_value, &io_space[addr], bits / 8);                \
        } else {                                                         \
            *out_value = (uacpi_u##bits)0xFFFFFFFFFFFFFFFF;              \
        }                                                                \
                                                                         \
        return UACPI_STATUS_OK;                                          \
    }

#define UACPI_IO_WRITE(bits)                                           \
    uacpi_status uacpi_kernel_io_write##bits(                          \
        uacpi_handle handle, uacpi_size offset, uacpi_u##bits in_value \
    )                                                                  \
    {                                                                  \
        auto addr = (uacpi_io_addr)handle + offset;                    \
                                                                       \
        if (io_space && addr <= UINT16_MAX)                            \
            memcpy(&io_space[addr], &in_value, bits / 8);              \
                                                                       \
        return UACPI_STATUS_OK;                                        \
    }

[dusky glade]

nyaux code jumpscare

nyaux code jumpscare

[north holly]

xdnbvdsjkfW

[dusky glade]

get

brain damaged

[frank canopy]

the code it generates is way bigger than i expected for the io ones but turns out thats because im building releasesafe so theres a bunch of safety checks branching to panic still in there

[fiery turtle]

what sort of checks are there to do?

[dusky glade]

who wants my 3.1 volt circle battery that i stole from my old remote

[frank canopy]

integer overflow turning base + offset into a u16 port

[dusky glade]

very useful for uacpi

trust

[fiery turtle]

just use an overflowing add or something

[frank canopy]

its the @intCast that generates it

not a huge deal either way

[fiery turtle]

go update uacpi in nyaux NOW 😡

[dusky glade]

oh ok

[fiery turtle]

yea

[north holly]

finally built!

[fiery turtle]

@north holly btw your gas stuff for EC can now be premapped

[frank canopy]

i could use truncate instead to avoid the checks but that generates extra code on no-safety-checks modes whereas the intcast just gets elided

[fiery turtle]

makes sense

[north holly]

inb4 doesn't boot

yay it boots

[fiery turtle]

shutdown/reset/suspend etc

[north holly]

yeye

[fiery turtle]

and EC stuff

[frank canopy]

i cant actually test this still since i havent finished my new page allocator yet and therefore have no allocaor lmao

[fiery turtle]

obos and pmos are probably the largest uacpi api users so its fine if they both test

[dense steppe]

wtf even is this?? store immediate 176 into rdx and jump (??) to memcpy.

[fiery turtle]

like that would give me enough confidence

[dense steppe]

ahh

because rdx is third arg and I assume 176 is the size of the context

[frank canopy]

im pretty sure this new per-size functions thing actually reduces line count for me btw, since i dont need to repeat the switch on each function and can just generic instantiate them instead

[north holly]

testing suspend

[  LOG  ] oboskrnl: Suspend requested
[ WARN  ] Note: Framebuffer might die
[  LOG  ] oboskrnl: Woke up from suspend.```

wooo

[fiery turtle]

lesgo

[dense steppe]

[north holly]

shutdown works

[fiery turtle]

try reset too

[north holly]

reboots

time to test on real hardware

[torpid root]

based

[fiery turtle]

inb4 blows up on real hw

because of an obos regression

[torpid root]

blows up on the real hw

[north holly]

obos regression #1000000

(of the day)

[fiery turtle]

lol

obos should introduce a permanent feature freeze in order to not regress

[sterile egret]

Epic

[kind mantle]

Who needs testing anyway

[north holly]

- famous last words of @kind mantle

    OBOS_Suspend();
    OBOS_Shutdown();```
my real hardware test case will be this

[dense steppe]

just waiting for the 'success' message. I'm ready with lots of in the clipboard

[kind mantle]

News headline next day: @kind mantle found assasinated

[fiery turtle]

looks like this shit is finally going to be removed soon

[north holly]

Ah God damn it obos regression

Bug in the r8168

[fiery turtle]

bruh

[north holly]

*r8169 driver

[fiery turtle]

what happens?

[north holly]

Invalid value load

[dense steppe]

compile it without r8169 then

and fix it later

[hollow elm]

r8168 is a variant of the r8169 so not too far off

[north holly]

At line 277 of device.c

[north holly]

Ye

[fiery turtle]

btw did u figure out why 8169 was breaking on wake

[north holly]

I'm sure that bug is fixed in the network stack

[north holly]

It wasn't

It was a bug with the transmit code

[fiery turtle]

what was it?

[north holly]

I forgor

[dense steppe]

yea, there are lots of realtek cards that use an r8169-like interface. iirc I have RTL8125A or smth on my desktop. (@north holly maybe I can setup some cursed passthrough stuff to help you debug your r8169.)

[north holly]

I have r8169 in my laptop

but it would be interesting to see if it even works on other laptops

[dense steppe]

are there any quirks for specific r8169 cards that one needs to be aware of when writing an r8169 driver?

[north holly]

/cards

[north holly]

idk I'm not linux

[dense steppe]

it's not a laptop.

[north holly]

yeah

[dense steppe]

yea lol

[north holly]

I meant NIC

btw never be brain damaged and forget to set the END_OF_RING bit on the last descriptor

of your Rx/Tx rings

otherwise the r8169 kind of just dies

[dense steppe]

I will study the available documentation very carefully (and maybe first do virtio) before trying to implement a r8169 driver.

anyways that is far into the future

[north holly]

r8169 is actually real easy*
*my driver only works on one piece of hardware that I know of

[dense steppe]

... still waiting for this

[north holly]

rebooting now

[fiery turtle]

are u going to test multiple pcs?

[north holly]

I'll test as much as possible

[fiery turtle]

nice

this reminds me i should update managarm's and proxima's score on the lb before merge

[hollow elm]

there's a whole bunch of different mac versions that require different behavior in places afaik

[north holly]

I remember seeing that in linuz

*linux

[dense steppe]

and the "documentation" for that is Linux?

[north holly]

Uh pretty much

[hollow elm]

most of the driver is the same, afaics it's just around init mostly

[fiery turtle]

is that the same driver that needs an array of proprietary random register -> value pairs that u must write for the nic to work

[north holly]

No

[hollow elm]

no that was some wifi nic

also a realtek one i think

[fiery turtle]

iirc rtl has that

[north holly]

God damn it

[fiery turtle]

maybe

[north holly]

Nullptr access

[hollow elm]

i think it was in the driver for the wifi nic in my laptop?

[north holly]

Brb

[north holly]

In obos code

[fiery turtle]

nah some serenity os driver has it

they definitely dont have wifi

[north holly]

It's serenity

[fiery turtle]

not another obos regression ☠️

[north holly]

For all we know the registers are well defined

[north holly]

I swear this booted 1 hour ago

When I merged the RTC code

Magically elves in my laptop

[dense steppe]

yeah I'm thinking it is probably possible to keep a table associating vendor/device pairs with a 'quirk flags'/bitmask

like R8169_QUIRK_DO_X_THING_DURING_INIT

[hollow elm]

well for the mac revision you need to figure that out based on device regs, not pci vid:pid

[dense steppe]

sure

[hollow elm]

https://github.com/SerenityOS/serenity/blob/master/Kernel/Net/Realtek/RTL8168NetworkAdapter.cpp#L711-L816 lol

[dense steppe]

but still basically the same thing

the sane thing

[fiery turtle]

what the actual

[hollow elm]

they do also have arrays of reg -> value in the driver

[hollow elm]

wtf is the serenity code style btw

one line: ```c
auto region = MM.allocate_contiguous_kernel_region(Memory::page_round_up(RX_BUFFER_SIZE).release_value_but_fixme_should_propagate_errors(), "RTL8168 RX buffer"sv, Memory::Region::Access::ReadWrite).release_value();

[north holly]

Wtf

[dense steppe]

probably awesomekling taking inspiration from the coding style of some GUI toolkit or browser

[fiery turtle]

[north holly]

R8168 is like the same thing I target

I don't do that.

[dense steppe]

btw hasn't ak been in this discord?

[fiery turtle]

dont think so and hes not doing serenity anymore

[hollow elm]

i mean please put in a line break this single line is 215 characters long

[dense steppe]

yeah

[hollow elm]

yeah afaik he's only doing ladybird now

[fiery turtle]

he resigned so ye

[dense steppe]

personally I steal a page from Linux's book and have 80 char width lines as a guideline, with exceptions for printk and where else reasonable.

[fiery turtle]

same

[dense steppe]

not documented anywhere. it's just something I do automatically nowadays lol. like a sense for when a line of code is more than 80 characters

I should get uACPI ported to my kernel.
then I can finally call myself a 'real' kernel

[fiery turtle]

if u do it fast enough i can put u on the leaderboard before 1.0 merge

[dense steppe]

sorry, no can do. (unless you delay 1.0 by like four days)

[fiery turtle]

lol

no worries there will be other readme updates later on

[dense steppe]

I will be busy with a local competitive programming competition this weekend (lots of fun activities + competition sunday morning), so not much time for osdev

[fiery turtle]

good luck!

[dense steppe]

actually maybe tomorrow after school, I might be able to speedrun a uACPI port by stubbing IRQ handling etc

[fiery turtle]

yeah u can port it in like a few hours

[dense steppe]

but most likely no

don't wait for me to port it before you merge 1.0 lol

[fiery turtle]

i speedran astral port in 2 hours knowing nothing about the code base

[fiery turtle]

dw i wont lol

[dense steppe]

only wait for @north holly to confirm that it works on real hardware

[fiery turtle]

ill do a final review pass tomorrow

wont merge today anyway

[dense steppe]

by just stubbing the IRQ stuff (I don't do IOAPIC yet lol, as there are no device drivers that use it) and replacing my own early ACPI table code with uACPI's early table support, I can probably get it done in like 15min lol (but it won't work, other than initializing the namespace lol)

[sterile egret]

He joined once for like…a few days. I think it was 4-5 years ago.

[fiery turtle]

Thats enough to get a score tbh

[dense steppe]

I might have done it by like 17:00 UTC+1 then lol

it's a race against the clock

[fiery turtle]

Lesgo

[dense steppe]

still waiting for this btw

[fiery turtle]

I think this was paused because of obos segfault

[dense steppe]

sadge

I'll just obnoxiously spam when 1.0 is merged then lol

[fiery turtle]

Lol

[dense steppe]

that's why you gotta do a countdown

[dense steppe]

(except there's a risk I'm at this)

[fiery turtle]

The release happens once I push the 1.0.0 tag, not merge tbh

Then its official

[dense steppe]

now I'm scared I'll get like 10k ops/s and be sad lol

[fiery turtle]

Nah even nyaux gets a million

[dense steppe]

but Linux mmap(MAP_POPULATE) for like one gigabyte is like 20ms and my kernel is very close to that

so it should be good

[fiery turtle]

How fast is your slab allocator

[dense steppe]

idk

haven't measured

[fiery turtle]

Monkuous gets 150ns/allocation

[dense steppe]

O(1) in theory

but that's complexity

perf is more complex than that

[north holly]

Ok my bug isn't too bad

Just need to not dereference the null pointer

[fiery turtle]

True

[hallow marten]

damn good luck

are you like high school level

like IOI quals

[dense steppe]

The main overhead to my generic kmalloc which takes in a size (slab_alloc takes in a preinitialized struct slab) is probably finding the correct struct slab to call slab_alloc with

[hallow marten]

or rather the qualifier to the qualifier to the qualifier

[dense steppe]

nah this is PO (progolymp.se), Swedish thing

[sterile egret]

https://youtu.be/bLHL75H_VEM

[hallow marten]

well yea but does it lead to IOI eventually

[dense steppe]

although I guess it is some kind of qual for IOI

yeah

[hallow marten]

every country has some kind of organization

here you do CCC (canadian computing contest) -> CCO (... olympiad) -> IOI

[dense steppe]

but I don't belong in IOI lol. so many cursed things like segtrees I don't know about

[hallow marten]

yea most are math cracks that do this kind of stuff 24/7

I doubt there's that much usefulness to it though

I mean it's good problem solving

[dense steppe]

although I am kind of a math crack (except I only do math 23/7)

[hallow marten]

ah cool

idk much math outside school, I'm doing calc 2 right now

[hallow marten]

but yeah about this, this isnt just about allocation speed too, there's cache to account for and all that kinda stuff

[north holly]

It suspended...

[fiery turtle]

Yeah

[north holly]

And it woke from suspend

And shut down

[fiery turtle]

Letsgo

[north holly]

As the test does

[hallow marten]

I'm eager to beat you all with uacpi benchmark btw

[fiery turtle]

[sterile egret]

I’m just eager to have a good solution for ACPI now

[north holly]

I will be testing EC events

[fiery turtle]

@north holly other subjects too?

[north holly]

Now

[north holly]

I will test my main pc

[dense steppe]

discord skill issue lol. cannot paste that many

[fiery turtle]

Oh yeah

[hallow marten]

my allocator is op

you are not ready.

(I'm totally overhyping it)

[dense steppe]

I gotta solve this tbh

[hallow marten]

(but its better than 99% of allocators here im 60% sure)

[fiery turtle]

Is it really that good

[sterile egret]

Probably true

[fiery turtle]

What algo does it utilize

[hallow marten]

it's slab

but multi cpu

[dense steppe]

I will probably implement some kind of per-CPU object caching in kmalloc()

[hallow marten]

it's roughly roughly similar to solaris's modern slab allocator

it's like 75% of it

[dense steppe]

won't do it in slab for the time being, as it would require dynamic cpulocal variable allocation, which is annoying™️

[hallow marten]

no

it doesnt

[dense steppe]

(dynamic cpulocal allocation can be solved by just reserving some amount of memory lol. but I'm lazy)

[hallow marten]

the per-cpu caches are stored in the kmem_cache structs

[dense steppe]

the way I plan on doing it does

[hallow marten]

in the slab "zones" (they're called caches because object caching)

[hallow marten]

and that I just use a switch statement

I have a few power-of-two slabs preallocated

and I just switch on the size in kmalloc

or rather an if statement

[dense steppe]

it's literally just a struct pcpu_slab_list_whatever [NUM_CPUS]; indexed by this_cpu_id()?

[hallow marten]

yes

essentially

[dense steppe]

tbh I should do some cursed __builtin_constant_p stuff to optimise slab selection

:P

[hallow marten]

and that's per cache

cache as in slab zone again

[dense steppe]

yeah

[hallow marten]

(I know it's confusing)

[north holly]

Ah shit

Ah nvm

[dense steppe]

not really tbh. it's just that I use slightly different terminology

[north holly]

Could have sworn I changed that

[hallow marten]

what solaris does and what I dont do is dynamic magazine sizes (per-cpu caches are refilled on a magazine-basis, like a gun)

so the allocator self-adapts itself during runtime to have optimal magazine size

by mesuring lock contention and stuff

meanwhile i just have fixed values but that's still better than most hobby OSs

[dense steppe]

on terminology: for me, a struct slab * is an opaque handle passed to the slab allocator to allocate memory of some fixed size

basically it is used instead of size in kmalloc

similar to linux kmem_cache I guess

[hallow marten]

the real terminology is:

• a cache works in slabs and has also a freelist for cached constructed objects
• slabs are allocated when a cache needs refilling, they contain memory for the objects

it's not linux stuff, it's solaris stuff

linux stole it from there

[fiery turtle]

Do u have struct page?

[dense steppe]

I might 'dial a friend' -- get some help by my constand factor optimisation enjoyer friends from the competitive programming circle with optimising my kernel lol

[dense steppe]

yes. but I call it struct pfn_entry for some reason lol

[frank canopy]

windows naming conventions moment

[dense steppe]

anything for that #1 spot

[frank canopy]

pfn is what windows calls it

[hallow marten]

I don't currently, but yea I will call it pfn too or something

[dense steppe]

nah... that would be PPFNENTRY (not a typo)

[fiery turtle]

Slab lookup might be slower without one

[frank canopy]

i call mine pfm because page frame number is a bad name for a struct lol

[north holly]

@fiery turtle EC worked

[hallow marten]

how lol

[frank canopy]

PMMPFN is the type

[north holly]

*works

[fiery turtle]

[hallow marten]

the P might be for private?

[dense steppe]

[dense steppe]

no, pointer

[fiery turtle]

Or maybe not idk

[frank canopy]

the first P is for pointer

[dense steppe]

as in PCSTR and friends

[dusky glade]

im sleepyyy

[north holly]

Sleep

[frank canopy]

everything is defined as ```
typedef struct _THING {
...
} THING, *PTHING

[dense steppe]

so get some sleep.

[frank canopy]

in windows

[hallow marten]

nah the slab is on another layer from raw pages

[frank canopy]

but yeah struct page = MMPFN basically

[hallow marten]

on solaris it uses vmem as a backing

so

[dusky glade]

im so happy cause nyaux works now

i should sleep

but before i sleep

i jsut wanna say

[north holly]

Yes sleep

[dense steppe]

yeah. well I've heard nowadays this is only the user-visible API. internally it is saner

[dusky glade]

wux is the goat

[frank canopy]

that i wouldnt know

[hallow marten]

the reason why I dont have a pfndb yet is because I was too lazy to figure out how to make it contiguous

[dusky glade]

bro found out the bug i was trying to debug for weeks in a few hours

anyways

sleepy time nightnight

[dense steppe]

i think funny hyena man or the other will wrote about it sometime quite recently

[frank canopy]

wdym contiguous? what reactos (and i in imaginarium) use is to have a bitmap where if the bit is set the PFN is valid and you just map whichever PFNdb regions have normally-usable pages in them

[hallow marten]

so it can be accessed as an array

[frank canopy]

yeah what i do works for that

[dense steppe]

a virtually-contiguous pfndb is quite nice

[hallow marten]

you have kind of a chicken-egg problem where you need pages to map memory but to get the pages you need the pfndb

so you need to setup a bump allocator in the memory map

[dense steppe]

that's what initmem is for

[frank canopy]

yeah

[dense steppe]

(initmem is an overcomplicated initmeme in my kernel)

[frank canopy]

the bump-allocator-in-memory-map is what i do with limine hhdm keeping it mapped

and then once page tables are up i swap to that from the hhdm

[north holly]

rebooting into obos on the other test subject rn

[hallow marten]

what is that

[hallow marten]

wdym?

[frank canopy]

where im at rn is i have it all initialized, both pfmdb (i use m for metadata instead of n for number) and tables, and then just dont have any way to allocate virtual memory

[north holly]

oberrow@AcerAIO:~/Code/obos/scripts$ uptime 
 19:15:01 up 9 days,  1:02,  2 users,  load average: 6.25, 6.12, 5.99

[dense steppe]

wdym bitmap? so code can test has_pfndb_entry(physical address)? isn't that implied by how it got physical address?

[north holly]

uptime before reboot

[frank canopy]

i pick the memory map entry with the most usable mem and just increment the base and decrement size when i need a new phys page

[frank canopy]

mmio wouldnt have an entry but might be mapped

[hallow marten]

yea but what's the hhdm thing

would mmio even have a pfn entry

why would you search for it

[frank canopy]

for refcounting reasons when temp-mapping normal pages is what i use it for

[north holly]

Ah shit

Obos regression

It kinda just hangs

[frank canopy]

hhdm is each usable phys addr is accessible at phys addr + constant offset

[north holly]

After telling me I have no EC

[hallow marten]

yeah I know that

[dense steppe]

shameless self plug: https://github.com/dbstream/davix/blob/main/mm/initmem.c iirc (pls no advertising ban. he clearly asked for it)

(I may have gotten the link wrong as I typed it manually on my phone)

[hallow marten]

" what i do with limine hhdm keeping it mapped.

[fiery turtle]

[frank canopy]

so if i have the page number i allocated from the memmap i can just access it from that

[north holly]

I have shilled obos way too many times

[frank canopy]

until i get my own page tables created

[hallow marten]

yes... but why are you using a bump allocator for that

[north holly]

And haven't gotten an advertisement ban

[hallow marten]

I think you may have worded it weirdly and that confuses me

[frank canopy]

idk if bump is the right word tbh, but its just a quick and easy way to get a known-free physical page before i have the pfmdb set up

[hallow marten]

yeah I think I get what you're saying now

[frank canopy]

the pfmdb is the last part of my mm bootstrapping

[hallow marten]

that was also what I was going to do

[hallow marten]

it's gonna be my first

[dense steppe]

I did get the link incorrect lol. https://github.com/dbstream/davix/blob/master/mm/initmem.c

[hallow marten]

probably

[dense steppe]

wrong branch

huh. I thought I did git branch -m main...

[hallow marten]

so you free it all back on exit?

[dense steppe]

to the normal page allocator, yes.

[hallow marten]

how do you keep the pfndb mapped

then

without overwriting

[dense steppe]

initmem doesn't use the pfndb

initmem additionally doesn't use any memory it hasn't been told by arch is mapped

[hallow marten]

yea but the pfndb uses initmem to allocate the page tables

[dense steppe]

yes

that's no problem

[hallow marten]

so freeing those pages would overwrite the pagetables

[dense steppe]

it iterates over the free regions

basically there are two arrays:

• memory ranges.

• reserved ranges.

[north holly]

    OBOS_InitWakeGPEs();
    OBOS_ECSetGPEs();

    uacpi_install_notify_handler(uacpi_namespace_root(), default_notify, nullptr);

    uacpi_finalize_gpe_initialization();```
hmm so it hangs somewhere here

[dense steppe]

it iterates over memory ranges and reserved ranges simultaneously (that was hard to implement lol) and only frees that which is not reserved

initmem_alloc_* functions mark the allocated memory range as reserved

[hallow marten]

• Iterate over memory regions which are free (i.e. regions in initmem_usable
• that are not INITMEM_DONT_ALLOCATE_MASK and which don't overlap with
• initmem_reserved). Returns true for each new entry, false when finished.

ah nvm

so you only free the free pages

that makes sense lol

that is, the memory that wasnt used to allocate the db and stuff

[dense steppe]

anyway I'm quite happy with initmem. It basically multiplexes as my kernel's early internal representation of the physical memory map and a very flexible early memory allocator.

if you have other inquiries about the davix (trademark pending) kernel, please lift them in the #1326937732122935379 thread so it doesn't appear dead

[fiery turtle]

Lol

[fiery turtle]

[north holly]

Uacpi debug logs enabled

[fiery turtle]

Maybe add prints to track it down

Like which specific call

[north holly]

It hung after a return op

So probably after evaluating a method

[fiery turtle]

Ye

[north holly]

it's in OBOS_InitWakeGPEs

as this machine has no EC

so OBOS_ECSetGPEs can't really hang if it does nothing

the next two calls are from uacpi

[fiery turtle]

What does it do

[north holly]

and uacpi is infalliable

[north holly]

finds GPEs that are wake-capable

then registers them for wake

[fiery turtle]

Not another regression

[north holly]

but only calls uacpi_setup_gpe_for_wake

[fiery turtle]

Can u add prints there too

[north holly]

I actually think I found this bug a long time ago

but never bothered with it

[fiery turtle]

This code wasn't touched at all by this pr btw

[north holly]

yeah

[fiery turtle]

Is that the one that's fixed by a reboot

[dense steppe]

never don't avoid not testing your code on twenty different machines after every single nontrivial commit (or series of commits)

[north holly]

never don't avoid

[fiery turtle]

Ig you could add more prints to see where it hangs exactly

[north holly]

yeah doing that rn

[fiery turtle]

Nice

[north holly]

it probably hangs in OBOS_DeviceGetDStateForWake

which is called by OBOS_DeviceMakeWakeCapable

which is called by OBOS_InitWakeGPEs

eventually

most of this is simple code

[dense steppe]

the only problem is, what is trivial and what is non-trivial?

[north holly]

which only calls into uacpi stuff

[hallow marten]

this sentence is making me have a brain fart

[north holly]

fr

but there is a loop in OBOS_DeviceGetDStateForWake

[dense steppe]

oh I can give you some long complicated sentences

maybe an English equivalent of the most vexxing parse

although it is hard to type on a phone without making lots of spelling mistakes lol

[north holly]

mmm the last line the kernel is seen at is line 301 of power/device.c

after evaluating an integer in _PRW

    char path_d[5] = { '_', 'S', '0' + state, 'D', '\0' };
    char path_w[5] = { '_', 'S', '0' + state, 'W', '\0' };

    uint64_t snd = eval_integer_node(dev, path_d);
    uint64_t snw = eval_integer_node(dev, path_w);

    d_state val = DSTATE_INVALID;

    if (snd == UINT64_MAX && snw == UINT64_MAX)
    {
        if (status)
            *status = OBOS_STATUS_SUCCESS;
        return DSTATE_INVALID;
    }
    if ((snd != UINT64_MAX && snw != UINT64_MAX) && snw >= snd)
    {
        if (status)
            *status = OBOS_STATUS_MISMATCH;
        return DSTATE_INVALID;
    }```

which means it either hangs here, or returns here

and hangs in the caller

static uint64_t eval_integer_node(uacpi_namespace_node* dev, const char* path)
{
    if (!path)
        return UINT64_MAX;
    uint64_t integer = 0;
    uacpi_status status = uacpi_eval_simple_integer(dev, path, &integer);
    return status == UACPI_STATUS_NOT_FOUND ? UINT64_MAX : integer;
}```

that probably isn't it

which means it hangs in the caller

[fiery turtle]

What would that mean?

[north holly]

idk, that's the problem

when the caller encounters an error in OBOS_DeviceGetDStateForWake

it errors out

static uacpi_iteration_decision acpi_enumerate_callback(void *ctx, uacpi_namespace_node *node, uint32_t max_depth)
{
    OBOS_UNUSED(max_depth);

    obos_status status = OBOS_DeviceMakeWakeCapable(node, UACPI_SLEEP_STATE_S3, !!ctx);
    if (obos_is_error(status))
    {
        if (status != OBOS_STATUS_WAKE_INCAPABLE)
            OBOS_Warning("Could not make device wake capable. Status: %d. Continuing...\n", status);
        return UACPI_ITERATION_DECISION_CONTINUE;
    }

    return UACPI_ITERATION_DECISION_CONTINUE;
}```

which means it hung somewhere after the call to OBOS_DeviceMakeWakeCapable

[fiery turtle]

But it just continues

[north holly]

unless the function doesn't fail

[fiery turtle]

Then it also continues

[north holly]

if the first if statement gets reached

    if (snd == UINT64_MAX && snw == UINT64_MAX)
    {
        if (status)
            *status = OBOS_STATUS_SUCCESS;
        return DSTATE_INVALID;
    }```

so here

[fiery turtle]

[north holly]

    uacpi_object* buf = {};
    if (uacpi_unlikely_error(uacpi_eval_simple_package(dev, "_PRW", &buf)))
        return OBOS_STATUS_INTERNAL_ERROR;

    uacpi_object_array pkg = {};
    uacpi_object_get_package(buf, &pkg);```

in which case

    status = enable_wake_gpe(dev, &pkg);
    if (obos_is_error(status))
    {
        // Back out of the unfinished operation.
        //enable_pwr(dev, &pkg, false);
        if (useDSW)
            dsw(dev, false, state, DSTATE_0);
        else
            psw(dev, false);
        OBOS_DeviceSetDState(dev, DSTATE_0, false);
        return status;
    }```

it does that

enable_wake_gpe just evaluates _PRW and enables that gpe

basically

[fiery turtle]

Anyways would be nice if you figured it out whether its obos or uacpi bug doesnt matter

Im off to bed for now tho

[north holly]

it's probably obos bug if I've had it for so long

[north holly]

gn

[fiery turtle]

Sadge

Debug it 😡

[north holly]

yes.

[fiery turtle]

Nice

At least the other subject works

[north holly]

ye

ok so enable_wake_gpe returns success

which means OBOS_DeviceMakeWakeCapable returns

static uacpi_iteration_decision acpi_enumerate_callback(void *ctx, uacpi_namespace_node *node, uint32_t max_depth)
{
    OBOS_UNUSED(max_depth);

    obos_status status = OBOS_DeviceMakeWakeCapable(node, UACPI_SLEEP_STATE_S3, !!ctx);
    if (obos_is_error(status))
    {
        if (status != OBOS_STATUS_WAKE_INCAPABLE)
            OBOS_Warning("Could not make device wake capable. Status: %d. Continuing...\n", status);
        return UACPI_ITERATION_DECISION_CONTINUE;
    }

    return UACPI_ITERATION_DECISION_CONTINUE;
}```

into there

where it return UACPI_ITERATION_DECISION_CONTINUE;

this callback is for uacpi_namespace_for_each_child_simple

infy, I am afraid this might be a deadlock

added logs to my kernel api's mutexes

wait nvm

the function returns

where it mysteriously hangs in OBOS_ECSetGPEs

[dense steppe]

it is probably possible to instrument (parts of) your code with some gcc flag

[north holly]

void OBOS_ECSetGPEs()
{
    if (ec_initialized)
        uacpi_enable_gpe(ec_gpe_node, ec_gpe_idx);
}```

ec_initialized is false on this machine

    uacpi_install_notify_handler(uacpi_namespace_root(), default_notify, nullptr);

    uacpi_finalize_gpe_initialization();```
it then probably goes onto here

[dense steppe]

by this I mean inserting calls to some __instrument_enter (CALLER_IP); and __instrument_leave (CALLER_IP)'; to everything in specific source files

it might help finding the bug

or it might not

idk

[north holly]

it hangs in uacpi_finalize_gpe_initialization

it says it's acquiring a mutex

whether that ever succeeds... idk

[dense steppe]

printf before and after?

maybe it is something silly, like running out of stack space

[north holly]

doubt

it would've probably crashed

[dense steppe]

on qemu, yes.

in a predictable way

on real hw...

[north holly]

obos' kernel stacks have a guard page

[dense steppe]

nice

[north holly]

so it would just page fault

hopefully

[dense steppe]

now... do you handle the double-fault from not being able to call the page-fault handler??

[north holly]

yes

[dense steppe]

nice

[north holly]

ok it's a deadlock

ofc using an IST for the double fault handler

[frank canopy]

F

[north holly]

unless I forgot to actually add the log

ah whoops

forgor to run dd

before ejecting the usb

[dense steppe]

would it be the easy 'bah! I forgot to release here!' kind of bug or the annoying 'wtf is happening' kind of bug?

[north holly]

probably, and hopefully the former

[dense steppe]

dude setup PXEBOOT

[north holly]

todo™️

I was looking at it the other day

[dense steppe]

I haven't done it myself but supposedly it is very good

[north holly]

it's convinient

if I had to guess

idk if it's "good"

[dense steppe]

basically 'just compile and run!' but for real hardware

[north holly]

ye

ok it doesn't deadlock

not on a mutex, at least

[dense steppe]

dude. instrument with GCC. then it is impossible to forget some printf statements

[north holly]

too much work

[dense steppe]

will pay off in the long run

[north holly]

bah

[dense steppe]

(except you gotta make sure you avoid infinite recursion in the instrument handlers)

[north holly]

I actually did steal monkuous' profiling thing

for gcc

so I have that

[keen marsh]

The best time investment ever and it pretty simple to setup

But it can be a bit annoying if your router doesn't support it

[dense steppe]

was there any router level stuff that you had to do to get your "victim" machines to boot from your dev machine?

[keen marsh]

The one who tells the machine what it should boot is the dhcp server

Typically located in your router

[dense steppe]

sadge :-(

[keen marsh]

If you have a extra machine laying around you can make it the dhcp server

[dense steppe]

well that'd be the dev machine :p

[keen marsh]

As long as it's always on

[dense steppe]

but there is a way to tell the victim machines "hey! pxeboot from 192.168.1.xyz instead!", no?

[keen marsh]

The dhcp server does that

[dense steppe]

(by storing stuff eg. grub config on the victim machine, i.e. no dhcp server)

[keen marsh]

That I haven't heard

But maybe its possible

[dense steppe]

probably

well

it's not relevant until I want to test on real hardware anyways

and... I think I'd need another ethernet cable for that lol

since afaik PXE over wifi is not common

[keen marsh]

Iirc you can also connect them directly

[dense steppe]

like an ethernet cable directly between the two machines?

yeah.

but then I lose internet connectivity on my dev machine

[keen marsh]

For like 30 sec

Until the machine booted

[dense steppe]

thus higher latency between a successful test and flexing in this discord

the worst type of latency

eh, I could probably use wifi to the router to get internet access lol

I just haven't bothered

[calm latch]

@fiery turtle I've gotten too caught up with AHCI and I'll test patches tomorrow...

[hasty plinth]

[hasty plinth]

btw there's plenty of precedents where people link their own code as an example of something they're talking about, imo its fine.

[dense steppe]

i'm just trolling lol. it's part of a deliberate strategy to get more eyes on the #1326937732122935379 thread

[hasty plinth]

Oh lol, I totally missed that one 😬

[dense steppe]

similarily misspelling it is a deliberate strategy so I get to post the link twice

[hasty plinth]

lol

[fiery turtle]

Pls do!

@north holly did you figure it out?

[north holly]

Was able to track it down to finalize gpe

Before going to sleep

[fiery turtle]

are u gonna continue now?

[keen marsh]

if you want i have a old dell machine where i can test uacpi on if you want, id just need an iso

[fiery turtle]

how old are we talking

[keen marsh]

i think its 5th gen

but let me see

nvm its a thinkcentre i5 4th gen 2013

[fiery turtle]

thats pretty new but u could test obos, im sure oberrow would appreciate it

also

[slim panther]

lfg

[fiery turtle]

i still want oberrow to figure out that obos bug

if its a uacpi bug we should fix it before 1.0

and also for mishakov to test pmos on his pcs

damn am i finally going to be able to work on other projects soon

cant believe it

[slim panther]

yay

[north holly]

Does this have an EC?

[keen marsh]

idk

[fiery turtle]

dmesg | grep EC

[north holly]

can u test obos pretty pls

this works on my haswell i5

[keen marsh]

btw does your pci code check/handle looped cap lists?

[fiery turtle]

💀

[north holly]

uh I don't think it does

[deft canopy]

I think i have a couple machines with some pentiums

[fiery turtle]

does this pc have that?

[keen marsh]

yeah

[north holly]

goddamnit

[fiery turtle]

that would be cool

(if u could run obos)

[deft canopy]

We'll see

[fiery turtle]

not another obos hang

[north holly]

is pentium even x86-64?

[north holly]

yeah I didn't know cap lists could be looped

[fiery turtle]

depends which pentium

[deft canopy]

I think this is a 64 bit pentium

[north holly]

if I compile obos as x86_64-v1

[deft canopy]

But id have to check when i get home

[north holly]

I could send that iso

[fiery turtle]

oh yeah i wanted to get rid of popcount shit bfore 1.0 too

this reminds me

[deft canopy]

Just DM a link to me or smth and ill try to remember

[north holly]

kk

    uint64_t tmp = 0;
    DrvS_ReadPCIRegister(dev->location, 0x34, 4, &tmp);

    pci_capability* tail = nullptr;

+    uint8_t first_offset = tmp & 0xff;

-    for (uint8_t offset = tmp & 0xff; offset; )
+    for (uint8_t offset = tmp & 0xff; offset && first_offset != offset; )
    {
        uint8_t next = 0;
        uint8_t cap_id = 0;

this should be the solution

[north holly]

this iso works around that PCI fnuy thing

wait maybe I'm dumb

[keen marsh]

are you checking if it reaches the first one again?

iirc it only loops on a subset

best bet is using a bitmap

[north holly]

that's what I'm tryna do

[keen marsh]

of visited offsets

[north holly]

so it doesn't loop on the first one??

like it's not tail->next = head

[fiery turtle]

that would be too simple

[north holly]

damn you retarted bios devs

[keen marsh]

it goes like cap a, cap b, cap c, back to cap b

[fiery turtle]

so are u supposed to just terminate if it goes back to b?

[keen marsh]

just break out of the for loop if you reach a cap that you already visited

[north holly]

theoretically that fixes the problem

    uint8_t visited_offsets[256/8];
#define set_visited_offset(off) (visited_offsets[(off)/8] |= BIT((off)%8))
#define visited_offset(off) !!(visited_offsets[(off)/8] & BIT((off)%8))

    for (uint8_t offset = tmp & 0xff; offset; )
    {
        uint8_t next = 0;
        uint8_t cap_id = 0;

        // works around certain PCs that have something like:
        // a->b->c->b
        if (visited_offset(offset))
            break; 
        set_visited_offset(offset);```

[keen marsh]

ok ill try

[fiery turtle]

static u8 __pci_find_next_cap_ttl(struct pci_bus *bus, unsigned int devfn,
                  u8 pos, int cap, int *ttl)
{
    u8 id;
    u16 ent;

    pci_bus_read_config_byte(bus, devfn, pos, &pos);

    while ((*ttl)--) {
        if (pos < 0x40)
            break;
        pos &= ~3;
        pci_bus_read_config_word(bus, devfn, pos, &ent);

        id = ent & 0xff;
        if (id == 0xff)
            break;
        if (id == cap)
            return pos;
        pos = (ent >> 8);
    }
    return 0;
}

static u8 __pci_find_next_cap(struct pci_bus *bus, unsigned int devfn,
                  u8 pos, int cap)
{
    int ttl = PCI_FIND_CAP_TTL;

    return __pci_find_next_cap_ttl(bus, devfn, pos, cap, &ttl);
}

u8 pci_find_next_capability(struct pci_dev *dev, u8 pos, int cap)
{
    return __pci_find_next_cap(dev->bus, dev->devfn,
                   pos + PCI_CAP_LIST_NEXT, cap);
}
EXPORT_SYMBOL_GPL(pci_find_next_capability);

looks like linux just has a TTL

aka max number of loops

[keen marsh]

mb i need the elf file. Im pxe booting (and limine cfg if you have anything special in there)

[fiery turtle]

#define PCI_FIND_CAP_TTL 48

set to 48 by default

[north holly]

obos uses hyper

[keen marsh]

ok ill get a usb

[fiery turtle]

so this is basically harder than it should be

[north holly]

wdym

[mortal yoke]

add pxe support to it

[fiery turtle]

linux just uses a "time to live" value

to avoid infinite cap loops

[north holly]

hyper has PXE support iirc

[fiery turtle]

aka max iterations

[fiery turtle]

nope

[north holly]

guess I didn't recall correctly

[fiery turtle]

https://lore.kernel.org/linux-pci/[email protected]/

[north holly]

other than the memory overhead being bigger, this isn't too complicated

[north holly]

LErtheriogres

FINALLY

obos booted on osmeone ellse's hardware

that panic I expected

[fiery turtle]

now test suspend and stuff

[north holly]

@keen marsh can u test this

if all goes well, your computer/laptop goes to S3

[fiery turtle]

this is 1.0 uacpi right?

[north holly]

then you wake it and it shuts down

[north holly]

https://github.com/uACPI/uACPI/commit/63ab369748db5764b59a728f54da0d7e5390f407

[fiery turtle]

shutdown debugging

[fiery turtle]

yeye

[north holly]

actually I think the iso I sent was using another copy of obos I had

using old uacpi

either way it should boot

[keen marsh]

When it starts a '_' appears in the middle of the screen if I then press any key I get

[north holly]

that hangs in finalize gpe initialization

just like on my main PC

[calm latch]

Is 765059be191db the right commit?

[north holly]

@fiery turtle we might have a uacpi regression here

using the old obos iso

with old uacpi

it doesn't hang

[north holly]

not even an old iso

[calm latch]

which branch do I checkout?

[north holly]

only behind on the RTC code

[north holly]

address spaces support

[north holly]

but with the new uacpi code it does hang in uacpi_finalize_gpe_initialization

on both my pc and his PC

and it doesn't on my laptop

with the same uacpi version