|
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
|
|
|
|
|
|
