NetBSD Problem Report #13212

Received: (qmail 4862 invoked from network); 15 Jun 2001 01:55:41 -0000
Message-Id: <200106150157.f5F1vwD28615@chuq.com>
Date: Thu, 14 Jun 2001 18:57:58 -0700 (PDT)
From: chuq@chuq.com
Reply-To: chuq@chuq.com
To: gnats-bugs@gnats.netbsd.org
Subject: next68k ethernet can't receive large packets
X-Send-Pr-Version: 3.95

>Number:         13212
>Category:       port-next68k
>Synopsis:       next68k ethernet can't receive large packets
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-next68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 15 01:56:00 +0000 2001
>Closed-Date:    Sat Jun 16 20:50:42 +0000 2001
>Last-Modified:  Sat Jun 16 20:50:42 +0000 2001
>Originator:     Chuck Silvers
>Release:        NetBSD-current 2001/06/14
>Organization:
me
>Environment:
System: NetBSD next.chuq.com 1.5W NetBSD 1.5W (SLAB.CHUQ) #47: Thu Jun 14 18:51:00 PDT 2001 chs@spathi.chuq.com:/home/chs/netbsd/src/sys/arch/next58k/compile/SLAB.CHUQ next68k


>Description:

next68k xe0 interface can no longer receive large packets.
they are dropped with the message:

	xe0: discarding oversize frame (len=1518)

the code which does this is in ether_input():

	if (m->m_pkthdr.len >
	    ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) {
		printf("%s: discarding oversize frame (len=%d)\n",
		    ifp->if_xname, m->m_pkthdr.len);
		m_freem(m);
		return;
	}

ETHER_MAX_FRAME() was recently changed to use the interface's MTU in the
upper-bound computation instead of ETHERMTU.  the xe0/mb8795 code has this
bit in mb8795_config():


	/* decrease the mtu on this interface to deal with
	 * alignment problems
	 */
	ifp->if_mtu -= 16;


so the ether code rejects the packet because it is larger than the MTU allows.



>How-To-Repeat:

turn on your next68k box

>Fix:

The mtu was set short since I was never able to get a full
length ethernet packet to transmit without truncation or
corruption.  From my original round of experimentation,
I was adding 15 byte to the length of the packet and rounding
up the length of the ethernet packet to the nearest cache line.
Unfortunately, a packet length of 1505 or greater would get
truncated if I set the length to 1520 and wouldn't go out
at all if I set the length to 1536.  After another round
of experimentation, I discovered that I don't have to
round to a cache line but I do have to add 15 bytes to
the length of the packet.

These cvs commits fix the problem in -current.  A last minute
pullup request was sent in for 1.5.1.

  sys/arch/next68k/dev/bus_dma.c revision 1.24
  sys/arch/next68k/dev/mb8795.c  revision 1.24
  sys/arch/next68k/dev/nextdma.c revision 1.29

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: dbj 
State-Changed-When: Sat Jun 16 13:49:14 PDT 2001 
State-Changed-Why:  
bugfix has been committed, although not extensively tested. 
>Unformatted:

Home	PR Database Search