Wesołych świąt!

Natknąłem się na dziwny przypadek: Są sobie 4 archiwa lha:

6ec19898d78f3fa78a559cf17cf3445b  system_backup_1.lha
d35f7ddda55bc4b7d5fcdbf86489ec75  system_backup_2.lha
d35f7ddda55bc4b7d5fcdbf86489ec75  system_backup_3.lha
d35f7ddda55bc4b7d5fcdbf86489ec75  system_backup_4.lha

-rw------- 1 pi pi 88743638 Aug 22  2020 system_backup_1.lha
-rw------- 1 pi pi 88743638 Aug 22  2020 system_backup_2.lha
-rw------- 1 pi pi 88743638 Aug 22  2020 system_backup_3.lha
-rw------- 1 pi pi 88743638 Aug 22  2020 system_backup_4.lha

Wszystkie cztery testowane przez linux'owe lha nie stwierdzają problemu po stronie linux'a (źródła). To samo md5:

$ md5sum -c system_backup.md5 
system_backup_1.lha: OK
system_backup_2.lha: OK
system_backup_3.lha: OK
system_backup_4.lha: OK

Natomiast po stronie amigi lha doszukuje się w każdym pliku błędnego jednego pliku. Próbowałem parokrotnie przygrywać przez NFS, nawet przegrałem spowrotem przez NFS do linux'a. Podejrzewałem na początku FastAT'e, ale po wyłączeniu i przejściu na oryginalny scsi.device objawy są takie same. Lha pokazuje błąd zawsze na tym samym pliku "C/DriveID", nawet gdy wywoła się go na napędzie zamontowanym przez ch_nfsmount:

1.OBELIX:backup> lha t system_backup_1.lha
LhA Freeware Version 2.15 68000+ 
Copyright (c) 1991-94 by Stefan Boberg.
Copyright (c) 1998,1999 by Jim Cooper and David Tritscher.
Copyright (c) 2004-2011 by Sven Ottemann.

Testing integrity of archive 'system_backup_1.lha':
    Testing: (      38/      38)  .backdrop
    Testing: (     520/     520)  .ssh/identity
    Testing: (     324/     324)  .ssh/identity.pub
    Testing: (    1679/    1679)  .ssh/id_rsa
    Testing: (     393/     393)  .ssh/id_rsa.pub
    Testing: (     400/     400)  .ssh/known_hosts
    Testing: (   57196/   57196)  C/7plus
    Testing: (   44764/   44764)  C/7plus2.04
    Testing: (    3484/    3484)  C/AddAudioModes
    Testing: (     444/     444)  C/AddBuffers
    Testing: (    4144/    4144)  C/AddDataTypes
    Testing: (    1068/    1068)  C/AddMem
---------- snip ----------
    Testing: (    1092/    1092)  C/Date
    Testing: (    2076/    2076)  C/Delete
    Testing: (    2072/    2072)  C/DeleteNetRoute
    Testing: (    4676/    4676)  C/DIC
    Testing: (    4024/    4024)  C/Dir
    Testing: (     328/     328)  C/DiskChange
    Testing: (  171532/  171532)  C/DiskDoctor
    Testing: (   84388/   84388)  C/DMS
    Testing: (    1588/    1588)  C/DoMIME
    Testing: (     108/     108)  C/DOnoColorMapping
*** Error on file 'DriveID' : Failed CRC Check
     WARNING: Skipping corrupt/extraneous data
105 files tested, 1 file failed.

Operation not entirely successful.

1.OBELIX:backup>

Lha ma swój własny mechanizm sprawdzenia integralności archiwum na poziomie poszczególnych plików oparty na CRC, a MD5 sprawdzam na całym archiwum. Ma ktoś pomysł gdzie szukać (i jak sprawdzić) problem?.

Używam 3.2.1, a MD5Sum który jest dołączony do systemu, natomiast md5sum2 z aminet'u guru'je ;)
Archiwa zostały stworzone po stronie Amigi:

lha -aezrx x system_backup_#.lha SYS:#?

Edyta: jednak linux'owy lha też zgłasza błąd na tym pliku (i w jeszcze jednym), ale pomimo błędu jednak kontynuuje dekompresję (błąd zgłasza do err-out). Da się amigowego lha zmusić do kontynuacji po napotkaniu błędu CRC?

