Memguard Hit when copying on USB key on AOS4.1U2.

@kas1e, modfr:

The original bug report described the corruption of FAT32 USB media. It was also reported by some people that a USB stick formatted as FFS also showed problems. That bug has been fixed, I can now dump large numbers of files with long names etc to a USB stick formatted as FAT32 or FFS with no problems on the A1 (UHCI) or the Sam (EHCI). I haven't tried formatting a USB stick with SFS or JXFS.

I don't know about the Memguard report - it's not a crash or a fault, it's only a warning message and probably means nothing bad.

@tonyw
But imho our problem and bugs there, is about "copy big file", and bug not only show us memguard hits, but also refuse to work OCHI stuff at all, with ellow window errors and alt.

Anyway, looks like we need to wait next update, and then we will see was it fixed or not ..

@tonyw

Quote:

Thanks for your work and the work of the AOS4 developper team about this verry annoying problem. greatly appreciated (that mean you betatest AOS4

Please make the same tests with memguard enabled during the copy of big files (200-400 or more Mo).

when memguard arrive, the usbstack reset during the copy (with requester who describe error during the copy and the USB media icon diseapeared and reappeared on the workbench) and mathematically corrupt the data copied on the USB medias.

If you need to know more about the memguard hit, please ask us...

@tonyw

Great to hear that is finally got fixed!

As I've stated before, I rather live with a slow but correct USB than a fast (or slow) broken one

Can you give some detail of the bug/fix? Was it a simple (or not) screwup with a table of blocks or something much more complex? Just curious since it took a while to get it acknowledge and fixed..

@Deniil

Don't know, I'm not involved with that component.

@tonyw

Thanks a lot for informing us that the FAT32 crash (maybe FFS, SFS too), when copying datas on USB medias, and give as result 8+3 filename, has been resolved.


No news for the memguard hit during the copy....


The crash with 8+3 filename as result is finally, resolved, since..... days, weeks and maybe...... months........ ????????


The goal of this special AOS4 feedback thread is for the users to post when problem found look like related to the AOS4 istelf.......

AND

The goal of this special AOS4 feedback thread is also for the AOS4 developpers to inform us if the problems, reported on this AOS4 feedback thread, has been resolved or not by the AOS4 developpers.


That mean normal users could stop looking at the problem and do other things for the amiga than continue to investigate an AOS4 problem allready resolved !!!!!!!!

@tonyw

Here this problem is not fixed: writing on FAT32 USB key.

I am right now doing this test again. I use this script:

set num 0
set source SYS:
set destination USB0:

lab begin

set num `eval $num + 1`
echo Iteration $num, "delete all":

delete $destination#? ALL FORCE
echo Error: $RC

ask Press return...

echo Copy all:

copy $source#? ALL $destination
echo Error: $RC

ask Press return...

skip back begin



When I do it with a FAT32 USB disk, the copy stops with an "seek failure".
With a FFS2 USB disk, it is still running right now. 3 iterations without problem.

@Elwood

Don't know what is a seek failure but run your test with memguard enabled (story to see if the memguard I report often - post #1 - is also allways present).

Thanks for testing this problem (I can't do that myself and you know why

@Elwood

Are you a beta-tester with access to the fixed USB driver/thingy? If not, we will of course have to wait until the next OS4 update.

If you are a beta tester and you can still reproduce some kind of bug, even if not exactly the same, it means I'm right and CrashDOSfilesystem does have a bug too.

Still, better with one bug down than none

@Deniil

I am a betatester.

Also please call it "Cross"Dos..... or the author may not want to fix it


@mrodfr

No hit with Memguard.
Still looking into it.

@Elwood

Can you try please to copy any file about 500mb of size from USB to hdd ? (some ISO will be good). I describe the bug on the page 3, but dunno was it fixed or not. While you check it, maybe you can also try to reproduce that bug as well ?

@kas1e

Confirmed.
The result is many files garbled on the USB disk.

@Elwood

Hm.. My problem happens exactly when copy from (not to) usb stick, and not many files of different size, but one file of big size (problems start to happens after coping of 300-400mb of the same file). Small files copies to/from fine.

Quote:

@elwood

theoricaly, the memguard hit appeared for this case.

@Mrodfr

So this hit may have been fixed in the meanwhile...

@Elwood

I did some exhaustive testing last night but I won't go into all the results here. Let's just say that you are right, it still plays up, but when I signed off the bug back in March, I had tested it as fixed.

I found that it all depends on how the USB stick was formatted.

If I Quick format the USB stick on a PC, then plug it into the A1 or the Sam, it works perfectly, no corrupted files at all. If I Quick format the stick on the A1 or the Sam, it will fail and corrupt files when writing.

Perhaps some of the others interested in this thread could try the same trick using the Update2 components. Does it still fail if you format the stick on a PC first? (Just a Quick format, even that is slow enough)

@tonyw

Quote:

This is not impossible. Also people said that It's better to formatting FAT32 on the PC than on FAT. It's necessary to do that for hardrives (compatibility problems) and not surely for USB stick also.

@tonyw , elwood

Trying to write few times in that thread for you, but still not understand did you check that or not :) If you format stick on PC, in fat32, and then trying to copy FROM stick to any partition on AOS4 a one big file of 500mb of size , did you have any problems or not ? For me with update2 ,i cant copy for example quake2.iso. On 300-400mb of coping i have ellow alerts, errors and memguard hits. And i should reconnect my stick/reboot.

@kas1e

Now copying a 470 MB file onto the USB stick (on the PC) to try it.

I'll let you know...

@kas1e

I found a 450 MB VOB file on a DVD and used the PC laptop to copy it onto a newly-formatted 8 GB USB stick.
The Write operation took about 10 minutes on the PC (I didn't time it).
The Read operation took:
(1) on the A1, using USB1, 8:26.
(2) on the Sam, using USB2, 1:03.

Both Read operations completed without any errors and gave the same md5sum as the original file.

(edit)
The PC is old and has only USB1 ports.
(/edit)