Kernel 53.22 problem with SamFlex [SOLVED]

[mechanic]

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

Can you try this again without ever starting Dopus. Just use the Workbench and drag the files into the ramdisk
window. Just an experiment.

[DAX]

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.

That's what I also thought, a defective hw piece should behave badly no matter the kernel, however until Update 2 (and even now if I swap the old kernel back) it all works perfectly.

@Xenic
Ok let us know if your freezes improve (me, you and Samo79 are all using an 800Mhz SamFlex by the way) if your system behaves anything like mine the only draw back of using Kernel 53.12 should be that you will get a rather "jumpy" mouse and keyboard controlls after a certain amount of time.

@Samo79
isn't that (in your screennshot I mean) the RamDisk data? Shouldn't it result always full even if it's filled by 2 drawers weighting 32K? (or am I missing something in that screen?). Anyway, the important thing is that the system doesn't crash and that in the "workbench" top-bar you see all your memory back. Works here, and I got all my 870MB of free memory when I deleted the test drawer I created in RamDisk. Also performed the test two subsequent times and it worked (drawer erased and got all my memory back).

@ChrisH
Sadly reverting to Kernel 53.12 it's no good for USB, after a certain amount of time controlls become jumpy (on my system at least). Basically if you move the mouse up it "disappears" and then reappears up much further away (all goes back to normal after a reset).
By the way I tried moving the files to RamDisk with the CPU docky, and it's definitively a whole system freeze USB isn't the culprit here.

[samo79]

@DAX

Yep i have to correct myself, that value in RAM title was correct, so no problem and nothing strange so far

What remain for sure is this Virtual memory issue that seems solved using the old Kernel 53.12 under AmigaOS 4.1 Update 3, before (with Update 2 i mean) virtual memory never worked here, even using the same 53.12 kernel that now seems to work, so VM continue to not work with 53.22 in Update 3 but do it now with 53.12 !

I can confirm also your mouse issue, luckly switching back to 53.22 all problems with the mouse are gone

We have found an important issue i think

[DAX]

Initially I thought that swapping back in the old kernel, would save my playing sessions from orrible 53.22 derived crashes, but the problem with USB input devices becoming "jumpy" prompted me to perform another test: I swapped in the whole Kickstart.
Using the entire older kickstart (not just the older kernel) not only I get no crashes at all, but also slightly better performance in E-UAE (some slight sound hiccups that I can hear in Turrican 2 intro sequence, or in Pinball Dreams, they are now gone).
There is some hard proof to this behaviour as RageMem values confirm this somewhat:

RageMem Values with Vanilla Update 3:

CPU: AMCC PPC440EP 1.3 @ 799 Mhz
Caches Sizes: L1: 32 KB - L2: none - L3: none
Cache Line: 32

---> CPU <---
MAX MIPS: 1598

---> L1 <---
READ32: 2866 MB/Sec
READ64: 5681 MB/Sec
WRITE32: 2877 MB/Sec
WRITE64: 5685 MB/Sec

---> RAM <---
READ32: 316 MB/Sec
READ64: 316 MB/Sec
WRITE32: 199 MB/Sec
WRITE64: 199 MB/Sec
WRITE: 873 MB/Sec (Tricky)

---> VIDEO BUS <---
READ: 15 MB/Sec
WRITE: 58 MB/Sec

NOTE:Acube released a while back a file to be placed in start-up called Sam440_SetUp, with this file in, the only improvement I get is that the VideoBus "READ" is raised to "39".

Here are the results of the RageMem test using Update 3 but with the whole Update1 Kickstart swapped in + Sam440_SetUp (basically themes, new Mui and few other things stay, but at its core this is more Update1 than update3):

RAGEMEM v0.37 - compiled 11/06/2010

CPU: AMCC PPC440EP 1.3 @ 799 Mhz
Caches Sizes: L1: 32 KB - L2: none - L3: none
Cache Line: 128

---> CPU <---
MAX MIPS: 1598

---> L1 <---
READ32: 2872 MB/Sec
READ64: 5741 MB/Sec
WRITE32: 2895 MB/Sec
WRITE64: 5744 MB/Sec

---> RAM <---
READ32: 323 MB/Sec
READ64: 323 MB/Sec
WRITE32: 204 MB/Sec
WRITE64: 204 MB/Sec
WRITE: 911 MB/Sec (Tricky)

