similar to: How to make dom0 support framebuffer or vesafb

Currently vesafb/efifb/... is kicked when hardware driver is registering framebuffer. To do it hardware must be fully functional, so there's a short window between start of initialisation and framebuffer registration when two drivers touch the hardware. Unfortunately sometimes it breaks nouveau initialisation. Fix it by kicking firmware driver(s) before we start touching the hardware.

Hi, > > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c > > index e894eb2..a3167fa 100644 > > --- a/drivers/virtio/virtio_pci_common.c > > +++ b/drivers/virtio/virtio_pci_common.c > > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_dev, > > goto err_enable_device; > > > > rc =

Hi, > > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c > > index e894eb2..a3167fa 100644 > > --- a/drivers/virtio/virtio_pci_common.c > > +++ b/drivers/virtio/virtio_pci_common.c > > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_dev, > > goto err_enable_device; > > > > rc =

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc:

Hi all, I''m trying hard to get a framebuffer console on a dom0 (Ubuntu 7.04/Debian Etch with (virtual)framebuffer support compiled it + Xen3.1) and already tried different tutorials, e.g. starting dom0 with kernel parameters - "xencons=xvc console=xvc0 console=tty1" or - "xencons=ttyS0 console=ttyS0 video=xenfb" and appending "S0:2345:respawn:/sbin/mingetty

Hi all, I''m trying hard to get a framebuffer console on a dom0 (Ubuntu 7.04/Debian Etch with (virtual)framebuffer support compiled it + Xen3.1) and already tried different tutorials, e.g. starting dom0 with kernel parameters - "xencons=xvc console=xvc0 console=tty1" or - "xencons=ttyS0 console=ttyS0 video=xenfb" and appending "S0:2345:respawn:/sbin/mingetty

Greetings! I have installed xen-4.0 with kernel 2.6.32 on a gentoo box. Everything works perfectly, except one tiny detail. I do not have X installed on the machine, so I configured the (old, non-xen) kernel to use a framebuffer, so that I don''t have to cope with the ugly 80x25 resolution, especially on a 19" display. Unfortunately, with the xen kernel, dom0 now uses the 80x25 mode

This patch replaces mgag200'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 mga_crtc_do_set_base() used to

Hello. Does anyone know why # CONFIG_FB_VESA is not set in kernel config? I find very useful having a large text console on servers (exp. without X running!). Now my setting vga=0x345 in grub.conf does not work anymore... Thanks! --Clorden

It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com>

On Wed, Mar 25, 2015 at 03:52:01PM +0100, Gerd Hoffmann wrote: > Hi, > > > > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c > > > index e894eb2..a3167fa 100644 > > > --- a/drivers/virtio/virtio_pci_common.c > > > +++ b/drivers/virtio/virtio_pci_common.c > > > @@ -510,7 +510,7 @@ static int

On Wed, Mar 25, 2015 at 03:52:01PM +0100, Gerd Hoffmann wrote: > Hi, > > > > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c > > > index e894eb2..a3167fa 100644 > > > --- a/drivers/virtio/virtio_pci_common.c > > > +++ b/drivers/virtio/virtio_pci_common.c > > > @@ -510,7 +510,7 @@ static int

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...

On 04/12/2015 19:17, Marcelo Ricardo Leitner wrote: > Em 03-12-2015 14:46, Duncan Brown escreveu: >> Here is a couple of pictures, >> >> http://i.imgur.com/Vqvqn1H.jpg >> http://i.imgur.com/WQaz1j9.png >> >> Any use? > > Of some. It's failing on ftrace initialization while allocating > memory, but can't know the real reason. It can be just

--- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 32 ++++++++++++++++++++++++++++++-- drivers/virtio/virtio_pci_common.c | 7 ++++++- 2 files changed, 36 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c index 56bd4ed..33d12d5 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c +++

--- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 32 ++++++++++++++++++++++++++++++-- drivers/virtio/virtio_pci_common.c | 7 ++++++- 2 files changed, 36 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c index 56bd4ed..33d12d5 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c +++

https://bugs.freedesktop.org/show_bug.cgi?id=83271 Priority: medium Bug ID: 83271 Assignee: nouveau at lists.freedesktop.org Summary: Windowed mode causes framebuffer not to refresh with PRIME on optimus/kepler discrete GPU QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified

Hi folks, Backing up a host as noted below im getting over and over again the same issue on actual kernel, details: - Backup host has a pci/usb2.0 card, with a 250gb usb 2.0 disk attached, - Celeron 900 family - Remote host, local console from boot linux rescue: # dd if=/dev/hda conv=sync,noerror | ssh -c blowfish root at 192.168.0.6 "dd of=/media/backup/vol-hda.raw.img" - Backup

Hello! I have spent some time on the issue. I'm not sure it's a nouveau bug. I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only. GRUB actually uses graphic mode on my card. That mode is supported by simplefb. However, the resource conflict happens regardless of whether simplefb is enabled. It's sysfb_simplefb that causes it, a completely different driver. If GRUB

Hi all, new to this list ;) I have a Lenovo Thinkpad T61. lspci|grep VGA says: 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1) I have Slacware64-13.0 and Slackware64-current installed. Nouveau is modularized in all my kernels for -current. A problem arise even if I don't want to use nouveau under X: unless nouveau be blacklisted in