Re: frame value too large by ifconfig!!!!

On Wed, 27 Feb 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <73bbadc8-a9bd-4351-b26e-17d220080ae2@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
water9580@xxxxxxxxx wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

ibupro...@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin) wrote:

water9...@xxxxxxxxx wrote:

That doesn't look good.

inet addr:192.168.1.22 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::255:7bff:feb5:7df7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:21668
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:60 (60.0 b) TX bytes:0 (0.0 b)
Interrupt:169

You can't talk to the NIC - you may be using the wrong driver. The
actual meaning of a Frame error is that the number of BITS is not
exactly dividable by 8 (bytes) which is wrong because an Ethernet
frame is always and exact number of bytes in length. This usually
indicates a hardware failure, but can also be caused by using the
wrong driver.

03:00.0 Ethernet controller: ABC Networks Inc Unknown device 0003 (rev
01)
Subsystem: Airgo Networks Inc Unknown device 0003

This PCIE NIC is designed by myself. i just borrow Airgo vendor/device
ID random. it isn't any product if Airgo.

Then there is some unknown design error. You are not getting the
correct flags, or your data path between the NIC and the computer
bus is not reliable. You should also change the 'Subsystem' data
and delete reference to Airgo - "Unofficial" might be a better choice,
as that word does not exist in the IEEE OUI data file.

ifconfig command shows one good packet of RX side,Tx side is not any.

It appears from the ifconfig output above that you got one packet of
60 bytes. Not knowing what is on your network,I can't say what that
may have been. Apparently, there was no attempt to transmit FROM THIS
DEVICE.

do you mean the large frame value is from Tx side ?

No. I have no idea what your design looks like, but normally when a
packet is received, and the trailing frame checksum is tested, the
hardware creates an interrupt. The driver on receiving this interrupt
reads a data count value (how many bytes to unload), and a flag
register, and then reads the data. Speaking of Ethernet, the number
of bits on the wire is ALWAYS an exact number of bytes (bits/8 * N is
always equal to N.0000), and the hardware will set the Frame Error
flag if this is not the case.

BITS BYTE ERROR BITS BYTE ERROR BITS BYTE ERROR
475 59+3 FLAG 476 59+4 FLAG 477 59+5 FLAG
478 59+6 FLAG 479 59+7 FLAG 480 60+0 OK
481 60+1 FLAG 482 60+2 FLAG 483 60+3 FLAG

Here, the flag gets set for every case except when BITS = 480 because
480/8 = 60.000 meaning there was no left-over bits. In every other case,
there were extra bits - they do not belong here, so where did they
come from? Did they come over the wire? Perhaps the (source) is bad
(does a different NIC receive frames correctly from this source), but
it's more likely to be a hardware error. On Ethernet, this may be
caused by a wrong time constant on the hardware directly connected
to the Ethernet making the card see an extra data transition. Now
according to the driver, it is seeing the Frame Error flag every time,
so either your hardware is setting the Frame Error flag always, or it
is never cleared when you have read the data, or you are reading the
wrong bit.

You'll have to look at the driver source, and see what it is trying to
read. Is your hardware setting things correctly?

Old guy
.

Relevant Pages