From: Nigel Kukard <nkukard@lbsd.net>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: webvenza@libero.it, linux-kernel@vger.kernel.org
Subject: Re: [HANG] SIS900 + P4 Hyperthread
Date: Tue, 8 Jun 2004 13:26:04 +0200 [thread overview]
Message-ID: <20040608112604.GY14247@lbsd.net> (raw)
In-Reply-To: <20040605130526.A31872@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 4228 bytes --]
No luck,
Funny thing is there is nothing in dmesg or even /var/log/messages for
a matter of fact, nor does it kick into sysrq console.
if i ping flood to a ip local on the network from the box giving the
problem, it does not hang.
if i copy something from the box giving the problem onto another pc,
BANG at around 30Mb (varying up to 60Mb) it bombs.
hang is such that nothing can be run, numlock. .. work fine. can't
execute any proggies or anything.
very weird.
I tried the patch to no avail, if i enable debugging the problem does
not occur (so it must be extreme load related).
as I said 2.4.x works fine with hyperthreading, 2.6.x bombs. seeing as
there isn't very much extreme driver change (and seeing as none should
be required) i suspect the problem is deeper.
-Nigel Kukard
On Sat, Jun 05, 2004 at 01:05:26PM +0200, Francois Romieu wrote:
> Nigel Kukard <nkukard@lbsd.net> :
> [...]
> > Any quick fix i can hack?
>
> Instant hack below. I do not expect it to make a difference but it _could_
> make one.
>
> You probably want to increase NUM_RX_DESC in sis900.h as well and see if
> it changes things: at 7.5Mb/s, it takes 3ms of interrupt processing latency
> before the network adapter exhaust the Rx ring (this should appear on the
> output of 'ifconfig' btw). So if anything keeps the irq masked for that long,
> you experience the usually very well tested error/uncommon paths of the
> drivers :o)
>
> NUM_RX_DESC at 64 or 256 should not hurt but I do not know if the datasheet
> limits the number of Rx descriptors. Fiddling with NUM_RX_DESC could change
> the behavior from "computer hangs" to "computer takes noticeably more time
> to hang".
>
> --- sis900.c.orig 2004-06-05 11:47:27.000000000 +0200
> +++ sis900.c 2004-06-05 12:43:48.000000000 +0200
> @@ -1626,7 +1626,7 @@ static int sis900_rx(struct net_device *
> "status:0x%8.8x\n",
> sis_priv->cur_rx, sis_priv->dirty_rx, rx_status);
>
> - while (rx_status & OWN) {
> + while (rx_status & OWN & sis_priv->rx_skbuff[entry]) {
> unsigned int rx_size;
>
> rx_size = (rx_status & DSIZE) - CRC_SIZE;
> @@ -1651,16 +1651,6 @@ static int sis900_rx(struct net_device *
> } else {
> struct sk_buff * skb;
>
> - /* This situation should never happen, but due to
> - some unknow bugs, it is possible that
> - we are working on NULL sk_buff :-( */
> - if (sis_priv->rx_skbuff[entry] == NULL) {
> - printk(KERN_INFO "%s: NULL pointer "
> - "encountered in Rx ring, skipping\n",
> - net_dev->name);
> - break;
> - }
> -
> pci_unmap_single(sis_priv->pci_dev,
> sis_priv->rx_ring[entry].bufptr, RX_BUF_SIZE,
> PCI_DMA_FROMDEVICE);
> @@ -1688,18 +1678,21 @@ static int sis900_rx(struct net_device *
> "deferring packet.\n",
> net_dev->name);
> sis_priv->rx_skbuff[entry] = NULL;
> - /* reset buffer descriptor state */
> - sis_priv->rx_ring[entry].cmdsts = 0;
> + /*
> + * reset buffer descriptor state and keep it
> + * under host control
> + */
> + sis_priv->rx_ring[entry].cmdsts = OWN;
> sis_priv->rx_ring[entry].bufptr = 0;
> - sis_priv->stats.rx_dropped++;
> - break;
> + continue;
> }
> skb->dev = net_dev;
> sis_priv->rx_skbuff[entry] = skb;
> - sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE;
> sis_priv->rx_ring[entry].bufptr =
> pci_map_single(sis_priv->pci_dev, skb->tail,
> RX_BUF_SIZE, PCI_DMA_FROMDEVICE);
> + wmb();
> + sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE;
> sis_priv->dirty_rx++;
> }
> sis_priv->cur_rx++;
> @@ -1728,10 +1721,11 @@ static int sis900_rx(struct net_device *
> }
> skb->dev = net_dev;
> sis_priv->rx_skbuff[entry] = skb;
> - sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE;
> sis_priv->rx_ring[entry].bufptr =
> pci_map_single(sis_priv->pci_dev, skb->tail,
> RX_BUF_SIZE, PCI_DMA_FROMDEVICE);
> + wmb();
> + sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE;
> }
> }
> /* re-enable the potentially idle receive state matchine */
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-06-08 11:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-04 21:02 [HANG] SIS900 + P4 Hyperthread Nigel Kukard
2004-06-04 21:47 ` Daniele Venzano
2004-06-04 22:50 ` Francois Romieu
2004-06-05 7:02 ` Nigel Kukard
2004-06-05 11:05 ` Francois Romieu
2004-06-05 12:13 ` Nigel Kukard
2004-06-08 11:26 ` Nigel Kukard [this message]
2004-06-14 18:27 ` Nigel Kukard
2004-06-14 18:39 ` Francois Romieu
2004-06-15 7:10 ` Nigel Kukard
2004-06-25 14:54 ` Nigel Kukard
2004-06-26 1:01 ` Herbert Xu
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=20040608112604.GY14247@lbsd.net \
--to=nkukard@lbsd.net \
--cc=linux-kernel@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
--cc=webvenza@libero.it \
/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