Search results

For users having tearing problems when using compositing with Nvidia Kepler and newer based cards: From what I understand, starting with Nvidia's Kepler based GPUs, Nvidia removed the hardware support for tearing/Vsync in the GPU and added additions to control this in the driver instead. For...

Sure, that makes sense. I can add a post to the thread later tonight or tomorrow when I get more time if you'd like or you can edit your post to add the information if you prefer. I'd like to grep through the Nvidia user forums again to find the reference to that statement first before I add the...

Correct, Xserver 1.16 and older were automatically configured by default to listen on TCP port 6000(-listen tcp). This changed in version 1.17 (-nolisten tcp)

Sure. Many people don't mark their threads as solved so the moderators will do so when they run across one that is obviously solved. To edit the thread title and/or mark it solved, click on "Thread Tools" in the upper right of the page while viewing the thread then click on "Edit Thread". In...

Hi. Nvidia removed hardware support for tearing from their GPUs starting with Kepler and replaced it with additions to their driver which unfortunately doesn't work well under FreeBSD or Linux for a lot of people when using compositing. It's a known problem. A workaround is to create a...

Yes, but it's not clear to me if it is a bug in certain Nvidia hardware, the Nvidia driver itself, the FreeBSD console driver or the interaction between them by looking at the PR. The problem has to be found before it can be fixed so I really have no idea how long it will take to fix, sorry...

I haven't seen this until recently myself. Right around the time 10.3-BETA1 was tagged is when I noticed it. It happens on 11-CURRENT as well. Edit: Just adding that there is a recent PR filed against this very issue - 201461

I don't think the Nvidia driver works with console switching from X right now when using vt and the UEFI framebuffer(efifb). IIRC, this should be fixed in later versions of the Nvidia driver that have not, as of yet, been pulled into the ports tree. It's being worked on: 201340. I don't know if...

A better suggestion, noted in tobik's thread he added in his reply above, is to add kld_list+=nvidia to /etc/rc.conf instead by running sysrc kld_list+=nvidia. It's more reliable.

Yep, offer enough good quality work and eventually the developers will tire of constantly approving your work and punish you with a commit bit. Someone has been enjoying a bit of liquid fun I see ;)

PacketMan, I say go for it. It's actual server hardware so IMO should provide a good learning experience even if it is older hardware. I've been considering picking up some older server hardware myself to tinker with.

talsamon, it is technically correct and I really just don't think you understand how a package builder works. Poudriere works the same way in that respect. It's already been explained how this works earlier in this monster thread. If you don't like the way Synth works, you're certainly free to...

The annoying part here is the resulting package will still be installed, registered, then finds and uses the correct library anyway if it exists, which it usually does, causing confusion like this when pkg check is run by a user as above. I wonder how many of the libraries in the ports tree are...

GeorgeG, it looks like from the output you posted above the controller is running in legacy mode as opposed to ahci mode. I do very vaguely remember there being some posts on the mailing list about the Intel ICH7 controller, or certain versions of, not supporting ahci mode and also having...

That is actually kind of surprising, though you did set the security level after X was already up as opposed to before. I still wouldn't be surprised to see more mysterious oddities headed your way soon enough. :) Lol.

Additionally, make sure your BIOS firmware is updated to the newest version released by Dell for that hardware.

topics-about-unsupported-freebsd-versions.40469

Agreed. This is a bad idea IMHO. Xorg needs access the the I/O subsystem as well as kernel memory on FreeBSD. This is true on Linux IIRC as well, and on FreeBSD, setting kern.securelevel above the default prevents that and will cause various weird errors(one of them noted above by Juha Nurmela)...

I'm not sure WITH_OPENSSL_PORT=yes is an issue. If it is, it's at least not universal as I use it for both 10-STABLE and 11-CURRENT with Synth without problems.

AFAIK, that's expected behavior. You can't set the sysctl kern.securelevel higher than 0 if you want to use x11/xorg.