usb 16go key copy problem on SAM and AOS4.1 U1 (now)

@ZeroG

The key has been formated as FAT32 with AOS4.1. Take now a verry long time to be initialized by AOS (key led flicker during a long time).

after formating by AOS4:
L:crossdodfilesystem (FAT2)
used: 9.3 go (62%)
free: 5.6 fo (38%)
size: 14.9 go
block:512 octets

A verry strange formated result by OS4. This key work without problems with a PC usually. It's why I have the problem to said It's a faulty Key and must be remplaced because no problems on a PC (key used often at job or on the classic+spider2).

I think I will full this key with the classic+spider2 for checking where came the problem

to be continued....

@all

Just for resurrected an old thread (but just related to USB and SAM).

Sometime copy USB stop strangely. This time a memguard hits when copying a file to a Memory stick adaptator.

The hit came and dopus4 PPC stop to copy. just reboot the SAM.

SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()

MEMGUARD HIT - "OHCI Controller Task Unit 0" (5fe9a010)
allocation of 32768 bytes by AllocVecTagList() failed
0: 6f8c2be4 5fe86e00 00000000 01c997c4 00008000 5fe86e88 80000005 80000003
8: 80000002 00000008 80000001 ffffff80 80000004 00000000 00000000 00000001
16: 4b421148 01e70000 5fe6b680 00008000 5ff99200 01e70000 ffffff0e 00000040
24: 4af6c508 00000003 00000000 00000000 00000040 00000001 00000001 00000080
----> 6f8c2be4 : "MemGuard" segment 0005 offset 8bdc
----> 01c997c4 : "Kickstart/kernel" segment 0001 offset 497c0
LR 01413690 : "Kickstart/kernel" segment 0000 offset 1368c
CTR 6f8c2be4 : "MemGuard" segment 0005 offset 8bdc

Stack backtrace:
----> 01413690 : "Kickstart/kernel" segment 0000 offset 1368c
----> 018b29dc : "Kickstart/ohci.usbhcd" segment 0000 offset 3bb8
----> 018b178c : "Kickstart/ohci.usbhcd" segment 0000 offset 2968
----> 018b5674 : "Kickstart/ohci.usbhcd" segment 0000 offset 6850
----> 018b59f8 : "Kickstart/ohci.usbhcd" segment 0000 offset 6bd4
----> 018b4508 : "Kickstart/ohci.usbhcd" segment 0000 offset 56e4
----> 0141581c : "Kickstart/kernel" segment 0000 offset 15818

Disassembly:
0141368c: 4e800421 bctrl
01413690: 80010084 lwz r0,132(r1)
01413694: 38210080 addi r1,r1,128
01413698: 7c0803a6 mtlr r0
0141369c: 4e800020 blr


It's just because I don't know how reporting this problem to AOS4 developpers. Hope one of them will see this post.


EDIT: Why allocated just little 32768 bytes for buffer (IMHO). We have 512mo of memory, or more

@ZeroG
Quote:
I know two things.
1. OS4 Dopus4 link handling is broken. Use Drag'n'Drop on WorkBench to make large copies that may have links. AsynWB seems to handle links and large copies with nested directories much better than Dopus4.
2. Copying Amiga files to a Fat32 formatted device of any kind is problematic. Amiga file names can contain characters that are illegal in Fat32. I only copy individual files (one at a time) for a Fat32 formatted USB stick, which works. I have formatted my 16GB USB memory sticks with SFS filesystem and can Drag'n'Drop entire partitions to the USB stick with no problems. Such copies seem to take forever because of USB1 speeds but nevertheless it works.

@xenic

Quote:

Do you know the illegal caracters...

BTW, no problem at all with poseidon/AOS3.x.

@all

Hum, I like this particular personnal thread, just for the USB problems I could have.

On my OCZ rally, I have copied AOS4.1 inside long time ago. one week ago, I have choosen to delete the copy located on the OCZ rally key, on the SAM. All have been well deleted but only:

DH1:utilities/sgrab/catalogs/aeeetina

hasn't been deleted (the path just with 0 size but on the key).

Ok. Some days ago, I have tried to use the key on a PC at job and the key has not been recognized on the PC.

This morning, I have used poseidon on the classic and the key work fine. try to play with aeetina (try to delete or rename or other things without luck). I have also copied some picture I have on the key safely on the classic (the only one who continue to recognize the key well).

OK, I have after copied one file on the key and... strangely, the name become 8+3.

hum, refresh the key content with dopus and all the key contend become 8+3 and with strange size. Again another time.

All this explanation to say that I have found that on sgrab, the langae aeeetina drawer (of course, sould be witten with the exact caracters langage) could lost you the content of your fat95 medias on particular conditions.

