Sourcecode Fortschritt
-
Der Fehler erfolgt auf der user-Seite, so wie es aussieht. Allerdings gibt es noch Ungereimtheiten:
- Du hast davon berichtet, dass der richtge Sektor geladen würde mit anschließendem "freeze".
- Schaltet man in os.h die "Diagnose-Schalter" zu, so taucht ein #PF > 0xF0000000 auf.
- Der #PF bei USER_STACK ist der dritte Fall, der wohl am meisten eintritt.
-
Hi,
ich denke der Fehler tritt im Kernel auf. Das sollte übrigens jeder an dem Wert in CS erkennen können. EIP gibt den Hinweis auf die Funktion, wo der Fehler auftritt, nämlich "execute".
Bei der weiteren Analyse sind mir mehrere Fehler aufgefallen:
void execute(const char* path) { ... while(*path != '/' && *path != '|' && *path != '\'')Die while-Schleife läuft über das Ende des Strings hinaus, wenn path weder \ noch | noch ' enthält. Es fehlt also ein Test auf den Nullterminator. Außerdem sieht man hier sofort, dass Pfade nicht mit "3:\" anfangen dürfen, wie in Erhards Beispiel. Diese beiden Sachverhalte kombiniert mit der Tatsache, dass der Wert von path knapp unter 01420000h sind die Ursache für den Fehler.
Lässt man übrigens 3:/TTT ELF ausführen, dann scheint das (zumindest bei mir) nicht zu klappen, weil das Laufwerk 3 oder was auch immer das ist nicht existiert. Das gibt wieder einen Page Fault (bei mir) an Adresse 0xf000ff7f, und bei dieser Adresse liegt sofort der Verdacht nahe, dass ein NULL-Pointer dereferenziert wurde. Ich denke mal es liegt an der Funktion getPartition, in denen weder die Variablen PortID, PartitionID und DiskID vollständig überprüft werden, noch die Werte der Zeiger auf NULL getestet werden, vor allem da in devicemanager.h dokumentiert ist, dass diese NULL sein können.
if(PortID != -1) { return(ports[PortID]->insertedDisk->partition[PartitionID]); } else { if(DiskID == 0) { return(systemPartition); } else { return(disks[DiskID-1]->partition[PartitionID]); } }
-
der Fehler tritt im Kernel auf. Das sollte übrigens jeder an dem Wert in CS erkennen können.
Ja stimmt, wird klar angezeigt. Der Wert des user-stacks hat mich irritiert. Danke für die Analyse, hilft uns weiter.
-
Ja, diese Prüfung auf 0 fehlt, das stimmt. Und, was noch schlimmer ist, auch die bei den Strings... Danke für den Hinweis.
Aber auch bei eigentlich existierenden Laufwerken klappts aber nicht, auch nicht nach Behebung der Fehler.
EDIT: Derzeit muss man auch noch "3:/TTT ELF" als Laufwerk angeben. Sonst klappt es derzeit erst recht nicht.
EDIT2: #PF-Grund gefunden: '\'' ist nich \, sondern ', daher gingen alle Pfade mit \ nicht.
-
Ehenkes und ich haben grade zusammen den Durchbruch erzielt. Danke Lüttmoor für die Hilfe dabei. Die von dir genannten Probleme sollten jetzt behoben sein. Das mit dem Pfadseparator hast Du ja auch angsprochen, Lüttmoor, aber ich habs in deinem Text garnicht realisiert/zu flüchtig überlesen.
Revision 505:
- Bugfix: Pfade mit \ gehen nun
- Bugfix: waitForKeyStroke sorgt nicht mehr für Freeze. STI eingefügt
- Bugfix: Nullpointer-Abfragen bei Strings und Partition in devicemanager.c ergänzt
-
Dank an Lüttmoor für den Schubs in die richtige Richtung. Auf jeden Fall klappt es nun.
-
Rev. 506:
Nicht-MSD (also nicht class
werden nicht in den msd device manager eingefügt.
-
Revision 507:
- Eingabe von normalen Dateinamen nun erlaubt, 8.3-Notation ("TTT ELF") nicht mehr nötig
- Shortcut für Disk/Port-Ausgabe: Strg+d
- Kleinigkeiten
-
Revision 508:
- Floppytreiber objektorientierter gemacht, basiert auf floppy_t
- flpydsk_refreshVolumeNames statt flpydsk_get_volumeName
- diskType_t mit Funktionspointern für Sector-Read/-Write für Abstraktion
- Vereinfachungen im Code
-
Revision 509:
Revision 510:Fehlerkorrekturen
- pointer cast
- partitionszeiger floppy
-
Revision 511:
- Laden von Floppy mit Devicemanager möglich
- floppy_load ausgebaut (file.c), syscall freigegeben
- Kleinigkeiten, BugfixesDer fat12-Treiber in fat.c ist schneller als der in fat12.c -> doppelt erfolgreich
-
Rev. 512:
Formale Kleinigkeiten:
- Abschließende '\0' hinter Floppy Dev 1 bzw. Floppy Dev 2 eingefügt
- Eine Zeile Abstand hinter "This is a volume formated with FAT12."PrettyOS "denkt" mit:
- Gibt man ttt.elf ein, so will man vielleicht wie bisher (.elf sollte sein) vereinfacht auf die Floppy zugreifen. Wir bauen bei Vorhandensein eines FDD1 den Pfad "1:/" probeweise davor und rufen rekursiv erneut execute(newPath) auf.$> ttt.elf <-- file is being searched... No valid path for partition found! Floppy found! PrettyOS now tries 1:/ttt.elf buffer: C0002000h type: 1 SecPerClus: 1 maxroot: 224 fatsize: 9 fatcopy: 2 firsts: 0 fat: 1 root: 19 data: 33 maxcls: 4294967263 mount: 1 serial #: 50h 52h 45h 54h - - - - - - - - - - - press key - - - - - - - - - - -void execute(const char* path) { partition_t* part = getPartition(path); if(part == NULL) { textColor(0x0C); printf("\nNo valid path for partition found!\n"); textColor(0x0F); if ((cmos_read(0x10)>>4) == 4 ) // first FDD implemented { if (path[0] == '1' && path[1]==':') { // do nothing } else { char newPath[40]; strcpy(newPath,"1:/"); strcat(newPath,path); textColor(0x0E); printf("\nFloppy found! PrettyOS now tries %s\n",newPath); textColor(0x0F); execute(newPath); } } return; } while(*path != '/' && *path != '|' && *path != '\\') { path++; if(*path == 0) { return; } } path++; loadFile(path, part); }maxcls: 4294967263 <--- etwas hoch
-
Rev. 513:
Zwei nicht mehr benötigte Funktionen zum Laden von Floppy in file.h/c entfernt
So stellt sich das momentan in VBox mit zwei Floppy Disk Devices dar:
Available ports: Type Number Name Inserted disk ---------------------------------------------------------------------- FDD A Floppy Dev 1 PRETTYOS FDD B Floppy Dev 2 RAM C RAM RAMDisk ---------------------------------------------------------------------- Attached disks: Type Number Name Part. Serial ---------------------------------------------------------------------- Floppy 1 PRETTYOS 0 PRETTYOS RAMdisk 3 RAMDisk 0 786436 ----------------------------------------------------------------------
-
Rev. 514:
Verbesserung der Darstellung der FAT-Descriptor-Daten in loadFile
-
Revision 515:
- Fehlerbehandlung von execute jetzt in shell.c
- execute und loadFile geben nun FS_ERROR zurück
- Disk zählt noch zu lesende Sektoren -> Möglichst seltenes an/aus des Motors bei "beweglichen" Medien wie Floppys, HDDs und CDs
- Syscall-Definition von execute repariert
- Kleinigkeiten
-
Revision 516:
- (jetzt hoffentlich funktionierende) Floppy-Motor-Steuerung
- Zahlreiche Funktionen aus fat12.c entfernt
-
Rev. 517:
Es gibt nach Umbauarbeiten (dank an MrX) überraschende Probleme auf real PC mit der Floppy:
Bei mir hört es in der ports-liste nach FDD auf, nur noch read error
daher cross-check, bitte testen.Mit den nachgereichten Versionen für die Motorsteuerung geht es ebenfalls nicht!
http://codepad.org/oZCtQChr
http://codepad.org/kaH3aG1q
http://codepad.org/MJDdABeh ("mal eine ältere Version")sag mir, ob es a) geht und wenn nicht b) zuletzt "off" angezeigt wird
a) es geht nicht (zwei PC mit echter Floppy, zwei Disketten)
b) "on" steht vorne nach Finden der FDD; "off" kommt nicht, nur der read error mit Lampe aus (bei beiden PCs and der exakt gleichen Stelle).MrX: bitte checke mal die Rev. 517, ob die wirklich so auf real PC bei dir läuft. Vielleicht hast du lokal eine andere Version.
VMWare läuft mit rev. 517 korrekt, aber lädt viel zu lahm.
Gibt man nur "ttt.elf" ein, so wird "Trying now on 1:/." angezeigt, aber korrekt geladen.VBox klappt gut mit zwei Floppys, lädt schnell.
Qemu läuft analog VBox.Nachdem ich auch noch auf meinem Entwicklungs-PC das gleiche negative Ergebnis erhielt:
Bei manchen PCs muss man zwei mal laden, bis es klappt (DMA-Init-Problematik, muss noch im geänderten Code untersucht werden), also erstes mal read error, dann beim zweiten mal Erfolg. Wenn wir aber Sektoren zählen und entsprechend bei null abschalten, könnte dies genau vor dem erfolgreichen Lesen erfolgen.
Nur so eine Idee. Spricht nur dagegen, dass das "off" bei dem einen Test nicht kam. Also könnte es auch sein, dass dieser Lesevorgang zur Detektion des Partitionsnamens in einer Fehlerschleife hängen bleibt.
Ein Test auf einem vierten PC: ebenfalls nicht ok. Nach ENTER drücken gings weiter, aber ständig read error und Festhängen an diesem Punkt. ttt.elf wurde nicht geladen, als es endlich gelang dies einzutippen.
Irgendetwas ist in Rev. 517 gegenüber früheren Versionen massiv gestört im Lesevorgang.
Bitte gegen den Ablauf im alten Code checken.Cuervo: bitte ebenfalls prüfen.
-
Danke für die Umfangreichen Tests, Erhard.
(dank an MrX)
Danke, das ichs zerschossen hab?
Naja, ab und zu muss man mal was kaputt kriegen, ums wieder zusammensetzen zu "dürfen"
-
Rev. 518: Vorbereitungen FAT-Modul: Schreiben (Ablösung file.c und weitgehend fat12.c)
-
Revision 519:
- Floppyproblem behoben. Ich hatte nicht bedacht, das flpydsk_enable_controller den Motor abschaltet. Daher wichen CurrentDisk->motor und Realität vonnander ab
- Shell gibt nun Dateinamen statt "1:/" bei retry an.
- Kleinigkeiten