On Wed, 2003-08-13 at 15:40, Mark Vojkovich wrote: > I spoke with David Mosberger about it before. He was dubious > as well, perhaps to the point that he didn't take it seriously. > Never-the-less, an NVIDIA engineer who's opinion I value came to > the conclusion that what Linux kernel was doing wasn't in line > with what the IA64 specifications described. Hacking things to > bring them in line made the problems go away. All this outb > business is just trying to put a bandaid on the real problem, > which I still believe is due to Linux kernel misprogramming > the caching.
I agree with you, there have been a number of ia64 "fixes" that never felt right to me, for which I could not find technical justification. The outb delays is one example, so was the desire to introduce memory barriers (memory fences) in various places (in particular in the nv driver). FWIW, I did find useful information in the following paper that explained the necessity in some circumstances of adding no-op reads before writes because of PCI transaction order rules, PCI posting (queuing PCI transactions for bursting), and the timing issues when there are multiple PCI bridges between the host and the card as is the case with the HP ZX designs. Porting Drivers to HP ZX1 - Grant Grundler http://h21007.www2.hp.com/dspp/files/unprotected/portinghpzx1.pdf These are issues that go beyond cached vs. uncached memory but can cause symptoms that are similar. Some of the issues may be due to PCI bridges, but I personally do not feel I understand PCI bridge issues well enough to make assertions. (For example bridges have complex rules on queuing transactions, delays, retrys, etc. If a bridge transaction timeouts, as I think is the case with VGA data which seems to be slower, then a bridge is susposed to return all ones which is what I was seeing, but I think this is only for PCI configuration cycles, not regular memory cycles, and here is a good example of where my understanding starts to break down :-( I am keen to see the right technical fixes get made to XFree86 for ia64 rather than guessing. Since you speak highly of your co-worker and he seems to understand a fundamental problem with ia64 I would appreciate being put into contact with him. You may either email me privately or give him my email. Since we do a fair amount of ia64 kernel work here in this office I will be an advocate for seeing his concerns are looked at and addressed. -- John Dennis <[EMAIL PROTECTED]> _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
