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

[winter orbit]

That waits for work

I’m not saying modern standby is GOOD just that your argument here is a little shaky

The bigger issue is

• Linux not being able to accept real communication with the vendors to fix this shit

• Microsoft.

[vast kestrel]

I mean, in deep sleep states of the cpu is there even a difference between that and s3

[winter orbit]

No S3 has been dead since core 2 duo

[vast kestrel]

in reallity what you probably want is modern standby while the laptop is idle, and s4 while the laptop is with lid closed

or even s5 for that matter, depending on the design of the board

[winter orbit]

you just need to not wake up everything down to the WiFi card to do “”work”” while in sleep

[vast kestrel]

(its very iffy when wakeup can happen from s5 and from which hardware sources)

[winter orbit]

Lid closed is very okay to do updates imo

sleep after sometime isn’t

[vast kestrel]

lid closed usually means someone is putting it inside of a bag, so you really should not

man it reminds me of the previous desktop I had

windows would enter sleep after 15 minutes

and then after 1 minute in sleep it would wake up

and then again wait for 15 minutes and so on

[winter orbit]

yeah that’s rough

[vast kestrel]

and that wakeup after a minute of sleep was for windows updates

I checked with the logs

so stupid

[winter orbit]

Reactos plans to handle modern standby

So I implore other osdev projects to try too

It’s not as bad as people make it out to be

[tired temple]

No, I definitely don't want thrashing an SSD with 16GB on every lid closure. STR is for this. Hibernation is not.

[vast kestrel]

I mean, technically nothing requires you to save the entire ram

the reason I said s4 and not s5 is because alot of times in s5 the board will cut power completely to PCI, so alot of required wake sources might not work

I think usually chipset devices keep work in s5 given the correct chipset config

like wakeup from usb

[winter orbit]

yeah

[vast kestrel]

tho tbh, with the correct ACPI

modern standby with correct OSPM should be == s4/s5

[winter orbit]

Always no matter what you do with ACPI firmware developers will always ruin it for you

[vast kestrel]

or well, practically equals

[winter orbit]

[vast kestrel]

man so many devices have missing OFF/ON for PCI

if every device had proper OFF/ON, you could totally use modern standby as a replacement for s4/s3

[winter orbit]

It’s stuff like that, that always makes me cringe at my job title

[vast kestrel]

in deeper sleep states of the cpu everything is saved into l3 cache and the rest is turned off, so its practically s3 anyways

[winter orbit]

“UEFI Innovation Engineer”

[vast kestrel]

don't forget to use the Intel® Platform Innovation Framework

[winter orbit]

Innovation? We can’t even make our current spec work

[vast kestrel]

Intel® has so much innovation they even have an Innovation Engine

[fiery turtle]

Could always innovate the spec to make it reflect real life

[vast kestrel]

I am the spec

[winter orbit]

technically I am

2027

2030

Maybe

The rate at which stuff we complain about goes down the chain makes ReactOS development. look fast paced and efficient

[fiery turtle]

Lmao

Good effort nonetheless!

[calm latch]

I kinda somewhat like modern standby

I can close my laptop's lid, and still be able to access files through smb on my other PC

[fierce kiln]

complain.reactos.org when

[flat badge]

It's probably more firmware vendors that don't actually care to provide a compliment implementation tbh

On both of my laptops linux can drive low power idle just fine

But i only buy laptops with explicit linux support

[winter orbit]

This isn’t true, most of the attempts to make the same communication with Linux as we have with MS has been met by pure asinine behavior

Linux’s maintainers care more about their ego then trying to work to make the kernel better at this point

[flat badge]

Arbitrary Linux kernel devs may not care but OEMs do care

[winter orbit]

Do they? You’re saying firmware vendors don’t care and now that OEM cares but at least Phoenix Insyde and AMI all send source code to OEMs and they then modify it to build the final bios

Our business models are providing utility’s and a baseline source tree

[flat badge]

yeah ik

[winter orbit]

OEMs are the ones that make almost all of these final choices

[flat badge]

I'm saying: if I buy a Dell business laptop that advertises linux support, they will make sure that sleep actually works on linux

If i buy a random gaming laptop that doesn't advertise Linux support, all bets are off

[winter orbit]

No, they will TRY, there’s been numerous times Dell has approached Linux maintainers behind closed doors (and even outside of them??) and Linux’s reaction to real concerns against their choices have been met with unprofessionalism

[flat badge]

I don't doubt that but linux devs are not a homogeneous group

[winter orbit]

They’re FAR close to one than any tech corporation

Not to mention that when it comes down to it the same few people have the final say on a lot of things

And one of them outright despises ACPI, and makes adamant choices against that personal vendetta

We do some pretty aggressive Linux testing here but it’s more to work around stuff they said no to lenovo for then actually test functionality :)

[lofty dragon]

yeah tbh Linux is probably the reason why device tree bullshit is so prevalent on non-x86

[flat badge]

But in any case, low power idle works fine on mainline Linux, given that i have two laptops that do it just fine

[lofty dragon]

i am glad that has started to change though

[flat badge]

Well before dts there were hard coded peripheral addresses so dts are at least an improvement in that regard

[lofty dragon]

neither are as good and flexible as ACPI lol

but yes, hardcoded is even worse

[flat badge]

I mean sure, acpi is definitely more flexible

That's also the reason why it's NOT used on small socs

[lofty dragon]

those small socs should be embedded only and not "general purpose computing devices" then

yet most phones use dts

because Android

aka Linux

[winter orbit]

I mean, it’s just unprofessionalism on the subject I’m more annoyed with than anything else.

Firmware developers aren’t the most competent programmers, but as a recent example the snapdragon SoC thing with the X Elite laptops

[lofty dragon]

phones are definitely machines that should be using ACPI and UEFI

[winter orbit]

None of that would have happened that way if it wasn’t for how Linus and the other main maintainers treats people behind closed doors :)

[flat badge]

What does the customer gain by that?

[lofty dragon]

what does the customer gain from having ACPI and UEFI on x86 PCs? just use dts there as well, actually, lock down the bootloader too

[winter orbit]

Apparently a lot since most devices are using it for their pre-boot OS now.

[flat badge]

I agree from a technical perspective: these devices are powerful enough that having acpi would not be a burden

But in the real world it's simply not a technical issue

[lofty dragon]

we're talking about ACPI, the Linux kernel, and device trees

we left "real world" realm a while ago

so that comment is not pertinent

[flat badge]

On x86 they gain that they can mix and match hw and software

Pick some machine, pick some OS, it just works (mostly)

[lofty dragon]

and how is that not something that consumers would benefit from, exactly?

even on phones

[flat badge]

This feature is expected in the workstation + server markets

[flat badge]

It is, but vendors are actively trying to prevent it

Because they want to lock you in

[lofty dragon]

but your original question was "what does the customer gain from that?"

you are moving the goalpost

[flat badge]

Even if they had acpi, they'd still just lock the bootloader

[flat badge]

No, I'm saying: acpi won't get you to this situation on phones anyway

[lofty dragon]

if Linux was more forceful in trying to get the only firmware/chipset interface standard that exists and works (in UEFI/ACPI) adopted, i am sure that wouldn't be an issue

you could make the tivoisation argument

Linux could've moved to GPLv3

or any other method, really, like rejecting patches upstream from non-complying tech manufacturers

but they actively chose to allow for this to happen, and even embraced that

and i feel like this is what @winter orbit 's original point was getting back to

[winter orbit]

[flat badge]

If Linux was more forceful in this regard, it'd just be adopted less

[lofty dragon]

and what would the alternative be?

by the point Android had a foothold (like 10+ years ago), there was no alternative

i am sure tech companies would've capitulated

making their phones open sounds like less of a pain in the ass and cost than developing their own non-intercompatible OS from scratch

[flat badge]

Yes, but that's not the question right? Android probably wouldn't have existed if Linux was more hostile towards adapting tech that companies want to use

[lofty dragon]

i doubt it

you're working off of hypotheticals of hypotheticals now

the facts are that Linux embraced tech companies' bullshit

what could've happened if it didn't is solely up to speculation, and not a valid argument imo

they didn't even so much as try

[flat badge]

i mean if you look at it from the perspective of a vendor who controls hw, firmware and OS, doing ACPI just doesn't make sense

[lofty dragon]

they went actively against the GPLv3, but yet still chose to use the GPLv2 rather than a permissive license

they chose the cuck-to-companies in-between

[flat badge]

without acpi you need to:
design hw -> add drivers for your for your prioprietary hw to linux
with acpi it becomes:
design hw in a way that can be driven by acpi -> write "driver" in aml, or if it's too hard, offload it to a coprocessor that aml talks to -> adjust linux acpi code to make sure that it works

it's just extra work

On a non-ACPI system you can just design based on the assumption "oh, you don't have a driver for this proprietary clock source? though luck, you won't get any peripherals to work"

On ACPI, you need to at least bring the system to a somewhat usable state after the namespace is initialized

[lofty dragon]

and how is any of this a bad thing for the customer?

[flat badge]

well, the advantage is that it's cheaper

[lofty dragon]

at worst it's transparent to them, and at best it allows them to do things like swapping OS

by how much?

[flat badge]

idk

[lofty dragon]

$10 per phone? $20?

probably much less

[flat badge]

I'm not saying that it's good, I'm saying that it's rational for the manufacturer to do it

