MAC address and NE2000

While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers, harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I will
keep you informed.

My question is:
Is MAC address data read from HW with every invocation of netinfo -L1, or is
it just in-memory copy?

Thanks

Pavol Kycina

PS: I am using QNX 4.25, but also QNX 6.1A seems to be affected by same
problem.

Previously, Pavol Kycina wrote in qdn.public.qnx4:

While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers, harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I will
keep you informed.

My question is:
Is MAC address data read from HW with every invocation of netinfo -L1, or is
it just in-memory copy?

Its just an in-memory copy.

Thanks

Pavol Kycina

PS: I am using QNX 4.25, but also QNX 6.1A seems to be affected by same
problem.



\

“Pavol Kycina” <kycina@microstep-hdo.sk> wrote in message
news:3c9b3999$1@asrpx.mshdo

While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers,
harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I
will
keep you informed.

Here is the summary:

My test equipment consists of:

processor boards:
SBC with AMD 5x86 133MHz, or AMD 486 100MHz
SBC with STPC 66MHz
old 486 based system with AMD 5x86 133MHz

storage:
CF card Apacer 32MB
CF card Transcend 64MB
HDD Western Digital 8.4GB

network cards:
ISA NE2000, Genius chip
ISA NE2000, RTL8019AS chip
embedded in SBC, ISA NE2000, RTL8019AS

With all these I have done following:

  1. boot plain QNX 4.25 system
  2. start Net &
  3. start Net.ether1000 -vvvv & (cable is connected to the nearest hub)
  4. wait some time (in range of minutes)

With some combinations of HW I started to get this output on my screen
(several seconds after Net.ether1000 startup):
Addr prom xxxx xxyy yyyy
Addr prom xxxx xxzz zzzz
Addr prom xxxx xxuu uuuu

All of these statements where accompanied by entry in netinfo output “(521)
bad rxed status header info”.

These combinations seem to be problematic:
CF Transcend + any AMD processor + NIC based RTL8019AS chip

The problem didn’t exhibit when there was CF Apacer or HDD used (instead of
Transcend one). Also STPC processor with Transcend and RTL8019AS was working
well.

In all my tests I used CF or HDD just for boot-up, it was not used later
(after starting Net, Net.ether1000 I didn’t even touch keyboard), no files
were read or written to storage medium.

The final summary:
I should be well if I don’t use transcend CF. (processor and NIC chip is
soldered to SBC)
BUT transcend seems to be much more reliable than apacer (in my long term
tests).
And I don’t see a reason why CF card should be a cause of problems with
ethernet MAC address.

Any hints?

Thank you, Pavol Kycina

PS: My problem is to find a solid CF card, which works in the HW the
customer has, and at the same time it is reliable over long time.

Maybe you have a hardware conflict between the network
card and some other devices.

“Pavol Kycina” <kycina@microstep-hdo.sk> wrote in message
news:3c9efc10$1@asrpx.mshdo

“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9b3999$> 1@asrpx.mshdo> …
While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers,
harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I
will
keep you informed.

Here is the summary:

My test equipment consists of:

processor boards:
SBC with AMD 5x86 133MHz, or AMD 486 100MHz
SBC with STPC 66MHz
old 486 based system with AMD 5x86 133MHz

storage:
CF card Apacer 32MB
CF card Transcend 64MB
HDD Western Digital 8.4GB

network cards:
ISA NE2000, Genius chip
ISA NE2000, RTL8019AS chip
embedded in SBC, ISA NE2000, RTL8019AS

With all these I have done following:

  1. boot plain QNX 4.25 system
  2. start Net &
  3. start Net.ether1000 -vvvv & (cable is connected to the nearest hub)
  4. wait some time (in range of minutes)

With some combinations of HW I started to get this output on my screen
(several seconds after Net.ether1000 startup):
Addr prom xxxx xxyy yyyy
Addr prom xxxx xxzz zzzz
Addr prom xxxx xxuu uuuu

All of these statements where accompanied by entry in netinfo output
“(521)
bad rxed status header info”.

These combinations seem to be problematic:
CF Transcend + any AMD processor + NIC based RTL8019AS chip

The problem didn’t exhibit when there was CF Apacer or HDD used (instead
of
Transcend one). Also STPC processor with Transcend and RTL8019AS was
working
well.

In all my tests I used CF or HDD just for boot-up, it was not used later
(after starting Net, Net.ether1000 I didn’t even touch keyboard), no files
were read or written to storage medium.

