All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: John Marvin <jsm@udlkern.fc.hp.com>
To: parisc-linux@thepuffingroup.com
Subject: [parisc-linux] Tulip Driver Bug
Date: Wed, 23 Feb 2000 09:25:55 -0700 (MST)	[thread overview]
Message-ID: <200002231625.JAA27870@udlkern.fc.hp.com> (raw)


I've been having reliability problems with networking on my J5000.
I tracked the problem down to this piece of code in tulip_interrupt():

    if (--work_budget < 0) {
	    if (tulip_debug > 1)
		    printk(KERN_WARNING "%s: Too much work during an interrupt, "
			       "csr5=0x%8.8x.\n", dev->name, csr5);
	    /* Acknowledge all interrupt sources. */
	    outl(0x8001ffff, ioaddr + CSR5);
	    /* Clear all interrupting sources, set timer to re-enable. */
	    outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt,
		     ioaddr + CSR7);
	    outl(12, ioaddr + CSR11);
	    break;
    }

My understanding is that this code tries to defer work until later because
too many incoming packets have been handled during the current interrupt.
The problem is that there is no later. Once this code is run I stop
seeing iosapic interrupts, and a little later I get some Tx Hung messages,
one or two more interrupts, and then that is it. The bug may not actually
be in the above code, i.e. it may be in the timer re-enable that is
mentioned in the comment above.

If I ifdef the above code out, the driver is fairly reliable. I've run
tests with more than 20 sockets open simultaneously.

I believe the reason I see this problem more than others is probably due
to the fact that I am running on a fairly high traffic network, so the
machine is seeing a lot more packets. You should be able to reproduce
the problem by reducing the value of max_interrupt_work.

I could continue working on this problem to track it to root cause, but at
this point I would have to spend more time learning the driver and the
tulip hardware.  Perhaps someone with more experience with this driver
could find the problem with less effort.

I haven't tried this on another machine like an A-180 to determine if
the problem is only on iosapic based machines or if the problem is
general to all tulip based lan interfaces.

John Marvin
jsm@fc.hp.com

             reply	other threads:[~2000-02-23 17:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-23 16:25 John Marvin [this message]
2000-02-23 18:22 ` [parisc-linux] Tulip Driver Bug Grant Grundler

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=200002231625.JAA27870@udlkern.fc.hp.com \
    --to=jsm@udlkern.fc.hp.com \
    --cc=parisc-linux@thepuffingroup.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.