netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: David Miller <davem@davemloft.net>
Cc: walt@holmansrus.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: Strange network timeouts w/ 2.6.30.5
Date: Thu, 20 Aug 2009 22:28:38 +0200	[thread overview]
Message-ID: <m31vn6jkll.fsf@intrepid.localdomain> (raw)
In-Reply-To: <20090820.122850.37712606.davem@davemloft.net> (David Miller's message of "Thu\, 20 Aug 2009 12\:28\:50 -0700 \(PDT\)")

David Miller <davem@davemloft.net> writes:

> swiotlb emulates what hardware does, so if it can go wrong with
> swiotlb it can go wrong with hardware to.
>
> Figure out what the exact bug is.

I think I already have.

The exact bug is using streaming allocations for the descriptor.
It can't work consistently on all platforms, period. Streaming
allocation can only have one owner (either CPU or device) at a time, and
e100 driver wants access (for examining desc status) simultaneously with
the hardware (which may alter desc status at any time).

On ARM with the previous patch applied it can work because the CPU cache
has the "dirty" bits (e100 driver only reads from the descriptors).
On x86 without swiotlb it can work because streaming allocations are
already coherent.
On x86 with swiotlb it can't really work reliably (and if does, it does
by pure luck) because (I guess) swiotlb has no "dirty" flag and can't
know when it doesn't need to flush.

There is no other fix than to convert the desc rings to coherent
allocs. I'm going to do precisely that in few days, but we're stuck with
the existing code in 2.6.31 (and 2.6.30.x etc).
-- 
Krzysztof Halasa

  reply	other threads:[~2009-08-20 20:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1359163732.51250769223038.JavaMail.root@mail.holmansrus.com>
2009-08-20 11:54 ` Strange network timeouts w/ 2.6.30.5 Walt Holman
2009-08-20 13:45   ` Krzysztof Halasa
2009-08-20 19:28     ` David Miller
2009-08-20 20:28       ` Krzysztof Halasa [this message]
2009-08-20 22:21     ` Walt Holman
2009-08-21  9:44       ` Krzysztof Halasa
2009-08-23 19:18     ` Aviv Greenberg
2009-08-23 20:02       ` Krzysztof Halasa
     [not found] <1489093361.01250869377567.JavaMail.root@mail.holmansrus.com>
2009-08-21 15:45 ` Walt Holman
2009-08-22 20:26   ` Krzysztof Halasa
     [not found] <1762204735.01250727555803.JavaMail.root@mail.holmansrus.com>
     [not found] ` <2087985663.21250727676944.JavaMail.root@mail.holmansrus.com>
2009-08-20  4:17   ` David Miller
2009-08-20  9:03     ` Krzysztof Halasa
2009-08-20  9:13       ` David Miller
2009-08-20  9:22         ` Krzysztof Halasa

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=m31vn6jkll.fsf@intrepid.localdomain \
    --to=khc@pm.waw.pl \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=walt@holmansrus.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).