There are no sleeps between polls in the event poll thread, ref:
event_dispatch_poll(...).
I am not sure if we are referring to the same 'poll'. I haven't gotten a chance
to look into
this. I will try adding logs when I get back to this.
~kp
- Original Message -
Krishnan Parthasarathi
- Original Message -
On Wed, May 06, 2015 at 02:52:05AM -0400, Krishnan Parthasarathi wrote:
The following threads have only the top-most frame. Is that expected?
Not sure. info threads lists the threads, don't you have anything
outside ow lwp_park?
I do. I see 2 threads 'waiting'
Krishnan Parthasarathi kpart...@redhat.com wrote:
On gdb'ing into one of the brick process, I see the following backtrace.
This is seen with other threads in the process too. This makes it difficult
to analyse what could have gone wrong. Is there something I am missing?
Obviously frame 4 and
- Original Message -
Krishnan Parthasarathi kpart...@redhat.com wrote:
On gdb'ing into one of the brick process, I see the following backtrace.
This is seen with other threads in the process too. This makes it difficult
to analyse what could have gone wrong. Is there something I
Krishnan Parthasarathi kpart...@redhat.com wrote:
I do. I see 2 threads 'waiting' on posix_health_check_thread_proc, 3
threads 'blocked' on select(2) in the changelog xlator and the remaining
in lwp_park. I still don't see thread 'waiting' on poll(2), listening for
events on socket fds
- Original Message -
On Mon, May 04, 2015 at 09:20:45AM +0530, Atin Mukherjee wrote:
I see the following log from the brick process:
[2015-05-04 03:43:50.309769] E [socket.c:823:__socket_server_bind]
4-tcp.patchy-server: binding to failed: Address already in use
This
Krishnan Parthasarathi kpart...@redhat.com wrote:
We need help in getting gdb to work with proper stack frames. It is mostly
my lack of *BSD knowledge.
What problem do you run into?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
___
- Original Message -
Krishnan Parthasarathi kpart...@redhat.com wrote:
We need help in getting gdb to work with proper stack frames. It is mostly
my lack of *BSD knowledge.
What problem do you run into?
On gdb'ing into one of the brick process, I see the following backtrace.
On Mon, May 04, 2015 at 09:20:45AM +0530, Atin Mukherjee wrote:
[2015-05-04 03:43:50.309769] E [socket.c:823:__socket_server_bind]
4-tcp.patchy-server: binding to failed: Address already in use
It seems to even have trouble displaying it. I will have a look.
--
Emmanuel Dreyfus
On Mon, May 04, 2015 at 09:20:45AM +0530, Atin Mukherjee wrote:
I see the following log from the brick process:
[2015-05-04 03:43:50.309769] E [socket.c:823:__socket_server_bind]
4-tcp.patchy-server: binding to failed: Address already in use
This happens before the failing test 52 (volume
On 05/03/2015 11:26 PM, Atin Mukherjee wrote:
On 05/02/2015 08:52 PM, Emmanuel Dreyfus wrote:
Atin Mukherjee amukh...@redhat.com wrote:
Although I couldn't reproduce cdc.t failure but georep-setup.t failed
consistently and glusterd backtrace showed that it hangs on gverify.sh
That
On 05/02/2015 08:52 PM, Emmanuel Dreyfus wrote:
Atin Mukherjee amukh...@redhat.com wrote:
Although I couldn't reproduce cdc.t failure but georep-setup.t failed
consistently and glusterd backtrace showed that it hangs on gverify.sh
That suggests the script itself blocks forever. Runnig
12 matches
Mail list logo