This time, the problem began on SAM, media not work on PC and finally, I have killed the usb content with the classic+poseidon

just for your information, be carefull with strange caracters on your SAM files installation.... could be destructed if copied on fat medias...

Bye.

@Mrodfr

Dont forget that all your data is going through crossdos which is not the most reliable program I've ever used. I don't know how well it handles soft links.

For a quick solution to your backup problem I suggest using AmiDVD to create an iso image and copy the single file to the usb stick. You can then use diskimage to mount it directly from the usb stick to access any files you need.

@Severin

At least, he not like: ?e?tina drawer on sys:utilities/sgrab (but as you could see on this whole thread, this ?e?tina arrive just now).

Do wee keep the crossDOSfilesystem as ever on the AOS4.x ???

FAT95 on 68k, even if chris hodges said he has problems, if for me a lot more reliable on AOS3.x than crossDOS on OAS4.x !!

QUestion:

- CrossDOSfilesystem has been improved a lot for AOS4.1.1 (please AOS4 betatesters, answer this question) ???

If not A bounty is urgently required to have good FAT support on the Amiga IMHO.

This is a point I will quicky talk again after AOS4.1.1 release..........

@Mrodfr

It was said several times on other topics the crossdosfilesystem bugs have been fixed. So i really hope copying files to usb will not corrupt with the os4 update.

@Kicko

Let's hope so,atleast for sam users. hehe

@All and kicko,

Have tested my brand new (return warranty) OCZ Rally2 16gb key with AOS4.1.1.


First was to copy all WB content to the key, as a first test. Choosing the wb content and the copy start fine. Some 100mo copied and suddenly a crash, catched by memguard:


MEMGUARD HIT - "OHCI Controller Task Unit 0" (5fe5a070)
allocation of 8192 bytes by AllocVecTagList() failed
0: 6f452be4 5fe3ad90 00000000 01ca97c4 00002000 5fe3ae18 5a1bd198 59af60a8
8: 00002000 00000008 01ca97c4 0000207f 24000082 00000000 00000000 00000000
16: 00000000 00000001 59af60a8 5a28b7b0 5fe23680 00002000 01e70000 5ff9fb40
24: 00000000 00000040 5a695668 5fe955b8 00000000 00000040 00000002 00000003
----> 6f452be4 : "MemGuard" segment 0005 offset 8bdc
----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
LR 014136f0 : "Kickstart/kernel" segment 0000 offset 136ec
CTR 6f452be4 : "MemGuard" segment 0005 offset 8bdc

Stack backtrace:
----> 014136f0 : "Kickstart/kernel" segment 0000 offset 136ec
----> 018c6dfc : "Kickstart/ohci.usbhcd" segment 0000 offset 5558
----> 018c45b4 : "Kickstart/ohci.usbhcd" segment 0000 offset 2d10
----> 018cb608 : "Kickstart/ohci.usbhcd" segment 0000 offset 9d64
----> 018cb788 : "Kickstart/ohci.usbhcd" segment 0000 offset 9ee4
----> 018c90b4 : "Kickstart/ohci.usbhcd" segment 0000 offset 7810
----> 0141587c : "Kickstart/kernel" segment 0000 offset 15878

Disassembly:
014136ec: 4e800421 bctrl
014136f0: 80010084 lwz r0,132(r1)
014136f4: 38210080 addi r1,r1,128
014136f8: 7c0803a6 mtlr r0
014136fc: 4e800020 blr

and after a requester said:

disk Rally2 has an error on block=298992.
error = 20
disk error


