file corruption during copy.

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

Hi,
Just to know if somebody noticed such problems, because I absolutely
don’t know the reason.

I got some files corrupted after having copied them through qnet. These
files were text files, executables and libs.

When I tried to execute the application, I got some unresolved symbols.
I discovered that, a symbol named ‘rememberxxxx’ in a shared lib, was
hanged in ‘remembedxxx’. I got some other strange thing like that.

In fact, as I also noticed such file corruptions with ped, I wonder if
the problem is in qnet or in the filesystem.

I did a chkfsys, nothing.

regards,
Alain.

2

Alain,

Never had a problem like that…what version of QNX are you using and what
kind of machines you are using?

Kevin

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3F275FC6.7090900@icbt.com…

Hi,
Just to know if somebody noticed such problems, because I absolutely
don’t know the reason.

I got some files corrupted after having copied them through qnet. These
files were text files, executables and libs.

When I tried to execute the application, I got some unresolved symbols.
I discovered that, a symbol named ‘rememberxxxx’ in a shared lib, was
hanged in ‘remembedxxx’. I got some other strange thing like that.

In fact, as I also noticed such file corruptions with ped, I wonder if
the problem is in qnet or in the filesystem.

I did a chkfsys, nothing.

regards,
Alain.

3

hi Kevin,
I’m using 6.2.1 SE on x86 machines

Alain.

Kevin Stallard a écrit:

Alain,

Never had a problem like that…what version of QNX are you using and what
kind of machines you are using?

Kevin

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3F275FC6.7090900@icbt.com> …


Hi,
Just to know if somebody noticed such problems, because I absolutely
don’t know the reason.

I got some files corrupted after having copied them through qnet. These
files were text files, executables and libs.

When I tried to execute the application, I got some unresolved symbols.
I discovered that, a symbol named ‘rememberxxxx’ in a shared lib, was
hanged in ‘remembedxxx’. I got some other strange thing like that.

In fact, as I also noticed such file corruptions with ped, I wonder if
the problem is in qnet or in the filesystem.

I did a chkfsys, nothing.

regards,
Alain.



\

4

On Wed, 30 Jul 2003 08:03:50 +0200, Alain Bonnefoy
<alain.bonnefoy@icbt.com> wrote:

Hi,
Just to know if somebody noticed such problems, because I absolutely
don’t know the reason.

I got some files corrupted after having copied them through qnet. These
files were text files, executables and libs.

When I tried to execute the application, I got some unresolved symbols. I
discovered that, a symbol named ‘rememberxxxx’ in a shared lib, was
hanged in ‘remembedxxx’. I got some other strange thing like that.

In fact, as I also noticed such file corruptions with ped, I wonder if
the problem is in qnet or in the filesystem.

We had this problem in QNX4 at a customer site. It was due to a bad
network card on one of the machines. I cannot tell you how this could
happen, but the end result was that the copy or transfer would complete
without any level of the software reporting an error, yet the information
was corrupted. We replaced the network card with another identical card
and the problem went away.

I always thought that there were various checksums and safeties in the
layers of data transmission in Ethernet and FLEET, but apparently they
are unable to catch every possible failure mode on a network card.

We also had some wacky problems due to a bad Ethernet hub, but those
were timing-related if I recall correctly.

Whether you think this is your problem or not, try replacing the network
cards, replace your router, try connecting the two machines directly using
a crossed patch cable. It’s a cheap and easy test to do.

Cheers,
Andrew

5

Andrew Thomas wrote:

I always thought that there were various checksums and safeties in the
layers of data transmission in Ethernet and FLEET, but apparently they
are unable to catch every possible failure mode on a network card.

There are CRC’s performed by the ethernet adapter, but FLEET has no error
detection code (it assumes that the hardware provides error detection, and does
not duplicate functionality unnecessarily - unlike TCP/IP which intentionally
makes no assumption about the capabilities of the underlying hardware).

If the ethernet card failed in such a way that it’s error detection circuitry
was faulty (not unimaginable), then FLEET would report no error on corrupt data.

Rennie

6