[lofty dragon]

sure, but the argument was about Linux doing nothing to at least try and prevent it, but rather do the opposite

[flat badge]

I, too, would prefer a world where phones were accessible and you could run your own SW on them

[lofty dragon]

if you're making an OS and you choose to support non UEFI/ACPI hardware, you're part of the problem

thank god Microsoft is embracing this point

Microsoft is... Linux isn't, just let that sink in lol

[flat badge]

It's also not that non-ACPI hw is inherently evil

IMHO in an ideal world we would have neither DTs nor ACPI

but properly specified interfaces

[calm latch]

It doesn't on my laptop

Linux just doesn't sleep on it

[calm latch]

Windows phone (8) used UEFI + ACPI?

[pine leaf]

I disagree, device trees are awesome

how else do you work with existing hardware that has no potential interface to deal with ACPI or UEFI

say, what happens when you're trying to run something on a MIPS router

or a PowerPC game console

or anything else that's even remotely nonstandard

"just use ACPI + UEFI" is not an option

if you want to write your OS for a hypothetical future that may not ever happen, that's up to you

if you want to write an OS for devices that actually exist, and you want to have broad support, even for weird devices (like Linux does).... well, there isn't really any other option

supporting actually real devices is not a "problem"
arguably, the opposite (fantasizing over a hypothetical future where literally everything is UEFI+ACPI) is a problem, much more than just supporting DT

[slim panther]

depends

imagine if every PC would need their own set of linux drivers just because the motherboards are slightly different

i would advocate for a configuration system that uses device trees, but still requires a higher level abstraction for kernels

[pine leaf]

you can do that with DTs as well
many things have common drivers

for example, anything that runs on top of i2c, gpio, or spi, should just work across any host, with just one driver

this applies to much more

[slim panther]

the reality is different

[pine leaf]

those are just the big examples I can think of off the top of my head

[slim panther]

just look at ARM GIC

there's at least 10 different gic drivers in linux

because every vendor just does whatever they want

even arm servers with acpi just work

[pine leaf]

well that's an issue with SoC manufacturers
has nothing to do with DTs

[slim panther]

so?

we don't live in a theoretical world

if there's no popular interface forcing them to do certain things, it'll always be like this

[pine leaf]

and?

I don't see much problem with that

[slim panther]

of course not

[pine leaf]

you either support that GIC, or you don't

nobody's forcing you to support [x] model

[slim panther]

great, so you like having paperweights for years until someone dedicates their time to explicitly support it vs. the hardware vendor doing that work for you and it works in most places ootb

because this is what i have to deal with all the time

[pine leaf]

if you don't want a product that doesn't just work, then... don't buy the product that makes weird hardware choices?

[slim panther]

[pine leaf]

lol

still is not a problem with DTs
the ability to support such products is still worth it, since they already exist, and you can't just make them vanish

that's why DTs are great, you can support any batshit insane setup

[slim panther]

i never said i hate DTs

they have their purpose

that just isn't for PCs

[pine leaf]

I never said they are for PCs either

[fiery turtle]

it is a problem with DTs, because since it's just a static description of the system manufacturers dont get any chance to abstact anything away behind "aml", everything must be exposed as is, every tiny chipset specific driver must be in place for the system to work

[pine leaf]

and what do you do about machines that can't possibly support ACPI

[fiery turtle]

idk, im talking about new hardware produced today

[pine leaf]

and that's exactly the issue
not everybody has hardware that is made today (or in some cases doesn't even exist yet)

[slim panther]

#1217009725711847465 message

[fiery turtle]

but thats a made up argument

no one uses DTs just for old hardware

[pine leaf]

I'm talking about devices that actually exist in our physical world

[fiery turtle]

they actively use it for new hardware which could easily support acpi

but i agree that its a very good solution for old hardware

[pine leaf]

because that's already the standard
changing it would need a ton of R&D

but sure, fair enough

if the device really could support ACPI, then sure, that is kinda silly

[fiery turtle]

what ton of R&D lol

acpi for arm has been standardized years ago

qualcomm laptops ship acpi

[pine leaf]

I'm more arguing against what Mint said here

if you're making an OS and you choose to support non UEFI/ACPI hardware, you're part of the problem

[pine leaf]

I don't find supporting existing devices as a "problem"

[fiery turtle]

🤷‍♂️

[flat badge]

But that also makes it way easier to support from the hw manufacturer's pov

ACPI support realistically requires you to take acpi into account at the hw design stage

[flat badge]

acpi for arm started shipping maybe 5 years ago and only on hyperscalers

okay, it was 6 years ago

still, it took way longer from spec to actual hw than on rv, for example

[slim panther]

that was a matter of weeks

for rv

[flat badge]

imho the sane alternative to both DTs and ACPIs would be communicating with a management interface on the SOC over a well defined protocol

that'd be way less insane than AML

[slim panther]

yeah

i mean something like SBI but way more advanced and in-depth would be cool

[fiery turtle]

yep

[flat badge]

intel, microsoft etc managed to design AML so poorly that even if you have an AML interpreter in the OS, you still call into proprietary management chips for half of the requests

you basically only need AML to send the right commands to the EC or SMBUS controller

the actual work is still done off CPU

so why not just make that a documented interface instead and throw AML out

[fiery turtle]

yeah

but thats just theories

aml already exists

and half is better than all lol

[flat badge]

well, the other half writes to PCIe config space

or returns hard coded data

[fiery turtle]

impl details

[dire owl]

I mean, they could've just forked Linux

[dire owl]

Could it tho? It was GPLv2-only from the start.

[crude summit]

you can make it v3

anyone can upgrade it to a newer gpl whenever they like unless the devs added a clause to say you can't

that's kinda sucky about the gpl imho

[flat badge]

linux doesn't have the "or later" clause

[dire owl]

there's two variants, one without the "or later" clause
hence I said "GPLv2**-only**", instead of "GPLv2**-or-later**"

meaning with Linux you can't

unless you ask every single contributor ever to agree :^)

[urban galleon]

uAPM when? Of uPnP

[fiery turtle]

never

[woven citrus]

yes uapm

[crude summit]

or later is the default, so it's a modified gplv2? I removed the upgrade clause from one of my projects too some years ago but now I prefer mit or Apache 2.0 licensed stuff

when I did it there was no variant and no GPL V3 yet

but my concern was "what if they make a V3 that has terms I dont like?"

[vast kestrel]

I am pretty sure Qualcomm does use uefi for their firmware, it's just locked down and unusable since it hardcodes the android loader

[vast kestrel]

Hardware reduced acpi is a thing, it needs a bit more software support but it's mostly so you can replace the single sci with whatever the platform needs

In the end 99% of what acpi does is have some way to get callback when something happens and then use Notify to tell the driver what happened in a standard way

[flat badge]

REST native soc, when? Just let me do

POST /dev/pcie_root0/:power
{"target": "D3"}

to the chipset

[pine leaf]

that still doesn't help you if you have a PowerPC, or a MIPS, or a SuperH, or an ARM7, where there's no spec for how ACPI should even behave
even on more "normal" architectures, nothing can help you if the firmware just doesn't implement it, and there's no chance of it ever implementing it

[kindred beacon]

Don't give #osdev-misc-0 ideas

[calm latch]

So embedded devices

[calm latch]

Windows Phone 8

[flat badge]

is there even ACPI for arm M profile?

or R profile?

probably not

[vast kestrel]

Yeah but Linux or anything similar doesn't run on M profile, and you don't really need them to, they usually run very domain specific stuff that use the library provided by the manufacturer

[vast kestrel]

I mean, it's really up to those companies to define what acpi tables they need to use, and yes i would expect companies like IBM or Mips to define these stuff

And ngl, listing interrupt controllers is like a tiny part of acpi

[flat badge]

the reality is that ACPI hard requires a lot of stuff that these SOCs just don't have

[vast kestrel]

The rest is completely independent and can be done using dsdt

Like what

[flat badge]

• All processors must support the C1 Power State
• The device power state definitions are device-independent, but classes of devices on a bus must support some consistent
  set of power-related characteristics.
• In a multiprocessing environment, all CPUs must support the same number of performance states and each processor
  performance state must have identical performance and power-consumption parameters

I can probably find more examples

[fiery turtle]

Linux doesnt even have support for non aarch64 acpi

And it's also little endian platforms only

[vast kestrel]

Just wait until you see the bi-endian Intel compiler :^)

Its implements big endian abi on x86 basically, for devices that have a shared address space with a big endian processor

[flat badge]

All devices must support the D0 and D3 states. Functionality available in D0 must be available after returning to D0
from D3 without requiring a system reboot or any user intervention.

[vast kestrel]

Those are some really basic requirements for power management to work at all ngl

If a device is unusable until reset after clock gating you have a bigger problem

[flat badge]

the 3rd bullet of this #1217009725711847465 message is already violated on basically all real time devices

where you have separate real time and rich OS processors

[vast kestrel]

I mean, some of those I have seen x86 platforms that are not compliant

There are enough x86 socs that come with an arm co-processor

[fiery turtle]

yeah this spec stuff can be changed and also literally nobody cares if this is violated

[vast kestrel]

But it's just included as a custom acpi device

[fiery turtle]

none of this is a hard requirement

[vast kestrel]

Yeah basically this

[flat badge]

well according to the spec it is

[fiery turtle]

spec is cool and all

