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", 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. --Chris H
On Sat, Dec 12, 2009 at 12:47, Chris H <chris#@1command.com> 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", 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.FreeBSD as of 8.0-RELEASE supports PAT which obsoletes MTRR. It was a requirement for the nvidia amd64 blob. So in the future it should all work fine if you have at least a card which is supported by the newest nvidia driver.
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", 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.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 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. 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. 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. There are also a very limited number of variable mtrr registers (7 on most hardware, iirc) for managing caching. robert.> --Chris H > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-- Robert Noland <rnoland@FreeBSD.org> FreeBSD