io-net crashes on large transfers via native networking over

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot

Which 802.11b driver are you running - Prism or Orinoco? What 802.11b
adapter do you have and is it PCMCIA or PCI?

“John Nagle” <nagle@overbot.com> wrote in message
news:3FAB5A6A.2060004@overbot.com

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:
I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot

QNX is just running the standard Ethernet driver. There’s
an external 802.11b bridge. We had everything working on
100baseT, and just substituted 802.11b bridges for the cable.

John Nagle

Hugh Brown wrote:

Which 802.11b driver are you running - Prism or Orinoco? What 802.11b
adapter do you have and is it PCMCIA or PCI?

“John Nagle” <> nagle@overbot.com> > wrote in message
news:> 3FAB5A6A.2060004@overbot.com> …

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot

\

What is “the standard Ethernet driver”? We have many!
It might be the driver that is crashing io-net.

“John Nagle” <nagle@downside.com> wrote in message
news:bogoa9$657$1@inn.qnx.com

QNX is just running the standard Ethernet driver. There’s
an external 802.11b bridge. We had everything working on
100baseT, and just substituted 802.11b bridges for the cable.

John Nagle

Hugh Brown wrote:
Which 802.11b driver are you running - Prism or Orinoco? What 802.11b
adapter do you have and is it PCMCIA or PCI?

“John Nagle” <> nagle@overbot.com> > wrote in message
news:> 3FAB5A6A.2060004@overbot.com> …

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot


\

Hugh Brown <hsbrown@qnx.com> wrote:
HB > What is “the standard Ethernet driver”? We have many!
HB > It might be the driver that is crashing io-net.

Hint:

Type:
pidin -Pio-net me | grep denv.*.so

More info from a crash dump of io-net. It had a segmentation fault.

This is repeatable; sending a few megabytes over native networking
over a slow 802.11b bridge does it.

Since QNX is a protected mode OS, with drivers in user space,
and the Ethernet driver is a separate program, the Ethernet
driver shouldn’t be able to affect this. Should it?

I will, however, find out what driver it is using once someone
goes to where that machine is and resets it. It’s off the
net again.

$ ls -l io-net
-rwxrwxr-x 1 nagle develop 58396 Jan 18 2003 io-net
$ gdb io-net io-net.core
GNU gdb 5.2.1qnx-326 QNX Neutrino 6.2.1

This GDB was configured as “ntox86”…(no debugging symbols found)…
Program terminated with signal 11, Segmentation fault.
#0 0xb0329ea5 in ?? ()
(gdb) backtrace
#0 0xb0329ea5 in ?? ()
#1 0x080508c6 in main ()

John Nagle

John Nagle wrote:

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot

This was done in GCC with the wrong version of io-net and the
…so files. Better results tomorrow, when I can get to the
machine in trouble.

More and more this looks like a 6.2.0/6.2.1 packaging problem.

John Nagle

John Nagle wrote:

More info from a crash dump of io-net. It had a segmentation fault.

This is repeatable; sending a few megabytes over native networking
over a slow 802.11b bridge does it.

Since QNX is a protected mode OS, with drivers in user space,
and the Ethernet driver is a separate program, the Ethernet
driver shouldn’t be able to affect this. Should it?

I will, however, find out what driver it is using once someone
goes to where that machine is and resets it. It’s off the
net again.

$ ls -l io-net
-rwxrwxr-x 1 nagle develop 58396 Jan 18 2003 io-net
$ gdb io-net io-net.core
GNU gdb 5.2.1qnx-326 QNX Neutrino 6.2.1

This GDB was configured as “ntox86”…(no debugging symbols found)…
Program terminated with signal 11, Segmentation fault.
#0 0xb0329ea5 in ?? ()
(gdb) backtrace
#0 0xb0329ea5 in ?? ()
#1 0x080508c6 in main ()

John Nagle

John Nagle wrote:

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot
\

I would suggest do a “pidin -p io-net mem” first so you would know
where is each module loaded.

Once you got a core, coreinfo io-net.core would show you the IP
where it generated the SIGSEGV, match it with the pidin output,
you would have a better idea where (in which module) the crash
happenes.

-xtang

John Nagle <nagle@downside.com> wrote in message
news:bohvbh$m0$1@inn.qnx.com

This was done in GCC with the wrong version of io-net and the
.so files. Better results tomorrow, when I can get to the
machine in trouble.

More and more this looks like a 6.2.0/6.2.1 packaging problem.

John Nagle

John Nagle wrote:
More info from a crash dump of io-net. It had a segmentation fault.

This is repeatable; sending a few megabytes over native networking
over a slow 802.11b bridge does it.

Since QNX is a protected mode OS, with drivers in user space,
and the Ethernet driver is a separate program, the Ethernet
driver shouldn’t be able to affect this. Should it?

I will, however, find out what driver it is using once someone
goes to where that machine is and resets it. It’s off the
net again.

$ ls -l io-net
-rwxrwxr-x 1 nagle develop 58396 Jan 18 2003 io-net
$ gdb io-net io-net.core
GNU gdb 5.2.1qnx-326 QNX Neutrino 6.2.1

This GDB was configured as “ntox86”…(no debugging symbols found)…
Program terminated with signal 11, Segmentation fault.
#0 0xb0329ea5 in ?? ()
(gdb) backtrace
#0 0xb0329ea5 in ?? ()
#1 0x080508c6 in main ()

John Nagle

John Nagle wrote:

The version of io-net running on the NC system is

58140 bytes May 02 2002

This is NOT the same version that the 6.2.1PE systems
are running. They have

58396 bytes Jan 18 2003

What’s going on here?

Part of the problem may be that we installed 6.2.1 NC without
the development tools on an x86 target machine, hoping to install
a basic system without building a custom boot image.
This may be related to the 6.2.1 packaging hell problem,
in which there are multiple, incompatible versions of key
components on a single distribution disk.

Still, for io-net to crash and cause a core dump is a bit much.

John Nagle
Team Overbot

John Nagle wrote:

I’ve now crashed io-net twice, simply by doing a “cp”
using native networking to transfer a file of a few
megabytes over a slow 802.11b link. Core dumps
of io-net are available. Where do I send them?

(QNX 6.2.1NC).

John Nagle
Team Overbot

\

John Nagle <nagle@downside.com> wrote:

Since QNX is a protected mode OS, with drivers in user space,
and the Ethernet driver is a separate program, the Ethernet
driver shouldn’t be able to affect this. Should it?

The ethernet driver devn-xxx.so is a shared object loaded into
io-net, not a seperate process.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

John Nagle wrote:

More info from a crash dump of io-net. It had a segmentation fault.

This is repeatable; sending a few megabytes over native networking
over a slow 802.11b bridge does it.

I have seen the very same symptoms caused by a board running the
crys8900 driver. The conditions for triggering it were somewhat odd.
Copying a file would frequently crash qnet, and it did not need to be a
large file either. But I don’t think I ever had a problem when executing
a program located in qnet land, even when the program was quite large.