[flat badge]

now if you argue "I can always ship non-compliant ACPI" that's true but it kinda invalidates your point that everybody should just ship compliant ACPI

[fiery turtle]

compliant acpi doesnt mean it follows the spec

in that sense no implementations are fully compliant

[flat badge]

besides, there are also requirements in the other direction

[vast kestrel]

Also most of these can totally be changed so hardware reduced acpi doesn't need to follow exactly

[flat badge]

i.e., what the OS has to do once it enables acpi mode

and people also don't want to do all of these things on small SoCs

like drive thermal zones correctly

[vast kestrel]

in most socs I seen Linux is still the one who needs to do it

By the OEM providing drivers for Linux that do

[flat badge]

all the stuff that i listed also applies to hardware reduced

[vast kestrel]

In some they have an EL3 firmware that ha dles it

But that's basically the same as SMM doing it on x86 lol

[flat badge]

well, or they just don't have thermal zones

and thus need no driver

but the ACPI spec says that the OSPM must be able to handle them

[fiery turtle]

thank god, otherwise any non-linux os will just cook the cpu

[vast kestrel]

I mean sure if you don't need to cool anything just don't define any thermal zone

[flat badge]

regardless of whether they are actually present or not ;D

[vast kestrel]

I once had Linux cook a cpu from using an older DTB meant for s different kernel version

[fiery turtle]

thats basically arm stuff for you

[vast kestrel]

But given all of these stuff practically only get a Linux port, and you already code in Linux able to handle it, is that really a problem

[flat badge]

yeah

[vast kestrel]

Like, 99% of socs never get anything other than some very specific Linux LTS port that is out of tree

[flat badge]

claiming that all devices could easily support ACPI means just that you don't understand the market for these devices at all

not even stuff like ZCU and other powerful industrial aarch64 SOCs support ACPI

[vast kestrel]

Yeah, and instead these devices use awful proprietary dtbs that have no spec or standard at all, just doing nothing and not working to make the spec be better fitted in a technical side is also harming

[flat badge]

This kit features an AMD Zynq™ UltraScale+™ MPSoC with a quad-core Arm® Cortex®-A53, dual-core Cortex-R5F real-time processors, and a Mali™-400 MP2 graphics processing unit based on 16nm FinFET+ programmable logic fabric by AMD.

^ same power state requirement already violated

[vast kestrel]

I am sorry including M co-processors under the same acpi requirements is not even in the theme of acpi

The main core that run Linux could definitely use acpi

[flat badge]

well, this board runs Linux

[vast kestrel]

I am not arguing that every tiny core in the system should be able to use acpi, but the thing that you run the conventional os that is 99% of the time Linux with no other option is

[flat badge]

not on the real time CPUs ofc

[vast kestrel]

Does the R5F run Linux?

[flat badge]

no

[vast kestrel]

Then yeah it's not part of the acpi system in my view

[flat badge]

well, ACPI cannot even describe this processor configuration

[vast kestrel]

Sure I would expect to be able to turn it on/off from the acpi system, but I don't expect full control over it from acpi

From my view it's just another device

The fact you can run code on it means nothing

Just like how a GPU is represented just fine, even tho it has firmware and a ton of power management on its own

I don't expect acpi to handle it fully, just put it to sleep or wake it up, and if it can wakeup the system I would expect that to be exposed by acpi as well

[flat badge]

well you still need to take it into account as a CPU e.g., when doing interrupt routing

[vast kestrel]

I see it as part of a driver that handles the rt professor

It's not just another cpu in the system in any way shape or form

[flat badge]

actually i'm not sure if the GIC that's connected to the R5 is also connected to the peripherals accessible from the application CPUs

but in any case, this setup is too messy to be expressible in the MADT (without making the MADT way more complex)

[vast kestrel]

I don't they should even be under the madt, as far as I see it the job of the madt is to provide the information needed to boot the OS itself, not every random coprocessor on the system

I would then expect it to be an ACPI Device that has some custom HID that the driver can bind on

[flat badge]

well, but you need to express somehow irq controller X and send/receive an irq to/from irq controller Y

[vast kestrel]

And it's not like Linux has an abstraction for this stuff either, each vendor exposes some random sysfs path with random nodes

[flat badge]

the MADT has to list all IRQ controllers, otherwise devices cannot advertise where their IRQs go to

[vast kestrel]

I mean, the irq controller dedicated to that core is part of that device no? The device has a way to send an interrupt to the main core, usually the exact same way a USB controller would

The fact the USB controller is a soc on its own with its own irq controller doesn't mean I need to know about it

[flat badge]

yeah but how do you express "the USB 3 can send an IRQ to the R5" if the R5's GIC is not in the MADT

it's not possible to do that in ACPI afaik

[vast kestrel]

You could define your own acpi or define your own acpi device that handles it, I don't see it as a job of acpi to express that in a generic manner since 90% of the time these do change per soc

[flat badge]

i mean sure, but at that point you're just reinventing DTs

[vast kestrel]

Heck even on the same vendor they almost never have the exact same driver or config for these stuff

Yeah but when 90% of the system can be abstracted in acpi, and the rest is custom stuff it's much better than 100% custom stuff

[flat badge]

also, this board runs mainline linux

so you'd need to shove all that franken-ACPI into mainline

[fiery turtle]

it is, have a device with _CRS, there's an extended interrupt resource which can provide a source which is a different acpi namespace node

acpi has a way to encode any of that stuff

doesnt have to be in MADT

[flat badge]

ah, i didn't know that

i stand corrected then

[vast kestrel]

I mean, I don't see it as franken acpi tho, the acpi system handles the main system

I didn't know that either tbh

I am quite surprised it can

[fiery turtle]

https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#extended-interrupt-descriptor

[vast kestrel]

I think over abstracting is bad, I don't think acpi should abstract everything

[flat badge]

i get that but I think this abstraction will leak

because the real time CPUs are not just any other device

[vast kestrel]

Like, I would expect an os without the code to drive these RT cores would be able to use acpi to just turn them off and not deal with it

And a system that can do more can query the device resource or even call a custom acpi function (there is that device specific interface stuff with the guids) to gather it

[flat badge]

how does linux even drive the r5f

it's not listed under cpus (not surprising)

ofc it has it's own firmware

https://github.com/torvalds/linux/blob/master/drivers/remoteproc/xlnx_r5_remoteproc.c

through some mailbox

[fiery turtle]

pretty small driver

[vast kestrel]

yeah its pretty common for most of these

alot of them basically have a shared sram that when you write to some random soc register it will reset the rt core and it will use the ivt that is usually by default at the start of the sram

so you just write your code to that sram, reset the core and done

[frank canopy]

dang there was a lot of talk in here while i was asleep

[frank canopy]

what sort of hardware even has ACPI on aarch64 actually? ive only got dtb stuff afaik so now im curious

[winter orbit]

Lumia 950xl and 950,
Anything that has EDK ports by community (one plus 6, pocophone f1 orange pi 5)
Any windows on arm device

Between all 3 there’s a decent amount of hardware out there now?

[frank canopy]

cool

wonder if its possible to use the edk firmware under the qemu orange-pi machine type (or otherwise get uefi/acpi firmware on a qemu aarch setup) since im not set up to run directly on hardware rn on any arch anyway

update apparently theres an acpi support option for the qemu arm virt board that just isnt listed in the docs lmao

wonder what its aml is like

tfw qemu arm virt board uses more modern acpi for defining its processors than the base x86 q35 acpi

[winter orbit]

yeah

[frank canopy]

found the part of qemu's code where it unconditionally says to use processor objects on x86 for some reason, and also the part where arm does its own processor device adding instead of using their generic code for it lmao

and by its own thing i mean qemu's arm virt board puts the processor devices directly in \_SB

also "When booting the VM with UEFI, UEFI takes ownership of the RTC hardware. While UEFI can use libfdt to disable the RTC device node in the DTB that it passes to the OS, it cannot modify AML. Therefore, we won't generate the RTC ACPI device at all when using UEFI."

idk why the comment implies a conditional there there isnt one

it just literally never puts the rtc in there

[winter orbit]

I saw comment here where someone said qemu’s firmware was at least semi decent

I would like them to retract this statement

[frank canopy]

if it seemed it before im looking at this acpi-on-arm code and im now in the wtf are you doing camp

[winter orbit]

swag

[real jetty]

I found that the less used features in qemu are often written horribly

[tired temple]

Can you print that secret option?

[vast kestrel]

couldn't they have the _STA check for it

Like literally the whole point of having it is to allow for dynamic checks

[flat badge]

That makes sense

UEFI has a runtime service to read the rtc

So qemu cannot both provide that service and hand the rtc to the OS

The runtime service is the de facto standard way to do an rtc on aarch64 uefi

https://uefi.org/specs/UEFI/2.11/08_Services_Runtime_Services.html#time-services

[flat badge]

well, they'd need to make _STA to return false unconditionally which seems pointless

[vast kestrel]

Well for once real hardware AML does it all the time, you will have a bunch of nodes ready made for a bunch of root ports that the bios in reality might disable unconditionally because the motherboard doesn't support all the root ports

And it sounds like an optional thing for uefi to take ownership of it

Or maybe I am not understanding what the point of that comment is, if it's not needed at all then it's all fine lel

[flat badge]

On x86 it's optional to support non uefi aware OSes

