From: Matthew Wilcox <matthew@wil.cx>
To: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
James Bottomley <James.Bottomley@SteelEye.com>,
Jesse Barnes <jbarnes@engr.sgi.com>,
Grant Grundler <grundler@parisc-linux.org>,
pj@sgi.com, SCSI Mailing List <linux-scsi@vger.kernel.org>,
mdr@cthulhu.engr.sgi.com, jeremy@cthulhu.engr.sgi.com,
djh@cthulhu.engr.sgi.com, Andrew Morton <akpm@osdl.org>
Subject: Re: SCSI QLA not working on latest *-mm SN2
Date: Tue, 21 Sep 2004 19:04:58 +0100 [thread overview]
Message-ID: <20040921180458.GF11446@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <B179AE41C1147041AA1121F44614F0B0DD04DD@AVEXCH02.qlogic.org>
On Tue, Sep 21, 2004 at 10:33:36AM -0700, Andrew Vasquez wrote:
> Hmm...adding more confusion to the mix. I apologize -- my reply was
> not written correctly, yes, the config-read will flush any pending
> writes. But, the same problem persists -- the RISC will still stop
> responding to requests (config or MMIO) during the soft-reset --
> potentially resulting in a MAC (as seen by SGI).
>
> The 'safe' solution (as suggested by the hw people) was to use PIO to
> issue the soft-reset, then udelay().
Even that's not safe ;-(
This snippet is from pci 2.3 (section 3.2.5.2) but there's substantially
similar wording in pci 2.2:
Host bus bridges are permitted to post I/O write transactions that
originate on the host bus and complete on a PCI bus segment when they
follow the ordering rules described in this specification and do not
cause a deadlock. This means that when a host bus bridge posts an I/O
write transaction that originated on the host bus, it must provide a
deadlock free environment when the transaction completes on PCI. The
transaction will complete on the destination PCI bus before completing
on the originating PCI bus.
Since memory write transactions may be posted in bridges anywhere
in the system, and I/O writes may be posted in the host bus bridge,
a master cannot automatically tell when its write transaction completes
at the final destination. For a device driver to guarantee that a write
has completed at the actual target (and not at an intermediate bridge),
it must complete a read to the same device that the write targeted. The
read (memory or I/O) forces all bridges between the originating master
and the actual target to flush all posted data before allowing the
read to complete. For additional details on device drivers, refer to
Section 6.5. Refer to Section 3.10., item 6, for other cases where a
read is necessary.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
next prev parent reply other threads:[~2004-09-21 18:05 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-21 17:33 SCSI QLA not working on latest *-mm SN2 Andrew Vasquez
2004-09-21 17:52 ` Jesse Barnes
2004-09-21 18:04 ` Matthew Wilcox [this message]
2004-09-21 18:59 ` Matthew Wilcox
2004-09-21 19:10 ` Jesse Barnes
-- strict thread matches above, loose matches on Subject: below --
2004-09-21 21:22 Andrew Vasquez
2004-09-21 21:44 ` Jeremy Higdon
2004-09-21 22:37 ` Jesse Barnes
2004-09-21 22:49 ` Jeremy Higdon
2004-09-21 20:50 Andrew Vasquez
2004-09-21 21:06 ` Jeremy Higdon
2004-09-21 22:36 ` Jesse Barnes
2004-09-21 22:39 ` Jeremy Higdon
2004-09-21 22:43 ` Jesse Barnes
2004-09-21 22:54 ` Jeremy Higdon
2004-09-21 23:17 ` Jesse Barnes
2004-09-22 21:33 ` Jesse Barnes
2004-09-21 15:58 Andrew Vasquez
2004-09-21 16:07 ` Jesse Barnes
2004-09-21 16:25 ` Matthew Wilcox
2004-09-21 16:33 ` James Bottomley
2004-09-21 20:39 ` Jeremy Higdon
2004-09-21 20:43 ` Jeremy Higdon
2004-09-17 22:55 Andrew Vasquez
2004-09-17 23:10 ` Jesse Barnes
2004-09-17 23:55 ` James Bottomley
2004-09-18 1:15 ` Andrew Vasquez
2004-09-18 1:25 ` Matthew Wilcox
2004-09-18 1:24 ` Andrew Vasquez
2004-09-18 2:36 ` Jeremy Higdon
2004-09-18 19:12 ` James Bottomley
[not found] <B179AE41C1147041AA1121F44614F0B060EF48@AVEXCH02.qlogic.org>
[not found] ` <20040916121235.5e4f9c32.pj@sgi.com>
[not found] ` <1095362263.16326.12.camel@praka>
2004-09-16 19:56 ` Paul Jackson
2004-09-16 20:05 ` Jesse Barnes
2004-09-16 20:56 ` Andrew Vasquez
2004-09-16 21:09 ` Jesse Barnes
2004-09-16 21:40 ` Andrew Vasquez
2004-09-16 22:25 ` Andrew Morton
2004-09-16 22:29 ` Jesse Barnes
2004-09-17 17:21 ` Jesse Barnes
2004-09-18 6:10 ` Grant Grundler
2004-09-20 22:40 ` Jesse Barnes
2004-09-20 23:27 ` Grant Grundler
2004-09-21 0:09 ` Jesse Barnes
2004-09-21 5:46 ` Grant Grundler
2004-09-21 6:45 ` Jeremy Higdon
2004-09-21 13:29 ` Jesse Barnes
2004-09-21 13:25 ` Jesse Barnes
2004-09-21 15:13 ` Jesse Barnes
2004-09-21 15:41 ` James Bottomley
2004-09-21 15:58 ` Jesse Barnes
2004-09-21 16:01 ` Matthew Wilcox
2004-09-21 16:05 ` Jesse Barnes
2004-09-21 16:11 ` James Bottomley
2004-09-21 16:18 ` Jesse Barnes
2004-09-21 16:24 ` James Bottomley
2004-09-21 17:03 ` Jesse Barnes
2004-09-21 17:15 ` Matthew Wilcox
2004-09-21 17:24 ` Jesse Barnes
2004-09-21 17:20 ` James Bottomley
2004-09-21 17:46 ` Jesse Barnes
2004-09-21 17:56 ` James Bottomley
2004-09-21 18:09 ` Jesse Barnes
2004-09-21 19:06 ` Grant Grundler
2004-09-21 19:40 ` Jesse Barnes
2004-09-21 22:44 ` Grant Grundler
2004-09-21 21:03 ` Jeremy Higdon
2004-09-21 21:11 ` Matthew Wilcox
2004-09-21 21:43 ` Jeremy Higdon
2004-09-21 22:33 ` Jesse Barnes
2004-09-22 0:02 ` Matthew Wilcox
2004-09-22 1:16 ` Jeremy Higdon
2004-09-22 1:44 ` Grant Grundler
2004-09-22 2:58 ` Jeremy Higdon
2004-09-21 23:03 ` Guennadi Liakhovetski
2004-09-16 23:14 ` Jeremy Higdon
2004-09-16 20:11 ` Andrew Morton
2004-09-15 22:51 Paul Jackson
2004-09-15 23:13 ` Andrew Morton
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=20040921180458.GF11446@parcelfarce.linux.theplanet.co.uk \
--to=matthew@wil.cx \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--cc=andrew.vasquez@qlogic.com \
--cc=djh@cthulhu.engr.sgi.com \
--cc=grundler@parisc-linux.org \
--cc=jbarnes@engr.sgi.com \
--cc=jeremy@cthulhu.engr.sgi.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mdr@cthulhu.engr.sgi.com \
--cc=pj@sgi.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 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.