#Astral

1 messages · Page 5 of 1

sacred gyro
#

not sure how I mixed the two up...

#

neither trackpad or keyboard seem to work tho even though they're both PS/2

fleet osprey
#

If I plug a real PS2 mouse in, I imagine it would detect that and probably log something?
If so that could differentiate between emulated and real PS/2 for the Precision

grand shadow
#

Damn

#

I reaaaally need to rework this ps/2 code

#

Its almost just straight copied from old astral

grand shadow
fleet osprey
#

Also, I get that same failing to open /init error when booting from Ventoy on my OptiPlex
So presumably Ventoy is to blame there, only had that issue on that specific method of booting it...
But at least it boots mostly now, which is more than I could say about it before

grand shadow
#

Wonder what Ill have first
A working usb + hid driver or a ps/2 driver that almost always works lmaooooooo

sacred gyro
#

I wonder if SeshOS PS/2 works on my chromebook

fleet osprey
#

I swear I had a PS2 mouse somewhere... Where did I put it....

sacred gyro
#

Of course discord didn’t send the image despite me adding the image to the message

fleet osprey
#

well damn
mouse also doesn't come on when using PS/2

#

one of
- the PS/2 ports on this PC are broken (it's old, certainly possible)
- the USB -> PS/2 adapters I'm using are broken (they're even older than the PC, iirc they came with some microsoft thingy from the late 90s)
- the kbd and mouse both happen to just draw too much power for the PS/2 ports to handle

#

but at least the 2 main bugs were fixed

#

also, did you touch anything with PCI? if so, I can check on the latitude again, which hung... here ^^^

#

or wow, that's not what I wanted to reply to

#

🤦

#

I meant this one ^^^

grand shadow
#

If you wanna check it out

#

Dont think much is gonna change

fleet osprey
#

was anything at all changed with PCI init? if not I probably won't bother, I gtg soon

grand shadow
#

I only changed something in msi which likely doesnt matter so not rly

#

Ty for testing

fleet osprey
#

well the last line that was printed does mention msi-x, but that looks like it's just listing everything, so I doubt it

#

I'll check when I get back, or maybe tomorrow, for the hell of it

#

oh btw
if you ever plan to expand support to ARM(64 or not), I have a decent amount of hardware I could test on
if you do at all I assume it would likely be far into the future I would assume, but regardless

- Nintendo Switch (it can run UEFI)
- Pi 3B
- Pi 4
- A large variety of Pi 0s
- A bunch of shitty Android devices

craggy tide
sacred gyro
#

¯_(ツ)_/¯

neon crane
#

thanks, I'll go check it out

#

it seems to boot to a bash prompt, but I can't type in anything

#

for transparency, I have and am using an actual PS/2 keyboard

#

and Limine and Boron work with it

inland cliff
#

pro move

grand shadow
#

I have to get that ps/2 thing sorted sooner or later but its not that much of a priority now since I cant reliably test it myself

neon crane
grand shadow
#

Yeah the kernel-src subdir is compilable on its own

neon crane
#

I get this:

iprogramincpp@IPROGRAMINCPP2:/mnt/c/Work/x/Astral/kernel-src$ make
# build build.h file
echo "#ifndef _BUILD_H" > include/build.h
echo "#define _BUILD_H" >> include/build.h
echo "  #define BUILD_DATE \"Sun Jul 28 19:47:32 UTC 2024\"" >> include/build.h
echo "  #define BUILD_TARGET \"x86-64\"" >> include/build.h
echo "#endif" >> include/build.h
make astral
make[1]: Entering directory '/mnt/c/Work/x/Astral/kernel-src'
[CC] arch/x86-64/acpi.o
cc -g -ffreestanding -mcmodel=kernel -O2 -mno-red-zone -mgeneral-regs-only -mno-mmx -mno-sse -mno-sse2 -nostdlib -Wall -I "/mnt/c/Work/x/Astral/kernel-src/include" -I "/mnt/c/Work/x/Astral/kernel-src/include/x86-64/" -I "/mnt/c/Work/x/Astral/kernel-src/flanterm" -DPRINTF_DISABLE_SUPPORT_FLOAT  -c -o arch/x86-64/acpi.o arch/x86-64/acpi.c
cc1: error: code model kernel does not support PIC mode
make[1]: *** [Makefile:33: arch/x86-64/acpi.o] Error 1
make[1]: Leaving directory '/mnt/c/Work/x/Astral/kernel-src'
make: *** [Makefile:25: all] Error 2
#

also it wants a <limine.h> in the includes which... okay?

#

why?

#

also youre gonna wanna enable dependency file generation at some point

#

passing -MMD to gcc will generate a .d file alongside the .o, use patsubst on the object file list to turn it into a dependency file list and -include it in the makefile

grand shadow
neon crane
#

independently compilable my ass, I needed to download flanterm and check it out in kernel-src

#

why not embed it as a submodule?

grand shadow
#

I download it when regenerating the source with jinx lmao

#

uhh after jinx regenerates it I think it puts it in sources/astral or something

neon crane
#

also this is weird

