|
Dave Bott(deleted)
|
libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/21/2009 11:28 AM
post20504
|
libsocket in a devn driver ?
A customer is writing a custom io-net-style driver for a Broadcom switch, although they want to use it in 6.4.0 with io-
pkt and the shim driver.
They're seeing it crash in resolve_rels() right at the start, and I suspect it is because they are linking in libsocket.
so.2.
Am I correct in thinking that that is not legitimate from within a network driver ?
If they do need socket access from inside the driver, is there a legitimate way to do it, or do they need to run an
external process to do that ?
Thanks !
Dave
|
|
|
|
|
|
Andrew Boyd(deleted)
|
RE: libsocket in a devn driver ?
|
|
Andrew Boyd(deleted)
01/21/2009 11:30 AM
post20506
|
RE: libsocket in a devn driver ?
I'm not sure why you would want libsocket in a
network driver. You could end up with a problem
with deadlocking.
Can you tell us more about what problem they're
trying to solve?
--
aboyd
|
|
|
|
|
|
Dave Bott(deleted)
|
Re: RE: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/21/2009 3:43 PM
post20529
|
Re: RE: libsocket in a devn driver ?
[That was fast !]
Good question - I've asked them...
Here's what they say:
"
My devn-bcm5696.so driver is an io-net driver. It uses devnp-shim.so as its wrapper to io-pkt. The code works with 6.3.0
(debug or no-debug version). devn-bcm5696.so does not call any libsocket stuff, the io-pkt does.
If my code is wrong, it should cause functional failure not dynamic loader failure (dlopen traceback).
If I ran iopkt+devn-5696.so via serial console, the code loads, but failed at later stage, i.e. bcm server attach
(interface to bcm server). That is why I need to run the debugger.
I have looked Freescale FCC3 driver, but my code requires to create 13 interfaces, it is quite different from other
drivers.
I wonder if there is a way to link io-pkt devn-bcm5696 and devnp-shim statically?
"
So, it sounds like a real problem on our end doesn't it ? The driver loads in io-net but not io-pkt..
Any suggestions ?
Thanks !
Dave
|
|
|
|
|
|
Robert Craig
|
RE: RE: libsocket in a devn driver ?
|
|
Robert Craig
01/21/2009 3:56 PM
post20534
|
RE: RE: libsocket in a devn driver ?
I think that this is the same issue as was being discussed here
http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/
discussion.drivers.topc3557
If its creating 13 interfaces on the fly, it sounds very different from
our standard drivers which create a single interface per instantiation.
If they are using the advertise packet to instantiate multiplee
interfaces, this doesn't appear to be supported under io-pkt.
Robert.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Wednesday, January 21, 2009 3:44 PM
To: drivers-networking
Subject: Re: RE: libsocket in a devn driver ?
[That was fast !]
Good question - I've asked them...
Here's what they say:
"
My devn-bcm5696.so driver is an io-net driver. It uses devnp-shim.so as
its wrapper to io-pkt. The code works with 6.3.0 (debug or no-debug
version). devn-bcm5696.so does not call any libsocket stuff, the io-pkt
does.
If my code is wrong, it should cause functional failure not dynamic
loader failure (dlopen traceback).
If I ran iopkt+devn-5696.so via serial console, the code loads, but
failed at later stage, i.e. bcm server attach (interface to bcm server).
That is why I need to run the debugger.
I have looked Freescale FCC3 driver, but my code requires to create 13
interfaces, it is quite different from other drivers.
I wonder if there is a way to link io-pkt devn-bcm5696 and devnp-shim
statically?
"
So, it sounds like a real problem on our end doesn't it ? The driver
loads in io-net but not io-pkt..
Any suggestions ?
Thanks !
Dave
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20529
|
|
|
|
|
|
Dave Bott(deleted)
|
Re: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/21/2009 3:59 PM
post20535
|
Re: libsocket in a devn driver ?
Hi Robert,
Thanks for the reply.
OK, so if they can't do this in advertise packet, that still doesn't
explain why they crash in the debugger does it ?
And, how should they advertise their interfaces ?
Dave
Robert Craig wrote:
>
> I think that this is the same issue as was being discussed here
>
> http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/
> discussion.drivers.topc3557
>
> If its creating 13 interfaces on the fly, it sounds very different from
> our standard drivers which create a single interface per instantiation.
> If they are using the advertise packet to instantiate multiplee
> interfaces, this doesn't appear to be supported under io-pkt.
>
> Robert.
>
>
>
>
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: Wednesday, January 21, 2009 3:44 PM
> To: drivers-networking
> Subject: Re: RE: libsocket in a devn driver ?
>
> [That was fast !]
>
> Good question - I've asked them...
>
> Here's what they say:
> "
> My devn-bcm5696.so driver is an io-net driver. It uses devnp-shim.so as
> its wrapper to io-pkt. The code works with 6.3.0 (debug or no-debug
> version). devn-bcm5696.so does not call any libsocket stuff, the io-pkt
> does.
>
> If my code is wrong, it should cause functional failure not dynamic
> loader failure (dlopen traceback).
>
> If I ran iopkt+devn-5696.so via serial console, the code loads, but
> failed at later stage, i.e. bcm server attach (interface to bcm server).
> That is why I need to run the debugger.
>
> I have looked Freescale FCC3 driver, but my code requires to create 13
> interfaces, it is quite different from other drivers.
>
> I wonder if there is a way to link io-pkt devn-bcm5696 and devnp-shim
> statically?
> "
>
> So, it sounds like a real problem on our end doesn't it ? The driver
> loads in io-net but not io-pkt..
>
> Any suggestions ?
>
> Thanks !
>
> Dave
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post20529
>
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post20534
>
--
Dave Bott (dbott@qnx.com) Field Applications Engineer
QNX Software Systems, Inc. Voice: 408-879-7230
900 E. Hamilton Ave #100 Fax:408-879-7221
Campbell CA 95008 Cell:408 391-3535
Join Foundry27 <http://community.qnx.com>; - the new QNX developer forum.
|
|
|
|
|
|
Andrew Boyd(deleted)
|
RE: libsocket in a devn driver ?
|
|
Andrew Boyd(deleted)
01/21/2009 4:07 PM
post20536
|
RE: libsocket in a devn driver ?
> how should they advertise their interfaces?
An io-net driver should create each interface
by using the ion->register function call. This
call takes a "registrant" structure, which in
turn points to a "registrant_funcs" structure.
io-net will call their advertise function as
required - say, after a new protocol is loaded.
In the io-net world, each network interface is
described with "cell" and "endpoint" / "lan"
values, to distinguish between them.
Looking at the source to an existing io-net
driver which registers two interfaces - reasonably
common - might be a good place to start.
--
aboyd
|
|
|
|
|
|
Dave Bott(deleted)
|
Re: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/21/2009 4:50 PM
post20541
|
Re: libsocket in a devn driver ?
Hi Robert,
Yes, it's the same issue - it's the same engineer and driver ! :-)
Thanks !
Dave
Robert Craig wrote:
>
> I think that this is the same issue as was being discussed here
>
> http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/
> discussion.drivers.topc3557
>
> If its creating 13 interfaces on the fly, it sounds very different from
> our standard drivers which create a single interface per instantiation.
> If they are using the advertise packet to instantiate multiplee
> interfaces, this doesn't appear to be supported under io-pkt.
>
> Robert.
>
>
>
>
> -----Original Message-----
> From: Dave Bott [mailto:community-noreply@qnx.com]
> Sent: Wednesday, January 21, 2009 3:44 PM
> To: drivers-networking
> Subject: Re: RE: libsocket in a devn driver ?
>
> [That was fast !]
>
> Good question - I've asked them...
>
> Here's what they say:
> "
> My devn-bcm5696.so driver is an io-net driver. It uses devnp-shim.so as
> its wrapper to io-pkt. The code works with 6.3.0 (debug or no-debug
> version). devn-bcm5696.so does not call any libsocket stuff, the io-pkt
> does.
>
> If my code is wrong, it should cause functional failure not dynamic
> loader failure (dlopen traceback).
>
> If I ran iopkt+devn-5696.so via serial console, the code loads, but
> failed at later stage, i.e. bcm server attach (interface to bcm server).
> That is why I need to run the debugger.
>
> I have looked Freescale FCC3 driver, but my code requires to create 13
> interfaces, it is quite different from other drivers.
>
> I wonder if there is a way to link io-pkt devn-bcm5696 and devnp-shim
> statically?
> "
>
> So, it sounds like a real problem on our end doesn't it ? The driver
> loads in io-net but not io-pkt..
>
> Any suggestions ?
>
> Thanks !
>
> Dave
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post20529
>
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post20534
>
--
Dave Bott (dbott@qnx.com) Field Applications Engineer
QNX Software Systems, Inc. Voice: 408-879-7230
900 E. Hamilton Ave #100 Fax:408-879-7221
Campbell CA 95008 Cell:408 391-3535
Join Foundry27 <http://community.qnx.com>; - the new QNX developer forum.
|
|
|
|
|
|
Dave Bott(deleted)
|
Re: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/21/2009 9:38 PM
post20553
|
Re: libsocket in a devn driver ?
Some progress.... but a kernel crash too.
Is it reasonable to say that we do not expect kernel crashes, no matter how broken the application code happens to be ?
Anyone care to say what qconn did ?
It looks like it got an EINTR (interrupted system call from errno.h) or am I mistaken ?
Dave
"After I did the following:
1. Disabled two BCM features (both cause assert errors) and
2. Init a BCM structure which registers two PCI config access routines (the code does not use these routines).
==> The BCM driver is up and running on the target (the no-debug version), I have exercised quite a lot of the BCM
features, the system did not go down.
Then I try to run the debugger, this time it worked. Well for a while (5 secs), the debugger died with the following
==>Debugger console:
CTL-C transmit - 3 retries exhausted. Ending debug session.
Cannot access memory at address 0x0
mi_cmd_stack_list_args: Not enough frames in stack.
Timed out.
===>Target console:
Shutdown[0,0] S/C/F=4/1/1 C/D=001200a0/0018ebf4
QNX Version 6.4.0 Release 2008/10/21-11:01:12EDT
[0]PID-TID=331793-1 P/T FL=00400010/80000000 "usr/sbin/qconn"
ppcbe context[0ffedf40]:
0000: 0000000c 0ffedff0 fe37e3b0 40000000 4803f658 ffffffe8 4803f648 00000002
0020: 4803f658 000001c0 00000000 00000000 28004042 48068914 4805c8d0 4805c8b4
0040: 4805c8c0 4805c8bc 4805c900 48060000 fe37cd20 fe380d6c fe37cd28 4803f77f
0060: 00000003 4803f6b8 0000ffff fe31b6c8 fe37cd30 48004028 0fe83d5c 0fe83a80
0080: fe31b6c8 fe31b734 00000004 00000c00 48004028 00000000 00000000 00000000
00a0: 00000000
instruction[00000c00]:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
stack[0ffedff0]:
0000: 00000000 00187278 00000000 00000000 00000000 00000000 00000000 00000000
0020: 00000000 00000000 0fffa700 0fffa700 00000000 00000000 00000000 00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0060: 00000000 00000000 00000000 00000000 00000000 00000000 0fe2b000 0fe2b000
"
|
|
|
|
|
|
Robert Craig
|
RE: libsocket in a devn driver ?
|
|
Robert Craig
01/22/2009 12:40 PM
post20635
|
RE: libsocket in a devn driver ?
In terms of qconn, I'd say that this question would best be asked in the
IDE forum. For the kernel crash, drivers generally involve programming
DMA engines which can write anywhere into memory, so a driver with bugs
in it can very easily crash the kernel.
Robert.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Wednesday, January 21, 2009 9:39 PM
To: drivers-networking
Subject: Re: libsocket in a devn driver ?
Some progress.... but a kernel crash too.
Is it reasonable to say that we do not expect kernel crashes, no matter
how broken the application code happens to be ?
Anyone care to say what qconn did ?
It looks like it got an EINTR (interrupted system call from errno.h) or
am I mistaken ?
Dave
"After I did the following:
1. Disabled two BCM features (both cause assert errors) and 2. Init a
BCM structure which registers two PCI config access routines (the code
does not use these routines).
==> The BCM driver is up and running on the target (the no-debug
version), I have exercised quite a lot of the BCM features, the system
did not go down.
Then I try to run the debugger, this time it worked. Well for a while (5
secs), the debugger died with the following
==>Debugger console:
CTL-C transmit - 3 retries exhausted. Ending debug session.
Cannot access memory at address 0x0
mi_cmd_stack_list_args: Not enough frames in stack.
Timed out.
===>Target console:
Shutdown[0,0] S/C/F=4/1/1 C/D=001200a0/0018ebf4 QNX Version 6.4.0
Release 2008/10/21-11:01:12EDT
[0]PID-TID=331793-1 P/T FL=00400010/80000000 "usr/sbin/qconn"
ppcbe context[0ffedf40]:
0000: 0000000c 0ffedff0 fe37e3b0 40000000 4803f658 ffffffe8 4803f648
00000002
0020: 4803f658 000001c0 00000000 00000000 28004042 48068914 4805c8d0
4805c8b4
0040: 4805c8c0 4805c8bc 4805c900 48060000 fe37cd20 fe380d6c fe37cd28
4803f77f
0060: 00000003 4803f6b8 0000ffff fe31b6c8 fe37cd30 48004028 0fe83d5c
0fe83a80
0080: fe31b6c8 fe31b734 00000004 00000c00 48004028 00000000 00000000
00000000
00a0: 00000000
instruction[00000c00]:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
stack[0ffedff0]:
0000: 00000000 00187278 00000000 00000000 00000000 00000000 00000000
00000000
0020: 00000000 00000000 0fffa700 0fffa700 00000000 00000000 00000000
00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0060: 00000000 00000000 00000000 00000000 00000000 00000000 0fe2b000
0fe2b000 "
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20553
|
|
|
|
|
|
Dave Bott(deleted)
|
RE: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/22/2009 1:37 PM
post20642
|
RE: libsocket in a devn driver ?
I agree that a DMA could cause a crash, but this is crashing when using the debugger, but not when run without. No DMA
taking place...
Dave
________________________________
From: Robert Craig [mailto:community-noreply@qnx.com]
Sent: Thu 1/22/2009 9:40 AM
To: drivers-networking
Subject: RE: libsocket in a devn driver ?
In terms of qconn, I'd say that this question would best be asked in the
IDE forum. For the kernel crash, drivers generally involve programming
DMA engines which can write anywhere into memory, so a driver with bugs
in it can very easily crash the kernel.
Robert.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Wednesday, January 21, 2009 9:39 PM
To: drivers-networking
Subject: Re: libsocket in a devn driver ?
Some progress.... but a kernel crash too.
Is it reasonable to say that we do not expect kernel crashes, no matter
how broken the application code happens to be ?
Anyone care to say what qconn did ?
It looks like it got an EINTR (interrupted system call from errno.h) or
am I mistaken ?
Dave
"After I did the following:
1. Disabled two BCM features (both cause assert errors) and 2. Init a
BCM structure which registers two PCI config access routines (the code
does not use these routines).
==> The BCM driver is up and running on the target (the no-debug
version), I have exercised quite a lot of the BCM features, the system
did not go down.
Then I try to run the debugger, this time it worked. Well for a while (5
secs), the debugger died with the following
==>Debugger console:
CTL-C transmit - 3 retries exhausted. Ending debug session.
Cannot access memory at address 0x0
mi_cmd_stack_list_args: Not enough frames in stack.
Timed out.
===>Target console:
Shutdown[0,0] S/C/F=4/1/1 C/D=001200a0/0018ebf4 QNX Version 6.4.0
Release 2008/10/21-11:01:12EDT
[0]PID-TID=331793-1 P/T FL=00400010/80000000 "usr/sbin/qconn"
ppcbe context[0ffedf40]:
0000: 0000000c 0ffedff0 fe37e3b0 40000000 4803f658 ffffffe8 4803f648
00000002
0020: 4803f658 000001c0 00000000 00000000 28004042 48068914 4805c8d0
4805c8b4
0040: 4805c8c0 4805c8bc 4805c900 48060000 fe37cd20 fe380d6c fe37cd28
4803f77f
0060: 00000003 4803f6b8 0000ffff fe31b6c8 fe37cd30 48004028 0fe83d5c
0fe83a80
0080: fe31b6c8 fe31b734 00000004 00000c00 48004028 00000000 00000000
00000000
00a0: 00000000
instruction[00000c00]:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
stack[0ffedff0]:
0000: 00000000 00187278 00000000 00000000 00000000 00000000 00000000
00000000
0020: 00000000 00000000 0fffa700 0fffa700 00000000 00000000 00000000
00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0060: 00000000 00000000 00000000 00000000 00000000 00000000 0fe2b000
0fe2b000 "
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20553
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20635
|
|
|
|
|
|
Robert Craig
|
RE: libsocket in a devn driver ?
|
|
Robert Craig
01/22/2009 1:39 PM
post20644
|
RE: libsocket in a devn driver ?
"Then I try to run the debugger, this time it worked. Well for a while
(5 secs), the debugger died with the following"
So things were running for a while before the crash. I'm not saying it
is DMA, but it's still possible that.
R.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Thursday, January 22, 2009 1:37 PM
To: drivers-networking
Subject: RE: libsocket in a devn driver ?
I agree that a DMA could cause a crash, but this is crashing when using
the debugger, but not when run without. No DMA taking place...
Dave
________________________________
From: Robert Craig [mailto:community-noreply@qnx.com]
Sent: Thu 1/22/2009 9:40 AM
To: drivers-networking
Subject: RE: libsocket in a devn driver ?
In terms of qconn, I'd say that this question would best be asked in the
IDE forum. For the kernel crash, drivers generally involve programming
DMA engines which can write anywhere into memory, so a driver with bugs
in it can very easily crash the kernel.
Robert.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Wednesday, January 21, 2009 9:39 PM
To: drivers-networking
Subject: Re: libsocket in a devn driver ?
Some progress.... but a kernel crash too.
Is it reasonable to say that we do not expect kernel crashes, no matter
how broken the application code happens to be ?
Anyone care to say what qconn did ?
It looks like it got an EINTR (interrupted system call from errno.h) or
am I mistaken ?
Dave
"After I did the following:
1. Disabled two BCM features (both cause assert errors) and 2. Init a
BCM structure which registers two PCI config access routines (the code
does not use these routines).
==> The BCM driver is up and running on the target (the no-debug
version), I have exercised quite a lot of the BCM features, the system
did not go down.
Then I try to run the debugger, this time it worked. Well for a while (5
secs), the debugger died with the following
==>Debugger console:
CTL-C transmit - 3 retries exhausted. Ending debug session.
Cannot access memory at address 0x0
mi_cmd_stack_list_args: Not enough frames in stack.
Timed out.
===>Target console:
Shutdown[0,0] S/C/F=4/1/1 C/D=001200a0/0018ebf4 QNX Version 6.4.0
Release 2008/10/21-11:01:12EDT
[0]PID-TID=331793-1 P/T FL=00400010/80000000 "usr/sbin/qconn"
ppcbe context[0ffedf40]:
0000: 0000000c 0ffedff0 fe37e3b0 40000000 4803f658 ffffffe8 4803f648
00000002
0020: 4803f658 000001c0 00000000 00000000 28004042 48068914 4805c8d0
4805c8b4
0040: 4805c8c0 4805c8bc 4805c900 48060000 fe37cd20 fe380d6c fe37cd28
4803f77f
0060: 00000003 4803f6b8 0000ffff fe31b6c8 fe37cd30 48004028 0fe83d5c
0fe83a80
0080: fe31b6c8 fe31b734 00000004 00000c00 48004028 00000000 00000000
00000000
00a0: 00000000
instruction[00000c00]:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
stack[0ffedff0]:
0000: 00000000 00187278 00000000 00000000 00000000 00000000 00000000
00000000
0020: 00000000 00000000 0fffa700 0fffa700 00000000 00000000 00000000
00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0060: 00000000 00000000 00000000 00000000 00000000 00000000 0fe2b000
0fe2b000 "
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20553
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20635
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post20642
|
|
|
|
|
|
Dave Bott(deleted)
|
Re: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/23/2009 1:16 PM
post20734
|
Re: libsocket in a devn driver ?
Me again,
So, something is fishy for sure.
First of all, their binary is *huge* - 5.7MB of .so stripped - 14MB with
debug symbols. I'm wondering if that could be a problem by itself...
I do have the binary...
The engineer says that it runs fine in 6.3.2 but very sporadically in
6.4.0. Here is some debug output, DL_DEBUG info etc. from first a failed
session, and then a working one, plus her comments.
Is the shim method supposed to be foolproof or are there known
limitations with using io-net drivers in io-pkt ?
Dave
So far, my system has been running unreliably. That is, the code will
run completely to the end and works fine at one time, and most other
time it crashes. I had to disable three functions in my system to get it
to run. I have some trouble to debug, the debugger can not resolve
routine addresses if access indirectly.
I am not sure how different between 6.3.2 and 6.4.0. At least the either
bss or stack memory init are different.
Attached are the console outputs of two runs. One segment fault at load
time, the other runs through completely.
Does anything look particularly out of the ordinary ? Any suggestions ?
Any extra debug we can add ?
Ideally, I'd like her to make this an io-pkt driver, but since there
aren't any clear guidelines on exactly what needs to change, I'm
reluctant to suggest this...
Cheers
Dave
==================================================
The segment fault traceback
bcm5696 (1) [C/C++ QNX QConn (IP)]
QNX GDB Debugger (1/22/09 5:43 PM) (Suspended)
Thread [1] (Suspended)
Thread [2] (Suspended: Signal 'SIGSEGV' received. Description:
Segmentation fault.)
12 resolve_rels() 0xfe34213c
11 resolve() 0xfe342708
10 dlopen() 0xfe344df8
9 nw_dlopen()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/nw_dl.c:152
0x480b00e4
8 io_net_dll_load()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/dev_qnx/shim/io-net.c:335
0xfe3868e4
7 shim_entry()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/dev_qnx/shim/init.c:248
0xfe384d58
6 nw_dlload_module()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/nw_dl.c:405
0x480b083c
5 init_load()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/init_main.c:1374
0x4808d7dc
4 load_drivers()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/init_main.c:1338
0x4808d664
3 receive_loop_uni()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/receive.c:899
0x480c398c
2 thread_init()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networking/trunk/sys/nw_thread.c:765
0x480b1be4
/home/schen/io-pkt-v4 on 10.1.0.14(SherrySCM2) pid 1384474 (1/22/09
5:43 PM)
/opt/qnx640/host/linux/x86/usr/bin/ntoppc-gdb (1/22/09 5:43 PM)
=================================================================================
============ The following is the console output of a BAD run ==========
dlopen("cache-ppcbe-8572DS.so",2)
load_object: attempt load of cache-ppcbe-8572DS.so
dlopen: Library cannot be found
dlopen("NULL",2048)
dlsym(0xfe381234,iofunc_notify_trigger_strict)=0xfe33c290
dlsym(0xfe381234,iofunc_notify_remove_strict)=0xfe33c18c
dlopen("devnp-bcm5696.so",3072)
load_object: attempt load of devnp-bcm5696.so
dlopen: Library cannot be found
dlopen("devn-bcm5696.so",3072)
load_object: attempt load of devn-bcm5696.so
load_elf32: loaded lib at addr fe382000(text) fe8c9388(data)
dlsym(0x4812b060,_btext)=0x4804da10
Library loaded; type 'add-sym libdevn-bcm5696_g.so.1 0x4804da10' in...
View Full Message
|
|
|
|
|
|
Robert Craig
|
RE: libsocket in a devn driver ?
|
|
Robert Craig
01/23/2009 1:37 PM
post20739
|
RE: libsocket in a devn driver ?
The shim tends to be far less forgiving of errors than io-net is. We
have had a number of occasions in which drivers that "worked under
6.3.2" failed in 6.4.0. So far (and cold comfort that it is), a very
high percentage of those (I'd say 90%) were attributed to latent driver
bugs.
In this case:
Non-working:
load_object: attempt load of devn-bcm5696.so
load_elf32: loaded lib at addr fe38e000(text) fe8d5388(data)
dlsym(0x4812b080,_btext)=0xfe455580
Working:
load_elf32: loaded lib at addr fe38e000(text) fe8d5408(data)
dlsym(0x4812b080,_btext)=0xfe455580
Note how the data area is offset but everything else is identical.
Am I correct in reading that consecutive invocations with nothing else
changing in between can work or not work, as the case may be? Also, the
DRIVER binary is 5.7MB (????). That seems out of whack to me as well.
The comment "I had to disable three functions to get it to run" is very
suspicious and suggestive of some sort of driver problem (size or
function).
It might be worthwhile asking in the OS forum if there are any known
limitations on dlls with regards to size.
Robert.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Friday, January 23, 2009 1:17 PM
To: drivers-networking
Subject: Re: libsocket in a devn driver ?
Me again,
So, something is fishy for sure.
First of all, their binary is *huge* - 5.7MB of .so stripped - 14MB with
debug symbols. I'm wondering if that could be a problem by itself...
I do have the binary...
The engineer says that it runs fine in 6.3.2 but very sporadically in
6.4.0. Here is some debug output, DL_DEBUG info etc. from first a failed
session, and then a working one, plus her comments.
Is the shim method supposed to be foolproof or are there known
limitations with using io-net drivers in io-pkt ?
Dave
So far, my system has been running unreliably. That is, the code will
run completely to the end and works fine at one time, and most other
time it crashes. I had to disable three functions in my system to get it
to run. I have some trouble to debug, the debugger can not resolve
routine addresses if access indirectly.
I am not sure how different between 6.3.2 and 6.4.0. At least the either
bss or stack memory init are different.
Attached are the console outputs of two runs. One segment fault at load
time, the other runs through completely.
Does anything look particularly out of the ordinary ? Any suggestions ?
Any extra debug we can add ?
Ideally, I'd like her to make this an io-pkt driver, but since there
aren't any clear guidelines on exactly what needs to change, I'm
reluctant to suggest this...
Cheers
Dave
==================================================
The segment fault traceback
bcm5696 (1) [C/C++ QNX QConn (IP)]
QNX GDB Debugger (1/22/09 5:43 PM) (Suspended)
Thread [1] (Suspended)
Thread [2] (Suspended: Signal 'SIGSEGV' received. Description:
Segmentation fault.)
12 resolve_rels() 0xfe34213c
11 resolve() 0xfe342708
10 dlopen() 0xfe344df8
9 nw_dlopen()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/nw_dl.c:152
0x480b00e4
8 io_net_dll_load()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/dev_qnx/shim/io-net.c:335
0xfe3868e4
7 shim_entry()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/dev_qnx/shim/init.c:248
0xfe384d58
6 nw_dlload_module()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/nw_dl.c:405
0x480b083c
5 init_load()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/init_main.c:1374
0x4808d7dc
4...
View Full Message
|
|
|
|
|
|
Dave Bott(deleted)
|
RE: libsocket in a devn driver ?
|
|
Dave Bott(deleted)
01/23/2009 1:39 PM
post20741
|
RE: libsocket in a devn driver ?
Thanks Robert - good info !
Dave
________________________________
From: Robert Craig [mailto:community-noreply@qnx.com]
Sent: Fri 1/23/2009 10:38 AM
To: drivers-networking
Subject: RE: libsocket in a devn driver ?
The shim tends to be far less forgiving of errors than io-net is. We
have had a number of occasions in which drivers that "worked under
6.3.2" failed in 6.4.0. So far (and cold comfort that it is), a very
high percentage of those (I'd say 90%) were attributed to latent driver
bugs.
In this case:
Non-working:
load_object: attempt load of devn-bcm5696.so
load_elf32: loaded lib at addr fe38e000(text) fe8d5388(data)
dlsym(0x4812b080,_btext)=0xfe455580
Working:
load_elf32: loaded lib at addr fe38e000(text) fe8d5408(data)
dlsym(0x4812b080,_btext)=0xfe455580
Note how the data area is offset but everything else is identical.
Am I correct in reading that consecutive invocations with nothing else
changing in between can work or not work, as the case may be? Also, the
DRIVER binary is 5.7MB (????). That seems out of whack to me as well.
The comment "I had to disable three functions to get it to run" is very
suspicious and suggestive of some sort of driver problem (size or
function).
It might be worthwhile asking in the OS forum if there are any known
limitations on dlls with regards to size.
Robert.
-----Original Message-----
From: Dave Bott [mailto:community-noreply@qnx.com]
Sent: Friday, January 23, 2009 1:17 PM
To: drivers-networking
Subject: Re: libsocket in a devn driver ?
Me again,
So, something is fishy for sure.
First of all, their binary is *huge* - 5.7MB of .so stripped - 14MB with
debug symbols. I'm wondering if that could be a problem by itself...
I do have the binary...
The engineer says that it runs fine in 6.3.2 but very sporadically in
6.4.0. Here is some debug output, DL_DEBUG info etc. from first a failed
session, and then a working one, plus her comments.
Is the shim method supposed to be foolproof or are there known
limitations with using io-net drivers in io-pkt ?
Dave
So far, my system has been running unreliably. That is, the code will
run completely to the end and works fine at one time, and most other
time it crashes. I had to disable three functions in my system to get it
to run. I have some trouble to debug, the debugger can not resolve
routine addresses if access indirectly.
I am not sure how different between 6.3.2 and 6.4.0. At least the either
bss or stack memory init are different.
Attached are the console outputs of two runs. One segment fault at load
time, the other runs through completely.
Does anything look particularly out of the ordinary ? Any suggestions ?
Any extra debug we can add ?
Ideally, I'd like her to make this an io-pkt driver, but since there
aren't any clear guidelines on exactly what needs to change, I'm
reluctant to suggest this...
Cheers
Dave
==================================================
The segment fault traceback
bcm5696 (1) [C/C++ QNX QConn (IP)]
QNX GDB Debugger (1/22/09 5:43 PM) (Suspended)
Thread [1] (Suspended)
Thread [2] (Suspended: Signal 'SIGSEGV' received. Description:
Segmentation fault.)
12 resolve_rels() 0xfe34213c
11 resolve() 0xfe342708
10 dlopen() 0xfe344df8
9 nw_dlopen()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/nw_dl.c:152
0x480b00e4
8 io_net_dll_load()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/dev_qnx/shim/io-net.c:335
0xfe3868e4
7 shim_entry()
/home/schen/ide-4.5-workspace/schen_ne_main_qnx64/ne/thirdparty/Networki
ng/trunk/sys/dev_qnx/shim/init.c:248
0xfe384d58
6...
View Full Message
|
|
|
|
|
|
