[Gluster-users] The continuing story ...

[Stephan von Krawczynski]

On Wed, 9 Sep 2009 23:17:07 +0530
Anand Avati <avati at gluster.com> wrote:

> So I'm really wondering, what is it that is making you believe that
> you are going to get a solution for this particular problem on the
> gluster mailing lists? You clearly have soft lockup backtraces from
> the kernel pointing to various kernel subsystems. Have you even
> reported this log dump to the linux-kernel mailing list? That is the
> first thing anybody does when they have a kernel backtrace in dmesg -
> report to LKML. Unlike what you have been telling that all you have in
> your kernel log is just a single line indicating a soft lockup, your
> kernel log below has a whole wealth of info and backtraces which are
> going to help you get the issue diagnosed a lot faster on the LKML
> than here. Apparantly they have not appeared to you as backtraces, but
> there are backtraces some of which go through tcpip ARP table
> management, ACPI (power save?) cpu shutdown, etc. I fail to see how
> any of these are related to glusterfs. No amount of messed up pointers
> or race conditions in glusterfsd can ever result in your kernel
> landing in this state. This is not windows 3.1 where apps and kernel
> run in the same address space. Just because glusterfs was being used
> at the time of this lockup, you are putting your efforts in trying to
> get a solution on this list, without ever working on the first direct
> evidence you have at hand - these kernel backtraces.
> 
> Please reply back to this thread only after you have a response from
> the appropriate kernel developer indicating that the cause of this
> lockup is because of a misbehaving userspace application. After that,
> let us give you the benefit of doubt that the misbehaving userspace
> process is glusterfsd and then continue any further debugging. It is
> not that we do not want to help you, but we really are pointing you to
> the right place where your problem can actually get fixed. You have
> all the necessary input they need.
> 
> Avati

This is the kind of statement that often drives listeners to think about a
project fork...

-- 
Regards,
Stephan