for (i = 0; i < n; ++i)
ptes[p+i] = ~1UL;
we reserve by setting also all the bits over 31 to 1. The tsunami specs
says that bits between 32 and 63 _must_ be zero, so the above is
definitely buggy. Maybe this has relactions with the fact the crashes
triggered on >=4G machines.
I will change it to:
for (i = 0; i < n; ++i)
ptes[p+i] = 0x2;
which is just obviously correct for our internal management of the
allocation in the critical sections and that is a definitely necessary
fix according to the specs. Maybe this is the right(tm) fix and then I
can drop the artificial alignment and the tsunami will go to re-fetch
the pte on memory automatically when we do the I/O through an invalid
pte then. If tsunami gets fixed by it I can bet then we can drop the
align_entry field from the pci_iommu_arena structure all together and
what was referred as hardware bug for the other platforms would be
infact a software bug in the iommu code.
I am optimistic this is the definitive fix so I will left out the
so far absolutely necessary artifical alignment on the tsunami for now
and I will put in this critical fix for now (until I get the confirm),
and if it works I will drop the align_entry field all together from the
pci_iommu_arena structure.
Ivan could you test the above fix on the platforms that needs the
align_entry hack?
Andrea
-
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/