NIC failured under QNX 6.2.0 (RTP Momentics)

QNX Newsgroups (Archives) qdn.public.qnxrtp.installation
1

Some time ago, I upgraded our development seat from QNX 6.1 (the free
version) to 6.2.0 (Momentics Professional Edition).
We have been having problems with our network connection since.
The card worked fine under Linux, QNX 4, Neutrino, and QNX 6.1, and
still works OK when booted to QNX 4 or Windows 95, but it malfunctions
under QNX 6.2.

IF the system manages to start the network (using rc.local – it
cannot autodetect, as they did not include this model in this
version of the trapping software), the OS things the NIC is a dual
port card (it is a dual media card 10BaseT and 10Base2, but single
port). It then sets up the network on en1. The network will function
locally until you try to use ftp to upload a large file to a machine,
say, across the room. Then it fails. When io-net is slayed, and things
restarted, the network then comes up on en0 (not en1), and it works
as before – until you try a largish ftp transfer again.

The NIC is a SMC EtherEZ (8416), which I think is actually a Western Digital
card.

Here is some output:
on boot:
$ /sbin/ifconfig -a
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
inet 127.0.0.1 netmask 0xff000000
inet6 fe80:1::1 prefixlen 64
inet6 ::1 prefixlen 128
en0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:ff:01:ff:01:ff
en1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:c0:6a:2b:eb
inet 144.92.179.65 netmask 0xffffff00 broadcast 144.92.179.255
inet6 fe80:3::200:c0ff:fe6a:2beb prefixlen 64
when using ftp:
ftp> get st5k_trk.exe
local: st5k_trk.exe remote: st5k_trk.exe
200 PORT command successful.
150 Opening BINARY mode data connection for ‘st5k_trk.exe’ (39896 bytes).
100% |********************************************************| 39896
48.89 KB/s 00:00 ETA
226 Transfer complete.
39896 bytes received in 00:00 (47.81 KB/s)
ftp> put tffs_512_DOC_tools.zip
local: tffs_512_DOC_tools.zip remote: tffs_512_DOC_tools.zip
200 PORT command successful.
150 Opening BINARY mode data connection for ‘tffs_512_DOC_tools.zip’.
0% | | 0
0.00 KB/s --:-- ETAf
tp: netout: No such process
0% | | -1
0.00 KB/s --:-- ETA
421 Service not available, remote server has closed connection.
ftp> ls s
Not connected.
ftp> close
Not connected.
ftp> quit

output of nicinfo:SMC EtherEz Ethernet Controller
Physical Node ID … 0000C0 6A2BEB
Current Physical Node ID … 0000C0 6A2BEB
Media Rate … 10.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
Hardware Interrupt … 0xA
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 72
Total Packets Txd Bad … 0
Total Packets Rxd OK … 5137
Total Rx Errors … 0

Total Bytes Txd … 6129
Total Bytes Rxd … 363739

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 0

Note that nicinfo clames it is a UTP connection. It is actually using
a thin-net (10Base2) connection.

Any ideas?

Richard Bonomo
bonomo@sal.wisc.edu

2

I’ll have to take a look at this driver and get back to you.

Previously, Richard Bonomo,6289 Chamberlin,263-4683, wrote in qdn.public.qnxrtp.installation:

Some time ago, I upgraded our development seat from QNX 6.1 (the free
version) to 6.2.0 (Momentics Professional Edition).
We have been having problems with our network connection since.
The card worked fine under Linux, QNX 4, Neutrino, and QNX 6.1, and
still works OK when booted to QNX 4 or Windows 95, but it malfunctions
under QNX 6.2.

IF the system manages to start the network (using rc.local – it
cannot autodetect, as they did not include this model in this
version of the trapping software), the OS things the NIC is a dual
port card (it is a dual media card 10BaseT and 10Base2, but single
port). It then sets up the network on en1. The network will function
locally until you try to use ftp to upload a large file to a machine,
say, across the room. Then it fails. When io-net is slayed, and things
restarted, the network then comes up on en0 (not en1), and it works
as before – until you try a largish ftp transfer again.

The NIC is a SMC EtherEZ (8416), which I think is actually a Western Digital
card.