“Rennie Allen” <rgallen@attbi.com> wrote in message
news:bgdtp0$ro4$1@inn.qnx.com…

Andrew Thomas wrote:

I always thought that there were various checksums and safeties in the
layers of data transmission in Ethernet and FLEET, but apparently they
are unable to catch every possible failure mode on a network card.

There are CRC’s performed by the ethernet adapter, but FLEET has no error
detection code (it assumes that the hardware provides error detection, and
does
not duplicate functionality unnecessarily - unlike TCP/IP which
intentionally
makes no assumption about the capabilities of the underlying hardware).

If the ethernet card failed in such a way that it’s error detection
circuitry
was faulty (not unimaginable), then FLEET would report no error on corrupt
data.

Rennie,
“error detection circuitry” you are refering to is a part of an Ethernet
silicon. I can not imagine the chip got fried in such fancy way that it does
not check Ethernet CRC but still let packets thru. It is unimaginable but
still possible, though :slight_smile: (I have seen controllers with CRC checking
disable/enable option.) Anyway, it is not very hard to figure out the truth:
one hub (not a switch), two PC running QNX and qnet and one PC running a
free sniffer, Ethereal http://www.ethereal.com , for example.

But I would check nicinfo output first for tx/rx/CRC problems.

7

Dmitri Poustovalov wrote:

Rennie,
“error detection circuitry” you are refering to is a part of an Ethernet
silicon. I can not imagine the chip got fried in such fancy way that it does
not check Ethernet CRC but still let packets thru.

Admittedly, seems unlikely; but I was trying to make a basic point about FLEET
not having error detection. Other ways that the ethernet card could fail, and
cause corrupt packets:

  • faulty DMA handling
  • some other method of corrupting the data between the adapter and main memory
    of the computer.

btw: this would require a bus analyser (not simply a packet sniffer) to diagnose.

Rennie

8

Rennie,
“error detection circuitry” you are refering to is a part of an Ethernet
silicon. I can not imagine the chip got fried in such fancy way that it
does
not check Ethernet CRC but still let packets thru. It is unimaginable but
still possible, though > :slight_smile:

I have seen that a few times a long time ago, that was with ISA card though.
It sounded like the data was corrupted when transfered over the ISA bus.

9

“Rennie Allen” <rgallen@attbi.com> wrote in message
news:bggjar$r5r$1@inn.qnx.com…

Dmitri Poustovalov wrote:

Rennie,
“error detection circuitry” you are refering to is a part of an
Ethernet
silicon. I can not imagine the chip got fried in such fancy way that it
does
not check Ethernet CRC but still let packets thru.

Admittedly, seems unlikely; but I was trying to make a basic point about
FLEET
not having error detection. Other ways that the ethernet card could fail,
and
cause corrupt packets:

  • faulty DMA handling
  • some other method of corrupting the data between the adapter and main
    memory
    of the computer.

btw: this would require a bus analyser (not simply a packet sniffer) to
diagnose.

It may require both but I would begin with a sniffer anyway. The reason
being that all probems you listed above should contribute into tx story
also. If we sent a pattern as our packets’ payload then we would see packets
with a corrupted pattern and perfect CRC.

10

“Rennie Allen” <rgallen@attbi.com> wrote in message
news:bggjar$r5r$1@inn.qnx.com…

Dmitri Poustovalov wrote:

Rennie,
“error detection circuitry” you are refering to is a part of an
Ethernet
silicon. I can not imagine the chip got fried in such fancy way that it
does
not check Ethernet CRC but still let packets thru.

Admittedly, seems unlikely; but I was trying to make a basic point about
FLEET
not having error detection. Other ways that the ethernet card could fail,
and
cause corrupt packets:

  • faulty DMA handling
  • some other method of corrupting the data between the adapter and main
    memory
    of the computer.

btw: this would require a bus analyser (not simply a packet sniffer) to
diagnose.

Rennie

I believe that when this was being discussed WRT QNX4, the implication was
that QNX could detect network errors, but that they could not detect any
errors that may get made between the adapter and RAM.

I doubt that this helps anyone. But if we’re going to pass the buck, it may
as well be the correct buck.