During runtime, if a PC-AT CMOS device is present in the platform the caller must synchronize access to the device before calling GetTime().

There is no such provision in the spec for arbitrary rtc devices

[vast kestrel]

I see, yeah makes sense

Then in real hardware usually the AML would check don't shared config buffer if the device should be enabled it disabled, tho with qemu it makes less sense

Since aml comes from qemu and not the bios and it's a weird abi to enforce

[slim panther]

all snapdragon x elite/plus laptops

[frank canopy]

it's just acpi on the machine type and I think having it print options should work

[frank canopy]

yeah fair ig, now the followup question then is can i get limine to give me the runtime services pointer or whatever on uefi aarch64

[mortal yoke]

efi system table request

[frank canopy]

ah cool perfect

tbh that might be preferable on x86 too, for rtc at least, though idk what page table stuff id need to propogate forward for it

[mortal yoke]

afaik you need to either have the identity mappings or use the set virtual map function to move the memmap entries used by the runtime service to the higher half

on x86 idk why not just write a cmos rtc driver yourself tbh

[frank canopy]

fair

[fiery turtle]

FYI a lot of AML blobs provide a function to read RTC

[frank canopy]

yeah but none that i have access to rn either in qemu or in actual hardware i own

[fiery turtle]

damn

[frank canopy]

neither my desktop nor my laptop have that and i cant figure out how to make qemu do it, so i cant test writing a driver for that lmao

[fiery turtle]

tbh u dont need much of a driver for it, since it just returns a very simple buffer

apparently 202/800 provide it

[frank canopy]

mhm

[fiery turtle]

at least this is good

[frank canopy]

proportion of amd in that 202?

because thats the thing thats the same across all my devices

(apart from qemu but thats qemu being its usual self)

[fiery turtle]

no clue lol

that needs more advanced grepping skills

also it's probably more than 202, because not all blobs include a disassmbled format

some are just .bin

[vast kestrel]

@fiery turtle do you have some resource or tutorial or something about how to run AML on windows and debug it?

[fiery turtle]

not really, although if u search in this thread i posted it before

[vast kestrel]

Yeah I assumed so much, any good keyword to search for it?

[fiery turtle]

#1217009725711847465 message

[vast kestrel]

Niceee thanks!

[fiery turtle]

np

[torpid ferry]

not that locked down, people extracted the drivers and use them on vanilla edk2

[vast kestrel]

Locked down I meant you can't just boot into it and do stuff with it

[torpid ferry]

fastboot boot edk2

:^)

project renegade my beloved

[winter orbit]

yeah it’s only going to get easier as QCOM depends more and more on mainline edk2

Last I saw they’ve managed to shove all their patches into a platform module much like Intel/amd does

[flat badge]

Does Qualcomm still force a hypervisor to be on?

[fiery turtle]

Thanks

[crude summit]

finally joining your cult.

I am having some issues with interrupt routing and I can't get the info to resolve it from anywhere but the _PRT ACPI table it seems. and I'm not writing my own AML parser, there lies madness.

basically I need the correct interrupt level/edge trigger settings etc, and they aren't anywhere but there for interrupts that don't have explicit gsi redirection in the madt as far as I can tell.

so down the uacpi rabbit hole I go

[fiery turtle]

cool, feel free to ask if u encounter any issues

[vast kestrel]

You should write chipset drivers and resolve it from the chipset config obviously

[fiery turtle]

@strong heath btw apparently your revolutionary idea about signalling init also exists in linux

[strong heath]

Im too smart for my own good

[fiery turtle]

Real

[crude summit]

does uacpi try to auto start APs or something

when i call uacpi_initialize(0) it dumps out a load of tables to its log channel then reboots my vm via triple fault

seems it does that because all 7 APs come up, when im only running the BSP

they have nowhere to go to

i just get this, then a reboot. whatever its doing, it somehow bypasses my fault handler that should log and stacktrace

init_uacpi uacpi_initialize(0)
[uACPI] starting uACPI, version 3.0.0
[uACPI] RSDP 0xFFFF8000000F59A0 00000014 v00 (BOCHS )
[uACPI] RSDT 0x000000007FFE256C 00000038 v01 (BOCHS  BXPC    )
[uACPI] DSDT 0x000000007FFE0040 000022EC v01 (BOCHS  BXPC    )
[uACPI] FACP 0x000000007FFE232C 000000F4 v03 (BOCHS  BXPC    )
[uACPI] APIC 0x000000007FFE2420 000000B0 v01 (BOCHS  BXPC    )
[uACPI] HPET 0x000000007FFE24D0 00000038 v01 (BOCHS  BXPC    )
[uACPI] MCFG 0x000000007FFE2508 0000003C v01 (BOCHS  BXPC    )
[uACPI] WAET 0x000000007FFE2544 00000028 v01 (BOCHS  BXPC    )
[uACPI] FACS 0x000000007FFE0000 00000040

[vast kestrel]

Uacpi doesn't do anything related to smp

[crude summit]

then something is going very wrong. most of the functions it needed me to define are just stubs. i dont have in kernel threads, i dont have 'work queues', etc etc.

[vast kestrel]

Those aren't needed that early

It's very likely you have an allocator bug

Given how early uacpi is

[crude summit]

my kernel is completely identity mapped, so i just return the phys as the virt, i dont need to map in io or get handles for pci devices, its all simple.

[vast kestrel]

Also ensure you have enough stack space

[crude summit]

my entire kernel uses the same kmalloc which is very simple, if it was broken my whole thing would come crashing down

[vast kestrel]

Not necessarily, we have seen alot of kernels with simingly working malloc crashing because they actually had a bug, uacpi is a pretty good malloc stress test

[crude summit]

got megabytes of it (yes really), im running a basic interpreter in the kernel

[vast kestrel]

