<zijjgfs>
right now my OS factory employs 200 illegal mexicans making OSes just the same way I did, but it's still not efficient enough, i'm thinking of replacing them w/ H1-B indians. they work somewhat harder and you know how they <3 tech
<EChelownED>
how does the OS operate Mutabah
<zijjgfs>
maybe in a couple years when AGI improves i can replace them with AI
<EChelownED>
like is it a spin off of linux or what is it
<zijjgfs>
and then i can use AI to prompt AI to make OSes even faster
<rayan>
i will try qemu replay
<Mutabah>
zijjgfs: Chill out dude
<zijjgfs>
then i will DOMINATE the OS market and rule the world... muahahahaha
<rayan>
the limine bootloader just dies
<zijjgfs>
Mutabah: U prolly havent even made one single OS yet u joker
<rayan>
when trying replay
<Mutabah>
EChelownED: My previous one? It was nearly all custom code, just implemented a unix-like syscall interface - so porting most software was not too hard
<rayan>
so thats a no go
<zijjgfs>
I can pump them out a dozen at a time like hotcakes.
<bslsk05>
github.com: NyauxKC/kernel/src/sched/sched.c at master · rayanmargham/NyauxKC · GitHub
<rayan>
you will find the stubs in isrstubs.asm
<rayan>
check gdte.asm for the context switching
<EChelownED>
why do you all make your own OS
<Mutabah>
EChelownED: Fun :)
<zijjgfs>
because some guy on reddit told me i couldnt do it. so i showed him!!!
<Mutabah>
rayan: What line did you change to break things? That may have clues
<rayan>
i just made a switch queue function
<zijjgfs>
there's no way you're going to be able to tell with his commit messages
<Mutabah>
Looking at gdte.asm (strange place for task switching code, shouldn't be related to gdt), it has hard-coded structure offsets
<zijjgfs>
> ttttryueru
<Mutabah>
with minimal comments
<rayan>
yes i verified the offsets to be correct
<rayan>
i think there may be UB going on
<zijjgfs>
rayan you should learn about the pause instruction
<rayan>
yea i know what a pause instruction is
<rayan>
it is for the spinlock wait loop
<rayan>
it hints to the processor to avoid memory order violations
<zijjgfs>
there are other effects
<rayan>
even then, that shouldnt effect the scheduler
<zijjgfs>
i was looking at your second to last commit
<kof673>
> some kind of libOS there was an oskit and other things but unmaintained, ancient, etc.
<rayan>
i dont know whats going on to be fair
<kof673>
that was somewhat the idea, let you get linux/bsd/whatever drivers "for free" and focus on whatever your real goal is
<zijjgfs>
rayan why are you making an os then wth
<rayan>
i had also verified everything on real hw
<zijjgfs>
so why don't you bisect the breaking commit
<rayan>
zijjgfs bro
<zijjgfs>
kof i was obviously being facetious
<rayan>
there is literarly no reason
<kof673>
i sensed that, just saying :D
<rayan>
a few locs can change how context switching works
<kof673>
various projects did want "universal drivers" but not sure they ever get anywhere...
<rayan>
i just changed the way i did my queue logic end of story
<zijjgfs>
ndis?
<zijjgfs>
lol
<zijjgfs>
rayan then you know how solve the problem, why are you on irc
<rayan>
bro, the queuing logic is not the problem
<Mutabah>
rayan: Maybe your queue logic is wrong enough that it's corrupted the queue? And is now attempting to run a dead task?
<rayan>
i check for NULL objects
<rayan>
all memory is memsetted too
<rayan>
Mutabah it shouldnt be happening like that to be fair
<Mutabah>
rayan: The context switch code checks out... although, it would be better to pass `&old->kernel_stack_ptr` instead of `old` to it - so the assembly doesn't need to know offsets
<Mutabah>
also, have that function handle changing CR3 - allows you to have kernel stacks in different address spaces
<rayan>
it does
<rayan>
its ur job to worry about that
<rayan>
as a kernel
frytaped has joined #osdev
frytaped has quit [Remote host closed the connection]
<rayan>
anyways Mutabah
<rayan>
this is very weird
frytaped has joined #osdev
<Mutabah>
My suggestion would be to print out the thread pointers, to check that they are consistent
<zijjgfs>
rayan you shouldve used Python. then you could've just done 'import sched' and then bam
<rayan>
zijjgfs please stop attempting to insult me
<zijjgfs>
im just trying to help jeez
<rayan>
thats not help
<Mutabah>
Oh, and that copy-pasted code you have for pushing/popping those registers?
<rayan>
yea what about that
<Mutabah>
Those are the callee-save registers in the ABI.
<zijjgfs>
in fact u have libos built into python, could just do 'import os' gg no re kthx
<Mutabah>
zijjgfs: Please stop.
<zijjgfs>
okay
<rayan>
Mutabah what about them
<Mutabah>
If you don't have anything productive to say, don't say anything
<zijjgfs>
i thought we all act like clowns in clown world
<Mutabah>
rayan: You have a comment implying that you don't know, thought I'd tell you why
<bslsk05>
github.com: rust_os/Kernel/Core/arch/amd64/start.asm at master · thepowersgang/rust_os · GitHub
<rayan>
oh yes that makes sense
<zijjgfs>
I just don't get why rayan can't figure this out on his own. like i said, could diagnose it by bisecting commits, using version control kinda what it was made for
<rayan>
Mutabah that makes sense for the ABI yea
<rayan>
zijjgfs already did
<Mutabah>
zijjgfs: have you seen the size of the commit that probably broke things?
<zijjgfs>
nope
<zijjgfs>
well i guess there's a lesson
<Mutabah>
rayan: Maybe also see if you can figure out why limine breaks with record+replay? That slightly surprises me (maybe it's a bug that is fixed in a newer qemu, if you have an older one currently)
<rayan>
i cant change qemu versions
<rayan>
sadlyh
<rayan>
im using wsl
<Mutabah>
compile it manually?
<rayan>
would be too much time
<rayan>
considering my CPU
<Mutabah>
Iirc, it's a 30min-1hr compile on an ultrabook CPU
<rayan>
no i mean
<rayan>
my cpu is really really REALLY old
<rayan>
either way, maybe you can try to compile it
<rayan>
its quite simple, just run the make command
<rayan>
all deps should be gotten for you
<Mutabah>
I'm not going to debug this entirely for you
<rayan>
that was not what i was suggesting but okay
<rayan>
anyways Mutabah i will print the thread pointers
<rayan>
old thread 0xffff800000006018, new thread 0xffff800000006018old thread 0xffff800000006018, new thread 0xffff800000006018
<rayan>
all looks consisent Mutabah
<rayan>
it is happening at context switch
<rayan>
i verified that with gdb
<rayan>
the ret is taking me to the schedd
<Mutabah>
would there be any race if you switch to yourself?
<rayan>
no as all cpus have their own queue
<rayan>
and touch only THEIR queue
<rayan>
the ret in the do_savekstackandloadkstack should take me to return_from_kernel_in_new_thread
<rayan>
meaning the stack is probs getting corrupted somehow
<Mutabah>
Oh, is this a newly created thread?
<rayan>
yes
<Mutabah>
let's look for that code too then
<rayan>
check main.c
<rayan>
check sched.c for create_kentry
<Mutabah>
Hmmm.... so, there is a requirement that the stack be aligned to 16 bytes at a `call` instruction iirc
<rayan>
it is though
<Mutabah>
I don't think that holds with that newly created stack
<rayan>
how do i make it 16 byte aligned then?
<Mutabah>
`StackFrame` is 22 words, there's one for the ret address, then 6 saved registers
<Mutabah>
Maybe that's causing corruption inside the `change_rsp0` function - check its disassembly
<rayan>
22 dwords*
<rayan>
and hold on
<clever>
rayan: whatever creates the initial stack, needs to decrement the stack by enough to make it aligned, which can be done with just an AND operation, clear those lower bits!
<Mutabah>
add a dummy push to the start of `do_savekstackandloadkstack` ?
<clever>
and anything that decrements the stack to make room for vars, needs to decrement it a bit extra
<Mutabah>
By "words" I meant 64-bit native machine words, not 16-bit intel "words"
<clever>
and of course, undo that when returning
<rayan>
how much dummy pushes will i add
<rayan>
just one Mutabah?
<clever>
22 x 64bit, is 176 bytes, or 11*16 bytes
<Mutabah>
Just one, to make the push count odd (which, with the pushed RA in `call` would align the stack to an even qword count)
<clever>
so 22 x 64bit, is already a multiple of 16 bytes
<rayan>
okay
<rayan>
hold on
<Mutabah>
clever: 6 pushed registers plus the one RA leads to an unaligned stack at the `call change_rsp0` instruction
<clever>
the key, is that 16 bytes, is 2 x 64bit, so if the number of 64bit words is even, its already a multiple of 16
<clever>
Mutabah: ah, that wouldnt be 22 words long then, but something else, and if all of those are 64bit, thats 7, which isnt even
<rayan>
that causes a fault
<rayan>
0xe
<rayan>
unpresent page
<rayan>
idt stub 54
<rayan>
yea um
<rayan>
yea thats what occurs i suppose
<rayan>
nvm, put the push in the wrong place
<rayan>
still
<rayan>
thread doesnt execute still :(
<rayan>
Mutabah and clever
Dead_Bush_Sanpai has quit [Ping timeout: 244 seconds]
<EChelownED>
what are some other good servers
<EChelownED>
this chat so far good one
<EChelownED>
or channels
hwpplayer1 has joined #osdev
<Mutabah>
rayan: Single-step and see where the bad value comes from?
<Mutabah>
(oh hey, qemu build is complete)
<rayan>
its stuck in send_eoi???
<rayan>
it iretqs to send eoi
<rayan>
all the time
<rayan>
wtf
<rayan>
ye athis is very weird
<rayan>
what the hell why is it iretqing to send eoi ? Mutabah
<Mutabah>
Not sure, when I see "EOI" I assuming it's sending the EOI message to the interrupt controller (which is an `out` instruction, not `iretq`)
<rayan>
yes
<rayan>
but iretq is returning to send eoi function
<rayan>
which makes ZERO sense
<rayan>
and its iretqing in the isr stub, not in the return from kernel in new thread
rayan has quit [Quit: Leaving]
<Mutabah>
single-step, and check the state and value of RSP.
frytaped has quit [Quit: WeeChat 4.4.2]
frytaped has joined #osdev
frytaped has quit [Max SendQ exceeded]
frytaped has joined #osdev
frytaped has quit [Max SendQ exceeded]
frytaped has joined #osdev
frytaped has quit [Max SendQ exceeded]
frytaped has joined #osdev
frytaped has quit [Max SendQ exceeded]
frytaped has joined #osdev
frytaped has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
EChelownED has quit [Remote host closed the connection]
karenw has joined #osdev
frytaped has joined #osdev
frytaped has quit [Max SendQ exceeded]
frytaped has joined #osdev
GeDaMo has joined #osdev
goliath has joined #osdev
housemate has joined #osdev
hwpplayer1 has quit [Quit: I'll be back later]
goliath has quit [Quit: SIGSEGV]
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
jedesa has joined #osdev
x64S has quit [Quit: Leaving]
msv has quit [Ping timeout: 260 seconds]
msv has joined #osdev
Left_Turn has joined #osdev
xal has quit [Quit: No Ping reply in 180 seconds.]
xal has joined #osdev
<cloudowind>
happy new year people , Un used the term first time ive seen "climate breakdown " for 2025.. lets see how happy its going to be
hwpplayer1 has joined #osdev
\Test_User has quit [Quit: \Test_User]
\Test_User has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
edr has joined #osdev
mavhq has quit [Read error: Connection reset by peer]
mavhq has joined #osdev
mavhq has quit [Read error: Connection reset by peer]