From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] I/O MCA recovery
Date: Tue, 04 May 2004 23:17:30 +0000 [thread overview]
Message-ID: <200405041617.30080.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <200405040954.09524.jbarnes@engr.sgi.com>
On Tuesday, May 4, 2004 4:11 pm, Grant Grundler wrote:
> On Tue, May 04, 2004 at 03:36:13PM -0700, Jesse Barnes wrote:
> > Are you describing ia64 as a broken platform here? The problem I'm
> > trying to solve isn't sn2 specific (though part of the X stuff I have to
> > do will be driven by sn2 requirements), it's a generic way to deal with
> > hard fails on PIO reads, which afaik, affects all ia64 platforms.
> > Correct me if I'm wrong here...
>
> hardfail vs softfail is a chipset, not arch issue.
> Intel IA32/IA64 chipsets will softfail on MMIO reads and IO port
> access that master abort (timeout).
That's nice (that's why I wanted a pointer to a spec--I can hand it to our hw
guys who have been asking for it).
> HP chipsets (ZX1/SX1000) will hardfail - it's one of the differences
> I point out in the "Porting drivers to ZX1" OLS2002 paper I wrote.
> Sounds like SGI chipsets behave the same way.
Yep.
> ISTR only config space accesses are always required to softfail
> on master aborts. I don't recall if IO Port space is required to as
> well and it looks like this issue is outside the scope of PCI spec.
Alex says that zx1 can soft fail on IO port accesses if configured to do so.
We don't have that option.
And of course, the more general case of MMIO accesses by user level drivers
remains...
Thanks,
Jesse
next prev parent reply other threads:[~2004-05-04 23:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-04 16:54 [RFC] I/O MCA recovery Jesse Barnes
2004-05-04 17:14 ` Grant Grundler
2004-05-04 17:27 ` Jesse Barnes
2004-05-04 17:43 ` David Mosberger
2004-05-04 17:51 ` Grant Grundler
2004-05-04 18:04 ` Jesse Barnes
2004-05-04 18:07 ` Jesse Barnes
2004-05-04 18:20 ` David Mosberger
2004-05-04 22:36 ` Jesse Barnes
2004-05-04 22:50 ` Chris Wedgwood
2004-05-04 22:51 ` David Mosberger
2004-05-04 22:58 ` Jesse Barnes
2004-05-04 23:11 ` Grant Grundler
2004-05-04 23:13 ` David Mosberger
2004-05-04 23:15 ` David Mosberger
2004-05-04 23:17 ` Jesse Barnes [this message]
2004-05-04 23:18 ` Grant Grundler
2004-05-04 23:23 ` Alex Williamson
2004-05-04 23:31 ` Grant Grundler
2004-05-04 23:31 ` David Mosberger
2004-05-04 23:36 ` Grant Grundler
2004-05-12 19:03 ` Jesse Barnes
2004-05-12 21:11 ` David Mosberger
2004-05-12 21:24 ` Jesse Barnes
2004-05-12 21:35 ` David Mosberger
2004-05-12 21:44 ` Jesse Barnes
2004-05-12 21:52 ` Jesse Barnes
2004-05-12 21:54 ` David Mosberger
2004-05-12 21:59 ` Jesse Barnes
2004-05-13 9:02 ` Luck, Tony
2004-05-13 15:52 ` Jesse Barnes
2004-05-13 16:07 ` Luck, Tony
2004-05-13 16:43 ` Russ Anderson
2004-05-13 16:53 ` Jesse Barnes
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=200405041617.30080.jbarnes@engr.sgi.com \
--to=jbarnes@engr.sgi.com \
--cc=linux-ia64@vger.kernel.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