Then my best advice would be to disable reboot on triple fault (if you haven't already) and start debugging the actual reason for the crash

[crude summit]

i did that but its just a register dump

[vast kestrel]

Well, where is the rip at, what was it trying to do at the moment of the crash

[crude summit]

without my stack trace, im a bit lost, i havent had to mess with my assembler stuff in years

[vast kestrel]

Start with taking the rip and using something like addr2line to figure the line at which you crashed

Also check the asm instruction and cross reference with the sdm on why it can throw an exception

But bottom line is have fun debugging

[crude summit]

this is all i get out of qemu. 7 of these one per cpu

(qemu) CPU Reset (CPU 0)
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=0 SMM=0 HLT=0
ES =0000 00000000 00000000 00000000
CS =0000 00000000 00000000 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 00000000 00000000
FS =0000 00000000 00000000 00000000
GS =0000 00000000 00000000 00000000
LDT=0000 00000000 00000000 00000000
TR =0000 00000000 00000000 00000000
GDT=     00000000 00000000
IDT=     00000000 00000000

and yeah all zeroes

idk how on earth thats even possible, my OS is up and running, i call the function boom gone

[vast kestrel]

Are you using acceleration or full emulator?

[crude summit]

q35 with accel

[vast kestrel]

Also in qemu you can pass -d int and it would trace all the exceptions that happen including when triple faulting

Try to disable accell, it sometimes help when you need to debug such stuff

[crude summit]

i did, i dont get any

its like something forces a reboot, rather than an actual error

[vast kestrel]

You might need to disable accell then

[crude summit]

oh god, that will be so slow

[vast kestrel]

Nah it's fine

[crude summit]

i do get more info out of it under emulation

[vast kestrel]

Yeah sometimes accell messes with it

[crude summit]

i have no idea what im even looking at

why would it just crash like that

i kinda chose this because it was supposed to do all the acpi stuff for me, not really ready and equipped to debug it

[vast kestrel]

Its 99.99% a bug in your code

[crude summit]

a bug that only manifests when i start uacpi?

[vast kestrel]

A bug that manifest when something starts stressing the allocator

[crude summit]

i mean my kmalloc is like 200 lines long its nothing special. i can only guess this assumes im running some windows-like or unix-like

[vast kestrel]

we have seen many people having weird crashes turning out to be their allocators or something else that they didn't think about

[crude summit]

its just tinymalloc with usage tracking

no need to get fancy with it

im tempted to put dprintf() in each of the stubs to see what its calling

but there are sooo many

[vast kestrel]

Either way I would start by figuring the state of your kernel at the time of crash, and try to extract some stack trace at list

Ensure that the stack pointer looks correct

[crude summit]

hmmm i got somewhere. according to my symbol file (yeah i keep one around as text lol) the rip is in mmio_read16

brb taking a look.

uh wot

uacpi_kernel_io_map(602,2)
uacpi_kernel_io_read16(0)

why is it trying to read a null pointer

oh i see.

[vast kestrel]

That's not memory... That's port Io...

[crude summit]

even still, you dont read port 0 right?

[vast kestrel]

Map should return a "handle" to a port, and then the read should read relative to that port

[crude summit]

this complicates matters for me

[vast kestrel]

The easiest way to deal with this is have map return the base value as the handle, and then use it from the read

[crude summit]

i have no need to dole out handles, as there is no access restriction on it, i'll just have to make some way of stashing the base in the handle

lol, you beat me to it

[vast kestrel]

uacpi_status uacpi_kernel_io_map(uacpi_io_addr base, uacpi_size len, uacpi_handle *out_handle) {
    *out_handle = (uacpi_handle)base;
    return UACPI_STATUS_OK;
}

void uacpi_kernel_io_unmap(uacpi_handle handle) {}

uacpi_status uacpi_kernel_io_read8(uacpi_handle base, uacpi_size offset, uacpi_u8 *out_value) { *out_value = __inbyte((uintptr_t)base + offset); return UACPI_STATUS_OK; }
...

And so on

[crude summit]

now i want to know why my #PF handler didnt catch the access to null, when it does everywhere else

[vast kestrel]

[crude summit]

well it boots now at least. it complains loudly

[uACPI] uacpi_kernel_get_nanoseconds_since_boot() appears to be a stub, this may cause problems

^ its onto me, it knows the truth! hide the bodies!

[crude summit]

what do these mean? i assume its on me? or something weird about the config of qemu. its not fatal, either way.

[uACPI] unable to acquire global lock after 65535 attempts
[uACPI] aborting method invocation due to previous error: timed out waiting for hardware response
[uACPI]     #0 in \_SB_.CPUS.C000._STA()

[fiery turtle]

you return the same handle for all mutexes

[crude summit]

ah, thats all? there are no mutexes.

i'll have it return an incrementing static int

[fiery turtle]

That should work

[crude summit]

seems happy now.

init_uacpi uacpi_namespace_load()
[uACPI] successfully loaded 1 AML blob, 1760 ops in 570ms (avg 3087/s)
init_uacpi uacpi_namespace_load() done
init_uacpi uacpi_namespace_initialize()
[uACPI] namespace initialization done in 22ms: 44 devices, 0 thermal zones
init_uacpi uacpi_namespace_initialize() done

now i can actually get on with what i wanted to do, writing something to figure out the correct gsi, trigger mode and priority etc for each pci interrupt behind a bridge

[fiery turtle]

Why is it so slow?

[crude summit]

its running on qemu on a very busy dual xeon server in my cellar

if you want real figures i'll run it on bare metal once ive got it doing what i want 😄

[fierce kiln]

no kvm? 💔

kvm might improve your turnaround time

[crude summit]

yeah kvm, but the kvm instance is competing with clion remote dev server, and a ton of other processes, like sentry, etc

its quite a congested dev box, and it isnt particularly new

processor       : 31
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
stepping        : 7
microcode       : 0x71a
cpu MHz         : 1200.000
cache size      : 20480 KB

[crude summit]

ok so I don't understand why it's important for uACPI to be really really fast, like millions of ops per second fast. surely in most cases ACPI scanning and operations stay out of the way, they're setup and initialisation tasks like detecting hardware, bringing things up? you don't run them continually in interrupts and tight loops?

what are people doing that isn't a boot time operation or someone clicking "find new hardware" that needs it to parse so quickly when it should have cached the entire tables to ram when you initialise uACPI?

[slim panther]

it's a benchmark for how fast your code is

linux for example is actually quite slow, but it's more robust

it does allocations, locking, etc

[crude summit]

ah, I guess? but I'd be "cheating" in such a comparison. no need for locking, no contention, simple allocator, identity mapped address space... I'm simply not doing as much.

[left orbit]

that's why there are some requirements for a score to be considered legit :^)

it's mostly a for fun thing

but i guess it could also be used to identify bottlenecks in your kernel

or maybe regressions in terms of performance

[hasty plinth]

it's not really that important, but the uacpi log does provident a convinient 'score' for your kernel, and its fun to compete. Plus its good fun to see if you can make your kernel more efficient at something and get a bigger number out of it.

ah 1760 is relatively slow though, most people here are in the millions.

I'm keen to see how new-new-northport fares when I get drivers (and uacpi) running again.

[crude summit]

tbh if I had a faster allocator I would have immense scores. my allocator isn't fast just simple and easy to reason about

simplicity of the system is more important to me than raw performance

https://github.com/brainboxdotcc/retro-rocket/blob/master/src/tinyalloc.c

...if you're curious

it's cobbled together from various places, and I added tracking of the ram usage total plus simple detection of double free

[hasty plinth]

fair enough, if you dont care - you dont care 🙂

nice artwork btw

[crude summit]

I was using the one from jamesm tutorials for a long time but it had so many issues

thanks but the credit isn't mine to take, the artwork is ai generated

[hasty plinth]

yeah I figured

[crude summit]

I can't draw 😭

well, not well enough to present it to others anyway

I did manage to get what I wanted out of uACPI but I'm not sure I'm doing it right, if I still have any questions I'll ask later

(as in, the data looks correct but there's probably a nicer way to get it)

[tired temple]

It's 3087 though, 1760 is the number of ops. I thought, it's obvious why this score is interesting. Apart from the fun of competition. It's one of the 1st tests deep inside your kernel. And making it survive the test gives you certainty, the parts that are involved in handling the requests are not dog shit. And of course, those parts certainly will be on critical code paths, so "not caring" about their performance is not wise.

[hasty plinth]

Ah lol 🤦

[fiery turtle]

3000 seems comically slow

its like 5 orders of magnitude behind what u can get?

like even when nyaux had a bug in his allocator (which would always take the slow path) it was faster without kvm

hell even in O0 with asan and ubsan i get more

like 30-40k

maybe your timekeeping is just wrong?

[slim panther]

debug + TCG

• laptop cpu

[kind mantle]

Telling uACPI nanos picoseconds passed are actually nanoseconds to sandbag in ranked competitive uACPI ops/s.

[fiery turtle]

can u elaborate?

[calm latch]

Not always in kernel

[tired temple]

Ah, right. Guys with microkernels. btw broadly present among the leaders.

[crude summit]

my timekeeping value I give to uACPI is just rdtsc() without scaling. I didn't want to spend time making a nanosecond accurate timer, I don't have any interrupts running more than 100ms granularity, don't need it. I don't multitask on interrupts so it doesn't dictate minimum timeslice.

basically it's rock and a hard place because uACPI wants a delay function at init but I init it before interrupts are up, as I need the info from it to remap interrupts properly.

so that probably explains it, it's likely 100x out or more

[left orbit]

no wonder time values are bogus

[crude summit]

and... with that I just realised why my #pf handler didn't catch the crash last night. it's not set up at this point, too early in the boot process

[calm latch]

I've gotten honorable 5.3M ops/s on an old version

Also the first place is a micokernel with uACPI in userspace

I forgot about it

[crude summit]

do i have to enter a speed figure to get listed on the readme? wouldnt mind being there for visibility

but not too concerned about speed of something that for me only happens once at boot

i think i'd be one of the few that isnt a unix-like in there

just figured out, i can give a nanosecond pause function and ns since boot. but, it will add a whole second to my boot time, boohoo

[calm latch]

Did ROS switch to uACPI?

[left orbit]

soon, yes

i'm pretty sure the uacpi driver is in works still

or in pr hell

or somewhere in between :^)

[fiery turtle]

Not yet its wip by @winter orbit , but uACPI is already merged in the repo

[fiery turtle]

U should really have timekeeping up before u do any sort of namespace stuff

Did u look at setup_early_table_access?

[frank canopy]

also when running on qemu you can get the tsc frequency from the hypervisor cpuid leaves instead of having to do a full calibration

[crude summit]

nothing I do has any need for it

I've made a nanosecond timer using rdtsc and the RTC to calibrate it, can do that without any interrupts on.

[frank canopy]

technically acpi firmware has sleep/stall instructions but other than that the only thing uacpi needs time for is just the benchmark anyway. which you can just ignore anyway if you want

[vast kestrel]

For a long time Linux implemented the Timer opcode using an incrementing counter

Literally returning ++ each time

[fiery turtle]

Lmfao

[urban galleon]

why...?

[vast kestrel]

For stuff like microkernels, which don't have full iopl (by design)

[flat badge]

also, non-x86 archs

[vast kestrel]

^^

[fiery turtle]

yeah on itanium (which is like the only other first party acpi arch) port io is memory mapped i think

[crude summit]

imagine using itanium

[tired temple]

How is it worse than using basic?

[flat badge]

pio is memory mapped on most aarch64 as well

[crude summit]

basic doesnt cost a small fortune 😄

im guessing most running itanium run it under emulation?

[tired temple]

agreed (on the price).

[fiery turtle]

there isnt a good itanium emulator

[crude summit]

not even in qemu?

is it a lack of accessible open firmware issue?

[fiery turtle]

nah

even qemu's version is incomplete

the arch is too complex, and there isnt interest or a driving force for implementing it

since most of these are implemented by corpos etc

[crude summit]

it never got the classic traction i guess

even things like the 32016 have better emulation

[crude summit]

when does uACPI use deferred or scheduled work?

seems like something that would have pretty niche uses

[vast kestrel]

Mostly comes from SCI handling as far as I saw

[fiery turtle]

any irq work

aka GPEs/Notify

so not niche at all really

[vast kestrel]

even basic stuff for ACPI

[crude summit]

but you have a function to register an interrupt handler for that?

if you mean things like power button

[gentle peak]

yeah but those run in IRQ context

and in that context most functions aren't allowed to be used

whereas the scheduled work runs in a regular context and is thus able to allocate, map, schedule, etc

[crude summit]

so basically any sceduled 'later' where 'later' is any time between now and n

outside of an irq context

[fiery turtle]

Yeah it makes sure u can run the work right away without deadlocking

If u want to

[slim panther]

are there many systems where you can turn off hpet?

[hollow crescent]

judging by the amount of "disable your hpet for free performance" videos, probably

[left orbit]

it's insane that people actually think turning off hpet actually improves your performance in games

but like

they don't know better, they see computer as gaming thing and not a fancy calculator that can do what i want

[crude summit]

finally able to share what ive done, is this ok or is there a better way to aggregate this data into my own structures? im basically just seeking out the irq info which isnt in the MADT.
https://github.com/brainboxdotcc/retro-rocket/blob/master/src/acpi.c#L454-L505

in terms of "am i mutilating the uACPI API, or is this right" because it works

[fiery turtle]

nah, you're looking for pci_routing_table

https://github.com/managarm/managarm/blob/master/kernel/thor/system/pci/pci_acpi.cpp

[crude summit]

interesting, this is the same data im getting, im just getting it in a round about way

both end up with _PRT

[fiery turtle]

yeah because in qemu the prt just references the respective LNKA/B/C/D device which has a _CRS

but it doesnt have to, the prt could provide hardcoded GSI numbers

[crude summit]

on my real hardware uACPI fails here:

    dprintf("init_uacpi uacpi_initialize(0)\n");
    st = uacpi_initialize(0);
    dprintf("init_uacpi uacpi_initialize(0) done\n");
    if (uacpi_unlikely_error(st)) {
        preboot_fail("uACPI init failed");
    }

is there any diagnostic mode or anything?

[fiery turtle]

uacpi_context_set_log_level

set it to debug

[crude summit]

and output the log callback?

[fiery turtle]

yes

[crude summit]

will this be very noisy? because at this point in boot i have no scrollback, no logging

[slim panther]

just add a serial logger

[crude summit]

i dont have a serial card

[slim panther]

don't you test on qemu?

[crude summit]

it works on qemu...

[slim panther]

oh

[crude summit]

on qemu i use the debug hack port to output to a log, no problem if it failed there

[crude summit]

invalid table 'TAMG' (0x00000000AFDF9B00) size: 34

it may be this, it is this board iirc
https://answers.launchpad.net/ubuntu/+question/706122

should it skip or be more forgiving of these invalid tables?

[fiery turtle]

can u attach an acpidump of that pc?

[crude summit]

i dont have a linux distro i can boot atm, perhaps in a few

[fiery turtle]

anyway it's probably a bug in your mapping code

[crude summit]

my mapping code?

it doesnt get that far

[fiery turtle]

it cant not get that far because it has to map the table

to actually access it

lol

[crude summit]

wdym my mapping code?

[fiery turtle]

uacpi_kernel_map

[crude summit]

my entire OS is identity mapped...

// Physical memory mapping (flat model)
void *uacpi_kernel_map(uacpi_phys_addr addr, uacpi_size len) {
    return (void *) (uintptr_t) addr; // identity-mapped
}

void uacpi_kernel_unmap(void *addr, uacpi_size len) {
    // no-op in flat memory
}

[fiery turtle]

the problem is the size of the table is less than the size of acpi SDT header

which all tables have

[fiery turtle]

even here u can see its much larger than 34 bytes

[crude summit]

if you google acpi tamg, you get a lot of results

different sizes, different checksums

[fiery turtle]

thats why i asked for a dump

[crude summit]

i can only boot a cdrw on it, so i need to find a small linux that can fit on the cdrw to get you that

probably dsl

[fiery turtle]

does it have any system on it?

[crude summit]

no

[fiery turtle]

if this is actually what it produces that would be the first table in the whole acpi specification that is allowed to be smaller than the header that all tables have

[crude summit]

its a spare pc with nothing on it specifically for my OS to boot on

it used to run windows 10

hmmm, none of these tiny distros have acpidump

[fiery turtle]

u dont need acpidump

[crude summit]

you said you wanted an acpidump

[fiery turtle]

hexdump /sys/firmware/acpi/tables/TAMG

[crude summit]

what even is a TAMG table

[fiery turtle]

some proprietary table

[crude summit]

...i thought acpi was supposed to be a ...standard

[fiery turtle]

the standard allows for proprietary stuff on top

and theres tons of stuff like that

WMI even

yeah even acpica doesnt know what it is

Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8:[000h 0000   4]                    Signature : "TAMG"
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8:**** Unknown ACPI table signature [TAMG]

[crude summit]

i do know that whatever uacpi needs to probe at, it can get to, there are no restrictions, its all identity mapped ring 0, as set up by limine at early boot

[fiery turtle]

idk

[crude summit]

difference is it doesnt fail on it in a fatal way? im getting hold of a linux distro atm to do an acpi dump for you

[fiery turtle]

it could be corrupted by your allocator earlier for example

or any other code that runs earlier

[crude summit]

unlikely

the allocator this uses is a simple incrementing number that starts at the start of a free section of memory

its what i use to allocate contiguous blocks below 4gb for some older drivers

[fiery turtle]

$ git grep -n4 'TAMG"'
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8944-
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8945-
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8946-TAMG
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8947-----
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA:8948:[000h 0000   4]                    Signature : "TAMG"
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8949-[004h 0004   4]                 Table Length : 00000B2A
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8950-[008h 0008   1]                     Revision : 01
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8951-[009h 0009   1]                     Checksum : 13     /* Incorrect checksum, should be 12 */
Desktop/Gigabyte Technology/EX58/EX58-UD5/DF2F64A5D6CA-8952-[00Ah 0010   6]                       Oem ID : "GBT   "
--
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9886-
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9887-
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9888-TAMG
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9889-----
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8:9890:[000h 0000   4]                    Signature : "TAMG"
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9891-[004h 0004   4]                 Table Length : 00000202
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9892-[008h 0008   1]                     Revision : 01
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9893-[009h 0009   1]                     Checksum : 45     /* Incorrect checksum, should be 44 */
Desktop/Gigabyte Technology/GA-880/GA-880GMA-USB3/83A64B35F7D8-9894-[00Ah 0010   6]                       Oem ID : "GBT   "
--
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8854-
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8855-
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8856-TAMG
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8857-----
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE:8858:[000h 0000   4]                    Signature : "TAMG"
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8859-[004h 0004   4]                 Table Length : 00000102
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8860-[008h 0008   1]                     Revision : 01
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8861-[009h 0009   1]                     Checksum : F4     /* Incorrect checksum, should be F3 */
Desktop/Gigabyte Technology/GA-MA785/GA-MA785GM-US2H/75CF50C321BE-8862-[00Ah 0010   6]                       Oem ID : "GBT   "

these are all examples i have

the length is in the hundreds of bytes

not 34

but anyway it will be clear once we see the dump

[crude summit]

well, i dont know what to say, uacpi basically has full unrestricted access to the whole machine before anything in my OS

[fiery turtle]

like i said lets see what other osses think about its contents

if u can open an efi shell there there's probably a way to check also

according to hexdump it contains info about various ram-related stuff

[slim panther]

truly a gigabyte moment

[crude summit]

wtf

it really IS 34 bytes

😮

[fiery turtle]

how did u check?

[crude summit]

hexdump the table in linux

hold on i'll get the screenshot

[fiery turtle]

huh

how fucked is your firmware

is it gigabyte btw

[crude summit]

fucked?

yes

[fiery turtle]

very

[crude summit]

windows is fine with it, and linux booted

[fiery turtle]

yeah ill have to allow such tables

[crude summit]

do you want any more info about this machine, while i have linux up

i can get you all the tables perhaps

[fiery turtle]

yeah

UACPI_PACKED(struct acpi_sdt_hdr {
    uacpi_char signature[4];
    uacpi_u32 length;
    uacpi_u8 revision;
    uacpi_u8 checksum;
    uacpi_char oemid[6];
    uacpi_char oem_table_id[8];
    uacpi_u32 oem_revision;
    uacpi_u32 creator_id;
    uacpi_u32 creator_revision;
})

this table has everything up to creator_revision

@crude summit can u just patch that if statement out locally and try without it?

[fiery turtle]

or wait lmfao

its even worse

it has every field

but the last one is cut in half

[crude summit]

you get half table 😄

i am pretty sure this machine may have been fucked with before i got it.

windows oem disks pick it up as a dell

it definitely is NOT a dell

[fiery turtle]

https://github.com/uACPI/uACPI/blob/0927c932d306bba99f23c71e9bc6e737946a7593/source/tables.c#L665

[crude summit]

i did get the whole machine 2nd hand

[fiery turtle]

this check can be patched out

can u try removing it and rebooting?

[crude summit]

wont that fall through to the other checks that will also fail as the data is missing? i'll give it a go.

commented out all of 665-669

[fiery turtle]

nah i dont think anything below actually cares about those fields

[crude summit]

is checksum failure non-fatal?

[fiery turtle]

ye

by default at least

[crude summit]

yeah ive not changed any defaults there

burning cds is soo agrrivating. i might add netboot support.

[fiery turtle]

lol

does it not have a usb

[crude summit]

it does but its fussy, and even if i got it to boot, i wouldnt be able to read my root fs in my os

because i dont have a usb stack

[fiery turtle]

u have an ide driver?

[crude summit]

i have ahci sata

i got rid of ide

wow... how much debug

it booted

[fiery turtle]

yeah u probably should've disabled debug

[crude summit]

i got another error now that is entirely my bag

[fiery turtle]

debug printing can take hours on real hw

but u have like one ssdt

[fiery turtle]

ok cool, ill just remove that check then

thx for reporting

[crude summit]

no problem 👍

[fiery turtle]

i wonder how u could possibly code it so it produces a header with all fields present but one cut in half

[crude summit]

i have an idea how

[fiery turtle]

like u have to be special

in the head

like all firmware devs ig

[crude summit]

i think the bios on this machine was 'cracked', someone has inserted a microsoft signature block into the acpi

i cant remember the proper term for it

[fiery turtle]

like OEM activation?

[crude summit]

but it makes it think its an OEM machine for dell or HP to bypass win activation, it came like this and i was always afraid to touch it

yeah

[fiery turtle]

ah

thats probably why

[crude summit]

i dont like doing bios upgrades

well it seems im not the only one 😄

google's full of it

[fiery turtle]

there are much easier ways to activate windows lol

especially these days

[crude summit]

i bet some ebay seller was selling this board ready flashed

yeah i dont bother with that crap any more

i have windows 11 on here, i paid legit for windows 10, actually from MS

i do business stuff on here, its the only way

well, the only correct way

[fiery turtle]

ye

[crude summit]

on the good news, the "crash i have to fix myself" is in the interrupt handler for my e1000, which says that uacpi gave me the right polarity and trigger mode for the int

this is all good

if it hadnt given me the right info, the int wouldnt fire

[fiery turtle]

cool cool

[crude summit]

im guessing there arent many other weirdness things like this that could happen now

in uacpi i mean

[fiery turtle]

probably, i mean last time i had to patch something for weird firmware was like months ago

[topaz briar]

Is the Rust bindings still maintained?

And is there docs for it?

[slim panther]

not really

they're incomplete

i am running my own bindings

[topaz briar]

Aagh. Okay

[vast kestrel]

Does acpica not check for table lengths? Does it just print out-of-bounds data in the initial dump?

Like the dump that Linux does at the boot

[crude summit]

happy to report my network card finally works on real hardware thanks in no small part to uACPI

[fiery turtle]

id have to check, not sure

it probably unconditionally maps at least the header size

so its technically inside the bounds, just bogus data

[fiery turtle]

thats cool

[gentle peak]

can't wait for the firmware that puts a 34 byte acpi table right before an mmio region

[woven citrus]

yes

[crude summit]

or a 34 byte ACPI table that's really 16 bytes

[woven citrus]

[crude summit]

(because why not, standards are nothing but ... recommendations)

[fiery turtle]

ngl we need floating-point-sized tables so firmware devs feel comfortable

like 34.3 byte table

[torpid root]

lmfao

[real jetty]

Firmware devs being comfortable with fp is the same as os devs beign comfortable around gdb

Nonexistent

[kindred beacon]

Laughs in assertOS

I have 4 gdb setups for debugging managarm

We don't even do gdb over serial yet

[calm latch]

Someone here had gdb over UDP with nic driver

[left orbit]

keyronex i believe

[calm latch]

obos

[vast kestrel]

GDB stub is really simple to make, and from there you just need some way to communicate

[jaunty fox]

very useful and relatively low-effort if you have the NIC driver already

[kindred beacon]

TCP I assume?

gdb natively supports connecting over tcp

[calm latch]

No

UDP

GDB stub in kernel

I mean maybe

I might be wrong

But I remember it being UDP

[kindred beacon]

but UDP makes no ordering or delivery guarantees?

[jaunty fox]

Pray it arrives (reasonably likely if you are on a lan) or add some trivial additions to cope with the possibility

[calm latch]

I think GDB can deal with that?

Also it's probably fine between two PCs

It's not like you're connecting to it over the internet with a bunch of routers or whatever

Like serial might also corrupt stuff

[crude summit]

I tried to do this but couldn't, what I want to debug is not native, I might make my own debugger

[hasty plinth]

It can deal with delivery failures but not ordering. It never has more than 2 things in flight at a time though (one of which doesn't require a response), so it's workable.

The protocol does have space for sequence numbers but they're deprecated and were apparently never used anyway

It can kind of deal with corruption too (you just send a nack after some timeout and the host will resend the last packet)

[flat badge]

posix-subsystem GDB runs over serial

[kindred beacon]

wait it doesn't go over dmalog

[flat badge]

kernel GDB does over dmalog

dmalog is not exported to userspace

[kindred beacon]

ah

[dense steppe]

yay, broken laptop ACPI:

[   16.381030] Bluetooth: hci0: Device revision is 0
[   16.381040] Bluetooth: hci0: Secure boot is enabled
[   16.381043] Bluetooth: hci0: OTP lock is enabled
[   16.381045] Bluetooth: hci0: API lock is enabled
[   16.381048] Bluetooth: hci0: Debug lock is disabled
[   16.381050] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   16.381054] Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 38
[   16.381185] ACPI Error: Needed [Buffer/String/Package], found [Integer] 000000005c4470e5 (20240827/exresop-557)
[   16.381196] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (20240827/dswexec-433)
[   16.381208] ACPI Error: Aborting method \_SB.PC00.XHCI.RHUB.HS10._DSM due to previous error (AE_AML_OPERAND_TYPE) (20240827/psparse-529)
[   16.381223] ACPI: \_SB_.PC00.XHCI.RHUB.HS10: failed to evaluate _DSM e0f410aa-ac81-3342-abf6-3b2ac50e28d9 rev:0 func:1 (0x3003)
[   16.381229] Bluetooth: hci0: Failed to call dsm to set reset delay

(this is Linux)

[fiery turtle]

probably not critical but yeah

[dense steppe]

yeah

I sent this from the laptop in question

[fiery turtle]

it tried to index into an integer as if it was a package

most likely it just was uninitialized

[vast kestrel]

Tbh I could believe windows would support such a thing :^)

