and before return, it calls CoreS_ExitIRQHandler
#OBOS (not vibecoded)
devout niche
which `cli`s
this pair should ensure no nonsense then
are you using an intterupt or trapt gate?
flint idol
trap gate probably
devout niche
obviously i can't spell tonight
flint idol
hopefully
devout niche
trap gates ars broken
flint idol
I'm 90% sure that my IDT code has been around the same since my 2nd kernel
chilly osprey
trap gate is the worse one isnt it
chilly osprey
well not worse, but interrupt is usually what you want
chilly osprey
then we find out its a call gate
devout niche
trap gate is the worse one isnt it
the trap gates leave interrupts enabled, nightmare
chilly osprey
the trap gates leave interrupts enabled, nightmare
yeah i dont know why anyone wants that
maybe for int 0x80 for syscalls or something
flint idol
the osdev wiki page on the IDT says trap gates should be used for cpu exceptions
flint idol
I messed up my comment
I said it uses a trap gate, but it actually is an interrupt gate
Do exceptions ignore the DPL field of the IDT entry
devout niche
Do exceptions ignore the DPL field of the IDT entry
as far as i know the DPL is only for interrupts generated with int instruction
flint idol
well I searched it
chilly osprey
as far as i know the DPL is only for interrupts generated with `int` instruction
i believe this is correct also
flint idol
Interrupts generated by issuing of the int instruction called soft interrupts. So here, the processor takes DPL field into account only when it handle soft interrupts, a completely ignore them in the case of interrupts generated by processor itself or by external devices.
chilly osprey
it wouldnt really make sense to restrict exceptions to kernel mode only
or hardware interrupts for that matter
devout niche
needlses to say hardware interrupts have to interrupt no matter who's running, but it wouldn't be acceptable to force the kernel to give it a DPL allowing any user app to fake a hardware interrupt
chilly osprey
what actually is the issue currently?
flint idol
it was goofy IRQL being caused by gs_base being cleared by swapgs
chilly osprey
right
flint idol
anyway I believe I fixed that issue
chilly osprey
well done
flint idol
first part of the IRQ dispatcher
works
now I need to test the other part
the part that handles shared IRQs
oops
forgot to send an eoi
[ DEBUG ] Arch_KernelMainBootstrap: Initializing IRQ interface.
[ DEBUG ] Moving IRQ Object 0xffffff0000002460 from vector 0 to vector 1.
[ DEBUG ] Moving IRQ Object 0xffffff0000002460 from vector 1 to vector 2.
[ DEBUG ] Received IRQ 0 (irq object 0xffffff0000001880)!
[ DEBUG ] Received IRQ 1 (irq object 0xffffff0000001cf0)!
[ DEBUG ] Received IRQ 0 (irq object 0xffffff0000002160)!
[ DEBUG ] Received IRQ 2 (irq object 0xffffff0000002460)!```Everything works as it should
it seems
nothing goofy happened to the IRQL
the IRQ dispatcher works
I'll commit and push this code
then I'll probably add some helpers
then I can make the scheduler preemptive and watch as the kernel goes to shit
real pecan
Nice
flint idol
I just pushed a function to free an IRQ object
I think that's it for the IRQ interface
The only other helper functions I can think of for the IRQ interface are some that set some callbacks in the irq object, but that's pretty useless, as one can just do obj->handler = handler;
flint idol
then I can make the scheduler preemptive and watch as the kernel goes to shit
time for this
Let's see for how long the kernel stays stable
flint idol
Let's see for how long the kernel stays stable
To test this, I've initialized an IRQ object and put the LAPIC timer on it
the handler simply yields and returns
lmao
it triple faults immediately
cr3 gets set to the page map initialized by hyper
and not my kernel's
the scheduler switches to the idle thread
specifically the one on the bsp
which was initialized before the new page table was made
of course cr3 in its context was never modified when the new page table was made
so on switch to the idle thread, since the page containing the old page table was freed (and likely has some new garbage values), the kernel triple faults
I forgot to restore the thread irql on context switch
whoops
except I do
I only restore CR8, but not the value in the cpu_local struct
flint idol
of course cr3 in its context was never modified when the new page table was made
same thing with gs_base
I get a page fault on execution of nullptr after I set gs_base to the correct value in the idle thread 
flint idol
I get a page fault on execution of nullptr after I set `gs_base` to the correct ...
It's a bug with my thread context saving code it seems
I fixed it
Now the scheduler is switching from the bsp idle thread to the kernel main thread
and is doing pretty much nothing else
Which is fine for now
I need to actually calibrate the LAPIC timer properly
and get the other CPUs to start a timer
flint idol
Well I did that
and found out my spin lock is broken
irql Core_SpinlockAcquireExplicit(spinlock* const lock, irql minIrql)
{
if (!lock)
return IRQL_INVALID;
if (minIrql & 0xf0)
return IRQL_INVALID;
const bool expected = false;
irql newIrql = Core_GetIrql() < minIrql ? Core_RaiseIrql(minIrql) : IRQL_INVALID;
while (atomic_compare_exchange_strong(lock, &expected, true))
spinlock_hint();
return newIrql;
}```the logging functions are locked and yet:
[[[[ DDDDEEEEBBBBUUUUGGGG ]]]] IIIInnnniiiitttitiaiailaliailzlzieeidzzdee ddtt iittmmiieemmreer r rf f ofofrroo rrCC PPCCPPUUUU 3120.
.
.
.```using an atomic flag fixed the problem
I've also copied the functions from the previous kernel that calibrate the LAPIC timer
then to make it so it initializes the timer for all CPUs, I just added some code to the scheduler IRQ handler that tests if the LAPIC timer has been initialized or not, and if it hasn't, the timer is initialized.
Then to trigger that, the kernel sends a global IPI with the IRQ vector which will initialize the timer IRQ on all CPUs
Bruh
It's time for the VMM now
Before that
I'm going to test the scheduler
I'll just create 16 threads
all doing some random shit
and see what the scheduler does
flint idol
and see what the scheduler does
maybe I'll make them test the allocator
flint idol
ASAN Violation at ffffffff800025e0 while trying to write 1 bytes from 0xffffff00000901e6 (Hint: Pointer is in shadow space).
While testing the allocator multi-threading
flint idol
anyway, this doesn't happen while testing the allocator single-threaded
so it's probably a problem with the allocator not locking stuff at the right time
I think I have a race condition in my IRQL functions
pretty much this:
*Core_GetIRQLVar() = to;
CoreS_SetIRQL(to);```That's a problem because, say the IRQL is at PASSIVE level, and it's raised to say DISPATCH level, there is a slight chance that, between the set of the irql in cr8 (the call to CoreS_SetIRQL) and the set of the IRQL in the cpu structs (*Core_GetIRQLVar()), an IRQ can happen. In that case, if an IRQ happens, the kernel will likely panic with IRQL on call of the dispatcher is less than the IRQL of the vector reported by the architecture (\"Core_GetIrql() < OBOS_IRQ_VECTOR_ID_TO_IRQL(frame->vector)\")
anyway back to the ASAN violation
after locking the allocator for the entire duration of the Allocate function, it still happens
flint idol
I got a use-after-free in the scheduler
flint idol
I think my kernel is cursed again
everything's gone to shit with multiple threads
what if
I just slap a big ol' scheduler lock
it deadlocks
real pecan
lol
flint idol
ok how tf does it deadlock:
beginning of scheduler: lock
end of scheduler: unlock
There are no return statements in between
ashen goblet
Are you maybe switching to another task between the lock/unlock
flint idol
oh wait
it might not be a deadlock
it seems as if a part of the scheduler could be taking
a very
very
very
long time
ashen goblet
How did you manage to do that
flint idol
`continue;`
note how this doesn't include the node = node->next
wait why tf is there a non-ready thread in one of the scheduler's priority lists
flint idol
wait why tf is there a non-ready thread in one of the scheduler's priority lists
because the remove node function seemed to fail
not fail with a status code
just like not work
if (node->next)
node->next->prev = node->prev;
if (node->prev)
node->prev->next = node->next;
if (list->head == node)
list->head = node->next;
if (list->tail == node)
list->tail = node->prev;
list->nNodes--;```I need to look at this very hard
and see if anything's wrong
ashen goblet
Look normal
real pecan
```c
if (node->next)
node->next->prev = node->prev;
if (node->prev)
node...
what if it only has next but not prev
then tail would be null
real pecan
is this a circular list?
flint idol
no
real pecan
then the node that's tail can never have next
devout niche
this is why i use time-tested <sys/queue.h>
flint idol
the top two if statements handle that
flint idol
the thread is blocked, has the flags set to dead, and yet the node is still in the priority list
devout niche
if the list manipulation routines are fine, and there is no double-insertion or similar, suspect concurrency problems or some kind of memory corruption
real pecan
^
flint idol
I want to make a debug check
the list remove function doesn't check for a node existing in a list
so something can provide a node which isn't actually in the list it says it is
flint idol
Of course as soon as I add the debug check the bug stops happening
ok now it happened
oh wait
the bug is the wrong cpu local structure is being used
basically every thread has a masterCPU struct
real pecan
how do u even manage to fuck this up
flint idol
this thread's struct was set to the bootstrap one
for the BSP
it was the kernel main thread
I also happen to fuck one of the priority lists
if (list->tail)
list->tail->next = node;
if(!list->head)
list->head = node;
node->prev = list->tail;
list->tail = node;
list->nNodes++;```now lemme look at this really hard and see if there's anything wrong
doesn't seem like it
Currently I'm chasing down at least two bugs:
- Whatever tf this is
- UBSan violation because of a thread node being corrupted
real pecan
```c
if (list->tail)
list->tail->next = node;
if(!list->head)
list->head...
looks fine
flint idol
I'm getting a UBSan violation within KASAN
how fun
wtf is wrong with the stack trace
my kernel is completely cursed
real pecan
rewrite 6 incoming
flint idol
how tf is ubsan_abort being called by asan_verify
my brain hurts
UBSan Violation unaligned access in file C:/Code/obos/src/oboskrnl/scheduler/schedule.c at line 98:19
this stack trace is completely fucked up
if I trace starting at the panic
rbp looks fine
except going one level down makes everything not make sense
maybe I should rewrite my scheduler to not be 💩
just saw these two comments in the work stealing function:
// NOTE: There could be some race conditions with this.
// TODO: Fix.```My scheduler deadlocks often
for reasons
unknown to me
devout niche
My scheduler deadlocks often
how does it lock?
flint idol
spin lock
devout niche
and in what fashion? is there but one lock? when is it acquired and released?
flint idol
there is a scheduler lock for each cpu
that gets locked whenever a thread priority list or thread is getting modified within it
or on entry of the scheduler
so, for example, if a thread is being blocked, the cpu that owns it would get its scheduler lock locked
or in the work stealing function, when the scheduler decides to steal some threads from a CPU, it locks the scheduler for that CPU
maybe my spin lock had a bug
I was using memory_order_release on unlock
devout niche
when does the lock get released?
devout niche
I was using `memory_order_release` on unlock
release is generally what one would want
flint idol
for the scheduler, it releases it before switching to the new thread context
devout niche
it should ensure that previous writes are done
flint idol
for the work stealing function, it releases it before return (note, there are no returns between the lock and unlock)
devout niche
for the scheduler, it releases it before switching to the new thread context
can that be a problem?
your old thread appears to be ready for rescheduling, but in fact you're still on its stack
flint idol
hmm true
which means, there could be a race condition where the scheduler is still being run on the old stack, and then another cpu switches to the thread
devout niche
i have an interim solution for this problem in keyronex by releasing the scheduler lock only once we're in the context of the new thread
flint idol
I think I could just switch to the CPU's temp stack when calling the scheduler
whoopsie daisy
; TODO: Make thread-safe
In the function that's supposed to switch to a temp stack.
ok now I made it thread safe
flint idol
I
am a fucking idiot
there was a very stupid bug in the work stealing function
It tried to steal work from the same CPU
it used the list parameter passed to it
to steal work from
flint idol
it used the `list` parameter passed to it
but that parameter contained the list of the current cpu
which was why the scheduler was deadlocking
it was removing a thread from the priority list
then adding it back to the same priority list
after fixing that bug
all threads are started
and exit successfully
now time to add back the allocator test
now the allocator rather deadlocks or is super slow multithreaded
Time to compile with optimizations, and probably watch as all goes to shit once again
flint idol
Time to compile with optimizations, and probably watch as all goes to shit once ...
After fixing a dumb bug (ret instead of retfq when the GDT is flushed, causing the stack to be incorrect on return because optimizations emitted the frame pointer), it works
flint idol
I have a deadlock in the allocator
I fixed it
it was in Free
Because I'm trying to do as much as I can to avoid writing the VMM I'm bored and it might help, I might write a kernel debugger
Actually no
I don't feel like making a makeshift ps/2 keyboard driver again
flint idol
I added a message to the kernel for when it starts
it says the build time, commit sha, and commit date/time
[ LOG ] Booting OBOS c59108167b885b8e9d74c18ed0ca302c81747092 committed on Sun May 19 20:33:59 2024. Build time: May 19 2024 20:34:11.
I've downloaded a paper on the working set model
and hopefully soon I can get started on the VMM!
empty kernel
`[ LOG ] Booting OBOS c59108167b885b8e9d74c18ed0ca302c81747092 committed on Sun ...
how do you store that info in your kernel?
ornate ginkgo
how do you store that info in your kernel?
You can generate a source file while compiling, and have that info are variables.
flint idol
Ok before I get to the fancy parts of the VMM, I need some sort of way to represent contexts
and like virtual addresses
and stuff
you know to store info about virtual addresses
devout niche
Denning's working set paper is quite interesting
make sure to pair it with the VMS papers to get an idea of how to operationalise it effectively
devout niche
what for?
devout niche
associating structures describing the shape of the address space?
flint idol
associating structures describing the shape of the address space?
yeah
I don't remember why
devout niche
I don't remember why
they are good for looking up sparse but ordered information
flint idol
I'm implemented "processes" in the kernel
Right now they're just a pid+a thread list
but soon it will contain info for the VMM
and info for handlers
and stuff
flint idol
I'm looking at some of the code for my 3rd kernel
and I'm thinking
this DEFINITELY wouldn't work on a lot of hardware
because of some of the assumptions it makes
flint idol
this DEFINITELY wouldn't work on a lot of hardware
at least not work as intended
The dependency mangement is horrendus for the third kernel
running the third kernel
it kind of seems cursed as well
flint idol
I think I've got a vague understanding of how the working set works
So I'm going to try implementing it
To "page out" memory, I'll just reserve a chunk of RAM and write the paged out chunk there
I guess it will be like a reverse free list
an allocated list
actually nvm that wouldn't work
I'll find that part out later
flint idol
actually nvm that wouldn't work
oh wait it could
real pecan
is obos actually stable rn
flint idol
Let's see
It doesn't triple fault randomly
The scheduler doesn't randomly deadlock (I think)
The allocator works multi-threaded
flint idol
(which means the basic memory allocator works multi-threaded as well)
ashen goblet
(For now)
flint idol
The IRQL is stable
IRQs are preemptible by IRQs with a higher IRQL than them
Spinlocks work
real pecan
The allocator works multi-threaded
welll... lets wait until uacpi demolishes it 
flint idol
It's the same as the last kernel
ashen goblet
Does kasan work too?
flint idol
indeed
flint idol
and it was tested hard
it's run thousands of passes with large allocation sizes without failing
only getting slower
for obvious reasons
ashen goblet
What allocator did you use again
flint idol
type?
idk
Just some allocator I made for the previous kernel
Probably free list
along with an allocated list
is atomic_bool guaranteed to be a struct type?
cppreference says struct atomic_flag;
so I'd assume so
real pecan
why does it matter
flint idol
my spinlock is a typedef of atomic_flag
but because it is, I need to include stdatomic
and intellisense doesn't like stdatomic.h because it thinks my C version is C99
so I want to know if I can typedef it to typedef struct atomic_flag spinlock
instead of including stdatomic.h and messing up my intellisense
haughty abyss
instead of including `stdatomic.h` and messing up my intellisense
solution
dont use msc/c++
use clangd
flint idol
vs
visual studio
not vscode
maybe it's time to ditch vs once and for all
not for notepad++ this time
that was a bad time
empty kernel
visual studio
Why?????
empty kernel
Fair point, the vs debugger is fairly decent. Idk how it would work for osdev though.
haughty abyss
clearly it doesnt lmao
haughty abyss
I like the debugger interface
gdb ftw
try getting chrome to support debugging x86 code :^)
flint idol
Fair point, the vs debugger is fairly decent. Idk how it would work for osdev th...
It can utilize GDB
I have a custom launch.vs.json
which specifies some commands to start and setup gdb
and some stuff to make it actually, y'know, work
I also have a launch.json for vscode
these two scripts I made a long time ago (around a year ago by now)
bruh clangd doesn't seem to have CMake support
how do I get compile_commands.json to work
clangd will look in the parent directories of the files you edit looking for it, and also in subdirectories named build/
it says that
so I made directory, make cmake output in build/ (CMake does actually output that file)
but it still no work
ashen goblet
visual studio
i couldn’t get myself do get that working with osdev
flint idol
oh wait it was because the build files were being put under build/x86_64-debug
haughty abyss
use chrome
flint idol
But how
devout niche
i don't know anything about DDD
i just use GDB
it's inefficient and tedious being a CLI (it has a text UI but i tried that and it was murder) but i don't know of any competent open source gui debuggers
flint idol
Well DDD is a data display debugger based on gdb
chilly osprey
i always find the gui ones to either lack information or not work half the time
devout niche
they were fantastic a long time ago but GDB has gotten better and i'm attuned to it now
some people like LLDB but it's greek to me
chilly osprey
yeah gdb is basically second nature to me
devout niche
i think once upon a time i was using Code::Blocks' debugger which is a frontend to GDB and that was alright, but that was before i got into GDB itself
chilly osprey
visual studio's debugger is okay but i find it doesnt like when i try to evaluate a more complex expression
where as gdb always works with that kind of thing
devout niche
i would quite like to write a kernel debugger, i think that would be fun, but supporting even 10% of what you can do with GDB would be prohibitive
chilly osprey
i think the hard parts are evaluating expressions and things
haughty abyss
i would quite like to write a kernel debugger, i think that would be fun, but su...
you can implement 90% of what you actually use without that much effort
break/step (in/out/over)/print/backtrace/examine/continue
devout niche
you can implement 90% of what you actually use without that much effort
i haven't looked at DAWRF yet
flint idol
break/step (in/out/over)/print/backtrace/examine/continue
I did that
haughty abyss
break/step (in/out/over)/print/backtrace/examine/continue
idk what you actually use apart from that
step backwards?
but thats just pain
devout niche
i will really be wanting to be able to identify locals, to name one thing
devout niche
it might be dead easy, i don't know
haughty abyss
yeah no idea either
i think there's some bytecode involved too
which you interpret until you are about to step after the current pc or something
devout niche
i know that dwarf is basically bytecode and you interpret it up to a given point - and then, i assume, you can get dawrf to tell you what register/stack location some local is in?
haughty abyss
i think its something like
devout niche
which you interpret until you are about to step after the current pc or somethin...
yes, that's my understanding too
haughty abyss
"X is now in Y"
and then you make a simulated system starting in some initial state like
"rdi = caller rdi, rsi = caller rsi" etc
devout niche
i would not necessarily be opposed to utilising a DAWRF parser
haughty abyss
and instructions are like, "rdi is now in rax"
or whatever
or "this variable is now here"
haughty abyss
i would not necessarily be opposed to utilising a DAWRF parser
not sure if there's that much to parse, tbh
devout niche
or perhaps GCC can still generate traditional STABS?
haughty abyss
i dont think stabs would work super well
oh maybe
seems like nasm can produce STABS
devout niche
MINOCA has a decent kernel debugger, i think they use elves, let me have a quick look if they also use dwarves
chilly osprey
i haven't looked at DAWRF yet
its a bit weird
devout niche
i also think that bloody what's his name invented a kernel debugger that might have used dwarves
i can't remember who he's called
bootboot author
chilly osprey
especially the way they do line to address mappings
devout niche
bzt
haughty abyss
oh cool i think i found some docs on stabs
devout niche
no, bzt's thing is just a standard trivial debugger
haughty abyss
no, bzt's thing is just a standard trivial debugger
is it?
oh, no dwarf
at that point just embed a gdbstub (x86) or copy BED (arm)
devout niche
the MINOCA debugger appears to be more sophisticated and has DWARF stuff
devout niche
just a bit time-consuming
in terms of computation or in terms of figuring out how to do it?
haughty abyss
anyway would be cool to have
but also, i have other much better things to do
like tcping
devout niche
it will be very useful for me to have on the amiga
haughty abyss
no gdb?
chilly osprey
^
haughty abyss
it will be very useful for me to have on the amiga
do you not have a serial port?
devout niche
i don't think my amiga's serial port works
devout niche
the amiga's monitor port is db-23 and the serial is db-25
and i got a cheap adapter for db-23 to commodore 1084s-d2 monitor's rgb port
that cheap adapter was just a db-25 that someone took a hacksaw to
and unthinkingly i plugged it into the serial port instead of the rgb port
devout niche
and there was much smoke and problems
haughty abyss
unfortunate
devout niche
i haven't tested the serial port since, maybe it still works
but the original amiga 2000 PSU, that was toast
chilly osprey
i haven't tested the serial port since, maybe it still works
only one way to find out
devout niche
thank fuck it didn't destroy the 68060 card
flint idol
It'd be funny if the next rewrite of obos is in french
devout niche
It'd be funny if the next rewrite of obos is in french
you're not french are you?
flint idol
I'm not
fluid crown
It'd be funny if the next rewrite of obos is in french
it's not really a programming language
chilly osprey
yet
flint idol
@real pecan is it normal for hyper to just not provide a frame buffer to my kernel when I asked it to
It mainly happens on uefi systems
Like test subject 1 and 2
Which makes debugging "slightly" harder
It works for bios emulation on test subject 1
#2 fails with cannot find a video mode for the constraint 1024x768x32bpp
On bios
#1 with bios does give a framebuffer
Which works fine
Limine worked btw
Based off my old kernels
But anyway, I've added yet another statement at boot for some basic cpuid things
Like the cpu vendor, brand string, and whether the kernel is being run on a hypervisor or not
Just a screenshot of it running on real hardware
The lapic ids are pretty weird but whatever
ornate ginkgo
nice
might be disabled cores, or you have hyperthreading disabled in the firmware?
flint idol
No hyper threading on this cpu
ornate ginkgo
or you're reading them wrong 
flint idol
I mean the cpus get started using said lapic id
So I think it's just a firmware quirk
vale nymph
my desktop also had that
empty kernel
The lapic ids are pretty weird but whatever
that looks like the LAPIC ids are shifted left by a bit
real pecan
<@353593948523986945> is it normal for hyper to just not provide a frame buffer ...
What fails specifically, is there like no framebuffer at all or different res?
I think it might be a bit annoying and not let you set a forced resolution above native, and often times there's no edid, maybe its that problem
If you have time we can debug later
flint idol
If you have time we can debug later
Yeah sure, but maybe in a couple days though, as I'm busy the next two days
flint idol
What fails specifically, is there like no framebuffer at all or different res?
There is no framebuffer at all
BTW the constraint is set to auto iirc
real pecan
i had a hyper build that just printed out all available video modes somewhere
hmm
i can make a new one if u can test rn
#560042023638269955 message
flint idol
If anyone's wondering why this project has had no vmm development on it for a week or two by now, it's for two reasons:
- School
- Arm injury while playing football*
*or soccer in north american english
Until my arm heals, I can't really code anything, because with one hand, I only type 20 wpm
which is slow af
oh wait y'all are osdevs, I need to explain what football is /j
vernal chasm
Until my arm heals, I can't really code anything, because with one hand, I only ...
Sounds like a skill issue :>
Anyways what doesn't kill you makes you stronger, so once your arm is fully healed it'll go speeeeeed
flint idol
What fails specifically, is there like no framebuffer at all or different res?
Test subject 1 booting from the hyper binary that prints the modes prints three modes
I'll see test subject 2
The reserved bit mask is 0000
Red is ff0000
Green is ff00
Blue is 00ff
For all modes on test subject 2
#1 is the same, except reserved is something else
flint idol
Test subject 1 boots normally without a framebuffer
#2 fails saying no constraint found
@real pecan
flint idol
BTW this is #2
real pecan
#2 fails saying no constraint found
what's the constraint?
flint idol
it wasset to auto
but it reported it couldn't find 1024x768x32
iirc
#1141057599584878645 message
wait that was for bios
real pecan
and you didn't set 1024x768 yourself?
flint idol
nvm, test subject 2 doesn't seem to provide a framebuffer in uefi
it boots successfully, but no fb
real pecan
how do u know it even booted then
flint idol
I'll add a test to make it triple fault if there is no fb
flint idol
maybe it's a bug with my drawing code
real pecan
yes, I think so
real pecan
the failed constraint one is this?
real pecan
so bios?
real pecan
oh ok, ill make a similar dumper for bios tomrrow and we'll take a look
flint idol
Ok
flint idol
Well on UEFI, it's a bug with my drawing code
real pecan
yeah try to fix that ig
once that fixed the only bug is failed constraint on one pc?
in bios mode
flint idol
Yes
flint idol
well it could partially be because of the fact that my fb retrieval code was in an #if OBOS_RELEASE statement
flint idol
oops
real pecan
ok i made it hang after dumping the video modes
try this
@flint idol ping me once u test it
flint idol
@real pecan
Nothing shows up lol
With that test image
Rather crappy bios (unlikely; iirc limine worked), or bad vbe code
real pecan
lol
ok well since you're not seeing any warnings
its line 326 that's failing probably
let me add a few more prints
@flint idol can u try this one pls
flint idol
ok
sharp pike
Limine better???
real pecan
i helped u fix a bug before 
sharp pike
wdym check?
sharp pike
confusion
real pecan
this is from limine
real pecan
confusion
on oberrows bios something about the video mode struct is different im tryin to figure out what
sharp pike
does Limine work there? if so, just check for diffs between Hyper and Limine's VBE code
real pecan
yeah i think so
flint idol
iirc yes
real pecan
anyway lets see what this prints out
real pecan
does Limine work there? if so, just check for diffs between Hyper and Limine's V...
looks fairly similar
something subtle probably
real pecan
static inline u16 fb_format_from_mask_shifts_8888(u8 r_shift, u8 g_shift, u8 b_shift, u8 x_shift, u8 bpp)
{
if (bpp == 24) {
if (b_shift == 0 && g_shift == 8 && r_shift == 16)
return FB_FORMAT_RGB888;
if (r_shift == 0 && g_shift == 8 && b_shift == 16)
return FB_FORMAT_BGR888;
} else if (bpp == 32) {
if (x_shift == 0 && b_shift == 8 && g_shift == 16 && r_shift == 24)
return FB_FORMAT_RGBX8888;
if (b_shift == 0 && g_shift == 8 && r_shift == 16 && x_shift == 24)
return FB_FORMAT_XRGB8888;
}
return FB_FORMAT_INVALID;
}
this is why it fails probably
@sharp pike do u just not check reserved or?
u literally dont huh
technically wrong but whatever
ill add the quirk workaround for oberrow
sharp pike
which fields?
real pecan
uint8_t lin_rsvd_mask_size;
uint8_t lin_rsvd_mask_shift;
what would you want me to do with those fields?
real pecan
it's a component of a pixel, therefore it must have valid offset & size to detect the type of the format
but idk how limine works exactly, maybe it doesnt care about the format
real pecan
so what if it was like shift=23 size = 2, that's a completely bogus format
you would just modeset that
sharp pike
yeah
sharp pike
BIOSes aren't a perfect science
it's not a C++ compiler
the only way it would matter is if rsvd overlapped r g or b
flint idol
Maybe the bug with my drawing code is really because hyper provides fb format invalid
Idk if that's allowed though
real pecan
can u try this pls
real pecan
I'll just add a check
yeah ofc
flint idol
Ok
real pecan
who knows
real pecan
yeah
flint idol
I'll just generate an obos image then
real pecan
pls do
flint idol
instead of the test image I made
real pecan
if it works ill give u one without info logs so it boots as fast
until i make a proper release
real pecan
the only way it would matter is if rsvd overlapped r g or b
which fucking firmware dev just thought whatever lets not bother setting anything for the x component
flint idol
"AMD ATOMBIOS" did
real pecan
more like RETARBIOS
flint idol
Well at least the reboot code works
real pecan
let's continue debuggin tomorrow, gtg soon
real pecan
Well at least the reboot code works
lol
flint idol
K
real pecan
ill give u one more image tho
oh nvm, might be a quick fix
i still faill if x_size != 8
@flint idol can u test real quick, it doesnt hang so u can use normally
flint idol
Ok
real pecan
thx
flint idol
Same error
real pecan
that was quick
flint idol
I added some code to memset the framebuffer to white when boot finishes
Rather boot hangs, or the framebuffer is broken
Because I never see my white screen
I'll add it to the beginning of boot
real pecan
ill add prints so we can check what framebuffer it tries to set tomorrow, but i doubt its a bug in hyper
i have one last binary for u tho
real pecan
ok good that would've been fucked
flint idol
I think my very early boot code hangs somewhere
Because the framebuffer isn't white
It's basically just some cpuid and rdseed/rdrand to get the random stack check value
flint idol
sure
real pecan
It's basically just some cpuid and rdseed/rdrand to get the random stack check v...
maybe the cpu doesnt support it?
flint idol
well yeah that's why it does cpuid first
to check
it does it for both instructions, and falls back to a default value otherwise
just to check that it's not hanging in there, I'm making it triple fault before jumping to the kernel
flint idol
Same error
real pecan
wdym
flint idol
From hyper
real pecan
that just prints out a list and hangs
is there a chance u didnt install the previous ones as well
real pecan
Well it hangs in early init it seems
your kernel?
flint idol
indeed
real pecan
i see
flint idol
I redownloaded the hyper install binary
And used it on the iso
And it still gives the error
real pecan
but how
flint idol
Maybe you gave the wrong hyper install binary
real pecan
hmm
real pecan
Maybe you gave the wrong hyper install binary
i have like one
flint idol
testing on qemu, it just boots normally
flint idol
oh wait
I'm using it on the normal obos image
maybe that has something to do with it
real pecan
oh maybe ur booting as iso
flint idol
that indeed seemed to be the problem
real pecan
damn
real pecan
should work
real pecan
okay uhh
flint idol
I can see the constraint
real pecan
is there a chance u just didnt flash it last time?
flint idol
Maybe I was getting the error because of the image being booted as iso
real pecan
or maybe the bios booted it as a cd
flint idol
The constraint error
flint idol
exec format error
flint idol
weird
real pecan
exec format error for what?
flint idol
hyper_iso_boot
real pecan
why are u executing it
real pecan
u pass it to xorriso right
flint idol
I'll fix the bug on uefi where it hangs in early boot later
real pecan
did u verify it actually hangs in your kernel?
flint idol
Well I'd assume it does
real pecan
how old is this pc?
flint idol
I'll make it triple fault first thing on boot
real pecan
I have a laptop from 2010 with this bug in UEFI
it might be the bootloader hanging in that case
or rather, the firmware
flint idol
it's a 2013 computer
flint idol
or rather, the firmware
That'd be funny
real pecan
try triple faulting and see if that works
but it might be an infinite page fault loop in UEFI
real pecan
tainocore uefi had this disgusting bug so its present on all early uefi implementations
u can update the bios to fix it
if thats the issue ofc
flint idol
Hangs before kernel code executes
vernal chasm
Ah yes framebuffer issues 
real pecan
Hangs before kernel code executes
Yeah I bet thats it
flint idol
The same thing happens in test subject 1
real pecan
How old is that?
flint idol
Guess I need to update both computers' bioses now
flint idol
How old is that?
2013
real pecan
Oh ok
real pecan
Guess I need to update both computers' bioses now
Well it would be cool if you did
And its generally a good thing to do
You 100% verified that it doesn't reach the kernel right?
flint idol
Lower half is indeed unmapped
real pecan
Then yeah
vernal chasm
And its generally a good thing to do
Only if you have problems with the current version, or the motherboard makers are like "UPDATE TODAY TO FIX THIS CVE"
real pecan
Im about 99% confident its that
real pecan
Yeah then its unmapped
flint idol
Only if you have problems with the current version, or the motherboard makers ar...
I do have a problem with the current version
So time to update
real pecan
I can add logging tomorrow so we can see that it indeed dies after trying to use uefi alloctor
flint idol
So time to update
Not now actually
real pecan
I mean u can just use bios for now it doesn't really matter for a 2013 pc
flint idol
I'll do it tomorrow probably
flint idol
I mean u can just use bios for now it doesn't really matter for a 2013 pc
Yeah
I'll remove the triple fault
And test obos
vernal chasm
but why target old machines :>
vernal chasm
flint idol
Twst subject 1,2, and 3 all are from 2013
real pecan
The 256 byte edid blob one
vernal chasm
Well I do have a macbook from like 2017 but it's kinda hard to test oses on it
vernal chasm
The 256 byte edid blob one
The big blob :>
real pecan
Indeed
vernal chasm
Wasn't it an extended-edid
vernal chasm
Version 2 edid
EDID structure (base block) versions range from v1.0 to v1.4; all these define upwards-compatible 128-byte structures. Version 2.0 defined a new 256-byte structure but it has been deprecated and replaced by E-EDID which supports multiple extension blocks.[citation needed] HDMI versions 1.0–1.3c use E-EDID v1.3.[1]
flint idol
well they were all my dad's
vernal chasm
what did E do
your mom
vernal chasm
Version 2 edid
Or E-EDID probably, since it came out in 1999
vernal chasm
real pecan
<https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Background>
Huh its deprecated in 2000
But you still have one
How old is your monitor
real pecan
Oh
vernal chasm
Because you can have up to 32 KiB blobs with E-EDID
Most likely the 128 upper bytes were used as either extension block 1 or a block map
vernal chasm
00 FF FF FF FF FF FF 00 05 E3 02 27 A4 2A 00 00
1A 21 01 04 B5 3C 22 78 3F 29 D5 AD 4F 44 A7 24
0F 50 54 BF EF 00 D1 C0 81 80 31 68 31 7C 45 68
45 7C 61 68 61 7C 56 5E 00 A0 A0 A0 29 50 30 20
35 00 55 50 21 00 00 1E 00 00 00 FF 00 56 58 4A
50 36 48 41 30 31 30 39 31 36 00 00 00 FC 00 51
32 37 47 32 47 33 52 33 42 0A 20 20 00 00 00 FD
00 30 A5 FA FA 42 01 0A 20 20 20 20 20 20 01 8C
02 03 32 F1 4C 01 03 05 14 04 13 1F 12 02 11 90
3F 23 09 07 07 83 01 00 00 E3 05 E3 01 E6 06 07
01 63 63 00 6D 1A 00 00 02 01 30 A5 00 00 00 00
00 00 98 FC 00 6A A0 A0 1E 50 08 20 35 00 55 50
21 00 00 1A 40 E7 00 6A A0 A0 67 50 08 20 98 04
55 50 21 00 00 1A 6F C2 00 A0 A0 A0 55 50 30 20
35 00 55 50 21 00 00 1E F0 3C 00 D0 51 A0 35 50
60 88 3A 00 55 50 21 00 00 1C 00 00 00 00 00 F8
This is one of my monitors EDID blobs
HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\<Monitor>\<ID>\Device Parameters\EDID In the registry 🙂
The upper 128 bytes refer to a CEA-EXT extension block it seems
real pecan
`HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\<Monitor>\<ID>\Device Parameters\EDI...
How did u read it
vernal chasm
For me I just reg query "HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\AOC2702\5&1a8dbdb9&0&UID4355\Device Parameters" /v "EDID"
in cmd
But you probably want to open it in registry editor to find the correct monitor and id parts
real pecan
I see
vernal chasm
Also you might have a system like me where you have more monitors than you actually have...
I have two, but this states I should have three xD
real pecan
Looks like it has the same id
weary hound
Looks like it has the same id
4355 vs 4357
real pecan
I meant the thing before
vernal chasm
Looks like it has the same id
Nono the first one is a nonexistent one
weary hound
I meant the thing before
oh my bad
vernal chasm
Ok the list of EDID blobs
AOC2702\1&8713bca&0&UID0
00 FF FF FF FF FF FF 00 05 E3 02 27 A4 2A 00 00
1A 21 01 04 B5 3C 22 78 3F 29 D5 AD 4F 44 A7 24
0F 50 54 BF EF 00 D1 C0 81 80 31 68 31 7C 45 68
45 7C 61 68 61 7C 56 5E 00 A0 A0 A0 29 50 30 20
35 00 55 50 21 00 00 1E 00 00 00 FF 00 56 58 4A
50 36 48 41 30 31 30 39 31 36 00 00 00 FC 00 51
32 37 47 32 47 33 52 33 42 0A 20 20 00 00 00 FD
00 30 A5 FA FA 42 01 0A 20 20 20 20 20 20 01 8C
AOC2702\1a8dbdb9&0&UID4355
00 FF FF FF FF FF FF 00 05 E3 02 27 A4 2A 00 00
1A 21 01 04 B5 3C 22 78 3F 29 D5 AD 4F 44 A7 24
0F 50 54 BF EF 00 D1 C0 81 80 31 68 31 7C 45 68
45 7C 61 68 61 7C 56 5E 00 A0 A0 A0 29 50 30 20
35 00 55 50 21 00 00 1E 00 00 00 FF 00 56 58 4A
50 36 48 41 30 31 30 39 31 36 00 00 00 FC 00 51
32 37 47 32 47 33 52 33 42 0A 20 20 00 00 00 FD
00 30 A5 FA FA 42 01 0A 20 20 20 20 20 20 01 8C
02 03 32 F1 4C 01 03 05 14 04 13 1F 12 02 11 90
3F 23 09 07 07 83 01 00 00 E3 05 E3 01 E6 06 07
01 63 63 00 6D 1A 00 00 02 01 30 A5 00 00 00 00
00 00 98 FC 00 6A A0 A0 1E 50 08 20 35 00 55 50
21 00 00 1A 40 E7 00 6A A0 A0 67 50 08 20 98 04
55 50 21 00 00 1A 6F C2 00 A0 A0 A0 55 50 30 20
35 00 55 50 21 00 00 1E F0 3C 00 D0 51 A0 35 50
60 88 3A 00 55 50 21 00 00 1C 00 00 00 00 00 F8
AOC2702\5&1a8dbdb9&0&UID4357
00 FF FF FF FF FF FF 00 05 E3 02 27 8D 07 00 00
1C 21 01 04 B5 3C 22 78 3F 29 D5 AD 4F 44 A7 24
0F 50 54 BF EF 00 D1 C0 81 80 31 68 31 7C 45 68
45 7C 61 68 61 7C 56 5E 00 A0 A0 A0 29 50 30 20
35 00 55 50 21 00 00 1E 00 00 00 FF 00 31 38 44
50 37 48 41 30 30 31 39 33 33 00 00 00 FC 00 51
32 37 47 32 47 33 52 33 42 0A 20 20 00 00 00 FD
00 30 A5 FA FA 43 01 0A 20 20 20 20 20 20 02 0D
02 03 32 F1 4C 01 03 05 14 04 13 1F 12 02 11 90
3F 23 09 07 07 83 01 00 00 E3 05 E3 01 E6 06 07
01 63 63 00 6D 1A 00 00 02 01 30 A5 00 00 00 00
00 00 40 E7 00 6A A0 A0 67 50 08 20 98 04 55 50
21 00 00 1A 6F C2 00 A0 A0 A0 55 50 30 20 35 00
55 50 21 00 00 1E F0 3C 00 D0 51 A0 35 50 60 88
3A 00 55 50 21 00 00 1C 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E1
70 12 79 03 00 03 01 14 EB 01 01 04 FF 09 69 00
07 80 1F 00 9F 05 3C 00 02 00 04 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C 90
O_O
It just got progressively bigger xD
flint idol
holy yapping of the yappingtons
vernal chasm
Absolutely
Just me trying to figure out parsing that block
But either the block is broken or the spec on wikipedia is broken
vernal chasm
Does it parse the upper 128 bytes tho?
real pecan
Yes
vernal chasm
As a normal EDID blob?
real pecan
Yes
vernal chasm
And not as the extension?
real pecan
How many times do I say yes 
real pecan
Uefi probably exposes it the way its compatible
Or again maybe you're experiencing a so called skill issue
vernal chasm
The problem is that the blob says it has a Speaker Allocation block of 12 bytes, but they're supposed to only be 3 bytes in total
vernal chasm
Yeah this is what I parsed manually
flint idol
@real pecan Upon updating the firmware for test subject two, OBOS still does not boot in UEFI mode
real pecan
let me give u a binary with info logs
flint idol
test subject one is on the latest bios version
real pecan
chilly osprey
nice try hacker
flint idol
the last update was from 2014
this specific model seems to have been manufactured in 2015
vernal chasm
dont worry i already have his OEM keys
And you also do have direct access to my machine, right?
real pecan
yes, there's a backdoor using asynchronous http uefi api to send over all keys
vernal chasm
Good good, I mean I don't use my pc to its fullest, so I gotta let others use some of it 😉
real pecan
yes, u dont need all your terabytes of ram
vernal chasm
I do have 64 gigs of DDR5 unused, but it'll be like 400€ :>
Cuz I paid way more for them
Anyways I should really try and get a server rig soon
flint idol
for reference, this is what qemu returns
real pecan
yeah it disables info logging relatively early as using UEFI ConOut is allowed to allocate memory
which alters the memory map
if that binary i sent u doesnt come up with anything ill remove the logging disabler
flint idol
I wanna make a script to refresh the fat32 image I use for xorriso
real pecan
how do u not have oine
flint idol
never made one
real pecan
damn
real pecan
i can just give u the test kernel iamge
that i use
if u wanna use that instead of reflashing stuff
it boots into the test kernel
flint idol
iso
real pecan
real pecan
huh wtf
flint idol
what if it's making a pt
real pecan
but lets dig deeper
real pecan
im afraid its simpler
i didnt add logging to the function that allocates memory
it probably hangs in that
lets see
wouldn't be surprised to never see the bottom log
but ill sprinkle a few more printfs just to be sure
flint idol
wouldn't be surprised to never see the bottom log
I assume that's because of the bug you told me about earlier
real pecan
yeah
but thats not the first allocation with a custom type i think
anyway lets see
would be nice if its some other bug
that means we didnt waste time
flint idol
flint idol
Horray
real pecan
I remmeber it only manifests itself once u actually try to retrieve the memory map
it probably hangs in GetMemoryMap
flint idol
after some light searching
phoneix is the company that makes the bioses for dell
which is the company that made test subject 2
real pecan
im afraid its this
flint idol
oof
real pecan
this is invoked when it tries to iterate the high memory to map it
it deferred until actually requested
so
but let's see ofc
still hoping its a bug on my part
real pecan
limine loads it and then carves pieces out of it manually i think, aka doesn't use uefi allocators or something like that i believe
which isnt super safe i think
@sharp pike can correct me on that
for a workaround i guess i could have an internal overlay buffer that contained a mapping of which range represents what loader memory type
idk its just a uefi bug that i didnt want to work around
sharp pike
Limine works around even the stupidest of firmware bugs if i find them
real pecan
what does it say