#
cc -g -ffreestanding -mcmodel=kernel -O2 -mno-red-zone -mgeneral-regs-only -mno-mmx -mno-sse -mno-sse2 -nostdlib -Wall -fno-pie -fno-pic -I "/mnt/c/Work/x/Astral/kernel-src/include" -I "/mnt/c/Work/x/Astral/kernel-src/include/x86-64/" -I "/mnt/c/Work/x/Astral/kernel-src/flanterm" -I "/mnt/c/boron/limine" -DPRINTF_DISABLE_SUPPORT_FLOAT  -c -o sys/timekeeper.o sys/timekeeper.c
sys/timekeeper.c: In function ‘timekeeper_time’:
sys/timekeeper.c:26:20: error: expected identifier or ‘(’ before numeric constant
   26 |         timespec_t unix;
      |                    ^~~~
sys/timekeeper.c:27:13: error: request for member ‘s’ in something not a structure or union
   27 |         unix.s = bootunix;
      |             ^
sys/timekeeper.c:28:13: error: request for member ‘ns’ in something not a structure or union
   28 |         unix.ns = 0;
      |             ^
sys/timekeeper.c:29:29: error: incompatible type for argument 1 of ‘timespec_add’
   29 |         return timespec_add(unix, fromboot);
      |                             ^~~~
      |                             |
      |                             int
In file included from /mnt/c/Work/x/Astral/kernel-src/include/kernel/timekeeper.h:4,
                 from sys/timekeeper.c:1:
/mnt/c/Work/x/Astral/kernel-src/include/time.h:19:50: note: expected ‘timespec_t’ but argument is of type ‘int’
   19 | static inline timespec_t timespec_add(timespec_t a, timespec_t b) {
      |                                       ~~~~~~~~~~~^```
#

no timespec_t 🥺

grand shadow
#

wtf

neon crane
#

damn

#

maybe you should try your build system on multiple machines

#

not trying to insult or anything but i think it needs a refactor

grand shadow
#

tbf it expects everything to be run from jinx

#

with the cross compiler

neon crane
#

throws a bunch of "No such file or directory" errors and quits

#

idk I was hoping I'd be able to simply build the kernel so I can fix the ps/2 issue

grand shadow
neon crane
#

something starting with root.x86_64

#

i can checkout the repo and try again if you want

#

nvm i didnt delete it

#

oh this

#

also whys it gotta download 182 mb every time I run jinx

grand shadow
#

I think its downloading the arch stuff

#

no ide about those errors, I didn't make jinx

#

also the missing printf.h stuff is cuz I also use an external printf that gets downloaded on the jinx regenerate

#
name=astral
version=0
source_dir="kernel-src"
allow_network="yes"
imagedeps="wget"
flanterm_commit="347d9cf1e3fced64aa20ab278e2fdcc834086035"

regenerate() {
    rm -f include/limine.h
    rm -f io/printf.c
    rm -f include/printf.h
    rm -rf flanterm
    curl https://raw.githubusercontent.com/limine-bootloader/limine/trunk/limine.h > include/limine.h
    pushd /tmp/
    wget https://github.com/mpaland/printf/archive/refs/tags/v4.0.0.tar.gz
    tar -xf v4.0.0.tar.gz
    wget https://github.com/mintsuki/flanterm/archive/${flanterm_commit}.tar.gz
    tar -xf ${flanterm_commit}.tar.gz
    popd
    cp /tmp/printf-4.0.0/printf.c io/printf.c
    cp /tmp/printf-4.0.0/printf.h include/printf.h
    cp -r /tmp/flanterm-${flanterm_commit} flanterm
}
#

t does this

grand shadow
craggy tide
neon crane
#

#

I had to add -fno-pie -fno-pic myself

craggy tide
#

i mean his kernel probably relies on being built inside jinx

#

which isn't a good idea

#

ideally a kernel should compile anywhere regardless

#

it is handy for things like setting up a language server with bear, for example

grand shadow
#

well update on that computer I had

#

it powers on but doesnt work enough even for the display on the back to show anything useful

#

so that wont be useful

grand shadow
#

anyways

#

I will try to compile gcc again for shits and giggles

#

configured, building now

#

it tries to redefire errno

#

cuz apparently configure thinks I dont have stdc headers?

#

yeahhhh I don't think this is quite right

#

honestly surprised by how usable this has been, I have been debugging this from inside astral

#

from disk too

analog berry
#

nice

grand shadow
#

this is whats making it die

#

I don't know hwo to read bash very well but like its there?

wild marsh
#

maybe the grep script is swallowing the exit status?

#

why does it pick egrep over grep -E?

grand shadow
#

Ill check when Im home

craggy tide
#

it's normal

#

it's just a warning

grand shadow
#

that probably explains some things lol

#

seems like grep wants splice

#

I'll just comment it out I cannot bother

wild marsh
#

what does your /usr/bin/egrep actually contain?

grand shadow
wild marsh
#

i assume it execs grep? if so then that should actually pass the error code correctly

grand shadow
#

yeah it does

#

but I think the issue is due to the redirections or something grep wanted splice and since its unimplemented mlibc paniced

#

which causes it to try egrep

wild marsh
#

strange that egrep apparently works though?

grand shadow
#

commenting out that ifdef for the splice call makes grep work with when called like that now

#

time to see if that changes anything in the configure

#

yup, fixed

#

anyways time to see if this will fix the other issue

#

while it was compiling with stdout piped like that I saw it also complained about diff missing, so I might port that too

#

yuuup

#

saw the checking for ansi c header files... yes

#

aaand libiberty built

#

now its actually configuring gcc itself I think

#

do I have a fucking leak

#

yeahhh

#

shit

prime juniper
#

At least you bubble it up

#

We just die

#

I think I should focus on self hosting after my vacation

analog berry
grand shadow
#

well I wrote a simple tool to see the number of allocations that haven't been free'd
its quick dirty and sloooow but I can wait

analog berry
#

Visual lsan

tawdry edge
#

Time is infinite

#

Slowness is eventually nothing

fleet osprey
#

yknow you can tell QEMU to just give it 1TB of RAM, and put the RAM as a file on large storage
if you just throw enough storage at the problem eventually it goes away :)

grand shadow
#

I ended up finding the problem :p

#

I was forgetting to free() the inode/block bitmap in ext2

#

woopsie!

#

ended up also finding some other leaks so those are fixed

fleet osprey
#

nice!

grand shadow
#

time to try it again

#

configuring gcc, think it passed where it was before

#

nice

#

time for the real test

#

this is weird, I can run make again which I couldn't last time

#

wait could it possibly be that I'm building it from the main tree

#

hmm

#

yeah otu're not supposed to do that

grand shadow
#

that does not look like an oom

#

out of memolry is when you have over 7gb free apparently

#

so maybe a system call return value is borked

#

oh

#

its a zero sized read

#

I am fucking

#

ugh

#

well posix says zero reads should just return 0 and fuck off so thats easy

#

actually wait

#

fuck off after making sure the fd exists and stuff

#

well at least I discovered a few leaks meme

#

alright hope this works now

#

fixincludes now

#

I'll leave this running now

#

still going strong

wild marsh
#

nice

warped plinth
#

nice nice nice

grand shadow
#

it has severely slowed down tho lmao

#

taking minutes to compile some of these files

#

but I think thats just cuz of gcc being heavy

fleet osprey
#

tbh, I've seen Linux PCs that compile slower than that

#

honestly quite impressive that you've already gotten Astral that fast

grand shadow
#

a few seconds per file rn

fleet osprey
#

idk, that's still pretty good
I have a machine that takes several hours to compile 50% of xmrig, then fails

grand shadow
#

damn

#

I hope this doesn't run into issues in the middle of compiling

#

it'll be hell to debug

#

good time to play factorio while I wait tho meme

grand shadow
#

well shit

#

this fucking bug

#

it happens so rarely

#

it compiled gcc for an entire hour straight before dying, thats progress

#

I'll leave qemu open to try to get this shit fixed tmr

winged basin
#

compiling GCC is an insane torture test

prime juniper
#

I’ll have to subject managarm to the torture test but I’m pretty sure autotools configure will fuck me on that fcntl.h test (issue open on Managarm)

grand shadow
#

I was surprised it lasted for as long as it did, but it is a welcome surprise

#

This virtio block bug has been pestering me for a bit but Ive never been able to get to the end of it

#

It happens rarely enough to not be easily reproducible but often enough to annoy me

#

I do think that seems like the only instability bug when running on a single cpu

grand shadow
#

My end goal with this is to eventually do some sort of "astral from scratch", where I will build an astral distro capable of building other software from inside astral itself

analog berry
#

@grand shadow im kinda bored so uhhh... do u want acpi support in your kernel?

grand shadow
#

I dont use it for anything other than the tables and I dont have any system at all for shutdown atm but if you want to play around with it I wont stop you lol

analog berry
#

nor does managarm lol

#

we can hook up the power button ig

grand shadow
#

Sure I suppose

#

Gl understanding the code meme

analog berry
#

is it that bad?

grand shadow
#

My coding style might be a bit weird but its muuuuch better tham old astral

analog berry
#

also since u have ported a bunch of software can't we just make a shutdown syscall and make it call that?

grand shadow
#

Yeah

#

Shutdown program that just calls sync and then shutdown or something

analog berry
#

yeah

#

do u have sync?

grand shadow
#

Sync and fsync

analog berry
#

damn

#

this man is years ahead of managarm meme

analog berry
#

u dont separate words in some places ig

grand shadow
analog berry
#

any rules to when u dont separate to keep it consistent?

grand shadow
#

I do the module_function thing and add an arch_ in front when its arch dependant (like arch_mmu_getphysical)

analog berry
#

i see

grand shadow
#

For structs I always typedef with a _t so page_t for example

#

And macros usually are LIKE_THIS

analog berry
#

fair enough

grand shadow
#

Also once everything builds you should probably set the distro type to minimal in the Makefile so you dont have to wait for the full initrd to be loaded

#

I should make it so that it only builds the minimal stuff as well

#

Would make compiling it faster if you just want to test the kernel for example

analog berry
#

i see

#

is there currently a placeholder shutdown thing anywhere?

grand shadow
#

Nope, completely unsupported

analog berry
#

would it live in tools?

grand shadow
#

Yeah

#

Tools is for the userland part of the os like init the dhcp client etc

analog berry
#

i see

#

makes sense so far

#

and i also appreciate just typing make and getting it to work

#

because i absolutely hate fighting with build systems

grand shadow
#

Thank mint for jinx lmao

#

Actually wait I just thought of something which could be an issue
@analog berry does uacpi unmap memory directly?

flat copper
# grand shadow well shit

i am thinking that it has to do with you setting queuewaiting[idx] from one core, and the DPC happens on another

grand shadow
flat copper
grand shadow
flat copper
#

compiler reordering?

flat copper
#

maybe you need to do volatile with blkdev, like notify = 0 is set before queuewaiting

grand shadow
# analog berry yeah

I think theres a bug in my vmm that causes physical mappings to try to change some page struct that doesnt exist, I think I can fix that later today

#

When you unmap them

#

For now you can just try running sithout unmapping

analog berry
grand shadow
#

And module pages too

analog berry
#

ohh ok

grand shadow
#

Not acpi

analog berry
#

well aml accesses reserved ranges, not acpi ranges

#

so anyways

#

but sure ill just not unmap for now

grand shadow
#

When slacking off at work today I will see if I can read through the virtio block code again

flat copper
#

is that even legal in c?

analog berry
#

i mean i doubt its anything that complex

#

if its single core its probably just a logic bug

grand shadow
#

Yeah

analog berry
#

lemme know when the unmap bug is fixed

grand shadow
#

Wont be for another 10 hours, its 8 am rn

analog berry
#

np lol im not that fast

grand shadow
#

Oh lmao

analog berry
#

would a submodule be ok then?

grand shadow
#

Sure

#

I probably should switch out my stuff to submodules anyways

#

Rn it just downloads them in the jinx regenerate

#

Since it depends on flanterm, some printf I forgot the name and limine.h

analog berry
#

ohh i see

analog berry
#

its still building btw lmao

#

..and just finished looks like

grand shadow
#

Yeah it takes a bit, it has to compile gcc twice etc

winged basin
inland cliff
wild marsh
#

native non-cross-target that is

wild marsh
#

if you don't pass --disable-bootstrap, compiling gcc will first build gcc with your current system compiler, then compile gcc with the just compiled gcc, then compile gcc with the new just compiled gcc, and it will finally compare the last 2 gccs to see if there are any differences

winged basin
#

in the end i got a gcc that passed the test but perl of all things built a dud miniperl

#

perl of all things

#

called one of the most portable programs to ever exist

grand shadow
#

I will pass that flag when building it on astral lmao

wild marsh
#

yeah

grand shadow
#

Probably just saved me hours of waiting

prime juniper
#

Oh yeah gcc uses Perl during its build step. That’s gonna be annoying

grand shadow
#

How difficult is it to port?

eager copper
#

halfmemeright if dennis says annoying, I'd take that as not so easy

grand shadow
#

actually hm

#

nescessary when regenerating makefile dependencies in libiberty

#

I dont think I have to do that?

#
Perl version 5.6.1 (or later)

    Necessary when targeting Darwin, building ‘libstdc++’, and not using --disable-symvers. Necessary when targeting Solaris with Solaris ld and not using --disable-symvers.

    Necessary when regenerating Makefile dependencies in libiberty. Necessary when regenerating libiberty/functions.texi. Necessary when generating manpages from Texinfo manuals. Used by various scripts to generate some files included in the source repository (mainly Unicode-related and rarely changing) from source tables.

    Used by automake.

    If available, enables parallel testing of ‘libgomp’ in case that flock is not available.
#

idk

wild marsh
#

if you don't ./bootstrap it's probably not needed?

grand shadow
#

thats what I assume since it was building fine up until that point

#

and I think it built libiberty too

prime juniper
#

Thank fuck

#

Perl is notably not portable unless you yeet Perl-cross over it but managarm’s Perl still has issues. Like it’ll run basic scripts fine, including a 2048 game, but autoshit has issues finding modules?

#

That means managarm gcc configure stress test is still on for somewhere in the next 2 weeks

grand shadow
#

but the index of the buffer in the queue is 0 somehow?

#

actually wait

#

I'm stupid

#

there is something in buffer 0

#

buuut

#

no threads are waiting there

#

there is a thread waiting on buffer 1

#

wait

#

agh

#

I dont know

#

this is so fking strange

#

I use the same dpc code for vionet

#

and it works there without this random crash

#

yeah, there is something on 1 but not 0

#

could it possibly be some very specific race in the enqueue?

#

thinking about it....

#
size_t driveridx = VIO_QUEUE_DRV_IDX(&blkdev->queue)++;
VIO_QUEUE_DRV_RING(&blkdev->queue)[driveridx % blkdev->queue.size] = idx;

sched_preparesleep(false);
blkdev->queuewaiting[idx] = _cpu()->thread;

*blkdev->queue.notify = 0;

I should increment the driver index right before the next notify, otherwise theres a chance the virtio device will process it while its not fully prepared

#

2 threads want to read from the device, one adds it normally and notifies and goes to sleep, and releases the lock
the other one comes in and increments the driver index but after the driver index is set up and before the buffer index is set the device handles the request and the wrong buffer there is used

#

which explains why it happens so rarely

#

that is like

#

the only fucking thing I can think of

#

welp

#

time to do this and pray that was it

#

because I cannot reproduce this bug easily :D

obsidian pivot
#

my strategy for debugging OBOS's weird bugs is guess the wildest things that could've possibly happened and investigate that

#

maybe that explains why developement is so slow....

grand shadow
#

time to do the vmm fix for uacpi and then leave it building gcc again so I have an excuse to play factorio

inland cliff
wild marsh
#

you still end up needing either gcc for every target, or at least compiler-rt for every target

#

and you still need to patch and recompile llvm and clang to add your custom os target to it

grand shadow
#

alright, put it to build again now, hope it doesn't die

#

w/ disable-bootstrap too so it hopefully doesnt last 5 days

#

I wonder how many hobby oses have managed to build gcc

#

I think sortix might have? I remember seeing on the sortix.org page that their release was built under itself

#

though it could be talking about the kernel lol

#

also @analog berry I've pushed the unmapping fix

grand shadow
#

its still going, maybe this time is the one

grand shadow
#

its linking cc1

#

oh boy

grand shadow
#

jesus its still linking cc1

#

and it hasn't deadlocked so thats good

grand shadow
#

Finally lonked cc1

#

Welp that was today's attempt

#

Tmr Ill try again and see what couldve caused this

wild marsh
analog berry
wild marsh
#

probably no, we still struggle with configure scripts of smaller projects

analog berry
#

which part specifically?

wild marsh
#

i mean see last messages in managarm-dev in the managarm server :^)

prime juniper
#

fcntl autotools check is being nasty

#

and gcc configure gives a broken Makefile

grand shadow
#

back to the grind

#

I was stupid last night and closed the vm without running sync

#

hopefully everything was automatically synced

#

well shit filesystems fucked meme

#

gcc building again, this time I wont be stupid enough to forget to sync hopefully

grand shadow
#

Left it building while visiting family, hopefully it doesnt explode

warped plinth
grand shadow
#

I think I left it at 30 seconds I forgot

#

Still, just got home

#

Its still compiling

#

I think it didn't go very far though

#

my laptop went to sleep cuz I forgot to leave it charging

#

its in the middle of the gcc build still I think

#

I dont think it got to the point of linking cc1 yet

warped plinth
#

o h

grand shadow
#

what was it trying to do there

#

oop finally got to the cc1 linking

#

this is gonna take a while now

grand shadow
#

cc1 linked, soon I will know if this will work

#

syncing the disk this time

#

the first page fault did happen in a library though, assuming libc

#

apparently died on a frigg rbtree remove half leaf function

wild marsh
#

that sounds strange

grand shadow
#
addr2line -e sysroot/usr/lib/libc.so 0x23fcb
/sysroot/usr/share/mlibc-build/frigg/include/frg/rbtree.hpp:330
#

disassembly does agree with this being the cause of the fault

#
                if(succ)
                        h(succ)->predecessor = pred;
wild marsh
#

could be heap corruption of some sort

#

the only place rbtree is used in mlibc is indirectly via the slab allocator

grand shadow
#

I load binaries at 0x1000000 so it does seem strange that it has an address kinda close to it

#

well I'm gonna let the disk sync and then run it again and take a look at the memory map

#

aghh I really need to make my disk sync faster lol

obsidian pivot
#

alas; it has gotten too powerful

grand shadow
#

if I can get this disk image to be able to reproduce it with just a make under a minute it'll make my life so so so sooo much easier

#

even if I have to manually switch out libc.so or whatever for testing

grand shadow
#

(it probably will)

#

Either way I will only be able to work on this friday, tomorrow Im going out with my coworkers after work

grand shadow
#

succ

#

disk synced, e2fsck returns no issues

#

Bruh it gotta link cc1 again

#

Ill leave it doing that

grand shadow
#

That will be after I get/give up on getting gcc to compile though

grand shadow
#

Hmmmmmm

#

Do I do sound or fat32 first

analog berry
#

sound

fleet osprey
#

fix the PS/2 code troll

grand shadow
fleet osprey
#

I can't mail you my entire NAS lmao

#

17" x 7" x 14"

#

and weighs a ton

#

it's a big chonky workstation

grand shadow
#

Just teach it to fly

#

Damn I cant access the OSS website at work bruh

obsidian pivot
grand shadow
#

after (possibly) fixing a double free in ext2, I'm ready to go after the gcc compilation bug again

#

I say possibly because it happens like 30 minutes into linking cc1 from the disk I have so I will know when cc1 links

grand shadow
#

yup, seems like that was fixed

#

now onto debugging this shit

#

yeah, it dies on a malloc

#

I should see if I can get this to happen without having to run make

obsidian pivot
#

alas, the oberrow curse seems to be upon you

grand shadow
#

00000000124a7000-00000000124de000 0000000000037000 urw
00000000125c0000-00000000125d1000 0000000000011000 urw

#

it tries to access between those two ranges

#

and it does seem to be consistent between invocations that 0x12500050 is the faulting address

#

so first I will see when this address gets mapped and unmapped

#

NOOOO I FORGOT TO SCREENSHOT THE FUCKING COMPILATION COMMANDJGKDGNJFSM,KHSFLHFJK

grand shadow
#

screenshotted

#

though

#

it does seem the address was never unmapped

#

or I added the wrong check

#

I did, infact, add the wrong check

#

aaaa

#

actually wait no

#

I made both printfs the same

#

I am so stupid

#

manually calling the build makes it not segfault

#

actual insanity

#

welp this is gonna take a while to debug

warped plinth
#

yippie!!! :DDD

fleet osprey
#

lovely
that's weird as hell
maybe some of the earlier stuff that happens by make consistently puts the system into a state where the bug can trigger?

grand shadow
#

ah whatever I give up I don't know how mlibc's malloc works and it takes an entire hour to get to the point where it matters

#

the memory gets unmapped but seemingly the pointer to there still exists

wild marsh
#

mlibc's allocator doesn't unmap memory unless it's was large allocation (larger than largest slab)

grand shadow
#

I am this close to just giving up on gcc for now and go read to try to add audio

#

I'll add a breakpoint to syscall_munmap when the range to unmap contains that address and leave it compiling one last time while I do research on audio stuff

prime juniper
#

If you get a tangible issue that’s mlibc related, feel free to report it! I’ve been doing the same trying to configure coreutils and sed, and I have more on the todo list

grand shadow
#

I should open that ppoll issue though

grand shadow
wild marsh
#

yeah

#

map is used to allocate both memory for slabs and large objects, but only the latter ever get unmapped

grand shadow
#

this is so weird

#

I can't really tell if this is an mlibc issue or an astral issue

#

and atp I'm only gonna make my headache worse if I try

#

should I open an issue about this

wild marsh
#

probably a good idea

#

i suppose what we could do is compile all the necessary programs for linux with mlibc and then try compiling gcc

grand shadow
#

that is true

wild marsh
#

cc @prime juniper

prime juniper
#

Time to revive Linux mlibc

#

I’ll see if I can tackle that soon

grand shadow
#

time to sit my ass down and read some of the intel hda spec

grand shadow
#

huh what

#

I did *something* that made X.org start logging again

#

I don't know what it was but uh

#

its logging now?

#

like when I ported it, it didn't put anything on stdio, only writing to the log file

#

wtf

#

well maybe it was actually handling nbytes=0 lol

prime juniper
grand shadow
#

qemu hda doesnt support msix, I think its time I finally stop being lazy and implement normal msi

prime juniper
#

if I knew that I wouldn't be wanting to throw something herre

#

I have no coredump nothing

#

/mnt/linux/managarm/linux-mlibc/scripts/lfs.sh: line 62: 1474491 Segmentation fault chroot $ROOT /usr/bin/env -i HOME=/root TERM="$TERM" PATH=/usr/bin:/usr/sbin /bin/bash --login is all I get

grand shadow
#

wtf

prime juniper
#

ikr

#

if I don't fix this, I can't try compiling gcc and friends on mlibc linux

#

so this is a big yikes

#

and god damn fucking annoying

robust geyser
#

or take a look at dmesg

prime juniper
#

dmesg is empty

#

strace a chroot call, I guess that could work

#

strace was a good call @robust geyser

fleet osprey
#

I've also gdb'd a chroot call, from one Linux system to another, in the situation where python and gdb were both segfaulting in the target
actually works fairly well

neon crane
#

why not unmap slabs when theyre empty

wild marsh
#

because reusing it for later allocations means theyre done faster?

neon crane
warped plinth
#

so, why isn't the playstation 2 code working? /j

wild marsh
#

we probably could do something like madvise(MADV_DONTNEED) if the whole page is no longer used

prime mulch
wild marsh
#

we don't have swap no

obsidian pivot
#

come on

#

even OBOS has swap*
*not on disk (yet)

neon crane
inland cliff
neon crane
#

I assume to avoid a useless syscall

neon crane
obsidian pivot
wild marsh
grand shadow
#

Ive opened an issue on mlibc about the allocator issue

prime juniper
#

Thanks for the report

grand shadow
#

I made my mmap more posixy, time to se if that will help anything

#

I wasn't handling MAP_FIXED properly and failing if there was already a mapping there

#

dont think that'd help much though

#

if it doesn't I will use the mlibc debug allocator

#

I said I wasn't going to try debugging this but meh I want astral to be self-hosting already

grand shadow
#

also I might have to port diffutils to make this faster

grand shadow
#

ported diffutils, lets see if this will make it not have to relink cc1

#

YEAHHHH IT OESN'T

#

okokokok

#

this makes life so much easier

obsidian pivot
#

||Ctrl+C||

#

you know if you don't like doing all this bs, just port Astral to the m68k

#

many studies show that it calms the heart

#

causes inner peace

grand shadow
#

looking deeper into it: it seems like the free_huge_ function is called for the slab but the rbtree still seems to have a pointer to the hook?

grand shadow
wild marsh
#

not really honestly

grand shadow
#

so enabling FRG_SLAB_TRACK_REGIONS gives me this assert fail

grand shadow
#

h(grand)->color seems to be color_type::red

#

ugh I am too dumb to understand this shit

wild marsh
grand shadow
#

alright

#

/sysroot/usr/share/mlibc-build/frigg/include/frg/rbtree.hpp:164: Assertion 'check_invariant()' failed!

#
    void insert_right(T *parent, T *node) {
        FRG_ASSERT(parent);
        FRG_ASSERT(!get_right(parent));

        if(enable_checking)
            FRG_ASSERT(check_invariant());```
wild marsh
#

does it happen earlier than the slab crash?

#

kinda hard to tell without a backtrace ig

grand shadow
# wild marsh kinda hard to tell without a backtrace ig

Linked list (successor, forward) violation

/sysroot/usr/share/mlibc-build/frigg/include/frg/slab.hpp:508
/build_dir/builds/mlibc/../../../base_dir/sources/mlibc/options/internal/include/mlibc/global-config.hpp:13
then the rest is in cc1plus I assume

grand shadow
#

lemme see what the rbtree checks say when FRG_SLAB_TRACK_REGIONS is disabled

wild marsh
#

hm

#

hm, does your anon_allocate return memory that's zeroed out?

grand shadow
#

yeah, x/4096c (((uint8_t *)zeropage) + 0xffff800000000000) shows everything as 0

grand shadow
#

reads from disk are usually going to be page_sized as it will be read into the page cache
currently reading block by block because lazy
change it to read page by page whenever possible
it gets 8x faster

#

I hate my past self with passion

prime mulch
#

wait until u do clustered page-in

fleet osprey
neon crane
#

seems like yeah

#

im going to change my kernel to use an MDL to perform io operations instead of a bare buffer

grand shadow
grand shadow
#

currently implementing named fifos, so I can try out the make jobserver and something else I'm curious about

robust geyser
#

took me a while to figure out what a j observer is

grand shadow
prime juniper
#

Nice

#

You don’t run into autotools wanting to run?

#

Like on managarm, we do configure (cache a few items), then issue make, but make then invokes autoconf and friends and we don’t have that (nor should it be required)

#

We also build from a tarball

grand shadow
#

not really, I dont even have automake or autoconf ported

prime juniper
#

Yeah

grand shadow
prime juniper
#

The tarball that is right?

grand shadow
#

yeah

prime juniper
#

Yeah same

grand shadow
prime juniper
#

(From the host into the sysroot but that shouldn’t make a difference)

grand shadow
#

I do it directly from astral meme

prime juniper
#

I could do that too (and have done so)

#

But can’t be bothered

#

And our update image command will nuke whatever I do inside the image unless it’s in the sysroot

#

I guess we can change the rsync command to not do that but meh

lean kettle
grand shadow
#

the build system only generates the .iso but it leaves a sysroot folder that I have a handy script to use for creating a disk image

lean kettle
#

it would amount to maybe removing --delete to the rsync command we use for the /root folder

prime juniper
#

Probably

robust geyser
#

good work sir

grand shadow
#

tyty

neon crane
#

jokes aside, good job, hopefully you can get to compile gcc on astral very soon 🤞

grand shadow
#

speaking of compile gcc, @prime juniper did you ever manage to get mlibc linux to work

prime juniper
#

Not yet. I get further on configure but flex is segfaulting

grand shadow
#

so now I am faced with the choice of what to do next:

  • continue debugging gcc
  • audio
  • actually support multiple users and stuff
  • fat filesystem
#

or the 5th option which is continue procrastinating on ftl

analog berry
#

i'd say do the first to be officially better than managarm as well as make a meaningful contribution to mlibc by fixing its bugged rb tree

prime juniper
#

It’s a miracle we haven’t ran into that rb tree thing

#

So that would be nice

grand shadow
#

Failed node: 0xff00000 sucessor(node) is 0xff80000 succ is 0x12500000

#
                        if(successor(node) != succ) {
                                mlibc::infoLogger() << "Linked list (successor, forward) violation" << frg::endlog;
                                mlibc::infoLogger() << "Failed node: " << node << " got sucessor(node) is " << (void *)successor(node) << " succ is " << (void *)succ << frg::endlog;
                                return false;
#

I have no idea what I am doing

wild marsh
#

what does _less(*successor(node), *succ) return?

grand shadow
grand shadow
#

honestly I think I will just get the multiuser stuff out of the way

#

the longer I wait the more work it will be down the line

#

since I'll have to go through a bunch of stuff to make sure it does the right calls to check for permissions etc

#

while I scribble that out on paper I will leave gcc building with -j2 and the less shit disk rw to see how stable it is on j2 and how faster it willbe now

#

I think the mlibc logging might be starting to slow down the configure a bit

#

and a print I forgot oops

#

still seems much faster than before

#

and I'm leaving it building on an xterm window now rather than the system console

warped plinth
#

how'd the gcc build go?

grand shadow
#

Had an assert fail but I know whats going on

grand shadow
#

I was wondering why everything was running so slow and was starting to think I did some shit in the kernel that slowed everything down
then I remembered I left jinx to build at -O0 so I could debug mlibc better oops

#

gcc build again

#

time to see if it reaches the mlibc bug with j2

grand shadow
#

also I should port xscreensaver for the silly

grand shadow
#

it did reach the bug

#

much faster this time

grand shadow
#

xscreensaver seems to be checking for the libraries on the configure --libdir path this is crazy

#

how does someone fuck autotools up this badly

#

I had to manually remove all the -L$libdir and -I$includedir shit from LDFLAGS and CFLAGS/CXXFLAGS in configure.ac

grand shadow
#

sooo cross compilation friendly jesus christ

#

and to top it all off, it uses $(install_prefix) instead of $(DESTDIR)

#

IT KNOWS ITS NOT AVAILABLE
AND IT TRIES TO INSTALL IT ANYWAYS

#

oh my god

obsidian pivot
#

lmao

#

gl

grand shadow
#

good news! it starts fading the screen out
bad news! it segfaults in some library

#

trying to figure out now

#

it dies in that if (*xlfd != '-') check

grand shadow
#

some sscanf seems to be failing and making it pass null to the name

#

time to see if mlibc bug or smth else

#

after I make dinner

grand shadow
#

oh huh mlibc doesn't implement %f

#

for scanf

#

it seems

#

guess I'm gonna open an issue about that

#

and just patch it out in xscreensaver to use %d or whatever

#

it seems like it just

#

gets the float and then multiplies it by 10 and casts it to into in a sprintf later

#

I could get to implementing it tomorrow or something but idk if I'll do it in the right way

warped plinth
#

nice :3

grand shadow
#

thats one more motivation to add multiuser support, screensavers

grand shadow
#

for today I will implement the system calls for set*id

#

and get*id

grand shadow
prime juniper
#

Nice work

grand shadow
#

@prime juniper I'm getting the itch

#

does webkitgtk need any procfs memes?

robust geyser
grand shadow
#

I am probably gonna do something similar to kauth(9) per fadanoid's suggestion

#

as tomorrow I wont be as tired (hate that my university does exams on saturdays) I will probably set some actual goals for what I want:

  • llvm and mesa
  • ultimately decide how to stop people from doing things they shouldn't
  • actually go around the kernel and implement all of these checks I haven't
#

the last one I probably wont fit in a day since there are a lot of places and cases

prime juniper
#

But; here’s a good tip. Get LLVM and Mesa with LLVMPIPE up and running

#

You’ll thank me later

prime juniper
errant zephyr
prime juniper
#

You can, by claiming to be one of the BSDs for example

#

Or Darwin probably

#

I don’t know how painful those are

#

But they’ll require some BSD items likely. Pretty sure I saw kqueue somewhere in the BSD paths

#

(Oh and you’ll want to make sure that whatever you claim to be, you claim the same to glib)

errant zephyr
#

for that matter you could try writing your own complete webkit port

prime juniper
#

Yep, that can be done too

grand shadow
#

I wonder which would be harder, own port or pretending to be someone else

grand shadow
#

the fact that the first thing is namd wtf is comforting

errant zephyr
prime juniper
errant zephyr
#

im pretty sure webkit is intended to be really portable so

#

it cant be that bad

prime juniper
#

It’s still a bunch of effort tho, and may require a glib backend too. As webkit calls into some glib memes on Linux (likely other platforms too) which I know on Linux will use netlink

grand shadow
#

I wonder why the hell is gcc not building libstdc++-v3 with -fPIC

grand shadow
#

llvm takes so long to compile they should've written it in c instead of c++ smh

grand shadow
#

yeah no I'm just not building clang with this

#

just llvm so I can use it with mesa

prime juniper
#

Understandable

craggy tide
prime juniper
#

cries in slow

grand shadow
#

My poor thing started swapping like crazy at the end of it and I had to turn down the job count lmao

dim arrow
#

llvm for me used to take 5+ hours to compile....

fleet osprey
#

I honestly wonder how bad that would be if I tried it on my iBook G3, if it takes fairly good PCs hours.......

robust geyser
#

it took around 30 minutes on a 4690k, and that is not decent by todays standards

#

and that was just llvm, no clang

#

and one target

obsidian pivot
#

TO(not)DO: Compile LLVM

grand shadow
#

no progress today because I had to speedrun an assignment

#

did what was supposed to be a group assignment solo in 6 hours

#

but it was the best snake clone I've ever written :')

#

I do have a bad headache now but worth it for the like 15% on the file grade (I was going to pass that class with or without it)

grand shadow
#

now do I want to finish the mesa port today

#

is it supposed to take this much space :(

wild marsh
#

did you forget to -DCMAKE_BUILD_TYPE=Release?

grand shadow
#

nope

#

it is full of .a files

wild marsh
#

oh

grand shadow
#

wait does vinix recipes delete them

#

seems like so

#

down to 3.7g now

wild marsh
#

what targets are you building it for

grand shadow
# wild marsh what targets are you building it for
        cmake \
        -GNinja \
        -DCMAKE_TOOLCHAIN_FILE=${base_dir}/util/cmake \
        -DCMAKE_INSTALL_PREFIX=${prefix} \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_LINK_LLVM_DYLIB=ON \
        -DLLVM_ENABLE_FFI=ON \
        -DLLVM_ENABLE_EH=ON \
        -DLLVM_ENABLE_RTTI=ON \
        -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-astral \
        -DLLVM_HOST_TRIPLE=x86_64-astral \
        -DLLVM_TARGETS_TO_BUILD="X86" \
        -Wno-dev \
        ${source_dir}/llvm

        ninja -j${parallelism}
}

package() {
        DESTDIR="${dest_dir}" ninja install

        find ${dest_dir} -name '*.a' -delete
}```
#

only x86 I think

wild marsh
#

4GB sounds about right i think

#

for llvm + clang

grand shadow
#

I dont think I built clang

#

yeah I disabled that

#

would take too long

wild marsh
#

oh right this is for astral, not for the build machine

#

seems a bit large then hm

grand shadow
#

most of it is still in libLLVM

#

llvm-exegesis is 1.2g

#

is that nescessary

#

according to the website its a benchmark tool

wild marsh
#

strange

#
qookie@selenium ~/projects/managarm/build-x86 λ ls -lh system-root/usr/bin/llvm-exegesis 
-rwxr-xr-x 1 qookie qookie 48M Jan  1  1970 system-root/usr/bin/llvm-exegesis
grand shadow
#

wtf

wild marsh
#

(don't mind the ctime)

grand shadow
#

maybe its cuz I dont strip the executables?

wild marsh
#

well -DCMAKE_BUILD_TYPE=Release should build without -g so no debug info should be generated

#

one thing that's different in the managarm recipe is that we don't pass -DLLVM_ENABLE_FFI=ON or -DLLVM_ENABLE_EH=ON

#

we do pass -DLLVM_ENABLE_RTTI=ON though, not sure why we don't pass the other ones

grand shadow
#

I just stole the vinix recipes which I assume are supposed to work fine

#

oh my god I AM SO STUPID

#

I left -g in my jinx-config

#

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

wild marsh
#

oh lol

#

that'd do it

fleet osprey
#

lol, it happens
wonder how different the build time is gonna be now

grand shadow
#

hopefully not too long

#

if it does I should just go to sleep I am exhausted

grand shadow
#

Tmr Ill port mesa

grand shadow
#

If anyone feels like trying it out, I have a disk image and boot disk in my server:

first option will boot to fvwm running from disk
second option will boot to a login prompt
third option will boot to the system console running from disk
and fourth option will boot to the system console running from a minimal initrd

to configure networking run netd vionet0
if youre in the system console and want to run xorg run startwm

https://avalios.dev/bootdisk.iso
https://avalios.dev/root.img
qemu-system-x86_64 -enable-kvm -M q35 -cdrom bootdisk.iso -m 4g -debugcon stdio -drive file=root.img,if=none,id=nvme -device nvme,serial=deadc0ff,drive=nvme -boot order=dc -netdev user,id=net0 -device virtio-net,netdev=net0

#

Its a few days old but should still work fine

grand shadow
#

anyways porting mesa atm

#

soon 3d graphics will be real

fleet osprey
#

get accelerated 3D graphics troll

prime juniper
#

yeah about that

#

that's certified pain

#

but, Managarm is working on a library style project to add support for this and other GPU related items (multi display support for example) for at least intel iGPUs

fleet osprey
#

ooh

analog berry
#

Good luck

grand shadow
#

/sysroot/usr/lib/libX11.so /sysroot/usr/lib/libz.so

#
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [/sysroot/usr/lib/libz.so]```
#

???????

#

hm according to [random github issue I found] this happens because libz doesnt have an SONAME set

#

time to see if I can fix this in zlib

craggy tide
prime juniper
#

Yep

grand shadow
#

I need to implement mprotect

#

fun

grand shadow
#

The good thing about having someone actually play around with your os is that they end up finding bugs you likely wouldnt

obsidian pivot
#

wish I could relate

grand shadow
#

wonder how long until I hit 100 syscalls

#

currently at 84

#

well glxgears doesnt crash anymore because of the lack of mprotect
but it also doesnt display anything lmao

#

wtf?

#

rip is stuck at 0xebe000

#

what even

#

stack trace time

#

I wonder if

#

its something in llvm

#

or like

#

mesa

#

wait

#

it could be that the shaders are being mapped as executable

#

but something is breaking

#

since it does seem to be handling nonstop page faults from gdb

#

cr2 is ebe

#

that is it

#

well time to see whats up

#

ohhh wait

#

lemme see something

#

its page faulting but the vmm_pagefault function is returning ok (otherwise it'd segfault)

#

seems like so

#

yeah

#

I know whats up

#

the mmuflags change but the ones in the mapping don't

#

I should update those

#

oopsie!

#

yeah

#

it goes like this:
vmm_changemap is called, the range->mmuflag value changes, the ones in the actual PTEs dont, and so on a page fault it checks if everything is okay by checking the range and sees that everything is ok so it returns success

#

but in the eyes of the cpu running that code is not valid

#

so it just keeps page faulting at 0xebe000 trying to run it

prime juniper
#

Whoops

grand shadow
#

easy fix probs

grand shadow
#

(the console bleeding into the screen was because of xterm printing to it)

craggy tide
#

pretty neat

analog berry
#

Big

grand shadow
#

doesnt die with 5 so its a win

#

wonder if I could make sdl and tyr-quake use opengl now

#

first I'll upstream this

craggy tide
#

but i think it's a scheduler issue of some sort

grand shadow
analog berry
#

Btw is the rbtree bug still unsolved?

craggy tide
#

nah, i haven't looked into it

grand shadow
#

you should go back to working on vinix more, its cool to see your progress there

craggy tide
#

i am waiting to be paid

grand shadow
analog berry
#

Sadge

craggy tide
#

if i worked on it seriously even when i am not paid then who pays me would have no incentive to do so

#

(also i need money for food and shelter)

analog berry
#

Thats fair enough

grand shadow
#

yeah thats fair

#

hopefully they pay you soon

analog berry
#

Are you going to get paid?

lean kettle
#

hopefully you get paid soon!

craggy tide
#

plus i've been busy with Limine

#

yeah i think maybe sept

analog berry
#

Nice

craggy tide
#

but yeah i am happy to see all the astral progress

#

honestly my favourite project here

grand shadow
#

ty :3

lean kettle
#

astral is very impressive, agreed

analog berry
#

Yeah it makes porting stuff seem trivial

lean kettle
#

although i am obligated to say that managarm is my favourite project halfmemeright

grand shadow
#

I have pretty much removed the initrd option from my local files since I am just running from disk 24/7 now

#

and it runs just fine, you dont even notice that much of a difference after a certain point

#

certainly there is still a lot to be better cough smp cough

craggy tide
#

funnily enough Vinix runs worse with 1 core than with more than 1

#

whatever scheduler issue it has makes it much worse when it's running with only 1 core

grand shadow
#

that is crazy

#

when you find the issue lmk cuz Im interested

craggy tide
#

sure

#

(if i remember to)

#

i'll probably post in the vinix thread

grand shadow
#

the biggest issues with smp in astral are my slow tlb shootdown (like its insane) and just general instability

#

my tlb shootdown just sends an ipi for every page unmapped

#

which is bad

#

but it was the easiest solution and I am a very lazy person

analog berry
grand shadow
#

true

#

I do look forward to the day I build gcc with make -jwhatever in astral and it compiles with several cores perfectly stable

craggy tide
#

Vinix does not have TLB shootdown

#

i think i may force all threads of a process to run on the same CPU for the time being as a poor man's TLB shootdown

lean kettle
#

Maybe I should try adding CPU migration to the Managarm scheduler again

grand shadow
#

I just juggle threads around cpus with no care at all

lean kettle
#

we dont juggle threads at all

#

when a process is created the CPU that thor puts it on is the one it stays on

grand shadow
#

the two ends of the spectrum meme

#

the only places I force a thread to be bound to a cpu is in some per cpu timer handling code and stuff

#

and waiting for timeouts

#

because I use the per cpu timers for almost everything

lean kettle
#

i wonder how cancer it would be to implement some sort of cpu performance counter monitoring

grand shadow
#

ig you could just measure how much it spends on the idle thread per second or something

lean kettle
#

not really even talking about using it for scheduling but just knowing them per thread

#

(at least intel CPUs have perf counters for things like cache misses and pipeline stalls and stuff)

grand shadow
#

ohhhhhhh

#

I have no idea

lean kettle
#

cache misses might be a nice thing to monitor as well for scheduling

#

if a thread constantly has cache misses due to it being chonking rescheduling it on another core could™️ be less damaging

#

while a thread that has almost no cache misses probably shouldnt be rescheduled if possible

grand shadow
#

true

#

I should do something more with priorities in my scheduler some day, I have them implemented but its also barely used outside of just kernel threads having a higher priority

#

doesnt even preempt if a thread with higher priority becomes available yet

#

too lazy to debug that

#

and it does seem like the gl version runs worse

#

I guess llvmpipe is slower than whatever the guy who made tyr-quake managed to make

#

<----- coping that something in astral is SLOW

lean kettle
#

not impossible that whatever tyr-quake does is faster for tyr-quake specifically ig

robust geyser
#

< 60 fps in glxgears is kinda bad ngl

#

i think vinix does like 400

lean kettle
#

llvmpipe has to be able to do everything after all

robust geyser
#

so you definitely have got some optimizing to do

lean kettle
#

managarm gets quite a bit more than that iirc

grand shadow
#

hmmm true

#

gonna leave it running with mint's profiler for a like a minute

#

ringbuffer_reads and ringbuffer_write are the two biggest costs

#

I should try optimising that then

robust geyser
#

inline them

grand shadow
#

I rw byte by byte

#

I think I should begin by making that better

robust geyser
#

holy balls

grand shadow
#

listen I just wrote the ringbuffer routines trying to get it out of the way asap the performance didnt matter until now 😭

#

my memcpy is also byte by byte :')

#

memset too

#

agh

#

first going to make ringbuffer_write/read call memcpy then optimise that

fleet osprey
#

it may not be fast for running quake on a modern pc

#

but it's still playable

#

which is still impressive

craggy tide
robust geyser
#

ok yeah i misremembered terribly

grand shadow
#

streamlined that, 120 fps now

#

still gotta make it better

#

I assume the slow is in memcpy now

#

yup

#

gonna optimize both memset and memcpy

#

I should make my memcpy just rep mosvb

#

it should be optimised enough for anything in the last decade

grand shadow
lean kettle
#

specifically getting geminilake working again

prime juniper
#

Also highly based

#

Maybe after lil then

#

That perf improvement would be big I can imagine

grand shadow
obsidian pivot
#

probably around the same amount

#

(1400 cores)

grand shadow
#

after bettering some things it runs at like 190-200fps

#

better than 60 but aghhhh

craggy tide
grand shadow
#

this had the side effefct of making it run better on the normal tyr-quake version too

#

the gl one does have weird graphical glitches

#

and seems faster?

#

what

fleet osprey
#

that's downright smooth

#

wtf

#

in llvmpipe?

#

I can't even get that much perf through llvmpipe on Linux

grand shadow
#

it does seem like llvmpipe uses multiple threads and cpus

#

ah well I am going to blame it on multicore and my cpu being slower meme

#

i5-10300h

#

searching glxgears in the discord I found something funny

wild marsh
#

if you're on amd and use -cpu host (so that cpuid is passed through) mesa will even try to use sched_{get,set}affinity to force the opengl thread to be on the same ccd as the main thread :^)

grand shadow
#

@craggy tide #voice-0 message I ran into this exact issue

#

turns out mesa wasnt installing a glx.pc

#

so I just added a case like it does with darwin

craggy tide
#

ah thanks for letting me know

grand shadow
#

I was also confused about it but I decided to dive into the meson.build and discovered that

fleet osprey
# grand shadow i5-10300h

mine is about 1.7x faster - i3-12100f
if you want I can try to run it on there and see how well it compares to some numbers I have with Linux on the same machine from earlier

lean kettle
#

The thing with glxgears is that it's so fast it's not a useful benchmark

#

(at least when running on Linux on a pc made in the last 30 years)

fleet osprey
#

on my Wii running Linux with llvmpipe I don't think it runs all that well

#

like, sub 10fps

grand shadow
#

would be cool

fleet osprey
#

👍 will probably test it over the weekend then

grand shadow
#

but yeah for now 200 fps is good enough ™️

grand shadow
#

I also figured out how I am gonna handle oom on page in

#

sigbus meme

#

its what linux does when the oom killer is disabled it seems

#

and posix also seems to allow it

#

An implementation may generate SIGBUS signals when a reference would cause an error in the mapped object, such as out-of-space condition.

grand shadow
fleet osprey
#

👍

#

If I get a chance I'll try it today

prime juniper
grand shadow
#

I mean it seems fast enough

#

At least it seemed to have increased perfirmance on all things xorg probably because I optimised like the two most used things

grand shadow
#

Well back on track now. Porting mesa took longer than Id have wanted

#

Today after I get home Ill sort the auth stuff out and start adding checks all around the kernel

robust geyser
#

nice work, i wonder if it would scale well with smp

#

unfortunately mouse input kinda broken under wsl so i couldnt test more :(

grand shadow
#

Good to know it was my cpu being bad all along and some of my code meme

#

Llvm pipe does seem to use multiple cores to do rendering if it can so I assume itd get faster

robust geyser
#

i did try smp but i couldn't get past a black screen with the cursor

grand shadow
#

Smp is a bit borked but tbh it couldve just been the tlb shootdown slowing it heavily

gritty shore
#

nice job!

grand shadow
#

I think I might just make a struct to describe a shootdown and have it flush the whole tlb of the other cpu if its larger than a few pages and its applicable

gritty shore
#

why are some x fonts broken tho

grand shadow
#

I might be missing some package

gritty shore
#

DateTime

grand shadow
#

I think its just being cut out

#

These windows are fvwm.being broken (I think it wants epoll)

gritty shore
#

epoll? doubt it

#

that's a linux API

grand shadow
#

I have seen something want epoll in the mlibc logs

robust geyser
#

hell no

obsidian pivot
#

qemu for windows is fine

neon crane
#

qemu for windows is better than qemu for linux on windows wdym?

robust geyser
#

i hate the windows version

neon crane
robust geyser
#

actually gtk frontend looks quite okay now

#

the sdl frontend is missing like everything except the framebuffer lol

fleet osprey
#

not bad

#

at least it works

#

that's not a given with Windows

neon crane
grand shadow
#

first smp bug I fix in like months 🥳

#

one of many