similar to: [Bug 11868] New: Starting X for the second time fails (without reloading drm modules)

Hello, I am kernel engineer working on PV-OPS kernel trying to get it work in Dom0 with an NVidia (NV30 right now) card. But there are issues, such as that the pv-ops kernel has a different understanding of memory (for details check out: http://wiki.xensource.com/xenwiki/XenPVOPSDRM). I've fleshed out most of them (like GART had the wrong phys addresses, ouch!), but the one that I am

Hi, Please find attached the patches which I currently use on my desktop machine for dual head with the randr branch to fix the issues which I found. They may help others as well but may e.g. also disable the Xv blitter which might be working for some (but didn't on my card) - more information is found in the text comments in the patches. I have to hurry so this is short, will be back.

https://bugs.freedesktop.org/show_bug.cgi?id=98997 Bug ID: 98997 Summary: Invalid ioctl during Xorg startup Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

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:

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 115

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

When hash collision occurs and it's near ramht object boundary, we could read and possibly overwrite some memory after ramht object. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: stable at vger.kernel.org --- drivers/gpu/drm/nouveau/core/core/ramht.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/core/ramht.c

On Mon, Mar 24, 2014 at 05:42:26PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c [...] > static int > -nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine, > - struct nouveau_oclass *oclass, void *data, u32 size, > - struct nouveau_object

--- drivers/gpu/drm/nouveau/nouveau_state.c | 52 ++++++++++++++++--------------- 1 files changed, 27 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 2ed41d3..25d207c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -317,7 +317,7 @@ nouveau_card_init(struct

The current logic is wrong since we send fw->size >> 8 to the card. Rounding the size up by 0x100 and 0x1000 didn't seem to help, the card still hung, so go back to what the blob does -- 0x40000. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- What's currently in the tree causes the card to hang. Looking back at all the patches I sent, I always had the firmware

Memory was always allocated for 4096 channels. Change this to allocate what we actually need according to the number of channels we use. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c

Memory was always allocated for 4096 channels. Change this to allocate what we actually need according to the number of channels we use. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c

--- drivers/gpu/drm/nouveau/nouveau_state.c | 73 ++++++++++++++++++++----------- 1 files changed, 48 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 2ed41d3..9fc5824 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -317,7 +317,7 @@ nouveau_card_init(struct

I've been doing some testing and it seems that glyphs (typically smaller than a page size on nv50) render slow'ish sometimes, mostly due to the many trips to the kernel (drm_addmap_core is the symbol that shows up). Ofcource this was a benchmark, but it does leave me wondering, do we really need need to call the kernel for every little pixmap? Also from a memory point of view, because a

Hello, I've build drm and nouveau from git and got this error while starting Xorg. Another thing is that before the install instructions on the wiki worked I had to install xorg-dev. This was the error I got before installing xorg-dev: ./configure: line 20257: syntax error near unexpected token `RANDR,' ./configure: line 20257: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)' I'm not

On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Skip the creation of a software channel for GK20A as software methods > are not yet supported. How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all the 3D Controller ones, and I guess even some that come up as VGA controller in PCI but don't have any outputs in their VBIOS)? i.e.

GK20A does not embed a dedicated COPY engine and thus cannot allocate the copy channel that nouveau_accel_init() attempts to create. It also lacks any display hardware, so the creation of a software channel does not apply neither. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git

GK20A does not embed a dedicated COPY engine and thus cannot allocate the copy channel that nouveau_accel_init() attempts to create. It also lacks any display hardware, so the creation of a software channel does not apply neither. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git

Skip the creation of a software channel for GK20A as software methods are not yet supported. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index ddd83756b9a2..5b46148ffd32 100644 ---