On 11/23/2011 9:57 AM, Lukas Razik wrote:
Which now leads me to wondering if this is due to the coalescing
code. If you can run with coalescing off (as described in my last
email) that might be telling.
TERRY DONTJE <firstname.lastname@example.org> wrote:
On 11/22/2011 6:59 PM, Lukas Razik wrote:
Roland Dreier<email@example.com> wrote:
On Tue, Nov 22, 2011 at 3:05 PM, Lukas Razik<firstname.lastname@example.org>
#0 0xfffff8010229ba9c in mca_pml_ob1_send_request_start_copy
(sendreq=0xb23200, bml_btl=0xb29050, size=0) at pml_ob1_sendreq.c:551
551 hdr->hdr_match.hdr_ctx =
If you can get into gdb here, I guess it would be useful to print the
address of hdr->hdr_match.hdr_ctx and
sendreq->req_send.req_base.req_comm->c_contextid to see which one
Not sure of the gdb syntax... does it work to just do
p&hdr->hdr_match.hdr_ctx and sendreq->req_send.req_base.req
Oh, sorry that I didn't do that before...
The values are:
&hdr->hdr_match.hdr_ctx and sendreq->req_send.req_base.req =
(uint16_t *) 0xad7393
&sendreq->req_send.req_base.req_comm->c_contextid = (uint32_t
So hdr_ctx is the bad one...
I always don't know the syntax of gdb - hence I use the nice kdbg. *g*
Can you get me the value of hdr too. I bet it is an odd value too.
You're right! :)
The value of hdr you can see in the first screenshot I've sent sent you:
hdr = (mca_pml_ob1_hdr_t*) 0xad7391
Terry D. Dontje | Principal
Engineering | +1.781.442.2631
95 Network Drive, Burlington, MA 01803