* [gentoo-user] Suspend to RAM caused crashes
@ 2011-08-21 10:27 Mick
2011-08-21 11:19 ` [gentoo-user] " Francesco Talamona
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Mick @ 2011-08-21 10:27 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: Text/Plain, Size: 1606 bytes --]
Here's a strange one:
Suspending a Pentium4 32bit machine used to work a treat. For years. Then
around 9 months ago or so, I can't recall exactly, it started causing crashes.
What happens is that the monitor will go to sleep and the disk will stop
immediately, but the machine continues to run and run and run ...
At that point I have lost access to the keyboard and the monitor does not wake
up if I move the mouse. Using ssh to connect shows that the machine is off
the network, so I assume that the NIC is also suspended. The only way to
recover is to pull the plug. :-(
Unfortunately, mysql has left a lock file behind, so it won't start at reboot
until I remove the lockfile.
Now, here's the strange thing about all this. I have 4 RAM modules, 2x1G and
2x500M. Following the manual I have installed them in this order:
slot 1 - 1G,
slot 2 - 0.5G,
slot 3 - 1G,
slot 4 - 0.5G
If I try to suspend the machine soon after boot, when it is still using low
amounts of memory, the machine will suspend each time without fail (just like
it used to do in the past).
If I wait until the machine is using more than 1G or so, then it will always
crash.
I'm running memtest86+ just in case, but 3 passes and no errors are shown so
far. Suspend to RAM is really a time saver on this machine and was being used
at least 4-5 times a day. Now the box is running non-stop 16 hours a day or
more, which is wasteful (although with the Pentium4 I'm saving on central
heating bills!) Any ideas what I can look into to resolve this?
--
Regards,
Mick
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 10:27 [gentoo-user] Suspend to RAM caused crashes Mick
@ 2011-08-21 11:19 ` Francesco Talamona
2011-08-21 11:42 ` Mick
2011-08-21 15:12 ` [gentoo-user] " Nikos Chantziaras
2011-08-21 12:53 ` [gentoo-user] " Volker Armin Hemmann
2011-08-21 15:30 ` meino.cramer
2 siblings, 2 replies; 16+ messages in thread
From: Francesco Talamona @ 2011-08-21 11:19 UTC (permalink / raw
To: gentoo-user
On Sunday 21 August 2011, Mick wrote:
> Here's a strange one:
>
> Suspending a Pentium4 32bit machine used to work a treat. For years.
> Then around 9 months ago or so, I can't recall exactly, it started
> causing crashes. What happens is that the monitor will go to sleep
> and the disk will stop immediately, but the machine continues to run
> and run and run ...
>
> At that point I have lost access to the keyboard and the monitor does
> not wake up if I move the mouse. Using ssh to connect shows that
> the machine is off the network, so I assume that the NIC is also
> suspended. The only way to recover is to pull the plug. :-(
>
> Unfortunately, mysql has left a lock file behind, so it won't start
> at reboot until I remove the lockfile.
>
> Now, here's the strange thing about all this. I have 4 RAM modules,
> 2x1G and 2x500M. Following the manual I have installed them in this
> order:
>
> slot 1 - 1G,
> slot 2 - 0.5G,
> slot 3 - 1G,
> slot 4 - 0.5G
>
> If I try to suspend the machine soon after boot, when it is still
> using low amounts of memory, the machine will suspend each time
> without fail (just like it used to do in the past).
>
> If I wait until the machine is using more than 1G or so, then it will
> always crash.
>
> I'm running memtest86+ just in case, but 3 passes and no errors are
> shown so far. Suspend to RAM is really a time saver on this machine
> and was being used at least 4-5 times a day. Now the box is running
> non-stop 16 hours a day or more, which is wasteful (although with
> the Pentium4 I'm saving on central heating bills!) Any ideas what I
> can look into to resolve this?
I'm using KDE to suspend my machine, for some reason it recently stopped
working, but it was only with kernel 3.0.1
I was able to see an error quickly changing to tty12 where the console
is used to echo /var/log/messages after clicking "sleep" button in KDE
Aug 15 07:42:31 aemaeth polkitd(authority=local): Registered
Authentication Agent for unix-
session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.29
[/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path
/org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Aug 15 07:42:35 aemaeth dbus[3247]: [system] Rejected send message, 2
matched rules; type="method_call", sender=":1.33" (uid=501 pid=4883
comm="nautilus --sm-client-id 10c6d9d5610001307993940000")
interface="org.freedesktop.DBus.Properties" member="GetAll" error
name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=3297
comm="/usr/sbin/console-kit-daemon ")
The machine locked itself shortly after that error, but the log was
there.
My problem is now gone with kernel 3.0.3. I wish yours it's not a RAM
issue, it could be tricky to spot, because memtest is not putting any
load to the machine, so it's very useful when it reports error, but when
it doesn't you can't be sure if RAM modules are in good health.
From my experience the stress load of compiling large packages is more
likely to evidence RAM faults than memtest itself.
HTH
Francesco
--
Linux Version 3.0.0-gentoo, Compiled #3 SMP PREEMPT Fri Aug 5 21:02:22
CEST 2011
Two 2.9GHz AMD Athlon 64 X2 Processors, 4GB RAM, 11659 Bogomips Total
aemaeth
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 11:19 ` [gentoo-user] " Francesco Talamona
@ 2011-08-21 11:42 ` Mick
2011-08-21 11:57 ` [gentoo-user] " Pandu Poluan
2011-08-21 15:12 ` [gentoo-user] " Nikos Chantziaras
1 sibling, 1 reply; 16+ messages in thread
From: Mick @ 2011-08-21 11:42 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: Text/Plain, Size: 3928 bytes --]
On Sunday 21 Aug 2011 12:19:40 Francesco Talamona wrote:
> On Sunday 21 August 2011, Mick wrote:
> > Here's a strange one:
> >
> > Suspending a Pentium4 32bit machine used to work a treat. For years.
> >
> > Then around 9 months ago or so, I can't recall exactly, it started
> >
> > causing crashes. What happens is that the monitor will go to sleep
> > and the disk will stop immediately, but the machine continues to run
> > and run and run ...
> >
> > At that point I have lost access to the keyboard and the monitor does
> > not wake up if I move the mouse. Using ssh to connect shows that
> > the machine is off the network, so I assume that the NIC is also
> > suspended. The only way to recover is to pull the plug. :-(
> >
> > Unfortunately, mysql has left a lock file behind, so it won't start
> > at reboot until I remove the lockfile.
> >
> > Now, here's the strange thing about all this. I have 4 RAM modules,
> > 2x1G and 2x500M. Following the manual I have installed them in this
> > order:
> >
> > slot 1 - 1G,
> > slot 2 - 0.5G,
> > slot 3 - 1G,
> > slot 4 - 0.5G
> >
> > If I try to suspend the machine soon after boot, when it is still
> > using low amounts of memory, the machine will suspend each time
> > without fail (just like it used to do in the past).
> >
> > If I wait until the machine is using more than 1G or so, then it will
> > always crash.
> >
> > I'm running memtest86+ just in case, but 3 passes and no errors are
> > shown so far. Suspend to RAM is really a time saver on this machine
> > and was being used at least 4-5 times a day. Now the box is running
> > non-stop 16 hours a day or more, which is wasteful (although with
> > the Pentium4 I'm saving on central heating bills!) Any ideas what I
> > can look into to resolve this?
>
> I'm using KDE to suspend my machine, for some reason it recently stopped
> working, but it was only with kernel 3.0.1
>
> I was able to see an error quickly changing to tty12 where the console
> is used to echo /var/log/messages after clicking "sleep" button in KDE
>
> Aug 15 07:42:31 aemaeth polkitd(authority=local): Registered
> Authentication Agent for unix-
> session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.29
> [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path
> /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
> Aug 15 07:42:35 aemaeth dbus[3247]: [system] Rejected send message, 2
> matched rules; type="method_call", sender=":1.33" (uid=501 pid=4883
> comm="nautilus --sm-client-id 10c6d9d5610001307993940000")
> interface="org.freedesktop.DBus.Properties" member="GetAll" error
> name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=3297
> comm="/usr/sbin/console-kit-daemon ")
>
> The machine locked itself shortly after that error, but the log was
> there.
>
> My problem is now gone with kernel 3.0.3. I wish yours it's not a RAM
> issue, it could be tricky to spot, because memtest is not putting any
> load to the machine, so it's very useful when it reports error, but when
> it doesn't you can't be sure if RAM modules are in good health.
> From my experience the stress load of compiling large packages is more
> likely to evidence RAM faults than memtest itself.
No problem with big package emerges, or running demanding applications like
gimp, inkscape and firefox, chrome and opera with umpteen tabs open, plus
Windows7 running on virtualbox on occasion. When all 3G is needed the machine
will swap happily.
I would readily say that I am certain this is not a memory problem except ...
the 2x1G RAM modules are not the same make as the 2x500M modules. In the past
I have had MoBos which were very particular on choice of memory modules and
mismatching them led to all sort of obscure crashes (e.g. when swapping was
starting).
--
Regards,
Mick
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Suspend to RAM caused crashes
2011-08-21 11:42 ` Mick
@ 2011-08-21 11:57 ` Pandu Poluan
2011-08-21 12:37 ` Mick
0 siblings, 1 reply; 16+ messages in thread
From: Pandu Poluan @ 2011-08-21 11:57 UTC (permalink / raw
To: gentoo-user
(sorry for top-posting)
Do the 1 GB pieces have the same timing values as the 0.5 GB pieces?
Try slowing down the memory timing parameters in BIOS (should look
like 8-5-3-3 or something like that; larger numbers are slower).
Rgds,
On 2011-08-21, Mick <michaelkintzios@gmail.com> wrote:
> On Sunday 21 Aug 2011 12:19:40 Francesco Talamona wrote:
>> On Sunday 21 August 2011, Mick wrote:
>> > Here's a strange one:
>> >
>> > Suspending a Pentium4 32bit machine used to work a treat. For years.
>> >
>> > Then around 9 months ago or so, I can't recall exactly, it started
>> >
>> > causing crashes. What happens is that the monitor will go to sleep
>> > and the disk will stop immediately, but the machine continues to run
>> > and run and run ...
>> >
>> > At that point I have lost access to the keyboard and the monitor does
>> > not wake up if I move the mouse. Using ssh to connect shows that
>> > the machine is off the network, so I assume that the NIC is also
>> > suspended. The only way to recover is to pull the plug. :-(
>> >
>> > Unfortunately, mysql has left a lock file behind, so it won't start
>> > at reboot until I remove the lockfile.
>> >
>> > Now, here's the strange thing about all this. I have 4 RAM modules,
>> > 2x1G and 2x500M. Following the manual I have installed them in this
>> > order:
>> >
>> > slot 1 - 1G,
>> > slot 2 - 0.5G,
>> > slot 3 - 1G,
>> > slot 4 - 0.5G
>> >
>> > If I try to suspend the machine soon after boot, when it is still
>> > using low amounts of memory, the machine will suspend each time
>> > without fail (just like it used to do in the past).
>> >
>> > If I wait until the machine is using more than 1G or so, then it will
>> > always crash.
>> >
>> > I'm running memtest86+ just in case, but 3 passes and no errors are
>> > shown so far. Suspend to RAM is really a time saver on this machine
>> > and was being used at least 4-5 times a day. Now the box is running
>> > non-stop 16 hours a day or more, which is wasteful (although with
>> > the Pentium4 I'm saving on central heating bills!) Any ideas what I
>> > can look into to resolve this?
>>
>> I'm using KDE to suspend my machine, for some reason it recently stopped
>> working, but it was only with kernel 3.0.1
>>
>> I was able to see an error quickly changing to tty12 where the console
>> is used to echo /var/log/messages after clicking "sleep" button in KDE
>>
>> Aug 15 07:42:31 aemaeth polkitd(authority=local): Registered
>> Authentication Agent for unix-
>> session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.29
>> [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path
>> /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
>> Aug 15 07:42:35 aemaeth dbus[3247]: [system] Rejected send message, 2
>> matched rules; type="method_call", sender=":1.33" (uid=501 pid=4883
>> comm="nautilus --sm-client-id 10c6d9d5610001307993940000")
>> interface="org.freedesktop.DBus.Properties" member="GetAll" error
>> name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=3297
>> comm="/usr/sbin/console-kit-daemon ")
>>
>> The machine locked itself shortly after that error, but the log was
>> there.
>>
>> My problem is now gone with kernel 3.0.3. I wish yours it's not a RAM
>> issue, it could be tricky to spot, because memtest is not putting any
>> load to the machine, so it's very useful when it reports error, but when
>> it doesn't you can't be sure if RAM modules are in good health.
>> From my experience the stress load of compiling large packages is more
>> likely to evidence RAM faults than memtest itself.
>
> No problem with big package emerges, or running demanding applications like
> gimp, inkscape and firefox, chrome and opera with umpteen tabs open, plus
> Windows7 running on virtualbox on occasion. When all 3G is needed the
> machine
> will swap happily.
>
> I would readily say that I am certain this is not a memory problem except
> ...
> the 2x1G RAM modules are not the same make as the 2x500M modules. In the
> past
> I have had MoBos which were very particular on choice of memory modules and
> mismatching them led to all sort of obscure crashes (e.g. when swapping was
> starting).
> --
> Regards,
> Mick
>
--
--
Pandu E Poluan - IT Optimizer
My website: http://pandu.poluan.info/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Suspend to RAM caused crashes
2011-08-21 11:57 ` [gentoo-user] " Pandu Poluan
@ 2011-08-21 12:37 ` Mick
0 siblings, 0 replies; 16+ messages in thread
From: Mick @ 2011-08-21 12:37 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: Text/Plain, Size: 1016 bytes --]
On Sunday 21 Aug 2011 12:57:48 Pandu Poluan wrote:
> (sorry for top-posting)
>
> Do the 1 GB pieces have the same timing values as the 0.5 GB pieces?
Yes, same timing values. When I bought the 1G modules I made sure that they
were matched exactly in terms of specification with the 0.5G pieces (other
than the size).
> Try slowing down the memory timing parameters in BIOS (should look
> like 8-5-3-3 or something like that; larger numbers are slower).
I have not messed about with the memory timing jumpers at all as far as I can
recall. The timing setting is the OEM's defaults (Compaq) and there is no way
to access them in the BIOS.
memtest86+ reports:
Chipset: Intel i915P/G (ECC: Disabled) - FSB: 200MHz - Type: DDR1
Settings: RAM: 200MHz (DDR400) / CAS: 3-3-3-8 / Dual Channel (Interleaved)
PS. memtest86+ did not show any errors for 4 passes. This script did not
come up with any errors either:
http://people.redhat.com/dledford/memtest.shtml
--
Regards,
Mick
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Suspend to RAM caused crashes
2011-08-21 10:27 [gentoo-user] Suspend to RAM caused crashes Mick
2011-08-21 11:19 ` [gentoo-user] " Francesco Talamona
@ 2011-08-21 12:53 ` Volker Armin Hemmann
2011-08-21 15:30 ` meino.cramer
2 siblings, 0 replies; 16+ messages in thread
From: Volker Armin Hemmann @ 2011-08-21 12:53 UTC (permalink / raw
To: gentoo-user
Am Sonntag 21 August 2011, 11:27:55 schrieb Mick:
> Here's a strange one:
>
> Suspending a Pentium4 32bit machine used to work a treat. For years. Then
> around 9 months ago or so, I can't recall exactly, it started causing
> crashes. What happens is that the monitor will go to sleep and the disk
> will stop immediately, but the machine continues to run and run and run ...
>
so try different kernel versions. Start with 3.0.3 and then go down - one
kernel per release (not all those stable releases in between) should be
enough. Then, as soon as it starts working again, you can narrow it down.
Use vanilla kernels for this.
Second, enable wake on lan - if your machine hangs while suspending, try to
kick it back to life with a wol-packet.
Third point, there are some checks and self tests among the kernel debug
options related to suspending, enable them.
For me, 3.0.1 is the first kernel ever that made it possible for me to
suspend-to-ram (with fglrx even). Suspending is a bitch, breaking and
unbreaking on an irregular basis thanks to crappy bios'.
--
#163933
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 11:19 ` [gentoo-user] " Francesco Talamona
2011-08-21 11:42 ` Mick
@ 2011-08-21 15:12 ` Nikos Chantziaras
2011-08-21 15:22 ` Volker Armin Hemmann
` (2 more replies)
1 sibling, 3 replies; 16+ messages in thread
From: Nikos Chantziaras @ 2011-08-21 15:12 UTC (permalink / raw
To: gentoo-user
On 08/21/2011 02:19 PM, Francesco Talamona wrote:
> I wish yours it's not a RAM
> issue, it could be tricky to spot, because memtest is not putting any
> load to the machine, so it's very useful when it reports error, but when
> it doesn't you can't be sure if RAM modules are in good health.
CPU load doesn't affect RAM errors. CPU load affects CPU errors. If
you only get RAM errors during heavy load, the RAM is just fine, but
your CPU has a fault.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 15:12 ` [gentoo-user] " Nikos Chantziaras
@ 2011-08-21 15:22 ` Volker Armin Hemmann
2011-08-21 15:33 ` Mark Knecht
2011-08-22 4:54 ` Francesco Talamona
2 siblings, 0 replies; 16+ messages in thread
From: Volker Armin Hemmann @ 2011-08-21 15:22 UTC (permalink / raw
To: gentoo-user
Am Sonntag 21 August 2011, 18:12:00 schrieb Nikos Chantziaras:
> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
> > I wish yours it's not a RAM
> >
> > issue, it could be tricky to spot, because memtest is not putting any
> > load to the machine, so it's very useful when it reports error, but when
> > it doesn't you can't be sure if RAM modules are in good health.
>
> CPU load doesn't affect RAM errors. CPU load affects CPU errors. If
> you only get RAM errors during heavy load, the RAM is just fine, but
> your CPU has a fault.
or you have a faulty psu that is not able to deliver clean current and stable
voltages as soon as the load goes up.
--
#163933
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Suspend to RAM caused crashes
2011-08-21 10:27 [gentoo-user] Suspend to RAM caused crashes Mick
2011-08-21 11:19 ` [gentoo-user] " Francesco Talamona
2011-08-21 12:53 ` [gentoo-user] " Volker Armin Hemmann
@ 2011-08-21 15:30 ` meino.cramer
2 siblings, 0 replies; 16+ messages in thread
From: meino.cramer @ 2011-08-21 15:30 UTC (permalink / raw
To: gentoo-user
Mick <michaelkintzios@gmail.com> [11-08-21 12:32]:
> Here's a strange one:
>
> Suspending a Pentium4 32bit machine used to work a treat. For years. Then
> around 9 months ago or so, I can't recall exactly, it started causing crashes.
> What happens is that the monitor will go to sleep and the disk will stop
> immediately, but the machine continues to run and run and run ...
>
> At that point I have lost access to the keyboard and the monitor does not wake
> up if I move the mouse. Using ssh to connect shows that the machine is off
> the network, so I assume that the NIC is also suspended. The only way to
> recover is to pull the plug. :-(
>
> Unfortunately, mysql has left a lock file behind, so it won't start at reboot
> until I remove the lockfile.
>
> Now, here's the strange thing about all this. I have 4 RAM modules, 2x1G and
> 2x500M. Following the manual I have installed them in this order:
>
> slot 1 - 1G,
> slot 2 - 0.5G,
> slot 3 - 1G,
> slot 4 - 0.5G
>
> If I try to suspend the machine soon after boot, when it is still using low
> amounts of memory, the machine will suspend each time without fail (just like
> it used to do in the past).
>
> If I wait until the machine is using more than 1G or so, then it will always
> crash.
>
> I'm running memtest86+ just in case, but 3 passes and no errors are shown so
> far. Suspend to RAM is really a time saver on this machine and was being used
> at least 4-5 times a day. Now the box is running non-stop 16 hours a day or
> more, which is wasteful (although with the Pentium4 I'm saving on central
> heating bills!) Any ideas what I can look into to resolve this?
> --
> Regards,
> Mick
Hi Mick,
one thing, which is able to produce any kind of error except those, which one
would exspect in a certain context, is a bad capicitor on the mobo (or
sometimes in the power supply).
If I understand your posting correctly, your PC is not the youngest
one...?
I had a motherboard, which completly fails to boot the very first
stages of the kernel boot process, but perfectly runs memtest86....
Bad capacitors...
More RAM means more power.
What happens, if you change the RAMS in such a manner:
slot 1 - 0.5G,
slot 2 - 1G,
slot 3 - 0.5G
slot 4 - 1G,
?
Does teh computer have problems after accessing slot 2 or after access
more than 1G?
Best regards,
mcc
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 15:12 ` [gentoo-user] " Nikos Chantziaras
2011-08-21 15:22 ` Volker Armin Hemmann
@ 2011-08-21 15:33 ` Mark Knecht
2011-08-21 15:43 ` Nikos Chantziaras
2011-08-22 4:54 ` Francesco Talamona
2 siblings, 1 reply; 16+ messages in thread
From: Mark Knecht @ 2011-08-21 15:33 UTC (permalink / raw
To: gentoo-user
On Sun, Aug 21, 2011 at 8:12 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
>>
>> I wish yours it's not a RAM
>> issue, it could be tricky to spot, because memtest is not putting any
>> load to the machine, so it's very useful when it reports error, but when
>> it doesn't you can't be sure if RAM modules are in good health.
>
> CPU load doesn't affect RAM errors. CPU load affects CPU errors. If you
> only get RAM errors during heavy load, the RAM is just fine, but your CPU
> has a fault.
Unless the CPU loading causes excessive heat and the RAM has problems
only when it gets hot.
In general semiconductor speeds slow down as temperature increases so
a RAM that's barely in spec at room temp could be out of spec at high
temp.
Just an idea.
- Mark
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 15:33 ` Mark Knecht
@ 2011-08-21 15:43 ` Nikos Chantziaras
2011-08-21 16:08 ` Mark Knecht
0 siblings, 1 reply; 16+ messages in thread
From: Nikos Chantziaras @ 2011-08-21 15:43 UTC (permalink / raw
To: gentoo-user
On 08/21/2011 06:33 PM, Mark Knecht wrote:
> On Sun, Aug 21, 2011 at 8:12 AM, Nikos Chantziaras<realnc@arcor.de> wrote:
>> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
>>>
>>> I wish yours it's not a RAM
>>> issue, it could be tricky to spot, because memtest is not putting any
>>> load to the machine, so it's very useful when it reports error, but when
>>> it doesn't you can't be sure if RAM modules are in good health.
>>
>> CPU load doesn't affect RAM errors. CPU load affects CPU errors. If you
>> only get RAM errors during heavy load, the RAM is just fine, but your CPU
>> has a fault.
>
> Unless the CPU loading causes excessive heat and the RAM has problems
> only when it gets hot.
The RAM gets hot when there's RAM load (meaning being used heavily), not
when there's CPU load :*)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 15:43 ` Nikos Chantziaras
@ 2011-08-21 16:08 ` Mark Knecht
2011-08-21 16:26 ` Nikos Chantziaras
0 siblings, 1 reply; 16+ messages in thread
From: Mark Knecht @ 2011-08-21 16:08 UTC (permalink / raw
To: gentoo-user
On Sun, Aug 21, 2011 at 8:43 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 08/21/2011 06:33 PM, Mark Knecht wrote:
>>
>> On Sun, Aug 21, 2011 at 8:12 AM, Nikos Chantziaras<realnc@arcor.de>
>> wrote:
>>>
>>> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
>>>>
>>>> I wish yours it's not a RAM
>>>> issue, it could be tricky to spot, because memtest is not putting any
>>>> load to the machine, so it's very useful when it reports error, but when
>>>> it doesn't you can't be sure if RAM modules are in good health.
>>>
>>> CPU load doesn't affect RAM errors. CPU load affects CPU errors. If you
>>> only get RAM errors during heavy load, the RAM is just fine, but your CPU
>>> has a fault.
>>
>> Unless the CPU loading causes excessive heat and the RAM has problems
>> only when it gets hot.
>
> The RAM gets hot when there's RAM load (meaning being used heavily), not
> when there's CPU load :*)
Do you feel heat when your PC is turned on and running hard? Of course
you do. The whole machine heats up. The CPU under load heats the
machine so the RAM and drives and everything else heats up also. Not
as hot as the CPU, but it heats up. So I might agree with you - the
RAM might not be 'hot', but it would certainly be 'warmer'.
I'm not suggesting that this would cause a normal DRAM stick to go
bad, but only that if he had a very marginal bit of RAM that it might
go out of spec...
- Mark
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 16:08 ` Mark Knecht
@ 2011-08-21 16:26 ` Nikos Chantziaras
2011-08-21 17:27 ` Mark Knecht
2011-08-21 17:28 ` Volker Armin Hemmann
0 siblings, 2 replies; 16+ messages in thread
From: Nikos Chantziaras @ 2011-08-21 16:26 UTC (permalink / raw
To: gentoo-user
On 08/21/2011 07:08 PM, Mark Knecht wrote:
> On Sun, Aug 21, 2011 at 8:43 AM, Nikos Chantziaras<realnc@arcor.de> wrote:
>> On 08/21/2011 06:33 PM, Mark Knecht wrote:
>>>
>>> On Sun, Aug 21, 2011 at 8:12 AM, Nikos Chantziaras<realnc@arcor.de>
>>> wrote:
>>>>
>>>> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
>> [...]
>> The RAM gets hot when there's RAM load (meaning being used heavily), not
>> when there's CPU load :*)
>
> Do you feel heat when your PC is turned on and running hard? Of course
> you do. The whole machine heats up. The CPU under load heats the
> machine so the RAM and drives and everything else heats up also. Not
> as hot as the CPU, but it heats up. So I might agree with you - the
> RAM might not be 'hot', but it would certainly be 'warmer'.
>
> I'm not suggesting that this would cause a normal DRAM stick to go
> bad, but only that if he had a very marginal bit of RAM that it might
> go out of spec...
On a laptop maybe. On a desktop, the air around the RAM modules get
maybe 1 degree C warmer (I know because I have temp sensor there,
connected to the front panel).
When it does get warm is when there's GPU and disk load. Those suckers
combined can raise the temp inside the box by 5-6 degrees.
The meaning of all this is that if memtest can't find any errors after a
full run (which can take an hour), the chances of getting an error that
is really related to RAM under CPU stress are very slim.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 16:26 ` Nikos Chantziaras
@ 2011-08-21 17:27 ` Mark Knecht
2011-08-21 17:28 ` Volker Armin Hemmann
1 sibling, 0 replies; 16+ messages in thread
From: Mark Knecht @ 2011-08-21 17:27 UTC (permalink / raw
To: gentoo-user
On Sun, Aug 21, 2011 at 9:26 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
<SNIP>
>
> The meaning of all this is that if memtest can't find any errors after a
> full run (which can take an hour), the chances of getting an error that is
> really related to RAM under CPU stress are very slim.
Which I completely agree with
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 16:26 ` Nikos Chantziaras
2011-08-21 17:27 ` Mark Knecht
@ 2011-08-21 17:28 ` Volker Armin Hemmann
1 sibling, 0 replies; 16+ messages in thread
From: Volker Armin Hemmann @ 2011-08-21 17:28 UTC (permalink / raw
To: gentoo-user
Am Sonntag 21 August 2011, 19:26:47 schrieb Nikos Chantziaras:
> On 08/21/2011 07:08 PM, Mark Knecht wrote:
> > On Sun, Aug 21, 2011 at 8:43 AM, Nikos Chantziaras<realnc@arcor.de>
wrote:
> >> On 08/21/2011 06:33 PM, Mark Knecht wrote:
> >>> On Sun, Aug 21, 2011 at 8:12 AM, Nikos Chantziaras<realnc@arcor.de>
> >>>
> >>> wrote:
> >>>> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
> >> [...]
> >>
> >> The RAM gets hot when there's RAM load (meaning being used heavily),
> >> not
> >> when there's CPU load :*)
> >
> > Do you feel heat when your PC is turned on and running hard? Of course
> > you do. The whole machine heats up. The CPU under load heats the
> > machine so the RAM and drives and everything else heats up also. Not
> > as hot as the CPU, but it heats up. So I might agree with you - the
> > RAM might not be 'hot', but it would certainly be 'warmer'.
> >
> > I'm not suggesting that this would cause a normal DRAM stick to go
> > bad, but only that if he had a very marginal bit of RAM that it might
> > go out of spec...
>
> On a laptop maybe. On a desktop, the air around the RAM modules get
> maybe 1 degree C warmer (I know because I have temp sensor there,
> connected to the front panel).
me too - and the direction of air flow from the cpu cooler plus the warmth of
the air can change the temperature of the ram sticks by 5°C. So...
No, not 'laptop maybe'.
>
> When it does get warm is when there's GPU and disk load. Those suckers
> combined can raise the temp inside the box by 5-6 degrees.
those can raise it even more.
>
> The meaning of all this is that if memtest can't find any errors after a
> full run (which can take an hour), the chances of getting an > error that
> is really related to RAM under CPU stress are very slim.
a full run is more than 24h. Everything shorter is only of worth if you
already hit errors after a few minutes.
--
#163933
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-user] Re: Suspend to RAM caused crashes
2011-08-21 15:12 ` [gentoo-user] " Nikos Chantziaras
2011-08-21 15:22 ` Volker Armin Hemmann
2011-08-21 15:33 ` Mark Knecht
@ 2011-08-22 4:54 ` Francesco Talamona
2 siblings, 0 replies; 16+ messages in thread
From: Francesco Talamona @ 2011-08-22 4:54 UTC (permalink / raw
To: gentoo-user
On Sunday 21 August 2011, Nikos Chantziaras wrote:
> On 08/21/2011 02:19 PM, Francesco Talamona wrote:
> > I wish yours it's not a RAM
> >
> > issue, it could be tricky to spot, because memtest is not putting
> > any load to the machine, so it's very useful when it reports
> > error, but when it doesn't you can't be sure if RAM modules are in
> > good health.
>
> CPU load doesn't affect RAM errors. CPU load affects CPU errors. If
> you only get RAM errors during heavy load, the RAM is just fine, but
> your CPU has a fault.
I see your point: to better explain my statement I point you to
http://people.redhat.com/~dledford/memtest.shtml
The idea is that a "synthetic" test isn't guaranteed to repeat real life
conditions, so its results has to be interpreted rather than taken
acritically.
Cheers
Francesco
--
Linux Version 3.0.3-gentoo, Compiled #1 SMP PREEMPT Fri Aug 19 07:16:13
CEST 2011
Two 2.9GHz AMD Athlon 64 X2 Processors, 4GB RAM, 11659 Bogomips Total
aemaeth
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-08-22 4:56 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-21 10:27 [gentoo-user] Suspend to RAM caused crashes Mick
2011-08-21 11:19 ` [gentoo-user] " Francesco Talamona
2011-08-21 11:42 ` Mick
2011-08-21 11:57 ` [gentoo-user] " Pandu Poluan
2011-08-21 12:37 ` Mick
2011-08-21 15:12 ` [gentoo-user] " Nikos Chantziaras
2011-08-21 15:22 ` Volker Armin Hemmann
2011-08-21 15:33 ` Mark Knecht
2011-08-21 15:43 ` Nikos Chantziaras
2011-08-21 16:08 ` Mark Knecht
2011-08-21 16:26 ` Nikos Chantziaras
2011-08-21 17:27 ` Mark Knecht
2011-08-21 17:28 ` Volker Armin Hemmann
2011-08-22 4:54 ` Francesco Talamona
2011-08-21 12:53 ` [gentoo-user] " Volker Armin Hemmann
2011-08-21 15:30 ` meino.cramer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox