96.43.14: nvidia_drv.so segfaults

[hmrct]

Problem is per the subject of this posting. The segfault occurs shortly after the GART is initialized.

nvidia-bug-report.log.gz attached: the included Xorg.0.log was generated with "-logverbose 9".

Kernel is 2.6.33.
Xorg server is 1.6.3 dated 2009-7-31 (latest version for Slackware 13.0).
Motherboard is a Tyan S1590S (Trinity 100 AT) with a K6-III/450.

There's a question in my mind as to whether MTRRs are working correctly on my K6-III/450: the kernel folks periodically break things for older CPUs for lack of a test platform :-(.

HELP!! I haven't had a working "nvidia" X11 driver for nearly a year now, and while the "nv" driver is getting better, it's nowhere near as efficient as the proprietary driver (when that's working correctly) on my system.

[cosoleto]

Same problem but using latest nvidia driver (.16) on a K7. it works only if X86_PAT isn't enabled ('nopat' is the boot parameter for the kernel).

X:7985 conflicting memory types d8000000-d8214000 uncached-minus<->write-combining
reserve_memtype failed 0xd8000000-0xd8214000, track uncached-minus, req write-combining
X:7985 conflicting memory types d8000000-d8214000 uncached-minus<->write-combining
reserve_memtype failed 0xd8000000-0xd8214000, track uncached-minus, req write-combining

[zander]

@cosoleto: can you generate/attach an nvidia-bug-report.log file? I was unable to reproduce this problem when I tried before - the more data I can from failing systems, the better.

[zander]

@hmrct: does this problem reproduce if you disable vesafb in favor of a standard VGA console?

(...)
vesafb: framebuffer at 0xd0000000, mapped to 0xd8900000, using 3072k, total 65536k
vesafb: mode is 1024x768x16, linelength=2048, pages=0
vesafb: protected mode interface info at c000:c4a0
vesafb: pmi: set display start = c00cc4e5, set palette = c00cc56a
vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03
d003 d103 d203 d303 d403 d503 da03 ff03
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
(...)
X:3252 conflicting memory types d0000000-d0570000 uncached-minus<->write-combining
reserve_memtype failed 0xd0000000-0xd0570000, track uncached-minus, req uncached-minus
X:3252 conflicting memory types d0000000-d0570000 uncached-minus<->write-combining
reserve_memtype failed 0xd0000000-0xd0570000, track uncached-minus, req uncached-minus
(...)

[cosoleto]

File attached.

[zander]

@cosoleto: thanks; can you also perform the vesafb experiment (boot with the vga=normal video=vesa:off kernel command line arguments)?

[zander]

@cosoleto: also, can you please download the attached patch and perform the following experiment:

# sh /path/to/NVIDIA-Linux-x86-96.43.16-pkg0.run \
--apply-patch /path/to/NVIDIA_kernel-96.43.16-572428.diff
# sh ./NVIDIA-Linux-x86-96.43.16-pkg0-custom.run
# dmesg -c
# startx

Then please generate/attach another nvidia-bug-report.log file.

[cosoleto]

Originally Posted by zander

@cosoleto: thanks; can you also perform the vesafb experiment (boot with the vga=normal video=vesa:off kernel command line arguments)?

No crash using these kernel command line arguments.

Originally Posted by zander

@cosoleto: also, can you please download the attached patch and perform the following experiment:

# sh /path/to/NVIDIA-Linux-x86-96.43.16-pkg0.run \
--apply-patch /path/to/NVIDIA_kernel-96.43.16-572428.diff
# sh ./NVIDIA-Linux-x86-96.43.16-pkg0-custom.run
# dmesg -c
# startx

Then please generate/attach another nvidia-bug-report.log file.

Attached.

[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

[hmrct]

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.