Page 4 of 7
Re: Kernel 53.22 problem with SamFlex
Posted: Fri Sep 09, 2011 7:58 pm
by Spectre660
Anyone with freeze up problems running the Rnetmon.docky ?
Re: Kernel 53.22 problem with SamFlex
Posted: Sat Sep 10, 2011 1:57 am
by xenic
Spectre660 wrote:Anyone with freeze up problems running the Rnetmon.docky ?
No, but I misunderstood your question and am running it now. So far no problems. I went to an Internet speed test site while it is runnng and didn't have any problem. I won't use it other that for testing because it is too big and crowds my AmiDock. The only thing I normally have in AmiDock are icons to start programs.
Re: Kernel 53.22 problem with SamFlex
Posted: Sat Sep 10, 2011 2:18 am
by Spectre660
I asked because I have had long periods without a freeze but two freezes in two days after adding the rnmetmon.docky to Amidock. These happend when I was away from the computer after having everything running ok for hours.I have samba installed and was wondering if it is possible that a Windows Xp machine could have caused a freeze by polling the available shares on the OS 4.1 machine and causing a lockup with the docky.
Just a theory but I think that the docky may be the culprit as I was doing an Acronis TrueIMage backup on a Windows machine about the time the first freeze took place.Will see as I have removed all non Icon dockys for now.
xenic wrote:Spectre660 wrote:Anyone with freeze up problems running the Rnetmon.docky ?
No, but I misunderstood your question and am running it now. So far no problems. I went to an Internet speed test site while it is runnng and didn't have any problem. I won't use it other that for testing because it is too big and crowds my AmiDock. The only thing I normally have in AmiDock are icons to start programs.
Re: Kernel 53.22 problem with SamFlex
Posted: Mon Sep 12, 2011 11:39 am
by DAX
@Xenix
The new USB drivers seem to be a little "incompatible" with the old kernel, when using the latter I get your very same symptoms after a while. After I installed the CPU Fan the system has become rockstable using 53.22 (and of course whi the latter there are no USB problems here), However....
@Developers (and ALL)
The performance improvement claimed by some (since the OS is supposedly "using more") isn't felt that much if at all (just some graphical operation, although minor stuff) and if the additional usage of the CPU could/should/would bring down a system like mine or Xenic's just because we don't have the absolute best CPU samples, this thing should be true even when, using the old Kernel, I put not one, not two, but 3 very taxing programs side by side (after a while the CPu should heat up enough to cause a freeze).
However in the latter case there is no problem at all even after hours, and I would seriously consider checking out if there isn't anything in the new kernel that unnecessarily throttles the system.
And besides, the reduced overall memory bandwidth (as seen in Ragemem test) allowed for forgotten audio hiccups in certain classic games (emulated in E-Uae, like for example Turrican II intro sequence) to magically return from the dead.
I at least hope to get a new Sam440SetUp file, which brings back the older values...
Re: Kernel 53.22 problem with SamFlex
Posted: Mon Sep 12, 2011 12:14 pm
by cha05e90
DAX wrote: down a system like mine or Xenic's just because we don't have the absolute best CPU samples
It would be interesting if you could perform your tests using the HyperClock tool from ACube and *reduce* your CPU and/or FSB speeds. My standard SAM440ep (mini-itx, 667MHz) works rockstable (up to now, fingers crossed

) with Update 3 - and yes, I did stress, including for example running MUIOWB and parallel copying some dozen GB to an external HD with USB2.0.
Re: Kernel 53.22 problem with SamFlex
Posted: Mon Sep 12, 2011 2:07 pm
by DAX
@Cha05e90
I briefly reported on this earlier and your guess is correct, at 667Mhz the system is stable (as it is stable at 800Mhz with a CPU fan).
What puzzles me is the fact that with the old kernel, even if I put impossible loads on the CPU (even at 800Mhz with FSB overclocked to 160Mhz) all I get is a super slow system, never a freeze.
Shouldn't a borderline CPU freeze too in such an exreme case?
Re: Kernel 53.22 problem with SamFlex
Posted: Mon Sep 12, 2011 3:22 pm
by xenic
cha05e90 wrote:
It would be interesting if you could perform your tests using the HyperClock tool from ACube and *reduce* your CPU and/or FSB speeds. My standard SAM440ep (mini-itx, 667MHz) works rockstable (up to now, fingers crossed

) with Update 3 - and yes, I did stress, including for example running MUIOWB and parallel copying some dozen GB to an external HD with USB2.0.
"Interresting" isn't the term I would use to describe my feelings if I find out I bought a system that must be crippled down to the equivalent of a system that cost hundreds less. I'm still testing my system with ehci.usbhcd disabled in my Kicklayout and don't want to cripple my system unless it's the only way to get it working. So far I haven't had a freeze with ehci.usbhcd disabled so I am hopeful. It will take a couple of freeze-free days to convince me that I have found the solution. I looked at the ehci.usbhcd file with a Hex editor and noticed that even though the file is the same for all PPC systems, the internal text strings contain the term "PPC460EX" but nothing relating specifically to other systems. That might not mean anything though.
Re: Kernel 53.22 problem with SamFlex
Posted: Mon Sep 12, 2011 4:19 pm
by ChrisH
DAX wrote:if the additional usage of the CPU could/should/would bring down a system like mine or Xenic's just because we don't have the absolute best CPU samples, this thing should be true even when, using the old Kernel, I put not one, not two, but 3 very taxing programs side by side (after a while the CPu should heat up enough to cause a freeze).
However in the latter case there is no problem at all even after hours, and I would seriously consider checking out if there isn't anything in the new kernel that unnecessarily throttles the system.
I'm not sure what you are arguing about: You have proved that a fan stops the crashing - for which the ONLY explanation is overheating. There is no need for "could/should/would" theory, when you have provided empirical proof of what is actually happening!
Now, you might argue it'd be nice if Hyperion could provide a switch to disable whatever optimisation(s) that causes the new kernel to overheat the CPU (on borderline overclocked systems), but that doesn't seem to be what you are asking for...
Re: Kernel 53.22 problem with SamFlex
Posted: Mon Sep 12, 2011 4:37 pm
by Spectre660
No coincidence then about the Hyperclock utility for adjusting things down as well as up . and the warning about cooling the CPU if overclocking .
There is also a note on memory type to achieve overclocking.