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