---> VIDEO BUS <---
READ: 41 MB/Sec
WRITE: 63 MB/Sec

I wonder why with the newer Kickstart the Sam440_Set up file doesn't improve the sistuation as strongly as it does with the older kickstart.

Now I created two new folders in Sys, and I use them to swap the kickstarts in case I want to play with emulators. The older Kickstart provides a safe and slightly faster environment to play the games (no jumpy input either), but I put the new kernel back in for WebBrowsing (with the older kickstart MUI OWB works but the mouse wheel doesn't sadly) or Blender, as I have no trouble when using other stuff and I don't wan't further problems to rear their ugly heads.

The situation is very far from ideal though

[xenic]

Can you try this again without ever starting Dopus. Just use the Workbench and drag the files into the ramdisk
window. Just an experiment.

O.K. but results are strange. I tried it again with Dopus4 by copying 2 565MB files to ram. The first attempt ended with an error requester from AmigaDOS reporting DOS Error 0, with some binary characters for the description, The second time it worked and the system seemed OK. When I tried drag-n-dropping the 2 565MB files (one at a time) without Dopus4 running, it worked but WorkBench showed more available system memory (in the WB drag bar) than I started with. When when I opened my Internet screen to go online and report the results, my system memory jumped up to 2,000,000+ MB. Every time I clicked a link to get to this forum the available memory jumped up until it reached 3,200,000 MB. When I started typing this response, it dropped to 2,035,712 MB. If I drag down my Internet screen and click on WorkBench the system memory drops to 832,000 MB but when I sswitched to the WorkBench screen the available memory jumped to 4,130,000 MB. This it great! The more memory I use, the more that is available. Actually, it looks like the system gets totally confused about how much system memory is available once virtual memory kicks in. P.S. I tried this experiment while testing with Kernal 53.12 instead of 53.22. Typing the last sentence just gave me another gigabyte of memory

EDIT: After entering the above message, I started Dopus4 and deleted the 2 huge files from RAM: and my available system memory reading on the WorkBench dragbar seems to have returned to normal. Apparently, the confusion only exists while virtual memory is in use.

P.S. After all the above experimenting and crazy mem readings, I still haven't had a freeze with Kernal 53.12. I think I need to run this way for a couple of days to confirm the difference but so far it looks promising.

[DAX]

@Xenic
Interesting...

[xenic]

@Xenic
Interesting...

Well. The system has been up for 14 hours straight without a freeze. RAOWB brought up a Grim Reaper with a DSI which allowed me to "Continue" without a reboot but that's probably an OWB issue. If this stability continues, I'm going to begin wondering if someone compiled the wrong kernal for SAM440 or if SAM Flex needs a slightly different kernal than regular 440. Is your system still stable with kernal 53.12?

[DAX]

@Xenic, Kernel 53.12 is able to sustain any kind of abuse without generating a crash, but I also found out something peculiar about my crashes:

I tryed underclocking the system using the Hyperclock utility, the first attempts resulted in the usal crashes however once I hit 667Mhz with a 111Mhz FSB the crashes with Kernel 53.22 ceased to take place . Now, at 800Mhz the 440 is running overclocked so it would be (too) easy to conclude that there is something going on hardware wise and it is probably, however this "something" is triggered by the new kernel as I'm about to demonstrate.

Basically what I did after this test was to load the 53.12 Kernel for a very long gNgeo session (this emulator has 100% CPU load) so I returned to the board's factory settings (800Mhz CPU + 133Mhz FSB), and played a few matches a Puzzle Bobble, than switched to a platform game (Blue's Journey) played some more, and then leaved the rolling demo going as I went catching a movie on TV.
After more than 3 hours of Gngeo running mighty fine I told to myself "now it's time push this thing further", so I loaded DGEN + MegaTurrican and had it run simultaneously while I went and watched some more TV, when I got back both were still running mighty fine, so I said to myself it's time to REALLY push it, so I loaded Hyper Clock and overclocked the FSB to 160Mhz (now the system was running at 800Mhz CPU + 160Mhz FSB), i launched DGEN, gNgeo and...E-UAE with Turrican 2. The latter had a 1 priority otherwise it wouldn't load the game, and to see all three running (as E-UAE was full screen while the other two were windowed and running side by side) I dragged down the WB just enough (remember to do this while E-UAE is showing the ASL requester for ADFs, otherwise the situation gets out of control, after doing this just reclick euae and close the requester).