[fiery turtle]

hes back

bro like just read the goddamn implementation, that function is tiny

[real jetty]

Idk kinda sounds like a reasonable question to me no?

People don't often read the library implementation from what im seeing

[torpid root]

ctrl+click

they should read it

[fiery turtle]

well first of all i dont agree, if you're using a third party library for your kernel, you should probably understand what it's doing instead of blindly trusting my word

second of all this guy has a history of lazy questions

and this question is weird because even acpica has delays and stuff in the reset function, u cant not have them

also, calling reset from an irq handler is a terrible idea

that means u dont do any sort of fs sync, or notify userspace in any way. also you're expected to call prepare_for_sleep_state(S5) for reset

[real jetty]

Yeah im the last person who'd give him the benefit of the doubt just this one kinda made sense - perhaps my lack of acpi knowledge is showing tho

[fiery turtle]

his questions are usually based around some weird limitations of his impl that are basically bogus

[real jetty]

While I agree, I don't think that's the common practice

[fiery turtle]

https://github.com/uACPI/uACPI/issues/132#issuecomment-3139114211 anyway i replied

[sterile egret]

lmao more rdos

[slim panther]

the meme continues

every time i'm intimidated by big projects i remember that rdos exists

[fiery turtle]

wtf does this even mean

[gentle peak]

