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

Hello dear AOS4 betatesters:


Would like to use this official AOS4 feedback forum to report a problem and show an example of working communication between betatesters and simply user like me


Please take this information and fill a bugreport on bugzilla for this problem:

- SAM440ep and AOS4.1U2.
- USB key FAT32 16go OCZ, with a just 1 drawer with 10 files on the drawer and just one file on the root (mean empty at 98%).

I launch memguard and launch, with dopus4, a copy from the HD to the USB key, factory formatted in FAT, with just one file to be copied on the key. The size of the file is 350mo.

dopus4 copy well the file untill maybe 50% and a memguard hit appeared.

the USB recognize again the key and and aos4 show me a read error on block xxx.

cancel and USB recognize again the key and aos4 show me a read error on block xxx.

and so on but by chance at a moment, I was able to save the memguard output.


Please, please, fill the bugzilla with this information. this error exist with AOS4 and AOS4.1U1 and with AOS4.1U2.
You have understand that this error is not new for me because encountered more than one time.


I would like also to said that this copy error appeared maybe because memguard is running but It's well OHCI pointed by memguard.


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

MEMGUARD HIT - "OHCI Controller Task Unit 0" (5fe5a070)
allocation of 8192 bytes by AllocVecTagList() failed
0: 6f611be4 5fe3ad90 00000000 01ca97c4 00002000 5fe3ae18 59cb2c58 59563048
8: 00002000 00000008 01ca97c4 0000207f 24000082 00000000 00000000 00000000
16: 00000000 00000001 59563048 5a5ecb50 5fe23680 00002000 01e70000 5ff9fb40
24: 00000000 00000040 59c749a8 5fe954c8 00000000 00000040 00000002 00000003
----> 6f611be4 : "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 6f611be4 : "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

MEMGUARD HIT - "OHCI Controller Task Unit 0" (5fe5a070)
allocation of 16384 bytes by AllocVecTagList() failed
0: 6f611be4 5fe3ad90 00000000 01ca97c4 00004000 5fe3ae18 58f6dea8 59030040
8: 00004000 00000008 01ca97c4 0000407f 24000088 00000000 00000000 00000000
16: 00000000 00000000 59030040 5a1550c0 5fe23700 00004000 01e70000 5ff9fb40
24: 00000000 00000040 59c749d8 5fe954c8 00000000 00000040 00000081 00000003
----> 6f611be4 : "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 6f611be4 : "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



Hum, I'm also interested if one betatesters could confirm to me when this error will appeared on the bugzilla. thanks in advance.

@Mrodfr

Had it too but I have no crash like you.

Anyway, this bug was already reported on OS4 Bugzilla.
I'm now adding more information to it.

Thanks for the detailed report.

@Mrodfr

Those reports don't show any problem with the USB system. They only show that it tried to get some memory from the Exec and the request failed. There may be a problem <i>after</i> that, if the USB system didn't handle the error properly, but there is no indication of any problem in what you have shown.

The reason that the attempted allocation failed could be that the USB system asked for a particular type of memory and the kernel was unable to provide it. For all we know, the USB system then made alternative requests that succeeded and proceeded normally.

@Elwood

Thanks for this problem on the AOS4 bugzilla, for adding my report and hope will be resolved soon.

@tonyw

For sure, your explanation of this problem should be near the thruth. Hope with elwood and my report, this problem will be sorted soon...

With a grim repear running not often and with only memguard, It's hard to have good problems report on the AOS4. More easy with muforce/muguardianangels on 68K.

@tonyw

Still, we all know USB is very buggy and unstable. Being CrashDOSfilesystem, the USB stack, USB drivers or simply the A1 hardware that fails to deliver the bits it is given is not something I can answer, nor can this memguard hit apparently.

Adding to this I can say that I have never seen any problem (no corruption, no lockup, no crash) when copying from any USB device. But almost everytime when I copy to (or delete files on) for example an MP3 player or USB stick I either get a lockup after a number of MB, or a corrupted file system on the USB device (sometimes only detectable on a PC with chkdsk).

I sincerely hope it is a hardware problem of the A1 because that means it will be gone when I get the X1000.

@Deniil

Well, i get the same problems on my A1 and my SAM so it's not a A1 hardware bug.

Does this Memguard hit happen if NOT using DOpus 4?

Try copying the same file with the DOS Copy command, for example.

Simon

Dunno will it make sense or not, but i all the time copy+move to / from (by latest dopus4) my 4gb stick on peg2 (and memguard all the time on backgorund with sashimi), and have no errors. Still, i not copy gygabates, just about 50-100mb at time or less.

@Rigo

Quote:

For my side, the problem arrive allways with dopus4 because I copy allways with dopus4.

