similar to: vgacon disable again

fbcon makes the (reasonable) assumption that it only needs to program the hardware once, when fbcon_init() is called for the foreground console. This doesn't always play well with vgacon because vgacon_deinit() is only doing its job when the last console it owns is closed (in most cases, that is *after* fbcon_init() has set the new mode). Depending on the hardware this can cause the wrong

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

Subject: Obtain VESA capabilities and attributes of VESA mode Also, move some more common code to dom0_init_screen_info(). This was tested on 2.6.22.1, and only made apply to 2.6.18 without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-08-07/arch/i386/kernel/setup-xen.c =================================================================== ---

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. So make sure we kick out vgacon early enough that it wouldn't disturb us. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 1 + 1 file changed, 1 insertion(+) diff

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. So make sure we kick out vgacon early enough that it wouldn't disturb us. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 1 + 1 file changed, 1 insertion(+) diff

On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote: > On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote: > > 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. So make sure we kick out vgacon > > early enough

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 Wed, Feb 20, 2019 at 03:36:40PM +0100, Gerd Hoffmann wrote: > 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

On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote: > 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. So make sure we kick out vgacon > early enough that it wouldn't disturb us. > > Signed-off-by: Gerd Hoffmann <kraxel at

Hey all, I have just compiled the 3.11.5 kernel from kernel.org to fix the ACPI wont shutdown issue, but I have a couple errors in dmesg I am trying to figure out. Can anyone point me in the right direction? The errors are: 1: dm_mod: module verification failed: signature and/or required key missing - tainting kernel 2: [drm] VGACON disable radeon kernel modesetting.

Hi, > I was thinking of checking whether pdev is a VGA class device and whether > it decodes vga access, and in that case automatically calling How can I figure that? Ok, class is easy, but decode? pci.h offers functions to set vga decode but not to get that info ... thanks, Gerd

On Thu, Feb 21, 2019 at 4:11 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Hi, > > > I was thinking of checking whether pdev is a VGA class device and whether > > it decodes vga access, and in that case automatically calling > > How can I figure that? Ok, class is easy, but decode? pci.h offers > functions to set vga decode but not to get that info ...

Hi, > I was thinking of checking whether pdev is a VGA class device and whether > it decodes vga access, and in that case automatically calling How can I figure that? Ok, class is easy, but decode? pci.h offers functions to set vga decode but not to get that info ... thanks, Gerd

Otherwise my card (nv92) never resumes from suspend to ram, hanging on nv_mask in nv50_gpio_drive. Before rework, initialization was done only from POST, so this patch restores previous behaviour. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Let me tell you little story about this patch... It took me ~week to figure it out. 1) I bisected it to "drm/nouveau/gpio:

------- Forwarded Message Return-Path: redhat-watch-list-request@redhat.com Received: from lists.redhat.com (lists.redhat.com [199.183.24.247]) by sapphire.fnal.gov (8.8.7/8.8.7) with SMTP id VAA26469 for <yocum@sapphire.fnal.gov>; Wed, 16 Jun 1999 21:19:18 -0500 Received: (qmail 7754 invoked by uid 501); 17 Jun 1999 03:06:01 -0000 Resent-Date: 17 Jun 1999 03:06:01 -0000 Resent-Cc:

below. Dan ___________________________________________________________________________ Dan Yocum | Phone: (630) 840-8525 Linux/Unix System Administrator | Fax: (630) 840-6345 Computing Division OSS/FSS | email: yocum@fnal.gov .~. L Fermi National Accelerator Lab | WWW: www-oss.fnal.gov/~yocum/ /V\ I P.O. Box 500 |

Hi, Here is a patch (on top of the paravirt patch queue) which makes xen guests use the hvc_console.c infrastructure for the console, thereby greatly reducing the amount console code. xvc0 is gone too, hvc0 is used instead. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de>

Hi, Here is a patch (on top of the paravirt patch queue) which makes xen guests use the hvc_console.c infrastructure for the console, thereby greatly reducing the amount console code. xvc0 is gone too, hvc0 is used instead. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de>

Hi, Here is a patch (on top of the paravirt patch queue) which makes xen guests use the hvc_console.c infrastructure for the console, thereby greatly reducing the amount console code. xvc0 is gone too, hvc0 is used instead. cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de>