Hi,
I’m currently writing a network driver and have a problem with the big
tcpip stack.
When I mount io-net with the driver and the big stack everything appears
to be working fine, however when I start two ping sessions on the rtp
machine io-net crashes.
The message I get from the ping session is:
ping: recvfrom: No such process
Tracing my own driver shows no problems and other services such as
telnet and ftp seem to be working fine.
Is there anyway to find out what has happened to io-net and in
particular which “driver” caused the problem.
I have tried the same test with the tiny tcpip stack and this does not
happen.
Cheers
Dave
If it’s not directly in your driver, could be a buffer / packet
management problem which may be harder to find. Things like
releasing a packet too many times, overrunning a buffer, not
setting up iov’s correctly…
Does it happen with other drivers? You should be able to
attach to io-net with gdb and step through you driver if
you’ve compiled with debug.
-seanb
Dave Edwards <nobody@home.com> wrote:
: Hi,
: I’m currently writing a network driver and have a problem with the big
: tcpip stack.
: When I mount io-net with the driver and the big stack everything appears
: to be working fine, however when I start two ping sessions on the rtp
: machine io-net crashes.
: The message I get from the ping session is:
: ping: recvfrom: No such process
: Tracing my own driver shows no problems and other services such as
: telnet and ftp seem to be working fine.
: Is there anyway to find out what has happened to io-net and in
: particular which “driver” caused the problem.
: I have tried the same test with the tiny tcpip stack and this does not
: happen.
: Cheers
: Dave
Sean,
My first guess would be with the setup of the buffers. The code is based
upon the pcnet example code but it’s been hacked around for a non dma
network device.
Pinging the RTP machine itself does not appear to have a problem,
although it would appear that a higher level of io-net is trapping the
packet (tcpip itself?)
I’m stuck at the momemt to test this with another driver, so I guess my
next question is how do I run io-net with gdb?
Cheers
Dave
Sean Boudreau wrote:
If it’s not directly in your driver, could be a buffer / packet
management problem which may be harder to find. Things like
releasing a packet too many times, overrunning a buffer, not
setting up iov’s correctly…
Does it happen with other drivers? You should be able to
attach to io-net with gdb and step through you driver if
you’ve compiled with debug.
-seanb
Dave Edwards <> nobody@home.com> > wrote:
: Hi,
: I’m currently writing a network driver and have a problem with the big
: tcpip stack.
: When I mount io-net with the driver and the big stack everything appears
: to be working fine, however when I start two ping sessions on the rtp
: machine io-net crashes.
: The message I get from the ping session is:
: ping: recvfrom: No such process
: Tracing my own driver shows no problems and other services such as
: telnet and ftp seem to be working fine.
: Is there anyway to find out what has happened to io-net and in
: particular which “driver” caused the problem.
: I have tried the same test with the tiny tcpip stack and this does not
: happen.
: Cheers
: Dave
Dave Edwards <nobody@home.com> wrote:
: Sean,
: My first guess would be with the setup of the buffers. The code is based
: upon the pcnet example code but it’s been hacked around for a non dma
: network device.
: Pinging the RTP machine itself does not appear to have a problem,
: although it would appear that a higher level of io-net is trapping the
: packet (tcpip itself?)
: I’m stuck at the momemt to test this with another driver, so I guess my
: next question is how do I run io-net with gdb?
This should be standard gdb stuff. Make sure your driver is compiled / linked
with debug.
/home/seanb >gdb
GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntox86”.
(gdb) target qnx pty
Launching on pty /dev/ptyp9
Debug server launched.
Remote debugging using pty
(gdb) shell pidin | grep io-net
60629026 1 t/x86/o/io-net 10r SIGWAITINFO
60629026 2 t/x86/o/io-net 10r RECEIVE 1
60629026 3 t/x86/o/io-net 10r RECEIVE 1
60629026 4 t/x86/o/io-net 10r RECEIVE 1
60629026 5 t/x86/o/io-net 21r RECEIVE 5
60629026 6 t/x86/o/io-net 20r RECEIVE 9
(gdb) attach 60629026
Attaching to process 60629026
Then look at the commands:
set solib-search-path
set solib-absolute-path
info sharedlibrary
sharedlibrary
Check out the gdb manual for more info.
-seanb
: Cheers
: Dave
: Sean Boudreau wrote:
:> If it’s not directly in your driver, could be a buffer / packet
:> management problem which may be harder to find. Things like
:> releasing a packet too many times, overrunning a buffer, not
:> setting up iov’s correctly…
:>
:> Does it happen with other drivers? You should be able to
:> attach to io-net with gdb and step through you driver if
:> you’ve compiled with debug.
:>
:> -seanb
:>
:> Dave Edwards <nobody@home.com> wrote:
:> : Hi,
:>
:> : I’m currently writing a network driver and have a problem with the big
:> : tcpip stack.
:>
:> : When I mount io-net with the driver and the big stack everything appears
:> : to be working fine, however when I start two ping sessions on the rtp
:> : machine io-net crashes.
:>
:> : The message I get from the ping session is:
:>
:> : ping: recvfrom: No such process
:>
:> : Tracing my own driver shows no problems and other services such as
:> : telnet and ftp seem to be working fine.
:>
:> : Is there anyway to find out what has happened to io-net and in
:> : particular which “driver” caused the problem.
:>
:> : I have tried the same test with the tiny tcpip stack and this does not
:> : happen.
:>
:>
:> : Cheers
:>
:> : Dave
:>
:>