Hyperion Entertainment Message Boards

1. Unpack the test tool (source also included).
2. Boot without startup-sequence.
3. Start the test tool.
4. Hit Ctrl-D to allocate memory until it runs out.
5. Hit Ctrl-D once more to make it swap.
6. Hit Ctrl-F until all memory has been freed.
7. Repeat step 4 and 5 once.
8. The machine locks up hard at step 5 so the reset button is the only choice.

This is repeatable for me every time.
If you quit the test tool after step 6, then redo the procedure, steps 3-6 it may take a few more runs until it locks up.

I have 512MB and one block (they are 20MB) "too much" is enough to repeat this. If you have a lot more memory, perhaps you need to make it swap out a little more to repeat this.

My SWAP: is 2GB and located at around 100GB on a 120GB IDE disk connected to a SII0680 in an A1-XE/G4.

Please acknowledge and try to fix this!

Any X1000/update5 users: Is this repeatable for you? Gues you need less than 2GB physical RAM to make use of the swap perhaps.

I guess most (all?) X1000 owners doesn't have SWAP: setup at all. The recommendation is that swap isn't needed if you have 2GB (or more) memory.

@Deniil

Affirmative.

OS4upd4
AOneXE - 1GB RAM - 1GB SWAP

Following your steps it locks up hard at #5 with it being able to print "Allocation block xx" but after that nothing, complete halt

@Raziel

Thanks!
Now, any beta tester, or even developer (:-o !!!) willing to risk their reputation by repeating this very very simple test case in a 100% controlled situation/environment causing a pretty certain lockup? Remember that the source code is included so you can verify that the code is not at fault.

It seems something goes wrong when swapped out (virtual) memory is freeded and then reused, which was also my suspicion in daily use, since the lockup usually didn't occur until I quit a program having swapped and then tried to uniconify another program, presumably being swapped out.

I tried it on my A1-XE with 512 MB RAM and >2 GB swap partition. My beta test installation is a bit later than Update 4 but the kernel is unchanged in the memory alloc and swapping functions AFAIK.

Mixed results: sometimes it locks up as you say, sometimes it runs fine over and over again.

It's late now, but I'll have a look at your test proggie tomorrow, on the other machines as well.
Thank you for going to all this trouble to isolate a problem. Let's hope we can get it sorted.

BTW, why do you use obsolete system calls like AllocMem() and FreeMem() ?

@tonyw

Thanks for taking an interest in this. Reboots because of swapping lockups is currently my main reason for reboots. Now that I got your attention I'll disable swapping for now since it simply doesn't work.

I wonder why it doesn't lockup everytime for you, if you followed the step without exiting the test tool in between. Could it have something to do with disk timing? I have a 120GB PATA disk on the second channel of a sii0680 and the SWAP is located far out on the disk, at 100GB, and it's slightly less than 2GB IIRC.

Btw. I though AllocMem was still the primary and most basic way of allocating memory. What's the alternative? AllocSysObject and a heap of tags? No thanks, unless I would need one of the new special features. It's also not portable, and I typically write a lot of portable code.

Okay, can someone remind me again exactly how to disable swapping in Os4.1?

Thanks

Disable the swap in media-toolbox by unchecking the automount button for this partition.

Question: Did it work prior to Update 4 ?

Deniil wrote:Now, any beta tester, or even developer (:-o !!!) willing to risk their reputation by repeating this very very simple test case in a 100% controlled situation/environment causing a pretty certain lockup? Remember that the source code is included so you can verify that the code is not at fault.

What does that have to do with reputation ? If there's a bug, and someone can deliver a test case that shows it, then I'll gladly acknowledge that I made a mistake and can correct it.

Deniil wrote:It seems something goes wrong when swapped out (virtual) memory is freeded and then reused, which was also my suspicion in daily use, since the lockup usually didn't occur until I quit a program having swapped and then tried to uniconify another program, presumably being swapped out.

It's not that simple. I tried it, and it didn't lock up at first... I repeated the allocation->deallocation cycle several times, until it finally locked up. It's not as simple as re-allocating something that has been paged out before. It might also be a race condition. I will have to find out what exactly is happening to be sure.

Question still stands, did it happen on anything prior to Update 4 ?