MTRR failure revisited (nVidia) 8-STABLE/RELEASE

[Chris H]

On Sat, December 12, 2009 6:36 am, Robert Noland wrote:
> On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote:
>
>> Greetings,
>> I brought this same error to the list back in May 2009.
>> Under: failed to set mtrr: invalid argument.
>> Well, I'm back using the same card:
>> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0.
>> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a
>> custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's "dog
>> slow"
UPDATE:
Disabling HAL /greatly/ increased performance
eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf
More specifically, response times are now closer to what one would anticipate/
expect now that HAL has been dis-abled in rc.conf.
>> , and the nvidia driver emits the following error: NVIDIA: failed to set
>> MTRR 0xf0000000, 0M (write-combining)
>> several times. I understand John Baldwin provided some "invaluable" help some
>> time ago:
>> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
>> and I was wondering if anyone has gained any further "insight" with these
>> cards, and how to better "interface" them in BSD. Last I spoke on the topic, I
>> was informed that the memory was basically "untouchable" - or perhaps in other
>> words; can't be manipulated. Has this changed? Surely someone else has had to
>> deal with this besides me. It seems crazy to spend a "boat load" of $$ on
>> these high performers, and not be able to use them on a high performing OS -
>> no? :) Sure, the one I'm working with now is "legacy". But I have 3 near new,
>> top of their line cards, and thus far it appears that if I ever hope to use
>> them, I'll be forced to... hack, choke.. spin up a WIN CD. :(
>>
>> Thank you for all your time, consideration, and insight.
>>
Greetings Robert, and thank you for taking the time to respond.
>
> The mtrr issue has to do with the system / bios, not the graphics card.
> While I've not used the blob driver, the issue in Nouveau and other drm
> drivers is that on many systems if you run "memcontrol list", you will see a line
> something like this:
>
> 0x0/0x100000000 BIOS write-back set-by-firmware active
I see the following (condensed for brevity):
0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active
0x10000/0x10000-0x70000/0x10000 BIOS write-back fixed-base fixed-length
set-by-firmware active
0x80000/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base fixed-length
set-by-firmware active
0xa0000/0x4000-0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length
set-by-firmware active
0xc0000/0x10000xc7000/0x1000 BIOS write-protect fixed-base fixed-length
set-by-firmware active
0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable fixed-base fixed-length
set-by-firmware active
0x0/0x40000000 BIOS write-back set-by-firmware active
0xe0000000/0x20000000 BIOS uncacheable set-by-firmware active

While I could pull the BIOS out of it's socket after POST. I don't suppose
I could read it's contents to file, and then allow manipulation of the
regions currently "off limits"?
>
>
> This says that all of memory defaults to write-back.  We aren't allowed
> to overlap write-combined on top of write-back, so the setting of mtrr fails.
Isn't it /best/ to choose write-back, so as to mark the memory dirty? I /could/
choose write-ahead, or write-through.
> I've looked at ways to try to fix this in the past, but
> generally found it more practical to use PAT than try to override/fix bios
> behavior.
Marius Nünnerich also mentioned this in a response to this thread. Would you be
willing to share any additional information, based on your experiences using PAT?
>
> I've been told that linux does apply some BIOS fixups to address this
> issue, which I might look into again, but I make no promises.
Is there anything I could do that would help you in this regard?
There are also a
> very limited number of variable mtrr registers (7 on most hardware, iirc) for
> managing caching.

Thank you again for taking the time to respond.

--Chris H
>
> robert.
>
>> --Chris H
>>
>>
>>
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>>
> --
> Robert Noland <rnoland at FreeBSD.org>
> FreeBSD
>
>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
>