similar to: Nouveau support for GeForce GT 730 or GTX 750 Ti?

2016-01-03 19:32 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > On Sun, Jan 3, 2016 at 1:04 PM, Csányi Pál <csanyipal at gmail.com> wrote: >> I want to use nouveau driver in the future too. >> >> So I'm in doubt in that that whether to buy >> GeForce GT730 >> So, does nouveau support these cards? >> >> Should I choose GTX 750 Ti or

On Sun, Jan 3, 2016 at 1:04 PM, Csányi Pál <csanyipal at gmail.com> wrote: > Hi, > > I'm currently use GeForce 7600 GT with nouveau driver. > This is a very old graphic card without OpenGL support. Well, I wouldn't say *without* but... crappy :) The nv30 driver leaves a lot to be desired, and it doesn't handle some fairly common cases in more recent software. >

2016-01-03 20:11 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > On Sun, Jan 3, 2016 at 1:52 PM, Csányi Pál <csanyipal at gmail.com> wrote: >> So there is an AMD card too: >> VGA ASUS AMD Radeon R7 240, R7240-2GD3-L, 2GB DDR3, 128bit, >> 730/1800MHz, HDMI, DVI-D, D-sub >> >> What would be the best choice here: >> GEFORCE GT 730 >> or

Hi, I own an Asus GT730-SL-2GD3-BRK, trying to drive two monitors at 2560x1440 resolution. Using gnome-shell with either Xorg or wayland I get screen freezes very frequently. Those freezes usually require a reboot to get working graphics (below a sample trace that I got yesterday). I am running Ubuntu 17.04 with the latest kernels avalable, I also tested various more recent kernels including

https://bugs.freedesktop.org/show_bug.cgi?id=85100 Bug ID: 85100 Summary: Geforce GT730: X freezes during normal 2d operation. Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau

On 07/05/2017 23:50, Ilia Mirkin wrote: > You have two issues: > > (a) nouveau's GL driver messed something up, causing a read fault error > (b) nouveau's kernel driver tried to recover. It failed. > > Solution to #1: None, really. You can try updating mesa, and hope it > helps. Not sure what version you're on. Here's my packages version: ii

mail_extra_groups=mail setting is often used insecurely to give Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared. If you do use /var/mail mboxes and Dovecot gives permission errors without it, do one of the following (in the preferred order): a) Upgrade to v1.0.11 and use the new mail_privileged_group setting

mail_extra_groups=mail setting is often used insecurely to give Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared. If you do use /var/mail mboxes and Dovecot gives permission errors without it, do one of the following (in the preferred order): a) Upgrade to v1.0.11 and use the new mail_privileged_group setting

Hi, I've two computers, one with Debian the other with Ubuntu. The Debian computer has v1.0.14, the Ubuntu v1.0.11. They do not manage to connect with error "wrong keylength": the Ubuntu computer sends a 512 byte key to the Debian computer which expects a 256 byte key. Is it expected ? Is there a configuration option somewhere that I've set differently on

Hi, I'm using Tinc v1.0.11 on Ubuntu 10.04 and seeing high CPU usage (up to 30%) on what I wouldn't consider high traffic levels. The traffic is application server to database server connections and multicast communication for session-replication on the application server. I'm running the tinc daemons in switch mode, to support the multicast. I have tried settings: TunnelServer =

This affects only blocking passdbs: - MySQL - PAM, passwd and shadow if blocking=yes The underlying bug exists in all v1.0.x versions, but I couldn't figure out a way to exploit it except with v1.0.11, v1.0.12 and v1.1.rc2. Probably a good idea to upgrade in any case. The main problem is that Dovecot's internal protocols use TAB character as a delimiter, but passwords were sent

This affects only blocking passdbs: - MySQL - PAM, passwd and shadow if blocking=yes The underlying bug exists in all v1.0.x versions, but I couldn't figure out a way to exploit it except with v1.0.11, v1.0.12 and v1.1.rc2. Probably a good idea to upgrade in any case. The main problem is that Dovecot's internal protocols use TAB character as a delimiter, but passwords were sent

You have two issues: (a) nouveau's GL driver messed something up, causing a read fault error (b) nouveau's kernel driver tried to recover. It failed. Solution to #1: None, really. You can try updating mesa, and hope it helps. Not sure what version you're on. Solution to #2: Ben Skeggs will hopefully have something clever to say. The recovery logic was recently beefed up considerably,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New nouveau DDX release. Ben Skeggs (1): Bump version to 1.0.12 Ilia Mirkin (14): copy: don't bother trying to create copy on pre-nva3 allow path to envyas binary to be specified kepler: remove unnecessary texbars, add live-only tex for nvf0 use defined method names where available nv50: explicitly disable

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New nouveau DDX release. Ben Skeggs (1): Bump version to 1.0.12 Ilia Mirkin (14): copy: don't bother trying to create copy on pre-nva3 allow path to envyas binary to be specified kepler: remove unnecessary texbars, add live-only tex for nvf0 use defined method names where available nv50: explicitly disable

Some additional data: - putting LIBGL_ALWAYS_SOFTWARE=1 in /etc/environment makes indeed the system work (for my current usage, the slowness is acceptable in exchange of stabillity) - I still get lock-up using mesa from git (17.2~git1705081930.25d2 from this repository https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) I have another question (probably Ben Skeggs could also give an

After upgrading from dovecot-1.0.7 to dovecot-1.0.10 any time when I delete message in logs appeared messages like: Feb 16 23:54:05 mail-chaos dovecot: IMAP(citrin): Cached message offset lost for seq 2 in mbox file /spool/mail/citrin.ru/citrin/Trash Feb 16 23:54:05 mail-chaos dovecot: IMAP(citrin): copy -> Trash: uid=3589, msgid=<E1JHT55-0009fX-3E at spray.anyhost.ru> Removing the

Hello, I would like some clarity from the developers on the state of power management for nouveau. I have recently acquired a Dell XPS 15 (2017) 9560 with: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:591b] (rev 04) 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1) There seems to be contradictory information online with Arch Wiki mentioning:

Are you sure this refactoring doesn't break anything? Few comments inline. On 10/27/2016 04:02 PM, Ilia Mirkin wrote: > This flips GM10x to using the updated format, which is what I tested > with. However GM20x and GP10x also use this TIC format. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > src/nvc0_accel.c | 11 ++++++++++ > src/nvc0_accel.h |

https://bugs.freedesktop.org/show_bug.cgi?id=104652 Bug ID: 104652 Summary: None of the video outputs are usable for GTX 1060 - jerky video very few seconds Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium