similar to: [PATCH] change acquire/release_console_sem() to console_lock/unlock()

On 03/10/13 15:41, Christoph Rudorff wrote: > On resume of a hibernated notebook, I get garbled virtual consoles. > > fb_set_suspend(*dev, state == 0 means dev is running ...) > > This patch fixes that issue for me: > Ouch, nice catch Christoph :) Seems like the following commit flipped the logic unintentionally, thus causing the issue. Stange enough I have no problems with

On resume of a hibernated notebook, I get garbled virtual consoles. fb_set_suspend(*dev, state == 0 means dev is running ...) This patch fixes that issue for me: hibernate: kernel: nouveau [ DRM] suspending fbcon... kernel: nouveau [ DRM] suspending display... kernel: nouveau [ DRM] unpinning framebuffer(s)... kernel: nouveau [ DRM] evicting buffers... kernel: nouveau [

On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote: > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > while nouveau was runtime suspended, a deadlock would occur due to > > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > > > Fix this by delaying

Current code disables fbcon acceleration before fbcon is suspended, leading to corrupted console after resume from s2disk. In a similar fashion we must make sure that fbcon acceleration is enabled before we revive the console. With this patch s2disk works correctly on my MacBookPro6,2 with GT216 [GeForce GT 330M] hibernate: kernel: nouveau [ DRM] suspending fbcon... kernel: nouveau [

On Wed, Jul 13, 2016 at 04:57:19PM +0200, Daniel Vetter wrote: > On Wed, Jul 13, 2016 at 02:40:50PM +0200, Peter Wu wrote: > > On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote: > > > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > > > while nouveau

There's a short window between module load and fbcon initalization when it's possible for vgacon to write to VGA RAM. Nouveau uses this memory for different purposes, so if we are unlucky, it causes mysterious memory corruptions. For me, booting with nv_printk debug levels set to 5 was enough to trigger it. It manifested as long stream of: "trapped write at ... on channel 0x0001fea0

On 3.8-rc2 with lockdep enabled and dual-GPU setup (Macbook Pro Retina), I see two releated lock inversion issues with the EFI framebuffer, leading to possible deadlock: when X takes over from the EFI framebuffer [1] and when nouveau releases the framebuffer when being vgaswitcherood [2]. Let me know if you'd like any testing or analysis when I can get the time. Many thanks, Daniel ---

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

On Wed, Jul 13, 2016 at 02:40:50PM +0200, Peter Wu wrote: > On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote: > > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > > while nouveau was runtime suspended, a deadlock would occur due to > > >

From: Peter Wu <peter at lekensteyn.nl> [ Upstream commit 7948a2b15873319d1bff4d37c09b9f2bf87b9021 ] "crtc->helper_private" is not initialized by the QXL driver and thus the "crtc_funcs->disable" call would crash (resulting in suspend failure). Fix this by converting the suspend/resume functions to use the drm_mode_config_helper_* helpers. Tested system sleep

On Tue, Sep 04, 2018 at 10:27:47PM +0200, Peter Wu wrote: > "crtc->helper_private" is not initialized by the QXL driver and thus the This is still initialized, it's the ->disable that goes boom. At least the call to drm_crtc_helper_add is still there. The ->disable was removed in: commit 64581714b58bc3e16ede8dc37a025c3aa0e0eef1 Author: Laurent Pinchart

Resuming from RPM can happen while already holding dev->mode_config.mutex. This means we can't actually handle fbcon in any RPM resume workers, since restoring fbcon requires grabbing dev->mode_config.mutex again. So move the fbcon suspend/resume code into it's own worker, and rely on that instead to avoid deadlocking. This fixes more deadlocks for runtime suspending the GPU on the

This patch replaces ast's framebuffer console with DRM's generic implememtation. All respective code is being removed from the driver. The console is set up with a shadow buffer. The actual buffer object is not permanently pinned in video ram, but just another buffer object that the driver moves in and out of vram as necessary. The driver's function ast_crtc_do_set_base() used to

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

On Wed, Jul 13, 2016 at 06:17:47PM +0100, Chris Wilson wrote: > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > while nouveau was runtime suspended, a deadlock would occur due to > > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > > > Fix this by delaying

Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov: > I'm not entirely sure this is correct. One needs to save and disable > accleration before suspending the fb. Please try the following > > - if (state == 0) > + if (state == 1) > nouveau_fbcon_save_disable_accel(dev); > fb_set_suspend(drm->fbcon->helper.fbdev, state); > - if (state == 1) > +

Problem: qxl switches from native mode back into vga compatibility mode when it notices someone is accessing vga registers. And vgacon does exactly that before fbcon takes over. Before qxl switched to the generic fbdev emulation that didn't cause any problems. With the generic fbdev emulation the switch to vga mode happens now and then, probably caused by a initialization order change and

Problem: qxl switches from native mode back into vga compatibility mode when it notices someone is accessing vga registers. And vgacon does exactly that before fbcon takes over. Before qxl switched to the generic fbdev emulation that didn't cause any problems. With the generic fbdev emulation the switch to vga mode happens now and then, probably caused by a initialization order change and

On 04/10/13 01:54, Christoph Rudorff wrote: > Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov: >> I'm not entirely sure this is correct. One needs to save and disable >> accleration before suspending the fb. Please try the following >> >> - if (state == 0) >> + if (state == 1) >> nouveau_fbcon_save_disable_accel(dev); >>