frame value too large by ifconfig!!!!
wate...@yahoo.com
ifconfig output:
eth2 Link encap:Ethernet HWaddr 00:55:7B:B5:7D:F7
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
why the frame value(21668) so large?
lspci -vvv
03:00.0 Ethernet controller: ABC Networks Inc Unknown device 0003 (rev
01)
Subsystem: Airgo Networks Inc Unknown device 0003
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 169
Region 0: Memory at b8900000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 40000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot
+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <1us, L1 <8us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s <512ns, L1 <64us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Moe Trin
article <9ea768c5-29cc-4312...@i29g2000prf.googlegroups.com>,
wate...@yahoo.com 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.
>my NIC doesn't work .My os is RHEL5.1/32bit/dual core intel cpu. the
>ifconfig output:
>
>eth2 Link encap:Ethernet HWaddr 00:55:7B:B5:7D:F7
[compton ~]$ etherwhois 00:55:7B
Non-existent address as of Feb 24 10:03:16 UTC 2008 OUI file
[compton ~]$
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
>
>why the frame value(21668) so large?
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
From the pci.ids file, dated 2/24/08
17cb Airgo Networks Inc
0001 AGN100 802.11 a/b/g True MIMO Wireless Card
0002 AGN300 802.11 a/b/g True MIMO Wireless Card
[compton ~]$ etherwhois Airgo
00-0A-F5 (hex) Airgo Networks, Inc.
000AF5 (base 16) Airgo Networks, Inc.
900 Arastradero Rd
Palo Alto CA 94304
UNITED STATES
[compton ~]$
It would appear that the device is unknown. You might try using the
search engine you are posting from - a search for 'Airgo NIC Linux'
turns up some information, and might be a starting place.
Old guy
wate...@yahoo.com
> On Sat, 23 Feb 2008, in the Usenet newsgroup comp.os.linux.networking, in
This PCIE NIC is designed by myself. i just borrow Airgo vendor/device
ID random. it isn't any product if Airgo.
ifconfig command shows one good packet of RX side,Tx side is not any.
do you mean the large frame value is from Tx side ?
david
say:
Are you sure that your self-designed hardware is working correctly?
Moe Trin
article <73bbadc8-a9bd-4351...@d5g2000hsc.googlegroups.com>,
wate...@yahoo.com 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...@painkiller.example.tld (Moe Trin) wrote:
>> water9...@yahoo.com 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