Robert Hancock wrote:
>> 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.
>
Ah, I see. Thanks for that introduction :-)
>> 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.
>
>
>> 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.
>
Ok,.. that sounds reasonable,.. so the whole thing might (!) actually be
a hardware design error,... but we just don't use that hardware any
longer when accessing devices via sata_nv.
So this doesn't solve our problem with PATA drives or other devices
(although we had until now no reports of errors with other devices) and
we have to stick with iommu=soft.
If one use iommu=soft the sata_nv will continue to use the new code for
the ADMA, right?
Best wishes,
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[email protected]
x-mozilla-html:TRUE
version:2.1
end:vcard
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
