Hyperion Entertainment Message Boards

The Short story: I have a problem with sudden system freeze which totally disappear if I flip the older kernel back in (and leave all the rest "update3 related" intact.

It doesn't matter if I'm using a tidy clean vanilla re-install from scratch, or an install over a previous (used) update 2 installation (ie: clean install doesn't cure the problem, flipping Kernel 53.12 in, does in both cases).

The long story:

After updating OS4 to Update 3, I noticed that emulators tend to crash "eventually". They do so after a while, and the "time frame" depends from game to game and session to session, for example I can start Gngeo, let the Puzzle Bobble rolling demo go on for a while, manage stage 15 in subsequent match before a system hang (If I play immediately, no rolling demo, and reach, say, stage 10 for example, I manage to close the emulator without troubles instead).

No DSI and no ISI, but a sudden screen freeze+last sound repeating at infinitum (switch off or Hard reset then needed).

Shorter play sessions followed by the closing and re-opening of the emulator seem to reset the "freeze count down", so if you play for an hour (or more) by changing emulators and closing them (and re-opening them) all the time, you might not notice this.

It would seem that other than emulators the system is solid, browsers and other Workbench utilities all work very well.
However the emulators behaviour is repeated again and again, the exact moment of the crash may change, meaning sometimes you reach further in the game, some times it crashes earlier specially if you play after a long OS session (using web browsers and what not), Emulators tend to work for a longer time if the system is fresh from boot instead) but it happens eventually.

Again even with this "beyond vanilla" OS4.1.3 installation (HD was hard formatted) the problem is only cured by swapping Kernels although this poses another problem: in time both keyboard and mouse start being difficult to controll (controll becomes "jumpy") probably some form of incompatibility between the new USB libraries and the older 53.12 kernel.

I wonder what has changed in Kernel 53.22 that generates the freeze problem, problem totally absent with 53.12.


P.S
I have an 800Mhz SamFlex with a beyond vanilla 4.1.3 re-install from scratch (HD full format, nothing added to start-up aside form what the installer adds by itself, no custom/third party library used, no nothing) I have tryed "full screen" modes (both double scanned and non-bouble scanned ) and windowed modes with gNgeo and ScummVM, eventually the freeze turns its ugly head although sometimes you get away with it (ie: you manage to close the emulator before it freezes the whole system).

Have you checked your memory lately?

If you don't have a reliable memory tester try creating a directory in ram and repeatedly filling it up with files until the memory is full and then delete it... repeat a few times... try different directories of files too... if this doesn't freeze your system chances are your ram is good.

I wonder if it's just a case of memory fragmentation also, I dunno if there are any realtime memory defrag tools... I remember a script back in the day that used to use avail flush in a script that run once a minute or more.

Of course the only other thing I would say which you probably don't want to hear is whatever you're running in cooperation with anything else you're running that is outside the scope of OS friendly or offical OS4.x is just not 100% compatiable...

No DSI and no ISI, but a sudden screen freeze+last sound repeating at infinitum (switch off or Hard reset then needed).

For those interested in getting to the bottom of this a serial output at this exact point could be invaluable

If you supplied us with the exact files you installed (links to downloads) ontop of a clean 4.1.3 installation someone just might go to all the trouble of installing it all and then bug logging that moment...

Ok I just performed the ram filling test you asked with usual (yet interesting) results: I had 870MB of free memory and the test consisted in moving to ram disk a couple drawers, the first weighted in 620MB and the second around 500MB (more than a GB total).
Using Update 3 with its rightful kernel (53.22) resulted in a system freeze as soon as the phisical limit of the ram was reached (had to Hard-Reset).
I tryed again afterward, same result (another hard reset).

Once I got back in workbench, I swapped in Kernel 53.12 and made another hard-reset, with this older kernel now active, I performed the previous test, and...tada! everthing moved in without breaking a sweat (using the swap I guess), I then deleted the folder I created in RamDisk and got all my memory back, no problems at all.
Repeated a couple of times, Kernel 53.12 is as solid as the hardest rock.

What do we make out of this?

Virtual memory never worked on my Sam Flex, Now with the update 3 i just tryed the same experiment: copy a video file of 940 MB of size (I have 1 GB RAM phisically installed) but the progression bar will stopped at some point (98% in this case) and if i click with the mouse somewhere i get an instantaneous freeze, keyboard doesn't work too ...

@Samo79
Try swapping-in the sole 53.12 kernel, in my case it does miracles (what happens to you with 53.22 is more or less what happens to me with the same Kernel...).

What do we make out of this?

After replying I remembered that I didn't run a SWAP partition so wasn't sure what result you might get. This is rather interesting though because it illustrates a potential unrelated problem. Since the hard reset happens when you're about to exceed the 1gig threshold (or there abouts) I find it unlikely that there is something actually wrong with your memory module and reverting back to the previous kernel adds weight to that conclusion.

Hopefully someone else following this thread will have more insight regarding this clash.

@DAX
Since installing Update3 I get at least one freeze per day. At first, I started logging them to see if I could establish a pattern but stopped while I was trying to get MUI-OWB working without a crash. Since I can't get a stack trace from the Grim Reaper that opens when MUI-OWB crashes, I've put it aside and am back to testing Update3 and logging freezes. So far today I've had 3 freezes. I'm using a SAM Flex 800 with OS4.1u3. I've been reluctant to start mixing files from previous versions but I will try your kernal swap to see if it makes any difference.

samo79 wrote:Virtual memory never worked on my Sam Flex, Now with the update 3 i just tryed the same experiment: copy a video file of 940 MB of size (I have 1 GB RAM phisically installed) but the progression bar will stopped at some point (98% in this case) and if i click with the mouse somewhere i get an instantaneous freeze, keyboard doesn't work too ...

I don't have a file that big but I copied a 550MB file to RAM and then several 100MB files until Dopus4 showed 640k (that number looks familiar) available memory in RAM. After that, when I copy files to RAM it continues to show 640k memory available for RAM. It seems that virtual RAM works for me. I am using SAM Flex 800. Are you sure you have a SWAP partition set up correctly? (Name SWAP, Automount, last partition on Hard-Disk, Blocksize 4096, Filesystem Type SWAP & mine is 2GB in size)
EDIT: My virtual memory test wasn't as successful as I thought. After completing the above post, I switched to my Dopus4 screen and deleted the files I had copied to RAM. Several seconds after the files were successfully deleted my system froze and I had to hit the reset button. I think the paint is wearing off of my reset button

@DAX

Ok i retry with the Kernel 53.12 and (surprise) now it works !
Almost i never see any freeze copying big files, i can be able to copy my big 900 MB file plus other small one, more or less 1 GB and more ...

Altrough when i cancelled all of them, my RAM look like that:

http://imageshack.us/photo/my-images/191/ramt.png/

FULL: 100% 0b Free 32Kb used

I don't understand what it mean, aniway ..

@Xenic

Yes i have a Sam Flex 800 aswell and i set the same value for my SWAP partition

I did some tests, and found that my *USB* keyboard & mouse permanently dies when I run out of real memory (and start using SWAP). Could you guys be mistaking USB dying for a system "freeze"? (I suggest adding the "CPUInfo" docky, or playing some music, so you can see/hear if the machine has really frozen or not.)

Given that I have found USB keyboard & mouse MUCH flakier than before, it would be an interesting test to see if switching to an older kernel fixes that too... EDIT: No it doesn't so looks like this is a separate problem, or perhaps only indirectly related.