From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28339 invoked by alias); 22 Jun 2005 21:05:44 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 27821 invoked by uid 22791); 22 Jun 2005 21:05:04 -0000 Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.206) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 22 Jun 2005 21:05:03 +0000 Received: by wproxy.gmail.com with SMTP id 36so103431wra for ; Wed, 22 Jun 2005 14:04:56 -0700 (PDT) Received: by 10.54.39.67 with SMTP id m67mr702451wrm; Wed, 22 Jun 2005 14:04:55 -0700 (PDT) Received: by 10.54.39.72 with HTTP; Wed, 22 Jun 2005 14:04:55 -0700 (PDT) Message-ID: Date: Wed, 22 Jun 2005 21:05:00 -0000 From: Fernando Flores Reply-To: Fernando Flores To: ecos-discuss@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [ECOS] Bug (and fix) for FEC driver PowerPC FEC X-SW-Source: 2005-06/txt/msg00210.txt.bz2 Hello, We have a Device with a Motorola PowerPC 855 w/ a FEC. We noticed that under heavy traffic loads, the network will stop receiving packets. Further investigation pointed to having all the RX buffer descriptors being full, but the processor stop sending interrupts.=20 Upon examining the fec code under '/ecos/packages/devs/eth/powerpc/fec//src/if_fec.c, we noticed that the interrupt handler code was written as: // // Interrupt processing // static void=20=20=20=20=20=20=20=20=20=20 fec_eth_int(struct eth_drv_sc *sc) { struct fec_eth_info *qi =3D (struct fec_eth_info *)sc->driver_private; unsigned long event; while ((event =3D qi->fec->iEvent) !=3D 0) { if ((event & iEvent_TFINT) !=3D 0) { fec_eth_TxEvent(sc); } if ((event & iEvent_RFINT) !=3D 0) { fec_eth_RxEvent(sc); } qi->fec->iEvent =3D event; // Reset the bits we handled } } The problem here is that we first clear out the RX buffers, then handle the TX buffers. But the FEC may receive more packets and fill up all buffers before we reset the bits in the event register. We then clear the event register but never empty the buffers when we loop back around. The processor believes we have acknowledged the event for the newly arrived packets and never sets the interrupt. This can be easily fixed by changing the order of the reset to the followin= g: // // Interrupt processing // static void=20=20=20=20=20=20=20=20=20=20 fec_eth_int(struct eth_drv_sc *sc) { struct fec_eth_info *qi =3D (struct fec_eth_info *)sc->driver_private; unsigned long event; while ((event =3D qi->fec->iEvent) !=3D 0) { qi->fec->iEvent =3D event; // Reset the bits we will handle if ((event & iEvent_TFINT) !=3D 0) { fec_eth_TxEvent(sc); } if ((event & iEvent_RFINT) !=3D 0) { fec_eth_RxEvent(sc); } } } We have tested this with and no longer have the network hang-up problems after flooding it with packets. The code is located in /ecos/packages/devs/eth/powerpc/fec//src/if_fec.c I hope this helps anyone having similar issues. To make this routine a bit better, it is a good idea to disable the FEC interrupts in the interrupt handler: // // Interrupt processing // static void=20=20=20=20=20=20=20=20=20=20 fec_eth_int(struct eth_drv_sc *sc) { struct fec_eth_info *qi =3D (struct fec_eth_info *)sc->driver_private; unsigned long event; unsigned long mask =3D qi->fec->iMask; // Disable all interrupts qi->fec->iMask =3D 0x0000000; while ((event =3D qi->fec->iEvent) !=3D 0) { qi->fec->iEvent =3D event; // Reset the bits we will handled if ((event & iEvent_TFINT) !=3D 0) { fec_eth_TxEvent(sc); } if ((event & iEvent_RFINT) !=3D 0) { fec_eth_RxEvent(sc); } } // Re-enable Interrupts qi->fec->iMask =3D mask; // enable interrupts } Is there a formal process to submit these changes to the official eCos distribution? Thanks, Fernando Flores -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss