Subject: Re: Ethernet driver bug?
To: Alexander A. V'ushkov <firstname.lastname@example.org>
From: Chuck Silvers <email@example.com>
Date: 11/03/2002 08:35:41
what revision of ofnet.c are you using? I fixed this problem with rev. 1.25:
date: 2002/09/18 01:47:08; author: chs; state: Exp; lines: +7 -9
use splnet() around the body of ofnet_read(). this is logically the
receive interrupt handler since it passes received packets to the
interface's input handler. that ends up scheduling a network softint
and queuing the packet on the interface's receive queue (in that order),
so if softnet isn't blocked at this point then softnet() doesn't find
the packet until it's triggered again by something else.
remove all vesitages of dk_establish().
if you've got that fix already then the problem is that the interrupt-masking
code isn't blocking the "softnet" interrupt level when it's supposed to.
are you using the "ofwgen" stuff that's in the ofppc port, or did you
write your own?
On Sun, Nov 03, 2002 at 06:26:19PM +0700, Alexander A. V'ushkov wrote:
> Hi, All!
> I'm continuing to start ofppc port of NetBSD on MPC8260.
> I'm deal with erratic NFS behavior, and as I suppose, there is a bug in the
> implementation of the Ethernet driver (function ether_input, file
> /net/if_ether_subr.c) Sometimes software interrupt, responsible for
> processing IP-queue of IP-stack (ip_intr() function) is called BEFORE than
> packet is really placed into IP-queue("ipintrq" variable). As a result, the
> packet will be processed only when the next packet arrives.
> I suppose that such behavior is ties with the specificity of the call of
> read function of the "ofnet" driver. It is called with assistance of callout
> mechinism. Probably, the current interrupt priority level lets software
> interrupt to occur (unlike calling the read function from hardware
> I've changed the order of actions. At first I've putted packet into
> IP-queue, and then set interrupt request. The error has disappeared.
> So, I want to know you opinion about the problem.