No, the MTRR's turn off store forwarding too.
How do we know? Think about DOS. It doesn't _have_ page tables, it depends
entirely on the MTRR's to do the right thing wrt IO memory.
> the only MTRR stuff we do right now is mmap()-ing the frame buffer via
> /dev/mem, right? In that case we are doing things outside of ioremap()'s
> scope anyway.
Nope. I'm convinced we want to use MTRR's for high-speed networking, for
example. You'll get to test thison gigabit soon enough, but the fastest
way to feed a networking card is to map a large buffer in PCI memory space
and then use the MTRR's to mark it write combining but uncached (whatever
intel calls that combination). That way the core will write combine and
burst PCI writes, which is what you need for top performance.
> actually this is how ioremap_nocache() popped up, i just didnt understand
> this issue at that time. (i hope i do now :). About 2 years ago CISCO
> found out when developing drivers that their driver fails mysteriously on
> PPro boxes. So i sent a small patch to add ioremap_nocache(), but that's
> the wrong solution now i believe.
It could easily be MTRR's set up wrong. Considering how many broken BIOSes
there are out there, that is not that unlikely.
On pre-P6 boxes we had the same kind of mysterious problems with some
XFree86 setups on _some_ motherboards..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/