He wants to be able to reset in panic instead of halting

[slim panther]

but why

[fiery turtle]

i would just look at how other osses handle resetting during a panic

[hasty plinth]

I already do this when ACPICA misbehaves

uacpi doesnt the same treatment then?

[fiery turtle]

yeah there's basically 0 difference here in terms of what uacpi requires vs acpcia

its more of an os design question i guess?

[median crest]

Triple fault

[torpid root]

valid

[fiery turtle]

for an emergency reset why not

[kindred beacon]

why do you even engage with someone like this who's just completely unwilling to accept how stuff works or doesn't, and seemingly is incapable of doing stuff properly

I don't get why you torture yourself like this

what's the point

this guy just doesn't get it, will complain forever while doing shit "their way" (aka wrong) while whining about how everyone is being mean to them

[fiery turtle]

well ur not wrong

[crude summit]

is this an rtos? he has time guarantees on each operation so has to detect hung operations and at worst case, restart?

not sure

[calm latch]

why not just tripple fault then

if the restart is not due to kernel panic, then restart normally?

like the dude has a microkernel (?), the server crashes shouldn't be bringing everything down anyway

[fiery turtle]

i found a memory leak in uacpi's LoadOp, but for some reason asan is refusing to detect it???

while valgrind does

==498023== 127 bytes in 2 blocks are still reachable in loss record 1 of 3
==498023==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==498023==    by 0x16C438: uacpi_kernel_alloc (interface_impl.c:324)
==498023==    by 0x198D24: handle_load (interpreter.c:1537)
==498023==    by 0x1B77F2: exec_op (interpreter.c:5606)
==498023==    by 0x1BA4EF: uacpi_execute_control_method (interpreter.c:6011)
==498023==    by 0x183137: uacpi_eval (uacpi.c:770)
==498023==    by 0x166C58: run_test (test_runner.c:446)
==498023==    by 0x167168: main (test_runner.c:564)

hmm

What does are still reachable in loss record 1 of 3 mean

[dense steppe]

the goal of asan isn't to detect memory leaks, is it?

[fiery turtle]

it is

