# Oversized Ethernet frame spanned multiple buffers

## Pethell

Does anyone have a good answer to this problem?

eth0: Oversized Ethernet frame spanned multiple buffers, entry 0xe length 0 status 00000600!

eth0: Oversized Ethernet frame c1df50e0 vs c1df50e0.

eth0: Oversized Ethernet frame spanned multiple buffers, entry 0xf length 1518 status 05ee0d09!

eth0: Oversized Ethernet frame c1df50f0 vs c1df50f0.

The problem shows when there is relatively high networkactivety, i.e downloading a file.

After a few minuts of googling, I'v come up with the conclution that this is due to, 1. Broken kernel driver, 2. Slow computer, 3. Wrong MTU-settings.

The computer in question is a old Pentium Pro 200, 128MB RAM and the nic is a D-Link DFE-530TX.

Additional info.

eth0: negotiated 100baseTx-FD flow-control, link ok

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx  

          inet addr:xx.xx.xx.xx  Bcast:xx.xx.xx.xx  Mask:xx.xx.xx.xx

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1063611 errors:0 dropped:1263 overruns:0 frame:749

          TX packets:180745 errors:3 dropped:0 overruns:3 carrier:0

          collisions:0 txqueuelen:100 

          RX bytes:112403586 (107.1 Mb)  TX bytes:56899012 (54.2 Mb)

          Interrupt:10 Base address:0xff80

0000:01:07.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06)

        Subsystem: D-Link System Inc DFE-530TX rev A

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-

        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

        Latency: 96 (29500ns min, 38000ns max), cache line size 08

        Interrupt: pin A routed to IRQ 10

        Region 0: I/O ports at ec80 [size=128]

        Region 1: Memory at ffafff80 (32-bit, non-prefetchable) [size=128]

        Expansion ROM at ffae0000 [disabled] [size=64K]

Linux version 2.4.22-gentoo-r7 (root@xx.xx) (gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)) #2 Mon Mar 8 16:05:19 CET 2004

 :Rolling Eyes: 

----------

## adaptr

It could be that the PC is not fast enough to keep up with a 100mbit feed; what amount of traffic are we talking about ?

But from the text: how big are the buffers ?

Run

```
mii-tool
```

or

```
mii-diag
```

to see.

Depending on the NIC, my 3Com's usually have 8KB divided 5/3 among receive/send.

This means the NIC hardware won't be able to buffer more than 3 full frames before the PC has to pull the data off the card.

This indicates a slow computer more than anything else.

MTU setting should be fine, unless the upstream link is broken.

----------

## Pethell

 *adaptr wrote:*   

> It could be that the PC is not fast enough to keep up with a 100mbit feed; what amount of traffic are we talking about ?

 

Well, it can reach speeds of 7-8MB/s (i.e. from local squid-cache) faster machines reach 12MB/s. So the computer is slow, no questions there. But the flow-control would kick in if the interface can't handle the stream.. right?

 *Quote:*   

> But from the text: how big are the buffers ?
> 
> Run
> 
> ```
> ...

 

mii-tools only shows (with -v option)

eth0: negotiated 100baseTx-FD flow-control, link ok

  product info: Davicom DM9101 rev 0

  basic mode:   autonegotiation enabled

  basic status: autonegotiation complete, link ok

  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

mii-diag shows (with -v option)

mii-diag.c:v2.09 9/06/2003 Donald Becker (becker@scyld.com)

http://www.scyld.com/diag/index.html

Using the default interface 'eth0'.

  Using the new SIOCGMIIPHY value on PHY 8 (BMCR 0x3100).

 The autonegotiated capability is 01e0.

The autonegotiated media type is 100baseTx-FD.

 Basic mode control register 0x3100: Auto-negotiation enabled.

 You have link beat, and everything is working OK.

   This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.

   Able to perform Auto-negotiation, negotiation complete.

 Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.

   End of basic transceiver information.

libmii.c:v2.10 4/22/2003  Donald Becker (becker@scyld.com)

http://www.scyld.com/diag/index.html

 MII PHY #8 transceiver registers:

   3100 782d 0181 b800 05e1 45e1 0001 0000

   0000 0000 0000 0000 0000 0000 0000 0000

   0640 8088 6800 0000 0000 0000 0000 0000

   0000 0000 0000 0000 0000 0000 0000 0000.

 Basic mode control register 0x3100: Auto-negotiation enabled.

 Basic mode status register 0x782d ... 782d.

   Link status: established.

   Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.

   Able to perform Auto-negotiation, negotiation complete.

 Vendor ID is 00:60:6e:--:--:--, model 0 rev. 0.

   Vendor/Part: Davicom DM9101.

 I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT

   Advertising no additional info pages.

   IEEE 802.3 CSMA/CD protocol.

 Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT.

   Negotiation  completed.

  Davicom vendor specific registers: 0x0640 0x8088 0x6800.

 *Quote:*   

> Depending on the NIC, my 3Com's usually have 8KB divided 5/3 among receive/send.
> 
> This means the NIC hardware won't be able to buffer more than 3 full frames before the PC has to pull the data off the card.
> 
> This indicates a slow computer more than anything else.
> ...

 

----------

## adaptr

 *Quote:*   

> But the flow-control would kick in if the interface can't handle the stream.. right? 

 

Well, yes - but that's all interface-specific.

If the machine can't keep up with PCI transfers then it will likely generate the sort of errors you're getting.

Depending on what else this P-200 has to do, a full 100mbit FD feed may be just too much for the kernel TCP/IP stack to handle.

About the mii-stuff:maybe I misremembered that that's where you can find the buffer sizes...

But I'm positive you can get that info somewhere - maybe in /proc, maybe the driver info.

----------

## Pethell

 *Quote:*   

> If the machine can't keep up with PCI transfers then it will likely generate the sort of errors you're getting.
> 
> Depending on what else this P-200 has to do, a full 100mbit FD feed may be just too much for the kernel TCP/IP stack to handle.
> 
> About the mii-stuff:maybe I misremembered that that's where you can find the buffer sizes...
> ...

 

Ok. Thanx for your help.   :Wink: 

I'll try with a diffrent nic and see if the problem persist.

If it does it's not the end of the world.

----------

