similar to: [Bug 24810] New: TTM out of aperture space, X lockup

Afer an upgrade to xorg-server-1.7.0.902 and latest git for the kernel and xorg nouveau drivers I cannot start x with kms under wmaker. As root (just twm and an xterm) it's ok. Dmesg shows: [drm] DAC-6: set mode 1680x1050 1a [drm] nouveau 0000:01:00.0: nv04_dac_mode_set called for encoder 0 [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on CRTC 0 [drm] nouveau 0000:01:00.0: Setting dpms

Hi there, I have just decided to try this new driver stuff (used 2.6.27 earlier and a proprietary nvidia driver) but the monitor (Samsung 214T) becomes black and the power LED starts flashing (standby) after loading nouveau module (from a fresh 2.6.33). For now I am trying framebuffer only. The monitor is connected with a single link DVI cable. lspci -nn 03:00.0 VGA compatible controller

http://bugs.freedesktop.org/show_bug.cgi?id=25754 Summary: Nouveau - GPU Lockup on 2.6.33-rc1 Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

Cleanup make system so that all noninstalled headers are put to noinst_HEADERS. This quarentees that header will be present in tar ball but not installed with make install. CC: nouveau at lists.freedesktop.org Signed-off-by: Pauli Nieminen <suokkos at gmail.com> --- Makefile.am | 6 +++--- intel/Makefile.am | 10 ++++++---- nouveau/Makefile.am | 4 +++- 3 files changed,

http://bugs.freedesktop.org/show_bug.cgi?id=24147 Summary: xv output slow and causes wmaker screen corruption Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

http://bugs.freedesktop.org/show_bug.cgi?id=25261 Summary: Fails at start on NV44 Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: monnier at

On Mon, 27 May 2019 at 09:19, Emil Velikov <emil.l.velikov at gmail.com> wrote: > > From: Emil Velikov <emil.velikov at collabora.com> > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Note: the outstanding

From: Emil Velikov <emil.velikov at collabora.com> The authentication can be circumvented, by design, by using the render node. >From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Note: the outstanding DRM_AUTH instance is: - legacy DRI1 ioctl, which is already neutered Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at

Today I tried Ubuntu-10.04 on a system with an NV34 (Geforce-5200) AMD-751 (Ironlake) Northbridge, however the kernel-module fails to initialize. Any idea what could be going wrong? Thank you in advance, Clemens PS: I filed a bug at ubuntu's launchpad: https://bugs.launchpad.net/ubuntu/+bug/580656 May 14 19:17:28 max-desktop kernel: [ 3.266782] [drm] Initialized drm 1.1.0 20060810 May

http://bugs.freedesktop.org/show_bug.cgi?id=25823 Summary: Not possible to create second X session Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=27928 Summary: Nouveau / Mesa sometimes gets libraries overwritten Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at

http://bugs.freedesktop.org/show_bug.cgi?id=24780 Summary: 2 second delay during boot using nouveau Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

On Wed, Jul 28, 2010 at 01:42:03AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said: > > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to > > > > http://userweb.kernel.org/~akpm/mmotm/ > > Hit this while the X server was on its way down during a 'shutdown -r now'. Worked fine

I am happy to report that the patches to support my video card under Nouveau have appeared in the mainstream kernel (currently running 2.6.34-rc5). But I have noticed that, if I run mplayer with -vo gl (output to an OpenGL window), the machine tends to crash after a variable time - from a few seconds to a few minutes. I tried with full-screen or partial, and even with the actual playback screen

Hi Patch "drm/nouveau: use drm_mm in preference to custom code doing the same thing" in nouveau tree introduced new deadlock possibility, for which lockdep complains loudly: [ 1541.070202] [drm] nouveau 0000:02:00.0: Allocating FIFO number 3 [ 1541.084772] [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 3 [ 2417.733440] [drm] nouveau 0000:02:00.0:

Hello, Since I've updated to F13 I keep getting blank screens at "cold" boot with this card: 00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce 6150] (rev a2) When I say "cold" boot I mean the first couple of times I turn on my computer in the morning. After a couple of reboots I get plymouth to show up, and then X11. This never happened with F12. After

From: Sui Jingfeng <suijingfeng at loongson.cn> This patch adds the aperture_contain_firmware_fb() function to do the determination. Unfortunately due to the fact that apertures list will be freed dynamically, the location and size information of the firmware fb will be lost after dedicated drivers call aperture_remove_conflicting_devices(), aperture_remove_conflicting_pci_devices() or

Use ioremap() for mapping the channel user regs (that are never exposed to user space) instead of drm_addmap(). This removes the last use cases of drm_addmap/drm_rmmap from Nouveau. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 13 ++++++------- drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +++------

Switching focus to a previously idle firefox and starting to type in the google bar, the screen locked up (and the display went black and showed 'no signal'). Ssh'ing into the machine, I found this in dmesg: [drm] nouveau 0000:01:00.0: Allocating FIFO number 1 [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1 [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on