Originally Posted by zander
OK, thanks. If the problem does not reproduce without vesafb, then it is an interaction problem between the two drivers, aggravated by a kernel check that's more strict than it needs to be. The only thing the NVIDIA legacy driver could do in this case is to fall back to uncached mappings of BAR1, which would likely yield severe/unacceptable performance penalties in this configuration.
If you need the two drivers to coexist (technically, this is not a configuration we support), you have two options:
- you can push to get vesafb updated to create write-combined mappings via ioremap_wc() on PAT-enabled kernels, rather than via a UC- mapping and a WC MTRR.
- you can modify the kernel to permit the combination of UC- and WC mappings
I'd rather the two drivers coexist: I've gotten used to the boot logo :-). Sorry it took me so long to check back for updates to this thread. Saw the same issue with 96.43.16, and thought I'd see if *anyone* else was seeing the problem. X86_PAT was a nice catch: you get it automatically when MTRRs are enabled unless you're building an embedded kernel, i.e., the *only* way to turn it off is via the kernel command line (nopat).
Perhaps I *am* paying a severe performance penalty by insisting on using the vesafb driver, but even so, the "nvidia" driver is much faster on my system than the "nv" driver. Anyway, my sincere gratitude for figuring out what's going on, AND suggesting multiple workarounds.