On Tue, Sep 03, 2013 at 05:48:48PM +0300, Pasi Kärkkäinen wrote:
> > >>>>> Not it really isn't appropriate..
> > >>>>>
> > >>>>> You'd have to call call nouveau_vm_map_sg_table instead, the only
> > >>>>> place that doesn't handle that correctly
> > >>>>> is where it's not expected to be called.
> > >>>>>
> > >>>>> Here, have a completely untested patch to fix things...
> > >>>>>
> > >>>> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to
> > >>>> modify the patch a bit to make it apply there..
> > >>>> I've attached the modified copy that applies to 3.10.9, hopefully I
> > >>>> did the backport correctly.
> > >>>>
> > >>>> With Linux 3.10.9 and the patch applied the kernel doesn't crash
> > >>>> anymore, and I get this error in dmesg:
> > >>>>
> > >>>> [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with
> > >>>> valid_domains=00000004
> > >>>>
> > >>>> Does that help?
> > >>>>
> > >>> Any comments?
> > >>>
> > >>> Maarten's patch works for me, I get that warning instead of a kernel
> > >>> crash,
> > >>> but it's also a bigger change that doesn't apply to older kernels
> > >>> as-is.
> > >>>
> > >>> Ilia's original patch in this thread can be applied to older kernels
> > >>> as-is,
> > >>> and it also prevents the kernel crash from happening.
> > >>>
> > >>> Should we get both applied, so Ilia's patch can be CC'd to stable ?
> > >>>
> > >> You haven't understood the root cause then. You're trying to move an
> > >> IMPORTED dma-buf into VRAM.
> > >> Doing so would seem to work, but at that point it's no longer a dma-buf
> > >> so changes done by the exporter
> > >> would not show up in nouveau because they no longer refer to the same
> > >> piece of memory.
> > >>
> > > Yes, that's true, I don't understand the root cause.
> > > That's mostly because I'm not familiar with the nouveau code/internals.
> > >
> > >
> > >> Failing is the only right option here.
> > >>
> > > Sorry but I'm not sure I understand that correctly.. what exactly do you
> > > suggest? What should fail?
> > >
> > >
> > > Because I'm not familiar with the code (yet) understanding and finding
> > > the root cause
> > > will take time for me.. that's why I was suggesting to meanwhile apply
> > > Ilia's very simple patch
> > > from this thread which actually prevents the hard kernel crash from
> > > happening, because it seems
> > > like an unharmful fix to have to protect against this kind of bugs (the
> > > root cause) ?
> > > Or is that unacceptable?
> > >
> > > (To recap: The kernel crash happens very often when trying to use the
> > > nouveau adapter in Optimus mode, with all kernels at least 3.8+, and it's
> > > very annoying that your laptop crashes when trying to enable a nouveau
> > > output. So Ilia's patch doesn't make the driver working properly, but at
> > > least it prevents the hard kernel crash from happening. The crash bug is
> > > in many kernel versions, including the long-term v3.10 tree. I've had the
> > > crash happening with 3.8.x, 3.9.x and 3.10.x)
> >
> > The fix probably requires commit fdfb8332651db7a280851dfccfc4f0cff4bcd052
> > to apply cleanly "drm/nouveau: fix some error-path leaks in fbcon handling
> > code"
> >
>
> So what you mean is to use fdfb8332651db7a280851dfccfc4f0cff4bcd052 and your
> patch from this thread?
> and skip Ilia's patch?
>
So I tested with Linux 3.10.10. I had to apply these two patches first:
1e2bd5f53b6282e711e9f074765911868f8e7dc1 drm/nouveau: fixup fbcon failure paths
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=1e2bd5f53b6282e711e9f074765911868f8e7dc1
fdfb8332651db7a280851dfccfc4f0cff4bcd052 drm/nouveau: fix some error-path leaks
in fbcon handling code
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=fdfb8332651db7a280851dfccfc4f0cff4bcd052
And with those applied I was able to apply Maarten's patch cleanly (also
attached to this email).
It's worth noting that I'm able to reproduce the kernel crash bug with Fedora
18 (which has xorg-1.13),
but I'm not able to reproduce it with Fedora 19 (which has xorg-1.14). Both
running the same kernel.
Optimus enabled in BIOS on Lenovo T430 laptop. Nvidia GF108 Discreet GPU with
Intel integrated GPU.
Maarten's patch fixes the kernel crash problem, and produces a warning message
instead in dmesg.
You can add my Tested-By to the patch, assuming Maarten's patch is going to be
merged?
Thanks,
-- Pasi
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
{
struct nouveau_framebuffer *nouveau_fb;
struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
int ret = -ENOMEM;
gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (!gem)
return ERR_PTR(-ENOENT);
+ nvbo = nouveau_gem_object(gem);
+ if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
+ nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
+ " valid_domains=%08x\n", nvbo->valid_domains);
+ ret = -EINVAL;
+ goto err_unref;
+ }
+
nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
if (!nouveau_fb)
goto err_unref;
- ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nouveau_gem_object(gem));
+ ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
if (ret)
goto err;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
