On 13 Aug 2003, John Dennis wrote:

> On Tue, 2003-08-12 at 09:49, Egbert Eich wrote:
> > Mark Vojkovich writes:
> >  >    NVIDIA root caused this at one point and came to the conclusion
> >  > that Linux kernel was incorrectly mapping the memory as cached.
> >  > Experiments with setting bit{63} of Base Register fixed the
> >  > problem. 
> >  > 
> > 
> > OK, this sounds like a very reasonable explanation.
> 
> Hmm... It's an interesting observation but I'm a little dubious
> because while it may have been true in the past that the Linux
> kernel may have failed to map memory as uncached I don't believe
> this is true any longer. This assertion has been raised in past with
> other ia64 driver bugs and because I'm fortunate enough to sit next to
> 2 ia64 kernel developers we were able to examine the low level kernel
> memory mappings when XFree86 was running and we verified that the MMIO
> space was indeed mapped as non-cached. One caveat though, the ia64 kernel
> code has been reworked since that exercise so its possible there may
> have been a regression. It would be good to verify there has been no
> regression, but the kernel engineer who helped is out of the office for
> a few days so I'm going to have to wait, but I will post a follow-up.

  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.

                Mark.



> 
> What did seem to work was to call outb twice rather than once hence 
> doubling the delay.
> 
> What we were seeing here was that the nv driver on HP ZX2000's needed
> the outb Egbert added before entering the SlowBCopy loop. But HP ZX6000's
> continued to fault. Doubling the outb's seemed to make the ZX6000's 
> happy. I'm not comfortable with the solution because it feels like
> guessing, but it seems to work and I guess that's the bottom line.
> 
> John
> 
> P.S. this is how the code now looks:
> 
> void
> xf86SlowBcopy(unsigned char *src, unsigned char *dst, int len)
> {
> #if defined(__ia64__)
>     outb(0x80, 0x00);
>     outb(0x80, 0x00);
> #endif
>     while(len--)
>     {
>       *dst++ = *src++;
> #if !defined(__sparc__) && !defined(__powerpc__) && !defined(__mips__)
> #if defined(__ia64__)
>       outb(0x80, 0x00);
> #endif
>       outb(0x80, 0x00);
> #endif
>     }
> }
> 
> 
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
> 

_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to