On Thu, Jan 17, 2008 at 10:54:32PM -0500, Dave Rigby wrote:
> Hi,
> 
> I'm trying to get an existing (binary) driver I have, asix working with io-pkt. This is a USB ethernet device, which 
was working fine with io-net. However when using it with io-pkt, I get a segfault. I managed to re-run it with a debug 
version of io-pkt, and it appears that there is a thread-local data structure which is not getting initialised correctly
.
> 
> GDB backtrace:
> 
> $ ntox86-gdb io-pkt-v4_g --core=io-pkt.core 
> GNU gdb 5.2.1qnx-nto
> <snip>
> Program terminated with signal 11, Segmentation fault.
> <snip>
> #0  realloc_bsd (addr=0x0, size=3072, ksp=0x80c2820, flags=3) at /export/davidr/core_networking/trunk/sys/kern/
kern_malloc.c:1120
> 1120			NW_SIGHOLD_P(wtp);
> (gdb) bt
> #0  realloc_bsd (addr=0x0, size=3072, ksp=0x80c2820, flags=3) at /export/davidr/core_networking/trunk/sys/kern/
kern_malloc.c:1120
> #1  0x0807d992 in malloc_bsd (size=3072, ksp=0x80c2820, flags=3) at /export/davidr/core_networking/trunk/sys/kern/
kern_malloc.c:1089
> #2  0x0805ca57 in dev_attach (drvr=0xb820615b "en", options=0x80a0c5c "", ca=0xb8207620, cfat_arg=0x7fc6ea0, single=
0x7f97d94, devp=0x7f97d98, print=0)
>     at /export/davidr/core_networking/trunk/sys/device_qnx.c:98
> #3  0xb82028c8 in shim_create_instance () from /export/davidr/stage/x86/lib/dll/devnp-shim.so
> #4  0xb8203fbc in ex_reg () from /export/davidr/stage/x86/lib/dll/devnp-shim.so
> #5  0xb8214709 in ax_register_device () from /export/davidr/stage/x86/lib/dll/devn-asix.so
> #6  0xb8214f9a in ax_attach () from /export/davidr/stage/x86/lib/dll/devn-asix.so
> #7  0xb82155fe in ax_insertion () from /export/davidr/stage/x86/lib/dll/devn-asix.so
> #8  0xb8218a1c in eventloop () from /export/davidr/stage/x86/lib/dll/devn-asix.so
>  
> The NW_SIGHOLD_P macro causes the wtp argument to be deferenced, and this is null at this point:
> 
> (gdb) info locals
> addr = (void *) 0x0
> va = (void *) 0x0
> wtp = (struct nw_work_thread *) 0x0
> size_rounded = 3072
> mcp = (struct malcheck *) 0x0
> 
> (gdb) info thread
>   4 process 4  0xb8214438 in ax_event_handler () from /export/davidr/stage/x86/lib/dll/devn-asix.so
> * 3 process 3  realloc_bsd (addr=0x0, size=3072, ksp=0x80c2820, flags=3) at /export/davidr/core_networking/trunk/sys/
kern/kern_malloc.c:1120
>   2 process 2  0xb0330c21 in MsgReceivev () from /export/davidr/stage/x86/lib/libc.so.2
>   1 process 1  0xb0331959 in SignalWaitinfo () from /export/davidr/Oquirrh/CRS_core_os/stage/x86/lib/libc.so.2
> 
> From a brief look at the source of kern_malloc.c, the wtp variable is initialised using the WTP macro, which selects a
 worker thread from the  stk_ctl.work_threads[] structure. The tid at this point is 3, but this is offset by -2 to get 
the index into stk_ctl.work_threads[]:
> 
> (gdb) p *stk_ctl.work_threads@stk_ctl.nwork_threads
> $32 = {0x80df840, 0x0, 0x0, 0x0}
> 
> Looks like only 1 worker thread (0) has been initialised.
> 
> 
> Could anyone shed any light on this?
> 
> Thanks
> 
> Dave Rigby
> 

You're run into a driver that does something atypical.  Most
drivers register with io-net (shim here) from their initial
entry point which is called by a thread io-pkt knows about.
This driver is registering as a result of an insertion event
from a thread that it created (one that io-pkt doesn't have
any knowledge of).  I don't see an easy proper fix at first
glance.  Some smarts could be added to
shim_create_instance() to fail in this case but that doesn't
really help you out.

-seanb

Hi Dave:
  After some pondering, we thought that the best way to solve the asix driver problem was to say "Don't use the io-net 
version of the driver".  We were left with the dilemma of either modifying the stack in some way to handle two specific 
drivers (asix and pegasus) OR somehow re-working the io-net drivers for io-pkt.  Neither of these options really make 
sense...  So we went with option 3 instead.

If you update your code base to the latest and re-build, you will now find a devnp-axe.so driver which is the ported 
NetBSD version.  Works on x86 but hasn't been tried on any other platforms yet. In the interests of saving other people 
pain, we also added in a new porting doc which covers what had to be done to get the axe ported over to Neutrino.  
Hopefully this will be pretty much cookie cutter now that it's been done once. 

http://community.qnx.com/integration/viewcvs/viewcvs.cgi/trunk/sys/dev/doc/?root=core_networking&system=exsy1001

Let me know how it works out,

    Robert.