#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages · Page 3 of 1
not all
Hmm
another one is ```
0x50300009ac34 is located 4 bytes inside of 32-byte region [0x50300009ac30,0x50300009ac50)
freed by thread T0 here:
#0 0x5631214da536 in free /var/tmp/portage/sys-libs/compiler-rt-sanitizers-17.0.6/work/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
#1 0x563121524d68 in uacpi_kernel_free /tmp/uacpi/tests/runner/interface_impl.cpp:217:5
#2 0x56312154d6e4 in free_object /tmp/uacpi/source/types.c:666:5
#3 0x56312154d6e4 in free_chain /tmp/uacpi/source/types.c:711:13
#4 0x56312154d6e4 in uacpi_object_unref /tmp/uacpi/source/types.c:749:9
previously allocated by thread T0 here:
#0 0x5631214da7de in malloc /var/tmp/portage/sys-libs/compiler-rt-sanitizers-17.0.6/work/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
#1 0x563121525082 in uacpi_kernel_alloc /tmp/uacpi/tests/runner/interface_impl.cpp:188:17
#2 0x563121525082 in uacpi_kernel_calloc /tmp/uacpi/tests/runner/interface_impl.cpp:222:17
#3 0x56312154c571 in uacpi_create_object /tmp/uacpi/source/types.c:313:11
Thx
That would be great
curious ```
[uACPI][WARN] invalid table 'DSDT' checksum!
[uACPI][TRACE] load of 'DSDT' (OEM ID 'ATC' OEM Table ID 'Cofbej')
[uACPI][TRACE] write to [_SB_.TP80] (2 bytes) TableData[0x0000000000000001] = 0x0
AddressSanitizer:DEADLYSIGNAL
==1950122==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x556a1f6d71e9 bp 0x7ffcff823501 sp 0x7ffcff823490 T0)
==1950122==The signal is caused by a WRITE memory access.
==1950122==Hint: address points to the zero page.
#0 0x556a1f6d71e9 in memory_write /tmp/uacpi/source/default_handlers.c:270:35
#1 0x556a1f6d71e9 in table_data_region_do_rw /tmp/uacpi/source/default_handlers.c:322:8
lmao another aml blob that just segfaults iasl
Program received signal SIGSEGV, Segmentation fault.
AcpiDmCheckForSymbolicOpcode (Op=Op@entry=0x5555556cc4c0, Info=Info@entry=0x7fffffffd030) at ../../../source/components/disassembler/dmcstyle.c:429
429 Target = Argument2->Common.Next;
(gdb) p Argument2
$1 = (ACPI_PARSE_OBJECT *) 0x0
sure is, its here https://github.com/DeanoBurrito/northport, although if you're looking for how I'm using uacpi its not in the repo yet. I'm using it as a loadable driver, and am still playing around with how I want the api to look on the kernel side.
I wanted to do that in my previous kernel, I don't think it's a good idea
The code was going to be messy
I think its a good idea 
ok then gl
ty
Huh
Classic
okay yeah this isnt a use after free
this is use of uninitialized pointer
the fuzzer made it so _STA returned nothing
in that case apparently nothing in the code overwrites the pointer to NULL
which is unfortunate
log with the fix applied
This is why you should've listened to my static analyzer
Funnily enough, if the code path was simple enough the static analyzer might've been able to tell you what happened
uacpi_execute_control_method must set the pointer to null if no return value was provided and the method exited successfully
that's just what any sane api would do
probably
Tbf this path would've been buried in the 100s of one's like it
yup
i wonder how many of these is just uninitialized pointer because of missing return value
a good chunk i presume
probably
[uACPI][TRACE] load of 'DSDT' (OEM ID 'DELL\x' OEM Table ID 'UsbCTabl')
AddressSanitizer:DEADLYSIGNAL
=================================================================
==3975158==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x55def6b6cdc0 bp 0x000000000007 sp 0x7ffea5f45180 T0)
==3975158==The signal is caused by a READ memory access.
==3975158==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used.
#0 0x55def6b6cdc0 in bit_copy /tmp/uacpi/source/io.c:80:21
but cool nonetheless
wym unknown address
lol
a good chunk of the crashes are also my fault
wdym?
ohh
[uACPI][TRACE] read from [\_SB_.PCI0.LPCB.LPC1] (1 bytes) PCI_Config[0x000000000000006B] = 0xFF
/tmp/uacpi/source/uacpi.c:634:23: runtime error: shift exponent 65 is too large for 32-bit type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /tmp/uacpi/source/uacpi.c:634:23 in
invalid free size: originally allocated 56 bytes, freeing as 32
that's an interesting one
almost certainly
diff --git a/source/interpreter.c b/source/interpreter.c
index d6693a0..1aa24a8 100644
--- a/source/interpreter.c
+++ b/source/interpreter.c
@@ -5680,6 +5680,9 @@ uacpi_status uacpi_execute_control_method(
}
out:
+ if (out_obj != UACPI_NULL)
+ *out_obj = UACPI_NULL;
+
if (ctx->ret != UACPI_NULL &&
ctx->ret->type != UACPI_OBJECT_UNINITIALIZED) {
uacpi_object_ref(ctx->ret);
this is the fix i made locally
see if that fixes like all of those
i wonder if i could teach afl that crashes in memory_read/memory_write are uninteresting
probably
okay that seems to fix all the interesting crashes
no that went away too
oh ok
or at least i don't see it
yeah that shifts the type member
since it was a bogus pointer it was shfting by a bogus number
i wonder how we come up with a read from 0x000000ff
i can't see how is_physical_pointer can say it's not physical
where did you see that?
[uACPI][WARN] invalid table 'DSDT' checksum!
[uACPI][TRACE] load of 'DSDT' (OEM ID 'DUC' OEM Table ID 'DkcVfdy')
AddressSanitizer:DEADLYSIGNAL
=================================================================
==263676==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000ff (pc 0x55cc0f480538 bp 0x7ffeba639cb0 sp 0x7ffeba639bc0 T0)
==263676==The signal is caused by a READ memory access.
==263676==Hint: address points to the zero page.
#0 0x55cc0f480538 in memory_read /tmp/uacpi/source/default_handlers.c:254:16
out of bounds write because of a previous mapping being smaller and then that trashed this pointer?
potentially
because 0xFF seems like what IO reads return
hmm
void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
{
+ std::printf("Mapping 0x%016" PRIX64 " with size %zu\n", addr, size);
+
try this
see if it maps the same thing multiple times
yup..
so that's the realloc thing you mentioned
yup
bit underwhelming to only find 1 real bug but that's still 1 bug less
its a pretty important bug so yeah
i wonder if that unblocks more bugs
i also want to make aborts in methods unwind back to table level code so that will unlock even more bugs potentially
yeah its pretty nice
@fiery turtle I get some warnings in uACPI related to variables possibly being used uninitialized.
uACPI/source/interpreter.c:2844:9: warning: 'arg1_buf.ptr' may be used uninitialized [-Wmaybe-uninitialized]
2844 | uacpi_memcpy(dst_buf + arg0_buf->size, arg1_buf.ptr, arg1_buf.len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uACPI/source/interpreter.c:2834:41: note: 'arg1_buf.ptr' was declared here
2834 | struct object_storage_as_buffer arg1_buf;
| ^~~~~~~~
uACPI/source/interpreter.c:2837:18: warning: 'arg1_buf.len' may be used uninitialized [-Wmaybe-uninitialized]
2837 | buf_size = arg0_buf->size + arg1_buf.len;
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uACPI/source/interpreter.c:2834:41: note: 'arg1_buf.len' was declared here
2834 | struct object_storage_as_buffer arg1_buf;```
same warning around interpreter.c:1714:17
actually I might as well give you the entire log
you can ignore all analyzer warnings, those are for my kernel
everything in the log until it says [27%] Built target uacpi
I just love it though when the static analyzer yells at me because of nullptr dereferences as a result of a new call
It's so annoying
@hollow elm I think I came up with a genius idea
diff --git a/tests/runner/interface_impl.cpp b/tests/runner/interface_impl.cpp
index cee0874..ae387f4 100644
--- a/tests/runner/interface_impl.cpp
+++ b/tests/runner/interface_impl.cpp
@@ -116,22 +116,7 @@ uacpi_status uacpi_kernel_pci_write(
return UACPI_STATUS_OK;
}
-static bool is_physical_address(uacpi_phys_addr addr, uacpi_size size)
-{
-#ifdef _WIN32
- return IsBadReadPtr((void*)addr, size);
-#else
- // https://stackoverflow.com/questions/4611776/isbadreadptr-analogue-on-unix
- int nullfd = open("/dev/random", O_WRONLY);
- bool ok = true;
-
- if (write(nullfd, (void*)addr, size) < 0)
- ok = false;
-
- close(nullfd);
- return !ok;
-#endif
-}
+bool g_expect_virtual_addresses = true;
static
std::unordered_map<void*, std::pair<uacpi_phys_addr, size_t>>
@@ -141,7 +126,7 @@ static std::unordered_map<uacpi_phys_addr, void*> phys_to_virt;
void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
{
- if (is_physical_address(addr, size)) {
+ if (!g_expect_virtual_addresses) {
auto it = phys_to_virt.find(addr);
if (it != phys_to_virt.end()) {
virt_to_phys_and_refcount[it->second].second++;
diff --git a/tests/runner/test_runner.cpp b/tests/runner/test_runner.cpp
index 891257e..d36daa6 100644
--- a/tests/runner/test_runner.cpp
+++ b/tests/runner/test_runner.cpp
@@ -131,6 +131,8 @@ static void run_test(
uacpi_status st = uacpi_initialize(¶ms);
ensure_ok_status(st);
+ g_expect_virtual_addresses = false;
+
st = uacpi_install_notify_handler(
uacpi_namespace_root(), handle_notify, nullptr
);
incredible
lmao
@hollow elm i made an insanely overengineered system that should be safe against everything
we should try fuzzing that
im about to merge it in a bit
@@ -118,31 +120,60 @@ uacpi_status uacpi_kernel_pci_write(
bool g_expect_virtual_addresses = true;
+struct mapping {
+ void *virt;
+ uacpi_size size;
+
+ bool operator==(const mapping& m) const
+ {
+ return size == m.size;
+ }
+};
+
+template <>
+struct std::hash<mapping>
+{
+ size_t operator()(const mapping& m) const
+ {
+ return m.size;
+ }
+};
+
static
std::unordered_map<void*, std::pair<uacpi_phys_addr, size_t>>
virt_to_phys_and_refcount;
-static std::unordered_map<uacpi_phys_addr, void*> phys_to_virt;
+static std::unordered_map<uacpi_phys_addr, std::unordered_set<mapping>>
+phys_to_virt;
void* uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size size)
{
if (!g_expect_virtual_addresses) {
auto it = phys_to_virt.find(addr);
if (it != phys_to_virt.end()) {
- virt_to_phys_and_refcount[it->second].second++;
- return it->second;
+ auto mapping_it = it->second.find({ nullptr, size });
+
+ if (mapping_it != it->second.end()) {
+ virt_to_phys_and_refcount[mapping_it->virt].second++;
+ return mapping_it->virt;
+ }
+
+ std::printf("WARN: remapping physical 0x%016" PRIX64
+ " with size %zu\n", addr, size);
}
void *virt = std::calloc(size, 1);
+ mapping m = { virt, size };
+
virt_to_phys_and_refcount[virt] = { addr, 1 };
- phys_to_virt[addr] = virt;
+ phys_to_virt[addr].insert(m);
return virt;
}
return reinterpret_cast<void*>(addr);
}
-void uacpi_kernel_unmap(void* addr, uacpi_size)
+void uacpi_kernel_unmap(void* addr, uacpi_size size)
{
auto it = virt_to_phys_and_refcount.find(addr);
if (it == virt_to_phys_and_refcount.end())
@@ -151,7 +182,18 @@ void uacpi_kernel_unmap(void* addr, uacpi_size)
if (--it->second.second > 0)
return;
- phys_to_virt.erase(it->second.first);
+ auto phys_it = phys_to_virt.find(it->second.first);
+ auto mapping_it = phys_it->second.find({ nullptr, size });
+ if (mapping_it == phys_it->second.end()) {
+ std::printf("WARN: cannot identify mapping virt=%p phys=0x%016" PRIX64
+ " with size %zu\n", addr, phys_it->first, size);
+ return;
+ }
+
+ phys_it->second.erase(mapping_it);
+ if (phys_it->second.empty())
+ phys_to_virt.erase(it->second.first);
+
std::free(it->first);
virt_to_phys_and_refcount.erase(it);
}
basically this
it now successfully runs that blob you sent yesterday
okay merged
now I expect 0 crashes in the fuzzer
nice
inb4 instant crash
for this round of fuzzing i'm enabling cmplog
which hooks comparisons and sends the values being compared against to afl which then tries to inject them into the fuzzer output
hopefully this should make it so more valid instructions appear
Hmm
Im not sure what that means but if it makes the fuzzing more efficient sounds great!
Thank you
ig it means that if you have a branch if (x == 42) then instead of afl randomly trying values for x until it hits 42, it'd get a hint that it should shove the value 42 in there
yeah
Ooh nice
i'm thinking it'll figure that it should shove more valid aml opcodes into the input
Yeah thats definitely interesting
personally i think part of what made fuzzing great was the fuzzer throwing random opcodes everywhere so you can find weird ass edge cases with uacpi
also i kinda forgot but thanks for sized frees :^)
Npnp
not my uacpi kernel api free is no longer a stub
although i do not believe it was called either way
Nice
Why is that lol
i absolutely do not utilize any of the public apis just yet
ill replace table iteration with uacpi shortly
oh no i do call init
And namespace load as well?
Yeah there's uh
U dont need the notify handler too
yeah let me throw in some more calls and see what happens
Its mostly for testing
Look at oberrows kernel or managarm init sequence
I should really make a tutorial
is eval("\MAIN") required?
Nope its the test runner abi
well it's still gonna do that, but it's not gonna throw in invalid opcodes which just abort execution
yeah i figured, just wanted to ask
oh i see
or at least that's the idea
no way in hell it's doing that
Well sometimes it does
did you see the kind of output it makes
Else { else { else {
if it is even decompilable with iasl
i am inadvertently fuzzing iasl as well :^)
It died almost instantly as well I think?
Considering it dies if u return a reference to a local object
Probably not at all
i was about to say "i wonder how hard it is to go from aml -> taking over linux due to bugs in acpica" but then i remembered aml can poke at arbitrary memory already
Yeah its trusted code basically
[ 0] (main) err: Kernel panic: switch on corrupt value
[ 0] (debug) err: Stack backtrace:
[ 0] (debug) err: 0xFFFFFFFF800827F7: <no symbol info> at kernel/src/mutex.zig:17
[ 0] (debug) err: 0xFFFFFFFF800B96B4: uacpi_kernel_acquire_mutex at kernel/src/uacpi.zig:306
[ 0] (debug) err: 0xFFFFFFFF8001F8ED: enter_method at kernel/./uacpi/source/interpreter.c:4232
[ 0] (debug) err: 0xFFFFFFFF800167F6: prepare_method_call at kernel/./uacpi/source/interpreter.c:4892
[ 0] (debug) err: 0xFFFFFFFF80015F97: uacpi_execute_control_method at kernel/./uacpi/source/interpreter.c:5635
[ 0] (debug) err: 0xFFFFFFFF8000E896: uacpi_eval at kernel/./uacpi/source/uacpi.c:618
[ 0] (debug) err: 0xFFFFFFFF8000E8E7: uacpi_eval_typed at kernel/./uacpi/source/uacpi.c:629
[ 0] (debug) err: 0xFFFFFFFF80012813: uacpi_eval_sta at kernel/./uacpi/source/utilities.c:620
[ 0] (debug) err: 0xFFFFFFFF8000F1E1: sta_eval at kernel/./uacpi/source/uacpi.c:460
[ 0] (debug) err: 0xFFFFFFFF8000E54D: do_sta_ini at kernel/./uacpi/source/uacpi.c:504
[ 0] (debug) err: 0xFFFFFFFF8005288A: uacpi_namespace_for_each_node_depth_first at kernel/./uacpi/source/namespace.c:476
[ 0] (debug) err: 0xFFFFFFFF8000DFF0: uacpi_namespace_initialize at kernel/./uacpi/source/uacpi.c:0
[ 0] (debug) err: 0xFFFFFFFF8008F0AF: init at kernel/src/uacpi.zig:41
[ 0] (debug) err: 0xFFFFFFFF8008EE73: main at kernel/src/main.zig:155
[ 0] (debug) err: 0xFFFFFFFF8008F2FA: _start at kernel/src/main.zig:111
[ 0] (debug) err: 0x0000000000000000: <no symbol info> at ??:0```
something seems to be going really wrong 
i'll have to fix my mutex bullshit, but thats for tomorrow
oh oops lmoa ```
[+] Found 44 unique tuples across 4578 files.
[!] WARNING: All test cases had the same traces, check syntax!
[+] Narrowed down to 1 files, saved in 'fuzz-in/'.
i threw out all blobs that time out after 0.8s
Lol
What does this mean?
i forgot to tell it to pass the filename to the test runner so it reduced all the inputs to just one
Lol
holy SHIT i think i might just be retarded !!!
$ afl-cmin -i hw-blobs/ -o fuzz-in/ -T all -- _build-nocmplog/test-runner
``` vs ```
$ afl-cmin -i hw-blobs/ -o fuzz-in/ -T all -- _build-nocmplog/test-runner @@
Makes sense
lol
Who knows maybe test runner segfaults at startup sometimes
/// Returns a pointer to undefined memory.
/// Call `destroy` with the result to free the memory.
pub fn create(self: Allocator, comptime T: type) Error!*T {```
HJAHA!!!!
WOW
WHO WOULD HAVE THOUGHT
[ 0] (phys) info: uacpi-info: namespace initialization done: 35 devices, 0 thermal zones, 1 processors
well then the chance is less than 1 in like 30 million
Nice
uninitialized allocations strike again
Lol
and less than 1 in 12 thousand on master
Fuzzing the clone syscall
r-rust?
Zig I think
Everything just hangs?
it's running very slow
Huh
which is confusing because i threw out all the hw blobs that timed out
even before feeding it into afl-cmin
Are you compiling llvm perhaps 
nah lol
Strange
am i losing it, the cmplog variant runs fine
Lol
okay no it also experienced slowdowns
im gonna run afl-tmin on the input corpus
and then maybe cmin again on the minimized files
i love gnu parallel ```
$ find ./ -type f | parallel afl-tmin -i {} -o ../fuzz-in-min/{/} -- ../_build-nocmplog/test-runner @@
Academic tradition requires you to cite works you base your article on.
If you use programs that use GNU Parallel to process data for an article in a
scientific publication, please cite:
Tange, O. (2024, January 22). GNU Parallel 20240122 ('Frederik X').
Zenodo. https://doi.org/10.5281/zenodo.10558745
This helps funding further development; AND IT WON'T COST YOU A CENT.
If you pay 10000 EUR you should feel free to use GNU Parallel without citing.
More about funding GNU Parallel and the citation notice:
https://www.gnu.org/software/parallel/parallel_design.html#citation-notice
To silence this citation notice: run 'parallel --citation' once.
Lmao
Lol yes
okay i think i'm gonna look into it tomorrow
what in the name of fuck
@hollow elm did it crash?
havent had any crashes yesterday but i didnt do any long campaigns
Made a basic uACPI page on osdev wiki: https://wiki.osdev.org/UACPI
for now this only has initialization tutorial but ill add some code examples later
Take some from my previous kernel :^)
I might add a list of kernels to look at for examples
Bro
Don't u just love when github ci runners randomly break every fucking week for no reason
typical fickle python
that's okay i fixed it 
didn't know there was an env var
maybe add example code to read some tables and maybe add some docs that list all api headers with a description on what functions they expose and their purpose
yeah thats on the todo list
whats the recommended course of action for handling the fatal type of firmware request? should that result in a panic or is it safe to keep running for a bit?
Linux just logs it and then ignores it
OK cheers, I saw managarm doing the same
Added a few more code examples in osdev wiki: https://wiki.osdev.org/uACPI
Also fixed a few misc things in uacpi, including namespace node attach order
nice
i will implement shutdown at some point
uacpi will make the doing it easy it's the preparing that won't be
yeah, unmounting everything and stuff is definitely not easy
thank you
proper shutdown is one of those features which i don't think i have ever seen a hobby OS
i'm not sure about unmounting either, which goes with it
yup
best u get is just how mangarm currently does it
power button press == instant shutdown
we should probably implement sync sometime :^)
well yeah ideally we'd wire the power button to tell userspace to shutdown
yeah
also usually power button is configured to actually trigger sleep instead
or bring up a gui prompt
but in the current situation having all managed memory objects (objects used to implement page caches) be told to do a writeback at least would be a good idea
if we want to just power off immediately
but yeah all of that comes down to routing it to userspace
thats a start for sure
Yeah
That reminds me I have some shutdown related work still standing. I should get back to work and get that shit fixed
Made method aborts while loading tables non-fatal (aka only the call chain is aborted and the table keeps loading)
[uACPI][TRACE] write to [\PCI0.UHCI.TEST.PCIR] (1 bytes) TableData[0x0000000000000000] = 0x7
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1140720==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x5655286ea9d3 bp 0x7fff6db14201 sp 0x7fff6db14170 T0)
==1140720==The signal is caused by a WRITE memory access.
==1140720==Hint: address points to the zero page.
#0 0x5655286ea9d3 in memory_write /tmp/uacpi/source/default_handlers.c:267:34
#1 0x5655286ea9d3 in table_data_region_do_rw /tmp/uacpi/source/default_handlers.c:322:8
i suppose there's not much you can do about this?
well the connection between TableData[0x0000000000000000] and the pointer being 0x000000000000 seems obvious? but i don't know how it actually works
oh actually i know exactly how this happened
so table data opregions are created via TableRegionDataOp
under the hood it uses the same opregion structure
but
this aml created it via OpregionOp by hijacking the address space type
address space type happened to match internal enum that corresponds to tabledata
and table data is mapped as just a plain virtual address
so it did not further validation on that
basically this "Internal type"
hm yeah ```
OperationRegion (PCIR, 0xFE, 0x00, Arg0)
Field (PCIR, AnyAcc, NoLock, Preserve)
{
REG0, 38
}
lmao
iasl managed to actually decompile it :^)
technically this is invalid i think, because its a reserved address space
but yeah i guess i should add validation for this in the code
to at least check that its not 0xFE
that's the only crash so far, after about an hour
but i'm only using the tests as input
technically this is a real bug, so nice
hmm well i guess its OEM defined
so maybe a u8 is not enough to represent it
idk
what's the TableData type used for?
ye
these are basically system memory, but the base is a virtual address
at least in uacpi
makes sense
Now that I think about why am I even doing _REG for it, thats not even a real opregion type
Good thing this bug was found
another crash found ```
[uACPI][WARN] error during _REG execution for operation region \PCI0.UHCI.TEST.PCIR@0x506000000b60: invalid argument
AddressSanitizer:DEADLYSIGNAL
==2406755==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x562631cbcd83 bp 0x7fff8eebe010 sp 0x7fff8eebdf20 T0)
==2406755==The signal is caused by a READ memory access.
==2406755==Hint: address points to the zero page.
#0 0x562631cbcd83 in memory_read /tmp/uacpi/source/default_handlers.c:245:16
#1 0x562631cc1063 in dispatch_field_io /tmp/uacpi/source/io.c:229:11
#2 0x562631cc1063 in access_field_unit /tmp/uacpi/source/io.c:288:12
#3 0x562631cbf7fd in uacpi_read_field_unit /tmp/uacpi/source/io.c:364:15
i can't disassemble it, it has invalid opcodes, and if i just patch them to 0x00 iasl segfaults instead :^)
but it seems related, \PCI0.UHCI.TEST.PCIR is what used to be the TableData opregion in the previous crashing input
can u send both crashes pls?
but yeah read is traced after the read so
there isnt like "about to read"
makes sense
so far there's 5 saved crashes but afaics they are all on a TableData opregion
--- a/source/interpreter.c
+++ b/source/interpreter.c
@@ -1080,6 +1080,9 @@ static uacpi_status handle_create_op_region(struct execution_context *ctx)
op_region = obj->op_region;
op_region->space = item_array_at(&ctx->cur_op_ctx->items, 1)->immediate;
+ if (op_region->space == UACPI_ADDRESS_SPACE_TABLE_DATA)
+ return UACPI_STATUS_AML_BAD_ENCODING;
+
try this
yeah that fixes all the crashes
ok nice
I'm adding core API that should be used during initial namespace device discovery to bind corresponding drivers
Im thinking ill add a mode to the test runner to run this against every node, perhaps this will add better coverage for the fuzzer @hollow elm
sounds like a good idea
maybe if its a device ill also run _CRS and _PRS against it
it'd probably also be useful for managarm for exposing all the legacy devices over mbus :^)
yeah definitely
this api i basically stole from acpica
linux uses it for initial bus enumeration
Also i want to add a CI mode that decodes all 500 AML blobs from that repo and runs the test runner against all of them
sounds like useful regression testing
Is there a reason why the EC driver is not part of uacpi
yes
because a proper implementation requires very tight coupling with kernel primitives
as well as being able to handle platform specific EC quirks
uacpi is not gonna take on that responsibility and provide a shitty half-working implementation
e.g. being able to asynchronously process transactions, or switch to poll mode as needed
this is completely outside of scope of what uacpi is doing
and uacpi philosophy is either do it well or dont do it at all
I thought you said an EC driver would be easy
it is trivial for a blocking EC driver that works on 80% of hardware
a proper async one that handles everything is quite a bit more complex tho
see: managarm ec driver
this file has so many bugzilla links
Makes sense
I just always see the same EC driver in hobby osdev and am like "this looks tiny"
But seeing Linux explains everything :^)
Same vibe as xhci
Yup
Today i decided that i will add more tables to acpi.h
So that users dont have to roll their own
ill start with madt
but ill also do hpet and a few other
I got it, now what? /j
stabilize it so it doesnt segfault when u blow on it
also when rewrite 5
When I figure out if the kernel is truly unfixable
When it's damaged beyond repair
I think I might try testing the VMM a bit (after school)
With large page allocations
and frees (those are largely untested)
SetProtection is so trivial there is no point in testing
But I use that in the driver loader and it works fine
Actually, the reason it took me so long to finish the VMM for this rewrite is because I wasn't working on the kernel
So if I work on the kernel more, a rewrite could be feasible
Anyway enough littering this thread
sure sounds good
I also kind of made a mistake where IRQs are non-preemptible like I originally wanted them to
(because otherwise the kernel shits itself)
are the RISC-V entries official now?
i know drwe de vault was very upset that ACPI was being pushed for risc-v
i know i know dumb question but who is acpi talking to when someone says it interacts with firmware? Like does it talk to some seperate controller running some system control code or does it talk to some special device or what does it really do
not yet i think
multiple answers:
- for more modern osses, mostly the firmware in terms of the embedded controller
- for older osses, AML invokes SMM
there's a data structure in ACPI NVS that has SMM opcode & args, that is configured and invoked by the AML bytecode
then bytecode waits for the smm to reply
and propagates the reply to the os etc
I see thanks for clarifying
np
lol
where was that?
i think the riscv structures might get added in acpi 6.6
6.5 is 3 years old at this point
why so mad
being a linux user, it is unlikely he is accustomed to concepts like "suspend" or "power management"
lmao
probably mad because it makes the kernel complicated
yes, for a hobby os like linux a fully static description of the state of the system at boot is totally enough
but kernels are complicated so that's a cringe complaint
it's why one ought to use a pleasant library instead
granted it won't be doing much for you unless you lean in to what it offers
tbh if u use something like uacpi u can implement suspend/resume in like 1000 loc
its not crazy difficult
plus some assembly for wake vector
i would like to try it at some point
i might do a PoC example for managarm evetually
for S1 suspend u dont even need assembly wake vector or saving ACPI NVS
it just resumes from where it left off
granted u dont save much power that way
it just triggers me because it reminds me of the casey muratori rant where he talks about hardware complexity
yeah id say that complaint is more of a skill issue
what's he upset about?
he's upset that hardware is complicated
"the world was better before branch predictors" sort of take?
i will not watch a 3hr rant
casey's take on acpi would be: 'oh my god shutting down the computer should just be a single memory access!!!!!'
didnt he port a huge library to implement ext4
and he complains about acpi complexity
A historical argument for creating a stable instruction set architecture (ISA) for entire system-on-a-chip (SoC) packages.
Please note that although it's never mentioned in the audio there was a typo in the slide deck that makes the situation even more ludicrous when comparing 1990's machine to 2015's: the hard drive line erroneously said "gig"...
lwext4, it's of a reasonable size
it's designed to be low in memory use though
i looked at it before
TL;DR:
'operating systems are very complicated. that's because hardware and drivers are complicated. what if we just hits blunt made hardware not complicated?'
it wouldn't work well for a kernel unless you reconstructed a lot of it (drop its custom caching, integrate it with your kernel's, drop its vfs, make it possible to use without holding a global lock around every read/write)
yeah from what im seeing its targeting embedded
❯ cloc --vcs=git .
90 text files.
90 unique files.
3 files ignored.
github.com/AlDanial/cloc v 1.90 T=0.09 s (916.7 files/s, 305922.9 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 30 3411 2940 14145
C/C++ Header 32 988 2819 3301
make 2 191 2 555
CMake 19 68 29 296
Markdown 1 45 0 199
YAML 3 5 1 38
-------------------------------------------------------------------------------
SUM: 87 4708 5791 18534
-------------------------------------------------------------------------------
okay yeah that library is the size of uacpi
i imagine drew went for it since bunnix is just a unix-like os speedrun
I also sometiems get tired of complex code and having to do everything properly and just end up wanting to speedrun something like that
i fell into that mode and regretted it
well
i don't regret it as such, it's very inspiring
running x11 was fun but i need to make this thing elegant, teachable
the benefit apart from the fun of making it run exciting software was perhaps the experience and familiarity it offered
makes sense
implementing something poorly can be a good prelude to implementing it well if you are too slow to turn out something beautiful the first time
oberrow@
SLIT would be nice if you've got SRAT, but I don't know how many are actually using those 🤔
yeah SLIT should be added def
there's a pr for lai about adding the tpm tables, but i'm not sure how useful it is or how well that fits
any table is useful, i think eventually uacpi should have every table in that header
ill take a look at the tpm table
Also numa aware allocators in managarm when
:^)
I will give you a wishlist once i start working on things that need tables
I remember that, I was there. Pretty sure I attended this specific talk lol
i will be using the SLIT table eventually
from time to time i get interested in extreme scaling on NUMA machines
so i want SLIT and SRAT
alright that's done
I made a nice namespace dumper in the test runner
e.g. heres a dump of pitust's chromebook namespace:
me when GOOG000A ps/2 keyboard
Stealing this immediately
That's the most HID of all time
added a new --ns-dump switch for the emulation mode that makes a dump like that at the end
your ps/2 keyboard isn't of the "google" brand?
@hollow elm do u remember the argument that i made for why its difficult to implement proper while timeouts?
im thiking abut how to design it now and i dont see any problems
liek i dont remember what the problem was last time
that the aml can trigger calls to kernel functions and those take an unknown amount of time?
hmm i dont think so?
well like an Event wait i guess
but thats not related to While timeouts
i think
anyway i added a start_ticks to every While codeblock, now i just check it at the beginning of that While
either when Continue or the end of block
you really should make a uACPI test image
managarm 
i wanted to test it on this new board i got but running managarm is tedious lol
yeah, tedious
yeah but a proper test image that supports everything uacpi needs will be an absolute ton of work
otherwise it would be a piece of crap
yeah
it's from yesterday
thats good enough!
whats the board?
like a new pc motherboard?
yeah
it's an MSI PRO B650M-B
i got it because it's one of the few AM5 motherboards with separate PS/2 keyboard and mouse
(it works well btw)
nice
ok i tried it
it seems to work
it gets to "waiting for /dev/sda0" and gets stuck there (of course it does)
but pressing the power button makes the machine shut down
nice
Fuck, never mind
The way While works right now is the code block is re-created every time when it gets jumped to
so the context of the while that was just being executed is lost
this will need some refactoring
managarm moment
live usb moment
Managarm does have USB drivers btw
Thats not why it doesn't work tho
sda0 usually corresponds to sata
with sdb0 being usb
shouldn't there be a boot option to use sdb0 instead like linux
It corresponds to SATA only if u have a SATA drive
And thats not a problem in managarm anyway
It can boot like this too
yes but it always defaults to sda0 all the time
which is sata and not usb
if you have a sata drive
idk what the drive name is if you have nvme
maybe just like linux where its nvme0p0
so unless you only have usb, it always defauts to sata or whatever
i mean ideally we'd just run udev in init-stage1, let it set up /dev/disk/by-uuid and just mount by uuid using symlinks from there
Yup
shouldn't even be that hard to do now, since the /dev/disk/by-uuid part was already working, and i recently merged some old patch that removes the size limitation for the initramfs

nope, i think i managed to implement it in very few loc
the idea is to preserve the previous while expiration and code offset before re-evaluating it
Here's a blob that infinitely polls some HW register
previously it would run forever
And another one from @vast kestrel
okay so i tried managarm on my laptop
and uacpi initialized fine, and there were even some queries happening and the aml was doing some notification (thermal zone related judging by the name), but unfortunately the power button didn't work
unfortunately i can't check if the uacpi init just failed since i didn't get into weston
looking at a disassembly of the acpi tables, it seems to use the new kind of power button
the acpi tables also apparently contain a (partial) list of bios settings? https://uwu.foundation/9SVYeaT.png https://uwu.foundation/7CvN1gC.png
oh it seems to be for WMI
Yeah this looks like WMI
Does it have a power button object in the namespace?
Would be interesting to see full logs ofc
Also pls send the dump
could also be related to _INI order, which I recently changed (but not yet merged into managarm)
so try git fetch && git checkout origin/master in the mangarm ports (although that will break find_by_signature a bit)
it does yeah
will try, and i can push the changes
that would be great, and a dsdt dump would be awesome too
yeah i can post it later
nice
@hollow elm is there an ECDT table as well?
no ecdt, linux says ```
[ 0.964029] ACPI: _SB_.PCI0.SBRG.EC0_: Boot DSDT EC used to handle transactions
nop, nothing happens
okay yeah its definitely the AML thinking we're a legacy os
there are some queries happening, and a notify that goes ignored for _TZ_.THRM, but nothing for the power button
do the fn+whatever keys do anything?
hm good q, didn't think to try them
mmm i hate usb
qemu-system-x86_64 -m 2G -device qemu-xhci -device usb-host,vendorid=0x13fe,productid=0x4200 boots, but on my laptop the usb msd driver doesn't seem to pick the usb stick up
lol
also lid and AC
ac i can't test because the battery is kinda dead 
anyway its definitely a result of misconfiguration
could be order thats currently in managarm
could be some opregion is read incorrectly
they use indexfields a lot in your laptop
can you give the latest uacpi master a try before i do more debugging pls
yeah ofc
thanks
also pls check that there's 100% no ECDT there ls /sys/firmware/acpi/tables | grep ECDT
because we had a similar issue in qwinci's laptop and that was because of that
qookie@selenium ~ λ ls /sys/firmware/acpi/tables | grep ECDT
qookie@selenium ~ λ ls /sys/firmware/acpi/tables
APIC CRAT dynamic FIDT IVRS SSDT10 SSDT13 SSDT2 SSDT5 SSDT8 VFCT
BGRT data FACP FPDT MCFG SSDT11 SSDT14 SSDT3 SSDT6 SSDT9 WSMT
CDIT DSDT FACS HPET SSDT1 SSDT12 SSDT15 SSDT4 SSDT7 TPM2
qookie@selenium ~ λ
yeah ok
/sys/firmware/acpi/tables/dynamic/ and /sys/firmware/acpi/tables/data/ are empty
because it does feature detection in the _REG method
just like qwinci
so if thats called early it will set the bare minimum features
but if there's no ECDT that should be correct
yeah basically the power button is unconditionally notified for query 28
Method (_Q28, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
Notify (PWRB, 0x80) // Status Change
}
so its 100% EC programmed incorrectly by AML
but why is that I currently have no idea
i come bearing new findings
Fn+F2 (brightness down) and Fn+F3 (brightness up) trigger ec queries 16 and 17 respectively, which end up notifying the vga acpi node (which has no listeners), and this only works once (and io-apic irq 7 is left unacknowledged so perhaps it requires the host's ps/2 driver to work),
at random times query 128 happens, which notifies the thermal zone, but again no listeners,
opening and closing the lid triggers query 138, which notifies the lid object, but again no listeners,
holding the power button for a while (but not long enough that it triggers a hard power off, letting go just before it shuts down) triggers query 153, which does nothing (?),
short pressing the power button does nothing
Yeah no listeners just means nothing in managarm hooked it up
Long press shutting down makes sense
Because it invokes smm
But yeah what you said confirms my theory
i'd expect it to be implemented in the chipset itself, but the query just before the hard shutdown happens is interesting
Just need to figure out why it thinks were below windows 7
Its like an emergency notification
yeah but it doesn't seem to notify anything
Because managarm doesn't install any notify handlers for those devices
Its supposed to be listentened to by a host driver
i mean, there was no warning saying there are no listeners
What device was it notifying?
oh _Q99 is literally a noop ```
Method (_Q99, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF
{
}
forgor
Is this latest master?
Nah I didn't
huh does windows vista and below not deserve the power button?
I think it doesn't support Notify interface for it
god bless hp ```
Device (PS2K)
{
Method (_HID, 0, NotSerialized) // _HID: Hardware ID
{
If (W8OS ())
{
Return ("*HPQ8001")
}
Else
{
Return ("PNP0303")
}
}
Lmao
WeightOS
They did
EC fun
No idea why
most likely custom memes they do which goes over the PS2 interface
also i wonder, do firmware developers have some special asl compiler that accepts longer names and just shortens them or do they actually suffer through 4 character names
afaik they only use 4 letter names
ig the fact things like W7OS are even legible makes that pretty clear
WsevenOS
They actually do
There isn't any extension or anything
I mean, they could have made a simple custom preprocessor
yeah i was thinking as a non-standard thing on top of asl
that just hex(os.urandom(2))
that'd make debugging annoying though ig
unless you teach the os about the random 4 characters -> name mapping
The thing I wonder about is how they make the WMI memes
the wmi bios settings list made me curious
because it lists things not exposed in the actual bios
Could be leftover from other laptops
it allows windows (or well, HP prop programs) to change the settings
Package (0x0F)
{
"Manufacturing Programming Mode Counter",
"Place holder ",
"\\Place holder for Path",
One,
Zero,
One,
0x0376,
0x03,
" ",
" ",
" ",
Zero,
Zero,
0x0A,
Zero
}
Place holder for Path
that might actually be a read-only counter and not necesarily a write
probably yeah but still kinda interesting
that is some cursed ass aml
but i don't think one should expect laptop firmware manufacturers to put in much effort and/or think too hard
If my kernel does not yet support SMP can i just declare the functions from the api headers for locking as always returning true?
they are supposed to sleepable locks, i think
so they are still important
Yeah but isnt the sleeping in case they were already locked? ("which cant happen")
i think the return value specifies whether you could acquire it before the timeout
as in they're not supposed to make the thread calling it nonpreemptible
Should be fine
i defer to the author's advice
Well technically yes
In reality probably won't matter
If (SRCM (MFLG, "MPMLock", 0x07))
{
If (SCMP (Local0, "Serial Number"))
{
DerefOf (N00D [Arg0]) [0x03] = One
}
If (SCMP (Local0, "Product Name"))
{
DerefOf (N00D [Arg0]) [0x03] = One
}
If (SCMP (Local0, "UUID"))
{
DerefOf (N00D [Arg0]) [0x03] = One
}
curious
SRCM is a strncmp afaics
So i have to implement the locks?
And cant just return "aquiring lock was successful" every time
hmm and MFLG is just a 64 bit field at 0xFF007000
idk why i am digging into this but this is very interesting
Well
I cant promise it won't break, but for truly single threaded workflows yea
Since aml mutexes are recursive anyway
couldn't you have issues if you do normal acpi work on one thread, and posted work on a separate thread, and query execution is posted from the irq handler?
they only mentioned not having SMP
Yeah of course
Lol
Okay so I would definitely debug this if I had the hardware, there are lots of things to check or dump, but idk how interested you are in that
uACPI doesn't have a way to override dsdt but would be interesting to recompile this with debug prints
And e.g force write WIN7 in EC as 1
Etc
Tons of things you could do
i'd be up for some debugging
i also need to figure out the parameter error i'm getting in the xhci driver when configuring the endpoint
but for that i think i have an idea from when i was talking with nooby about his xhci driver
Yeah if we had working xhci we could also properly inspect logs
Right now I guess thats impossible as well
i am forgetting to set some fields in the device contexts :^)
well we could just rearrange init and the initramfs a bit to put dmesg and less on it
and the ps2 driver
although not sure if less would work on the kernel console :^)
i can try fixing this and seeing if it helps
iirc i am missing the ESIT and polling interval fields (oops
)
ofc qemu doesn't care about the polling interval
even for hid
Oh if you can fix it that would be amazing, if not we can come up with something else
@hollow elm and pressing the power button does do something for your Linux right?
yeah on linux it is handled and passed on to user space
Ok ok just checking who knows
and triggers the kde shutdown prompt
Yeah makes sense
Also I think we unconditionally enable the fixed event for the power button (without checking fadt), maybe this somehow messes with the ec
Could comment that out but I doubt thats it
i hate the xhci spec
its fine™️
"Refer to section 6.2.3.8 for more information."
the 6.2.3.8 is a link, click it, get taken to the section
"Refer to section 4.14.2 for the definition of an “ESIT” [...]"
the 4.14.2 is not a link
at the very least 4.14.2 is the correct section
there are some references that are off because they added stuff inbetween
Lmao
here's an example: in table 6-21:
TD Size. This field provides an indicator of the number of packets remaining in the TD. Refer to
section 4.10.2.4 for how this value is calculated.
section 4.10.2.4: "4.10.2.4 Babble Detected Error"
section 4.11.2.4: "4.11.2.4 TD Size"
Lol
Added very detailed examples on how to tie acpi into the driver system and enumerate the namespace https://wiki.osdev.org/UACPI#Namespace_Enumeration_.26_Finding_Devices
Method (^BN00, 0, NotSerialized)
{
Return (Zero)
}
Method (_BBN, 0, NotSerialized) // _BBN: BIOS Bus Number
{
Return (BN00 ())
}
least insane AML
prob could reuse the code from https://github.com/kora-org/ydin/blob/rewrite-old for an uacpi test kernel
slightly rewriting it too with codes from the main zig version translated into c
managarm is a thing already
its much more advanced, basically ruling out kernel being broken at this point
no need to maintain a test kernel in addition to uacpi
is there a particular reason detecting pointer size is done this way?
as opposed to something like sizeof(void*)?
Im asking because it causes my riscv tests to fail 
Probably because sizeof is unusable from macros contexts
I dont even remember where this is used, id have to check
Riscv should be added to the list definitely
ah I didnt know that, dont do a lot of macro stuff
but yeah, riscv support would be helpful (for me lol)
ah it does, nice
Ye
fwiw thats the only thing that prevents it from building on riscv
cant say if it runs just yet because clang generates relocations I havent implemented 😅
very kind of you both to explore risc-v with uacpi
I think that's the define anyway
i would like to work on a risc-v keyronex against but i decided to wait until risc-v acpi is a bit more established (you needed a custom qemu for it to be any use, last i worked on it)
Yeah thats nice for sure
Yeah riscv stuff is not yet officially there
tbh its a totally selfish goal for me, I want my kernel to be as uniform as it can - will see how that goes when it gets uacpi loaded 😛
yeah riscv/acpi is a huge WIP
will do, thank you 🙂
This strips out huge chunk of code for supporting full acpi hardware
Its not mandatory to disable it ofc
Its autodetected otherwise
i had a quick google search for risc-v acpi and someone is coping and seething about it
you posted cringe mdp_cs
Giant skill issue
there's more to it than acpi.sys and acpi-ca
the "easier to implement drivers for each power IC" bit also led me down the garden path, i thought he was being sarcastic at first
This is just wrong on so many levels
no one will ever deny acpi is complex, but such is the price of flexibility
True
it's a far cry from a format loosely inspired by Open Firmware's device tree but turned into a static blob
Yeah
Basically yeah, and features like deferred execution from an interrupt handler are really difficult to get right from scratch
Which you must have for the full package
At this point the only bad thing about managarm is poor driver stability
But that dies in userspace luckily
why?
try #if sizeof(void*) == 4
Because pointer size varies
why not #if UINTPTR_MAX == UINT32_MAX?
Have you tested on 32 bit machines copyobject abuser
you don't generally need to branch on this
because that means im relying on some other system header
that would have to be replacable by the user etc
like 32-bit only pre amd64? no, i dont have one that old
but uacpi is tested in 32-bit mode in normal ci
I mean you are already using stdint.h in types.h (that can be overwritten by the user as uacpi_types.h)
are those defined in stdint.h?
yes
ig i could do that
but then again im not sure thats better than checking the architecture
at least it would work on more architectures without you needing to add them there
other than that probably not
that is true, yeah
but there's only so many architectures with acpi
itanium, x86, arm, and risc-v
Managarm has a pretty big image and it doesn't actually boot on a ton of hardware, so it's not that useful as a debug image....
Like, even if the acpi init pass can't really test much when it dies somewhere else down the chain
it does boot almost everywhere, but drivers die in userspace so its not a big deal
Does it reach deep enough for testing power button and stuff?
It doesn't on my PC
thats in the kernel so that almost always works
It dies on USB
And on my laptop it dies before even reaching the kernel
that shouldnt prevent the power button from working
Idk it's in a panic state
anyways it's still not a nice test image for quickly checking a bunch of functionality 
well a proper test image would need a full blown kernel with a sophisticated scheduler, so thats like 10k loc of code
Do you need a sophisticated scheduler tho
can't test events otherwise
I can take the core of my C# kernel very easily
It has a scheduler with events, it has a simple memory management
well if it has a higher success rate at booting than managarm and you actually port uacpi there then that can work as a test image as well 
I might try it if I ever get free time :^)
that would be great
much easier for an OS to implement drivers for each power IC
hell naw
no way he said that
that's why i thought he was being sarcastic, but apparently not
finally got around to extending the test suite to run the 500 publically available acpi dumps
a lot of them timeout because they infinitely poll some MMIO or IO regs
thats where my loop timeout detection PR comes in as well
what's the 20 fails, timeouts?
yeah, all of them are timeouts
nice
Unfortunately 150 of these 500 don't have the AML to extract for DSDT
only its disassembled representation
which might not be compilable
or at least its not possible to even extract with any existing tools
so thats kinda unfortunate
fuuck this doesnt work on windows lol
ill have to modify the repo
ok that was just one file, great
okay so with the timeout branch only 3 are failing
and its really annoying blobs
Method (RR_M, 1, Serialized)
{
If ((Acquire (MUEC, 0xFFFF) == Zero))
{
Local0 = Arg0
Local1 = (Local0 & 0xFF)
Local0 >>= 0x08
Local0 &= 0xFF
CDT2 = Local1
CDT1 = Local0
CMD1 = 0x80
ESEM = 0x0F
Local0 = 0x7F
While ((Local0 && CMD1))
{
Sleep (One)
Local0--
}
If ((CMD1 == Zero))
{
Local0 = EDA1 /* \_SB_.PC00.LPCB.EC0_.EDA1 */
}
Else
{
Local0 = Ones
}
Release (MUEC)
Return (Local0)
}
Return (Ones)
}
it does 127 sleeps for 1 ms
and this shit is called a lot of times
so the blob takes longer than 10 seconds to load and test runner thinks it timed out
Firmware developers are very smart as we can see
1 second total sleep time in the end
hmm on linux tihs only takes 1.8 seconds to load
runner/build-linux-64bits/test-runner 0.33s user 0.25s system 31% cpu 1.837 total
with UBSAN+ASAN
why is it so slow on windows
std::this_thread::sleep_for(std::chrono::milliseconds(msec));
like
maybe this takes longer on windows for some reason
Yayy all passes if i port my while timeout commit
thats with ubsan and asan
the only problem is on windows where sleep takes longer for some reason in debug mode
maybe allow longer timouts in debug mode?
the timeout is in the python test runner
i could bump it, yeah
still annoying
its currently set to 10 seconds
man that sucks
Is this decompiled from AML?
Yea
me when firmware developers
and their error paths
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If ((TPTY == One))
{
Name (SBFB, ResourceTemplate ()
{
I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2CA",
0x00, ResourceConsumer, , Exclusive,
)
})
}
If ((TPTY == 0x02))
{
Name (SBFS, ResourceTemplate ()
{
I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2CA",
0x00, ResourceConsumer, , Exclusive,
)
})
}
Name (SBFI, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0009
}
})
If ((TPTY == One))
{
Return (ConcatenateResTemplate (SBFB, SBFI))
}
If ((TPTY == 0x02))
{
Return (ConcatenateResTemplate (SBFS, SBFI))
}
}
brooo are u fucking kidding
lmao
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If (GTPM ())
{
Return (Zero)
}
If (GCTP ())
{
Return (ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xFED40000, // Address Base
0x00005000, // Address Length
)
IO (Decode16,
0x0CB0, // Range Minimum
0x0CB0, // Range Maximum
0x08, // Alignment
0x10, // Length
)
})
}
Else
{
Return (Zero)
}
}
Thats not how you _CRS 
Brooo hand rolled fucking resource template
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (NAM, Buffer (0x0F)
{
"\\_SB.SDHB.BRCM"
})
Name (SPB, Buffer (0x0C)
{
/* 0000 */ 0x8E, 0x18, 0x00, 0x01, 0x00, 0xC0, 0x02, 0x00, // ........
/* 0008 */ 0x00, 0x01, 0x00, 0x00 // ....
})
Name (END, Buffer (0x02)
{
0x79, 0x00 // y.
})
Concatenate (SPB, NAM, Local0)
Concatenate (Local0, END, Local1)
Return (Local1)
}
[uACPI][ERROR] invalid/unsupported serial connection type 192
i guess i should support that
Well ACPICA doesnt support it
so i wont either, whatever
maybe just make it a warning instead
well i have to be able to convert it somehow
for it to be a warning
because this aborts the _CRS invocation
hmmm, you also want a way for drivers to have custom types in there probably
probably, but acpica managed to not support it for 30 years and be fine
i guess no one uses it
is that your inspiration
ah, so that's (_CRS) what uacpi_get_current_resources calls and gives back to you? (message from nyaux chat, dont wanna pollute it)

