xfs
[Top] [All Lists]

Re: 3.9.0: general protection fault

To: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx>
Subject: Re: 3.9.0: general protection fault
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 7 May 2013 11:12:54 +1000
Cc: linux-xfs@xxxxxxxxxxx
Delivered-to: linux-xfs@xxxxxxxxxxx
In-reply-to: <5187A663.707@xxxxxxxxxxxxxxxxxx>
References: <kltu6o$33j$1@xxxxxxxxxxxxx> <km7oop$28c$1@xxxxxxxxxxxxx> <20130506122844.GL19978@dastard> <5187A663.707@xxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, May 06, 2013 at 02:47:31PM +0200, Bernd Schubert wrote:
> On 05/06/2013 02:28 PM, Dave Chinner wrote:
> >On Mon, May 06, 2013 at 10:14:22AM +0200, Bernd Schubert wrote:
> >>And anpther protection fault, this time with 3.9.0. Always happens
> >>on one of the servers. Its ECC memory, so I don't suspect a faulty
> >>memory bank. Going to fsck now-
> >
> >http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> 
> Isn't that a bit overhead? And I can't provide /proc/meminfo and
> others, as this issue causes a kernel panic a few traces later.

Provide what information you can.  Without knowing a single thing
about your hardware, storage config and workload, I can't help you
at all. You're asking me to find a needle in a haystack blindfolded
and with both hands tied behind my back....

Stuff like /proc/meminfo doesn't have to be provided from exactly
the time of the crash - it's just the simplest way to find out how
much RAM you have in the machine, so a dump from whenever the
machine is up and running the workload is fine. Other information we
ask for (e.g. capturing the output of `vmstat 5` as suggested in the
FAQ) gives us the runtime variation of memory usage and easy to
capture right up to the failure point....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>