Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with 3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e Author: Ben Skeggs bskeggs@redhat.com Date: Mon Apr 30 11:33:43 2012 -0500
drm/nouveau: create real execution engine for software object class
Just a cleanup more or less, and to remove the need for special handling of software objects.
This removes a heap of documentation on dma/graph object formats. The info is very out of date with our current understanding, and is far better documented in rnndb in envytools git.
Signed-off-by: Ben Skeggs bskeggs@redhat.com
lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX 1800M] (rev a2)
kernel output from a working 3.4: Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x0a3e00a2) Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Checking PRAMIN for VBIOS Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: ... appears to be valid Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Using VBIOS from PRAMIN Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: BIT BIOS found Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Bios version 70.15.43.00 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: TMDS table version 2.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: MXM: BIOS version 3.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: MXM: MXMS Version 3.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB version 4.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 00: 01000313 00010034 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 03: 080153d6 0f220020 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 04: 08015392 00020020 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 05: 080143c6 0f220010 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 06: 08014382 00020010 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 08: 040383b6 0f230014 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 10: 020273a6 0f220010 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 11: 02027362 00020010 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB outp 13: 02049300 00000000 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 00: 00000040 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 01: 00001161 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 02: 00001231 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 03: 01000331 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 04: 01000446 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 05: 02000546 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 06: 00010631 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 07: 00010746 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 08: 00020847 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: DCB conn 09: 00000900 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0x7AE4 Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 0x7E6B: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 0x7E6F: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0x809A Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0x951E Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0x955C Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0x97CA Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0x982F Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 0x982F: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [TTM] Zone kernel: Available graphics memory: 4008772 kiB Jul 23 19:49:57 localhost kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB Jul 23 19:49:57 localhost kernel: [TTM] Initializing pool allocator Jul 23 19:49:57 localhost kernel: [TTM] Initializing DMA pool allocator Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: Detected 1024MiB VRAM (GDDR5) Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) Jul 23 19:49:57 localhost kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Jul 23 19:49:57 localhost kernel: [drm] No driver support for vblank timestamp query. Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: ACPI backlight interface available, not registering our own Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 3 available performance level(s) Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 0: core 135MHz shader 270MHz memory 135MHz voltage 800mV Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 1: core 405MHz shader 810MHz memory 324MHz voltage 850mV Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: 3: core 561MHz shader 1125MHz memory 1099MHz voltage 1000mV Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: c: core 405MHz shader 810MHz memory 324MHz voltage 1000mV Jul 23 19:49:57 localhost kernel: [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x210000, bo ffff880230e50c00 Jul 23 19:49:57 localhost kernel: fbcon: nouveaufb (fb0) is primary device Jul 23 19:49:57 localhost kernel: Console: switching to colour frame buffer device 210x65 Jul 23 19:49:57 localhost kernel: fb0: nouveaufb frame buffer device Jul 23 19:49:57 localhost kernel: drm: registered panic notifier Jul 23 19:49:57 localhost kernel: [drm] Initialized nouveau 1.0.0 20120316 for 0000:01:00.0 on minor 0
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Glück wrote:
Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with 3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e Author: Ben Skeggs bskeggs@redhat.com Date: Mon Apr 30 11:33:43 2012 -0500
drm/nouveau: create real execution engine for software object class Just a cleanup more or less, and to remove the need for specialhandling of software objects.
This removes a heap of documentation on dma/graph object formats.The info is very out of date with our current understanding, and is far better documented in rnndb in envytools git.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX 1800M] (rev a2)
Please post the crash log.
Marcin
On 24.07.2012 19:00, Marcin Slusarz wrote:
Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it seems). The screen goes black and the machine is dead. So there is nothing I could post here, unfortunately.
This is a video of 3.5 booting: http://www.odi.ch/VIDEO0010.3gp
Don't worry about the external monitor: same behaviour with the built-in panel.
Thanks,
Ortwin
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Glück wrote:
On 24.07.2012 19:00, Marcin Slusarz wrote:
Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it seems). The screen goes black and the machine is dead. So there is nothing I could post here, unfortunately.
This is a video of 3.5 booting: http://www.odi.ch/VIDEO0010.3gp
Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X?
Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log?
Marcin
Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)?
nouveau.noaccel=1 is already on my cmdline as running X with accel enabled never worked anyway.
Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log?
Thanks for the netconsole tip. I have attached the log.
I am not an expert but it looks like a crash in the inlined nouveau_software_vblank(). Is the vblank.list already initialized at this point?
Thanks,
Ortwin
On Wed, Jul 25, 2012 at 10:46:49AM +0200, Ortwin Glück wrote:
Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)?
nouveau.noaccel=1 is already on my cmdline as running X with accel enabled never worked anyway.
Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log?
Thanks for the netconsole tip. I have attached the log.
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?).
-- From: Marcin Slusarz marcin.slusarz@gmail.com Date: Wed, 25 Jul 2012 20:07:22 +0200 Subject: [PATCH] drm/nouveau: init vblank requests list
Fixes kernel panic when vblank interrupt triggers before first sync to vblank request.
(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: Ortwin Glück odi@odi.ch Signed-off-by: Marcin Slusarz marcin.slusarz@gmail.com Cc: stable@vger.kernel.org [3.5] --- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 -- drivers/gpu/drm/nouveau/nouveau_irq.c | 4 ---- drivers/gpu/drm/nouveau/nouveau_software.h | 1 + 3 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 8613cb2..b863a3a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -689,8 +689,6 @@ struct drm_nouveau_private { void (*irq_handler[32])(struct drm_device *); bool msi_enabled;
- struct list_head vbl_waiting; - struct { struct drm_global_reference mem_global_ref; struct ttm_bo_global_ref bo_global_ref; diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c b/drivers/gpu/drm/nouveau/nouveau_irq.c index 868c7fd..b2c2937 100644 --- a/drivers/gpu/drm/nouveau/nouveau_irq.c +++ b/drivers/gpu/drm/nouveau/nouveau_irq.c @@ -41,12 +41,8 @@ void nouveau_irq_preinstall(struct drm_device *dev) { - struct drm_nouveau_private *dev_priv = dev->dev_private; - /* Master disable */ nv_wr32(dev, NV03_PMC_INTR_EN_0, 0); - - INIT_LIST_HEAD(&dev_priv->vbl_waiting); }
int diff --git a/drivers/gpu/drm/nouveau/nouveau_software.h b/drivers/gpu/drm/nouveau/nouveau_software.h index e60bc6c..b507a92 100644 --- a/drivers/gpu/drm/nouveau/nouveau_software.h +++ b/drivers/gpu/drm/nouveau/nouveau_software.h @@ -38,6 +38,7 @@ static inline void nouveau_software_context_new(struct nouveau_software_chan *pch) { INIT_LIST_HEAD(&pch->flip); + INIT_LIST_HEAD(&pch->vblank.list); }
static inline void --
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?).
After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached.
Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing...
Thanks,
Ortwin
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?).
After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached.
Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing...
I didn't look at it yet, but can you catch panic with maxcpus=1?
Marcin
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?).
After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached.
Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing...
No, the real problem is: with "noaccel" we don't register "software engine", but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
--- From: Marcin Slusarz marcin.slusarz@gmail.com Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering PDISPLAY ISR
Currently, we register vblank IRQ handler and later we disable vblank interrupts. So, for the short amount of time, we rely on vblank ISR to operate correctly, even if vblank interrupts are never going to be used later.
In "noaccel" case, software engine - which is used by vblank ISR - is not registered, so if vblank interrupt triggers in a wrong moment, we can hit NULL pointer dereference in nouveau_software_vblank.
To fix it, disable vblank interrupts before registering PDISPLAY ISR.
Reported-by: Ortwin Glück odi@odi.ch Signed-off-by: Marcin Slusarz marcin.slusarz@gmail.com Cc: stable@vger.kernel.org [3.5] --- drivers/gpu/drm/nouveau/nv04_crtc.c | 1 + drivers/gpu/drm/nouveau/nv50_crtc.c | 1 + drivers/gpu/drm/nouveau/nvd0_display.c | 2 ++ 3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c b/drivers/gpu/drm/nouveau/nv04_crtc.c index 4c31c63..38bfe8d 100644 --- a/drivers/gpu/drm/nouveau/nv04_crtc.c +++ b/drivers/gpu/drm/nouveau/nv04_crtc.c @@ -1057,6 +1057,7 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) }
nv04_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, crtc_num);
return 0; } diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c b/drivers/gpu/drm/nouveau/nv50_crtc.c index 97a477b..7648f52 100644 --- a/drivers/gpu/drm/nouveau/nv50_crtc.c +++ b/drivers/gpu/drm/nouveau/nv50_crtc.c @@ -792,6 +792,7 @@ nv50_crtc_create(struct drm_device *dev, int index) goto out;
nv50_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, index); out: if (ret) nv50_crtc_destroy(&nv_crtc->base); diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index c486d3c..32f8a86 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -908,6 +908,8 @@ nvd0_crtc_create(struct drm_device *dev, int index) goto out;
nvd0_crtc_lut_load(crtc); + /* uncomment once nvd0 vblank lands */ + /* nouveau_vblank_disable(dev, index); */
out: if (ret) --
Hey,
Op 29-07-12 22:15, Marcin Slusarz schreef:
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote:
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html has not been applied (yet?).
After applying your patch, it still crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached.
Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing...
No, the real problem is: with "noaccel" we don't register "software engine", but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
From: Marcin Slusarz marcin.slusarz@gmail.com Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering PDISPLAY ISR
Currently, we register vblank IRQ handler and later we disable vblank interrupts. So, for the short amount of time, we rely on vblank ISR to operate correctly, even if vblank interrupts are never going to be used later.
In "noaccel" case, software engine - which is used by vblank ISR - is not registered, so if vblank interrupt triggers in a wrong moment, we can hit NULL pointer dereference in nouveau_software_vblank.
To fix it, disable vblank interrupts before registering PDISPLAY ISR.
Reported-by: Ortwin Glück odi@odi.ch Signed-off-by: Marcin Slusarz marcin.slusarz@gmail.com Cc: stable@vger.kernel.org [3.5]
I can confirm this bug when I was working on adding d0 vblank, but it seems to me like nv*_display_create would be a more logical place to put the disable call. This will make it more clear that vblank is disabled before the irq is registered.
Also maybe add a WARN_ON(!nv_engine(dev, NVOBJ_ENGINE_SW)); in nouveau_vblank_enable and/or return -EINVAL in that case?
If you add the modification to nouveau_vblank_enable: Reviewed-by: Maarten Lankhorst maarten.lankhorst@canonical.com
~Maarten
On 29.07.2012 22:15, Marcin Slusarz wrote:
No, the real problem is: with "noaccel" we don't register "software engine", but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
Unfortunately I am still seeing the crash. Without "noaccel" it works though (until X crashes the machine, but that is a different thing).
Thanks,
Ortwin
On Mon, Jul 30, 2012 at 01:16:37PM +0200, Ortwin Glück wrote:
On 29.07.2012 22:15, Marcin Slusarz wrote:
No, the real problem is: with "noaccel" we don't register "software engine", but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
Unfortunately I am still seeing the crash. Without "noaccel" it works though (until X crashes the machine, but that is a different thing).
Are you sure you boot the correct kernel? I'm asking because your panic says its version is "3.5.0 #3" - exactly the same as in previous crash log.
Marcin
Yes, as far as I can tell. I didn't do anything different this time. The date on the kernel file looks ok. Just did a fresh make && make install again, and got the same behaviour. When is that number after the hash sign upped?
Marcin Slusarz marcin.slusarz@gmail.com wrote:
Are you sure you boot the correct kernel? I'm asking because your panic says its version is "3.5.0 #3" - exactly the same as in previous crash log.
Marcin
On 30.07.2012 19:16, Marcin Slusarz wrote:
Are you sure you boot the correct kernel? I'm asking because your panic says its version is "3.5.0 #3" - exactly the same as in previous crash log.
I am using the correct kernel, don't worry. (.version may not be incremented on each build necessarily).
I am still seeing the same crash with all your patches, but only with "noaccel=1". I have added some printk's (starting with XXX), but can not obtain them via netconsole. I think netconsole may have been disabled and replaced with the real console at that point already? When I boot with noaccel I can see the printk's in the log on disk. That log is attached. I am sorry that I can not provide better information.
Thanks,
Ortwin
I have managed to turn the crash into a WARN_ON, by adding this to the begin of nouveau_software_vblank():
if (!psw) { WARN_ON(1); return; }
And I have also managed to load the module manually instead by udev. So I am happy to attach a full log of what's going on here. See also my added printk's starting with XXX that mark some interesting points in the initialization.
This should give you enough information to track down the cause of the problem. To my non-expert eyes it looks like "noaccel" prevents registration of NVOBJ_ENGINE_SW or at least delays it too much.
Thanks,
Ortwin
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
I have managed to turn the crash into a WARN_ON, by adding this to the begin of nouveau_software_vblank():
if (!psw) { WARN_ON(1); return; }
Yes, I know about it, but this change fixes only a symptom. We should not get into this code at all without enabling vblank.
And I have also managed to load the module manually instead by udev. So I am happy to attach a full log of what's going on here. See also my added printk's starting with XXX that mark some interesting points in the initialization.
This should give you enough information to track down the cause of the problem. To my non-expert eyes it looks like "noaccel" prevents registration of NVOBJ_ENGINE_SW or at least delays it too much.
Yes, that's what I wrote in my last patch - with noaccel it's not registered, which leads to NULL pointer derefence.
I'm currently out of ideas why my patch does not work. But I have some ideas how to debug it. Can you come to nouveau IRC channel at freenode and do some additional tests? My nick is "joi" and I'm available on IRC between 6pm and 11pm CEST.
Marcin
dri-devel@lists.freedesktop.org
-
Maarten Lankhorst -
Marcin Slusarz -
Ortwin Glück