Nachrichten

1

Lowlevel-Coding / Re:Floppy-Treiber: IRQ6 blockiert?

« am: 25. April 2011, 23:03 »

Da bin ich beruhigt. Nur leider verzögert dies doch sehr stark oder?  Nunja, ich werde es selber mal probieren und hoffen, dass ich da ein optimum raushole. Danke für den Tipp.

2

Lowlevel-Coding / Re:Floppy-Treiber: IRQ6 blockiert?

« am: 24. April 2011, 18:27 »

Ganz recht, langsam verzweifle ich, denn es ist ein für mich nicht logisches Problem. Anscheinend wird tatsächlich dieser IRQ6 selber blockiert, obwohl er beim Boot vorher noch funktionierte. Und beim Emulator funktioniert er durchgehend, das verwirrt mich. Wenn der beim Emulator in der Shell nicht funktionieren würde, könnte man gezielt schauen, aber so, dass der nur bei einem Aufruf durch die Shell und nur bei echter Hardware blockiert ist, seltsam

3

Lowlevel-Coding / Re:Floppy-Treiber: IRQ6 blockiert?

« am: 23. April 2011, 21:52 »

Also bei einem Syscall ruft meine Shell eine Funktion auf, welche die nötigen Parameter in die Register schreibt, dann meinen Syscall-ITR 0x30 aufruft. In meiner IDT ist der Syscall natürlich als RING3 gekennzeichnet. Dann werden in meiner ISR nur alle Register gesichert und eben zu dem C-Teil meiner ISR gesprungen. Dort wird vom Interrupt mit einem switch unterschieden und das ausgeführt, was unter meinem Syscall Eintrag steht (meine Syscall-Funktion, die dann die aufgerufenen Funktionen aufruft). Also ich deaktiviere die eigentlich nirgends. Aber bei meiner Syscall-Funktion mache ich eh nochmal ein explizites sti, damit wirklich alles funktionieren kann.

4

Lowlevel-Coding / Floppy-Treiber: IRQ6 blockiert?

« am: 23. April 2011, 18:51 »

Hallo,

ich hab mein Problem ja im IRC schon öfter angesprochen. Nachdem ich FAT ansatzweise hab, bin ich nun am FDC-Treiber. Mein eigener war eigentlich fertig, hat aber auch nach 1 Monat Fehlersuche nicht auf einem echten Rechner funktioniert. Deshalb hab ich nun zu einem fertigen Modul gegriffen von NeptuneOS, welches auch PrettyOS verwendet, und das für mein OS umgeschrieben. Während des Bootens funktioniert dieser auch hervorragend auf sowohl auf einem Emulator, als auch auf echter Hardware. Also man kann davon ausgehen, dass der funktioniert. Jedoch nachdem meine Shell gestartet ist und ich zum Beispiel von der FAT aus einen Sektor zum Analysieren lesen möchte, kommt bei keinem FDC-Befehl mehr ein IRQ6 zurück, dementsprechend hängt das System an der Stelle, da auf den IRQ6 gewartet wird.

Ein gutes Beispiel ist beim Seek. Im MSR kann man ja auslesen, ob der noch seekt und da habe ich gesehen, dass auch wenn der nicht mehr seekt und der IRQ6 in jedem Fall gesendet werden müsste, keiner kommt. Er wird also irgendwie blockiert. Aber ich sende nach jedem der 16 IRQs ein EOI, der IRQ6 sollte meiner Meinung nach nicht maskiert sein, da ich dies nirgends mache und ein cli kann auch nicht Schuld sein, denn ein IRQ1 zum Beispiel kommt noch sauber durch.

Nun frage ich mich natürlich, wieso der IRQ6 anscheinend von der Shell mit einem Syscall aus nicht mehr ankommt, obwohl der während des Bootens noch funktionierte.

MfG
ChristianH