lol
like from a user perspective linux doesnt need that and it supports like all hw out there
I do wonder what windows do
probably some proprietary driver that handles this serial connection
yeah
there's also possible_resources (_PRS)
which is a list of possible values that can be used to override the current resources
setting everything up properly is quite involved lol
yeah
and this resource conversion thing has a bytecode VM for converting them
its pretty insane
here's one for IRQ for example
Some of these public blobs do absolutely insane things
crazy uacpi survives all of that
good fuzzing experience because of qookie i guess
Added a test case for infinite while loops
600k iterations with ASAN+UBSAN and O0 is pretty decent
(in 3 seconds)
can aml integers be arbitrarily large?
only 64 bits
yeah
idk if its worth guarding against 64-bit overflow lmao
unless this runs on nasa quatum computer
if aml is revision 1 the ints are 32 bits, 64 for >= 2
ah right i remember something about 32-bit integers and acpi
yeah its an annoying backwards compat thing
also if DSDT is rev 1 and SSDTs are 2 everything is still done as 32 bits
this can be seen on real hw too
huh
basically only DSDT revision matters
do you actually support that?
of course
how much do you even need to do to handle it? just & 0xFFFFFFFF on every arith operation?
i have a UACPI_PARSE_OP_TRUNCATE_NUMBER
thats basically applied to any math operation
yeah, basically that
hm what about a load from a 64-bit field?
its loaded as a buffer
ah
if in 32 bit mode
not sure what i expected
also on NT if u have a qword immediate its still loaded as a qword
even in 32 bit mode
so i do that as well
and its never truncated unless u do math on it
interesting
yet another acpica incompatibility
yup
well actually no
it would only store the first 4 bytes
the rest is zeroed