And I have seen and reported the same error on AOS4.1 version also(see post #22 before-look like the same), and allways on AOS4.1.1

A reboot and the key is allways recognized fine. great. I wil continue some tests soon.

NOTE 1:

Yes, catched by memguard and no by grim reaper and also sorry for not having the usb.log because as the error = 20 is showed on the requester and I have teied to open ram:=bad idea. next time will be to quit the error requester and try to open the Ram:

NOTE 2:

The USB copy become more and more slower with drawer like AISS / toolbarimages, with 3500+ small images inside. At the end of this drawer copy, a little bytes file take one second or two ???????

@Mrodfr

I just copied my whole OS4 installation on a FAT32 formated Kingston 2 GB key. The copy process works fine but when I plug the key on a PC, it says it's broken :-/

@Mrodfr

(I put this in another thread but it is more relevant here)

CrossDOSFilesystem was changed for v53, however this may not be entirely relevant as v53.1 on OS4.1 had the problem also.



It can be reverted back with the above switch. Unfortunately there's no way of setting CONTROL options for USB devices to see if this fixes the problem, that I know of.

It would be good if this and the other control options could be set in the CrossDOS commodity, as they could be quite useful regardless.

@Chris
I owned and updated the commercial CrossDOS for OS3 for years and the manual always suggested or warned that disks should be formatted with a real MS PC. With OS4.x I stick to single file copies to a single directory on USB memory sticks. Large copies (dragging a partition to the USB stick) seldom work properly for me with FAT formatted sticks. I formatted my 16GB USB memory sticks with SFS and use them for backup. There seems to be a speed difference depending on the stick size. My first 1GB stick was really fast. They seem to have gotten progressively slower as I bought bigger sizes (2GB, 4GB, 8GB etc.) It seems especially noticeable on the 16GB stick I've got. It seems really slow.

@Chris

Quote:

OK. V53.2 convert 8p3 names now with Windows-1252. Great to know that CrossDOS has been improved to try to resolving the FAT32 problem Kicko and I and another user have sometime and thanks for sharing with use this information.

@xenic

Quote:

All my USB hardware are really factory formated with a PC (untill now).

Quote:

What does that mean ?? you make a drawer on the USB key and copy all inside surely....

About the speed to copy to the 16gb USB key I have is when copy the 3500 small files inside AISS, the last one has been copied with verry verry slow speed (first one with correct speed).

Hyep, I just had a problem copying to my 16GB DataTraveller USB stick.

Before OS4.1 Update 1 I couldn't even copy data from FAT formatted USB sticks. Since 4.1u1 I have copied lots of large files from FAT USB sticks and an external HD without problems.

Tonight was probably the first time I risked writing a file to a FAT filesystem on USB, though. Just a small text file.

This was the contents of the original:




And this is the content of what ended up on my USB stick:




I got the "write error" requestor and I tried to RETRY a few times. I had to reboot because Workbench was frozen. I could move windows but I couldn't close any, and only the backdrops would redraw, not the contents.

The file above is what was on the USB stick after I rebooted.

The filename was OK. I haven't checked to see if the md5sums on the rest of the files on the stick are still OK.


I use an SFS-formatted USB stick for backing up Workbench and Work partitions and I haven't had a problem yet. That worked before 4.1u1, too.

@robo-ant

Hello and welcome to the club

Thanks for your report and another time the error located on 16GB medias.

What mean your before AOS4.1, FAT95 failed allways ??? I don't understand really the before and after AOS4.1U1 explanation.

As you have seen, there are problems with FAT95 medais on USB with AOS4.

- What look like the write error requester ???
- You copied things with a filemanager (dopus4) ???
- The USB reset during the copy (USB mouse and keyboard) ???

@Mrodfr

Quote:

FAT32 USB volumes used to get read errors for me, with the OS4.1 beta (SAM). It was dangerous to copy files _from_ a USB stick. Now with OS4.1u1 I have successfully copied many, and large, files from USB media, with no errors.

With either version of the OS, it seems dangerous to copy files _to_ a FAT32 USB device.

Note that the small file I copied last night was named simply "files.md5", so no special characters or long filenames were involved.

Quote:

Um, a normal system requester, I guess. I didn't pay that much attention to what it looked like, and I couldn't get a grab of it because Workbench was locked-up.

It said there was a write error on some block with a big number that I didn't write down.

Quote:

Nope. I dragged the file to the volume using Workbench.

Quote:

I don't know if USB reset during the copy. I have a SAM440EP so I have to use USB mouse and keyboard. The mouse was still working after the error. Workbench was locked-up and I didn't have anything I could type into, so I don't know if the keyboard was still working.

Also, I don't have any USB hubs connected, or anything like that. Apart from the mouse and keyboard, the USB stick was the only USB device connected to the SAM.

I use this same USB stick with Windows all the time, and occasionally with Linux, and I haven't experienced a problem with it on those operating systems.

@Mrodfr

Darnit! I just tripped over this again by accident!

I had a large directory of stuff on my 16GB DataTraveller USB stick. I copied it to my Sam's HD. I didn't like the name, so I renamed... the wrong one! I accidentally renamed the one on the USB stick.

The result: The direcory disappeared! But the space on the stick was not freed. So it was not deleted, just the directory entry was lost.

Good thing I had a copy.

I copied the rest of what I wanted saved to my Sam, and then reformatted the stick on a WinXP box.

I wish this stick had a write-protect tab that I could set before plugging it into my Sam!

BTW, I have been using a FAT formatted 16MB (yes, megabyte) CompactFlash card to xfer files back to the Windows box, and that has worked so far. Maybe this really is some issue with media size.

@robo-ant

Hum, interesting. I have also my 16GB USB stick who have caused problems before. I will try to do your test...

BTW, there are differents clusters for FAT32. As ly key is a speedy one, maybe with big clusters... BTW, the crash when renaming your Key isn't related to clusters.