@ALL So, first time i catch that bug too. I trying to copy right now 700mb file, and something on 70% i have Ellow alert, with words "Babble detected on USB unit 0. USB controller will be reset!" Then Disk Error ! window with words: Bad read Disk block 6,209,624 Error = 20 Device Error
Then retry or change make no sense, it always spawn that ellow window with words Babble detected, and device all the time recognized/unrecognized in loop.
And the same recognize/unrecognize in loop. That is was agan copy to SFS0. Will try right now copy to SFS2 and to JFS (to see, will it make sense or not).
I do clear reformat of my FAT32 stick, write here only quake2.bin. Then , put stick to the my peg2 , then do in shell copy quake2.bin work:quake2.bin (work are SFS2 1.286). And have absolutly the same error with Ellow window, with recognize/unrecognize in loops, and again, on the same 388mb of copy. And memguard HIT looks again the same. If it will make any sense, my version of CrossDOSFileSystem - 53.3
If you want, i can do any other tests which will help you out to found the problem.
And on 388mb of copy, i have again ellow error with the same words, and the MemGuard HIT again coming:
snip
And the same recognize/unrecognize in loop. That is was agan copy to SFS0. Will try right now copy to SFS2 and to JFS (to see, will it make sense or not).
did you rebooted after that first Dopus4 copy attempt?
Of course. And not one time, and not only soft, but also hard reset (still, not cold power off /power on). If that make sense, i can try after power off.
@Framiga I test it after very cold power-off / power-on for now: the same problems, exactly on the same place of file, with exactly the same Ellow window, memguard HIT, and recognize/unrecognize in loop.
So, bug is cleary reproducable, and not because of dopus4 100% (i just not run it at all for now). Just power-on, newcli, copy from stick to parition, and only run OWB in which surf the net.
kas1e wrote: @Framiga I test it after very cold power-off / power-on for now: the same problems, exactly on the same place of file, with exactly the same Ellow window, memguard HIT, and recognize/unrecognize in loop.
So, bug is cleary reproducable, and not because of dopus4 100% (i just not run it at all for now). Just power-on, newcli, copy from stick to parition, and only run OWB in which surf the net.
sorry if i have asked about the reboot thing. (i was sure you did).
Now we need Rigo here, so maybe he can give for us some hints or debug versions of some stuff, which we can test and found exactly problem. Because even for now its imho not clear why it happenes. I just lucky can reproduce it on the same place, but looks like that i am only one for who it happenes at the same way and all the time.
That all a bit strange, because back in times (when i have aos4.1 and aos4.1 update 1 if i remember right), i copy some PSX games to aos4 (for example Tekken3, which are 500mb of size), from the same stick, on the same partition. And everything was fine.
Maybe, problem happens only on some "sequences" of data. Like many 00 in file, or many other characters, and on some stage, it cause a bug .. But imho then it should cause just error on read/write, but there is just controller resets. Which make me think, that maybe usb driver itself, be resident in memory, fucked by some reasons by system itself ..
For testing purposes, i will create today/tommorow an empty file full of zeros about 500-600-700mb of size, and will try to copy it.
- could you make one of your previous tests (fat32 or sfs copy with dopus4 or copy itself) but without memguard running ????
as you have allways the problem, when the copy of your quake.bin arrive at 3xx mo, the USB driver should theorically just reset by itself. (It's just to remove the memguard program from the list).
- as you have allready make some copy without problems, do you have changed your USB hardware since ???
It's just another memguard only hit that not help at all to found the problem
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
This should fail randomly. Perhaps if ithe machine doesn't lockup I can get something from it. After any such failure, chkdsk E: on a PC usually complains about crosslinked files and stuff. chkdsk can fix it with /f. No need to reformat (so far).
My theory if that if a crosslink happens in a directory entry (or the FAT table?) we get garbage as filenames.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
This should fail randomly. Perhaps if ithe machine doesn't lockup I can get something from it. After any such failure, chkdsk E: on a PC usually complains about crosslinked files and stuff. chkdsk can fix it with /f. No need to reformat (so far).
My theory if that if a crosslink happens in a directory entry (or the FAT table?) we get garbage as filenames.
Interesting theory....
How can I check if I have crosslink (softlink ??) on my HD ?????
NOTE: I don't really know what is crosslink. Made with makelink ??? and how removing them ???
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
@Mrodfr I believe a "crosslink" is two files sharing the same block(s), so one file incorrectly contains data from another file. You need a FAT disk-check utility to find & remove them; at least one of the fixed files will still be corrupted, but at least won't be prone to further corrupton. Windows has (IMHO) the best FAT disk-check utility, while AmigaOS may not even have one (and probably not very good even if it exists).
My theory if that if a crosslink happens in a directory entry (or the FAT table?) we get garbage as filenames.
You are probably quite right. However, the fault has been fixed, and it wasn't anything to do with CrossDOS, so there's no point in chasing more evidence.
As for the Memguard "hit", it wasn't a fault, it was only a "failure" return value from an Exec call. What the calling program did with that return value, we don't know. Since no other fault was trapped, it probably took some successful recovery action.
tonyw wrote: You are probably quite right. However, the fault has been fixed, and it wasn't anything to do with CrossDOS, so there's no point in chasing more evidence.
Do you state, as maybe an AOS4 developper or tester, that the FAT32 destroyed datas who become 8+3 filename has been now complelely resolved ????
Quote:
As for the Memguard "hit", it wasn't a fault, it was only a "failure" return value from an Exec call. What the calling program did with that return value, we don't know. Since no other fault was trapped, it probably took some successful recovery action.
Could you explain more here also ???
I said that because the memguard hit stop the copy on the FAT32 medias and also reset the USB stack and the result is a FAT32 media datas problem or worse a 8+3 filename.
As the 2 problems are surely linked together, I really will be sure that all are resolved. That mean for us just wait another AOS4.1 update
Also a question:
the resolved version of this problem has been tested with FAT32, SFS, JXFS filesystem (as kas1e has been able to reproduce the problem on all filesystems).
Sorry for asking again like that but this problem is really really really dangerous and cause datas loss. I woul dlike to be 200% really sure that all the problems (8+3 filename and memguard hit) has been resolved.
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