but i guess its implementation defiend ofc 
i know how nt does it
acpica recently fixed ToHexString
aka ToHexString(0xF) == "0xF" and not 00000000F
god bless
a drop in the bucket but oh well
making that one machine where the fw engineer went insane work on linux
lol
it was actually from a bug report yeah
Some firmware does ToHexString and then Mid to parse the serial number
So on linux it was printing out bogus serial
ig that use makes sense
yeah
not the worst example i can think of
Yay large tests pass on CI as well!
In both 32-bit and 64-bit builds
Big
this bumps the ci up to like 6 minutes on ubuntu
but its fine i guess
@fiery turtle are kernels using uacpi supposed to discover all devices using the uacpi methods? like you can find the ps2 keyboard using acpi, how about pci devices? or is that better done by probing manually
Well you can discover PCI roots and from there match the devices
But not all devices are guaranteed to be in the namespace
So of course a pci subsystem lives on its own
And talks to acpi as needed
For pci acpi is more of a nice extension, not a replacement
i see, i was just wondering since my way of enumerating pci devices is pretty janky and i thought that maybe there is some big brain acpi way to put me out of misery :^)
What sort of jankiness?
How do you do it?
i can send the code if you want to take a look, its around 30-40 lines
ive written it more than a year ago
i dont understand the way it works lmao
it might be that i just dont remember how exactly pci works anymore, but this isnt very good code either way, it doesnt support mmio which i think is preferred way of doing pci
Looks fairly okay barring some magic numbers
Brush up on osdev I guess
yeahhh
i had to do some msi-x stuff yesterday for xhci so it was a nice reintroduction into some parts of my old codebase
Nice
i discovered some funny bugs
like not having a separate stack for the page fault handler
Are you reviving an abandoned project?
and now when i add a field to my xhci controller struct i get an kvm error :D
Damn
ehh im not sure what i wanna do, i wanted to start from scratch
Similar bug like @kindred beacon
Makes sense
but zig i just meh, so i guess im working on it for experience so that i can make something better in the future, rather than have the zig kernel be actually good
compiler is poo poo
