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
