From: Yucheng Low <ylow@andrew.cmu.edu>
To: Ray Lee <ray-lk@madrabbit.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: System Freeze on Particular workload with kernel 2.6.22.6
Date: Thu, 20 Sep 2007 21:04:12 -0400 [thread overview]
Message-ID: <46F3188C.1040902@andrew.cmu.edu> (raw)
In-Reply-To: <2c0942db0709200914p5ba04307pee519d4991f62299@mail.gmail.com>
Hi all,
Thanks all. After lots of testing, I isolated the problem to one of the
memory modules.
Thought it might have been a kernel problem as I thought memtest should
be exhaustive enough considering I ran it for so long, but apparently not...
Even now, the bad module still does not show any errors in memtest...
Thanks,
Yucheng
Ray Lee wrote:
> On 9/19/07, Low Yucheng <ylow@andrew.cmu.edu> wrote:
>
>> [1.] Summary
>> System Freeze on Particular workload with kernel 2.6.22.6
>>
>> [2.] Description
>> System freezes on repeated application of the following command
>> for f in *png ; do convert -quality 100 $f `basename $f png`jpg; done
>>
>> Problem is consistent and repeatable.
>> Problem persists when running on a different drive, and also in pure console (no X).
>>
>> One time, the following error logged in syslog:
>> Sep 19 04:22:11 mossnew kernel: [ 301.883919] VM: killing process convert
>> Sep 19 04:22:11 mossnew kernel: [ 301.884382] swap_free: Unused swap offset entry 0000ff00
>> Sep 19 04:22:11 mossnew kernel: [ 301.884421] swap_free: Unused swap offset entry 00000300
>> Sep 19 04:22:11 mossnew kernel: [ 301.884456] swap_free: Unused swap offset entry 00000200
>> Sep 19 04:22:11 mossnew kernel: [ 301.884491] swap_free: Unused swap offset entry 0000ff00
>> Sep 19 04:22:11 mossnew kernel: [ 301.884527] swap_free: Unused swap offset entry 0000ff00
>> Sep 19 04:22:11 mossnew kernel: [ 301.884562] swap_free: Unused swap offset entry 00000100
>>
>> Should not be a RAM problem. RAM has survived 12 hrs of Memtest with no errors.
>> Should not be a CPU problem either. I have been running CPU intensive tasks for days.
>>
>
> The "Unused swap offset entry" is almost always a sign of bad memory,
> if google can be trusted. Your workload is *extremely* CPU and memory
> intensive (and even hits the disk!), so this looks like bad RAM, bad
> cooling, or a marginal power supply that is failing under load.
>
> memtest86+ doesn't stress the CPU nearly as much, so it often doesn't
> show all the problems.
>
> Take your RAM down to one stick and try again (looks like you have 2G
> installed?). If that still fails, try different RAM. If that still
> fails, then swap out the power supply for another if you can, and try
> again.
>
> Ray
>
>
prev parent reply other threads:[~2007-09-21 1:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-19 8:45 Low Yucheng
2007-09-19 15:47 ` Oleg Verych
2007-09-19 16:16 ` Low Yucheng
2007-09-19 19:25 ` Ahmed S. Darwish
2007-09-20 10:00 ` Jarek Poplawski
2007-09-20 15:24 ` Ahmed S. Darwish
2007-12-01 22:39 ` Daniel Phillips
2007-09-20 16:14 ` Ray Lee
2007-09-21 1:04 ` Yucheng Low [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46F3188C.1040902@andrew.cmu.edu \
--to=ylow@andrew.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=ray-lk@madrabbit.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome