linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Moore, Eric" <Eric.Moore@lsi.com>
Cc: "Prakash, Sathya" <Sathya.Prakash@lsi.com>,
	"Desai, Kashyap" <Kashyap.Desai@lsi.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Matthew Wilcox <matthew@wil.cx>, Milton Miller <miltonm@bga.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	"paulus@samba.org" <paulus@samba.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: RE: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
Date: Thu, 19 May 2011 07:30:18 +1000	[thread overview]
Message-ID: <1305754218.7481.0.camel@pasglop> (raw)
In-Reply-To: <4565AEA676113A449269C2F3A549520F80B66280@cosmail03.lsi.com>

On Wed, 2011-05-18 at 09:35 -0600, Moore, Eric wrote:
> I worked the original defect a couple months ago, and Kashyap is now
> getting around to posting my patch's.
> 
> This original defect has nothing to do with PPC64.  The original
> problem was only on x86.    It only became a problem on PPC64 when I
> tried to fix the original x86 issue by copying the writeq code from
> the linux headers, then it broke PPC64.   I doubt that broken patch
> was ever posted. Anyways, back to the original defect.  The reason it
> because a problem for x86 is because the kernel headers had a
> implementation of writeq in the arch/x86 headers, which means our
> internal implementation of writeq is not being used.  The writeq
> implementation in the kernel is total wrong for arch/x86 because it
> doesn't not have spin locks, and if two processor simultaneously doing
> two separate 32bit pci writes, then what is received by controller
> firmware is out of order.   This change occurs between Red Hat RHEL5
> and RHEL6.  In RHEL5, this writeq was not implemented in arch/x86
> headers, and our driver internal implementation of write was used.

You may also want to look at Milton's comments, it looks like the way
you do init_completion followed immediately by wait_completion is racy.

You should init the completion before you do the IO that will eventually
trigger complete() to be called.

Cheers,
Ben.

  parent reply	other threads:[~2011-05-18 21:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110504115324.GE17855@lsi.com>
     [not found] ` <1305616571.6008.23.camel@mulgrave.site>
     [not found]   ` <B2FD678A64EAAD45B089B123FDFC3ED70157F7BCE5@inbmail01.lsi.com>
2011-05-18  4:15     ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Matthew Wilcox
2011-05-18  4:23       ` James Bottomley
2011-05-18  7:00         ` Benjamin Herrenschmidt
2011-05-18  8:23           ` Milton Miller
2011-05-18 15:35             ` Moore, Eric
2011-05-18 18:31               ` Milton Miller
2011-05-18 19:11                 ` Moore, Eric
2011-05-19  4:08                   ` Hitoshi Mitake
2011-05-19  4:46                     ` James Bottomley
2011-05-19  5:36                       ` Benjamin Herrenschmidt
2011-05-19  8:35                       ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic David Laight
2011-05-19  4:16                 ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Roland Dreier
2011-05-19  5:34                   ` Benjamin Herrenschmidt
2011-05-19 18:15                     ` Ingo Molnar
2011-05-18 21:30               ` Benjamin Herrenschmidt [this message]
2011-05-18 22:05                 ` Moore, Eric
2011-05-18  8:04         ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic David Laight
2011-05-18  5:45       ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Benjamin Herrenschmidt

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=1305754218.7481.0.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=Eric.Moore@lsi.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Kashyap.Desai@lsi.com \
    --cc=Sathya.Prakash@lsi.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthew@wil.cx \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.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 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).