Thema: Dauerhafter Floppy Zugriff

[sebi2020]

Ich habe meinen Kernel mal kompiliert und unter Bochs ausgeführt. Aus irgend einem Grund findet ein ständiger Zugriff auf das Floppylaufwerk vor, und der Prozessor wird auch ständig belastet. Hat jemand eine Idee woran das liegen könnte?
Kann auch gerne mal meinen quelltext posten
dsplib.lib:

Code: [Auswählen]

// Bildschirmdefinition
#define DISPLAY_MEM_START 0xb8000
#define DISPLAY_MEM_END 0xB8FA0
// Konsolendefinition
#define LINE (console_y * 0xA0)
/* Konsolenzeile */
int console_y = 0;
int console_x = 0;
char* video = (char*) 0xb8000;
/* Konsolenzeile ende */

int strlng(char* string)
{
int count = 0;
while(*string)
{
string++;
count++;
}
return count;
}
void cls(void)
{
for(video=(char*)DISPLAY_MEM_START; video < (char*) DISPLAY_MEM_END;video++)
*video=0;
video = (char*) 0xb8000;
}
void s_line_print(char text[])
{
int cursor = 0;
for(cursor = 0; cursor < strlng(text);cursor++)
{
video[LINE+(2*cursor)] = text[cursor];
video[LINE+(2*cursor)+1] = 0x7;
}
console_y++;
}
void put_char(char c, int color)
{
if(c != '\n' && c != '\r' && console_x <= 80)
{
video[LINE + (2*console_x)] = c;
video[LINE + (2*console_x)+1] = color;
console_x++;
}
else
{
if(c == '\n' || console_x > 80)
{
console_y++;
return;
}
if(c == '\r')
{
console_x = 0;
return;
}
}
}
void print(char text[],int color)
{
int count;
for(count = 0; count < strlng(text);count++)
{
put_char((char) text[count],(int) color);
}
}

display.h:

Code: [Auswählen]

// Funktiondeklaration
int strlng(char* text);
void cls(void);
void s_line_print(char text[]);
void put_char(char c,int color);
void print(char text[], int color);

kernel.c

Code: [Auswählen]

#include "display.h"
void init(void)
{
cls();
s_line_print("InfoOS");
print("Starting InfoOS...\n\rPlease wait...",7);
return;
}

start.asm

Code: [Auswählen]

global loader
MB_MAGIC equ 0x1badb002
MB_FLAGS equ 0x0
MB_CHECKSUM equ - (MB_MAGIC + MB_FLAGS)

section multiboot
; Multiboot Header
align 4
dd MB_MAGIC
dd MB_FLAGS
dd MB_CHECKSUM

section .text
extern init

loader:
mov esp, 0x200000
push eax
push ebx
call init
cli          ; Vorzeitige Lösung
hlt         ; --

Hier noch mein Linkerscript:

Code: [Auswählen]

ENTRY (loader)
OUTPUT_FORMAT(elf32-i386)
OUTPUT_ARCH(i386:i386)

SECTIONS
{
. = 0x100000;
.text :
{
build/start.o(multiboot)
*(.text)
}
.data :
{
*(.data)
}
.bss :
{
_sbss = .;
*(COMMON)
*(.bss)
_ebss = .;
}
}
Hoffe das Hilft weiter Ich ahb absolut keine Ahnung, woran das liegen könnte.

[FreakyPenguin]

Aus irgend einem Grund findet ein ständiger Zugriff auf das Floppylaufwerk vor, und der Prozessor wird auch ständig belastet. Hat jemand eine Idee woran das liegen könnte?

Woher weisst du denn, dass der Prozessor belastet wird? Also mit cli hlt müsste da eigentlich schon fertig sein.

Auf das Diskettenlaufwerk wird wohl auch nicht zugegriffen, lediglich der Motor läuft. Das hängt vermutlich damit zusammen, dass grub den nicht ausschaltet.

[sebi2020]

Ich merks da Bochs dass anzeigt, (IPS). Und der Prozessor auf meim Host-System auf hochtouren läuft.

[sebi2020]

ist es den normal, dass grub den motor nicht ausschaltet?

[Jidder]

Wie drückt sich das in Bochs aus, dass der dauernd auf die Floppy zugreift?

[sebi2020]

In der Statusleiste ist neben IPS, ein Eintrag "A:". Und der leuchtet GRÜN.

[XanClic]

Das kenne ich, war bei mir immer so (afair auch, wenn ich den Motor explizit ausgeschaltet hatte). Ich glaube, das kann man getrost ignorieren.

[sebi2020]

Das kenne ich, war bei mir immer so (afair auch, wenn ich den Motor explizit ausgeschaltet hatte). Ich glaube, das kann man getrost ignorieren.

Hast du den dein OS schon mal aufm richtgen PC ausgeführt und es hat nicht die ganze Zeit gerattert?

Ich wunder mich dass es bei mir immer so ist, weil ich hab mir mal nen tyndur Image runtergeladen und gestartet , und da isses nicht so (mal abgesehn davon, dass dass image nicht funzt, in so fern dass dort immer steht, abhängigkeit konnte nicht gefunden werden oder so ähnlich).

[FreakyPenguin]

Ich wunder mich dass es bei mir immer so ist, weil ich hab mir mal nen tyndur Image runtergeladen und gestartet , und da isses nicht so (mal abgesehn davon, dass dass image nicht funzt, in so fern dass dort immer steht, abhängigkeit konnte nicht gefunden werden oder so ähnlich).

tyndur hat ja auch einen Treiber fürs Diskettenlaufwerk, der sich unter anderem auch darum kümmert, den Motor auszuschalten, wenn er grad nicht benutzt wird. Und jo, dass es in Bochs kaputt ist, wissen wir.

[sebi2020]

naja, aber xanclic hat ja auch versucht den motor auszuschalten, und es hat nicht geklappt... hm...

[XanClic]

Na, dann werde ich was falsch gemacht haben.

Aber ich kann zumindest guten Gewissens bestätigen, dass das Laufwerk nach einem Start von GRUB nicht ständig rattert. Deshalb gehe ich entweder davon aus, dass bochs im "Diskettenmodul" selbst einen Fehler hat oder im BIOS.

[kevin]

Das Laufwerk rattert auch nicht, wenn man den Motor anlässt, sondern das Licht bleibt halt an. Aber auch das tut es mit GRUB normal nicht.

[sebi2020]

hm, vllt nen bug von bochs

EDIT:
Grub stellt den Motor nicht aus, dass ist kein Bug von Bochs oder so. Habe meinen kernel mal auf floppy kopiert und auf nem richtigen computer gestartet. Der Motor wird nicht abgeschaltet. Aber vielleicht liegt dass auch nur an meiner Grub version. keine ahnung. ich benutzt grub4dos. Vielleicht ist dass beim normalen Grub (unter linux) anders.