Here is some output:
on boot:
$ /sbin/ifconfig -a
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
inet 127.0.0.1 netmask 0xff000000
inet6 fe80:1::1 prefixlen 64
inet6 ::1 prefixlen 128
en0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:ff:01:ff:01:ff
en1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:c0:6a:2b:eb
inet 144.92.179.65 netmask 0xffffff00 broadcast 144.92.179.255
inet6 fe80:3::200:c0ff:fe6a:2beb prefixlen 64
when using ftp:
ftp> get st5k_trk.exe
local: st5k_trk.exe remote: st5k_trk.exe
200 PORT command successful.
150 Opening BINARY mode data connection for ‘st5k_trk.exe’ (39896 bytes).
100% |********************************************************| 39896
48.89 KB/s 00:00 ETA
226 Transfer complete.
39896 bytes received in 00:00 (47.81 KB/s)
ftp> put tffs_512_DOC_tools.zip
local: tffs_512_DOC_tools.zip remote: tffs_512_DOC_tools.zip
200 PORT command successful.
150 Opening BINARY mode data connection for ‘tffs_512_DOC_tools.zip’.
0% | | 0
0.00 KB/s --:-- ETAf
tp: netout: No such process
0% | | -1
0.00 KB/s --:-- ETA
421 Service not available, remote server has closed connection.
ftp> ls s
Not connected.
ftp> close
Not connected.
ftp> quit

output of nicinfo:SMC EtherEz Ethernet Controller
Physical Node ID … 0000C0 6A2BEB
Current Physical Node ID … 0000C0 6A2BEB
Media Rate … 10.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
Hardware Interrupt … 0xA
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 72
Total Packets Txd Bad … 0
Total Packets Rxd OK … 5137
Total Rx Errors … 0

Total Bytes Txd … 6129
Total Bytes Rxd … 363739

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 0

Note that nicinfo clames it is a UTP connection. It is actually using
a thin-net (10Base2) connection.

Any ideas?

Richard Bonomo
bonomo@sal.wisc.edu

3

How are you starting the driver in your rc.local file? I have
started the driver in my rc.local file and transferred large files
between 2 machine without any problems. When the driver is started,
it registers as en0. Here is my rc.local:

slay io-net
sleep 2
io-net -dwd -ptcpip
sleep 1
ifconfig en0 xx.xx.xx.xx up
inetd

Previously, Hugh Brown wrote in qdn.public.qnxrtp.installation:

I’ll have to take a look at this driver and get back to you.

Previously, Richard Bonomo,6289 Chamberlin,263-4683, wrote in qdn.public.qnxrtp.installation:
Some time ago, I upgraded our development seat from QNX 6.1 (the free
version) to 6.2.0 (Momentics Professional Edition).
We have been having problems with our network connection since.
The card worked fine under Linux, QNX 4, Neutrino, and QNX 6.1, and
still works OK when booted to QNX 4 or Windows 95, but it malfunctions
under QNX 6.2.

IF the system manages to start the network (using rc.local – it
cannot autodetect, as they did not include this model in this
version of the trapping software), the OS things the NIC is a dual
port card (it is a dual media card 10BaseT and 10Base2, but single
port). It then sets up the network on en1. The network will function
locally until you try to use ftp to upload a large file to a machine,
say, across the room. Then it fails. When io-net is slayed, and things
restarted, the network then comes up on en0 (not en1), and it works
as before – until you try a largish ftp transfer again.

The NIC is a SMC EtherEZ (8416), which I think is actually a Western Digital
card.

Here is some output:
on boot:
$ /sbin/ifconfig -a
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
inet 127.0.0.1 netmask 0xff000000
inet6 fe80:1::1 prefixlen 64
inet6 ::1 prefixlen 128
en0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:ff:01:ff:01:ff
en1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:c0:6a:2b:eb
inet 144.92.179.65 netmask 0xffffff00 broadcast 144.92.179.255
inet6 fe80:3::200:c0ff:fe6a:2beb prefixlen 64
when using ftp:
ftp> get st5k_trk.exe
local: st5k_trk.exe remote: st5k_trk.exe
200 PORT command successful.
150 Opening BINARY mode data connection for ‘st5k_trk.exe’ (39896 bytes).
100% |********************************************************| 39896
48.89 KB/s 00:00 ETA
226 Transfer complete.
39896 bytes received in 00:00 (47.81 KB/s)
ftp> put tffs_512_DOC_tools.zip
local: tffs_512_DOC_tools.zip remote: tffs_512_DOC_tools.zip
200 PORT command successful.
150 Opening BINARY mode data connection for ‘tffs_512_DOC_tools.zip’.
0% | | 0
0.00 KB/s --:-- ETAf
tp: netout: No such process
0% | | -1
0.00 KB/s --:-- ETA
421 Service not available, remote server has closed connection.
ftp> ls s
Not connected.
ftp> close
Not connected.
ftp> quit

