lkml.org 
[lkml]   [2007]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Christoph Anton Mitterer wrote:
> Sorry, as always I've forgot some things... *g*
>
>
> Robert Hancock wrote:
>
>> If this is related to some problem with using the GART IOMMU with memory
>> hole remapping enabled
> What is that GART thing exactly? Is this the hardware IOMMU? I've always
> thought GART was something graphics card related,.. but if so,.. how
> could this solve our problem (that seems to occur mainly on harddisks)?

The GART built into the Athlon 64/Opteron CPUs is normally used for
remapping graphics memory so that an AGP graphics card can see
physically non-contiguous memory as one contiguous region. However,
Linux can also use it as an IOMMU which allows devices which normally
can't access memory above 4GB to see a mapping of that memory that
resides below 4GB. In pre-2.6.20 kernels both the SATA and PATA
controllers on the nForce 4 chipsets can only access memory below 4GB so
transfers to memory above this mark have to go through the IOMMU. In
2.6.20 this limitation is lifted on the nForce4 SATA controllers.

>
>> then 2.6.20-rc kernels may avoid this problem on
>> nForce4 CK804/MCP04 chipsets as far as transfers to/from the SATA
>> controller are concerned
> Does this mean that PATA is no related? The corruption appears on PATA
> disks to, so why should it only solve the issue at SATA disks? Sounds a
> bit strange to me?

The PATA controller will still be using 32-bit DMA and so may also use
the IOMMU, so this problem would not be avoided.

>
>> as the sata_nv driver now supports 64-bit DMA
>> on these chipsets and so no longer requires the IOMMU.
>>
> Can you explain this a little bit more please? Is this a drawback (like
> a performance decrease)? Like under Windows where they never use the
> hardware iommu but always do it via software?

No, it shouldn't cause any performance loss. In previous kernels the
nForce4 SATA controller was controlled using an interface quite similar
to a PATA controller. In 2.6.20 kernels they use a more efficient
interface that NVidia calls ADMA, which in addition to supporting NCQ
also supports DMA without any 4GB limitations, so it can access all
memory directly without requiring IOMMU assistance.

Note that if this corruption problem is, as has been suggested, related
to memory hole remapping and the IOMMU, then this change only prevents
the SATA controller transfers from experiencing this problem. Transfers
on the PATA controller as well as any other devices with 32-bit DMA
limitations might still have problems. As such this really just avoids
the problem, not fixes it.

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


-
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/

\
 
 \ /
  Last update: 2007-01-16 01:53    [W:0.136 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site