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
next prev parent 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®