[Top] [All Lists]

Re: 3.9.0: general protection fault

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: 3.9.0: general protection fault
From: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx>
Date: Mon, 06 May 2013 14:47:31 +0200
Cc: linux-xfs@xxxxxxxxxxx
Delivered-to: linux-xfs@xxxxxxxxxxx
In-reply-to: <20130506122844.GL19978@dastard>
References: <kltu6o$33j$1@xxxxxxxxxxxxx> <km7oop$28c$1@xxxxxxxxxxxxx> <20130506122844.GL19978@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
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-


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.

[303340.514052] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[303340.517913] Modules linked in: fhgfs(O) fhgfs_client_opentk(O)

Kernel tainted with out of tree modules. Can you reproduce the
problem with them?

The modules are unused, as this is the server side. I disabled client packages now and will re-run. But I really think that we should look for memory/list corruption outside of fhgfs. Also very unlikely that always only xfs would suffer, as there is also running ext4 for fhgfs meta data. Also, it took from Friday evening till this morning to run into the crash, so the next occurance might take some time. And I think tracing xfs is out of question, as I need the disk space to store data (the client side is running our stress test suite).


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