The final summary:
I should be well if I don’t use transcend CF. (processor and NIC chip is
soldered to SBC)
BUT transcend seems to be much more reliable than apacer (in my long term
tests).
And I don’t see a reason why CF card should be a cause of problems with
ethernet MAC address.

Any hints?

Thank you, Pavol Kycina

PS: My problem is to find a solid CF card, which works in the HW the
customer has, and at the same time it is reliable over long time.
\

“Pavol Kycina” <kycina@microstep-hdo.sk> wrote in message
news:3c9efc10$1@asrpx.mshdo

[snip]

I did another test. Start everything as usually, create ram disk, copy
umount and rm to ram disk. Then umount and rm /dev/hd0, so there is no
Fsys.eide in effect. The problem persists. It goes away only if I remove
compact flash from its socket. If I put it back, the problem reappears.

So, I am going to search for other compact flash vendor.

Pavol Kycina

I don’t think so, it works well with HDD, problem is only with some compact
flash. Configuration of all devices is the same.

Thanks anyway,
Pavol Kycina

“Mario Charest” <goto@nothingness.com> wrote in message
news:a7n37j$383$1@inn.qnx.com

Maybe you have a hardware conflict between the network
card and some other devices.

“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9efc10$> 1@asrpx.mshdo> …
“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9b3999$> 1@asrpx.mshdo> …
While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers,
harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I
will
keep you informed.

Here is the summary:

My test equipment consists of:

processor boards:
SBC with AMD 5x86 133MHz, or AMD 486 100MHz
SBC with STPC 66MHz
old 486 based system with AMD 5x86 133MHz

storage:
CF card Apacer 32MB
CF card Transcend 64MB
HDD Western Digital 8.4GB

network cards:
ISA NE2000, Genius chip
ISA NE2000, RTL8019AS chip
embedded in SBC, ISA NE2000, RTL8019AS

With all these I have done following:

  1. boot plain QNX 4.25 system
  2. start Net &
  3. start Net.ether1000 -vvvv & (cable is connected to the nearest hub)
  4. wait some time (in range of minutes)

With some combinations of HW I started to get this output on my screen
(several seconds after Net.ether1000 startup):
Addr prom xxxx xxyy yyyy
Addr prom xxxx xxzz zzzz
Addr prom xxxx xxuu uuuu

All of these statements where accompanied by entry in netinfo output
“(521)
bad rxed status header info”.

These combinations seem to be problematic:
CF Transcend + any AMD processor + NIC based RTL8019AS chip

The problem didn’t exhibit when there was CF Apacer or HDD used (instead
of
Transcend one). Also STPC processor with Transcend and RTL8019AS was
working
well.

In all my tests I used CF or HDD just for boot-up, it was not used later
(after starting Net, Net.ether1000 I didn’t even touch keyboard), no
files
were read or written to storage medium.

The final summary:
I should be well if I don’t use transcend CF. (processor and NIC chip is
soldered to SBC)
BUT transcend seems to be much more reliable than apacer (in my long
term
tests).
And I don’t see a reason why CF card should be a cause of problems with
ethernet MAC address.

Any hints?

Thank you, Pavol Kycina

PS: My problem is to find a solid CF card, which works in the HW the
customer has, and at the same time it is reliable over long time.


\

“Pavol Kycina” <kycina@microstep-hdo.sk> wrote in message
news:3c9f1424$1@asrpx.mshdo

“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9efc10$> 1@asrpx.mshdo> …

[snip]

I did another test. Start everything as usually, create ram disk, copy
umount and rm to ram disk. Then umount and rm /dev/hd0, so there is no
Fsys.eide in effect. The problem persists. It goes away only if I remove
compact flash from its socket. If I put it back, the problem reappears.

Then it’s got to be a hardware conflict? Is the compact flash connected

through PCMCIA?

What addresses is the compact flash using? What interrupt?


So, I am going to search for other compact flash vendor.

Pavol Kycina
\

Previously, Pavol Kycina wrote in qdn.public.qnx4:

“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9b3999$> 1@asrpx.mshdo> …
While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers,
harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I
will
keep you informed.

Have you tried to pass the I/O port and IRQ to the Net.ether1000 driver?

Here is the summary:

My test equipment consists of:

processor boards:
SBC with AMD 5x86 133MHz, or AMD 486 100MHz
SBC with STPC 66MHz
old 486 based system with AMD 5x86 133MHz