On the other side, all informations on the memguard aren't related to dopus4...

elwood have filled a bugzilla for this one because he has also encountered the problem...

@Mrodfr

I'm trying to establish whether the problem is in the USB components or in DOpus4.

The way to find out is to perform the same task in a different way, and see if the bug changes or disappears. If the bug turns out to be in DOpus4, someone will have wasted time to ascertain that, when it should be the job of the person reporting the bug to see how reproducible it is.

Simon

@Rigo

Quote:

there aren't mention to dopus4 on the memguard or memguard could give wrong informations ???

too bad that DSI not catch this kind of problems (memory allocation problems)



thanks for taking a look on this problem. for me It's an old problem and I have much decreased to use of USB and AOS4 with FAT32 problems.

I think also this problem came from big usb keys like 16go.

Hum, and again, It's allways with FAT32 medias...


- also my 1go key is initialized verry quickly with AOS4.
my 16go one need 6-8 seconds to be initialized (with USB....NDOS in the name of the key).

- copying on the 16go with dopus4 finished (progress bar) and maybe 10 seconds the key led flicker before finishing really the copy). Verry dangerous if a user remove before (make a RW error- tested).


- AOS4 need security on the DOS for this kind of medias and filesystem IMHO.


Yes, this is my remarks about USB on AOS4 in one answer

@Mrodfr

Memguard catches memory boundary mishits, but the output from it is not so useful. Rather than relying on it's output, and posting on forums, it would have taken less time to try it with "copy" than for both of us to waste time writing here.

If you want the problem investigated, then please try the test, otherwise it will get ignored simply because the test involves programs (and code) outside of the OS4 developers domain. The perfect test case is using OS components only, and if the problem persists, it can be investigated fully, without the need to download MB's of source code that none of us is familiar with.

Simon

Sadly , but i cant reproduce the problem on my peg2. I have 4gb kingston stick, formatted as FAT, and do copy by dopus4 from SFS a 700mb file, and there is no HITS appears ..

@Mrodfr
You need just copy your big file, by AOS4s "copy" command from shell. I.e. go to shell, and type:

Quote:

If HIT will appears again, then its not Dopus4 related problem, but of AOS4 itself. If no HIT will appears, then that will be problem of Dopus4.

Btw, copy to USB are madness slow. From: are good, to: slow in 5-10 times.

@Rigo

I used to make scripts when I needed to copy a lot of files (like filling my MP3 player with music) and run that script in a shell using the normal Copy command. This way I could easily restart when it locked up, and it always locked up, usually many times before I filled that 1GB memory...

So, no it's not a DOpus problem, sorry. I know you'd like it to be, but it's not. I'm pretty confident it is a CrashDOSfilesystem bug, but can't be certain. I'd like to format a USB stick with SFS and try to reproduce but I have no spare stick.

@Mrodfr

Here is an easy way to test the copy on USB.
Write a script like this:

--
set num 0
set source SYS:
set destination USB0:

lab begin

set num `eval $num + 1`
echo Iteration $num, delete: >>sys:testusb.log
delete $destination#? ALL QUIET FORCE *>>sys:testusb.log
echo Error: $RC >>sys:testusb.log

echo Copy: >>sys:testusb.log
copy $source#? ALL QUIET $destination *>>sys:testusb.log
echo Error: $RC >>sys:testusb.log

skip back begin
--

Run this and let it run for some hours. Then check the testusb.log file

Here on a FAT32 formated USB key I had a "seek failure" error and various errors on the key (files with wrong size...)
On a FFS2 formated key, I had no error in 10 iterations.

Try to do the same test...


I'll do more tests myself and report accordingly on OS4 bugzilla.

@Deniil

Quote:

While I obviously would prefer there not to be a bug at all, if a bug does exist, it needs to be established where. Hearsay is not enough to find and fix bugs, proof is.

If the bug is in CrossDOSFileSystem, then there's only one person that can fix it. But before that, the bug needs to be established, proven and reproducible. This applies wherever the bug might be, otherwise it cannot be found.

Simon

deleted after second thoughts...

@Elwood

Quote:

OK, I will do the test when I will have some free time and report back.

I have just launched the script and the script try to copy something (I haven't inserted an USB media). What the script copy ????

I think it's CrossDOS.

Today i copied some movies from my PS3 to my A1 using a USB-Stick and something in OS4.1 Update 2 changed (during a read access!) a 250 MB mp4 movie in a 512 Byte file that looks like a part of a PNG image with some random junk before the PNG magic number.

@Rigo

this is my famous (hum, just for me), thread about my bad luck with AOS4 and USB FAT32 medias (with details and pictures)

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