Re: PYXIS bug detection

From: Kurt Garloff (garloff@suse.de)
Date: Thu Dec 13 2001 - 16:22:03 EST


Hi Jay, Ivan,

On Thu, Dec 13, 2001 at 02:59:11PM -0500, Jay Estabrook wrote:
> On Thu, Dec 13, 2001 at 10:51:29PM +0300, Ivan Kokshaysky wrote:
> > BTW, yet another idea: since the bug affects only scatter/gather DMA, what
> > if we'll disable sg windows completely on affected machines? ;-)
> > It would be generic fix, not only for bus mastering IDE.

Is it really a fix?

> That's what was done here for NT on MIATAs, IIRC; no S/G.

And how do you handle large requests then? You can't expect to find large
blocks of physically contigous memory to do I/O with Linux.

So disabling S/G makes the performance suck. (For IDE it might still be
acceptable. For SCSI, things would already hurt more.)

Or did I misunderstand your question and you just do S/G in a different way?
Just the pyxis not doing s/g when it can access the whole memory anyway?

> Does our Linux pci_iommu code failover to use direct correctly in all
> the cases, ie not only map_single but (epecially) map_sg? Actually,
> it's really only the latter that is necessary to check, as map_single
> will always use direct when possible, and it should always be possible
> on MIATA (because it can't have more than 2GB of memory).

My docs say it should be possible to have 6GB. Don't know if that's actually
true.

I don't know about the pci_iommu failover things :-(

The way the IDE chips wants to work is to get a pointer to a list with PRD
segments containing the bus addresses and length of the segments to transfer.

If your suggestion just changes the way those bus addresses are calculated
and imaged via the pyxis, it should be fine.

Regards,

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


- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html



This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:33 EST