(qnet makes my brain squishy)

Can pidin detect this and print something more meaningful?

Xiaodan Tang wrote:
> On client side, if you MsgSend() cross QNET, pidin show you block on
> server_pid@server.
> 
> On server side, it is qnet (vthread) sending to real server (NETCON);
> when the server decided to "MsgRead()", it is blocked on the same
> connection, hance the pidin report it block on itself (cop->chn->proc).
> 
> -xtang
>  
> 
>> -----Original Message-----
>> From: Colin Burgess [mailto:community-noreply@qnx.com] 
>> Sent: Thursday, February 05, 2009 3:56 PM
>> To: ostech-core_os
>> Subject: Re: A bug with MsgReadv in 6.3.0 SP2 kernel???
>>
>> Looking at the code that seems to be the case (ker_msg_readv 
>> -> lookup_rcvid -> net_send2) but why is pidin not reporting 
>> the pid@<node> information?
>>
>> Xiaodan Tang wrote:
>>> Reply Block "on itself", is usually a sign that a server thread
>>> MsgRead() a client message from remote node.
>>> Is this the case?
>>>
>>> -xtang
>>>
>>>> -----Original Message-----
>>>> From: Oleh Derevenko [mailto:community-noreply@qnx.com]
>>>> Sent: Thursday, February 05, 2009 1:53 PM
>>>> To: ostech-core_os
>>>> Subject: Re: A bug with MsgReadv in 6.3.0 SP2 kernel???
>>>>
>>>> No, GDB thread 64 is also kernel thread 64
>>>>
>>>> (gdb) p {CUNIXThreadDescriptor}m_pHostThread
>>>> $5 = {m_pThreadID = 0x40, m_lRefCount = 2, 
>> m_ai_RunningMutexStorage = 
>>>> {65538, 64, -2147483647, 1348403264}}
>>>>
>>>> Here m_pThreadID = 0x40 is the thread ID returned by
>>>> pthread_self() when a pool thread starts executing.
>>>>
>>>> _______________________________________________
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post21504
>>>>
>>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post21523
>>>
>> --
>> cburgess@qnx.com
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post21536
>>
>>
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post21537
> 

-- 
cburgess@qnx.com

The MsgReadv is in _resmgr_unblock_handler.

The thread 24 on the client should still be REPLY blocked on the server at this point... I would think!

Xiaodan Tang wrote:
> The message looks like an _IO_READ (0x0101) with nbyte 5;
> I am not sure why this would causing a MsgRead(). 
> 
> Being said that, blocking a MsgRead() forever is also not the right
> thing to
> happen...
> 
> -xtang
> 
> 
>> -----Original Message-----
>> From: Oleh Derevenko [mailto:community-noreply@qnx.com] 
>> Sent: Thursday, February 05, 2009 4:17 PM
>> To: ostech-core_os
>> Subject: Re: RE: A bug with MsgReadv in 6.3.0 SP2 kernel???
>>
>> Yes, the request has come from the another node.
>>
>> (gdb) fr 6
>> #6  0x080ad8b1 in CResourceManager::ProcessRequest 
>> (this=0x83dca28, pdcRequest=0x8425288) at 
>> /home/masha/rel6776/Src/shared/common/rm.cpp:774
>> 774             dispatch_handler(pdcRequest);
>> (gdb) p pdcRequest[0]
>> $6 = {resmgr_context = {rcvid = 8650979, info = {nd = 7, 
>> srcnd = 155, pid = 14934133, tid = 24, chid = 185, scoid = 
>> 1073742051, coid = 12, msglen = 16,
>>       srcmsglen = 16, dstmsglen = 2147483647, priority = 12, 
>> flags = 256, reserved = 0}, msg = 0x84252e4, dpp = 0x8347888, 
>> id = -1, tid = 0, msg_max_size = 4104,
>>     status = 0, offset = 0, size = 4, iov = {{iov_base = 
>> 0x84252e4, iov_len = 60}}}, message_context = {rcvid = 
>> 8650979, info = {nd = 7, srcnd = 155,
>>       pid = 14934133, tid = 24, chid = 185, scoid = 
>> 1073742051, coid = 12, msglen = 16, srcmsglen = 16, dstmsglen 
>> = 2147483647, priority = 12, flags = 256,
>>       reserved = 0}, msg = 0x84252e4, dpp = 0x8347888, id = 
>> -1, tid = 0, msg_max_size = 4104, status = 0, offset = 0, 
>> size = 4, iov = {{iov_base = 0x84252e4,
>>         iov_len = 60}}}, select_context = {rcvid = 8650979, 
>> info = {msginfo = {nd = 7, srcnd = 155, pid = 14934133, tid = 
>> 24, chid = 185, scoid = 1073742051,
>>         coid = 12, msglen = 16, srcmsglen = 16, dstmsglen = 
>> 2147483647, priority = 12, flags = 256, reserved = 0}, 
>> siginfo = {si_signo = 7, si_code = 155,
>>         si_errno = 14934133, __data = {__pad = {24, 185, 
>> 1073742051, 12, 16, 16, 2147483647}, __proc = {__pid = 24, 
>> __pdata = {__kill = {__uid = 185, __value = {
>>                   sival_int = 1073742051, sival_ptr = 
>> 0x400000e3}}, __chld = {__utime = 185, __status = 1073742051, 
>> __stime = 12}}}, __fault = {__fltno = 24,
>>             __fltip = 0xb9, __addr = 0x400000e3}}}}, msg = 
>> 0x84252e4, dpp = 0x8347888, fd = -1, tid = 0, reserved = 
>> 4104, flags = 0, reserved2 = {0, 4}, iov = {{
>>         iov_base = 0x84252e4, iov_len = 60}}}, 
>> sigwait_context = {signo = 8650979, info = {msginfo = {nd = 
>> 7, srcnd = 155, pid = 14934133, tid = 24, chid = 185,
>>         scoid = 1073742051, coid = 12, msglen = 16, srcmsglen 
>> = 16, dstmsglen = 2147483647, priority = 12, flags = 256, 
>> reserved = 0}, siginfo = {si_signo = 7,
>>         si_code = 155, si_errno = 14934133, __data = {__pad = 
>> {24, 185, 1073742051, 12, 16, 16, 2147483647}, __proc = 
>> {__pid = 24, __pdata = {__kill = {
>>                 __uid = 185, __value = {sival_int = 
>> 1073742051, sival_ptr = 0x400000e3}}, __chld = {__utime = 
>> 185, __status = 1073742051, __stime = 12}}},
>>           __fault = {__fltno = 24, __fltip = 0xb9, __addr = 
>> 0x400000e3}}}}, msg = 0x84252e4, dpp = 0x8347888, status = 
>> -1, tid = 0, set = {bits = {4104, 0}},
>>     reserved2 = {0, 4}, iov = {{iov_base = 0x84252e4, iov_len = 60}}}}
>> (gdb) x/16b...