All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Jaco Kroon <jkroon@cs.up.ac.za>
Cc: Fredrik Steen <fredrik@stone.nu>,
	linux-kernel@vger.kernel.org, dwmw2@infradead.org
Subject: Re: 2.4: kernel BUG at inode.c:334!
Date: Tue, 30 Mar 2004 13:51:52 -0300	[thread overview]
Message-ID: <20040330165152.GA5989@logos.cnet> (raw)
In-Reply-To: <4069898D.90005@cs.up.ac.za>

On Tue, Mar 30, 2004 at 04:51:57PM +0200, Jaco Kroon wrote:

> So this seems to be a more general problem (My co-worker suspects ext3 - 
> since this bug report started with xfs that might not be the case).  The 
> only pattern we are seeing between all of these is that they serve as 
> nfs servers (but on mine at home it still dies, even when not serving 
> nfs - it still is a nfs client when it dies though), are not the newest 
> and greatest machines and all of them use ext3 as their root file 
> system.  Oh, also, usually shortly after, or during, intensive disk io - 
> which match up with what Mika mentioned.  I've also tried disabling 
> IO-APIC (which we're not even sure is supported, but APIC is), as well 
> as pre-empting.
> 
> We don't suspect nfs on the production machines anymore since we managed 
> to trash the nfs exported dir for about an hour (keeping the server at 
> load average 8.5) which makes use of reiserfs - we might've been lucky 
> though.  In almost all the cases these exports are relatively big 
> though, and I noticed there is a problem there as well (We don't get the 
> magical 1000 number quite yet).
> 
> Is there anything else I should/can take a look at?  Is there any other 
> way in which I can help find the problem?  If I can just get somewhere 
> to start ... (The patch below doesn't apply to 2.6 as far as I can see).
> 
> Apologies for the essay.

Jaco, 

The "kernel BUG at inode.c:340" problem is fixed in 2.4.26-rc1. 
If that was what you were hitting, can you try that on  your servers

About the other crashes, its hard to help without more information. Try attaching
a serial cable to the box for serial console.

      reply	other threads:[~2004-03-30 17:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-25 17:32 [Bug 2367] New: kernel BUG at inode.c:334! Martin J. Bligh
     [not found] ` <20040326154915.GC3472@logos.cnet>
2004-03-26 15:58   ` Marcelo Tosatti
     [not found]     ` <20040326154000.GA28389@panic.unixguru.info>
2004-03-26 18:39       ` 2.4: " Marcelo Tosatti
2004-03-30 14:51         ` Jaco Kroon
2004-03-30 16:51           ` Marcelo Tosatti [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=20040330165152.GA5989@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=dwmw2@infradead.org \
    --cc=fredrik@stone.nu \
    --cc=jkroon@cs.up.ac.za \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.