storage:
CF card Apacer 32MB
CF card Transcend 64MB
HDD Western Digital 8.4GB

network cards:
ISA NE2000, Genius chip
ISA NE2000, RTL8019AS chip
embedded in SBC, ISA NE2000, RTL8019AS

With all these I have done following:

  1. boot plain QNX 4.25 system
  2. start Net &
  3. start Net.ether1000 -vvvv & (cable is connected to the nearest hub)
  4. wait some time (in range of minutes)

With some combinations of HW I started to get this output on my screen
(several seconds after Net.ether1000 startup):
Addr prom xxxx xxyy yyyy
Addr prom xxxx xxzz zzzz
Addr prom xxxx xxuu uuuu

All of these statements where accompanied by entry in netinfo output “(521)
bad rxed status header info”.

These combinations seem to be problematic:
CF Transcend + any AMD processor + NIC based RTL8019AS chip

The problem didn’t exhibit when there was CF Apacer or HDD used (instead of
Transcend one). Also STPC processor with Transcend and RTL8019AS was working
well.

In all my tests I used CF or HDD just for boot-up, it was not used later
(after starting Net, Net.ether1000 I didn’t even touch keyboard), no files
were read or written to storage medium.

The final summary:
I should be well if I don’t use transcend CF. (processor and NIC chip is
soldered to SBC)
BUT transcend seems to be much more reliable than apacer (in my long term
tests).
And I don’t see a reason why CF card should be a cause of problems with
ethernet MAC address.

Any hints?

Thank you, Pavol Kycina

PS: My problem is to find a solid CF card, which works in the HW the
customer has, and at the same time it is reliable over long time.

\

“Mario Charest” <goto@nothingness.com> wrote in message
news:a7n88f$72f$1@inn.qnx.com

“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9f1424$> 1@asrpx.mshdo> …
“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9efc10$> 1@asrpx.mshdo> …

[snip]

I did another test. Start everything as usually, create ram disk, copy
umount and rm to ram disk. Then umount and rm /dev/hd0, so there is no
Fsys.eide in effect. The problem persists. It goes away only if I remove
compact flash from its socket. If I put it back, the problem reappears.

Then it’s got to be a hardware conflict? Is the compact flash connected
through PCMCIA?

What addresses is the compact flash using? What interrupt?

No, it’s connected throught IDE 2 CF adapter.
http://www.advantech.com/products/PCM-3835.asp I am not aware of any
conflict.

Pavol Kycina

“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.020325083131.6396B@node90.ott.qnx.com

Previously, Pavol Kycina wrote in qdn.public.qnx4:
“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9b3999$> 1@asrpx.mshdo> …
While testing my system (and finding some hidden problem) I discovered
following:

With almost every invocation of “netinfo -L1” I get different physical
address (MAC) in netinfo output. I have tested several computers,
harddisks,
network cards, compact flash cards. When I have an idea what’s wrong I
will
keep you informed.


Have you tried to pass the I/O port and IRQ to the Net.ether1000 driver?

It’s autodetected, but correctly.

Pavol Kycina

“Pavol Kycina” <kycina@microstep-hdo.sk> wrote in message
news:3c9f2fd0@asrpx.mshdo

“Hugh Brown” <> hsbrown@qnx.com> > wrote in message
news:> Voyager.020325083131.6396B@node90.ott.qnx.com> …
Previously, Pavol Kycina wrote in qdn.public.qnx4:
“Pavol Kycina” <> kycina@microstep-hdo.sk> > wrote in message
news:3c9b3999$> 1@asrpx.mshdo> …
While testing my system (and finding some hidden problem) I
discovered
following:

With almost every invocation of “netinfo -L1” I get different
physical
address (MAC) in netinfo output. I have tested several computers,
harddisks,
network cards, compact flash cards. When I have an idea what’s wrong
I
will
keep you informed.


Have you tried to pass the I/O port and IRQ to the Net.ether1000 driver?

It’s autodetected, but correctly.

If it autodetects, that means it scans a bunch of IO port. I may have hit
something that causes the hardware to misbehave.

Pavol Kycina

Have you tried to pass the I/O port and IRQ to the Net.ether1000
driver?

It’s autodetected, but correctly.

If it autodetects, that means it scans a bunch of IO port. I may have hit
something that causes the hardware to misbehave.

In the mean time I have returned it to the supplier, so I can’t test it.

Thanks anyway,

Pavol Kycina