[gentoo-user] Suspend to RAM caused crashes

[gentoo-user] Suspend to RAM caused crashes

[Mick]

[-- 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 --]

[gentoo-user] Re: Suspend to RAM caused crashes

[Francesco Talamona]

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

Re: [gentoo-user] Re: Suspend to RAM caused crashes

[Mick]

[-- 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 --]

Re: [gentoo-user] Suspend to RAM caused crashes

[Pandu Poluan]

(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/

Re: [gentoo-user] Suspend to RAM caused crashes

[Mick]

[-- 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 --]

[gentoo-user] Re: Suspend to RAM caused crashes

[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.

Re: [gentoo-user] Re: Suspend to RAM caused crashes

[Volker Armin Hemmann]

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

Re: [gentoo-user] Re: Suspend to RAM caused crashes

[Mark Knecht]

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

[gentoo-user] Re: Suspend to RAM caused crashes

[Nikos Chantziaras]

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 :*)

Re: [gentoo-user] Re: Suspend to RAM caused crashes

[Mark Knecht]

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

[gentoo-user] Re: Suspend to RAM caused crashes

[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).

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.

Re: [gentoo-user] Re: Suspend to RAM caused crashes

[Mark Knecht]

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

Re: [gentoo-user] Re: Suspend to RAM caused crashes

[Volker Armin Hemmann]

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

[gentoo-user] Re: Suspend to RAM caused crashes

[Francesco Talamona]

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

Re: [gentoo-user] Suspend to RAM caused crashes

[Volker Armin Hemmann]

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

Re: [gentoo-user] Suspend to RAM caused crashes

[meino.cramer]

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