Ostatnia aktualizacja: 25.12.2021 14:28:14 przez sq7bti

Spakuj to czyms innym, albo lha w starszej wersji, albo uzyj jakiegos najnowszego dearchiwizera lha na Amidze. Lha sie tak zachowuje jak napotka nieznana wersje kompresji. To moga byc rozne kompresje, zalezne od tego czym pakowane. Dlatego ja zwykle lha pakowalem tylko z kompresjami do uzywanych maks w lha 1.51. Nowszych juz do pakowania nie uzywalem, bo tylko problemy z rozpakowywaniem potem byly. Ale mozesz sprobowac rozpakowac na Amidze uzywajac xad.library.

Ale jesli pakowales i rozpakowywales to na Amidze uzywajac TEJ SAMEJ wersji lha. To jest to jakis blad w tej wersji programu. Po prostu nie pakuj tego pliku (wystarczy bit protekcji R skasowac) i powinno byc ok A ten plik skopiuj osobno.

BTW. Amigowy lha tez pomija uszkodzony wedlug niego plik, tylko ze to dlugo trwa jezeli to jest dlugi spakowany plik.

Ostatnia aktualizacja: 25.12.2021 15:16:52 przez Don_Adan

Lha amigowy przerywa rozpakowywanie jak tylko napotka trefny plik, a w opcjach nie znalazłem sposobu by zmusić go do kontynuacji. Natomiast na linux'ie w jakiś sposób daje rade i rozpakowuje do końca. Sprawdziłem czy te dwa pliki które wykazują błąd CRC są "zdrowe", ale file pod linuxem poprawnie rozpoznaje przynajmniej nagłówek. Linuxowy lha podczas rozpakowywania wypluwa na err-out:

C/DriveID       - Testing  :  .
C/DriveID       - Testing  :  o
C/DriveID       - Tested  
LHa: Error: CRC error: "C/DriveID"
--- snip ---
C/MP3Tool - Testing  :  .
C/MP3Tool - Testing  :  o
C/MP3Tool - Tested  
LHa: Error: CRC error: "C/MP3Tool"

Pomimo że file rozpoznaje nagłówek te pliki są jednak "szturchnięte":

$ file DriveID sound/MP3Tool 
DriveID:       AmigaOS loadseg()ble executable/binary
MP3Tool:       AmigaOS loadseg()ble executable/binary

DriveID jest z aminetu (docs/hard/PCFloppy2Amiga.lha) różni się od tego który udało się rozpakować z archiwum:

$ cmp DriveID ../sys/C/DriveID 
DriveID ../sys/C/DriveID differ: byte 6027, line 51

Oba plik DriveID ma 6052 bajty więc przekłamanie wystąpiło na 10 bajtach (wszystkie 0x20 zamiast oryginalnych 0x00)

Wracając do MD5, używam go do sprawdzenia poprawności kopiowania. Myślałem że lha przyda się do tego z uwagi na funkcjonalność sprawdzania integralności archiwów, ale jak widać na powyższym przykładzie zapis i odczyt był w porządku, musiało się coś stać z samym archiwum już wcześniej (te cztery archiwa to są tak naprawdę kopie tego samego pliku).

Jak sprawdzałem odczyt z CD zauważyłem że MD5Sum na pliku bezpośrednio na CD stwierdza poprawność odczytu, ale jak już skopiuje na dysk (PFS/3) ten sam MD5Sum pokazuje mismatch (względem md5 z płyty). To tylko dowodzi że sam odczyt z CD (podłączony jako slave do tego samego kanału co dysk docelowy - znowu FastATA) jest poprawny, ale najciekawsze jest to że już przeliczony przez ten sam MD5Sum md5 jest TAKI sam na pliku po zrzuceniu na dysk. Utworzyłem więc nowy plik .md5 z TAKĄ SAMĄ sumą kontrolną md5 i wtedy MD5Sum potwierdził poprawność tego pliku już na dysku. Albo coś jest nie tak z dyskiem, kontrolerem FastATA, albo MD5Sum (lista poprawek przez ostatni rok w ReleaseNotes dla MD5Sum jest dość długa - 46 zmian i poprawek).

Po dwu godzinach testów jednak nie jest tak różowo: raz MD5Sum daje poprawny wynik, a za innym razem inny. Tak samo md5 (md5) co raz to daje inny wynik. Mam podejrzenie że podłączenie jako slave na tym samym kanale powoduje jakieś problemy z odczytem na dysku (bardzo sporadyczne, ale jednak). Plik testowy ma pojemność ponad 735MB. Jutro kontynuacja testów: tym razem bez CD na tym samym kanale. Niestety jeden przebieg trwa przynajmniej 15 minut.

Mozliwe, ze to jest problem z transferem danych ale bardziej prawdopodobne z uszkodzona pamiecia. Ale ja nie uzywalem nowszych lhA niz 1.51 do pakowania i rozpakowywania plikow na Amidze bo mialy jakies bledy (juz nie pamietam jakie) moze potem je poprawili. Z tego co pamietam to lhA 1.51 na pewno przeskipowywal plik, ktory uwazal za uszkodzony. Uzywalem zwykle: lha x ram:* ram: z CLI. Byc moze inaczej rozpakowujesz. Ja czasami jeszcze przez lha e (jesli chcialem pojedynczy plik rozpakowac z archiwum). Do rozpakowywania dziwnych kompresji lhA uzywalem xad.library. Zawsze mozesz tez spakowac ten plik lzx lub zip.

Ostatnia aktualizacja: 26.12.2021 00:22:46 przez Don_Adan

Mozliwe, ze to jest problem z transferem danych ale bardziej prawdopodobne z uszkodzona pamiecia

Żeby sprawdzić tę () hipotezę, wrzuciłem do RAM: jakieś duże archiwum, żeby został niecały 1MB wolnego RAM (Fast), przeliczyłem md5 (MD5SUM file.lha TO=checksum.md5) i MD5Sum sprawdził już po raz setny poprawność (MD5Sum CHECK=checksum.md5). No chyba że problem jest z CHIP RAM?

Mogles uzyc "run NoFastMem", latwiejsze troche. Czasami sie zdarza, ze na jakims pliku paker/archiwizer sie wyburacza, bo czegos autor nie przewidzial. Tez tak mialem na jednym archiwum DMS, zawsze byl error (przy rozpakowaniu/testowaniu) jak bylo spakowane HEAVY. Zmienilem kompresje na slabsza i poszlo bez bledu. Zmien archiwizer na inny lub inna wersje lhA. Bo jak to blad w programie to nic raczej sam nie poprawisz. W lhA mozna chyba tylko ustawic bylo inna metode kompresji, np. brak kompresji tez.
A jak chcesz miec to wszystko koniecznie w jednym archiwum lhA to spakuj najpierw normalnie wszystkie pliki, ktore nie sa problematyczne. Przetestuj czy jest to archiwum ok. Skopiuj sobie to archiwum jako backup gdzies (przetestuj czy jest ok tez) . A potem za pomoca "lha a sciezkaInazwapliku" dodawaj ten plik do tego archiwum. Moze za, ktoryms razem zalapie, jesli to jest losowy blad. Mozesz tez uzyc tylko dla tego pliku innej kompresji lhA lub bez kompresji (store file) w ogole.

Lha pokazuje błąd zawsze na tym samym pliku "C/DriveID

Zrób kilka testów.
[*] zmień nazwę pliku na inny
[*] ten plik w ogóle nie dokładają do pakowania lha
[*] nazwij inny plik DriveID


Ostatnia aktualizacja: 26.12.2021 13:26:33 przez Norbert

Może zostałem trochę źle zrozumiany, bo opisuję sprawę na bieżąco, a zmienia się z godziny na godzinę:
Najpierw użyłem jakichś archiwów lha i funkcję lha do detekcji błędów, ale okazało się że pewniejszy jest MD5Sum, i od tej pory przeliczam wyłącznie md5.

Wracając do tematu. Skrypt który w kółko sprawdzał kilka dużych plików umieszczonych w RAM już powtórzył 350 razy, i nie wykazał żadnego błędu. Mogę chyba w takim razie wykluczyć błędy pamięci (przynajmniej FastRam).
Natomiast ciekawsza jest sprawa z dyskiem. Utworzyłem plik md5 na całym katalogu downloads (w sumie jakies 770MB plików zip, lha, lzx, tar.gz etc). Uruchomiony kilka pierwszych razów MD5Sum na pliku md5 wykazał błędy na kilku archiwach. W części okazało się że obliczył sumy które umieścił w pliku .md5 nieprawidłowo (dlatego musiałem ręcznie je w tym pliku poprawić), a w innych ponowne policzenie widocznie dało wynik odmienny - dlatego "mismatch". Co ciekawe, po tych pierwszych kilku razach z błędami, teraz już po raz 8 przechodzi bez błędu. Niestety za 9 razem pokazał "mismatch" dla jednego pliku:

15.Storage:> MD5Sum download TO=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
download/AmiSSL-4.11.lha: Checksum mismatch.
download/Executive.lha: Checksum mismatch.
download/amicygnix-base.lha: Checksum mismatch.
15.Storage:> MD5Sum CHECK=checksum.md5
download/m68k-base.tgz: Checksum mismatch.
download/sh-utils-bin.lha: Checksum mismatch.
download/ADE.lha: Checksum mismatch.
download/GG-Lite-bin-m68k.lha: Checksum mismatch.
15.Storage:> MD5Sum CHECK=checksum.md5
download/binutils-bin.lha: Checksum mismatch.
download/ADE.lha: Checksum mismatch.
download/ProfiPacketSrc.lha: Checksum mismatch.
download/AMIcast_Player.lha: Checksum mismatch.
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
do15.Storage:> MD5Sum download TO=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
download/checksum.md5: object not found
download/CommodoreAmigaApplicationsADF: Checksum mismatch.
download/CommodoreAmigaApplicationsADF.: Checksum mismatch.
download/HighGFXnmore.lha: Checksum mismatch.
download/hippoplayerupdate.lha: Checksum mismatch.
download/jpeglibrary.lha: Checksum mismatch.
download/lvl.pointers.lha: Checksum mismatch.
download/m68k-amigaos-ahiusr.lha: Checksum mismatch.
download/m68k-base.tgz: Checksum mismatch.
MD5SUM: ***Break
15.Storage:> MD5Sum CHECK=checksum.md5
download/AmiSSL-4.11.lha: Checksum mismatch.
download/Executive.lha: Checksum mismatch.
download/amicygnix-base.lha: Checksum mismatch.
15.Storage:> MD5Sum CHECK=checksum.md5
download/m68k-base.tgz: Checksum mismatch.
download/sh-utils-bin.lha: Checksum mismatch.
download/ADE.lha: Checksum mismatch.
download/GG-Lite-bin-m68k.lha: Checksum mismatch.
15.Storage:> MD5Sum CHECK=checksum.md5
download/binutils-bin.lha: Checksum mismatch.
download/ADE.lha: Checksum mismatch.
download/ProfiPacketSrc.lha: Checksum mismatch.
download/AMIcast_Player.lha: Checksum mismatch.
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
15.Storage:> MD5Sum CHECK=checksum.md5
download/AmiSSL-4.11.lha: Checksum mismatch.
                                  download/amicygnix-base.lha

Zaraz odłączę CD i sprawdzę czy dysk i CD nie kolidują ze sobą na wspólnym kanale ATA.

Jest jeszcze jedna możliwość: jakiś program gra sobie w kulki i pisze po pamięci.

A jaka masz pewność że program MD5Sum nie ma jakiegoś błędu ?
Przetestuj innym program tego typu.

Do testowania pamieci lepsze sa specjalne programy testujace pamiec niz MD5Sum. Mi to wyglada na problem z RAM-em. MD5Sum tez wczytuje do pamieci te pliki, wiec takie testy raczej niewiele Ci dadza. Ale jak chcesz tak robic to uzyj "run nofastmem" i wtedy testuj pliki czy sa ok. Zakladajac, ze masz troche wolnego chipu. Ogolnie w przypadku bledow w RAM-ie to dosc czesto sie zdarza, ze on na poczatku nie jest walniety calkowicie. Tylko np. przeklamuje jeden bit pod jakims adresem raz na 10 razy. Po pewnym czasie dopiero dzieje sie to czesciej i/lub dotyczy tez innych bitow. Ale oczywiscie moze byc tez blad odczytu danych z dysku (czyli problem dysku lub kontrolera), ale wtedy zwykle file system zglasza bledy odczytu a nie dopiero w ramie one wystepuja. Przynajmniej FFS zawsze mi najpierw zglaszal bledy jezeli HD mial jakies padajace blocki.

