#bentobox
1 messages · Page 3 of 1
true tho i dont swap to disk lol
i don't really know if its the kernel's fault or rust being rust
nobody serious has yet to write a decent kernel where a big selling point was "it's rust"
redox is junk
oh yeah i forgot about that
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
i've been considering doing a rewrite, but rewriting this again sounds like a huge PITA
so i don't know what to do
i made an awful mess of my branches so i've been filtering keyronex code back into a fresh one and doing some refactoring (and i got dragged into some new feature work too) and i've found that a helpful process
so rather than a rewrite, a sort of grand refactoring
maybe
i find it a satisfying process but it is irritating to go from running xorg and sketching the service manager and networking stuff back to putting the basics together again (i have no choice because the branch i took up work in, i stupidly simplified a lot of things vital to portability)
yeah it is
my idea with this rewrite was to not rush userspace again as it will lead to bad design in some stuff (although it was way worse in my older kernel), and i may experiment with stuff like irq priorities etc
in terms of refamiliarising yourself with what you wrote it's certainly great for that
i benefit from that since some things are 2-3 years old and long since out of my mental working set
yeah for me its only a few months but i still manage to forget what some parts of my code do
i wanted to experiment with a new build system (meson), but since i've never used it i will stick to what i know (makefiles), at least for the time being
in the meantime i stopped being lazy and finished my pty work for once
so fvwm3 failing to start when running with smp seems to be a race condition with my polling
since even running single core but with tcg causes the same issue
ah yes
and when i add a shit ton of logging the issue happens with no smp on kvm too...
fuck
and after doing a clean build im getting shit tons of random crashes
great
oh wait this is tcg
wait a minute...
fuck i think i have some horrible race conditions
specifically when i run with smp and tcg
this is like the 39485798345023478508234th polling issue i've had
oh wow it seems like closing windows in dwm works now
i think one of my fixes for something else also made this work
the only issue now is that if i close a terminal, i can't open any more
oh
that's not good
oh no wtf
what did i do
oh shit
i know what's happening
my vfs will refuse to remove a node if it doesn't have a remove op
i could either call vfs_remove_node instead of vfs_remove that doesn't have that check, or add an op
i'll just call vfs_remove_node instead
oh and my unix pipes have the same issue
dwm should be fully usable now
What about maestro (ik this message is old asfk)
holy shit great work
dammit seems like i forgot to push the cmatrix diff on my other machine
eyy not bad
3.7mil ops
ty
bent obos my beloved
yes
so i think that was the last major xorg issue i had
never say last issue and xorg together
lol
real hw
holy shit fvwm loaded on real hw, although it took a while
dude the nes emulator on my laptop is as smooth as on LINUX on my main
its smoother than even in qemu
how tf
very cool
after this I went on a side quest and rewrote my website, looks much better now
tomorrow I'll continue to work on this though, a few things I want to do:
- proper error handling for some of my vfs functions
- AHCI interrupts (will probably do legacy ones for now but I may look into MSI later)
- make uACPI work on my laptop (I have a half-stubbed function that doesn't work on my laptop)
some other things I may want to do:
- write a page cache
- port a better nes emulator
(the issue being my polling race conditions, I finally used my brain for once and fixed it properly)
i think writing a vfs block cache would significantly reduce the time fvwm takes to load
because it loads really fast with a ramdisk
implement page cache
bump
soon™
Implement page cache
implement page cache
soon™
oops i left the vm running for 27 minutes in the background with -smp 12 and nyancat running in fvwm3 but it didn't crash at all, although there seems to be a small memory leak somewhere
also yeah no page cache today
aaand it crashed after 45 minutes when i closed a second st window
definitively a cleaner race condition that could've happened at any time, i need to fix that too
implement page cache
good commit message
Trust the process
soon™
i should stop procastinating this
today i made a struct that holds all memory usage info and a function in the pmm to get it including heap usage
and i also fixed a few memory leaks in my syscalls
but with this fix -smp 12 is finally stable in xorg
Yo bro, i would recommend you to implement implement page cache
Good Morning , im happy to share this moment with my community
this is the progress thread for bentobox, I suggest you start one for your project if you want to share your progress rather than use someone else's.
hey sorry , good luck for bentobox , this first time for me so don't know about this , any way , peace
time to work on this again
so even tho 3 of yall told me to implement a page cache, i'm going to ignore all of you and work on smth else 
fixed a race condition in sched_sleep that made fvwm3 take way longer to start up than normal
i thought i fixed all of my wakeup race conditions, but i forgot to fix it in sched_sleep
I have a banger idea tho
Implement page cache
today i started implementing pci virtio drivers
Yeah isnt it literally just reading a msr instead of a physical address
pretty much, yes
icr registers are gone in favor of a single msr
and apic ids are 32-bit wide instead of 8 bit wide
Shouldve made it 64 bit wide in anticipation of microtubule quantum vibration computing
But I made a board woth 4.0001 million cpus :(
oh lmao
i never read into it so
is XAPIC the regular APIC mode or is it in between regular APIC and X2APIC?
pretty sure xAPIC is different from APIC
its all the same function for me: https://github.com/brainboxdotcc/retro-rocket/blob/master/src/apic.c
i could abstract further, but havent had the need
since i forgot to push my virtio changes to work on them here, i think i'll work on x2APIC support
or maybe i can just watch youtube :P
xAPIC is original mode of the local apic (the mmio based one)
so why are they moving to something inferior in terms of access kind
like
why did they switch to MSRs with the x2APIC
thats genuinely inferior imo
i understand the decision to increase the maximum CPU count
and ICR being a single register is nice
wait, what's ICR?
two 32 bit registers you use to send ipis
ah
ICR being a single 64-bit register I guess
instead of ICR0 and ICR1 being two 32-bit parts for different purposes
i have pushed my virtio code to another branch as i will be taking a short break from that and work on the x2apic (shouldn't take long)
i forgot to enable interrupts on other cores 😭
and now fvwm will deadlock in a spinlock in my scheduler on all cores when its starting up
something's really weird
but i cba debugging it now, i just ret in gdb and un-deadlock it 
i mean, technically i don't really need to hold the tcb's lock in sched_exit
as that mostly exists to avoid race conditions for missed wakeups, but this probably won't miss it
oh waaaait i see the issue
i acquire the lock twice in an irq
ok so ig i'll just release it before calling sched_exit_group in signal_handle, as i don't want to make it take an extra argument to not take the lock
or maybe i could add a check if i'm in an irq but that's more complicated
yeah i'll just release the lock i think it'll be fine
it wasn't the last issue 
so i've started playing aokana and it's 2:30am and i'm still playing it sooooo
very productivity
so i think some libraries i built in my sysroot that xorg requires made gcc break and it's trying to include my system's headers when i build it
so that's annoying
made it so my mmu preallocates the higher 256 pml4 entries on x86-64
i could've made my code sync the higher entries better but this is a lot simpler even if it has a slight memory overhead (1mb)
hopefully should get rid of some of my random crashes
on aarch64 i don't need this as it has two separate pagemap registers
maybe I could blame it all on bit flips...
god i really need to fix this fucking mess
ls ports/
bash.sh doomgeneric.sh font-util.sh grep.sh libpthread-stubs.sh libXext.sh libxkbfile.sh lua.sh st.diff xeyes.sh xorgproto.sh
binutils.sh dwm.sh freetype.sh isl.diff libSM.sh libXfixes.sh libxml2.sh mpfr.diff st.sh xf86-input-keyboard.diff xorg-server.diff
cmatrix.diff expat.sh fvwm3.sh less.sh libX11.sh libXfont2.sh libXmu.sh ncurses.sh ttf-ibm-plex.sh xf86-input-keyboard.sh xorg-server.sh
cmatrix.sh fastfetch.diff gcc.sh libevent.sh libXau.sh libXft.sh libXpm.sh nes_emu.sh twm.sh xf86-input-mouse.diff Xorg.sh
config.sub fastfetch.sh gettext.diff libfontenc.sh libXaw.sh libXi.sh libXrandr.sh nettle.sh vim.sh xf86-input-mouse.sh xorg-util-macros.sh
coreutils.diff figlet.diff gmp.diff libICE.sh libxcb.sh libxkbcommon.diff libXrender.sh nyancat.sh xcb-proto.sh xf86-video-fbdev.diff xtrans.sh
coreutils.sh figlet.sh gnulib.diff libiconv.sh libxcvt.sh libxkbcommon.sh libXt.sh pixman.sh xclock.sh xf86-video-fbdev.sh zlib.sh
doomgeneric.diff fontconfig.sh gnulib.sh libpng.sh libXdmcp.sh libxkbcomp.sh lua.diff src xev.sh xkeyboard-config.sh
ICE
lol
Jinx:

I recommend making a seperate repository and putting each script into a folder that is categorized
for example any xorg tool in x11/
Then just make it link to the category
i guess but the mess rn is the over 1000loc of duplicate code in those shell scripts
i also kinda wanna keep this as a monorepo but we'll see
Get a clanker to rewrite that stuff as jinx recipes for you
github.com/AlDanial/cloc v 2.08 T=0.03 s (3061.0 files/s, 130828.9 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Bourne Shell 68 398 3 1910
diff 17 71 399 852
-------------------------------------------------------------------------------
SUM: 85 469 402 2762
-------------------------------------------------------------------------------
🥀 almost 2000loc of shell script slop
i need to stop slacking off so much
my friends at school like to refer to me as the procastinator pro max
i think they're right
virtio drivers
tho I forgot to push my changes on my other machine so I can't work on it for a day
One of my friends today confirmed it 
ohh
bump
dont do that.
I was gonna work on this and say something but I ended up not
maybe it's refactor time
i want to do a better build system
yk, use jink and alldat
whats a jink
jinx*
i swear i will work on this again soon™
port qemu
port kde
💀
i may start by making a gcc 15 toolchain instead of 16 because surprise surprise it's half fucking broken
actually i don't have the time for that
just pushed my first changes, doesn't build yet but it's close to
i gotta go for a bit and i'll be on my other machine when i come back so that's why i pushed
also as last time i'll keep what's good, except this time i have more stuff that's good lol
i'll keep the scheduler but unlike last time i'll rewrite the vfs
or maybe i could just do a good refactor
yeah i'll do a good refactor instead lol my code actually isn't that shit
things i want to do soon:
- redo my toolchain using gcc 15.2.1 instead of 16 from trunk
rewritemake a clanker rewrite my ports scripts to jinx
then maybe i can make my VFS properly etc etc
does clanker actually know how to do jinx stuff
it can probably figure it out
i can give it the codeberg link and it'll figure it out
or write a driver for Wacom Serial Pen HID Tablet
xorg in this on my tablet pc would be hilarious
well.. for that you need usb
is it
seems like you have neither an [xeuo]hci driver nor a usb stack
well, yeah lol
how do you plug it in
it looks like it's using serial
wait what
oh sorry iread "wacom pen hid tablet"
i glossed over serial
but what the hell?
according to windows its on Intel 82801GBM (ICH7-M) LPC Interface
lmfao what the hell
its a proprietary driver probably
but it says its irq 4

ah
how old is this pc
2008
ohh then maybe its not i2c but literal serial
yeah that's what im thinking
cursed
its a fujitsu st5112
i wonder how it even detects it
no idea
crazy stuff
i'll see what linux says about this
yes
u can check in details
aight so as I expected, no ttyS0 as it's on 0x220
(this screenshot was mostly me wanting to showcase it running on new hardware lol)
new 
i just looked at my clock and saw 3am and i was so fucking confused
turns out its summer time now
wait wtf why am i getting a ttyS0 now
fuck i know why 💀
also the sad thing about this machine is that the ps2 emulation is horrible, if i type faster than like 1 character/sec it will bug out and spam it
yes do xhci
soon™
now
hello everyone, this might be a bit sudden, but due to the complexity of maintaining a legacy codebase in C I'm announcing that I'll be rewriting this to Fortran to allow for a cleaner codebase and less scheduler crashes
I will be also targeting SPARC64 and loongarch64 instead of x86-64 and aarch64 as it allows the scheduler to be more efficient.
Intel however, is looking into hardware accelerating date acceleration with 512-bit timestamps powered by AVX-512. If this technology succeeds, I absolutely see everyone moving to this format.
I will be also moving to the AVX-512 accelerated timestamps for performance reasons.
and since SPARC doesn't have AVX-512 I will be implementing a compatibility layer in software to allow the optimisations to still work.
Hopefully everyone understands these changes in the philosophy bentobox is taking—I'm open to suggestions for improving this even further!
wtf
um i think binary will be better
i feel like writing code in english is so stupid man
lets just use numbers to write them

dead os until i get motivation
so this thing will be on hold until i can get a better setup for trying out the driver, i almost had it there but i had to wait 3 MINUTES every time i tried a change as 1. my flash drive is slow (cheap usb 2.0 hp one), 2. the target pc is old and takes twice the time to read the image from the usb than my main to write it and 3. i have no initrd compression
so, here's a list of things i want to work on from what i can remember, mostly in order:
- redo my toolchain
- move my userspace scripts to jinx
- ???
- initrd compression
- ftruncate
- finish the wacom driver
- page cache (?)
- virtio drivers
- fix the arm port
- logging backend (?)
my current toolchain is fine but it's always been giving me small issues as my dumbass though using the master branch of gcc to make my gcc was a good idea
why not just use PxE boot?
if you have it
i'm lazy to set it up
after fighting jinx for the past few hours, i've decided that instead of trying to use it i think i'll make my own tiny wrapper thingy
and clean up my ports folder a bit
what i was mostly annoyed by with my ports scripts is that 1. there was no dependency handling and 2. there is a SHIT ton of repetitive code
actually nvm
ok so i got jinx working and i'm fininshing setting up gcc and allat, but setting up jinx makes this even more generic (mlibc + unix like + limine os)
:(
ok I almost got bash working today
from now on it should be pretty smooth sailing
i got back to working on it, jinx works!
not sure why i'm getting the missing tcgetwinsize sysdeps now, it didn't use them before
Nice
Hi, are u using what for the writing? Like VGA?
flanterm
It's very convenient
I'll give a look, thx u so much
I love this rofl
FUCK, this exact issue i had with the old bentobox when i compiled vim
seems like some linux-specific stuff is causing this to break on my os? but what could be fucking causing this 😭
maybe so
like maybe some syscalls arent implemented
probably not that
I had the same issue months ago when I was using musl
I guess I'll try disabling the Linux option in mlibc
fastfetch
do you also have slowfetch?
alias slowfetch="neofetch"
neofetch won't run lmao
neofetch is considerably more difficult to run than fastfetch
simply because it is a huge shell script and so it stress tests your shit 
not slow enough 
i got it running in old bentobox but my rewritten kernel probably has some bug making it not work
probably a race condition somewhere
so uh
the keyboard doesn't do anything in xorg for some reason
xorg's not even trying to read from it for some reason
bruh the refcount is zero
because i forgot to increment it on fork
lol i'll drop the refcount i don't even need it
lol it works now
i'm thinking of writing a logging backend
that's not just a ringbuffer and nothing else
cause i found a bug where if i have a low enough loglevel, the first 4 logs will get shown anyway cause when i initialize the framebuffer i just dump the whole ringbuffer onto it
although this could probably be fixed by treating the first logs as all LOG_INFO cause i don't see how i would make it store the loglevels without having some kind of data structure and that would require making a list and i need to dynamically allocate that before i even set up the mmu...
maybe i could get rid of gdt init... ok but ehh
anyway, the new evdev driver should make it so i don't have to suffer writing abs support for my old keyboard and mouse xorg drivers
so i think i could already hook up the wacom driver, the only issue is that i don't have that pc here rn
How do u do this cool screenshots?
kde lets you do that
xclock and xeyes ported again
it may be time this thing gets a logo of some kind
i'm open for ideas
you could do a bento box with different OS/hardware components inside like a terminal or something lol
ik u never saw that one coming
do you see me fitting that in a fastfetch ascii art
A meat pie
trying to run openbox, it starts and the mouse cursor changes to the arrow, but when i try to launch anything or open the menu it will do nothing
i can't even launch apps from the serial tty, openbox is half broken here
and running openbox --debug also doesn't help much:
it may be some race condition somewhere but i have no idea where to start looking
hmmm of course I can't capture it
those x11 backgrounds cause weird moire patterns in my screen in the image
yeah it happens on some screens
why does x11 default to such an ugly pattern
i'm doing X -retro
xorg or oldschool x11r6?
xorg
fontconfig not working has been fixed
i was returning -EINVAL instead of -EOPNOTSUPP
meow
yeah it works just fine without futexes
weird
idk if its a race condition or what but
it looks like it gets stuck waiting in futexes in glib
classic glib
i forgot to mention that i now support zstd compressed modules
Code is generally not very well compressable
I compress filesystem images
...upx called
i meant initrds lol
from ~250mb down to ~66mb
not bad, I just use zlib and I compress my esp partition image from 68mb to 600k
it is mostly nuls
built the new userspace on my other machine
i only ran into 2 small issues:
- freedesktop.org's libevdev mirror has bot protection and it wasn't letting it download on my network, switching to the gitlab mirror fixed it
- st didn't have ttf-ibm-plex as a dependency so it couldn't find the font
i also rewrote the build instructions in the readme
now the logging system thingy can store loglevels
so you can now silence gdt logs at startup
i also implemented truncate & ftruncate
ok i tried porting i3 and it gets stuck in futexes too 😭
ain't no fucking way
ig my futex code was shit after all
this works flawlessly now 😭
fixed a deadlock in the scheduler's balancing
i forgot to acquire the thread's lock 😔
there is something spectacle is doing to my screenshots that makes them blurry for some reason
i use 125% scale in kde cause it looks better but my screenshots specifically when i do it in the screenshot window mode look weird
compared to
and it's been happening for a while
it's been running for almost an hour with scheduling balancing disabled lmao so yeah that was it
my spanish teacher lied to all of us lmao
she said there was an exam today and i went to school for nothing because all the teachers are on strike here
anyway, I still need to look into futexes I believe as openbox sometimes still won't start
i spent all of this afternoon replacing my isp provided router with my mikrotik as my sfp ont finally arrived
the issue was that the firmware on the ont was broken and wouldn't make a connection so i had to try 3 different images until it finally fucking worked and that was a solid 3-4h
after that the mikrotik setup was pretty easy
I've been working on making spinlock usage in my lists consistent as half of my code just didn't use the locks
Tho now the scheduler deadlocks running fastfetch (even on single core lol)
If I sleep before doing anything in the cleaner I can get around it but I'll have to keep investigating
And hopefully this makes my scheduler more stable and not randomly crash from time to time
No work today as I'm at a concert in Valencia
okay the hopefully safer code has been pushed
i think it's time to implement a page cache
my io isn't that slow but it'll help anyway
so uh that's for tomorrow
cause i'm lazy
fvwm3 again
soon™
oops i forgot i broke scheduler balancing (i nuked the old code out of existance)
so this is running all under one core
and quite well actually
its using 75-80% of this one core on my 5600x
its only a tiny bit laggy
i'm quite impressed at how well this is performing
I find it funny how I never renamed the old main branch
That branch is stuck on bentobox 0.2.2 lmfao
things I wanna make work:
- fix pty use after frees
- stability
- page cache
- merge math's mlibc patch into my fork
- more games
- fix the scheduler running everything on the bsp
- revive arm cause it's just dead
I literally haven't updated the arm code since like january
i should also make my mmu safer
okay maybe my scheduler lock fixes paid off after all? it's been running for 3 hours straight without any crashes (i had class and it's still running)
although the instabilities usually are when launching processes so idk
i have noticed that disk performance absolutely tanks when there is a lot of load from xorg from running a dozen xeyes
but it still works just very slowly
ok so the issue is actually just a use after free of struct process?
so i realized that for the past few months i've been shooting myself in the foot as i was stiing in malloc which is called in irq contexts, and especially schedule()...
so that's been fixed
i also fixed some other things here and there
oh yeah i fixed init not reaping shit properly lmao
how come schedule calls malloc
since it does more than it should, it migrates threads to the zombie threads list for the cleaner to clean them and that move between lists allocates and frees memory
why do lists allocate and free memory
because they're dynamic? i need to allocate the nodes
i use generic lists for everything
what happens on oom
instead of keeping next and prev pointers in every structure i use
are you worried about your scheduler's performance
in the form that i'd like it to be better but most of the time i just make it work and don't give it more thought
it could be much better if i wasn't lazy, the optimizations are coming soon™
idk if you care at all but in "real kernel" schedulers they make it a point to never call the heap because it causes layer ordering problems with the memory manager that lead to deadlocks later on and whatnot
its also a performance issue
so they use intrusive list links in the thread structure and whatever
ah makes sense
often they use circularly linked lists bc then its branchless to add and remove an item to it
the only reason i use generic lists is because i couldn't be bothered manually managing it in the scheduler
but i absolutely could make schedule not allocate anything and move what i need to a thread, i just did it this way for now
very nice
augh dammit i wanted to run this on real hardware and it's just crashing starting the scheduler now
it's jumping to NULL somewhere and the backtrace is not useful at all
it doesn't even get to init
ah wait i fixed it
oh okay i fixed it entirely
i just kinda guessed what was wrong
this works flawlessly
openbox works awesome too
Xorg was still running when I woke up
But nyancat and doom were frozen after 5h of runtime
And when I tried minimizing something in the fvwm3 sidebar if deadlocked
I tried getting a pick but discord fucking deleted it
wow compiling with -O0 makes zstd take half a minute to decompress my initrd 💀
at -O2 it takes 4 seconds under tcg
why the fuck
thanks i3
wow init is killing itself
my code is very good™
i spent the whole fucking night trying to make movistar's iptv work on my mikrotik only to realize that the tv in the living room is connected behind a unmanaged fucking switch and that my vlan isolation would've broken the smart tv
so i have to get a fucking managed switch
i hate this house's wiring
how big is your initrd
that sounds.... wrong
by default I build my kernel with -O0 and my rootfs on usb is about 70mb and that doesn't take anywhere near so long to decompress, like fractions of a second
123mib compressed, 423mib uncompressed
maybe meta's zstd decompressor is just terrible at -O0
maybe
what do you have in initrd that it needs to be 423mb
this is 10x the size of windows 95
i think it's so big because i dont strip binaries when building the userspace
plus i do have like 4 wms built, ~90 packages
ah well, its more of a live system than initrd
that explains the size
i don't have an initrd in the traditional sense, i can opt to either make an ext2 hdd image or a "live cd"
I only use an image type system like that when booting from usb
the usb has a gzipped iso that limine loads as a module, decompresses to ram and mounts
else I just read direct from the fs with no need for any initrd style system
yeah same
i've been working on making this crash less for the past few days
it's a bit more stable i think but
not as much as i'd want it to be after working on it for this long
but i guess stuff goes like this sometimes
i also have to fix ptys now
okay okay yeah i think the scheduler fixes made my broken pty cleanup code finally show lmao
actually maybe it isn't? commenting it out did nothing
weeeird
so uh me from like 4 months ago forgot to properly implement pty cleanup if the master is killed instead of exiting cleanly
but its all fixed now
i need to get a wallpaper for this
how did i break this even
oops i broke some shit i shouldn't have touched in the first place
fixed
now we're talking
(yes i did go to openbox and use fvwm-root but fvwm works too)
noooo
it was running so good lmao
except that when i moved my mouse cursor even a little bit half of the dooms would start running at <1fps but i think that's because i removed my old scheduler balancing code
i'll rewrite it soon™ but it was causing issues from what i could see
-smp 16 btw
i think there's also quite a bit of slowdown from tlb shootdowns maybe?
that's for later
too many dooms
so every time i've started up fvwm in this i've always moved my mouse cursor around because when i first ported it iirc there was a race condition or something that made xorg not wake up when fvwm finished loading and all, but moving the mouse cursor aggressively in xorg makes it load waaay slower than if i don't do anything
so i thought that it loaded ultra slow on the ext2 disk but no it takes 12s which is not bad compared to like the >30s it took when i first ported it back in february iirc
on an initrd it takes 4s
but yeah that bug that made me move the cursor so it didn't lock up seems to be gone and i have NO idea when it might've disappeared
i finally fixed the mouse in xorg moving 3px at a time always
i was using an if instead of a while in my ps2 driver.
i'm so disappointed
to be fair, i have no idea how a triple wakeup would happen since the only place i wake it up is in my irq handler and that's only when i finish a packet
fixed shutting down and rebooting deadlocking
nevermind fuck me
i forgot to test in xorg and it deadlocked 😔
ok
fixed
and now the "temporary" cli/sti i had in malloc for like 4 months is gone now (it was only there because i had nasty race conditions back then) and that should help a lot with performance
and it deadlocked starting fvwm3 on 16 cores 💀
oh well i'll actually fix it later
so i fixed 2 deadlocks and one use after free in the process but all the 16 cores are really hammering this single heap
so i'll prolly have to write a per-cpu slab or smth sometime
that's for later
and the compiler seems to be able to compile
holy shit how did i procrastinate this so much
lowk me w anything
i made my kernel use gs for kernel gls instead of whatever i was using before (using cpuid for every this_cpu() call...) and the kernel legit runs so much better now
haven't done a benchmark but
xorg is noticeably smoother smh
i mean this is how every kernel does it but
i was lazy as fuck when i wrote my smp code
oh holy shit this is -O0 too??
oh my god fvwm3 starts instantly now
why would you use cpuid for that
what past me was probably thinking is that i could use the bspid to index into my cpu array to get the current cpu
but that's slow as fuck
no... just use gsbase
that's what i do now
on x86_64 you don't even need to check its presence as it's always there (i'm pretty sure)
this went from taking ~4s today to like under 750ms
46 frames in kdenlive @ 60fps so 766.66ms
make
it's doing shit
so i had to compile nasm as well
and it got so close to finishing
it locked up when it had 3 files left
Gg
i think something was memory leaking for some reason
after a reboot
it has heaps of memory so idk how it memory leaked so hard it crashed
oh wow on tmpfs it actually compiled the kernel
i didn't make it make an iso because i haven't compiled xorriso and that stuff but
hmm and on smp with a livecd it crashes or deadlocks
so i fixed the crashes
i wasn't swapping gs on isr entry
hmm i can't get it to deadlock like before on tcg tho
the system is suffering a lot tho because i only have one heap for the whole system
and the way i have it rn is just a huge bottleneck for everything
ok i finally found the deadlock
nvm i didn't
oh wait i forgot to also fix sched_find_next
well now i'm getting memory corruption so i'll put it back where it was for now...
but yeah all of these deadlocks are probably gonna be solved when i write my own heap
so i can have per-core allocators
yeaaaah so uh right after i pushed the fix it started crashing the same way
so thats great
imma buy a usb3 flash drive tomorrow cause the fastest I have is a 20mb/s 128gb micro SD card from my gopro
I finally realized that new flash drives are actually quick
And that I probably wasted an hour of my time implementing zstd into my kernel
this is so annoying to debug
cause on kvm i can kinda get it to do that quite often if i try hard enough, but on tcg where i can actually hook up gdb i can't
wait
since when can you hook up gdb to kvm
omg
bruh this makes my life so much easier 😭
istfg this wasn't possible a while back
huuh forever?
you just have to use hb and awatch instead of b and watch
damn
i've always used tcg to debug with gdb in qemu before
this is so so useful
there is a downside with kvm tho
you are limited to 10 breakpoints active in total
that's fine
i don't use them that much anyway
printf debugging ftw
nah but this is so useful for catching deadlocks that only happen on kvm for example
also, you running in wsl or linux?
uh arch linux
bc those deadlocks normally mean race conditions
i know
and i found out that wsl is far slower than linux
but
that can be a good thing
some deadlocks will only show up in wsl XD
not on tcg or linux
💀
i test on real hw anyway and on potato core 2 duos at 1.2ghz sometimes
i finally found the deadlock last night and it was... me doing cli/sti in malloc again
yeah so that was a bad idea from the beggining and i had to get rid of it and actually fix what it was masking
and then i had to fix exec not blocking all signals while it execs cause if i get signals delivered mid-exec we're fucked
along with a few other fixes
it seems to compile my kernel reliably now without crashing
lol
i added scrolling to the ps2 driver
it was like 5loc
i also made the pty send sigwinch when the window size changes and that was also 5loc
ok this isn't very stable with -smp 12 :(
ok wtf even with -smp 2 i'm crashing more than i should
ah yes i love it when doom just keeps running even after the system ran out of memory
mhhhh ok i thought that the 5 commits i've done in the past few days have made it more stable
ig not enough
seems like i've got some memory corruption going on in the vfs?
after coming back at this after a few hours with a fresh mind and debugging again, i finally 100% found the cause of the deadlocks and crashes i think
ayyyyy it finished both compiles without crashing
it triple faulted with 4 copies of bentobox compiling at the same time :(
at least my deadlock fix worked tho
bruh
seems like some random bot account
and this is claiming a case that never happens
sched_setup_stack always takes a kernel argv and envp it never takes arguments from userspace and the fix this shit provided is just stupid and wouldn't help anyway
you can do that?
it tried to say my os had a bug and it turned out the value it said could overflow was fed by qemu not the end user
and then I pointed it out, it force pushed irrelevant docs changes to its pr
tried to change auto generated html files
added unit tests when I don't have a unit test framework
it's just dumb af
same here
I reported it as spam
click 3 dots next to the pr
choose block user iirc
you can ban it from your org
yw 🙂 burn it with fire
so apparently the amount of tlb invalidations im sending on -smp 12 is enough to overflow my 64k kernel stacks and triple fault
really weird as it should be enough...
hmm so i left this running on my laptop for 5h and like last time, at around 5h of uptime nyancat and doom froze for some reason
and it isn't even an smp issue since i've been running this with nosmp to see if it would make a difference compared to last time
maybe i have some timer overflow fucking everything up?
Absolutely
(this is meant to be at least 19600s in)
i was curious and discovered all of their footer links redirect to the homepage
so so fake
This kind of shi is why curl closed their bug bounties btw
so the bug i know of rn with smp is that if i'm compiling 4 copies of my kernel on -smp 12, there will be so much irq overhead that one of my 64kb kernel stacks will overflow and make that cpu triple fault and take the whole machine down
but that's not worrying me too much rn
and maybe this
actually, on -smp 12 (since my 5600x i'm using rn has 4 fewer threads) and with 12 dooms open and 6 sts open instead of 9 and 3, it's not crashing at all
i had to use 2 fvwm desktops since i couldn't fit that many of them on my 1080p screen but it's running just fine
and moving the mouse also works just fine (probably because i also made sched_wake wake up idling cpus if the thread i'm trying to wake is on there, but i still don't do balancing)
i had to do that to achieve fast fvwm3 startups
it crashed after a while and while it seems like a weird ass crash, on another core i could see that it tried to panic because it ran out of memory
so i may have a memory leak somewhere...
How
64KB is GIGANTIC
this feels weirdly specific
absolutely no clue
i'll have to debug further but increasing the stack size to 256kb seemed to work
How could "IRQ overhead" possibly be causing that
Do you even have nested interrupts
no i don't that's why i'm confused too
but that's what i assumed it could've been
It's almost certainly not just from an ISR stack frame
Unless you're allocating a like 60KB buffer on the stack somewhere
well yeah and no i don't allocate huge stack buffers
This is probably masking something rather than fixing an overflow
If it is an overflow then you're being really egregious with stack usage somewhere
Like many levels of recursion or something
mmm yeah i should try -d int and see what it says
Keep in mind the Windows kernel probably has 3x as many levels of nesting as you and they get away with an 8K kernel stack
only 8k?
i used to do 16k in my old kernel but i bumped it to 64k when i rewrote it since that's what limine did and it seemed reasonable enough
hm oh well
I'm tired
Not of working on this but because I've stayed up to 5am again trying to get iptv working
Seems like iptv in my house uses dynamic NAT-PAT but if I go to the HGU's advanced settings and go to vlan2 it uses a static ip?
Honestly fuck Movistar
after leaving this idling for ~50 minutes (i had to do shit irl) and trying to run the 4 compilations at the same time it hasn't triple faulted
i can't replicate the triple fault with -smp 2 anymore? wtf
took a small break from this because debugging this shit is tiring
i can probably fix it if i debug enough but i'd rather do something else like
implementing tsc timing would make boot decently faster (~200ms) since my root filesystem is 1gb
well, technically i don't need to for that exact case but it would be better anyway
gdb is not cooperating
or i could try reviving my silly bios bootloader
holy shit the perf has gotten a lot better
great and on my other pc its fucking deadlocking acquiring a spinlock in the vfs
this is with the default qemu flags i use that always work too
what the fuck
Why's there a spinlock in the vfs
my polling code uses it for the waiters list
why can't it be a blocking mutex
because its meant to only acquire it for a short period of time
which is why im confused as to why its leaving it held and making it deadlock
funnily enough in the magazines paper it is stated that disabling interrupts is more expensive than just taking a mutex
and that was 25 years ago, I wouldn't put it behind intel and amd engineers to have made atomics much faster than changing interrupt state
Maybe their mutex isn't optimized
It's cool how with software IPL you don't need to disable or enable interrupts on almost any spinlock
what was it
so my dumb fuck thought it was a good idea to cli/sti in my pmm to avoid the case where my cow handler tries to allocate a page, but whoever is allocating pages rn got preempted and deadlocks
i think i can make it atomic
oh wait no i can't
how did they get preempted if u have a cli
wait you have a point 💀
ok nvm then i didn't find the deadlock
but when i remove cli/sti from my pmm i don't get the deadlock anymore
so maybe its related to that somehow
do u literally cli sti or do u understand the concept of nested cli
i don't nest them in the first place
u cant possibly know that
anything that calls that function from an irq handler already nests that
my cli/sti are macros and if its in an irq context they won't run
easy to check, just add a
void cli()
{
BUG_ON(!(rflags() & IF));
cli();
}
will try
but anyway i only have 13 cli calls in my kernel so i kinda doubt that
you're not counting irq handlers indirectly reaching that code like i mentioned
i said my macros won't run the instruction if it's in an irq context...
i have check for that
show
#define cli() if (this_cpu->current_irq == 0xff) asm ("cli");
#define sti() if (this_cpu->current_irq == 0xff) asm ("sti");
0xff = not in an irq context
well never hurts to check either way
yeah i will
to enforce your invariant

seems like if i just return from acquire in gdb in the deadlocking spinlock it runs just fine?
like it doesn't deadlock again
hmm
maybe the thread that is holding node->waiters_lock is getting blocked by someone else on another thread and not waking up?
cause i don't protect against that
and maybe removing cli/sti just changes the timing enough or something that it doesn't deadlock
so uh
i'll just cli when i acquire the lock
i only acquire it for a very short time anyway
can't think of a better solution that would make my kernel not triple fault at boot
(pls don't make me explain that)
actually, i got away without adding extra cli/sti
seems like i just had to make it so i don't allocate memory while holding that lock that was deadlocking
is it a good approach? no, am i lazy too lazy to fix the pmm instead? yes
Explain that
well, there is a small gap while i'm starting the scheduler where this is just null, and when that happens anything that will try to read it will immediately fault
and why the triple fault and not just a normal exception? im not sure, but i dont think it really matters anyway
since spinlocks are used in quite a few places then i think its just that
i could've made it work but its 2am and yeah
well that's great
i spent a while porting sdl2 just for this to be complaining about audio when i already patched it and deadlocking my system for no reason?? (its not even deadlocking on a spinlock, something weird is happening)
and its supposed to be the "good" emulator
https://github.com/ObaraEmmanuel/NES
ok i can't figure this out 
apparently this thing actually has pen support in the bios setup??
vga text mode touchscreen is truly cursed
welp, i finally finished the wacom driver
i had some small issues in it and all but it works with xorg and it works awesome
sorry for the terrible video lmao my phone wasn't cooperating
Wtf they done make qemu usb-tablet irl
Thats pretty cool
the next step would be to detect if its present using acpi as rn i just try to initialize the serial port and return if it fails
Do u handle it via a special line discipline?
nope, i just register the irq to my own handler and read it that way
i could reuse the one in my serial driver but i just didn't when i implemented the logic for this like 2mo ago
it could be interesting to do it that way tho
technically thats how you're supposed to ™ do it
yea makes sense
tho the linux driver actually does the same thing i do lmao
they just
static irqreturn_t w8001_interrupt(struct serio *serio,
unsigned char data, unsigned int flags)
{
struct w8001 *w8001 = serio_get_drvdata(serio);
struct w8001_coord coord;
unsigned char tmp;
w8001->data[w8001->idx] = data;
switch (w8001->idx++) {
(...)
well hmm but they do use serio_get_drvdata
idk im no expert in linux internals
https://elixir.bootlin.com/linux/v7.1/source/drivers/input/serio/serport.c this is the line discipline driver
config SERIO_SERPORT
tristate "Serial port line discipline"
default y
depends on TTY
help
Say Y here if you plan to use an input device (mouse, joystick,
tablet, 6dof) that communicates over the RS232 serial (COM) port.
More information is available: <file:Documentation/input/input.rst>
If unsure, say Y.
To compile this driver as a module, choose M here: the
module will be called serport.
Is this wacom actually exposed over a com port?
ah i see
It's N_MOUSE apparently
Broke: propriterary shit
Woke: hid over serial 
if it is in sleep mode you have to WOKE it up?
apparently i somehow fixed xclock not ticking?
i thought it needed itimers but i suppose it must've been some kernel bug i fixed recently
(yes they are still stubs in my mlibc fork)
Yeah the video was pretty cool imo
i think i finally managed one of my gs bugs
i had a race condition where there could be a smp shootdown irq while i was restoring the user context in my syscall assembly stub
and i forgot to cli in that stub before restoring the registers 💀
seems like some vmas are corrupting when i run the kernel with -smp 16
im not quite sure why
On the tablet PC
Running at 800x600@60hz since it's the highest this thing will take before not syncing
CDE must go hard on that screen
Only if I had it ported 😔
I should do that
But in the meantime I'll enjoy doom in b&w
I think my code has gotten a bit better
(old bentobox, might have sent this clip a long time ago here already but here it is again)
i am lazy
I want to write a proper IRQ subsystem instead of manually registering to the IDT and IOAPIC as that opens me up to modern devices that use MSI/-X
But uhh it's 4am so I should sleep first
I'm also considering writing an NVMe driver although I'm not sure if I should do vio-blk first or not
And obviously having XHCI would be nice but I know I'll be too lazy to implement it in a long time
But I'll probably bring Bach aarch64 before that
Ah yes Johann Sebastian Bach
I did no work yesterday 
I only debugged a bit why bash bails out when I SIGINT it and I think it's because I'm missing syscall interruption
holy shit my signals are COMPLETELY broken
what's happening:
- bash runs a syscall
- get preempted
- signal code saves the USER context instead of the kernel context
- userspace signal handler runs
- sigreturn restores the old USER context instead of the old KERNEL context
- suddenly ppoll gets cut off mid-execution and bash is confused as fuck as to what happened
- bash bails out and exits
and i didn't catch this when writing my signal code 6 months ago since my test code would work fine as it wouldn't really check the output of the syscall
yay i have to write more assembly...
(i don't mind it)
U know it's not supposed to restore kernel context ever right
yeaaa but what do i do instead
cause if i don't do that i'll memory leak if a syscall allocates memory (they do)
Signals cause the syscall to abort
If it's in a wait you wake the wait with a status indicating to the caller of the wait function (your syscall impl) that a signal interrupted it
You see this status and clean up and exit from the syscall
oh yeah i see now 😭
Then the signal is dispatched upon return to usermode
yay i fixed everything
1000th commit pushed
just implemented it hackily
some nice screenshots i'll upload to the readme
now realizing these wallpapers are all rights reserved... oops
i'll have to come find my own and make a new package
why do absolutely none of my machines have good ps2 emulation
my tablet pc's ps2 emulation is very funky and a lot of the times keys get stuck and its infurriating to type on
and if i type specific stuff it works
on my sempron le-1250 machine it doesn't emulate a ps2 mouse (i tried different keyboards, no luck)
and on everything else i have it claims it has emul but it doesn't
just
do
xhci
yeaaa but im lazy
Port riscv64 instead trust
I mean the architecture is a lot simpler and easier than aarch or x86 and requires less to be fully implemented
yeaaaa but you forgot that i already ported aarch64 over 6 months ago
it just bitrotted
and i also want proper irq shit on x86 so i can have irq allocation and msi easily etc etc
also my aarch64 specific code is like 1000loc and will get smaller 
time to try to bring back aarch64
this is gonna be fun
i also found out that if i use LTO and -O3 in my kernel i get 5.4M uacpi ops/s instead of 3.7M
so idk what to do with the benchmark score in the uacpi readme
man where do i even start with this
i guess building an aarch64 bare toolchain
and now its where i regret making the kernel source outside the jinx bootstrap folder cause now i can't use the same toolchain to build the userspace as the one to build the kernel
since the one in it builds weirdly iirc
or not
oh i can reuse it cool
i thought the paths would be all messed up but apparently not
ok this is what i feared
xrc2 ~ src bentobox bootstrap build-aarch64 jinx host-pkgs/binutils/usr/local/bin/aarch64-pc-bentobox-as
host-pkgs/binutils/usr/local/bin/aarch64-pc-bentobox-as: error while loading shared libraries: libopcodes-2.46.0.20260210.so: cannot open shared object file: No such file or directory
xrc2 ~ src bentobox bootstrap build-aarch64 jinx
tf is libopcodes
library for opcodes 
also it looks like you need to add your prefix lib dir to library dirs with env
like force glibc to use your prefix libdir
no clue
i think i found the issue
xrc2 ~ src bentobox bootstrap build-aarch64 jinx cd host-pkgs/binutils/usr/local/
aarch64-pc-bentobox/ bin/ include/ lib/ share/ x86_64-pc-linux-gnu/
xrc2 ~ src bentobox bootstrap build-aarch64 jinx cd host-pkgs/binutils/usr/local/
xrc2 ~ src … binutils usr local jinx find . -name libopcodes*
./x86_64-pc-linux-gnu/aarch64-pc-bentobox/lib/libopcodes.so
./x86_64-pc-linux-gnu/aarch64-pc-bentobox/lib/libopcodes.a
./x86_64-pc-linux-gnu/aarch64-pc-bentobox/lib/libopcodes-2.46.0.20260210.so
xrc2 ~ src … binutils usr local jinx
yup both libs are in there
imagine using powerline in prompt smh \j
nothing wrong with it
yeah i was joking xD
heres mine btw, it also shows errs but i forgot to scrot
heres that
i have PS1=: lol
the rest is a PROMPT_CMD
PROMPT_CMD(){
local exit_stat=$?
local user="\x1b[48;2;58;58;58m $USER \x1b[0m"
local os="\x1b[48;2;78;78;78m $HOSTNAME \x1b[0m"
local file="\x1b[48;2;38;38;38m $PWD \x1b[0m"
local err="\x1b[0m"
(($exit_stat != 0)) &&\
err="\x1b[48;2;255;175;95m\x1b[38;2;28;28;28m $exit_stat \x1b[0m"
local chr=""
chr="\x1b[48;2;58;58;58m${debian_chroot:+($debian_chroot)}\x1b[0m"
local all="$user$os$file$err$chr\x1b[0m"
printf "$all\n"
}
that is LONG