To make a long story short: with kernel 53.12 I had DGEN + gNgeo + E-UAE all running simultaneously at 800Mhz CPU + 160Mhz FSB with no sign of crashes whatsoever. This older Kernel it's just INVINCIBLE.

What I make out of this, is that there is something in Kernel 53.22 that overloads the CPU somewhat, an unwanted overload that can be avoided as 53.12 clearly demontrates.

I don't know if this problem is related to Virtual memory not working but alas, this new kernel is rather fishy, that's for sure.

[xenic]

@DAX
I've always been suspicious about the switch to 733Mhz for the Flex but of course ACube would never admit that there was any problem with the 800Mhz version. I'm in my second day with kernal 53.12 and still no freezes. I'm going to run my system this way for several days and then switch back to 53.22 to confirm that that is really a difference. I can live with an occasional Grim Reaper or minor USB issues but freezes (lockups) are just unacceptable. About a month after I first got my SAM Flexx 800, I returned to my µA1 and put the SAM in the closet until UBoot & OS4 updates stabalized the system. Once the SAM got stable enough for me, I liked it better than the µA1 and the µA1 has been in the closet ever since. I would just like to know what new features and bug-fixes we are missing by using the older kernal.

I have had 2 peculiar mouse issues since switching to the 53.12 kernal but that was probably a USB issue. When I moved the pointer around a lot during network startup (I don't start my Internet during bootup) the mouse pointer got slow and intermittant. I couldn't really control the system with a mouse any longer. Plugging in another mouse didn't help. I moved the mouse pointer to AmiDock with the keyboard and clicked a USB reset icon (which I set up because of keyboard dropouts with Update2) and the mouse pointer returned to normal.

I'll keep you posted with my results from switching to Kernal 53.12 and hope it is a workable solution for both of us.

[DAX]

After noticing the fact that at 667Mhz + 111Mhz FSB there were no crashes (actually there were no crashes with 133Mhz FSB as well but there were USB drop outs strangely enough) we now have clear two things:

1)The Kernel "CAN" be stable so it doesn't have bugged code that generate the crash.

2)It certainly does something that it didn't do in the previous version, which stresses out the CPU far more (without any apparent benefit, as a matter of fact performance were slightly better before, check my RageMem related post above).

Now on one hand we know 800Mhz Sams are selected CPUs which were overclocked, and since Acube found 440 chips, that could go as up as 867Mhz, it isn't too hard to imagine a situation where some of these 800Mhz chips can actually go a little higher (so this overload doesn't effect them), while another bunch is running at 800Mhz "borderline".
Probably both me and you have such chips, however to cut Acube some slack, with a super tuned kernel like 53.12 this was never a problem. Heck even with overclocked FSB to 160Mhz and all the abuse in the world the sytem never crash! I made another experiment after posting the last message, I launched both gNgeo and DGEN but instead of E-UAE I launched a VERY high resolution video with DVPlayer. While everything was moving I kept resizing the DVPlayer window (even slightly larger than the screen itself) moving around the window at high speed etc. and all this at 800Mhz + 160Mhz FSB...there is just no way to make 53.12 crash, if that isn't both rock solid and well made I don't know what it is.

So the new kernel is unnecesarily stressing the CPU out, and this is problematic with certain 800Mhz Sams. Just after the video test I mentioned I opened the case and performed a custom/hacked job to install a CPU Fan above the 440 heat sink (good enough for my system which is laying flat, but i don't know if it's robust enough for permanent vertical case orientation) and, you guessed it, gNegeo is running in the background since, without a problem (even as I write this, a couple of hours now) with Kernel 53.22, never got it to run this long at 800Mhz, so apparently the CPU Fan (which is hovering half a centimeter above the CPU heat sink) is curing the problem.

I will have to buy a better "more fitting" one eventually but I hope even more that they come out with an updated kernel that behaves like the older one which could be overclocked and abused in every possible way without needing any electric fan. (also a problem for lovers of systems that are, or rather "should be", 100% silent).