STDERR FOR table-loading-1.aml:Load tables from opregions & fields:

        =================================================================
        ==499614==ERROR: LeakSanitizer: detected memory leaks

        Direct leak of 127 byte(s) in 2 object(s) allocated from:
            #0 0x71227ccfd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
            #1 0x5f6f2928af4f in uacpi_kernel_alloc /mnt/d/uACPI/tests/runner/interface_impl.c:324
            #2 0x5f6f292cde1c in handle_load /mnt/d/uACPI/source/interpreter.c:1537
            #3 0x5f6f292f92e5 in exec_op /mnt/d/uACPI/source/interpreter.c:5606
            #4 0x5f6f292fcfa5 in uacpi_execute_control_method /mnt/d/uACPI/source/interpreter.c:6011
            #5 0x5f6f292ad8a1 in uacpi_eval /mnt/d/uACPI/source/uacpi.c:770
            #6 0x5f6f292828a1 in run_test /mnt/d/uACPI/tests/runner/test_runner.c:446
            #7 0x5f6f29282fab in main /mnt/d/uACPI/tests/runner/test_runner.c:564
            #8 0x71227c02a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
            #9 0x71227c02a28a in __libc_start_main_impl ../csu/libc-start.c:360
            #10 0x5f6f2927d9c4 in _start (/mnt/d/uACPI/tests/runner/build-linux-64bits/test-runner+0x1259c4) (BuildId: e50b781e981b504df517bec4ef112be2502e9503)

        Direct leak of 127 byte(s) in 2 object(s) allocated from:
            #0 0x71227ccfd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
            #1 0x5f6f2928af4f in uacpi_kernel_alloc /mnt/d/uACPI/tests/runner/interface_impl.c:324
            #2 0x5f6f292cde1c in handle_load /mnt/d/uACPI/source/interpreter.c:1537
            #3 0x5f6f292f92e5 in exec_op /mnt/d/uACPI/source/interpreter.c:5606
            #4 0x5f6f292fcfa5 in uacpi_execute_control_method /mnt/d/uACPI/source/interpreter.c:6011
            #5 0x5f6f292cb52a in do_load_table /mnt/d/uACPI/source/interpreter.c:1300
            #6 0x5f6f292ce2be in uacpi_execute_table /mnt/d/uACPI/source/interpreter.c:1590
            #7 0x5f6f2929cb5b in uacpi_table_load_with_cause /mnt/d/uACPI/source/tables.c:1133
            #8 0x5f6f292abf51 in uacpi_namespace_load /mnt/d/uACPI/source/uacpi.c:452
            #9 0x5f6f29282546 in run_test /mnt/d/uACPI/tests/runner/test_runner.c:386
            #10 0x5f6f29282fab in main /mnt/d/uACPI/tests/runner/test_runner.c:564
            #11 0x71227c02a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
            #12 0x71227c02a28a in __libc_start_main_impl ../csu/libc-start.c:360
            #13 0x5f6f2927d9c4 in _start (/mnt/d/uACPI/tests/runner/build-linux-64bits/test-runner+0x1259c4) (BuildId: e50b781e981b504df517bec4ef112be2502e9503)

There u go

it was because i wasnt zeroing the static table array, so it thought the pointers were still reachable

fixed, it was a really rarted error

For some reason LoadTableOp did handle it, but LoadOp didnt??

like this logic was completely absent from the latter??

Anyway it's not a serious leak, afaik not a single os currently using uacpi triggers aml that dynamically loads aml

and its not unbounded or anything, u just permanently keep some amount of bytes leaked

or wait actually it's not really a leak

because tables installed by Load are heap allocated anyway so freeing them before uacpi_state_reset is impossible

since there's no way to get the contents back later on if it's ever requested by find()

nvm then

that said leaking a reference is probably not great anyway so ill keep the fix

[fiery turtle]

I made an incredibly cursed test case for verifying that i handle bogus table lengths in LoadOp/TableLoadOp:

// Name: Load/LoadTable handle bogus-sized tables correctly
// Expect: int => 0

DefinitionBlock ("", "DSDT", 2, "uTEST", "TESTTABL", 0xF0F0F0F0)
{
    External(\SSDT, IntObj)
    External(\OK, IntObj)
    External(\TYPE, IntObj)

    // All dynamic loads branch into here
    If (CondRefOf(\OK)) {
        if (TYPE == 0) {
            Local0 = Load(\SSDT)
        } Else {
            DataTableRegion (DSDT, "DSDT", "uTEST", "TESTTABL")
            Field (DSDT, DwordAcc, NoLock, Preserve) {
                SIGN, 32,
                LENG, 32,
            }

            // Make our own length bogus, then try to load ourselves, this should fail
            LENG = 3
            LoadTable("DSDT", "uTEST", "TESTTABL", "", "", 0)
        }

        // Should be unreachable, we expect the Load above to abort us
        OK += 1
        Return (0)
    }

    Name (SSDT, Buffer {
        0x53, 0x53, 0x44, 0x54, 0x2a, 0x00, 0x00, 0x00,
        0x01, 0x89, 0x75, 0x54, 0x45, 0x53, 0x54, 0x00,
        0x42, 0x41, 0x44, 0x54, 0x42, 0x4c, 0x00, 0x00,
        0xf0, 0xf0, 0xf0, 0xf0, 0x49, 0x4e, 0x54, 0x4c,
        0x28, 0x06, 0x23, 0x20, 0x70, 0x0d, 0x3f, 0x00,
        0x5b, 0x31
    })
    Name (OK, 0)
    Name (TYPE, 0)

    Method (MAIN) {
        // Make the size something bogus
        SSDT[4] = 0x11
        SSDT[5] = 0
        SSDT[6] = 0
        SSDT[7] = 0

        // Try Load'ing a bogus length SSDT
        TYPE = 0
        Local0 = LoadTable("DSDT", "uTEST", "TESTTABL", "", "", 0)

        // Now try LoadTable ourselves, after corrupting our own length
        TYPE = 1
        Local0 = LoadTable("DSDT", "uTEST", "TESTTABL", "", "", 0)

        // Expect the above to fail
        if (Local0 || OK) {
            Return (1)
        }

        Return (0)
    }
}

it loads itself recursively and then loads a different corrupted table, or corrupts itself and tries to load itself again

both cases should fail cleanly which is what it checks

[uACPI][INFO] dynamic load of 'DSDT' (OEM ID 'uTEST' OEM Table ID 'TESTTABL')
[uACPI][ERROR] Load: table size 17 is too small
[uACPI][ERROR] aborting table load due to previous error: invalid table length
[uACPI][ERROR]     #0 in \()
[uACPI][INFO] dynamic load of 'DSDT' (OEM ID 'uTEST' OEM Table ID 'TESTTABL')
[uACPI][TRACE] write to [\DSDT] (4 bytes) TableData[0x0000514000000044] = 0x3
[uACPI][ERROR] aborting table load due to previous error: invalid table length
[uACPI][ERROR]     #0 in \()
[uACPI][TRACE] fixed event 0 disabled successfully

runs cleanly

[fiery turtle]

Made a PR https://github.com/uACPI/uACPI/pull/137

@crude summit with a fix for your insane firmware as well

fix being this mostly

the rest is just fighting with the consequences of allowing that and other bugfixes

[crude summit]

thanks, i'll update at next version release, as im using a zip of the release not a submodule, and i put the manual fix in anyway

[fiery turtle]

yeah fair

ill make a new release soon

[crude summit]

you know once i got uacpi working, only then i realised i had an interrupt storm munting up my os

it had been going on since day one, since i first set up an idt

uacpi uncovered it, once i fixed it (by only unmasking the interrupts i was using on the ioapic) everything went faster, and my keyboard interrupts kept delivering multiple keys. it uncovered other laziness in my code lol

[fiery turtle]

what other interrupts were u getting out of curiousity

[crude summit]

all of them

no idea, random crap on vectors i had no interest in, because i unmasked everything

[fiery turtle]

thats kinda strange

[crude summit]

i assumed (wrongly) that my simple push regs, pop regs, iret that is there if theres no handler wouldnt be an issue

[fiery turtle]

u sure it wasnt just the timer?

[crude summit]

it was a combination of the number of interrupts, plus my server sucks at running qemu

just starting a 100hz lapic timer makes it eat like 33% cpu

i mean its not an utterly crap server, it just isnt built for running virtualisation in qemu

[fiery turtle]

what are the specs?

[crude summit]

by built i mean its config

64gb, HP server, 2x 16 core Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz

it seems to spend all its time spinning one core

[fiery turtle]

Seems like a pretty good server no?

[crude summit]

its great at what i bought it for... compiling, running daemons, etc, but crap at qemu

yeah only qemu i have problems with

and im running it with kvm too

but luckily i do half my testing on real hardware now

[fiery turtle]

Strange

[calm latch]

100hz should not even run that many instructions per second?

[crude summit]

yeah thats the thing, it doesnt

[winter orbit]

Dumping this is gonna be funny

[fiery turtle]

Damn

Indeed

[slim panther]

funny

[winter orbit]

It’s a reference board too not just a normal engineering sample

Meaning it as a connector to flash the entire SPI

[slim panther]

i have a bunch of intel mobile platforms

laptops but as desktops

[winter orbit]

That’s cool

[winter orbit]

Oh it’s a 5th gen

The coolest generation

[median crest]

@fiery turtle can you delist astral in the next uacpi pr ty

[torpid root]

[slim panther]

why bru

[vast kestrel]

Tbh that is also fairly popular on server motherboards for recovery purposes

[fiery turtle]

Wait why

I mean sure if you want

[slim panther]

😭 bro is giving up

[torpid root]

relatable

[fiery turtle]

nooooo

astral was like the most advanced os here