OSDev.org

Are you sure it's a bug, nicknytko?

Roman wrote:

muazzam wrote:Are you sure it's a bug, nicknytko?

"It's not a bug. It's a feature!"

haha.

But I was serious.

muazzam wrote:

Roman wrote:

muazzam wrote:Are you sure it's a bug, nicknytko?

"It's not a bug. It's a feature!"

haha.

But I was serious.

hahaha yes, it was an accident
my printDecimal had a bug where if the input number was zero, it would infinite loop and overwrite the first 48kb of memory

Working on my "Terminal Emulator" recently. While trying some optimisations to speed up the display (it's way too slow at the moment), I got this:



It has something to do with telling the graphics subsystem to update zero-sized areas of the screen, but I only got this after I added a check for that... Also, I have no idea why the text is purple.

There are still some syncing issues present. Some old code is still not fully preeption-aware and explodes if "real preemption", that is preemption plus concurrency kicks in.

The culprit lies in the design of one of my printf-functions which has a "internal_vprintf" that works on a ivp_ctx structure with a putchar-callback (one for string, one for framebuffers, ...). The structure on the stack gets damaged as sometime miracously two processors work on the same stack, which is a bit surprising as the "scheduler's log" clearly shows, that each task uses it's own stack. Additionally each task has a running flag, disallowing the usage of the stack for other task_schedule calls.

The scheduler is an implementation of the rotating staircase scheduler, kredraw is in the queue with highest priority, which explains the 10 context switches towards it.
(kredraw -> task_yield -> kredraw -> task_yield -> until quota=0 and cur_prio--)

I was experimenting with SMP in my OS. I have the cores in 32 bit mode, so was now trying to start them up. Of course, I had to go and trigger a fault... on BOTH cores.

When I'm tested TTY scrolling. Looks like it's not working well

When you have bug in your scroll routine:

Me, trying to fill my Vesa Framebuffer with a Material design Color:



and a few seconds later:

qemu: fatal: Trying to execute code outside RAM or ROM at 0x8210043b

EAX=04106003 EBX=0015ac09 ECX=000000ff EDX=03380000
ESI=00000001 EDI=00ffe082 EBP=00000000 ESP=00106004
EIP=8210043b EFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0010 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0018 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0018 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0018 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0018 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 00108240 00000020
IDT= 00000000 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=000001ff CCD=000000ff CCO=SARL
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
Aborted (core dumped)

cheapskate01 wrote: LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
GDT= 00108240 00000020
IDT= 00000000 00000000

Does that mean I did Gdt and Idt successfully?

cheapskate01 wrote:

cheapskate01 wrote: LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
GDT= 00108240 00000020
IDT= 00000000 00000000

Does that mean I did Gdt and Idt successfully?

I don't think so.

Roman wrote:

cheapskate01 wrote:

cheapskate01 wrote: LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
GDT= 00108240 00000020
IDT= 00000000 00000000

Does that mean I did Gdt and Idt successfully?

I don't think so.

Brainfart. I didn't build Gdt and Idt in this code fork Lol

That's the result of transfering 5 2/3rds 24-bit pixels via the SSE movdqa into the framebuffer. The 24-bit pixel format is the most tricky one to get right, innit?

My failure to add a clear screen function :/
I have no Idea how to fix it. No matter what I do, the background is green.