![]() |
ENGLISH VERSION |
|
![]() |
Links | | | Forum | | | Kommentare | | | News melden |
![]() |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
![]() |
amiga-news.de Forum > Amiga, AmigaOS 4 > Probleme mit SCSI und IBM Festplatte | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
1 -2- | [ - Beitrag schreiben - ] |
26.07.2005, 16:18 Uhr aPEX Posts: 4692 Nutzer |
Zitat:Eigentlich nicht. Ist zwischen Netzteil und Daughterboard eingebaut. Aber da auch nur lose, Gehaeusedeckel ist offen... Zitat: Laut Jörg (Autor von SFS) sollte es keinerlei Fehler geben. Ich habe ihm ja schon die Fehlermeldung und alles zukommen lassen... Ich werde die Partition mal mit FFS formatieren und dann ein Script machen welches mir die Daten rueberkopiert. Mal schauen was er so nach 3-4 Stunden kopieren sagt... Da es sich um eine SFS Fehlermeldung handelt, muss bei FFS ja irgendwas anderes passieren... -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
26.07.2005, 17:56 Uhr aPEX Posts: 4692 Nutzer |
Hallo Thomas, hier mal ein paar Daten von SFSCheck Nach dem Crash... Partition start offset : 0x00000001:02c00000 End offset : 0x00000002:c4300000 Surfaces : 16 Blocks/Track : 128 Bytes/Block : 512 Sectors/Block : 1 Total blocks : 14727168 Device interface : NSD (64-bit) Checking RootBlocks ...okay Checking AdminSpaceContainers at block 2 Block 17 is not a valid admin block but it is marked in use in AdminSpaceContainer at 2 Dump of first 64 bytes of block 17. 0x0000: 4142b7a9 d9000000 00110000 00140000 AB·©Ù@@@@Q@@@T@@ 0x0010: 04500000 04620000 03d20000 045b0000 DP@@Db@@CÒ@@D[@@ 0x0020: 042f0000 04560000 041c0000 04530000 D/@@DV@@D@@DS@@ 0x0030: 03e30000 03fb0000 03960000 03b00000 Cã@@Cû@@C.@@C°@@ ...damaged Nach dem Formatieren... Partition start offset : 0x00000001:02c00000 End offset : 0x00000002:c4300000 Surfaces : 16 Blocks/Track : 128 Bytes/Block : 512 Sectors/Block : 1 Total blocks : 14727168 Device interface : NSD (64-bit) Checking RootBlocks ...okay Checking AdminSpaceContainers at block 2 ...okay Checking NodeContainers at block 7 ...okay Checking ObjectContainers at block 3 ...okay Checking Bitmap at block 34 (3682 blocks, 4000 bits/bitmap) ...okay Und hier die Daten von Check4GB... Name Volume Size Device Unit Version DosType Version Big Check CD0 685M cybscsi 1 8.5 CD01 113.20 no ok DH0 System 1085M cybscsi 0 8.5 SFS0 1.247 no ok DH1 Work 3053M cybscsi 0 8.5 SFS0 1.247 yes * N T S DH2 Stuff 7191M cybscsi 0 8.5 SFS0 1.247 yes * N T S DH8 Storage 5078M cybscsi 0 8.5 SFS0 1.247 yes * N T S DH9 Mails 1113M cybscsi 0 8.5 SFS0 1.247 yes * N T S PC0 NFORMAT! 720K mfm 0 40.9 MSD0 40.19 no ok PC1 720K mfm 1 40.9 MSD0 40.19 no ok DH3 Backup 3652M scsi 0 43.35 SFS0 1.247 no ok DH4 MP3 3153M scsi 0 43.35 SFS0 1.247 yes * N S DH5 Storage 2733M scsi 0 43.35 SFS0 1.247 yes * N S DF0 880K trackdisk 0 40.1 DOS0 45.9 no ok DF1 880K trackdisk 1 40.1 DOS0 45.9 no ok -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
26.07.2005, 18:00 Uhr aPEX Posts: 4692 Nutzer |
Ich habe jetzt die Version von SFS auf der IDE Platte auch erneuert. Werde jetzt ein Script starten das mir die Daten kopieren soll, mal schauen was nach 3 Durchläufen passiert. Mir wäre der Fehler ja nie aufgefallen wenn ich die Platte komplett neu bespielt hätte! Kopiere ich evt. viel zu lange zu viele Daten? Soll ich mal probieren die Verzeichnisse einzeln zu kopieren? -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
26.07.2005, 20:55 Uhr GolfSyncro Posts: 1455 Nutzer |
[quote] Original von aPEX: Zitat: Jepp hab ich ;-) Nein ich meinte ich hast du alles mal frisch eingerichtet und den yamaha garnicht drangehabt? Ihn mal komplett weglassen bis das kopieren rum ist. Das problem bei yamaha ist das er eigentlich nur für ihre ide brenner konzepiert ist und daher keine genaue scsi implementation hat. Zitat:Ja das weis ich auch robert aber wiegesagt vielleicht ist es auch eines von einer MK II odda War nur als hilfe gedacht Pack den rechner ein und komm vorbei... -- Mfg GolfSyncro [ - Antworten - Zitieren - Direktlink - ] |
26.07.2005, 23:21 Uhr aPEX Posts: 4692 Nutzer |
Gute Nachricht: Es hat nichts mit SFS zu tun... Schlechte Nachricht: FFS ist auch gecrascht. ![]() Mitten im Schreiben kam ein -write error und er hat gestoppt. Nach dem Booten sind auf der Partition kaum Files, wird aber angezeigt das 7GB belegt sind... -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 07:45 Uhr thomas Posts: 7719 Nutzer |
Kopier die Daten mal nacheinander, nicht alles auf einmal. Und nimm DOpus oder sowas. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 08:18 Uhr aPEX Posts: 4692 Nutzer |
@Thomas Kann das evt. auch "nur" ein Speicherproblem sein? Terminierung usw. bin ich gestern nochmal duchgegangen, alles ok. Dann habe ich mir die Jumper auf der MK1 angeschaut. Hauptspeicher stand auf -> Fast RAM Access (habs jetzt auf normal gejumpert). Mainboard burst access war deaktiviert (habs aktiviert). Beim Speicher handelt es sich um 4x 32MB PS2 vor 2 Monaten bei REICHELT Elektronik NEU gekauft. (Auf dem MoBo sind nochmal 16MB, wovon bei einem Riegel laut MemTest 3 Blocks defekt sind) -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 08:47 Uhr aPEX Posts: 4692 Nutzer |
Als Option kann ich noch das 8.2 ROM zu testen, wobei da wohl niemand mehr den Unterschied kennt zu 8.5. -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 09:00 Uhr tboeckel Posts: 124 Nutzer |
Zitat: Und warum glaubst du mit kaputtem Speicher noch irgendeine sinnvolle Reaktion vom Rechner zu bekommen? Kaputter Speicher muss nicht unbedingt Probleme machen, aber man muß davon ausgehen, daß er es früher oder später tut. Und bei dir scheint "früher" der Fall zu sein. Die einzig mögliche Lösung für dein Problem sollte dir jetzt auch alleine einfallen. [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 09:43 Uhr hannibal Posts: 201 Nutzer |
ja sieh zu das du den defeckten speicher raus baust, ich denke zwar nicht, das irgentwas in das langsame Mainboard ram gebracht wurde (da die 4 * 32 auf der TK wohl nie voll sind) aber wenn der Mainboard ram mall irgentwann gefüllt/genutz wird kommt es sicher zu "lustigen" efeckten... [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 10:29 Uhr aPEX Posts: 4692 Nutzer |
Eigentlich sollte das MoBo-Ram ja nichts ausmachen. Im Aminet gibt es ein Tool das nennt sich glaub MemCheck. Laut diesem Tool sind auf einem 4MB Riegel ein paar Blöcke defekt. Allerdings erzeugt dieses Tool eine ausführbare Datei die sich MemPatch nennt. Diese muss man vor Setpatch einbinden. Wenn man nun nochmal das Checkprogramm startet, findet er keine Fehler mehr, da die defekten und markierten Bloecke uebersprungen werden. Wusste auch nicht das es so geniale Tools gibt. ![]() vielleicht ist das ja die Lösung wenn die anderen Sachen nicht greifen. Sonst niemand mehr eine Idee? Detailierter kann man ja den Fehler leider nicht mehr beschreiben... ![]() -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 10:53 Uhr tboeckel Posts: 124 Nutzer |
Zitat: Warum nicht? Es ist da, es darf benutzt werden. Und nur weil es erst dann verwendet wird, wenn nichts anderes mehr frei ist, heißt nicht, daß es nie verwendet wird. Und wenn dummerweise Kontrollstrukturen in genau diesem kaputten Bereich gelagert und später wieder auf die Platte zurück geschrieben werden, dann ist der Platteninhalt ebenso kaputt. Da hilft auch kein Glauben und kein Hoffen. Kaputtes RAM sorgt nicht nur für fehlerhafte Daten im Speicher! Zitat: Die Lösung ist kurzfristig und genaugenommen ein Hack. Wer sagt dir denn, daß dieser Speicher wirklich immer als belegt gekennzeichnet werden kann? Ich habe früher zwar selbst mal so ein Programm geschrieben, weil von den 2MB auf dem alten GVP genau 1,5K kaputt waren. Das Programm hat dann diese 1,5K per AllocAbs() belegt und nie wieder freigegeben. Aber selbst AllocAbs() kann und darf fehlschlagen. Außerdem lohnt es sich die Anleitung zu lesen: Zitat: [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 11:33 Uhr aPEX Posts: 4692 Nutzer |
...ok, Speicher wird entfernt... Eine Sache die mir noch einfällt: Ich verwende nicht die 68060.library aus dem letzten Phase 5 Release (war das 1999 Packet), sondern die DCE Version von 2001. Kann es sein das die evt. Probleme hat mit der MK1? Die MK1 wurde ja nie von DCE neu aufgelegt... -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 19:33 Uhr aPEX Posts: 4692 Nutzer |
Jemand noch ne Idee? Ich weiss ich bin ungeduldig... ![]() Aber das Teil soll endlich laufen und morgen ist wieder ein Testabend angesetzt. ![]() -- cu, aPEX ![]() ![]() A1000-512KB Chip,8MB Fast,BlizzardTurboMemory,68010P12,ALF-Kontroller Phoenix, A500+, A600, A1200, A4000 ... http://phase5.a1k.org [ - Antworten - Zitieren - Direktlink - ] |
27.07.2005, 19:46 Uhr R-TEAM Posts: 1030 Nutzer |
Hi, da fast alles schon probiert wurde hier mal 2 ungewöhnliche tips von mir ![]() 1, probleme mit neueren ROM's und SCSI von der MK-I .. hatte NIE ein neueres ROM als IMHO 1.17 oder so ähnlich auf der MK-I-SCSI und hatte NIE probleme [auser mit burn-it wegen nichtunterstützten SCSI commandos des alten rom .. aber HD gingen ALLE] 2, versuche die HD mit dem tool von P5 einzurichten ! Sollte zwar kein unterschied machen ob HDToolBox oder SCSIConfig [nur mischen darfste nicht] aber man weis nie ... Ob die neure lib probleme macht ... ?? Lass sie halt mal weg beim starten .. benenne sie um [die 040 dummy lib] und sie wird nicht geladen .. Grüße R-TEAM [ Dieser Beitrag wurde von R-TEAM am 27.07.2005 um 19:48 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
1 -2- | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Amiga, AmigaOS 4 > Probleme mit SCSI und IBM Festplatte | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
![]() |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2025 by amiga-news.de - alle Rechte vorbehalten. |
![]() |