From: Beezly <beezly@beezly.org.uk>
To: Beezly <beezly@beezly.org.uk>
Cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: Sun GEM card looses TX on x86 32bit PCI
Date: 11 Mar 2002 21:23:34 +0000 [thread overview]
Message-ID: <1015881814.4315.12.camel@monkey> (raw)
In-Reply-To: <1015881102.4312.10.camel@monkey>
In-Reply-To: <1015849164.2153.3.camel@monkey> <20020311.042124.103955441.davem@redhat.com> <1015871701.2832.1.camel@monkey> <20020311.110236.133275094.davem@redhat.com> <1015881102.4312.10.camel@monkey>
[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]
David,
I've been looking some more at what my changes did.... it might be best
to completely ignore them ;) I had no clue what I was doing!
Cheers,
Beezly
On Mon, 2002-03-11 at 21:11, Beezly wrote:
> Hi David,
>
> It seems I fubar'd. I recompiled the module and run it through the test
> again... no hang. It looks like I forgot to copy the new module into my
> /lib/modules/<blah>. Apologies for messing up there.
>
> Anyway... the new driver still drops packets after the initial RX
> overflow, so I had a poke around with it and I've seen some definate
> improvement by forcing the whole chip to reset when the RX overflows.
>
> My modifications to the driver are evil and I only intend them to be a
> test, but it helps to shed some extra light on what's going on.
>
> When the chip does a full reset I loose a whole load of packets, but I'm
> guessing this is normal :(
>
> Also, I can't remember where I read it, but the Extreme Summit 48 is
> supposed to support *receiving* the xon/xoff Pause stuff (I'm no expert
> in this area, so I could be talking complete twaddle!), no transmit
> capability though.
>
> Here's what I get out of the module when it resets (with my limit=5000
> mod);
>
> eth0: RX buffer overflowed - running rxmac_reset
> eth0: RX MAC resetting
> eth0: RX MAC *ONLY* reset
> eth0: RX MAC reset ok?
> eth0: RX MAC will not disable, resetting whole chip.
> eth0: PCS AutoNEG complete.
> eth0: PCS link is now up.
>
> Without the limit=5000, it appears that the module detects the RX
> section is "un-hung" when it isn't.
>
> Cheers,
>
> Beezly
>
> On Mon, 2002-03-11 at 19:02, David S. Miller wrote:
> > From: Beezly <beezly@beezly.org.uk>
> > Date: 11 Mar 2002 18:35:01 +0000
> >
> > Sorry it took so long for me to get back to you. Sadly it also hung with
> > this patch ;) I was unable to get an oops out of it (machine was
> > completely hosed and in X so I couldn't even note the oops on paper :(
> > ).
> >
> > So rerun the test not under X please?
>
> ----
>
> --- sungem.c Mon Mar 11 20:37:57 2002
> +++ sungem.c.testing Mon Mar 11 20:31:12 2002
> @@ -302,14 +302,23 @@
> u64 desc_dma;
> u32 val;
>
> + printk(KERN_ERR "%s: RX MAC resetting\n", dev->name);
> /* First, reset MAC RX. */
> writel(gp->mac_rx_cfg & ~MAC_RXCFG_ENAB,
> gp->regs + MAC_RXCFG);
> + printk(KERN_ERR "%s: RX MAC *ONLY* reset\n", dev->name);
> +
> for (limit = 0; limit < 5000; limit++) {
> - if (!(readl(gp->regs + MAC_RXCFG) & MAC_RXCFG_ENAB))
> + if (!(readl(gp->regs + MAC_RXCFG) & MAC_RXCFG_ENAB)) {
> + printk(KERN_ERR "%s: RX MAC reset ok?\n", dev->name);
> break;
> + }
> udelay(10);
> }
> +
> + /* RX MAC reset doesn't appear to work so I force a whole reset */
> + limit = 5000;
> +
> if (limit == 5000) {
> printk(KERN_ERR "%s: RX MAC will not disable, resetting whole "
> "chip.\n", dev->name);
> @@ -323,6 +332,9 @@
> break;
> udelay(10);
> }
> +
> + limit=5000;
> +
> if (limit == 5000) {
> printk(KERN_ERR "%s: RX DMA will not disable, resetting whole "
> "chip.\n", dev->name);
> @@ -399,6 +411,8 @@
> if (rxmac_stat & MAC_RXSTAT_OFLW) {
> gp->net_stats.rx_over_errors++;
> gp->net_stats.rx_fifo_errors++;
> + printk(KERN_DEBUG "%s: RX buffer overflowed - running rxmac_reset\n",
> + gp->dev->name);
>
> ret = gem_rxmac_reset(gp);
> }
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2002-03-11 21:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-10 20:36 Sun GEM card looses TX on x86 32bit PCI Beezly
2002-03-11 0:43 ` David S. Miller
2002-03-11 8:19 ` Beezly
2002-03-11 12:19 ` Beezly
2002-03-11 12:21 ` David S. Miller
2002-03-11 18:35 ` Beezly
2002-03-11 19:02 ` David S. Miller
2002-03-11 21:11 ` Beezly
2002-03-11 21:23 ` Beezly [this message]
2002-03-11 22:51 ` Beezly
2002-03-12 17:31 ` David S. Miller
2002-03-12 20:34 ` Beezly
2002-03-12 20:39 ` David S. Miller
2002-03-14 20:43 ` Aaron Sethman
2002-03-14 21:21 ` Aaron Sethman
2002-03-11 1:39 ` David S. Miller
2002-03-11 1:58 ` David S. Miller
2002-03-11 8:29 ` Beezly
2002-03-11 8:42 ` David S. Miller
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=1015881814.4315.12.camel@monkey \
--to=beezly@beezly.org.uk \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/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.