moldytzu / mos Goto Github PK

When calling an interrupt handler, the cpu triple faults and hard resets.

Probably a buffer overflow.....

Describe the bug
After a threshold of total apps loaded is reached, the kernel will panic with a page fault message pointing to framebuffer code.

Steps to reproduce
Set shell to wm.mx in init.cfg and spam "q".

Expected behavior
No exception

Screenshots
If applicable, add screenshots to help explain your problem.

Affected enviroment (please complete the following information):

• SMP enabled: doesn't matter
• KVM enabled: doesn't matter
• RAM amount of test machine:
• Bare metal:

Additional context
Add any other context about the problem here.

Self explainatory

Describe the bug
The timer frequency is not the same on all cores. Some have the requested frequency from the kernel config, some have 10~20x that value.

Steps to reproduce
Build mOS normally but with tps debug mode in cpu/xapic.c

Expected behavior
All cores have very similar frequencies

Affected enviroment (please complete the following information):

• SMP enabled: yes
• KVM enabled: yes
• RAM amount of test machine: doesn't matter
• Bare metal: yes

Additional context

[c1] (1.000) 35622
[c0] (1.003) 147
[c1] (2.000) 37132
[c0] (2.008) 150
[c1] (3.000) 39324
[c0] (3.003) 148
[c1] (4.000) 39408
[c0] (4.009) 150

Describe the bug
In the PS/2 driver implementation there is a setting named MAX_DELTA_PER_PACKET. It affects the maximum relative position change per mouse packet. With it disabled the cursor goes nuts when moving down or left. Might be a problem with the way we handle the sign bits?

Steps to reproduce

Expected behavior
Working cursor

Screenshots

Affected enviroment (please complete the following information):

• SMP enabled: doesn't matter
• KVM enabled: doesn't matter
• RAM amount of test machine: doesn't matter
• Bare metal: no

Additional context
Add any other context about the problem here.

Something isn't right when cleaning up after the task is killed. It can't be a race condition caused by SMP because it affects non-SMP systems too.

Describe the bug
The .bss section may not be initialised properly thus resulting in random values.

Example code

#include <mos/sys.h>
#include <stdlib.h>
#include <stdio.h>

int abcd;
int initialised = 1;
int nul = 0;

int main(int argc, char **argv)
{
    printf("%d %d %d", abcd, initialised, nul);
}

Expected output
0 1 0

Actual output
134283269 1 319

It is caused by a wrong handling of the situation in the exit syscall handler. We should ask the scheduler to load the next task's context instead of killing and waiting for a context switch.

EDIT: it affects non-SMP enviroments too