mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: "Ammar T. Al-Sayegh" <ammar@kunet.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel BUG at mm/rmap.c:483!
Date: Thu, 24 Feb 2005 05:31:06 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0502240512330.5427@goblin.wat.veritas.com> (raw)
In-Reply-To: <005e01c519f8$65ba5020$7101a8c0@shrugy>

On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
> ----- Original Message ----- From: "Hugh Dickins" <hugh@veritas.com>
> > though quite possibly you cannot afford
> > such experiments on this server, and will revert to 2.4 for now.
> 
> The problem is that my server is already in production
> mode. I'm running great portion of my business on it,
> where there is very little tolerance for downtime.

I feared as much.

> Because the server is located in a remote datacenter,
> every time it goes down it takes several hours to have
> someone sent up there to manually reboot it for a hefty
> emergency fee. So this bug has already cost me a lot of
> money, and I'm worried that it will cost me a lot of my
> clients as well if it persists.

I'm very sorry for that.

> Remote hands are rather expensive, so it will cost me
> $100/hr to have someone runs memtest86 on my server
> since I can't perform it remotely. I'll do it though
> since that's your recommendation for the time being.
> Hope it will not take more than an hour to run the
> test, and hope it turns out as bad memory modules as
> you expect because I hate to downgrade after all the
> time and money I expended on the upgrade.

One hour will be enough if it does find a problem in that time,
worth a shot; but not enough to give confidence in the memory
if it does not find one, 12 hours better.  I actually wonder
whether rmap.c:483 is the best memory tester (serious answer
would be, in some cases yes, but not in all).

Do let me know.  If I can find time to rejig the debug patch
against your kernel, it would itself keep your server running,
replacing the BUG_ON by printks and safety.  But without knowing
what it will report, I can't judge how satisfactory that would
be (and it's unlikely to lead us to the final answer in one go).

Hugh

  reply	other threads:[~2005-02-24  5:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-23 20:41 Ammar T. Al-Sayegh
2005-02-23 20:54 ` Arjan van de Ven
2005-02-23 21:45   ` Ammar T. Al-Sayegh
2005-02-23 22:01     ` Arjan van de Ven
2005-02-23 22:46       ` Ammar T. Al-Sayegh
2005-02-24  8:38         ` Arjan van de Ven
2005-02-24  9:25           ` Ammar T. Al-Sayegh
2005-02-24  9:30             ` Arjan van de Ven
2005-02-28 10:43               ` Giacomo A. Catenazzi
2005-02-28 11:09                 ` Arjan van de Ven
2005-02-23 21:31 ` Hugh Dickins
2005-02-23 22:38   ` Ammar T. Al-Sayegh
2005-02-24  5:31     ` Hugh Dickins [this message]
2005-02-24 13:25   ` Horst von Brand
2005-02-23 22:05 Nick Warne
2005-02-24 12:15 ` Hugh Dickins

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=Pine.LNX.4.61.0502240512330.5427@goblin.wat.veritas.com \
    --to=hugh@veritas.com \
    --cc=ammar@kunet.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®