From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 02:36:40 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 2DAFA16A401 for ; Wed, 25 Apr 2007 02:36:40 +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 DFE9A13C45B for ; Wed, 25 Apr 2007 02:36:39 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.197] (c220-239-255-86.rivrw3.nsw.optusnet.com.au [220.239.255.86]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id F373E5C1A; Wed, 25 Apr 2007 12:36:36 +1000 (EST) Message-ID: <462EBEB3.3060208@fromorbit.com> Date: Wed, 25 Apr 2007 12:36:35 +1000 From: Alan Garfield User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Jeremy References: <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> <1177077805.4063.7.camel@hiro.auspc.com.au> <20070420233619.GC52136@comp.chem.msu.su> <1177287886.4075.15.camel@hiro.auspc.com.au> <20070423145429.GF66604@comp.chem.msu.su> <20070424213706.GA1736@turion.vk2pj.dyndns.org> In-Reply-To: <20070424213706.GA1736@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yar Tikhiy , freebsd-net@freebsd.org Subject: Re: Corrupt packets in Jnet (Was: 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: Wed, 25 Apr 2007 02:36:40 -0000 Peter Jeremy wrote: > Given that we are effectivly dealing with a shared memory block, how > does the SP now when the server has finished writing and vice versa? > Is jnet's handling of multiple mbufs making the SP think there are > multiple packets? D'oh! /me slaps forehead I wondereded what the NAK response I saw I was getting after each TX. RX gets an interrupt, TX gets a NAK. If I block sending the next packet until I receive a NAK or I timeout that should fix it. Silly silly boy! >> Your jnet_start() routine fills the tail of the buffer w/zeros >> already, doesn't it? > > I would also suggest padding to 256 bytes with zeroes. Already does that as Yar correctly pointed out. The ADDR port is reset to zero, a bus_space_write_multi1 dumps into the DATA port the packet till there is no packet left, and a for loop fills what's left. Thanks, Alan.