From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 14:03:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 453DA16A402 for ; Fri, 20 Apr 2007 14:03:28 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id C772713C469 for ; Fri, 20 Apr 2007 14:03:27 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 624895C19; Sat, 21 Apr 2007 00:03:25 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070419175331.GA5999@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au> <20070419175331.GA5999@comp.chem.msu.su> Content-Type: text/plain Date: Sat, 21 Apr 2007 00:03:25 +1000 Message-Id: <1177077805.4063.7.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 14:03:28 -0000 On Thu, 2007-04-19 at 21:53 +0400, Yar Tikhiy wrote: > 1. Ping the Linux side with packets close to the MTU in size (ping > -s), use different data patterns (ping -p), see with tcpdump -X if > the data gets damaged. Yeah I figured out. I wasn't handling mbuf chains properly so a bit of the packet wasn't being put into the buffer. Fixed that now.... BUT! Now I get this after I log in and try to output anything more than a few characters (eg. ls -la) :- ---- Disconnecting: Corrupted MAC on input. ---- I'm sure it's something to do with how I'm doing the output. Does this look sane? ---- static void jnet_start_locked(struct ifnet* ifp) { /* {{{ */ struct jnet_softc *sc = ifp->if_softc; struct mbuf *m0, *m; int i, total_len; //device_printf(sc->dev, "jnet_start_locked() called.\n"); JNET_ASSERT_LOCKED(sc); outputloop: if ((&ifp->if_snd)->ifq_len == TX_QUEUE_SIZE || (&ifp->if_snd)->ifq_drv_len == TX_QUEUE_SIZE) { /* No room left. Set OACTIVE to tell everyone */ ifp->if_drv_flags |= IFF_DRV_OACTIVE; return; } IFQ_DRV_DEQUEUE(&ifp->if_snd, m); if (m == 0) { /* * Space is still available in buffers so allow * new packets to be added */ ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; return; } m0 = m; /* set address counter to zero, then read the entire fifo */ bus_space_write_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_STATUS_OFFSET, 0x00); /* Output the IP_CHAR to tell SP the buffer is an IP packet */ bus_space_write_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, IP_CHAR); total_len = 0; // Loop over mbuf chain and output data to PRS1 DATA register - Packet max length should // already be worked out by the upper layers while (m0) { if(m0->m_len) { total_len += m0->m_len; /* Output ethernet frame to prs buffer */ bus_space_write_multi_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, mtod(m0, unsigned char *), m0->m_len); } m0 = m0->m_next; } device_printf(sc->dev, "len: %i padding: %i total: %i\n", total_len, FRAME_SIZE - total_len, total_len + (FRAME_SIZE - total_len)); /* Added padding to fill what's left of the buffer */ for (i = total_len; i < FRAME_SIZE; i++) { bus_space_write_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, 0x00); } m0 = m; BPF_MTAP(ifp, m0); m_freem(m0); /* Loop to top to possibly buffer more packets */ goto outputloop; } ---- > Nevertheless, it can be a reference driver working with real hardware > for other folks to study. It's simple enough once I figured out where the pitfalls are. :) -A.