output of nicinfo:SMC EtherEz Ethernet Controller
Physical Node ID … 0000C0 6A2BEB
Current Physical Node ID … 0000C0 6A2BEB
Media Rate … 10.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
Hardware Interrupt … 0xA
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 72
Total Packets Txd Bad … 0
Total Packets Rxd OK … 5137
Total Rx Errors … 0

Total Bytes Txd … 6129
Total Bytes Rxd … 363739

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 0

Note that nicinfo clames it is a UTP connection. It is actually using
a thin-net (10Base2) connection.

Any ideas?

Richard Bonomo
bonomo@sal.wisc.edu
\

4

Hugh Brown wrote:

How are you starting the driver in your rc.local file? I have
started the driver in my rc.local file and transferred large files
between 2 machine without any problems. When the driver is started,
it registers as en0. Here is my rc.local:

slay io-net
sleep 2
io-net -dwd -ptcpip
sleep 1
ifconfig en0 xx.xx.xx.xx up
inetd

Here is our rc.local:

slay io-net &
sleep 10
io-net -dwd -ptcpip -pqnet
sleep 1
ifconfig en0 down
ifconfig en1 144.92.179.65/24
ifconfig en1 up
sleep 8
route add -net default 144.92.179.1 -netmask 255.255.255.0

If I do this manually AFTER boot up, I have to configure en0
instead of en1, as I noted. (It should be en0 anyway, but on
boot, en1 is the “real” connection for some odd reason.)

Also, I recently discovered (or re-discovered) that we cannot
reach anything beyond our LAN router (“no route to host” error),
no matter what I do the routing tables.

Rich

5

Richard Bonomo,6289 Chamberlin,263-4683, <bonomo@sal.wisc.edu> wrote:

Hugh Brown wrote:

How are you starting the driver in your rc.local file? I have
started the driver in my rc.local file and transferred large files
between 2 machine without any problems. When the driver is started,
it registers as en0. Here is my rc.local:

slay io-net
sleep 2
io-net -dwd -ptcpip
sleep 1
ifconfig en0 xx.xx.xx.xx up
inetd

Here is our rc.local:

slay io-net &
sleep 10
io-net -dwd -ptcpip -pqnet
sleep 1
ifconfig en0 down
ifconfig en1 144.92.179.65/24
ifconfig en1 up
sleep 8
route add -net default 144.92.179.1 -netmask 255.255.255.0

This doesn’t look right. Try simply:

route add default 144.92.179.1

If I do this manually AFTER boot up, I have to configure en0
instead of en1, as I noted. (It should be en0 anyway, but on
boot, en1 is the “real” connection for some odd reason.)

Also, I recently discovered (or re-discovered) that we cannot
reach anything beyond our LAN router (“no route to host” error),
no matter what I do the routing tables.

Rich

6

Sean Boudreau wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:
Hugh Brown wrote:

How are you starting the driver in your rc.local file? I have
started the driver in my rc.local file and transferred large files
between 2 machine without any problems. When the driver is started,
it registers as en0. Here is my rc.local:

slay io-net
sleep 2
io-net -dwd -ptcpip
sleep 1
ifconfig en0 xx.xx.xx.xx up
inetd

Here is our rc.local:

slay io-net &
sleep 10
io-net -dwd -ptcpip -pqnet
sleep 1
ifconfig en0 down
ifconfig en1 144.92.179.65/24
ifconfig en1 up
sleep 8
route add -net default 144.92.179.1 -netmask 255.255.255.0

This doesn’t look right. Try simply:

route add default 144.92.179.1