Edit, a co do programu smiecacego po pamieci to odpal bez s-s i wtedy testuj. Bledny program moze zasmiecac pamiec to jest nawet dosc czeste.

Ostatnia aktualizacja: 27.12.2021 03:19:11 przez Don_Adan

Wcześniej pisałem:

Albo coś jest nie tak z dyskiem, kontrolerem FastATA, albo MD5Sum (lista poprawek przez ostatni rok w ReleaseNotes dla MD5Sum jest dość długa - 46 zmian i poprawek).

Testowałem md5 na kilku plikach. Jest wolniejszy i dał takie same wyniki, natomiast nie daje możliwości sprawdzenia poprawności przez podanie na wejściu pliku z sumami i nazwami plików do sprawdzenia.
md5sum2 już próbowałem - guru.
Jest jeszcze md5sum z 1993 roku. Nie sprawdzałem go jeszcze tak długo jak ten dołączony do OS321. Obsługuje pliki .md5 więc łatwo można sprawdzać dużą liczbę plików.

Zastanawia mnie natomiast jedna sprawa, skoro miałby to być problem z pamięcią, dlaczego objawia się tylko przy sprawdzaniu plików z dysku, a nie z CD, a już po bardzo długim przetestowaniu nie było błędu jak miałem pliki umieszczone właśnie w RAM:.

Takie objawy wskazywałyby na problem raczej z dyskiem, kontrolerem, albo kombinacją z CD-rom'em.
Dysk to WDC 250GB, podłączony na 20cm kablu 2.5" (44 piny - primary na FastATA), a CD Samsung SC-148A, podłączony zwykłym 80 przewodowym IDE (podłączone do drugiego gniazda primary na FastATA).

Bo to moga byc po prostu inne obszary pamieci, w zaleznosci z czego akurat korzystasz. Najprawdopodobniej masz gdzies w pamieci jeden bajt (komorke?), ktory pada, ale czasami jeszcze dziala ok. Najprosciej jest zmienic SIMM na inny i wtedy sprawdzic czy to jest problem padajacego SIMMa albo uzyc program testujacy pamiec (pare razy). Mozesz tez sie bawic:
1. Jesli to sa 2 SIMMy w karcie to zamienic je miejscami.
2. Zapelnic polowe pamieci jakimis danymi i sprawdzic czy sa problemy. Jak nie ma to w zapelnic druga polowe pamieci, a pierwsza zwolnic i testowac/szukac.
3. Mozesz tez uzyc AllocAbs z exeka do testow i wylaczac (alokowac) poszczegolne obszary pamieci az znajdziesz slabowity obszar.

Zalezy co lubisz.
Moze to byc tez jakis problem z HD czy kontrolerem, ale raczej watpie.

Czy Diagrom wykryje tego typu błędy?

Nie wiem tego na pewno, ale chyba nie. Na Aminecie sa jakies programy do testowania pamieci, ale nie wiem na ile dobre.
Tutaj tez sa jakies wymienione i chyba jeden zadzialal jak nalezy, wiec jego bym uzyl na poczatek.

link

Ten program to Advanced Amiga Analyzer v2.00. Test pamięci przeszedł już 10 raz bez błędów.
Znalazłem też na aminecie trzy inne memtest-y i one też nic nie wykazały.
memcheck też nic nie wykryły.

Ostatnia aktualizacja: 27.12.2021 21:28:52 przez sq7bti

To nie wiem, to moze rzeczywiscie jakis problem z HD lub kontrolerem? Albo z jakichs powodow teraz ta pamiec dziala ok. Mozesz jeszcze sprobowac zapelnic polowe RAM-u jakimis danymi i meczyc te lhA czy beda te bledy. Bo najprawdopodobniej problem dotyczy pierwszej polowy fastu.

Te testy które robię trwają długo, więc dziękuje za cierpliwość.
Chyba znalazłem główną przyczynę problemów: wyczyściłem i poprawiłem piny w nakładce na Gayle'a. Od tego czasu wszystkie pliki które testuje dają powtarzalne sumy MD5. Nie ważne czy niepoprawnie skopiowane przed czyszczeniem, czy po, zawsze powtarzalne.
ehhhhh te kanapki ;)