similar to: [bisected][3.9.0-rc3] NULL ptr dereference from nv50_disp_intr()

This series was originally motivated by a deadlock, introduced in commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b 'drm/nouveau/disp: port vblank handling to event interface', due to inverted lock order between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() (the complete lockdep report is included in the patch 4/5 changelog). Because this series fixes the vblank event

This fixes a deadlock inversion when vblank is enabled/disabled by drm. &dev->vblank_time_lock is always taken when the vblank state is toggled, which caused a deadlock when &event->lock was also taken during event_get/put. Solve the race by requiring that lock to change enable/disable state, and always keeping vblank on the event list. Core drm ignores unwanted vblanks, so extra

On 08/12/2013 07:50 AM, Maarten Lankhorst wrote: > This fixes a deadlock inversion when vblank is enabled/disabled by drm. > &dev->vblank_time_lock is always taken when the vblank state is toggled, > which caused a deadlock when &event->lock was also taken during > event_get/put. > > Solve the race by requiring that lock to change enable/disable state, > and

Complete migration of nouveau_event_get/_put from add/remove semantics to enable/disable semantics. Introduce nouveau_event_handler_install/_remove interface to add/remove non-local-scope event handlers (ie., those stored in parent containers). This change in semantics makes explicit the handler lifetime, and distinguishes "one-of" event handlers (such as gpio) from "many

Most nouveau event handlers have storage in 'static' containers (structures with lifetimes nearly equivalent to the drm_device), but are dangerously reused via nouveau_event_get/_put. For example, if nouveau_event_get is called more than once for a given handler, the event handler list will be corrupted. Migrate nouveau_event_get/_put from add/remove semantics to enable/disable semantics.

Lockdep report [1] correctly identifies a potential deadlock between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due to inverted lock order of event->lock with drm core's dev->vblank_time_lock. Fix vblank event deadlock by converting event handler list to RCU. List updates remain serialized by event->lock. List traversal & handler execution is lockless which

Not as thoroughly tested as I would like. Newer nvd0 and kepler are unsupported, as I don't know the registers yet. Information of the scanout position is based on Lucas Stach's original patch, with a teak to read vline twice, to prevent a race of hline with vline. Cc: Lucas Stach <dev at lynxeye.de> Cc: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Signed-off-by: Maarten

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It's unclear to me whether GF11x devices actually support this, but the disp "split" is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't actually have DP in the first place, so it may not be a huge issue. I

Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before the rework to event interface, so I guess it got reintroduced. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 7e3875d..35e526b 100644 ---

Hi again, I got a new dmesg log with the debug parameters, but I guess I could not isolate VESA. I blacklisted it at /etc/modprobe.d/blacklist.conf but comparing those logs I see no difference... Is it possible to isolate VESA somehow without removing it? The new logs are here, I'm posting full content because I'm not sure what information is more relevant...

My new GTX 960 (GM206, I think) says: [ 10.329351] nouveau ![ DEVICE][0000:09:00.0] unknown Maxwell chipset [ 10.329355] nouveau E[ DEVICE][0000:09:00.0] unknown chipset, 0x126010a1 [ 10.329356] nouveau E[ DRM] failed to create 0x00000080, -22 [ 10.330129] nouveau: probe of 0000:09:00.0 failed with error -22 Hacking up nouveau so that it treats it like a GM204 doesn't work. Are

https://bugs.freedesktop.org/show_bug.cgi?id=90453 Bug ID: 90453 Summary: Desktop periodically freezes when using Nouveau & getting "nouveau E[PDISP]" errors in dmesg Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity:

Prepare for transition to RCU-based event handler list; since RCU list traversal may have stale pointers, local storage may go out of scope before handler completes. Introduce nouveau_event_handler_create/_destroy which provides suitable semantics for multiple, temporary event handlers. Signed-off-by: Peter Hurley <peter at hurleysoftware.com> --- drivers/gpu/drm/nouveau/core/core/event.c

https://bugs.freedesktop.org/show_bug.cgi?id=85160 Bug ID: 85160 Summary: [NV94] INVALID_STATE error, X fails to start on GeForce 9600 GT with dual monitors, kernels 3.18.0-0.rc0.git8.2.fc22.1 onwards Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

Provide private field for event handlers exclusive use. Convert nouveau_fence_wait_uevent() and nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent. Signed-off-by: Peter Hurley <peter at hurleysoftware.com> --- drivers/gpu/drm/nouveau/core/include/core/event.h | 1 + drivers/gpu/drm/nouveau/nouveau_fence.c | 20 +++++++------------- 2 files changed, 8

Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have had my mouse pointer disappear soon after logging in, and I have observed the system freezing temporarily when clicking on objects and when typing text. I have also found records of push buffer errors in dmesg output: [ 6625.450394] nouveau 0000:01:00.0: disp: ERROR 1 [PUSHBUFFER_ERR] 02 [] chid 0 mthd 0000 data 00000400 I

On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley <peter at hurleysoftware.com> wrote: > This series was originally motivated by a deadlock, introduced in > commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b > 'drm/nouveau/disp: port vblank handling to event interface', > due to inverted lock order between nouveau_drm_vblank_enable() > and nouveau_drm_vblank_handler() (the

https://bugs.freedesktop.org/show_bug.cgi?id=77529 Priority: medium Bug ID: 77529 Assignee: nouveau at lists.freedesktop.org Summary: NVS 510 DP-3 output doesn't work QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: tex at sergio.spb.ru

https://bugs.freedesktop.org/show_bug.cgi?id=56615 Priority: medium Bug ID: 56615 Assignee: nouveau at lists.freedesktop.org Summary: Unable to start X on ThinkPad T420s laptop QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mark.cave-ayland at

https://bugs.freedesktop.org/show_bug.cgi?id=67628 Priority: medium Bug ID: 67628 Assignee: nouveau at lists.freedesktop.org Summary: [BISECTED] Monitor on Display port shows distortions QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: