#Astral
1 messages · Page 5 of 1
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
Damn
I reaaaally need to rework this ps/2 code
Its almost just straight copied from old astral
Probably would work, I dont depend on a keyboard always being present
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
Wonder what Ill have first
A working usb + hid driver or a ps/2 driver that almost always works lmaooooooo
I wonder if SeshOS PS/2 works on my chromebook
I swear I had a PS2 mouse somewhere... Where did I put it....
Well this is incredibly helpful…
Of course discord didn’t send the image despite me adding the image to the message
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 ^^^
was anything at all changed with PCI init? if not I probably won't bother, I gtg soon
I only changed something in msi which likely doesnt matter so not rly
Ty for testing
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
pitch issue?
¯_(ツ)_/¯
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
pro move
Well good to see that at least it boots
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
is there a way to compile just the kernel?
Yeah the kernel-src subdir is compilable on its own
Seems like my compiler has PIC enabled by default or something?
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
aaaaa I forgot that it downloads stuff
independently compilable my ass, I needed to download flanterm and check it out in kernel-src
why not embed it as a submodule?
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
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 🥺
wtf
tried -nostdlib but now it complains about printf.h missing
damn
maybe you should try your build system on multiple machines
not trying to insult or anything but i think it needs a refactor
well guess what, jinx doesn't work for me either
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
whjat was missing
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
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
tho yeah, I do agree the build system is a bit hacked together at places
lol someone did not copy all the template flags
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
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
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
nice
this is whats making it die
wtf?
I don't know hwo to read bash very well but like its there?
maybe the grep script is swallowing the exit status?
why does it pick egrep over grep -E?
Ill check when Im home
well
that probably explains some things lol
seems like grep wants splice
I'll just comment it out I cannot bother
what does your /usr/bin/egrep actually contain?
its a script printing that message into stderr and calling grep -E
i assume it execs grep? if so then that should actually pass the error code correctly
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
strange that egrep apparently works though?
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
what
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
oh
oh no
do I have a fucking leak
yeahhh
shit
At least you bubble it up
We just die

