[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-tulip
Subject:    Datapoint: Re: "Oversized Ethernet frame spanned multiple buffers"
From:       Tom Brown <tbrown () baremetal ! com>
Date:       1997-12-07 22:44:33
[Download RAW message or body]

On Sun, 7 Dec 1997, Steve wrote:

> David Woodhouse wrote:
> > 
> > I was away for the night, and found that my machine had rebooted at about 4am.
> > The logs have very little but the subject line shortly before the crash. This
> > machine has no cron jobs scheduled during the night; I like it quiet while I'm
> > sleeping.
> > 
> > What causes these messages (yes I know the idea, but what _exactly_? I would
> > have thought that a buffer would be 1584 bytes long and that a longer packet
> > than that would be impossible)?
> 
> David,
> 
> I have been living with that same message on my console screens for
> months. Nobody seems to know how to stop it.
> 
> I did see a message from someone who said it was caused by Windows 95/NT
> sending out broken ARP packets.
> 
> We are using kernel 2.0.32 with Netgear/Tulip cards at 100bt. No crashes
> or lockups because of this, however.

I've got some evidence that might help identify it.

We use MOSTLY SMC etherpower cards... a mix of the 10BT and 10/100 cards.

On Friday I was playing with a Lantronics LMS-8 switch which can do
Full-Duplex, although it does NOT do auto-negotiation (and I was unable to
get the SMC 10/100 card to go into full duplex with this device)... 

Anyhow, 'in the end' I only changed one thing. I switched from using the
de4x5 driver in the 2.0.32 kernel, to the tulip driver, and then to the
current stable tulip driver:

Dec  5 16:40:21 tin kernel: tulip.c:v0.83 10/19/97 becker@cesdis.gsfc.nasa.gov
Dec  5 16:40:21 tin kernel: eth0: Digital DS21140 Tulip at 0x6100, 00 e0
29 00 e1 bb, IRQ 11.

Immediately, one machine on that segment started getting the:

Dec  7 15:49:49 aluminum kernel: eth0: Ethernet frame 
			spanned multiple buffers,status 7fffceff!
Dec  7 15:49:49 aluminum kernel: eth0: Ethernet frame 
			spanned multiple buffers,status 06a081ae!
Dec  7 15:50:35 aluminum kernel: eth0: Ethernet frame 
			spanned multiple buffers,status 7fffceff!
Dec  7 15:50:35 aluminum kernel: eth0: Ethernet frame 
			spanned multiple buffers,status 065d81ae!
Dec  7 15:57:39 aluminum kernel: eth0: Ethernet frame 
			spanned multiple buffers,status 7fffceff!
Dec  7 15:57:39 aluminum kernel: eth0: Ethernet frame 
			spanned multiple buffers,status 063181ae!


warning messages (these messages show up in pairs). That machine was 
the only other machine on that segment to be running the tulip 
driver...  it's specs are:

tulip.c:v0.10 8/11/95 becker@cesdis.gsfc.nasa.gov
        +0.72 4/17/96 http://www.dsl.tutics.tut.ac.jp/~linux/tulip
        +0.02 12/15/96 mjacob@feral.com (2.0.27)
eth0: smc8432 (DEC 21041 Tulip) at 0x6100, 00:00:c0:b7:2d:e8, IRQ 11

One other datapoint. I recently moved a subnet... so while both these
machines are on the same segment, they don't know that... and they route
to each other via an ethernet card in the firewall (a <blush> PCI NE2000 
clone:)

NE*000 ethercard probe at 0x6100: 00 00 21 97 33 01
eth1: NE2000 found at 0x6100, using IRQ 9.

I don't know if this helps, but it should be a sufficiently
accurate description, and we know that ONLY changing the driver
on 'tin' was sufficient to cause the problem... average traffic
on the segment concerned is about 80 packets/sec, but these are
webservers, so it can be quite bursty... also, the warning
message was being logged 24 hours a day... (e.g. 456 lines in syslog,
over 14 hours).

Since then, 'tin' has been returned to the de4x5 driver...

----------------------------------------------------------------------
tbrown@BareMetal.com   | Don't go around saying the world owes you a living;
http://BareMetal.com/  | the world owes you nothing; it was here first.
                       | - Mark Twain

[prev in list] [next in list] [prev in thread] [next in thread]