Hi,
The application does writing only and I’m sseing that after the output
buffer is filled Dev stops calling my serial driver. The buffer length is
currently set as default to 2048. I’m updating the tail, size properly. I’m
also seeing that head pointer is also rolled back by Dev. The application
keeps writing and the following messages are by tracelogger with each of the
application write.
Jul 08 07:34:10 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Jul 08 07:34:11 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Jul 08 07:34:12 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Any idea what I’m not doing or doing wrong?
Thanks,
Hakim
Hakim <ddrv2002@yahoo.ca> wrote:
Hi,
The application does writing only and I’m sseing that after the output
buffer is filled Dev stops calling my serial driver. The buffer length is
currently set as default to 2048. I’m updating the tail, size properly. I’m
also seeing that head pointer is also rolled back by Dev. The application
keeps writing and the following messages are by tracelogger with each of the
application write.
Jul 08 07:34:10 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Jul 08 07:34:11 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Jul 08 07:34:12 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
A “Msg fault” says that the pointer & length combination passed to a
Send/Receive/Reply is invalid, that is, that it refers to memory
that is not part of the address space of the calling program.
(Or, to put it another way, if it wasn’t the kernel trying to
write to or read from the memory, the program would have died of
a SIGSEGV.)
So, I’d say that either the buffer passed to write() is bad, or
the buffer passed to the Receive() insed Dev32 is bad, or that
Dev32 might be doing a ReadMsg() into a buffer from your driver,
and that buffer is bad.
I don’t know enough about the head/tail stuff inside the Dev drivers
to say what on that side might have triggered it.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
Thanks, your information makes sense.
I’m giving my child process the pointer access of output buffer by
qnx_segment_arm-MK_FP way. The buffers are allocated by Dev on behalf of my
serial driver. If my child process doesn’t make the pointers then everything
goes fine. I’m wondering whether my child process can get those pointers
properly since Dev is allocating the buffer not my serial driver. The
confusing thing is that the buffer member values are assigned and checked
between parent and child and they are exact.
Any idea on this matter?
Thanks,
Hakim
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:dajl2p$a3g$1@inn.qnx.com…
Hakim <> ddrv2002@yahoo.ca> > wrote:
Hi,
The application does writing only and I’m sseing that after the output
buffer is filled Dev stops calling my serial driver. The buffer length is
currently set as default to 2048. I’m updating the tail, size properly.
I’m
also seeing that head pointer is also rolled back by Dev. The application
keeps writing and the following messages are by tracelogger with each of
the
application write.
Jul 08 07:34:10 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Jul 08 07:34:11 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
Jul 08 07:34:12 2 00001012 Msg fault 16 0004 0001 //1/bin/Dev32
A “Msg fault” says that the pointer & length combination passed to a
Send/Receive/Reply is invalid, that is, that it refers to memory
that is not part of the address space of the calling program.
(Or, to put it another way, if it wasn’t the kernel trying to
write to or read from the memory, the program would have died of
a SIGSEGV.)
So, I’d say that either the buffer passed to write() is bad, or
the buffer passed to the Receive() insed Dev32 is bad, or that
Dev32 might be doing a ReadMsg() into a buffer from your driver,
and that buffer is bad.
I don’t know enough about the head/tail stuff inside the Dev drivers
to say what on that side might have triggered it.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
Hakim <ddrv2002@yahoo.ca> wrote:
Thanks, your information makes sense.
I’m giving my child process the pointer access of output buffer by
qnx_segment_arm-MK_FP way. The buffers are allocated by Dev on behalf of my
serial driver. If my child process doesn’t make the pointers then everything
goes fine. I’m wondering whether my child process can get those pointers
properly since Dev is allocating the buffer not my serial driver. The
confusing thing is that the buffer member values are assigned and checked
between parent and child and they are exact.
Any idea on this matter?
Are you passing the pointers created by MK_FP to the Send/Receive/Reply
calls? Because, MK_FP gives a 48-bit pointer (16 bit segment, 32 bit
offset) and all of the C library functions take a 32-bit (local) pointer,
which means that your 48-bit far pointer will be truncated to 32 bits, and
probably result in an invalid address.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
Are you passing the pointers created by MK_FP to the Send/Receive/Reply
calls?
No.
Because, MK_FP gives a 48-bit pointer (16 bit segment, 32 bit
offset) and all of the C library functions take a 32-bit (local) pointer,
which means that your 48-bit far pointer will be truncated to 32 bits, and
probably result in an invalid address.
My driver does not use the buffer in any routines just updates the tail
pointer and size member but Dev may have something that uses those routines
with the buffer as an argument. This is likely the case. I’m wondering how
can I get to the bottom of this pointer issue.
Thanks,
Hakim
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:dajr4i$ekb$1@inn.qnx.com…
Hakim <> ddrv2002@yahoo.ca> > wrote:
Thanks, your information makes sense.
I’m giving my child process the pointer access of output buffer by
qnx_segment_arm-MK_FP way. The buffers are allocated by Dev on behalf of
my
serial driver. If my child process doesn’t make the pointers then
everything
goes fine. I’m wondering whether my child process can get those pointers
properly since Dev is allocating the buffer not my serial driver. The
confusing thing is that the buffer member values are assigned and checked
between parent and child and they are exact.
Any idea on this matter?
Are you passing the pointers created by MK_FP to the Send/Receive/Reply
calls? Because, MK_FP gives a 48-bit pointer (16 bit segment, 32 bit
offset) and all of the C library functions take a 32-bit (local) pointer,
which means that your 48-bit far pointer will be truncated to 32 bits, and
probably result in an invalid address.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
Hakim <ddrv2002@yahoo.ca> wrote:
Are you passing the pointers created by MK_FP to the Send/Receive/Reply
calls?
No.
Dev might be.
Because, MK_FP gives a 48-bit pointer (16 bit segment, 32 bit
offset) and all of the C library functions take a 32-bit (local) pointer,
which means that your 48-bit far pointer will be truncated to 32 bits, and
probably result in an invalid address.
My driver does not use the buffer in any routines just updates the tail
pointer and size member but Dev may have something that uses those routines
with the buffer as an argument. This is likely the case. I’m wondering how
can I get to the bottom of this pointer issue.
I’m sorry, but I don’t know enough about the Dev/Dev.driver interface
to help much more.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com