I think I should focus on self hosting after my vacation
Just buy more ram or we assert your ass

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
Visual lsan
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 :)
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
nice!
time to try it again
configuring gcc, think it passed where it was before
nice
time for the real test
bruh?
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
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 
YIPPE
alright hope this works now
fixincludes now
I'll leave this running now
still going strong
nice
nice nice nice
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
tbh, I've seen Linux PCs that compile slower than that
honestly quite impressive that you've already gotten Astral that fast
its kinda slow now that its at the bulk of the gcc stuff
a few seconds per file rn
idk, that's still pretty good
I have a machine that takes several hours to compile 50% of xmrig, then fails
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 
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
compiling GCC is an insane torture test
AssertOS!
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)
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
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
@grand shadow im kinda bored so uhhh... do u want acpi support in your kernel?
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
is it that bad?
My coding style might be a bit weird but its muuuuch better tham old astral
also since u have ported a bunch of software can't we just make a shutdown syscall and make it call that?
Sync and fsync
whats weird about it? i see u use tabs but other than that
u dont separate words in some places ig
Mostly this
any rules to when u dont separate to keep it consistent?
I do the module_function thing and add an arch_ in front when its arch dependant (like arch_mmu_getphysical)
i see
For structs I always typedef with a _t so page_t for example
And macros usually are LIKE_THIS
fair enough
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
Nope, completely unsupported
would it live in tools?
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
Thank mint for jinx lmao
Actually wait I just thought of something which could be an issue
@analog berry does uacpi unmap memory directly?
i am thinking that it has to do with you setting queuewaiting[idx] from one core, and the DPC happens on another
This was running on a single core
wdym by directly
ah what the fuck
Like it maps some physical memory and then unmaps it later
compiler reordering?
yeah
maybe you need to do volatile with blkdev, like notify = 0 is set before queuewaiting
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
sure but i dont think im even going to actually map anything, astral does use hhdm anyway right
I only map usable and bootloader pages in the hhdm
And module pages too
ohh ok
Not acpi
Lemme check
well aml accesses reserved ranges, not acpi ranges
so anyways
but sure ill just not unmap for now
Its not mmio but I could try so, maybe its compiler optimisation fucking me over
When slacking off at work today I will see if I can read through the virtio block code again
yeah, only thing i can think of is if queuewaiting[idx] is reordered after the volatile
is that even legal in c?
i mean i doubt its anything that complex
if its single core its probably just a logic bug
Yeah
lemme know when the unmap bug is fixed
Wont be for another 10 hours, its 8 am rn
np lol im not that fast
Oh lmao
would a submodule be ok then?
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
ohh i see
Yeah it takes a bit, it has to compile gcc twice etc
Such a frustration, I really hope to figure out how to not do that some day
Congratulations
at least its less than the 3 gccs you build during a native build
native non-cross-target that is
you what mate?
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
this tortured me when i was trying to re-port modren gcc to hp-ux on hppa
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
lmfao
Oh shit I did not know
I will pass that flag when building it on astral lmao
yeah
Probably just saved me hours of waiting
Oh yeah gcc uses Perl during its build step. That’s gonna be annoying
How difficult is it to port?
if dennis says annoying, I'd take that as not so easy
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
if you don't ./bootstrap it's probably not needed?
thats what I assume since it was building fine up until that point
and I think it built libiberty too
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
I have no idea wtf is causing this, the lastusedindex and VIO_QUEUE_DEV_INDEX are correct
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
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....
@flat copper since you tried to help earlier, I think this is what is happening, with some other things that lead to it being that there was a thread waiting on buffer index = 1 (which only happens when 2 different threads want to access the device at the same time) and the device ring entry was poiting to buffer 0 (which is the one usually used)
time to do the vmm fix for uacpi and then leave it building gcc again so I have an excuse to play factorio
Why does no one use LLVM / Clang? Is it too complicated? It basically does cross anything no need to compile 100 toolchains, just one for the host you want to use it on.
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
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
its still going, maybe this time is the one
Finally lonked cc1
NOO
Welp that was today's attempt
Tmr Ill try again and see what couldve caused this
Thanks
rip
can managarm compile gcc?
probably no, we still struggle with configure scripts of smaller projects
which part specifically?
i mean see last messages in managarm-dev in the managarm server :^)
Yeah saw it
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 
gcc building again, this time I wont be stupid enough to forget to sync hopefully
Left it building while visiting family, hopefully it doesnt explode
idk, would you be able to add a cronjob or something simple like a shell script that runs sync every half hour or so?
The worker thread already does that every once in a while
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
wtf
o h
what was it trying to do there
oop finally got to the cc1 linking
this is gonna take a while now
cc1 linked, soon I will know if this will work
died compiling parser.cc again
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
that sounds strange
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;
could be heap corruption of some sort
the only place rbtree is used in mlibc is indirectly via the slab allocator
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
the oberrow curse has reached even the likes of astral
alas; it has gotten too powerful
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
I really hope debugging this wont involve me having to dig deep into mlibc source code or worse gcc
(it probably will)
Either way I will only be able to work on this friday, tomorrow Im going out with my coworkers after work
succ
disk synced, e2fsck returns no issues
Bruh it gotta link cc1 again
Ill leave it doing that
I can probably speed it up a bit by having multiple writer threads as well as optimising my disk and fs stuff which sucks atm
That will be after I get/give up on getting gcc to compile though
sound
fix the PS/2 code 
mail me one a machine that has issues 
I can't mail you my entire NAS lmao
17" x 7" x 14"
and weighs a ton
it's a big chonky workstation
use tor 
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
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
alas, the oberrow curse seems to be upon you
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
ok
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
yippie!!! :DDD
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?
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
mlibc's allocator doesn't unmap memory unless it's was large allocation (larger than largest slab)
so far from what I've gathered:
something causes that region to get unmapped (I should get a stack trace or something, but that would mean waiting another hour because I seemingly cant reproduce it without doing so which wtf)
the application calls malloc()
and the rbtree functions try to access that memory on /sysroot/usr/share/mlibc-build/frigg/include/frg/rbtree.hpp:330
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
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
I still don't 100% know if its mlibc related, but once I know whats calling that last munmap I'll open an issue
I should open that ppoll issue though
is that what VirtualAllocator::unmap does? it seems munmap is being called from there
yeah
map is used to allocate both memory for slabs and large objects, but only the latter ever get unmapped
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
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
that is true
cc @prime juniper
time to sit my ass down and read some of the intel hda spec
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
if only I didn't fucking segfault every fucking time I want to chroot into it
qemu hda doesnt support msix, I think its time I finally stop being lazy and implement normal msi
why's it segfaulting?
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
wtf
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
strace it
or take a look at dmesg
dmesg is empty
strace a chroot call, I guess that could work
strace was a good call @robust geyser
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
why though
why not unmap slabs when theyre empty
because reusing it for later allocations means theyre done faster?
but what if you run into situations where you're low on memory?
so, why isn't the playstation 2 code working? /j
page out the heap to swap 
we probably could do something like madvise(MADV_DONTNEED) if the whole page is no longer used
does managarm have that
we don't have swap no
you should consider adding some kind of signal or something broadcast to every running process that says "hey, running low on memory, free whatever you don't need"
Well, if something's not needed, it should be freed anyway, but you're probably talking about caches and such?
qookie is talking about not freeing slabs immediately
I assume to avoid a useless syscall
what kind of swapping does it have
It swaps into a ram buffer for now
yeah it's probably likely that the memory will just be reused soon enough by subsequent allocations anyway
Ive opened an issue on mlibc about the allocator issue
Thanks for the report
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
also I might have to port diffutils to make this faster
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
||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
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?
@wild marsh do you have any guesses about what could be happening here so I can try to debug this when I get home later?
not really honestly
h(grand)->color seems to be color_type::red
ugh I am too dumb to understand this shit
in frg/rbtree.hpp there's an enable_checking constant that you could set to true to have the rbtree code perform checks at various point (during and after operations)
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());```
does it happen earlier than the slab crash?
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
lemme see what the rbtree checks say when FRG_SLAB_TRACK_REGIONS is disabled
still just segfaults
when a page fault happens on an anon range it maps a page that was zero'd at boot and then on a write fault it does CoW with that page so I'm pretty certain it does return memory thats zero'd out. I could try to check if that page is still all zeros on gdb but I'd assume it is
yeah, x/4096c (((uint8_t *)zeropage) + 0xffff800000000000) shows everything as 0
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
wait until u do clustered page-in
a lot of issues in a lot of software that I've looked at follow that same pattern
> x is supposed to be done in y way
> currently is doing it in z way because "not enough time", "too lazy", etc
> changes it to be y
> massive measurable improvement
I swear I've seen this pattern crop up elsewhere like, 10 times already
but regardless, nice job, glad you found it and made it better :)
are these changes to the nvme driver?
seems like yeah
im going to change my kernel to use an MDL to perform io operations instead of a bare buffer
both to the nvme and virtio block drivers yeah
currently implementing named fifos, so I can try out the make jobserver and something else I'm curious about
took me a while to figure out what a j observer is
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
not really, I dont even have automake or autoconf ported
Yeah
I wget it directly from the gnu mirror
The tarball that is right?
yeah
Yeah same
(From the host into the sysroot but that shouldn’t make a difference)
I do it directly from astral 
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
i mean it probably would be a good idea
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
it would amount to maybe removing --delete to the rsync command we use for the /root folder
Probably
based
good work sir
tyty
all that for a hello world? /s
jokes aside, good job, hopefully you can get to compile gcc on astral very soon 🤞
speaking of compile gcc, @prime juniper did you ever manage to get mlibc linux to work
Not yet. I get further on configure but flex is segfaulting
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
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
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
what does _less(*successor(node), *succ) return?
/sysroot/usr/share/mlibc-build/frigg/include/frg/rbtree.hpp:627:99: error: ‘_less’ was not declared in this scope
627 | mlibc::infoLogger() << "_less(*successor(node), *succ): " << _less(*successor(node), *succ) << frg::endlog;
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
how'd the gcc build go?
Had an assert fail but I know whats going on
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
also I should port xscreensaver for the silly
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
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
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
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
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
nice :3
thats one more motivation to add multiuser support, screensavers
Nice work
did you teach vfs about permissions yet? :^)
I still need to see how I am going to do that
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
It really really really wants /proc/self/maps in the Linux code paths
But; here’s a good tip. Get LLVM and Mesa with LLVMPIPE up and running
You’ll thank me later
(It also wants some netlink BS in those code paths)
cant you use the not linux code paths though
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)
or writing your own port
for that matter you could try writing your own complete webkit port
Yep, that can be done too
I wonder which would be harder, own port or pretending to be someone else
yeah thats the first thing I'm gonna do today
the fact that the first thing is namd wtf is comforting
probably the former, especially if you don't have a lot of linuxy things
Webkit Template Framework (or, if I’m debugging it, which I did, What in The actual Fuck is it doing this time!?)
Yes, likely
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
I wonder why the hell is gcc not building libstdc++-v3 with -fPIC
no idea what happened there but adding a patch I found in the gcc mailing list it was fixed lmao
llvm takes so long to compile they should've written it in c instead of c++ smh
Understandable
llvm+clang with all targets enabled takes 10 minutes on my machine :p
cries in slow
My poor thing started swapping like crazy at the end of it and I had to turn down the job count lmao
llvm for me used to take 5+ hours to compile....
I honestly wonder how bad that would be if I tried it on my iBook G3, if it takes fairly good PCs hours.......
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
TO(not)DO: Compile LLVM
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)
now do I want to finish the mesa port today
is it supposed to take this much space :(
did you forget to -DCMAKE_BUILD_TYPE=Release?
oh
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
most of it is still in libLLVM
llvm-exegesis is 1.2g
is that nescessary
according to the website its a benchmark tool
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
wtf
(don't mind the ctime)
maybe its cuz I dont strip the executables?
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
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
lol, it happens
wonder how different the build time is gonna be now
hopefully not too long
if it does I should just go to sleep I am exhausted
either way, a friend of mine is playing around with it and did some stuff
Went down to 200mb, much better
Tmr Ill port mesa
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
get accelerated 3D graphics 
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
ooh
/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
yeah
time to see if I can fix this in zlib
something something build-support/checksoname.sh and also backporting changes from vinix
Yep
awh sick
The good thing about having someone actually play around with your os is that they end up finding bugs you likely wouldnt
wish I could relate
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
Whoops
easy fix probs
pretty neat
Big
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
that saddens me as vinix dies with >1
but i think it's a scheduler issue of some sort
do you have any guesses about what could be happening?
Btw is the rbtree bug still unsolved?
nah, i haven't looked into it
you should go back to working on vinix more, its cool to see your progress there
i am waiting to be paid
yeah I have no idea where to even begin (I am severely lacking on some CS fundamentals)
Sadge
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)
Thats fair enough
Are you going to get paid?
hopefully you get paid soon!
Nice
but yeah i am happy to see all the astral progress
honestly my favourite project here
ty :3
astral is very impressive, agreed
Yeah it makes porting stuff seem trivial
although i am obligated to say that managarm is my favourite project 
even I am surprised at how well it runs
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
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
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
Aren't we all
true
I do look forward to the day I build gcc with make -jwhatever in astral and it compiles with several cores perfectly stable
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
Maybe I should try adding CPU migration to the Managarm scheduler again
I just juggle threads around cpus with no care at all
we dont juggle threads at all
when a process is created the CPU that thor puts it on is the one it stays on
the two ends of the spectrum 
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
i wonder how cancer it would be to implement some sort of cpu performance counter monitoring
ig you could just measure how much it spends on the idle thread per second or something
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)
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
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
damn it starts but uh its kinda broken
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
not impossible that whatever tyr-quake does is faster for tyr-quake specifically ig
llvmpipe has to be able to do everything after all
so you definitely have got some optimizing to do
also that yeah
managarm gets quite a bit more than that iirc
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
inline them
holy balls
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
yknow what that's damn playable
it may not be fast for running quake on a modern pc
but it's still playable
which is still impressive
it does 1400 for me
ok yeah i misremembered terribly
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
on x86 at least
Please do
am working on lil atm
specifically getting geminilake working again
Also highly based
Maybe after lil then
That perf improvement would be big I can imagine
with how many cores is this
i don't think it matters but it's like 4
quake is decently playable now
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
that's downright smooth
wtf
in llvmpipe?
I can't even get that much perf through llvmpipe on Linux
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 
i5-10300h
searching glxgears in the discord I found something funny
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 :^)
@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
ah thanks for letting me know
I was also confused about it but I decided to dive into the meson.build and discovered that
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
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)
on my Wii running Linux with llvmpipe I don't think it runs all that well
like, sub 10fps
I'll probably update the image on avalios.dev tomorrow after I fix up some more ports and fix a bug or two that my friend told me about
would be cool
👍 will probably test it over the weekend then
but yeah for now 200 fps is good enough ™️
I also figured out how I am gonna handle oom on page in
sigbus 
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.
@fleet osprey its on the server with mesa now
it's faster than managarm that's for sure
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
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
nice work, i wonder if it would scale well with smp
unfortunately mouse input kinda broken under wsl so i couldnt test more :(
Damn your cpu seems much better with mine
Good to know it was my cpu being bad all along and some of my code 
Llvm pipe does seem to use multiple cores to do rendering if it can so I assume itd get faster
i did try smp but i couldn't get past a black screen with the cursor
Smp is a bit borked but tbh it couldve just been the tlb shootdown slowing it heavily
nice job!
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
why are some x fonts broken tho
I think its just being cut out
These windows are fvwm.being broken (I think it wants epoll)
I have seen something want epoll in the mlibc logs
Use qemu for windows ffs
hell no
qemu for windows is fine
huh
qemu for windows is better than qemu for linux on windows wdym?
i hate the windows version
perhaps all you dislike is the gtk ripoff, if so, try -display sdl
actually gtk frontend looks quite okay now
the sdl frontend is missing like everything except the framebuffer lol
i like the sdl backend actually because it's using native windows
an excuse for me to implement sysconf soon
first smp bug I fix in like months 🥳
one of many