That DOES help the odd routing problem to some extent, but
the NIC weirdness remains. (It’s hard to test routing thoroughly
as the network interface crashes as described – unpredictably (sp?).

7

I tested this with the 6.2.1 driver. Have you tried upgrading the driver?

Previously, Richard Bonomo,6289 Chamberlin,263-4683, wrote in qdn.public.qnxrtp.installation:

Sean Boudreau wrote:

Richard Bonomo,6289 Chamberlin,263-4683, <> bonomo@sal.wisc.edu> > wrote:
Hugh Brown wrote:

How are you starting the driver in your rc.local file? I have
started the driver in my rc.local file and transferred large files
between 2 machine without any problems. When the driver is started,
it registers as en0. Here is my rc.local:

slay io-net
sleep 2
io-net -dwd -ptcpip
sleep 1
ifconfig en0 xx.xx.xx.xx up
inetd

Here is our rc.local:

slay io-net &
sleep 10
io-net -dwd -ptcpip -pqnet
sleep 1
ifconfig en0 down
ifconfig en1 144.92.179.65/24
ifconfig en1 up
sleep 8
route add -net default 144.92.179.1 -netmask 255.255.255.0

This doesn’t look right. Try simply:

route add default 144.92.179.1



That DOES help the odd routing problem to some extent, but
the NIC weirdness remains. (It’s hard to test routing thoroughly
as the network interface crashes as described – unpredictably (sp?).

8

Hugh Brown wrote:

I tested this with the 6.2.1 driver. Have you tried upgrading the driver?

Someone just recently suggested an upgrade, and I have sent e-mail to our
sales rep about getting the update CD (no response yet). Is it possible for
me to obtain and install the driver before doing an upgrade of whole system,
so I can try it? Can the driver be obtained over the network?

Rich

9

Richard Bonomo,6289 Chamberlin,263-4683, wrote:

…
That DOES help the odd routing problem to some extent, but
the NIC weirdness remains. (It’s hard to test routing thoroughly
as the network interface crashes as described – unpredictably (sp?).

Just as a bit of (I think) related info, I have also been seeing random
network weirdness. I am running Momentics 6.2.1 installed on a desktop
(Athlon) using the tulip driver. Connecting to an iPaq running eQip (QNX
for the iPaq) I have never seen network problems. Connecting to a PC104
board running the crys8900 driver, I occasionally see io-net crash on
PC104. So I concluded something must be be wrong with the PC104, either
the hardware or the crys8900 driver.

But then a few days ago I tried connecting to another PC104 running the
Davicom driver (not QNX supported) from here:
http://www.jumptec.de/SW_DB/PAGES/Board63.htm#Board63BS12

The Davicom driver generally worked ok, but it frequently crashed io-net
on the desktop with the tulip driver! And this doing simple things like
doing an ‘ls’ on the remote directory. So then I tried sticking an Intel
ethernet board in the desktop, and had the same symptoms.

Since two boards in the desktop behaved identically (within the limits
of “randomness”), that leads me to conclude there is an underlying
problem, not necessarily restricted to the individual drivers. I suspect
there might be a bug in the Davicom driver, which is triggering a
problem on the desktop. I am inclined to assume that nothing that a
remote device does should crash io-net on the desktop.

Oddly, the main use I have for the network is that I compile code on the
desktop, and then leave it there and execute it remotely on the PC104
boards, and am using QNX resource managers which programs are accessing
across the network. All this generates quite a lot of ethernet activity,
which never has crashed io-net on any of the machines, regardless of the
combination of ethernet interfaces/drivers (including with the Davicom).
Go figure!

Also, the desktop is a multiboot, with QNX, Linux, and Win2000. I have
not seen a network problem with the other OSes.

10

Send driver via e-mail.

Previously, Richard Bonomo,6289 Chamberlin,263-4683, wrote in qdn.public.qnxrtp.installation:

Hugh Brown wrote:

I tested this with the 6.2.1 driver. Have you tried upgrading the driver?


Someone just recently suggested an upgrade, and I have sent e-mail to our
sales rep about getting the update CD (no response yet). Is it possible for
me to obtain and install the driver before doing an upgrade of whole system,
so I can try it? Can the driver be obtained over the network?

Rich

11

Hugh Brown wrote:

Send driver via e-mail.

I’m sorry but I do not know if this is an instruction to

me to send you my current driver, or if it is an instruction
to someone else to send an updated driver to me.
Which is it?

Rich

12

Hugh Brown wrote:

Send driver via e-mail.

I will assume you want me to send the devn-wd.so I am
using now, so I will send it within a few minutes of posting
this…

Rich

13

Hugh Brown wrote:

Send driver via e-mail.

OK. I installed the 6.2.1 driver you sent me. It is too
early for me to report on “crashability,” but I can report
that it is still producing the phantom “en1” as before,
on boot.

Rich

14

Hugh Brown wrote:

Send driver via e-mail.

OK, I am happy to report that ftp seems to be working with
the 6.2.1 devn-wd.so driver. At least, I managed to
transfer several large files without incident, which
is a first with 6.2 for us.

The double port (en0 and en1) phenomenon on boot-up remains,
but at least we are operational for now.

Rich

15

Richard Bonomo <bonomo@sal.wisc.edu> wrote:

Hugh Brown wrote:
Send driver via e-mail.

OK, I am happy to report that ftp seems to be working with
the 6.2.1 devn-wd.so driver. At least, I managed to
transfer several large files without incident, which
is a first with 6.2 for us.

The double port (en0 and en1) phenomenon on boot-up remains,
but at least we are operational for now.

My guess is the enumeration process at boot up detected another
card on your system. You can look at the ‘nicinfo’ output to
see what it is. Also ‘pidin me’ to see which dll’s are loaded
into io-net.

-seanb