Re: IDE DMA on AXP & barriers

Kurt Garloff (garloff@suse.de)
Fri, 7 Dec 2001 18:02:14 +0100


--gdTfX7fkYsEEjebm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Ivan, Jay,

[stripped the distributor's lists from Cc: again; I just wanted the patch to
reach lots of people that can potentially test.]

On Fri, Dec 07, 2001 at 07:43:47PM +0300, Ivan Kokshaysky wrote:
> On Fri, Dec 07, 2001 at 03:48:15PM +0100, Kurt Garloff wrote:
> > Hey, where did you find that manual? I could not find one at Compaq's w=
eb
> > site.
>=20
> IIRC, few years ago someone posted a link on axp-list, and I picked it up.
> Anyway, I've placed it on
> ftp://ftp.park.msu.ru/ink/docs/21174_SI.pdf

Got it, thanks!

> > How do I recognize the broken PYXIS in software? (Except for waiting for
> > your hard disk to be corrupted?)
>=20
> Put the chip into PCI loopback mode, read some memory (crossing the
> page boundary) via direct PCI window and check for corruption -
> perhaps this will work.

I guess the manual will tell me how to do that ...

> > Or should I just put an #ifdef CONFIG_ALPHA_PYXIS in my patch?
> > What about the users of generic alpha kernels?
>=20
> #ifdef CONFIG_ALPHA_PYXIS won't work for them.

That's why I'm looking for something better ...
But on a generic kernel, we have to do a number of things, then:
* Detect PYXIS
* Set into PCI loopback
* Do the cross 8k DMA read
* Set flag if corruption

(And even this test is not completely perfect, as only devices on the
primary PCI bus seem to be affected.)

> > Or a config option?
>=20
> Maybe...

Runtime detection is better of course. Think of distributors ...

On the other hand, the workaround does not hurt performance as far as I cou=
ld
measure. For reading data from disk (i.e. DMAing to memory), the patch does
not do anything. For writing to disk, I make 16 or 17 PDR segments from 4,
but bonnie would not tell me any difference in performance.
So doing it on every PYXIS would also be an option.=20

> Jay, your opinion? Perhaps you have the info which systems are affected?

=2E.. and how they can be identified.

Thanks,
--=20
Kurt Garloff <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security

--gdTfX7fkYsEEjebm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8EPYWxmLh6hyYd04RAtoVAJ461gZ9IoXaNAajv1MVnmX+UZ0N3gCgoAzR
0RBhL63uip2utHwmjoWTapk=
=Lx4T
-----END PGP SIGNATURE-----

--gdTfX7fkYsEEjebm--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/