OSDev.org

froggey wrote: ↑Sat Jan 17, 2009 11:09 pm This happened after I messed up a memcpy and dumped my kernel's debug info to VGA memory.

damn bro that's crazy but what kind of debug info did you dump to VGA for it to be this kind of colorful?

I remember when I made my panic function accept variadic arguments. It took me yesterday of figuring out that I was reading garbage, so int 6 would panic with:
INT 00000000 EIP 0000004C CODE 00108E94
Which obviously wasn't true. Very funny nonetheless.
BTW, the correct one was "INT 00000000 EIP 00100743 CODE 00000000". Also offset 0x0743 in the kernel leads me to padding (maybe I didn't calculate it right? linked with offsets at 1M)

When FRED ain't FREDding right...
Fixed it now though

I'm refactoring my directory reading syscall and have to mess around in all of my drivers. The FAT filesystem driver directory logic is so terribly complex because the filesystem is too simple and poorly designed, which leads to fairly hilarious bugs.

The test here is simply:

rw -i /dev/zero -o fs.fat -c 64m
mkfs.fat -F 12 fs.fat
fatfs fs.fat /mnt
mkdir /mnt/foo
mkdir /mnt/bar
ls /mnt

And the filesystem massively duplicated the foo and bar entries hundreds of times lmao -- the most surprising thing was that it wasn't an infinite loop! The bug was that the root filesystem on FAT 12/16 is special and is not subject to the FAT cluster system, and so it has its whole own special directory iteration logic, and I accidentally mismatched my own logic and set the sector field instead of the cluster field in the (cluster, sector, offset) position triplet.

(Kids, don't implement FAT. Do ext2 instead. I only implemented FAT for EFI compatibility, and it's lack of good design makes it hard to retrofit into a well designed system -- and contrariwise making FAT your first filesystem will just damage your whole VFS design. FAT is simple, but it's too simple, and it makes life so much more complex. ext2 is slightly complex, and is much simpler to implement properly than FAT. In this case, the FAT root directory being special is making me go even balder than I already am.)

Not too crazy, but this is what happened when I first tried to implement terminal scrolling...

Hi everyone,

(I am new to this forum, so I hope I am embedding the images correctly)

My OS crashed 2 times: The first crash happened, when I tested battery level detection. The OS is german, so here is the translated text of the Blue Screen:



KOSMOS BLUE SCREEN

An error occurred in the kernel.

Error: PAGE_FAULT

Details:

EXCEPTION: PAGE FAULT

address: Ok(VirtAddr(0xe000))

error code: PageFaultErrorCode(0x0)

InterruptStackFrame {instruction_pointer: VirtAddr(0x10000025f60,),code_segment: SegmentSelector {index: 1,rpl: Ring0,},cpu_flags: RFlags(RESUME_FLAG | SIGN_FLAG | AUXILIARY_CARRY_FLAG | CARRY_FLAG | 0x2,),stack_pointer: VirtAddr(0x1800000f378,),stack_segment: SegmentSelector {index: 2,rpl: Ring0,},}

System-Watcher: KERNEL_FAULT
The system was halted. Please restart manually.

The second crash was the "coolest" one: I tried to use BIOS, but with an .ISO instead of an .IMG format... I guess it booted the ISO incorrectly as a floppy image, which caused a VRAM error and corrupted the screen, but I don't know.
Anyways, it doesn't matter anymore, because the battery level detection does now work and UEFI IMG, UEFI ISO and BIOS IMG do work.



Bye