All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Jeremy Higdon <jeremy@sgi.com>
Cc: Michael Reed <mdr@sgi.com>,
	pazke@donpac.ru, Michael Joosten <michael.joosten@c-lab.de>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH]: Re: qla1280.c broken on SGI visws, PCI coherency problem
Date: Tue, 13 Dec 2005 20:59:37 -0800	[thread overview]
Message-ID: <1134536377.3133.13.camel@mulgrave> (raw)
In-Reply-To: <20051214012856.GA185272@sgi.com>

On Tue, 2005-12-13 at 17:28 -0800, Jeremy Higdon wrote:
> On Mon, Dec 12, 2005 at 03:47:37PM -0600, James Bottomley wrote:
> > Well, the idea was that mmiowb and posting flushes were orthogonal.
> > mmiowb would be used in places where a posted write flush was done but
> > was strictly unnnecessary.  This bug report is implying that the posted
> > write flush was necessary, so it was incorrectly replaced with mmiowb
> > (which is a nop on most platforms).
> 
> No, I don't think it was necessary here.  Though if a platform does
> write posting yet has a null mmiowb() implementation, it will have
> trouble.

Now you're worrying me: Every platform other than Altix does have a null
mmiowb() implementation and, obviously, PCI posting flush requirements
are within the province of the bridge rather than the platform (high end
servers being the ones that have posting bridges).  If mmiowb() is
meant to take the place of write posting flushes then we're in deep
do-do.

The only thing I thought mmiowb() was supposed to be used for is the
case where the platform implements relaxed ordering and we want to
enforce strong ordering on the PCI bus write transactions, but don't
actually care when the write actually completes.

> > > I agree that replacing the pio read which flushed the preceeding
> > > pio write with mmiowb() is what has likely broken the driver.  If you
> > > restore them,  please make it either mmiowb or pio read, but not both.
> > > 
> > > Perhaps something like this?  It's not the most elegant solution....
> > 
> > I'm tempted to say I think we need to put the write posting flush back
> > in and dump the mmiowb(), but since the driver is supposedly doing PIO
> > for VISWS, there's something else going on here (PIO writes aren't
> > supposed to post).  I've cc'd the VISWS maintainer in case he can think
> > of anything.
> 
> Yes, the posting of PIO writes is the real problem with the VISWS.
> Early ports of Linux for Altix had the same problem.
> The current Altix outw looks like this:
> 
> static inline void
> ___sn_outw (unsigned short val, unsigned long port)                                         
> {
>         volatile unsigned short *addr;
> 
>         if ((addr = sn_io_addr(port))) {
>                 *addr = val;
>                 __sn_mmiowb();
>         }
> }
> 
> 
> There ought to be a similar facility in the VISWS, though finding
> anyone who knows about it might be difficult (the last one was built
> in 1999).
> 
> It sounds as though the VISWS should also implement the mmiowb(),
> since it apparently needs it for write ordering.  Of course, you
> can always do a readX for that, but that's quite a bit heavier weight
> than necessary.

My primary concern in all of this is that the write posting flush was
incorrectly removed.  In this case, a UP VISWS should still show the
error (now we've established that it's posting even in the PIO case).
If it doesn't, I'll be happy with a VISWS specific fix.

James



  reply	other threads:[~2005-12-14  7:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-09 19:11 qla1280.c broken on SGI visws, PCI coherency problem Michael Joosten
2005-12-09 23:48 ` Michael Reed
2005-12-12 21:00   ` [PATCH]: " Michael Reed
2005-12-12 21:24     ` Christoph Hellwig
2005-12-12 21:31       ` Jesse Barnes
2005-12-12 21:47     ` James Bottomley
2005-12-12 23:00       ` Michael Reed
2005-12-13 13:22         ` Michael Reed
2005-12-13 14:50           ` James Bottomley
2005-12-13 18:15             ` Michael Reed
2005-12-14  5:00               ` Michael Joosten
2005-12-14 17:29                 ` James Bottomley
2005-12-15  1:17                   ` Michael Joosten
2005-12-15  2:20                     ` Jeremy Higdon
2005-12-15 16:21                       ` Michael Joosten
2005-12-14  1:39             ` Jeremy Higdon
2005-12-14  3:16               ` Michael Reed
2005-12-14  1:28       ` Jeremy Higdon
2005-12-14  4:59         ` James Bottomley [this message]
2005-12-14 23:56           ` Jeremy Higdon
2005-12-15  0:14             ` Michael Reed
2005-12-15  1:13               ` Jeremy Higdon

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=1134536377.3133.13.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=jeremy@sgi.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdr@sgi.com \
    --cc=michael.joosten@c-lab.de \
    --cc=pazke@donpac.ru \
    /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.