public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zhang Fuxin <fxzhang@ict.ac.cn>
To: Robert Olsson <Robert.Olsson@data.slu.se>
Cc: Paul <xerox@foonet.net>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: NAPI eepro100 bug fixed
Date: Tue, 18 Jun 2002 11:25:46 +0800	[thread overview]
Message-ID: <3D0EA83A.50606@ict.ac.cn> (raw)
In-Reply-To: 15624.63280.379421.369909@robur.slu.se

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

hi,all
      My first NAPI eepro100 contains a subtle but fatal race,which will 
lead
to lockup(of the whole machine here,but of ether interface for paul). This
version should be ok, Paul, would you like to have a try? I've tested it 
in my
pcs,it seems very stable now. Even 50kpps traffic won't cause any problem
here.
      The bug is explained in the comment,i think NAPI driver writer 
probably
will meet it,so it is listed here.
     /* disable interrupts here is necessary!
         * We need to ensure Rx/RxNobuf ints are disabled if in poll
         * flag is set. If interrupt comes bwteen netif_rx_complete
         * and enable_rx_and_rxnobuf_ints, the following will happen:
         *         netif_rx_complete --> clear RX_SCHED flag
         *           -> ints(e.g. TxDone)
         *                  speedo_interrupt
         *                       if (netif_rx_schedule_prep(dev))
         *                          disable_rx_and_rxnobuf_ints
         *                  return
         *           <-
         *         enable_rx_and_rxnobuf_ints
         *  then we will have Rx&RxNoBuf ints enable while in polling!
         *  it may lead to endless interrupts and effective lockup of
         *  the whole machine.
         */
        spin_lock_irqsave(&sp->lock,flags);
        netif_rx_complete(dev);
        enable_rx_and_rxnobuf_ints(dev);
        spin_unlock_irqrestore(&sp->lock,flags);
 
  Sorry for my delay,it is all the world cup's fault:)

Robert Olsson wrote:

>Paul writes:
> > Man well I tried 2.4.17 kernel
> > eepro100.c driver patched with NAPI and as soon as 
> > I route traffic to it it destroys eth0 and eth1 which are the two
> > interfaces that take the traffic.. they just die.. nothing in logs
> > nothing in dmesg, no errors, just all of a sudden no traffic
> > can go in or out those interfaces... sigh.. 
> > I then took the driver from kernel 2.5.21 and put it in 2.4.17 and compiled
> > after patching with NAPI and had the same problem..
> > 
> > You have any idea what the deal is?
> > 
> > It just dies instantly..
>
> Honestly no, just uploaded the eeproo napi patch from Zhang Fuxin he might 
> have some ideas. 
>
> I'm struggling with napi variant of the D-LINK sundance driver for 4-port 
> board myself.
>
> Cheers.
>
>						--ro
>
>



[-- Attachment #2: eepro100-napi.tar.gz --]
[-- Type: application/gzip, Size: 7900 bytes --]

       reply	other threads:[~2002-06-18  3:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <15624.57000.928651.530593@robur.slu.se>
     [not found] ` <JBEKKKICLLIJKLIGCCKLCEAJCCAA.xerox@foonet.net>
     [not found]   ` <15624.63280.379421.369909@robur.slu.se>
2002-06-18  3:25     ` Zhang Fuxin [this message]
2002-06-18  4:43       ` NAPI eepro100 bug fixed kuznet
2002-06-18 17:07       ` Robert Olsson
     [not found] <3D0EF872.7020007@ict.ac.cn>
2002-06-18 17:54 ` kuznet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D0EA83A.50606@ict.ac.cn \
    --to=fxzhang@ict.ac.cn \
    --cc=Robert.Olsson@data.slu.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xerox@foonet.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox