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

@tonyw

- I have formatted my OCZ 16go key with XP, at job, this midday.
- I boot the SAM and launch dopus4 and copy a 850mo files from the amiga to the USB key.

the copy run a little and the memguard hit.

- If I use retry or cancel, a new memguard hit came and the USB stack restart, (as if I have just inserted the key).

- If I use cancel, finally a requester said:
the integrity of the copy is damaged, continue at your own risk (or something like that).

A grab at the start of the problem:




Please notice:

- I use a 16go USB key.
- fresh formated FAT32 with a PC at job.
- Just copy one file with the amiga on (file 850mo).
- This memguard hit is important and mean something because it reset the USB stack (or reset the OCZ media only).


USB problems with FAT32:

1. Use my OCZ 16go key for copy some small files (like the workbench) and an error occured and datas on the key become 8+3 with crazy high size

http://www.amigans.net/modules/newbb/ ... =ASC&type=&mode=0&start=0

2. Use my OCZ 16go key for copy one big file, and this thread about the memguard hit.

TonyW, could you make some tests with a big size USB media ??? (It's more easy for you because you test USB2).


I have a PS2->USB adapter with a PS2 keyboard and a standard 3 boutons USB mouse logithech. All work fine and no problems.



EDIT: another test:

I have just baught a 500go 2.5" USB2+esatap external Harddrive.

Just Trying to fomat to FAT32 with the SAM (after waiting long minuts because USB1) and:



A new memguard hit, same as previously but with 16384 this time (with the HD).

Don't know but... earing about cluster 8ko and 16ko for FAT32 ???


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

MEMGUARD HIT - "OHCI Controller Task Unit 1" (59a84130)
allocation of 16384 bytes by AllocVecTagList() failed
0: 6f4fbbe4 59a4ed90 00000000 01ca97c4 00004000 59a4ee18 5b787e38 5cd5a000
8: 00004000 00000008 01ca97c4 0000407f 24000088 00000000 00000000 00000000
16: 00000000 00000000 5cd5a000 59c75970 59a37680 00004000 01e70000 5ff9a8c0
24: 00000000 00000040 59a50a88 59ac1e30 00000000 00000040 00000081 00000003
----> 6f4fbbe4 : "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 6f4fbbe4 : "MemGuard" segment 0005 offset 8bdc

Stack backtrace:
----> 014136f0 : "Kickstart/kernel" segment 0000 offset 136ec
----> 018c7abc : "Kickstart/ohci.usbhcd" segment 0000 offset 5558
----> 018c5274 : "Kickstart/ohci.usbhcd" segment 0000 offset 2d10
----> 018cc2c8 : "Kickstart/ohci.usbhcd" segment 0000 offset 9d64
----> 018cc448 : "Kickstart/ohci.usbhcd" segment 0000 offset 9ee4
----> 018c9d74 : "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

@Mrodfr

I'm not going to speculate on why it fails for you, other than to repeat that I am using the latest betatest components. There *might* be a SW bug that has been fixed in my versions, DOpus4 may be causing problems, or your hardware *might* have some problem(s) that cause problems for you.

@Mrodfr

Can I add that if you are doing the kind of things described in this other thread (that I told you wasn't recommended) your problem might be caused by your system configuration.
Can you try the same tests cold booting from the AOS 4.1 (I insist on the cold booting because if you replaced some of your kickstart modules by others older versions a simple software reboot won't be enough).

@abalaban

I haven't remplaced the ..... kernel debug kmod (don't remember the exact name) on my machine for debug101.

The test is made with a cold boot and just put the USB hardware, open dopus4 and start a copy. (This problem exist long before debug101 exist).


- I have just formatted my 1go USB key on the PC (at job) and will made the same test after the job (to check if 16go key cause the problem).
- I will made the test without keyboard and mouse plugged (to test if my USB hardware cause the problem).

@Mrodfr

Oops I forgot a word : Quote:...

@Mrodfr

Quote:
Do not use OS4 to format the key. Use a PC.
We are not sure that FAT32 support is correct so doing a format is ... too much

@all

I have copied the same file on my 1go USB stick (formatted on a PC), with Dopus4, without problems.

I will do the same test, with my 16go key FAT32 formatted on the PC, with the AOS4 copy command, this end of day.

I actually fill my 16go key with datas on the job's PC (for checking the media).


@Elwood

If formatting medias with FAT32 on the SAM should not be used, why is it possible to format FAT32 ???? (Remove this feature untill FAT32 will be well tested IMHO).

@Elwood
Quote:
If aos4 cant format FAT32 right then its bug which should be reported and fixed (imho). Saying "do not format on os4. use a PC" its a bit strange :)

@all

OCZ rally2 16go, formatted with FAT32 with a PC, this morning at job, and copy 3 times 16go on the rally2 with the PC (and format in FAT32 between) to be sure the media is fine (and effectively no problems on the PC).

On the SAM+AOS4.1U2:

TEST1:

copy a 850mo files on the USB rally2 key with a drag'n'drop icons.

The copy start fine but same problems.

See the 2 grabs.


8192 bytes:



16384 bytes + AsyncWB.



- The USB stack reset for the OCZ medias 3-4 times and during each reset, the memguard hit that mean this is USB the problem surely.

TEST2:

Just after the test1, I have made the same but only remove the AsyncWB tool (loading during the boot and managed with prefs/wbstartup).

I have drag'n'drop the same files and the copy work fine UNTILL THE END !!!!!!!!!!!!!!!!!! YEAH !!!


AsyncWB not running mean It's not possible to do other things during the copy with the Amiga but this first copy work fine !!!!!.


TEST3: (also without AsyncWB)

The same as TEST2 and this time use DOPUS4 and.... the copy work fine also !!!!

As the workbench run completely during the copy, (surfing at the same time of the copy), the fault is: AsyncWB !!!.


TEST4:

Let AsyncWB running, and just add NOASYNC (as a tooltype), and the copy work fine also.

TEST5:

Let AsyncWB running, and just add NOCOPY (as a tooltype), and the copy work fine also.


RESULT: AsynWB cause problems during the copy of datas on FAT32 medias. Add NOCOPY tooltype on asyncWB Tooltype solve the problem.

@all

Bump

@Mrodfr

I am working on reporting the issues (as a betatester).

I have determined that there are two remaining problems *with the current betatest files*. One of them is the FAT32 formatting, the other is SAM-specific (but we are working on it). Disabling ASyncWB has no effect here on either problem.

I can't make any more comments until the problems are resolved and we can tell you (for sure) that they are resolved.

Thank you for pointing out the original problem, I thought it was fixed until Elwood corrected me. However, investigating using the old Update2 components is not going to help fix the current components. I suggest you don't waste your time any further.

@tonyw

Quote:

Great!! (and lots of issues IMHO)

Quote:

This is really strange because with asyncWB disabled (or NOASYNC or NOCOPY), I have successfully copied 3 times a big file on a 16go FAT32 key (and I have never managed to copy one big file on a FAT32 16go USB key before).

Are you sure this fact not show another not known problems ??? (big files on big medias with FAT32,FS,FFS). Remember kas1e also report this problem on SFS and FFS.

I have planned to open a new thread on the AOS4 feedback thread about FAT32 (just for explaining my point of view about bad FAT32 on AOS4). IMHO FAT32 suffereing a lot of problems and another thread just for FAT32 will be usefull to manage.

Quote:

No problem, I'm sure now with elwood and you, this problem will be resolved for the next release

Quote:

FAT32 is important because for sharing datas between differents OS and for the credibility of AOS4.

IMHO Problems are:

- corrupted datas during copy on FAT32: 8+3 filename+ big size on the medias.
- Big datas copied give memguard on FFS,SFS,FAT32.
- FAT32 need to be verry improved.

Thanks Tonyw to said that I have been usefull for something. Thats great for me